הפחתת מורכבות וסיכונים

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

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

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

תקורות ניהוליות מינימליות

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

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

איכות ניהולית – ניהול ידע ושליטה בפרטים

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

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

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