שיטת ניהול פרוייקט תוכנה: 6 מיתוסים לניפוץ

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

צילום: flickr, cc-by, markhillary

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

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

מיתוס מספר 1: כל פרויקטי התוכנה נכשלים

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

 (*) Standish Group היא חברת ייעוץ מובילה בתחום ניהול הפרויקטים הממוקמת בבוסטון. החברה אוספת נתונים על פרויקטי תוכנה מאז שנת 1994, ומפרסמת אחת לשנה סטטיסטיקות עדכניות. נתוני 2011 פורסמו בגיליון PM Network August 2011 של אגודת ה – PMI. הנתונים בגרף למטה הם משנת 2005 (לא כל כך ישן למאמר אקדמי), אבל הם בהחלט תקפים כפי שתוכלו ללמוד מהמאמר ב – PM Network וההשוואה של הנתונים הכוללים לשנים הקודמות (37% מהפרויקטים עומדים בזמן ובתקציב, 42% “מאותגרים הצלחתית” ואילו ב – 21% מהמקרים הכירו בכישלון המוחלט של הפרויקט).
.
From Leading Answers Blog: 2007 Study by Standish Group

.

מיתוס מספר 2: פרויקטים נכשלים כי אין להם מספיק משאבים

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

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

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

מיתוס מספר 4: אני מנהל פיתוח בסטארט אפ, השיטה הזאת לא מתאימה לי, היא מתאימה רק לחברות גדולות!

.

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

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

מיתוס מספר 5: שיטת ניהול פרויקטי התוכנה הנכונה ביותר היא זאת שכולם מדברים עליה בערב יום שישי

.

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

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

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

מיתוס מספר 6: קוד תוכנה הוא כמו ג’לי, צריך לתת לו להתמצק לפני שמשחררים אותו החוצה

.

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

.

השורה התחתונה

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

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

משה קפלן

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

הגב

11 תגובות על "שיטת ניהול פרוייקט תוכנה: 6 מיתוסים לניפוץ"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
בירש
Guest
משה קפלן
Guest

לינק מומלץ,

הערה: אני חושב שמי שכתב את העמוד הזה בהחלט הפנים את הפוסט: לפעמים מה שחשוב זה הלקוח המשלם ולא התוכנה היפה (לצערנו…)

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

hod
Guest

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

משה קפלן
Guest
שלום הוד, קודם כל אשריך כפי שנהוג לומר בעולם הדתי, אם אתה לא נתקל במיתוסים האלו. אכן, כפי שכתוב בפרופיל שלי, אני אכן מבלה לא מעט בעולם הסטארט אפים, אבל יוצא לי לבקר גם במקומות אחרים ולשוחח לא מעט עם עמיתים למקצוע. בנוגע למיתוס #1: בעולם הסטארט אפים אכן יחס של 1:10 מקובל, אבל אני מזמין אותך לבקר בכל הבנקים, חברות הביטוח ושאר הארגונים הגדולים בארץ ולגלות שהמצב לא טוב בהרבה (ואם תתעקש ותבקר בחו”ל תגלה שגם שמה המצב לא טוב בהרבה). אבל כאמור קטונתי ולכן הסתמכתי על נתונים של חברת ייעוץ מכובדת שניתחה 23,000 פרויקטים. בנוגע למיתוס #3, אני… Read more »
משה קפלן
Guest

הוד,

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

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

ישי סמיט
Guest

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

משה קפלן
Guest

ישי,

אני חושב שאפשר להגדיר אותך כאבי השיטה בישראל :-). זאת בהחלט שיטת ניהול פרויקטים מצויינת לארגונים שמספקים שירות או מוצר כשירות. מי שמעוניין, שווה שיקשיב לפודקאסט ברברסים של ישי: http://www.reversim.com/2010/08/075-continuous-deployment.html

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

שחר זריהן
Guest
משה – אחלה פוסט, כרגיל. אני מאוד נהנה לקרוא את המאמרים שלך. לגבי הנקודות שהועלו ובעיקר לגבי מיתוס #1 – יחס של 1:10 בסטארטאפים (שאכן נשמע הגיוני וזהו הנתון שגם אני מכיר כחוק אצבע) אינו אומר ששאר הסטארטאפים נכשלו כפרוייקט תוכנה או בכלל. לא מעט מהם יוצאים לפועל ועובדים בעולם האמיתי ומדי פעם גם יוצאות תוכנות ואפליקציות יפות מאוד שנכשלות מסיבות אחרות לחלוטין (מוצר מתחרה שיוצא, שינוי API של חברה וכו’). אני לא מכיר את המספרים ואני מעריך שחברה רצינית אשר בדקה 23,000 פרוייקטים, ולא ידוע על סיבה לחשוד בהם אכן מספקת מספרים אמינים ואכן נשמע לי מניסיוני שכל פרוייקט… Read more »
משה קפלן
Guest

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

משה קפלן
Guest

שלום שחר,

תודה!

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

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

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

איתי
Guest

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

http://bit.ly/xMSjY0

wpDiscuz

תגיות לכתבה: