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

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

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

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

דביר,

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

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

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

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

- המשקל שיש לדברים שאומר "מנהל" הוא יותר גדול ממשקלו האמיתי - דבר שגורר החלטות טכניות שגויות.

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

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

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

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

 

 נ.ב. - דביר, אני זוכר את החוב שלי אלייך ואני אממש אותו אחרי סוכות.

 

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

בסופו של דבר נראה היה כי זמן רב מידי מתבזבז על תאום בין השניים.

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

האתגר הגדול הוא להפוך את המנהלים הטכנולוגיים ל"מסודרים" יותר.  

 

דביר, אני מצטרף לאלעד - אחלה דיון. מענין מאד מה תהיינה התגובות כאן.

 

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

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

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

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

קודם כל שמעון, תתחדש על התמונה :)

 

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

 

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

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

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

 

בשביל הסימוכין אני מוסיף (זה גם מופיע בבלוג שלי -  פוסט שביעי) לינק לשיעורי ההצלחה של פרויקטים בעולם התוכנה, רק בשביל שתבינו איפה תעשיית התוכנה עומדת ולמה אני חושב שהגיעה הזמן "למהפכה מדעית"  (גם בבלוג פוסט רביעי) - http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

 

אלעד.

אלעד, ראשית תודה על הברכות להצבת התמונה החדשה באתר :-)

 

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

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

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

צטט: שמעון זיירמן 2008-10-02 22:52:50

 

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

 

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

אני מצטרף קצת באיחור, אבל דיון מעניין ביותר!

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

 

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

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

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

 

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

 

מנסיוני, ע"מ להבטיח קיום תהליכי ניהול, צריך גם גוף PMO. ה PMO מורכב מאנשי ניהול מקצועיים שדואגים לקיום התהליכים (תוכניות עבודה מעודכנות, ניהול סיכונים, בקרה וכו'). הם גם עוזרים מקצועית למנהלי הפרויקטים ומציירים להנהלה את תמונת המצב של כלל הפורטפוליו (בגישת ה AGILE, ה SCRUM MASTER מבצע את שני התפקידים הראשונים). גוף PMO יכול לכלול סטונדט בחצי משרה בארגונים קטנים ולהגיע עד עשרות אנשים בגופים של אלפי אנשים.

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

 

לסיוון (וגם אחרים שרוצים להגדיר תהליכי פיתוח פשוטים),

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

 

צטט: דביר זהר 2008-10-04 23:32:42

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

 

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

 

מנסיוני, ע"מ להבטיח קיום תהליכי ניהול, צריך גם גוף PMO. ה PMO מורכב מאנשי ניהול מקצועיים שדואגים לקיום התהליכים (תוכניות עבודה מעודכנות, ניהול סיכונים, בקרה וכו'). הם גם עוזרים מקצועית למנהלי הפרויקטים ומציירים להנהלה את תמונת המצב של כלל הפורטפוליו (בגישת ה AGILE, ה SCRUM MASTER מבצע את שני התפקידים הראשונים). גוף PMO יכול לכלול סטונדט בחצי משרה בארגונים קטנים ולהגיע עד עשרות אנשים בגופים של אלפי אנשים.

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

 

לסיוון (וגם אחרים שרוצים להגדיר תהליכי פיתוח פשוטים),

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

 

 

 איפה נרשמים?

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

 

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

 

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

 

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

צטט: שמעון זיירמן 2008-10-02 22:52:50

דביר, אני מצטרף לאלעד - אחלה דיון. מענין מאד מה תהיינה התגובות כאן.

 

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

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

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

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

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

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

תודה