מפגש קבוצת המשתמים של Project עם יצחק בן לוי על ההיבט האנושי
יצחק בן לוי הוא שועל פרויקטים ותיק. הוא גם מומחה ב Lean, שזה, אם אתם לא יודעים, הלהיט התורן בניהול פרויקטי תכנה. אבל יצחק לא בא מתחום פרויקטי התכנה, הוא בא מתחום הפרויקטים של מערכות שכוללות מרכיבים רבים, כמו מיכל דלק של מטוס או פריסה לוגיסטית של מערכת נשק. נקודה זו, שלא באשמתו, היתה בעכוריו. כי לא כל המשתתפים היו מסוגלים לראות, את הקשר הישיר בין מה שהוא דיבר לבין ניהול פרויקטי תכנה, וחבל.
יצחק הציג את המתודה שלו עם הרבה סיפורים מהשטח. מנהלי הפרויקטים הותיקים בקהל הצליחו להתחבר יפה אל השיטה ואל הדוגמאות. למנהלי הפרויקטים הצעירים בקהל, היה הרבה יותר קשה לעשות את זה, וחלק מהם פשוט פיספסו את התובנות, בגלל חוסר נסיון מספיק בפרויקטים שנכשלו.
אני ישבתי בסוף והיה לי קשה שלא לצחוק ו/או לבכות, כי כל משפט שני של יצחק, הזכיר לי דוגמא מעשית, מאחד הפרויקטים שנקראתי לטפל בהם. אני מזכיר למי שלא יודע, שכאשר קוראים לי לפרויקט, זה בדרך כלל פרויקט תכנה שמתעופף, מסיבה זו או אחרת, אצל הלקוח או ברצפת הייצור. מי שקורא לי, לא עושה את זה רק כדי שאפתור את הבעיה הנקודתית, אלא גם כדי שאאתר את ה Root Cause of Failour, שזה משהו הרבה יותר עמוק מאשר ה Bug הספציפי והנקודתי שהעיף את המערכת. וכאשר אתה מחפש את ה Root Cause of failour, אתה כמעט תמיד מגיע לשלב ה Design של הפרויקט, ולכל ה Process שלו. ומכאן ההזדהות העמוקה שלי, עם המון מהתובנות שהציג יצחק.
אני לא הולך לשחזר כאן את ההרצאה, אני מניח שפנינה תעשה את זה בבלוג שלה (קדימה פנינה), אני רק אעלה כאן כמה נקודות ותובנות, שקפצו לי לראש בזמן ההרצאה. מדהים דרך אגב, כמה הדברים שהעלה יצחק, מתקשרים בצורה ישירה, לעקרונות ה MSF. אותו MSF, שפעם היה מתודה שלמה, שנלמדה בקורסים וסדנאות, והיום התנוון לכדי שבלונה ב TFS, שמעטים מאלה שמשתמשים בה, מודעים לרקע התיאורטי הנרחב שעומד מאחוריה.
השקף הזה מייצג בצורה די ברורה, למה חלק מהצעירים בקהל איבדו את יצחק, ברגע שהוא הציג אותו. עם יד על הלב, כמה מכם היו מעורבים בפרויקט, שכלל כל כך הרבה גופים מעורבים ? תתפלאו לשמוע, אבל אני טוען, שכל מי שהיה מעורב בפרויקט תכנה, שהיו בו יותר מעשרה מפתחים, או בפרויקט שהתבסס על שילוב של קוד מכמה מקורות שונים, היה כבר בפרויקט כזה. רק תחליפו כל מחלקה ב Feature Team, או ב Out Sourcer, ותקבלו את אותו דבר.
הבעיה שהוצגה היא שמאחר וכל אחד נמצא בפינה שלו, ורואה רק את קצה האף שלו, תקלות באינטגרציה מתגלות (אם בכלל) בשלב מאוחר מדי בפרויקט, עם נזקים משמעותיים. השיטה שהוצגה, היא להביא את כולם למקום אחד. לדחוף להם בכוח את התמונה הכללית, ולסחוט תוך שימוש בלחץ פיזי מתון, מכל אחד מהמשתתפים, את המחויבות שלו, לפינה הקטנה שלו בפרויקט, מתוך ראיה כוללת של ההשתלבות, של החלק שלו בכלל המערכת.
הקטע הבא, נועד לשבור את כל משוגעי הטכנולוגיה, שבטוחים שתכנת Project היא הפתרון האולטימטיבי, לקבלת התמונה הכללית של התהליכים והמשימות בפרויקט. היא לא. בשלב הארגון הראשוני (וגם בהמשך) אין משהו שנותן מיפוי טוב יותר של המצב בשטח מאשר פתקים שמודבקים על הקיר. כן, כן, אני לא צוחק, Wall Design שם בכיס הקטן, כל נסיון לעשות את זה, כאשר משתתף אחד בלבד מחזיק את ה Keyboard, ומציג את הכל, על מסך. זה פשוט לא אותו דבר. אין דבר שמשתווה לעבודה הקבוצתית, שבה כל אחד מזיז את הפתק שלו לנקודה הנכונה בתהליך, כתוצאה מאילוץ או מגבלה, שנתגלתה תוך כדי הדיון המשותף.
השימוש בקיר מוביל לכמה תובנות מענינות (ומשעשעות) על מגבלות התהליך. כמו למשל שגובה הקיר קובע את מספר המחלקות/יחידות שיכולות להשתתף בפגישה (22 ערוצים אם זה כל כך חשוב לכם). רוחב הקיר קובע את ציר הזמן (צריך מסדרון ארוך או חדר ישיבות גדול). פרויקטים שיש להם תאריך יעד קשיח מסתימים בפינה (כי שם נגמר הקיר) בעוד שפרויקטים שציר הזמן שלהם גמיש, מסתימים באיזה שהוא מקום באמצע הקיר. לא יאומן כמה הויזואליזציה, של ההתקרבות לסוף הקיר, מדגישה את אילוצי הזמן של הפרויקט לכל המעורבים.
הנכון הוא להשאיר את הכל על הקיר במסדרון ולהיפגש שם כל כמה זמן (יום, יומיים, שבוע, תלוי בפרויקט) ולקיים ישיבת סינכרון בעמידה, אל מול נקודת הזמן שבה נמצא הפרויקט בפועל, כאשר מעדנים את התכנון לטווח הקצר בהתאם לאילוצים. ומזיזים את הפעילויות (פתקים) מנקודה לנקודה, בהתאם למה שקורה בשטח.
שימו לב לציר הזמן בצילום הזה. הציר הוא לוגריתמי. יש לך "אופק תכנון" שבו אתה יכול להגיע לרזולוציה גבוהה. חודש, חודשיים, אולי שלושה. מעבר לזה אין טעם לתכנן ברזולוציה גבוהה, כי ממילא הרבה דברים ישתנו עד שתגיע לאותה נקודת זמן. רבעונים כבר מתכננים ברזולוציה בינונית ואת הטווח הרחוק עושים ברזולוציה גסה. כל מנהל פרויקט יודע את זה, אבל אני עדיין מוצא תכנונים ב Project, שטוענים שהם יודעים, מה יקרה בעוד שנתיים, ברזולוציה של חצי שעה. שימו לב לדמיון הרב של כל זה עם Agile ו XP.
הנקודה הבאה שרציתי להתיחס אליה היא מה שנקרא Unknown – Unknown. הנושא שצריך להדיר שינה מעיניו של מנהל פרויקט טוב, הוא השאלה" מה אני לא יודע שאני לא יודע". זה נשמע משחק מילים, אבל זה אולי הגורם הכי קריטי למניעת הפתעות יקרות בפרויקט. את מה שאתה יודע שאתה לא יודע, אתה יכול לרשום ברשימת ה Todo של הפרויקט, לבצע עליו ניתוח, ולהפוך אותו ל Action Items ו/או ל Risk Statements עם Mitigation ועם Contingency מוכנים. אבל מה שאתה לא יודע שאתה לא יודע, ממתין באפלה, לרגע הכי לא מתאים, ואז מכניס לך את זה בסיבוב. הטכניקה שהציג יצחק, מציפה למעלה המון Unknown – Unknown, והיא גם מאפשרת לקיים דיון מעשי, על תהליכים של קיצור לוחות זמנים ודרכים אחרות לחסכון כספי בפרויקט.
הנקודה האחרונה שרציתי להתיחס אליה, היא התיחסות ריאלית לדרישות של הלקוח. לא תמיד הלקוח מודע למשמעויות של כל דרישה. לפעמים לדרישה שנראית פשוטה ללקוח, יש תג מחיר גבוה. לפעמים דרישה עם עלות גבוהה, אינה באמת חשובה ללקוח. היו לי המון פרוקטים שנתקעו, בכלל דרישות לא הגיוניות של הלקוח, שבסופו של דבר הסתבר שהלקוח בכלל לא היה צריך אותם ו/או שהוא בכלל התכוון למשהו אחר, או שיש לו דרישה תחליפית, שטובה לו באותה מידה, רק שהעלות שלה משמעותית קטנה יותר.
יש לי עוד הרבה תובנות מהמפגש הזה, אבל גם ככה זה יצא ארוך מדי. אז אני אמשיך בהזדמנות אחרת איל"ז.