עידו הוא מנהל צוות של 5 אנשים, צוות שמתרכז בפיתוח תוכנה. אנחנו נפגשים מידי פעם ל"כיוונון" הדרך ע"פ גישת Pro-it.
עידו הוא מנהל מוצלח מכל הבחינות, מלא רעיונות ומאוד דידקטי, מידי פעם אנחנו נפגשים לכוונון הפוקוס העיקרי של הצוות.
ישבנו יחד על תוכנית העבודה שלו לרבעון הבא של השנה, הבנו וחידדנו יחד את התפוקות העיקריות שהוא צריך לספק ומתי.
עידו אימץ את גישת Pro-it - ולהלן חלקה:
בעצם דיברנו כמו שאני קורא לזה בגישת Pro-it: על ה"עתיד", לאן הספינה ע"ש עידו מפליגה.
ביקשתי מעידו להציג לי את ה"עבר", והוא בהתלהבות הראה לי איך הוא פוגש את אבני הדרך שלו אחת אחרי השנייה בדיוק לא רע בכלל.
כשהסתכלתי בתוכנית עבודה של עידו - הבחנתי במשהו שונה - שני ה- Deliveries האחרונות , אחת נמסרה ב- 44 יום מוקדם יותר והשנייה ב- 20 יום מוקדם יותר - מתאריך ההתחייבות ללקוח.
מבחינת עידו והצוות שלו - זו הצלחה גדולה, מבחינת הארגון - לא כ"כ בטוח.
כולנו מכירים את גישת JIT - Just in time - בגדול : תורה שפותחה ביפן, צמחה מן השטח במפעלי התעשייה ונקלטה גם בארגוני השירותים. כ- 70% מהתרומה להצלחה של יישום ה- JIT מקורם בתכנים שהם מאוד אוניברסליים ואינם קשורים בהכרח לתרבות היפנית. השילוב של גישת JIT עם גישות ניהוליות אחרות מראה כי היישום בשטח מביא תוצאות טובות יותר מאשר יישום JIT בפני עצמה.
החוק ה- I של JIT קובע:
עבוד רק על מה שנדרש - בזמן, בכמות ובדרישות המפרט.
פירושו של החוק הוא כי אין לספק את המוצר או השירות לפני הזמן או אחריו. אין לפתח מוצר בפחות מדרשות המפרט, אך גם לא מעבר לדרישות.
מה שמביא אותי לחוק "40-20-40" -
התעלמות מהחוק ה- I של JIT יוצר את תופעת "40-20-40" בארגונים. מצב בו:
• 40% מהביקושים מסופקים לפני הזמן.
• 20% מהביקושים מסופקים בזמן.
• 40% מהביקושים מסופקים באיחור.
החוק ה- I של JIT "מיישר את הקו": הביקושים שהיו מסופקים בעבר באיחור, יסופקו בזמן, וזאת על חשבון אותם ביקושים שהיו מסופקים לפני הזמן.
תופעת ה- "40-20-40" מצב הנוצר מחוסר עדיפויות ברור או כתוצאה מסדר עדיפויות הנקבע על פי לחצים שונים, מנהלי הקבוצות צוותים מבצעים עשרות משימות לפני הזמן. יישור הקו ע"י מתן סדר עדיפויות מתאימים, מביא לשיפור משמעותי בתפקוד הצוותים.
בארגון הנ"ל מחלקת ה- QA מהווה צוואר בבקבוק - הקדמה של תאריכים באופן כ"כ קיצוני,
של 44 יום, אומרת:
• מכיוון שברור שצוות ה- QA מהווה צוואר בקבוק, ה"מלאי" בתהליך גדל - מה שמביא איתו הרבה מאוד בעיות.
• אף אחד מצוות ה- QA לא מתכוון ל"געת" במוצר ב- 44 יום הקרובים.
• כשצוות ה- QA כן יתחיל לבדוק את המוצר לאחר ה- 44 יום, אומר שהצוות של עידו יתחיל לקבל רשימת BUGS , ויצטרכו לעזוב את כל מה שהם מתעסקים בו באותו רגע, ויתחילו לשחזר ולהתחיל לעבוד על פיתרון אותן בעיות - מה שיגרום לעיקוב בתהליכי פיתוח של המוצרים החדשים, ולהגדלת זמן התגובה של הצוות.
• מאוד יכול להיות שהדרישות של המוצר שכביכול הוקדם, כבר אינן עונות על דרישות הלקוח הסופי. הלקוח הסופי הוסיף דרישות למוצר במשך הזמן, מה שדורש מהצוות לחזור לאיטרציות נוספות של פיתוח.
• הצוות, במקום ל"רוץ" על המוצר הספציפי, יכול להמתין ו"לרוץ" על מוצרים אחרים יותר חשובים ובעלי ערך לארגון, מוצרים או פיתוחים שפוטנציאל האיחור/סיכון שלהם הרבה יותר גבוה.
לפרטים נוספים על גישת Pro-it , ניתן ליצור קשר עם המחבר.
איתי פוירשטיין - מאמן מומחה ניהול פרויקטים. טל' 0544731214 http://www.pro-itnow.com itay@pro-itnow.com
מקור המאמר: www.Articles.co.il - מאמרים לשימוש חופשי
כלים שימושיים למאמר: פרסם את המאמר
 הדפס את המאמר
 שלח לחבר
 קישור ישיר למאמר
 פניה לכותב המאמר
 דווח מאמר בעייתי
|
