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

 

מיתוס מספר 1: כל פרויקטי התוכנה נכשלים
לא כל הפרויקטים נכשלים. אבל הנתונים של של Leading Answers שמוצגים למטה ומתבססים על נתוני Standish Group (*) מצביעים ש - 95% מהפרויקטים שנמשכים מעל שנתיים נכשלים! אלו כמובן החדשות הרעות. החדשות הטובות הן שאם נבין למה יש 5% שמצליחים, נוכל לבצע את הדברים הנכונים גם אצלנו. לשם כך נצטרך לשבור כמה מיתוסים.

 

(*) Standish Group היא חברת ייעוץ מובילה בתחום ניהול הפרויקטים הממוקמת בבוסטון. החברה אוספת נתונים על פרויקטי תוכנה מאז שנת 1994, ומפרסמת אחת לשנה סטטיסטיקות עדכניות. נתוני 2011 פורסמו בגיליון PM Network August 2011 של אגודת ה - PMI. הנתונים בגרף למטה הם משנת 2005 (לא כל כך ישן למאמר אקדמי), אבל הם בהחלט תקפים כפי שתוכלו ללמוד מהמאמר ב - PM Network וההשוואה של הנתונים הכוללים לשנים הקודמות (37% מהפרויקטים עומדים בזמן ובתקציב, 42% "מאותגרים הצלחתית" ואילו ב - 21% מהמקרים הכירו בכישלון המוחלט של הפרויקט).

 

 

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

 

מיתוס מספר 3: יש רק שיטת ניהול פרויקטים אחת והיא עובדת לכל פרויקטי התוכנה
בקורסי ניהול פרויקטים מתרכזים בעיקר בשימוש בגאנט וניהול פרויקטים בשיטה הקלאסית Waterfall. בשנים האחרונות החלו להופיע מספר שיטות חדשות שמביאות מענה לצרכים עסקיים שונים של חברות. הראשונה בהן היא מתודולוגיית ה - Agile המתמקדת בעבודה עסקית בסבבים קצרים יותר, תוך שימוש בהיזון חוזר מהסביבה (אנחנו נעסוק בה בפוסטים הבאים, אבל בינתיים מומלץ שתעיפו מבט בבלוג המצויין של אלעד סופר שעורך גם את מפגשי ה - Agile practitioners IL). מתוך מתודולוגיה זו צמחה שיטת ה - SCRUM שדוגלת בשחרור גרסאות עובדות מדי 2-5 שבועות. שיטה חדשה עוד יותר שהופיעה רק בשנתיים האחרונות היא ה - Continuous Deployment. שיטה זו מוטמעת כבר במספר חברות בישראל ודוגלת בשחרור גרסאות לייצור מסביב לשעון (או בעברית פשוטה יותר עשרות גרסאות חדשות בייצור מדי יום). השיטה הזאת מתאימה בעיקר לגופי תוכנה שמספקים שירות ללקוחות פנימיים או חיצוניים וגם בה נדון בשבועות הקרובים.

 

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

 

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

 

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

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

 

 

 

ממשיכים לפתח
משה קפלן

 

 

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

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

 

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

 

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

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