שיטת ניהול פרוייקט תוכנה: 6 מיתוסים לניפוץ
על תרבות ארגונית, צרכים עסקיים ואיך זה מתחבר לקוד שאנחנו כותבים? שישה מיתוסים שצריך לשבור לפני שבוחרים את שיטת ניהול פרויקט התוכנה הנכונה עבורך
צילום: flickr, cc-by, markhillary
אחרי שדיברנו על כיצד לעשות ארכיטקטורת תוכנה בצורה טובה יותר, הגיע הזמן לפתוח את הקלפים ולראות איך אנחנו מביאים תוצר עובד שמתאים לארגון שאנחנו עובדים בו.
מיתוס מספר 1: כל פרויקטי התוכנה נכשלים
לא כל הפרויקטים נכשלים. אבל הנתונים של של Leading Answers שמוצגים למטה ומתבססים על נתוני Standish Group (*) מצביעים ש – 95% מהפרויקטים שנמשכים מעל שנתיים נכשלים! אלו כמובן החדשות הרעות. החדשות הטובות הן שאם נבין למה יש 5% שמצליחים, נוכל לבצע את הדברים הנכונים גם אצלנו. לשם כך נצטרך לשבור כמה מיתוסים.
.
מיתוס מספר 2: פרויקטים נכשלים כי אין להם מספיק משאבים
הוספת שולי בטחון לפרויקט והגדלת רמות הניהול (שמתרגמות בסופו של דבר לדיוני סטטוס בני שעתיים שבהם חצי מהאנשים המשתתפים לא רלוונטיים), תגרומנה באופן פרדוקסאלי להגדלת הפרויקט ולפי הגרף לעלייה בסיכוי לכשלון. אם נעיף מבט נוסף בגרף נראה שפרויקטים קצרים מגיעים ל – 60% הצלחה, ולכן הפתרון לעיתים יהיה להקטין את הפרויקט: הקטנת תכולה, הקטנת זמנים, פישוט ארכיטקטורת התוכנה וקיצור יעדים.
מיתוס מספר 3: יש רק שיטת ניהול פרויקטים אחת והיא עובדת לכל פרויקטי התוכנה
בקורסי ניהול פרויקטים מתרכזים בעיקר בשימוש בגאנט וניהול פרויקטים בשיטה הקלאסית Waterfall. בשנים האחרונות החלו להופיע מספר שיטות חדשות שמביאות מענה לצרכים עסקיים שונים של חברות. הראשונה בהן היא מתודולוגיית ה – Agile המתמקדת בעבודה עסקית בסבבים קצרים יותר, תוך שימוש בהיזון חוזר מהסביבה (אנחנו נעסוק בה בפוסטים הבאים, אבל בינתיים מומלץ שתעיפו מבט בבלוג המצויין של אלעד סופר שעורך גם את מפגשי ה – Agile practitioners IL). מתוך מתודולוגיה זו צמחה שיטת ה – SCRUM שדוגלת בשחרור גרסאות עובדות מדי 2-5 שבועות. שיטה חדשה עוד יותר שהופיעה רק בשנתיים האחרונות היא ה – Continuous Deployment. שיטה זו מוטמעת כבר במספר חברות בישראל ודוגלת בשחרור גרסאות לייצור מסביב לשעון (או בעברית פשוטה יותר עשרות גרסאות חדשות בייצור מדי יום). השיטה הזאת מתאימה בעיקר לגופי תוכנה שמספקים שירות ללקוחות פנימיים או חיצוניים וגם בה נדון בשבועות הקרובים.
מיתוס מספר 4: אני מנהל פיתוח בסטארט אפ, השיטה הזאת לא מתאימה לי, היא מתאימה רק לחברות גדולות!
.
אז זהו, שלא כל החברות זהות, גם אם מספר העובדים בהן דומה ואפילו אם הן עוסקות באותו ענף. ההחלטה על שיטת ניהול פרויקטי התוכנה צריכה להלקח על בסיס מאפייני הארגון, צוואר הבקבוק הארגוני שלו והתרבות הארגונית. אם הכוונה שלך במילה סטארט אפ היא "חברה ללא הררכיה מסודרת עם רמת הגדרת מוצר נמוכה, חוסר ודאות לצרכי המשתמשים ותרבות ארגונית שמבוססת על ניצול הזדמנויות" אז ככל הנראה החסם שלכם בארגון הוא השוק וההיזון החוזר ממנו. אמנם תיאור זה מאפיין ארגונים של 3 אנשים שייסדו את החברה לפני חודש עם מושג מועט לגבי השוק, אבל הוא גם מאפיין חברות גדולות בהרבה (דוגמה טובה לכך תמצאו בפוסט על השלבים הראשונים בפיתוח מוצר ב – Google).
סגמנט נוסף של חברות הוא סגמנט חברות שיודעות מה השוק רוצה והן רוצות לזעזע אותו. במקרים כאלו המשימה המרכזית תהיה בניית תוכנית מסודרת שתתמקד ביצירת אפקט מקסימלי בזמן מינימאלי בעת ההשקה.
מיתוס מספר 5: שיטת ניהול פרויקטי התוכנה הנכונה ביותר היא זאת שכולם מדברים עליה בערב יום שישי
.
קודם כל אם אתם מדברים על זה בערב יום שישי, אז הגיע הזמן שתגוונו את החברים שלכם. מיד לאחר מכן, כדאי שתבינו מה החסם העסקי של החברה שלכם, וכיצד גוף פיתוח התוכנה שלכם יכול לשרת טוב יותר את החסם הזה. לעיתים תדרשו להבין האם הארגון במשבר וכיצד אתם צריכים להתאים את עצמכם לכך.
לדוגמה, חברה שתלויה בגחמות של לקוח יחיד: במצב זה מתן מענה מיידי בתוך חלון זמנים קצר לצרכי הלקוח משמעותו זכייה בחוזה משמעותי נוסף, לשם כך תדרשו להתאים את שיטת ניהול הפרויקטים לדרישה הזאת. איך עושים את זה? אמנו את צוות הפיתוח שלכם למימוש פרויקטים בזמן קצר, תרגלו זאת והשקיעו בהרחבת הידע של הצוות. גם אם האימונים הללו נראים חסרי תוחלת או שנראה לכם שיכולתם להוציא יותר תוצר פיתוחי בפרק הזמן הזה, אל תתפתו לשנות את התעדוף.
מיתוס מספר 6: קוד תוכנה הוא כמו ג'לי, צריך לתת לו להתמצק לפני שמשחררים אותו החוצה
.
קוד שלא שוחרר ללקוחות הוא מלאי של חברות שהמוצר שלהם הוא חבילות תוכנה או שירותים מבוססי תוכנה. אם תשאלו מנהלי תפעול ומנהלי כספים של חברות תעשייתיות, הם יספרו לכם שמלאי הוא דבר רע כי הוא צובר אבק ומאבד ערך והדבר היחיד שגרוע ממנו הוא מלאי בתהליך (חומרי גלם שעברו עיבוד ראשוני ואי אפשר למכור אותם לא כחומר גלם ולא כמוצר מוגמר). הבשורה הרעה היא שכאשר אנחנו מפתחים מוצר, כל עוד אנחנו לא משחררים גרסה ללקוחות, כל הקוד שלכם הוא מלאי בתהליך (שילמתם כסף טוב למפתחים, מעצבים וכו' אבל שום לקוח לא יכול להשתמש בתוצרים). במקרה הרע שבו אתם משחררים גרסה פעם בשנתיים, למעשה כל הוצאות המו"פ שלכם במשך שנתיים הן מלאי בתהליך. הבשורה הרעה עוד יותר, היא שבתעשיית התוכנה הפחת של מלאי הוא מהיר מאוד, ולכן במחזורים ארוכים, אנחנו משחררים מוצרים מיושנים שעלות הפיתוח שלהם יקרה ומפסידים כסף רב שיכול היה לעבור לשורה התחתונה של הדוחות הכספיים. בעיה נוספת של זמני פיתוח ארוכים היא שככל שהמוצר מסובך יותר זמן ההתמצקות של הג'לי ארוך יותר, ואת התוצאה תוכלו כמובן למצוא במיתוס מספר אחד. אם מעניין אתכם איך משחררים גרסאות במהירות ללא התמצקות של ג'לי חכו לפוסט על Continuous Deployment.
השורה התחתונה
בחירת שיטת ניהול פרויקטי התוכנה המתאימה לכם צריכה להתבצע לפי הצורך העסקי שלכם, המבנה הארגוני והתרבות הארגונית, וחשוב מכל: החסם העסקי שעומד בפניכם. אם כולם בוחרים ליישם SCRUM, זאת לא בהכרח השיטה הנכונה בשבילכם ויתכן שהיא תגרום לכם יותר נזק מתועלת. בפוסטים הבאים נלמד על השיטות השונות ומתי נכון להפעיל כל אחת מהן.
משה קפלן
משה קפלן הוא מפתח ויזם. בשנים האחרונות הקים את חברת רוקטיר עם שותפים, סטארט אפ שהפך לחברה מובילה בתחום האצת ביצועים של מערכות תוכנה. בעל תואר ראשון בפיזיקה ומדמ"ח ותואר שני בהנדסה, לשעבר דירקטור בארגון הגריד הישראל ויועץ לסטארטאפים בנושאים שונים כגון חיבור תשתיות ותוכנה, כיצד להטמיע תהליכי פיתוח מתקדמים דוגמת SCRUM ו - Agile, כיצד לבחור טכנולוגיה וארכיטקטורה וכיצד לשלב את הטכנולוגיה עם הצרכים העסקיים.
הגב
11 תגובות על "שיטת ניהול פרוייקט תוכנה: 6 מיתוסים לניפוץ"
* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.
http://programming-motherfucker.com
לינק מומלץ,
הערה: אני חושב שמי שכתב את העמוד הזה בהחלט הפנים את הפוסט: לפעמים מה שחשוב זה הלקוח המשלם ולא התוכנה היפה (לצערנו…)
ממשיכים לפתח,
משה קפלן
מיתוס אחד ושלוש לא קיימים. לפי דעתי הכותב (משה קפלן, סלח לי) דחף אותם בכוח כמיתוסים בשביל למלא את הדף.
שאר המיתוסים כתובים מנקודת מבטו של סטארטאפיסט ומתאימים בהתאם לעולם הסטארטאפים (זה לא אומר שהם לא נכונים אלא ספציפיים לעולם מסויים).
הוד,
נ"ב, אני אשמח לשמוע דוגמאות אישיות או מחברים כיצד אתה בחרת את שיטת ניהול הפיתוח שלך,
ממשיכים לפתח,
משה קפלן
יתרון נוסף של פריסה ממשכת (Continuous Deployment) היא ההפרדה מוחלטת בין מחזורי פיתוח עסקי והנדסי. אין צורך להסתנכרן על פרקי זמן קבועים ואפשר בקלות להפנות משאבי פיתוח למספר שעות או ימים לחלקים שונים של המוצר ללא דאגה שהדבר יפגע ב"ספרינט".
למשל, אין צורך לדחות פיצ'ר של שעתיים למחזור פריסה הבאה כי הקוד בפיתוח לא יציב, ומורכב מידי לחזור לקוד שבייצור, לשנות אותו, ולמזג את הקוד שעכשיו בפיתוח.
מוצר נלווה הוא שעלוית תיקון באג בייצור קטנה מאוד יחסית למחזורי פיתוח "מסורתיים" כי הקוד בפיתוח זהה כמעט לקוד בייצור.
ישי,
אני חושב שאפשר להגדיר אותך כאבי השיטה בישראל :-). זאת בהחלט שיטת ניהול פרויקטים מצויינת לארגונים שמספקים שירות או מוצר כשירות. מי שמעוניין, שווה שיקשיב לפודקאסט ברברסים של ישי: http://www.reversim.com/2010/08/075-continuous-deployment.html
ממשיכים לפתח
משה קפלן
שלום שחר,תודה!אני מסכים איתך שכישלון והצלחה של פרויקט תלויים מאוד בהיבטים שהקשר בינהם לטכנולוגיה רופף מאוד. אני חייב להודות שראיתי לא מעט חברות מצליחות מאוד שהטכנולוגיה שמניעה אותן היתה מקרטעת מאוד, וכמובן גם את המקרים ההפוכים (טכנולוגיה מדהימה וכשלון עסקי מפואר).לגבי הסטטיסטיקות. ממחקרים אחרים שלא צרפתי פה, יש קשר הדוק בין התעשייה ושולי הרווח לבין הצלחות פרויקטים. וזאת בדיוק בגלל הסיבה שציינת: יש עסקים שלא ישרדו כשלון של פרויקט תוכנה גדול (או קטן), ולכן הם נלחמים על ההצלחה שלו ועל הקשר שלו לעסק.ממשיכים לפתח, משה קפלן
שלום שחר,
תודה!
אני מסכים איתך שכישלון והצלחה של פרויקט תלויים מאוד בהיבטים שהקשר בינהם לטכנולוגיה רופף מאוד. אני חייב להודות שראיתי לא מעט חברות מצליחות מאוד שהטכנולוגיה שמניעה אותן היתה מקרטעת מאוד, וכמובן גם את המקרים ההפוכים (טכנולוגיה מדהימה וכשלון עסקי מפואר).
לגבי הסטטיסטיקות. ממחקרים אחרים שלא צרפתי פה, יש קשר הדוק בין התעשייה ושולי הרווח לבין הצלחות פרויקטים. וזאת בדיוק בגלל הסיבה שציינת: יש עסקים שלא ישרדו כשלון של פרויקט תוכנה גדול (או קטן), ולכן הם נלחמים על ההצלחה שלו ועל הקשר שלו לעסק.
ממשיכים לפתח,
משה קפלן
פוסט מצוין – יצרתי סדנא מעשית לניהול פרויקטים, מנהלי פרויקטים בתוכנה ימצאו בה עיניין:
http://bit.ly/xMSjY0