עבודה עם Muktitasking – עבודה מרובת משימות בו זמנית של משאב אחד.

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

 אם כן איך תוכל להעריך כמה זמן תיקח העבודה שלהם? כמה זמן ייקח להם לסיים את העבודה?

אתה לא. אתה לא יכול. אל תנסה אפילו.

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

אתה לא תוכל להעריך זמן בעבודת מולטיטסקינג ( מולטיטסקינג יכול לבזבז בין 20-90% מהזמן שלך).

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

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

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

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

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

צטט: איתיf 2009-04-18 02:15:35

עבודה עם Muktitasking.

עבודה עם Muktitasking – עבודה מרובת משימות בו זמנית של משאב אחד.

 

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

 

 אם כן איך תוכל להעריך כמה זמן תיקח העבודה שלהם? כמה זמן ייקח להם לסיים את העבודה?

 

אתה לא. אתה לא יכול. אל תנסה אפילו.

 

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

 

אתה לא תוכל להעריך זמן בעבודת מולטיטסקינג ( מולטיטסקינג יכול לבזבז בין 20-90% מהזמן שלך).

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

 

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

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

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

צטט: ליאורשיאון 2009-04-18 15:14:08

 

 

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

 

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

 

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

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

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

צטט: איתיf 2009-04-18 15:46:01

צטט: ליאורשיאון 2009-04-18 15:14:08

 

 

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

 

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

 

 

 

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

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

 

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

 

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

איתי,

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

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

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

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

צטט: שמעון זיירמן 2009-04-21 22:15:42

איתי,

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

 

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

 כמלווה פרויקטים, הדבר העיקרי שבד"כ אני דוחק במנהלי פרויקטים - הוא להתחיל לנהל!!!!  כלומר ... מה צריך לעשות היום עכשיו, על מנת לקדם את הפרויקט!  Get it done!

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

באחד המאמרים של  התייחסתי לזה...

היי אתי!

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

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

שמעון

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

שאלנו אותו פעם מה הסוד, והוא אמר, "אני עושה רק דבר אחד בבת אחת."

אורן,

שני המשפטים חזקים!!!

איתי,

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

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

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

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

שבת שלום,

יואב.

צטט: sheepofnoise 2009-05-22 22:49:40

איתי,

 

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

 

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

 

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

 

שבת שלום,

יואב.

 יואב,

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

אחד הדברים שאני מנסה לדחוף מנהלי פרויקטים - הוא להתחיל לנהל!!!

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

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