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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מי יודע, אולי יום אחד כל הארגון יעבוד באופן דומה.

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

סוף מעשה במחשבה תחילה

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

מה יש לנו לתכנן?

א.     תיקוני תקלות –

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

ב.     שלבי עליה לאוויר –

יש לתכנן את השלבים ולגזור את לוחות הזמנים מתוך תאריך היעד. שלבי העליה לאוויר כוללים:

1. פעילויות מקדימות לתאריך היעד – ביצוע הסבות נתונים, ביצוע הדרכות, בדיקות משתמשים (כוללות או מדגמיות), ביצוע סימולציות פעולה במערכות ארגוניות ועוד…
2. הקפאת תצורה – קביעת תאריך להקפאת תצורת המערכת. מתאריך זה ועד לעליה לאוויר תבוצענה רק פעולות תיקון קריטיות.
3. תכנון חלון הזמן לביצוע – מתי תבוצע ההתקנה, כמה זמן יש לביצוע, כמה זמן יש לחזרה אחורה במקרה של כשלון. תכנון זה הוא קריטי מכיוון שחלון הזמן העומד להתקנה, בעיקר במקרים של שדרוגים, הינו קצר.
4. יום העליה לאוויר – ביצוע גיבויי מערכת (מערכות ונתונים), הפסקת פעילות ארגונית, ביצוע הסבות נתונים, ביצוע התקנות תשתיתיות נדרשות, ביצוע התקנות המערכת, בדיקות מדגמיות למערכת ושחרור המערכת לארגון.

ג.      תכנון נקודות בקרה ומיזעור סיכונים –

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

ד.      תכנון כח אדם ותחומי אחריות –

מיהם האנשים הנדרשים לביצוע התהליך – אנשי פיתוח, אנשי בדיקות, אנשי תשתיות, מנהלי מוצר, לקוחות וכו', מהם תחומי האחריות של כל אחת מהקבוצות המעורבות ומהו נוהל הדיווח על הצלחות וכשלונות.

ה.     תכנון היום שאחרי –

הקצאת משאבים למעקב, בקרה ותיקונים הנובעים מהעליה לאוויר.

ו.       ביצוע סימולצית התקנה –

בתהליך זה נעלה על נקודות שלא עלו בתהליך התכנון.

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

יום העליה לאוויר

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

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

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

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

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

סיום העלייה לאוויר

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

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

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

כבר אמרו בעבר שהדבר הבטוח ביותר בחיינו כגופי פיתוח הוא השינוי.

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

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

למה הכוונה ?

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

וכמובן שיש עוד נקודות של שינוי הנחות יסוד בחברות שונות .

אז מה אנחנו עושים עם זה?

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

עכשיו כשאנחנו מודעים לכך, אנו צריכים לדעת להתכונן.

ההכנה מורכבת מכמה רבדים.

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

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

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

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

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

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

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

כמנהלים, אנו תמיד נדרשים למחשבה – מה אנחנו מנהלים?

האם אנחנו מנהלים תכניות עבודה? לא ולא. תכנית עבודה אנחנו בונים, מתקשרים, מבקרים. תכנית העבודה היא כלי שעוזר לנו לעמוד בהתחייבויות שלקחנו על עצמנו.

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

המשאב האמיתי שאנחנו באמת מנהלים – הוא האנשים שלנו. העובדים, ראשי הצוותים, מנהלי הקבוצות.

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

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

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

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

איך גורמים להם לשתף אותנו כמנהלים בהתלבטויות המקצועיות שלהם.

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

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

טוב, אז בלי הקדמות מיותרות.

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

תכנית העבודה עצמה נשענת על שלושה מרכיבים בסיסיים:

1. תכולת עבודה
2. זמן
3. משאבים וכח אדם

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

מהיכן מתחילים?

כל תהליך של בניית תכנית עבודה מתחיל מנקודה שונה.

לעיתים הזמנים קשיחים.

לעיתים התכולה קשיחה.

לעיתים המשאבים קשיחים.

לעיתים שניים מהמרכיבים קשיחים.

לעיתים כל שלושת המרכיבים קשיחים.

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

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

נתחיל ממקרה ראשון:

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

במקרה זה – התכולה קשיחה (אם כי הדרך ליישם אותה הינה גמישה ונותנת אפשרות למגוון תכניות עבודה).

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

נקודות עיקריות בתהליך:

1. ניתוח דרישות תכולה.
2. בניית ארכיטקטורה מתאימה למענה על הדרישות
3. בניית אפיון ותיכון טכני, הנותן מענה לארכיטקטורה המוצעת.
4. בנייה וקידוד תשתיות מתאימות
5. בנייה וקידוד אפליקציה
6. בדיקות יחידה.
7. אינטגרציה
8. בדיקות ובקרת איכות.
9. סבבי תיקוני תקלות.
10. אריזה

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

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

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

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

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

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

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

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

מחזור הפיתוח מתחלק לשלוש תקופות עיקריות.

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

תקופה ראשונה – הקמה.

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

התקופה השניה – תיקונים והשלמות.

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

התקופה השלישית – העליה לאוויר

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

כיצד ננהל את הזמן לאורך שלוש תקופות אלו?

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

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

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

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

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

"תגיד, סיימתם עם המשימה הזו ?"

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

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

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

מקורות הרעש הלבן

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

השפעות הרעש הלבן

הרעש הלבן משפיע לרעה על היכולת שלנו לעמוד בהתחייבויות שלנו.

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

התמודדות עם הרעש הלבן

ישנם שלושה אלמנטים מרכזיים העוזרים לנו ביכולת ההתמודדות עם הרעש הלבן.

• סינון
• הפחתה
• מיקוד 

סינון

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

הפחתה

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

מיקוד

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

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

בקרה

הבקרה שאנו נדרשים לעשות היא רב מימדית.

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

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

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

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

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

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

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

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

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

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