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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סינון

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

הפחתה

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

מיקוד

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

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

בקרה

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

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

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

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

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

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

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

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

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

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

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

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

הכלי הראשוני והחשוב ביותר הוא הכלי המהווה את סביבת העבודה של המפתחים. סביבת עבודה זו יכולה להיות מבוססת מיקרוסופט, ואז הכלי העיקרי שיהיה בשימוש הוא ה Visual Studio . אם הסביבה והמערכת מבוססות java , אזי יהיו כלים כמו Eclipse , IntelliJ Idea , סביבת העבודה של Sun ועוד… ההבדל העיקרי בין הסביבות הינו שיטת העבודה וממשק המשתמש.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The site is basically in hebrew. Some of the content will be published in both hebrew and english.

The main issues that will be covered here are people management, technology management, work plan management and management methodologies