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

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

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

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

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

אז כמה משימות?
אז הבנו שלנהל 1000 משימות זה לא ריאלי, ולנהל 2 משימות זה גם לא דבר ממש חכם (חריגה של אחת מהן ב - 10%, ומיד חרגנו בכל הפרויקט ב - 5%), אז כדי להגיע למספר הנכון נעשה מספר הנחות:

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

לכן אם משימה בודדת יכולה לחרוג ב - 50%, וחריגה כוללת של 5% בכל הפרויקט היא כבר בעיתית, אזי אנחנו נדרשים לנהל לפחות 10 משימות (50/5=10) אם רק משימה אחת תחרוג. בהנחה ריאלית מטבע האדם ששתיים או שלוש משימות לפחות יחרגו הרי אנו נדרשים לנהל לפחות 20-30 משימות.
מצד שני אם ננהל 100 משימות, אז חריגה של כל אחת מהן תהיה כמעט ולא משמעותית לפרויקט (50/100 = 0.5%) ולכן אין בשביל מה לרדת לרזולוציה כזאת.

השורה התחתונה (בינתיים)
התשובה נמצאת אי שם באמצע, וההמלצה שלי היא על ניהול של מספר עשרות משימות

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

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

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

חושבים אחרת? רוצים לשתף מנסיונכם? אתם מוזמנים להגיב ולהעיר

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

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

משה קפלן  

 

יש כמה כללי אצבע שעובדים מצוין:

1. מנהל צריך לנהל 5(+/-)2 אנשים כדי להיות אפקטיבי . 
2. כל המשימות בפרויקט צריכות להיות מפוזרות בין האנשים האלה (אחריות ביצוע). 
3. בהנחה שאצל כל אחד מהם יש משימה אחת או שתיים שהן במסלול הקריטי או פוטנציאל לסיכון אזי יש 3-14 משימות לטיפול אישי צמוד (14 זה הרבה מאוד). שאר העבודה היא מעקב,הנחיה, דווח, טיפול בכ"א ועוד. 

הערה 1 : אני מתיחס לפרוייקט שאינו קטן דהיינו מעל 15 איש ל 6 חודשים ומעלה. 
כלל ה 5+-2 מבטיח שתשומת הלב אינה מתפצלת לאלף כיוונים והופכות את המנהל לבלתי יעיל 
הערה 2 : משימה של 0.1% מהפרויקט שמתעכבת מסיבות "לוגיסטיות" יכולה לגרום לאסון כך שקריטריון הסיכון אינו רק היקף העבודה.

 

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

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

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

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

המפתח הוא

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

 

השאלה:

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

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

 

התשובה:

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

 

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

 

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

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

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

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

לגבי ראש צוות שלא עובד ב - Agile עם הצוות הנ"ל, נניח שמספר חודשים זה חצי שנה, שזה בערך 100 ימי עבודה (אחרי שהורדנו חגים, ימי חופש, מחלה וכו') לכל אדם.  מה שאומר בכל הצוות יש משהו בסגנון של 350 ימי עבודה בתקופה הזאת.
ניהול בגאנט ע"י ראש הצוות יאפשר לו לנהל כ - 50 משימות בגודל של כ - 7 ימי עבודה. משימה בגודל כזה היא סבירה, וגם הפריסה על גאנט היא סבירה. רצוי מאוד שכל משימה כזאת תהיה אטומית, דהיינו, תבוצע ע"י איש צוות אחד שיהיה אחראי מקצה לקצה על היישום שלה.
אם כל אחד מאנשי הצוות ישבור את המשימות הוא לא יצטרך יותר מרשימה לא ארוכה במיוחד כדי לרשום את התוכנית שלו (בשבעה ימי עבודה לדוגמה הוא יצליח לכתוב מספר פונקציות עם פניות לבסיס הנתונים, לכתוב Unit Tests ולבצע אינטגרציה).
לכן אנשי הצוות עצמם רצוי שימנעו להשתמש בגאנט, אלא אם הם מרגישים צורך עז לתעד את המשימות שלהן באמצעות הכלי הזה.

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

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: פונקציית "החלקת המשאבים" היא חשובה ומועילה מאד. אחרי שלומדים "להכניע" אותה ולעקוף את הבעיות שלה, היא יכולה להפוך את תחזוקת הגנט השוטפת לקלה הרבה יותר ואת תוצאות הפרויקט לטובות יותר.

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

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

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

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

אלטרנטיבות:
על אלטרנטיבות לשימוש בגאנטים נדבר בהמשך, אבל בינתיים אם אתם לא מתים על המוצר Project עצמו אבל עדיין רוצים להשתמש בפתרון לניהול Gantt בודאי תשמחו לדעת שיש מוצרים תחליפיים היום שלא דורשים רישיון ואפילו מאפשרים שיתוף בין אנשים:

• Clarizen: חברה ישראלית המספקת פתרונות ניהול פרויקטים בתצורת SaaS
• LiveProject: פתרון דומה אבל עם ממשק מאוד דומה ל - Project
• Google Docs: הכנסו לכלי הגליון האלקטרוני של גוגל ותוכלו להתשתמש בגרסה מופשטת ומוגבלת של גאנטים.
• Gantter: כלי חינמי בתצורת SaaS, מבוסס Google Docs ועושה רושם מצויין ותודה לאסף כהן ואופיר גור.

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

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

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

נ"ב רוצים ללמוד קצת יותר על ביצועים ו - Cloud Computing? אתם מוזמנים לגלוש לבלוג האנגלי שלי

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

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

 

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

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

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

 

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

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

 

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

 

מדוע זה קורה? 

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

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

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

משה קפלן