למה שיפוצניק מנהל את הפרויקט שלך

4 ביולי 2010

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

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

 

מרגיש שהפרויקט שלך מנוהל ע


איך הצלחנו להגיע למצב הזה?

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

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

 

רגע זה נשמע לי מוכר…

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

 

מה הקשר?

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

 

מדוע זה קורה? 

כנראה שבכל זאת יש מאפיינים די דומים, בשני המקרים אנחנו נוטים להסחף לתוך פרויקטים שלא נגמרים, אנחנו לא ממש מתכננים מה אנחנו באמת צריכים ולא באמת מה אנחנו רוצים, בשנייהם אנחנו מתאהבים ב – Features לא נחוצים בהכרח, בשנייהם כולנו חושבים שאנחנו מבינים ובאף אחד מהם אנחנו לא באמת מתכננים את ה – Exit Strategy (האמת שגם חתונה יכולה להיות אנלוגיה לא רעה, אבל כמה מלח אפשר לזרות על הפצעים בפוסט אחד 🙂


 

אז מה עושים? 

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

 

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



  1. Agile/SCRUM (כן, זה לא רק באזז)

  2. Continuous Deployment: איך משפרים את תהליך ההעברה לייצור וניהול גרסאות.

  3. איך לנצל את גאנטים (לא אומרים איכס על כלי ניהול) בצורה טובה יותר

  4. איך מתמודדים עם בלת"מים

נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!


ממשיכים לפתח,


משה קפלן Follow MosheKaplan on Twitter

הוסף תגובה
facebook linkedin twitter email

להגיב על Moshe Kaplan לבטל

האימייל לא יוצג באתר. שדות החובה מסומנים *

11 תגובות

  1. אלון12 ביולי 2010 ב 23:43

    בתור אחד שעשה לא מעט שיפוצים לאחרונה,
    אני ממש מזדהה!

    אחלה פוסט 🙂

    הגב
  2. יוני13 ביולי 2010 ב 10:25

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

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

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

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

    (וסליחה על החפירה – אולי הייתי צריך כבר לכתוב טור נגד וזהו :))

    הגב
  3. Moshe Kaplan13 ביולי 2010 ב 12:22

    יוני,

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

    אחלה התייחסות,

    משה קפלן

    הגב
  4. יוני13 ביולי 2010 ב 23:11

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

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

    -יוני

    הגב
  5. גיא ניר14 ביולי 2010 ב 13:43

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

    כמו שחבר ותיק שלי אומר על כל דליברי של פרוייקט: במקרה הטוב, תאחר את ההגשה בחודש ו-$20,000.

    הגב
  6. Moshe Kaplan14 ביולי 2010 ב 14:18

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

    גיא, אתה ממש צודק. הבעייה שאני מכיר כמה אנשים עם פרויקטים של כמה מיליונים טובים של דולרים, שהיו שמחים מאוד להתפשר על החודש וה – 20K$ 🙂

    משה קפלן

    הגב
  7. שחר פריזאת29 ביולי 2010 ב 13:10

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

    הגב
  8. Moshe Kaplan29 ביולי 2010 ב 13:51

    שחר,

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

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

    הגב
  9. יובל ירט16 במרץ 2011 ב 18:04

    אני כל כך מתחבר להערה על האינטגרציה.

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

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

    הצעד הראשון והמהותי של Lean/Agile אם תרצו.
    אני קורא לזה זרימה/Flow… ומדבר ומיישם את זה די הרבה לאחרונה.

    הגב
  10. Moshe Kaplan16 במרץ 2011 ב 18:17

    שלום יובל,

    הערות מצויינות.
    אם כבר Continuous Integration, אז שווה לדבר על Continuous Deployment… אני אקדיש לזה פוסט בשבועות הקרובים,

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

    הגב