איך לגדול כארגון – מבלי לאבד את המהירות? (על מִקּוּד)

• "כשהיינו חצי מהאנשים היום – נדמה לי שעשינו בערך אותה כמות של דברים"
• "כשחברה מגייסת עוד הרבה עובדים, היא לא הופכת לגדולה יותר – היא הופכת לשמנה יותר"
• "אי אפשר לזוז פה… כל היום יש רק ישיבות. איפה הימים של פעם, שכתבנו קוד רוב היום?!"

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

איך טווטיר / פייסבוק / Whatever – נתנו בשנים הראשונות ערך, שנראה לא רחוק מהערך היום, אבל עם שבריר מהעובדים שיש להם היום?

לתופעה הזו יש כמה הסברים פשוטים:

• כשהארגון הוא קטן – מתמקדים ביכולות ("פיצ'רים") שהם Low-hanging fruits, מעט השקעה – והמון ערך. הפיצ'רים הללו נגמרים די מהר – ונשארים רק פיצ'רים שדורשים השקעה גדולה יותר.
  • לחברה צעירה (מעט לקוחות/רווחים) לא משתלם להשקיע בפיצר'ים עם ערך לא גבוה. פיצ'ר שיוסיף עוד 1% הכנסות – לא שווה יריקה. כשהחברה גדלה – פיצ'ר שיוסיף עוד 1% הכנסות יכול להיות שווה שנות עבודה רבות, ובצדק.
• מערכות תוכנה נוטות להסתבך ולהיות קשות יותר להרחבה ככל שהן גדלות / הזמן עובר. אם בשנה הראשונה של החברה פיצ'ר חדש צריך להשתלב עם 4 פיצ'רים קיימים, לאחר כמה שנים כל פיצ'ר חדש צריך להשתלב עם 20-30 או יותר פיצ'רים קיימים – ויש הרבה יותר עבודה כך שלא יפריעו / יסתרו זה את זה. כתבתי על כך בפוסטים: איך לנצח את הסיבוכיות? ו סיבוכיות: מקבלים את זה בחינם.
• ביצוע (Execution) – הופך לקשה יותר ככל שהארגון גדול יותר:
  • ארגון גדול הוא מורכב יותר, וכמות האנשים המעורבים בכל פיצ'ר היא גדולה יותר. נדרשים יותר תיאומים ותקשורת.
  • צמצום פוקוס / פיזור הפעילות: ארגונים גדולים נוטים לפזר את כוחם על יותר נושאים, ולרוב נגררים לפיזור-יתר, שלא היה בזמן שהיו קטנים. פיזור היתר גורם לפרויקטים להתמשך, לא לעמוד בלוחות הזמנים – ואז תחת לחץ של עמידה ביעדים => להסתיים בצורה רדודה יותר, מה שיוצר חוב טכני / תפעולי – שמאט עוד את המערכת.

בפוסט הזה אתמקד בבעיות הביצועים של ארגונים גְּדֵלִים: ארגונים גדולים, אם שרדו, כנראה הצליחו להתמודד (לפחות חלקית) עם בעיות הביצועים שלהם. ארגונים גְּדֵלִים, החווים זו בפעם הראשונה – יכולים להגיע "להיתקע", ואולי אף לא לצלוח יפה את הצמיחה.

צמצום פוקוס – איך זה קורה?

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

• גודל הארגון (למשל: מספר האנשים) – מספק תחושת יכולת. כל אותם דברים שאמרנו לעצמנו "אנחנו ארגון קטן, אין לנו זמן לעשות את זה" – עולים עכשיו על השולחן לדיון מחודש.
  • חלק מהדברים הללו, אולי אפילו חלק גדול מהם – עדיין לא נכון לעשות, אבל הכשל הלוגי הוא הצמדה של הדחייה לטיעון "אבל אנחנו רק 20 אנשים", וברגע שהפיתוח כולל כבר 50 אנשים – התנאים השתנו ויש לנהוג אוטומטית אחרת.
  • בכל זאת, אנחנו רוצים "לצ'פר" את האנשים הטובים שהביאו אותנו לכאן ולעזור לקדם דברים שהם מאמינים בהם. בכל זאת – הם צודקים: עכשיו יש לנו יותר אנשים.
  • "התמורה לא מצדיקה עדיין את ההשקעה" – הוא קישור לוגי נכון יותר, שיכול להיות תקף גם בחברה של 500 או 1000 עובדים.
• כשהארגון גדול, כבר אין קיום (כמעט) לפרשים בודדים. מעטים הם האנשים / המשימות שאדם יוכל לבצע אותן לבדו – מבלי להזדקק לעזרה, בניגוד לארגון קטן.
  • למשל:
    • איש ה Security לא יוכל לקדם דברים משמעותיים – בלי השקעה משמעותית של מפתחים.
    • איש ה Performance שבא לשפר את המערכת – לא יוכל להתקדם הרבה בלי השקעה משמעותית של מפתחים.
    • איש ה Training – לא יוכל לקדם תוכניות הדרכה בלי מעורבות / השקעה משמעותית של המפתחים הטובים שמבינים בעניין.
  • בכל שלושת הדוגמאות הבאנו לארגון "מומחה שיקדם נושא" – אבל שכחנו להעריך את ההשקעה הנוספת הנדרשת מהפיתוח בכדי לקדם ברצינות את האג'נדה. התוצאות הן לרוב:
    • פיזור הכוח על יותר חזיתות ממה שנכון לארגון.
    • אי קידום רציני של האג'נדות – מה שמבאס את מי שאמור להוביל אותן, ואת מי שקיווה מהן לשיפור ממשי. פגיעה במורל ואולי אף יותר: בהרגל החשוב לסיים את מה שהתחלנו => מקור לעוד התדרדרות ב Execution.
  • אותו מקרה בדיוק קורה גם ביוזמות שהן nice-to-have, למשל:
    • מעבר לטכנולוגיות / ספריות חדשות שנראות טובות יותר (אך הארגון יכול "לסחוב" בסדר עוד כמה שנים בלעדיהן) – הערכה ראשונית היא שמפתח ל x שבועות יבצע את המעבר – אך הוא "מפריע" לפיתוחים אחרים ואף דורש שיתוף פעולה שלא תוכנן.
    • השקעה בתשתית שהציקה לנו והגבילה אותנו, כך שלא תגביל בעתיד (אך מחיר ההשקעה הוא גבוה מדי לתמורה) – לאחר שמתחילים את ההשקעה לפעמים "תחושת החיוניות" של השינוי יורדת – אך לא מרגיש נכון / קשה להפסיק באמצע, וכך ממשיכים גם כאשר החשיבות נראית פחותה.
    • הקמת בלוג / ארגון כנסים / יוזמות חברתיות / וכו' – אנו נוטים להעריך בחסר את המחיר האמיתי של היוזמה בשעות מפתחים בפועל + קשה מאוד להפסיק אותן בפועל כדי לא לאכזב את האנשים הטובים שהתמסרו להן.
  • תופעות הלוואי העיקריות של "פרשים בודדים" שנדרשו לעזרה מכוח העבודה העיקרי הן:
    • התעכבות בפרויקטים – וגם בפרויקטים הקריטיים לארגון.
    • שחיקה של אנשים, בלי שהם יודעים לתאר הרבה פעמים מדוע: הם רוצים לעזור, היוזמות השונות נראות להן הגיוניות – אבל ה context switch, ואי קיום תחושת ההתקדמות שהם רגילים לה – שוחקים.
• ריבוי תהליכים שטרם הגיע זמנם – כולם יודעים שארגון לא יצליח לגדול בלי תהליכים ונהלים טובים הבנויים ל Scale, אבל לא פעם תהליכים שנדרשים לארגון של 2000 מושתתים על ארגון של 500 עובדים, ותהליכים המתאימים לארגון של 500 עובדים מושתתים על ארגון של 100 אנשים. משלמים היום על צרכים עתידיים – כמו משפחה ששוכרת דירה בת 6 חדרים כאשר הילד הראשון נולד…
  • דוגמאות נפוצות הן:
    • נהלים אחידים ונוקשים ברחבי הארגון, כאשר יחידה לא מסוגלת להתאים אותו לצרכיה – גם כאשר הדבר גורם לתקורה ניכרת.
    • תהליכים "למופת" – היכן שלא נדרש: "צריך כבל USB? הגש בקשה – קבל אישור של המנהל שלך ומנהל ה IT ואז תקבל ביום המחרת". כבל USB אנחנו לא צריכים הרבה, אבל תהליכי Design, קוד רביו, ושחרור לפרודקשיין גם הם יכולים להסתבך מתוך היגיון שעדיין לא מצדיק את עצמו.
• כל הדוגמאות הנ"ל גרומות לארגון להיות אטי, לדרוש יותר תקשורת / תשומת לב / פעלתנות – בכדי להשיג אותו הדבר.
• פיזור הכוח על מספר רב של חזיתות – נותן את אותותיו:
  • הפרויקטים מתארכים ולא מסתיימים בזמן
  • אנשים נשחקים יותר – כי הם צריכים לעשות יותר בכדי להשיג תוצאה דומה
  • העדיפות בפועל של הפרויקטים הקריטיים יורדות: המפתח המוביל בפרויקט החשוב ביותר בארגון עוזר קצת ליוזמה X, מעדכן את הסביבה שלו לתשתית החדשה, עונה על כמה סקרים, משתתף בקבוצת חשיבה וממלא אחר כמה נהלים חדשים. לכאורה כל אלו בעדיפות שנייה – אך בפועל כל הפעילויות הללו נעשות על חשבון הפרויקט הקריטי ביותר בחברה: כלומר הן הפכו לעדיפות העליונה.
• במקביל: ההנהלה בארגון גדול יותר מנותקת מהפרטים והשטח – ולא מבינה מה מתרחש. תוצאות שליליות אפשריות הן:
  • תחושה שאנשים פחות משקיעים – וצריך לדרבן אותם יותר. דרישה "לחזק כוחות – ולעמוד ביעדים" – לרוב תוביל לתוצאה צפויה, ולא רצויה: ירידה באיכות / בדיוק / ובסגירת הנושאים.
  • ההנהלה בעיקר רואה עמידה / אי-עמידה בלוחות הזמנים (מה שקל למדוד) ורואה פחות ופחות דיוק ואיכות (מה שקשה למדוד, במיוחד מגבוה).
  • התוצאה הטבעית היא ירידה באיכות במקומות הפחות נראית (חובות טכניים) => מה שגורם לאיטיות מצטברת ולמעגל העצמה של הבעיה.
    • הצוותים בשטח לא משקפים עד-הסוף את האיכות היורדת – אבל נאלצים לשלם את מחיריה בהתנהלות השוטפת – מה שפותח להם חזית נוספת לעבודה, ומפזר את הכוח של החברה על מרחב גדול אפילו יותר של פעילויות: התמודדות עם חובות טכניים שאינם על השולחן.
  • בארגון מפתחת שחיקה, תסכול, וציניות = מה שמדרדר עוד את היעילות של הארגון, ופוגע עוד ביכולת של ההנהלה להבין בדיוק מה קורה כאן…
• רוצים להוסיף עוד קצת שמן למדורה? שלחו את ראשי הצוותים שלכם להדרכה על "ניהול זמן". זה בטח עומד לפתור את הבעיה!
  • קביעת "שעות ללא פגישות" הן וריאציה מוצלחת מעט יותר – אך עדיין לא פוגעת בבעיה העיקרית: ריבוי החזיתות שיש להתמודד איתן.

האם באמת מדובר בבעיית פוקוס?

ביצועיות (Execution) מושפעת ממספר גורמים בארגון: מעורבות (Engagement), כישרון, אפשור (Empowerment) וכו'. פגיעה בכל אחד הנ"ל – יפגע ביכולת ה exection. אם הארגון היה בסדר בכל הדברים, והוא בתהליך גדילה – פיזור הפוקוס הוא המועמד הסביר ביותר לתאר רגרסיה ב Execution. בואו ננסה להציב עוד כמה מאפיינים של בעיית פיזור הפוקוס, בכדי לאשש שאכן בה מדובר:

• פרויקטים הולכים ומתארכים (הערכות הזמנים), בד בבד עם פרויקטים שפחות ופחות עומדים בזמנים. כאשר צוות נדרש להרבה חזיתות – אחוז הזמן שהוא משקיע בפרויקט העיקרי – הולך ופחות.
  • שערוך של שעות העבודה נטו על קוד / דזיין ביום – יכולות לעזור לזהות ירידה בפוקוס. קושי: יש להתחיל בשערוך כשהמצב עוד "טוב".
• יעדים לא מושגים, או שמתברר בדיעבד שלא הושגו: חשבנו ששיפרנו חוב טכני / חווית משתמש – אבל חודשים אח"כ מתברר שהתוצאה לא הושגה – ואולי יש לחזור ולהשקיע באזור.
  • כשאנחנו מפזרים את הפוקוס – אנחנו יכולים פחות להקפיד שאכן הדברים נסגרו. כשיש פרויקט אחד שהוא עיקר תשומת הלב שלנו – יותר קל וסביר שנסגור דברים "עד הסוף".
• מאבק עקוב מדם על משאבים (כלומר: אנשים) – הרבה צוותים שמרגישים שאין להם את כוח האדם שהם זקוקים לו בכדי להתקדם / להשיג את היעדים. ש"אם רק היינו מקבלים עוד 2 מפתחים – הכל היה מסתדר".
• עבודה קשה ו/או היכולת לסיים דברים היא המדד העיקרי להערכת עובדים, בפועל (ולא למשל: עבודה מצוינת וחכמה). זה אומר ש:
  • אנשים כנראה באמת עובדים קשה, וזה יכול להיות סימן שלא עובדים כ"כ יעיל.
  • המנהלים כבר לא מסוגלים להיות בפרטים, ולהבין את העבודה שנעשית – ונאלצים לבצע הערכת עובדים ע"פ "מי נשאר עד מאוחר בערב / מתלונן יותר על הקשיים".
• אי אפשר להשיג את אנשי המפתח (ראשי צוותים, Tech Leads, וכו') להתייחסות על נושאי-הליבה. היומן שלהם סגור 8:00 עד 8:00 וניתן להשיג אותם רק בטווח של כמה ימים ל"איזו חצי שעה".
  • חשוב שאנשי-מפתח יהיו זמינים לדברים החשובים ביותר. אם הם לא – הם ייגרמו לעיכובים מתגלגלים ובעייתיים מאוד – דווקא בפרויקטים הקריטיים.
• לא ברור בארגון מהם הפרויקטים החשובים ביותר. כל אחד חושב שהוא "הכי חשוב" או שמסכימים ש"כולם חשובים" => אף אחד לא מקבל באמת עדיפות => אין תעדוף אפקטיבי.
• צוותים מסוימים משלמים על חוב טכני משמעותי, ולא תמיד שנגרם בגללם. לא אמירות כלליות (שתמיד יהיו; כל פרויקט שרק נגמר "סוחב" חוב טכני כלשהו) – אלא בזבוז זמן ניכר, שקל למדוד ולהעריך.

סיפור לדוגמה הוא שיטת ה prioritization של חברת פנדורה – שהתפרסמה כמודל לחיקוי. השיטה מציגה מנגנון תעדוף ע"פ תקציב (budget). כל stakeholder / איש-מוצר מקבל "תקציב" (נניח $100) של פיתוח – אותו הוא יכול להקצות ל"פיתוחים" לפי ראות עיניו. לכאורה זה מאוד הוגן, נוח, ומסיר חיכוכים – כל אחד מצביע לפי הבנתו, בלי צורך להתווכח בדרך לקונצנזוס. מצד שני: אין מנגנון שווידא ש stakeholders מושכים לאותו הכיוון, לאותה האסטרטגיה. לכאורה יש אפשור שבשתיקה למשוך לכמה כיוונים שונים, בו זמנית, בפיזור מאמץ "by design". יותר גרוע: כל stakeholder לעצמו עלול "לפזר סיכונים" ולהשקיע בכמה יוזמות – כדי שלפחות יזמה אחת "שלו!" – תצליח. המנגנון בעצם מאפשר להשקיע בעשרות יוזמות במקביל, בלי תיאום, ועם סיכוי הולך וקטן להשיג ערך משמעותי. פנדורה כבר בדעיכה, ולא נחשבת דוגמה ללמוד ממנה. אין לי ידיעה אם זה מה שהוביל לנפילתה – אבל זו בהחלט נראית לי דרך מעולה לאבד פוקוס!

מה אפשר לעשות?

"טוב. אולי יש לנו בעיית פוקוס. אז בואו נתפקס יותר טוב, לא?"

זה נשמע קל, אבל זה לא – במיוחד שהארגון גדל:

• כדי להתמקד ב 10 יוזמות, הארגון דחה כבר 40 יוזמות אחרות. קשה להפנים שלא התמקדנו מספיק, במיוחד כאשר:
  • הארגון הצליח וגדל – "והגיע הזמן קצת 'לשחרר' ולעשות יותר דברים".
  • מצטרפים לארגון עוד ועוד אנשי-מפתח שמעלים נקודות נבונות – היכן לארגון יש חוסרים, ו"חשוב" להשקיע ועכשיו. בשביל זה גייסנו אותם – לא?

המפתח לפוקוס בארגון גָּדֵל הוא:

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

המלצה היא לתת למשימות הארגוניות החשובות שם גדול כמו "Wildly Important Goals" (בקיצור: WIG). שם גדול שלא ניתן להתעלם ממנו. הארגון צריך להתמקד בכמה משימות סופר-חשובות שכאלו בצורה עמוקה. השם גם יגרום לביקורת פנימית – אם המשימה אינה באמת חשובה ומשמעותית עד כדי-כך.

כ WIG, יש לבחור את המשימות שמוכנים ללכת בהם "עד הסוף" מבחינת משאבים והשקעה, מתוך אמונה שכל יום שמושקע בהן – ייתן תמורה משמעותית לחברה.

אמורים להיות מעט מאוד WIG – בהם אנחנו מתמקדים. (תזכורת למתודולוגית ה OKR, בה יש לקבוע 3-5 יעדים של החברה – ולא יותר. חברות המתחילות לנהל רשימות ארוכות של יעדים, נחשבות כחוטאות למתודולוגיה). מכאן:

• האם ל WIG יש את כל המשאבים (האנשים) כדי לעבוד ביעילות מרבית? אם לא – שקלו לצמצם / לדחות יעדים אחרים, בכדי לאפשר לו להתקדם מהר יותר. אנחנו רוצים לשים על כל WIG כמה שיותר משאבים, כל עוד זה יעיל – ולהתקדם בו כמה שיותר מהר.
• אם יעדים מתעכבים – אל תקבלו את המציאות הזו! אל תלחיצו אנשים לעבוד שעות נוספות! העדיפו:
  • לצמצם את ה scope של היעד – כך שתשיגו את היעד המעודכן – מוקדם/מהר יותר.
  • לצמצם יעדים אחרים – אם ניתן להציב עליו עוד כוח עבודה.
    • פחות יעדים = דבר טוב. פחות תלויות והפרעות הדדיות (שלא תמיד אנו מודעים להן).
  • לפצל את היעד לשני יעדים: שלב א' משמעותי, ואז שלב ב' משמעותי.
    • בלי קשר לעמידה ביעדים: אם ניתן לעשות זאת – עשו זאת בהקדם. כל "loop" שסגרתם מוקדם יותר ייתן לכם פידבק עד כמה הוא באמת מצליח / משמעותי – ואתם רוצים ללמוד את הדברים האלו, בעיקר ב WIGs – כמה שיותר מוקדם!
    • כלל מומלץ הוא "כלל 90 היום" – לא יהיה WIG ארגוני שזמן העבודה שלו יותר משלושה חודשים. אם יש – פצלו אותו / הפחיתו scope. לא ניתן לתוצאות קריטיות לחברה להתעכב ולא נסכים שזמן גדול מדי אנו לא יודעים אם ההשפעה שצפויה מהן הושגה.
• הרשו לעצמכם, ביתר קלות, לסרב ליוזמות של אנשים חרוצים, טובים, ואהובים. אנחנו רוצים לתגמל, לחבר (to engage), ולהוקיר את דעתם של האנשים שעובדים למען הארגון – אך חשוב להבהיר שקידום יוזמות "nice-to-have" ברמה הארגונית – היא לא דרך לעשות זאת. הרבה חזיתות יכולות להיפתח בכדי לרצות אנשים טובים. האנשים טובים – אך הנזק אותו הנזק.
• הערה: אנשים שעובדים על יעד משמעותי וברור, שהם מבינים שהוא כזה – יהיו לרוב יותר פרודוקטיביים ומחויבים מאנשים שביקשו מהם "להשקיע מאמץ" – ולעבוד שעות נוספות / קשה יותר.

איזו גישה מרגישה יותר נכונה?

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

מצד שני, גישת ה Parallelize אומרת שנשיג את היעדים שלנו מאוחר יותר. וכנ"ל לגבי למידה מכל יעד – יגיע מאוחר יותר. אם מרגיש שגישת ה Parallelize היא ניהול סיכונים נבון יותר ("לא לשים את כל הביצים בסל אחד"), דווקא כאשר מדובר ב WIGs – גישת ה Maximize Focus היא מסוכנת פחות: אם יש WIG שלא עובד – נגלה את זה מוקדם יותר, וזה יותר חשוב: ללמוד ולהתכוונן מחדש – איך בדרך אחרת, להשיג את היעד הכל-כך חשוב הזה.

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

עבדתי פעם בארגון שהתכונן לצמיחה גדולה, והקים 10 צוותים של 2-3 עובדים כל אחד. כמה מהם – עבדו ללא ראש צוות (שעדיין לא גויס). החשיבה הייתה "איך בונים את הארגון בחשיבה לטווח ארוך", אך קיבלנו הרבה צוותים בלי "כוח-אש משמעותי", הרבה ראשי צוותים חדשים בו זמנית, ומכיוון שכל צוות עצמאי – הכנסנו לעבודה הרבה משימות בחשיבות משנית. נראה שהיה טוב בהרבה להקים 5 צוותים משמעותיים – ולגזור מהם בהדרגה צוותים נוספים: למשל, ברגע שהחלטנו שהגיע הזמן לצוות נוסף – להקדים אותו כבר עם 5-6 אנשים (מתוך צוותים קיימים). זה מורכב יותר מבחינת קשר המנהל-עובד, אך זה הרבה יותר בריא לארגון ככלל.

עוד נקודות:

• ליצור תרבות של דיון מתמיד ב WIGs שלנו: האם הם נכונים? מספיק משמעותיים? אנחנו משקיעים בהם את כל מה שאפשר?
  • תרבות כזו מייצרים ע"י דוגמה אישית של מנהלים, וע"פ פרגון אמיתי למי שיוצר דיון איכותי בנושא (חשוב לבדוק, גם אם מסקנת הדיון היא: "בעצם הכל בסדר").
• מה עושים עם פרויקטים שאינם WIG? איך לא נפגע המורל של מי שלא עובד על WIG – אך עובד על דברים חשובים אחרים? נסו להפוך כל מאמץ ל WIG, או לפחות ל WIG-like: צמצום ה scope להכרחי ביותר הניתן ופוקוס להצלחה. למשל: אם יש בעיה מסוימת – אל תקימו יוזמה לפתור אותה לגמרי: הקימו יוזמה להביא את המצב ל "good enough" – ואז להמשיך ליוזמה הבאה. יהיה קל יותר לחבר את האנשים על היוזמה שהם עושים משהו משמעותי, ולא מבזבזים רגע מיותר. כמו ב WIG.
• יוזמה שראיתי פעם הייתה לצבוע פרויקטים בצבעים:
  • כחול = WIG. "חשוב בטירוף!". לשם הולך כוח האש העיקרי. כמטאפורה: "כיבוש האי XYZ".
  • צהוב = Sustainability – "תיקון דליפה בספינה" כדי שנוכל להגיע ליעד ("האי XYZ"). אפילו אם זה לא הפרויקט העיקרי – מובן שזה חשוב ונדרש בכדי להצליח ב WIG.
  • לבן = למידה / POC – פרויקטי גישוש שנחיצות כל אחד מהם אכן בספק – אך מהם יצמח ה WIG הבא "איסוף מודיעין" או "מחקר מדעי לקראת הדור הבא", לצורך העניין.
  • הצבעים עוזרים להעביר את המקום האסטרטגי של כל פרויקט בבהירות – ולעזור לארגון לכוונן את עצמו נכון יותר לכל פרויקט. למשל: מובן יותר לנסות להימנע שאיש בפרויקט כחול ישקיע זמן בעזרה לפרויקט צהוב – מבלי שזה ייחשב חוסר-קולגיאליות. פרויקט לבן יכול להימנע / לדלג על נהלים – וכך להיות יעיל יותר.
• celebrate scope reduction – כפי שמחיקת קוד הוא דבר שחוגגים (למרות שמישהו השקיע וכתב את הקוד הזה באהבה, פעם) – גם צמצום של Scope הוא דבר לחגוג ולשמוח איתו.
• אחריות ברורה בהחלט – לכל WIG חשוב שיהיה Owner ברור. קפטן שחייב לספק את המשימה. ניסיון (לפזר אחריות) – לרוב נגמר באסון.
  • חשוב שיהיה גם Executive Owner מחויב, בעל יכולת לקבל החלטות משמעותיות. Executive Attention הוא משאב חשוב – שגם אותו צריך לספק ל WIG.
• אם צוות משקיע ביותר מ 2 WIGs בו-זמנית, כנראה משהו לא בסדר. Context Switch הוא "מס" לא רק על תהליכים במערכות הפעלה.

סיכום

הפעלת ארגון תוכנה – הוא דבר מורכב: יש הרבה נושאים והיבטים לטפל בהם.

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

• כל כמה זמן, אנחנו מצליחים להסיר scope מיעדים / פרויקטים ו/או מחליטים לסגור יעדים כי אנחנו מבינים שהם לא חשובים מספיק.
  • לכאורה עדיף לא להתרחב ל scope לא-נחוץ מלכתחילה – אך לא פחות (ואולי יותר) חשוב לדאוג לכך שיהיה תהליך תיקון חי ובועט בארגון.
• ה engagement של המפתחים לפרויקטים הוא גבוה: לכולם ברור מה הם עושים ולמה, ושזה באמת דבר משמעותי לחברה. נדיר למצוא "כיסים של חוסר-משמעות".
• כאשר פרויקט חשוב זקוק לאיש מפתח – הוא זמין, ובזמן קצר. לא קורה כמעט שדיון / החלטה מחכה לזמינות של אנשי-מפתח. הלו"ז שלהם בנוי לטיפול בבלת"מים חשובים, ולא בעומס של נושאים משניים.

שיהיה בהצלחה!

---

קישורים רלוונטיים:

• How (and Why) to Stop Multitasking