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