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

22 ביולי 2010

11 תגובות

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

If You Have to Shoot, Shoot, Don't Talk
אז, כמובן שגאנטים הם קצת מבאסים גם ליצירה וגם לתחזוקה, אבל זה כלי מצויין לזהות צווארי בקבוק ולהבין אם בכלל יש לכם סיכוי להגיע למטרה, אם רק תעשו את זה נכון.
 
טיפים של אלופים
אז כנראה שכמו כל דבר בחיים, כדי להצליח בפרויקט צריך להתחיל הכי מהר שלך ולאט לאט להגביר….





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


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

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

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

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

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

  5. אל תשאירו משאבים בהעמסה נמוכה. אם לא תעשו את זה, או שהמשאבים ימצאו (או ימצאו להם) תעסוקה אלטרנטיבית, או שתקבלו שאלות מתאימות. העמסה נמוכה (ואין הכוונה ל – Buffer של 10% לתורנות), צריכה להתבצע בדרכים אלטרנטיביות, כמו ניהול Buffer כולל לפרויקט.

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

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

  8. אל תשאירו משימות ללא תלויות. אין כמו משימות שהופיעו משום מקום באמצע הפרויקט (האם הן אפילו לא תלויות באפיון המערכת?) או ללא תלות במשימה אחרת או שמשימה אחרת לא תלויה בהם (אם זה המצב יתכן שאתם יכולים לסיים את הפרויקט בלי לבצע את המשימה הזאת…)

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

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

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

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

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


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

 

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


 

עדכונים מתגובות:

הטיפים של אילן עצמון:

שני דברים נוספים:



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

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

הטיפים של רונית סנה:

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


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

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

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

כתיבת תגובה

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

11 תגובות

  1. אילן עצמון27 ביולי 2010 ב 8:46

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

    להגיב
  2. יובל28 ביולי 2010 ב 12:55

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

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

    להגיב
  3. Moshe Kaplan28 ביולי 2010 ב 17:42

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

    משה קפלן

    להגיב
  4. Moshe Kaplan28 ביולי 2010 ב 17:45

    הי אילן,

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

    משה קפלן

    להגיב
  5. Moshe Kaplan31 ביולי 2010 ב 11:57

    שימו לב להתכתבות בקבוצת High Tech Consultants in Israel
    ב – Linkedin

    http://www.linkedin.com/groupItem?view=&gid=2181962&type=member&item=25598753

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

    להגיב
  6. ספי בארי2 בפברואר 2011 ב 19:27

    בתור מי שעובד עם AGILE -
    השאלה הגדולה היא – מה סדר הגודל של המשימות שצריכות להיכנס לתוך הגנט? כידוע המשימות ה"אמיתיות" צריכות להיות מפורטות ברמה של מספר ספרינטים קדימה (2-3). מעבר לזה הכל השערות – וזהו בדיוק הטווחים שיותר "סקסיים" על הגנט. אני משתדל להשאיר הכול מעורפל מעבר ל2-3 חודשים – ולזרוק את הכדור חזרה בנוגע לתעדופים שמנהלי המוצר רוצים באותו פרק זמן.

    להגיב
  7. Moshe Kaplan3 בפברואר 2011 ב 9:43

    תודה ספי,

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

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

    להגיב
  8. גיא19 בספטמבר 2011 ב 20:44

    1. רונית דיברה על שיטות "להכניע" את החלקת המשאבים כך שיעבוד בצורה מוצלחת. אפשרי לפרט?

    2. מה בין הניהול בTFS של הPBIs לבין הניהול בגאנט?
    אני יודע שיש אופציית סנכרון בין הTFS לגאנט שלי, אבל להראות למנהל מאות user stories מפורטים זה לא פרקטי.

    בעצם בזמן שבTFS אני אנהל User stories שמקוטלגים לפי area path של תהליכים עסקיים מבצעיים (בשפת המשתמש), אני רוצה להציג גאנט מלא עד לסוף הפיתוח של הבלוק הנוכחי, וכנראה שארצה להציג נושאים רחבים יותר תחת כותרות כמו "תקשורת", "ממשק למערכת X", "יתירות" וכו'

    מה נפח הtaskים שמציגים בתור US לעומת בגאנט?
    האם בגאנט הכיוון הוא להציג נושאי פיתוח במערכת כמו שהדגמתי למעלה, או כיוון של סיפורי משתמש?
    איפה אני מתכנן את הארוך טווח שלי? כי בכל זאת יש product burndown chart, האם מקביל לגאנט?
    דיווחי שעות – גם וגם? רק באחד המקומות?

    להגיב
  9. Moshe Kaplan19 בספטמבר 2011 ב 22:27

    שלום גיא,

    1. אני אתוודא שאני לא מחובבי פונקצית החלקת המשאבים. אבל אם אתה שואף להשתמש בה, היא ניתנת להגדרה מפורטת בתיבות הדו שיח השונות של הפונקציה (מה שאומר שרצוי להעמיק באופציות השונות לפני שלוחצים על הכפתור). תוכל למצוא מספר דוגמאות בלינק הבא: http://office.microsoft.com/he-il/project-help/HP045326241.aspx

    2. ה – PBI (Product Backlog) הוא למעשה היישום של SCRUM ב – TFS. מה שאומר, אם אני מבין נכון, שהשאלה שלך בפועל היא מה הקשר בין SCRUM לגאנטים? התשובה היא שגאנט צריך למעשה להיות "החזון" או תוכנית העבודה הכללית מאוד שניתן ורצוי יהיה לשנות אותה, והיא זאת שתחבר בין הטקטיקה של הספרינטים לבין האסטרטגיה של פיתוח המוצר.

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

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

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

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

    להגיב
  10. גיא24 בספטמבר 2011 ב 14:51

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

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

    להגיב
  11. משה קפלן25 בספטמבר 2011 ב 10:12

    שלום גיא,

    שאתה מתייחס אליו הוא תמחור של פרויקטים והערכת התקדמות. הבעייה המרכזית שמתרחשת בהרבה מאוד פרויקטי תוכנה, שמה שאנחנו צריכים בעוד שנה וחצי יהיה לו קשר נומוך למה שאנחנו חושבים שצריך היום (ואז השאלה היא אחרת…).
    אם התכולה היא אכן סגורה (עשינו אותה 100 פעם בצורה זו או אחרת או היא רכיב קטן בתוך פרויקט גדול יותר), יש מספר שיטות תמחור לזיהוי התקדמות. בכל מקרה לפני התחלת הפרויקט במקרה כזה תצטרך לבצע תמחור עלות לתכולות (לא חייבים להיכנס לכל תת רכיב קטן):
    1. התשומות המושקעות חלקי התמחור המקורי: עברו שלושה חודשים מתוך שנה וחצי, השקעתם תשומות של 16% (שיטה מצויינת בעיקר אם אתה סופר את החודשים לשחרור או לפנסיה)
    2. התשומות מול הערך: עשיתם 10% מהתמחור המקורי, ב – 3 חודשים (16% כאמור), כנראה שאתם בפיגור משמעותי.

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

    כמובן שניתן לשלב גם את תורת האילוצים בסיפור…

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

    להגיב