בקצרה: רוב השיחה על Agentic Development עוסקת במהירות כתיבת הקוד. אבל ביום עבודה של צוות תוכנה, חלק גדול מהזמן הולך על בירורים, תיאומים, המתנה לאישור ותיקונים של דברים שכבר נבנו. כשאפשר לראות גרסה עובדת מוקדם ולשנות אותה בזול, העבודה הזו מתכווצת. מהניסיון שלנו, שם נמצא חלק משמעותי מהחיסכון.
החיסכון שלא מופיע בדוח המהירות
כשמדברים על Agentic Development, מדברים בדרך כלל על קוד: כמה משימות מפתח אחד מספיק, כמה זמן לוקח להוסיף פיצ׳ר, כמה עבודה אפשר להעביר לסוכן AI.
תסתכלו על שבוע עבודה רגיל של הצוות שלכם. כמה ממנו הלך על כתיבת קוד, וכמה על הבהרות, ישיבות, המתנה לאישור ותיקונים של משהו שכבר עבד?
ב-Globalbit ראינו ששם מסתתר חלק גדול מהחיסכון. הדרך שבה אנשי מוצר, UX, עיצוב, פיתוח ו-QA עובדים יחד משתנה ברגע שאפשר לראות גרסה עובדת מוקדם, ולתקן אותה מהר.
הדרישה הייתה מדויקת. הערך שלה פחות
במשך שנים, מנהלי מוצר, מאפייני UX ומעצבים הגדירו איך המוצר צריך להיראות ולהתנהג, וצוות הפיתוח נדרש לבצע בדיוק. כל סטייה מהאפיון הפכה למשימת תיקון, גם כשהפתרון שנבנה בפועל עבד היטב.
ויש משהו שלא נעים להגיד בענף: רוב אנשי המקצוע בינוניים. מעט מאוד הם באמת הטופ. זה נכון למנהלי מוצר, למאפיינים, למעצבים, למפתחים ולמנהלים. תהליך עבודה טוב צריך להביא את זה בחשבון.
התהליך המסורתי נתן גם למאפיין בינוני כוח להעסיק צוות שלם במשך ימים סביב הדרך שבה הוא אישית רצה שהמוצר יעבוד. ברגע שדרישה נכנסה למסמך, היא קיבלה מעמד מחייב, בלי קשר לשאלה כמה מחשבה, ניסיון או הבנה של המשתמש עמדו מאחוריה.
חלק מהדיוק הזה הכרחי. חלק אחר הוא העדפה אישית שהפכה למשימה של כמה אנשים.
דוגמה אחת: חלונית צד או מסך נפרד
ניקח מסך פשוט לאישור בקשות. באפיון נקבע שלחיצה על בקשה פותחת מסך נפרד. בפיתוח נבנתה חלונית צד, שמאפשרת לראות את הפרטים ולאשר בלי לצאת מהרשימה.
נניח ששתי האפשרויות עומדות בדרישות ונוחות למשתמשים. עדיין, מספיק שמישהו יתעקש על התאמה לאפיון כדי להתחיל סבב עבודה חדש: המפתח משנה את הניווט, המעצב מעדכן מצבים, איש ה-QA בודק שוב, ומנהל הפרויקט מכניס את התיקון לתוכנית.
בדוח השעות יופיעו פיתוח, עיצוב, בדיקות וניהול. אף שורה לא תגיד שהצוות השקיע את כל זה כדי להחליף פתרון סביר בפתרון סביר אחר.
כשזה חוזר על עצמו לאורך פרויקט, מצטבר הרבה זמן. ומצטבר גם חיכוך. אנשי המוצר מרגישים שלא מקשיבים להם. המפתחים מרגישים שמבזבזים להם את הזמן. והבודקים צריכים להכריע אם משהו תקין לפי מסמך שכבר לא בהכרח משקף את הפתרון הנכון. (כתבנו על זה גם באיך מנהלים שינויי היקף בפרויקט.)
לראות מוצר לפני שמחליטים על כל פרט
ב-Agentic Development אפשר להגיע לגרסה שאפשר להפעיל ולבחון עוד לפני שסיימנו לפרט כל מסך וכל התנהגות. מגדירים את הצורך, את המשתמשים, את התהליך העסקי ואת האילוצים, ומתקדמים למימוש ראשוני עם סוכני AI.
כש-Product Owner יושב מול גרסה עובדת, הוא מחליט אחרת. הוא משלים פעולה, רואה איזה מידע חסר ומרגיש איפה התהליך מסורבל. הרבה יותר קל להגיד ״כאן חסר לי משהו״ מאשר לדמיין מראש את כל מה שיצטרך.
הוא גם פוגש פתרונות שלא היה בוחר בעצמו, ומגלה שהם עובדים. החלונית מהדוגמה הקודמת יכולה להתברר כנוחה לגמרי. אין סיבה להחליף אותה רק כי בתכנון המקורי דמיינו מסך אחר.
כך אפשר לוותר מראש על חלק מהאפיון המפורט, ולמקד את סבב השינויים במה שבאמת משפיע על השימוש. גם אנשי המוצר מרוויחים: יורד מהם הלחץ לנחש ולסגור כל פרט לפני שמישהו מתחיל לבנות.
