Velocity - קצב התקדמות לכיוון מסויים של הצוות בפיתוח של דרישות חדשות.

Throughput - כמות העבודה שהצוות מספק בפרק זמן נתון.

אחרי קרוב לשני עשורים בתעשיה, נוכחתי לדעת שנדיר למצוא שני ארגונים, או אפילו שני צוותים באותה חברה, הפועלים באופן זהה. עם זאת, קיימות אסטרטגיות מוכחות לשיפור ה-Velocity וה-Throughput של צוותי פיתוח, המשותפות לרבים מהם. האתגר האמיתי הוא לזהות אילו מתוכן ישפרו באופן משמעותי את הביצועים תוך שמירה על הגמישות והתפוקה הגבוהה האופייניות לחברות סטארטאפ, גם כאשר החברה בתהליך צמיחה.

אתם בטוח מכירים את זה - מתחילים מחברה קטנה, דברים זזים סופר מהר. כל יום פיצ׳רים חדשים, כל שבוע משחררים גרסאות חדשות והכל נראה מדהים. ואז, פתאום מבלי משים, קצב ההתקדמות יורד באופן משמעותי. דברים שהייתם מפתחים בכמה ימים, פתאום לוקחים שבועות ולפעמים חודשים עד שכל הסטייקהולדרס (בעלי העניין) מתיישרים, כל הצוותים ביצעו אינטגרציה והפיצ׳ר החדש מוכן להגיע לידי הלקוחות.

אז איך בכל זאת אפשר גם לגדול וגם לשמור על הגמישות, המהירות והתפוקה של חברות קטנות?

אתחיל מזה שאין מטה קסמים שיאפשר לנו לעשות את הכל מושלם כל הזמן, ואם למישהו יש מטה שכזה, אשמח לשמוע עליו. מה שכן, אני יכול לשתף במה שעזר לי להוביל לא מעט צוותי פיתוח לאורך השנים ולדאוג לכך שננסה לשמר ולשפר את המדדים הללו.

בהירות (Clarity)

יצירת בהירות לגבי המטרות והעדיפויות היא אחד הצעדים הקריטיים ביותר לשיפור הביצועים של צוות הפיתוח. חוסר בהירות יכול לגרום לבזבוז זמן ומשאבים על פרויקטים שאינם תורמים למטרות העיקריות של המחלקה והחברה. 

לדוגמה, אם החברה שלך מפתחת אפליקציית מסרים, יש להבהיר לצוות אם המטרה העיקרית היא הוספת משתמשים חדשים או שיפור חווית המשתמש הקיימת. החלטות הפיתוח ייראו שונה לחלוטין בהתאם למטרה:

אם המטרה היא הוספת משתמשים, צוות הפיתוח ישים דגש על פיצ'רים שיגדילו את החשיפה והגיוס, כמו שיתופי רשתות חברתיות אינטגרטיביים וממשקים לייבוא אנשי קשר קיימים. מצד שני, אם המטרה היא שיפור חווית המשתמש, הדגש יהיה על יכולות חדשות לשיתוף תכנים, התאמה אישית של הממשק וכדומה.

בדוגמא אחרת, אם אתם חברת תוכנה שמפתחת מוצרים עבור לקוחות עסקיים, חשוב להבהיר מה חשוב יותר - לספק מוצר מלא ומושלם או להיכנס לשוק מהר יותר עם פיצ'רים בסיסיים. ההחלטות לגבי גמישות מול שלמות המוצר ישתנו בהתאם.

כדי ליצור בהירות, כדאי לקיים דיונים משותפים ושקופים על המטרות והעדיפויות עם הצוות. פרטו את הרציונל מאחורי כל מטרה ואיך היא הולכת יד ביד עם אסטרטגיית החברה. ודאו שכל חבר צוות מבין את חלקו בהשגת היעדים הללו.

יכולות (Capabilities)

לאחר שהמטרות ברורות, חשוב לוודא שלצוות הפיתוח יש את כל המשאבים והיכולות הנדרשים כדי לבצע את המשימות ביעילות מירבית. אחד המשאבים החיוניים ביותר הוא מוביל טכני חזק ומנוסה. ,תפקיד זה לאו דווקא צריך להיות מאוייש בידי המנהל. מה שחשוב הוא שיהיה גורם טכני מוביל כלשהו על מנת לסייע ולתמוך בחברי הצוות.

לדוגמא, אני מאמין גדול בג'וניורים - כ-30% מצוות המו"פ שלי הם בעבודה הראשונה שלהם בתעשייה. לא היינו יכולים להרשות לעצמנו זאת ללא מובילים טכניים מוכשרים שמספקים הכשרה, עזרה בעיצוב המערכת, מעבר על PRים וכד'.

המוביל הטכני ממלא שני תפקידים מרכזיים:

1. הדרכה וחניכה של מפתחים ג׳וניורים בכל הקשור לפיתוח, בחירת טכנולוגיות, ראיונות קוד ועוד. בהנחה שמדובר בגורם מנוסה, הדבר יכול לחסוך זמן רב לצוות.
2. זיהוי וטיפול מוקדם בבעיות פוטנציאליות - מוביל בעל ניסיון רב יכול לחזות ולהעלות דגלים אדומים עוד בשלבים מוקדמים של הפרויקט, לפני שהמפתחים האחרים יבחינו בסימני האזהרה.

    

יצא לי לעבוד עם לא מעט Tech Leads עם כישרון רב שהצליחו לפתור לא מעט תקלות לפני שאלו קרו, לחזות מקומות בעייתיים בקוד ובארכיטקטורה שלא היו עולים בדעתם של מפתחים בתחילת דרכם כלל וכלל. 

דבר נוסף שמוביל טכני מאפשרת היא פרספקטיבה, והיכרות עם דפוסי פיתוח מוכרים שמאפשרים חיסכון עצום בזמן מבלי להמציא את הגלגל על בעיות שכבר נפתרו.

הסטה שמאלה (Shift Left)    

גישת "הסטה שמאלה" (Shift Left) היא דרך יעילה לשיפור איכות הקוד וקיצור זמן הפיתוח. הרעיון הוא לשלב פעילויות כמו בדיקות, אבטחת איכות (QA), וטיפול בסוגיות אבטחה כבר בשלבים המוקדמים של מחזור החיים של הפרויקט. 

במקום לחכות עד לסיום הפרויקט ורק אז לרכז את כל הבדיקות והפעילויות הללו בשלב האינטגרציה, הגישה היא שיש לבצע אותן באופן שוטף ומתמשך. כך, הבעיות נתפסות ומטופלות בצורה מהירה ו״זולה״ יותר, לפני שהן מסתבכות מעבר למצופה.

למשל, לפני מספר שנים פיתחנו מערכת עבור צה״ל לפיקוד העורף, שתפקידה היה לחזות מה קורה במקרה וישנו פיצוץ במיכלי אמוניה ואת מי צריך לפנות. את הבדיקות התחלנו כבר בימים הראשונים של בדיקת המערכת ולא כעבור חודשים של פיתוח. הדבר איפשר לנו לספק מערכת מבצעית לצה״ל ללא עיכובים, שכן כל בדיקות האינטגרציה ביצעו מיד לאחר יצירתן ולא חודשים לאחר מכן.

לעומת זאת, בגישה המסורתית של השארת הבדיקות לשלב מאוחר, ייתכן וצוות הפיתוח יקדיש חודשים לבניית המערכת, רק כדי לגלות בבדיקות האינטגרציה שישנן בעיות חמורות הדורשות תיקונים נרחבים. 

הבעייתיות כאן היא לא רק בעלות הגבוהה לביצוע התיקונים. כשהמפתחים צריכים לחזור למקורות הקוד הישנים שנכתבו לפני זמן רב, יש להשקיע זמן ומאמץ רב כדי להיזכר בקוד ובמערכת כולה. גישת "הסטה שמאלה" חוסכת את התסבוכת הזו.

ככל שיש פחות מעורבות של גורמים חיצוניים בפרויקט, כך הפרויקט יתקדם באופן חלק יותר. כשמוצר עובר ״הרבה ידיים״ - מעצבים, מפתחים, אנשי אבטחת איכות, וכו' - יש הרבה שינויי קונטקסט (מעבר בין משימות שונות בזמן קצר), חפיפות ושלבים של המתנה שמאריכים את זמן העבודה על הפרויקט.

מניעת הסחות דעת ויצירת פוקוס בפרויקט (Context Switching)

שינויים תכופים של תחומי עבודה ומעברים ממשימה אחת לאחרת פוגעים ביעילות המפתחים. כשמפתח נדרש לעבור לפרויקט שונה לחלוטין, ידוע כי יש להשקיע זמן רב בלימוד הקונטקסט החדש, המערכת, הטכנולוגיות והדרישות. הדבר מביא לזמן השקעה ארוך והפחתת יעילות הפיתוח בטווח הקצר.

ככל שיוקצו צוותים ספציפיים לתחומים וליכולות מסוימות, כך יתאפשר למפתחים להתמקד על הפיצ׳ר הנדרש בפרויקט, ללא צורך בשינויי קונטקסט תכופים. זוהי דרך יעילה למנוע בזבוז משאבים על לימוד מחדש של פרויקטים שונים.

הדבר עומד בעינו גם כאשר מפתח מסוים עובד על מערכת אחת, אך צריך להתמודד עם הרבה שינויי קונטקסט לאורך היום. לדוגמה, אם מצופה מהמפתחים לאורך היום ״לעזוב את הכל״ ולענות על מיילים בעת הגעתם, או לפתור באג לא קריטי כאשר הטיקט נפתח. הדבר יוביל לכך שהמפתח צריך ״לזרוק״ הצידה את כל המודל המנטלי המושקע במשימה ולנסות מאוחר יותר לשוב אליו - דבר שייקח זמן לאחר שקו המחשבה נקטע. 

תרבות אחריות אישית (Accountability)

חלק מרכזי בהעלאת תפוקת צוותי פיתוח היא טיפוח תרבות ארגונית של אחריות אישית (accountability), שבה מצופה מכל חבר וחברת צוות לקחת אחריות מלאה על תחום אחריותם ולגלות מחויבות להשגת היעדים שהוגדרו.

כאשר חברי הצוות תופסים את עצמם כשותפים משמעותיים להצלחה או לכישלון של הפרויקט, נוצרת מוטיבציה חזקה להשיג יותר. זוהי גישה הפוכה לסביבה שבה אנשים מסתתרים מאחורי בירוקרטיות, פועלים רק על פי הוראות ללא מעורבות אמיתית, ולעתים אף מדירים מעצמם אחריות באמרות כמו "זה לא תחום אחריותי" או "זה באחריותו של מישהו אחר".

לדוגמה, בפרויקט שביצענו בעבר עבור פיקוד העורף שאר הינו חיוני ומציל חיים, הוטמעה תרבות accountability באמצעות שיתופי פעולה הדוקים בין חברי הצוות. המפתחים עבדו בצוותים קטנים על מודולים שונים של המערכת, אך התקיימו מפגשי עדכון יומיים קצרים שבהם כל צוות סקר את ההתקדמות והאתגרים. כשהתגלו בעיות או חסמים, חברי הצוותים האחרים התגייסו לסייע ללא היסוס, מתוך תחושת אחריות משותפת להצלחת הפרויקט.

כשחברי צוות חשים אחריות אישית להצלחה, העבודה הופכת ממשימה טכנית לחתירה משותפת להשגת היעדים. תרבות accountability מניעה אותם להשקיע מאמץ נוסף, לקחת סיכונים ולפעול "מעבר לקו" בשירות המטרה המשותפת.

עצמאות וגמישות לצוותים (Team Autonomy & Flexibility)

נדבך חשוב נוסף להעלאת תפוקת צוותי פיתוח הוא מתן עצמאות וגמישות לצוותים לקבל החלטות ולנהל את עבודתם באופן אוטונומי, בכפוף למטרות ולקווים מנחים כלליים. 

צוותים אוטונומיים שאחראים על חלקים ממוקדים של המוצר יכולים להתקדם במהירות רבה יותר מצוותים הצריכים אישור על כל צעד. העצמאות מאפשרת להסיר חסמים בזמן אמת, כאשר הצוות יכול להחליט באופן עצמאי על טכנולוגיות, כלים, תהליכים ועוד, מבלי להמתין לאישורים מההנהלה.

לדוגמה, בחברת תוכנה לניהול פרויקטים, הצוות שפיתח את מערכת ניהול הלקוחות היה עצמאי לגמרי בבחירת שפת הפיתוח, סביבת העבודה וזירת השיתוף. הם יכלו לקדם את העבודה בקצב מהיר מבלי להמתין לאישורים שיכלו להתעכב. חשוב להדגיש, כי ישנן עדיין קווים מנחים הצד האירגון או הגילדות, אך הן יותר בגדל המלצות מאשר הכתבות מלמעלה. 

עצמאות כרוכה גם בגמישות - הרשאה לצוות לעבוד בשעות ובמקומות המתאימים להם. אפשרות לעבוד מרחוק או בשעות לא שגרתיות מאפשרת איזון טוב יותר בין עבודה לחיים האישיים וגם מייעלת את העבודה. כמובן שיש לשמור על תיאום וזמינות מינימליים, אך ניסיון מראה כי הגמישות הזו מעלה את המוטיבציה והמסירות של חברי הצוות.

כך, עצמאות וגמישות מאפשרות לצוותים להיות "בעלי המשחק" של הפרויקט שלהם ולא רק "רשות מבצעת". תחושת הבעלות וההרשאה להחליט מגבירות את המחויבות ואת הרצון להשיג יותר. במקום לבזבז זמן על אישורים וחסמים בירוקרטיים, הצוות יכול להתמקד בעשייה ובחתירה להישגים.

לסיכום

להלן העקרונות המנחים שהובאו בבלוג זה, כצ׳ק ליסט שניתן לקחת ולאמץ ליומיום. אני מאמין שרצוי להטמיע את חלקם, אם לא כולם,  בכל ארגון שרוצה לשפר את קצב הפיתוח שלו:

1. יצירת בהירות מוחלטת לגבי מטרות הפרויקט, דרכי הפעולה והגדרת עדיפויות. ככל שיש פחות אי-בהירויות, כך הצוותים יכולים להתמקד בביצוע יעיל יותר.
2. וידוא שלצוותים יש את כל הכלים, המשאבים והיכולות הנדרשים לביצוע הפרויקט ביעילות, כולל מוביל טכני מנוסה.
3. אימוץ גישת "הסטה שמאלה" שמשלבת פעילויות כמו בדיקות, QA ואבטחה כבר בשלבים המוקדמים של הפיתוח כדי לזהות ולפתור בעיות מוקדם ככל האפשר.
4. מזעור שינויי קונטקסט והפרעות לצוותים כדי לאפשר ריכוז וזרימת עבודה רציפה.
5. טיפוח תרבות של אחריות אישית, מסירות ומחויבות לתוצאות בקרב חברי הצוותים.
6. מתן עצמאות וגמישות לצוותים לקבל החלטות באופן עצמאי בתוך מסגרת העבודה שהוגדרה.

כידוע, אין פתרון קסם אחד שמתאים לכל הארגונים. כל חברה צריכה לזהות את נקודות הכשל והחסמים הספציפיים לביצועי הצוותים שלה, ולפתור אותם באמצעות שיטות מותאמות. שיתוף פעולה הדוק בין כל הגורמים המעורבים - מנהלים, מובילים טכניים, מפתחים, אנשי QA ואחרים - הוא הבסיס ליצירת תהליך פיתוח גמיש, יעיל ומהיר. 

בסופו של דבר, השילוב הנכון של כל הגורמים הללו והתאמתם למאפיינים הספציפיים של הארגון והפרויקטים החשובים לו, הוא שיאפשר קצב פיתוח מהיר ויעיל. זוהי מלאכה מתמשכת של למידה, שיפור והתאמה מתמדת של התהליכים לצורך שינוי מהותי שיורגש באופן יומיומי.