בתשובה לeasy, 24/03/08 19:35
 |
|
 |
||
|
||||
 |
טוב, כנראה שיש ויש. האקס שלי, שהיה בכיר בתחום כמה שנים טובות, פרש בפניי פעם מסכת תלונות על כל עניין ''הדד-ליין הרצחני'', הידוע מראש לכישלון, ועל הטיפשות שבקביעה לא ריאלית של הדד-ליין. |  |
 |
 |
|
|
|
||
|
||||
|
זה נכון. לא היה לי דד-ליין אחד בחיים שהיה ריאלי. מצד שני, כאמור, אין יותר מדי כאלה. | |
|
|
|
|
|
||
|
||||
|
זה בטח בגלל שמבינים שממילא העבודה לא תהיה מוכנה בדד-ליין שנותנים לעובדים, אז מקדימים אותו כדי שתהיה מוכנה בזמן שבאמת צריכים אותה. מזכיר לי את הימים הנוראים של הקורסים במדמ"ח, עם הטקסים של דחייה לרגע האחרון, התבכיינות קולקטיבית למרצה, וקבלת דחייה מצטברת של שבוע. זה ככה גם בעבודה? | |
|
|
|
|
|
||
|
||||
|
זה לא בגלל זה. הדד-ליינס בדרך כלל קשורים בגורמים חיצוניים, כמו לקוחות או חברות איתן יש שיתוף פעולה. אי-עמידה בהם, למרות שמדובר בעניין קבוע וכמעט בלתי נמנע, גורר תמיד ''מיני'' משבר דיפלומטי עבור ההנהלה. | |
|
|
|
|
|
||
|
||||
|
במשך שנים חשבתי שזמני יעד (לא רוצה לכתוב דד-ליין) לא ריאליים הם תופעה מגונה שנובעת מחוסר כישורים ויכולת של ההנהלה. לפני כמה שנים התערערה אמונתי (ועדיין לא שבה על כנה) עקב מאמר שנתקלתי בו. במאמר צוטטו מחקרים שטענו שהצבת זמני יעד לא ריאליים אמנם מגדילה את הסיכוי שלא לעמוד בזמן, אך מקצרת את זמן הפרויקט ואפילו באופן משמעותי (כמה עשרות אחוזים למיטב זכרוני), כל זאת בהשוואה להצבת יעדים סבירים. איכשהו המחשבה האינטואיטיבית שלי היא שזמני יעד מטורפים דווקא יצרו תחושת יאוש ולא יתרמו לעמידה במשימה, אבל אולי הניסיון מראה שדווקא מדיניות כזו מביאה להגברת התפוקה. |
|
|
|
|
|
|
||
|
||||
|
גם בתחום שלי (הלא היי טקי) יש פרויקטים שזמני היעד שלהם הם בדרך כלל ליום לפני שהחומר הגיע אליך בכלל. לי זה תמיד נותן תחושה שאפשר להתברבר איתם לגמרי, כי זמן היעד ממילא עבר... | |
|
|
|
|
|
||
|
||||
|
בדרך כלל זה עובד ככה: החברה נגשת למכרז. על כל הסעיפים הטכנים היא מציינת Comply למרות שבפועל זה נכון רק לחצי מהם, אחרת ההצעה תדחה על הסף. לא ידוע בשלב הזה מה סיכויי הזכיה, לכן לא עושים מאמץ רציני למלא במהירות את הפערים בין ההצהרה במכרז ובין מצב המוצר בפועל, לכל היותר עושים משנים קצת את סדרי העדיפויות בתכנית הפיתוח המקורית. השלב הטכני מסתיים, החברה נשארת במכרז ועוברת לשלב הפיננסי, כעת יודעים מי המתחרים במכרז (אלו שנגשו ועברו את השלב הטכני) ויש כבר מושג מהם סיכויי הזכיה. אם הם נראים טובים, מתחילים לעבוד על החלקים החסרים. זוכים במכרז - עכשיו כבר ברור שאין מספיק זמן לסיים את הכל עד מועד האספקה, אבל אם יודיעו את זה ללקוח הוא יקח את מספר שתיים. קובעים את זמן היעד לפי המכרז מתוך ידיעה ששבועיים לפני יבקשו מהלקוח הארכה. שבועיים לפני מבקשים מהלקוח הארכה של חודש, הלקוח מסכים לשבוע (גם לו יש התחייבויות כלפי הלקוחות שלו), שלושה שבועות עובדים כמו מטורפים, כולל ימי עבודה ארוכים וימי שישי קצרים, בערב שלפני הכל מתרסק, וכולם בהסטריה, באיחור של שבוע הלקוח מקבל את המוצר כשהוא מלא באגים, סופגים קצת קנסות על האיחור, הרבה צעקות על הבאגים, מוציאים בתוך חודש גרסת עדכון שפותרת את הבאגים הבולטים ביותר (בעיקר כאלו שקשורים לממשק המשתמש) ונושמים לרווחה. |
|
|
|
|
|
|
||
|
||||
|
תיאור ממש אמיתי של העליה שלנו עם הERP . | |
|
|
|
|
|
||
|
||||
|
אז אולי תנסו להשתנות? הרי באופן זה, בשונה מחברות רבות בישראל, לעולם לא תגיעו לרווחיות הנשענת על שווקים בחו"ל. למרות שנהניתי מן התגובה של איזי ואף הכרתי חברות כאלו, לא כולם עובדים כך. חברות הדואגות לשמן הטוב לטווח הרחוק ישתדלו להמנע מתבנית זו. למשל החברה בה אני עובד בשנים האחרונות החלה כסטארט-אפ שכאשר ניגש לפילוטים, תמיד הבטיח כמעט תמיד פחות (פיצ'רים, איכות, מהירות אספקה) ממה שידע שייתן בסופו של דבר. |
|
|
|
|
|
|
||
|
||||
|
החברה שלך לא הפסידה במכרזים לחברות שמבטיחות יותר ממה שהן יכולות לתת? | |
|
|
|
|
|
||
|
||||
|
אכן החברה לא קיבלה כל פרוייקט בו רצתה. קשה לי לזכור כרגע מדוע (לא אני ניהלתי וגם עברו שנים). אך בעזרת שמה הטוב1 וטכנולוגייתה העדיפה הפכה היא רווחית אחרי שנתיים ועם תוספת השקעה היא רכשה את המתחרות האמריקניות. 1 המדיניות אותה ציינתי קודם לכן הושפעה מאוד ממצב דומה לשתיאר איזי, אותו חוויתי בחברה קודמת. דברים אלו הופנמו ע"י המנכ"ל בחברה החדשה שהיה חסר ניסיון. |
|
|
|
|
|
|
||
|
||||
|
הרווחיות שלנו מעולה ולאט לאט אנחנו משתלטים על ה-ERP .התכוונתי בעיקר לחברה המיישמת ולדרך ההתארגנות תוך כדי תנועה וברגע האחרון. | |
|
|
|
|
|
||
|
||||
|
איציק ש., בעל הון ואון - בגילך (עשרים שנות חינוך מתחת לחגורה, לא?) בקריירה חדשה כתוכניתן, או כבעלבית? | |
|
|
|
|
|
||
|
||||
|
לא זה ולא זה. | |
|
|
|
|
|
||
|
||||
|
יש שיטת ניהול שמתבססת על ההנחה הזאת (CCPM), לפחות כך ראיתי אותה מיושמת (1). בקצרה, לוקחים את לוחות הזמנים ומקצרים אותם לזמנים לא ריאליים, את כל הזמן ש'נחסך' שמים כחוצצים (Buffer) בסוף כל שרשרת בפרויקט. כך, במקרה הגרוע ינוצל כל זמן החוצץ, במקרה הטוב חלק מהמשימות יבוצעו לפני זמני היעד והזמן יחסך לכל הפרויקט. כשלימדו אותנו את השיטה באחד ממקומות עבודתי המוקדמים (ימי הבועה), המשילו את המשימה ללמידה למבחן, כאשר אם המבחן נדחה בשבוע, נתחיל ללמוד אליו שבוע מאוחר יותר ובסוף נהיה בלחץ זמן בכל מקרה. השיטה עשויה, אם אני זוכר נכון, לחסוך 30% מזמן הפרויקט, אבל היא אינה לוקחת בחשבון (לפחות לא במקרה שאני חוויתי) את השחיקה והלחץ שנגרם לעובדים בכך שתמיד ניצב בפניהם יעד לא ריאלי (1) אני לא מומחה לשיטה ויכול להיות שהישום שלה היה לא מדויק במקרה שאני נחשפתי אליו |
|
|
|
|
|
|
||
|
||||
|
העבודה מתרחבת כדי לתפוס את הזמן שהוקצה לה. | |
|
|
|
|
|
||
|
||||
|
תגובה 86331 | |
|
|
|
|
|
||
|
||||
|
אצלינו ניסו פעם שיטה דומה של איזה גורו ניהול ישראלי לשעבר (נדמה לי שקראו לזה בשם תורת האילוצים או שם מפוצץ אחר). אפילו הביאו תוכנה מפוארת שהתחברה לגאנטטים. באיזשהו שלב השיטה נקברה וחזרו לשיטה הישנה של לסמוך על ראשי הצוותים שהם יודעים מה הם אומרים. | |
|
|
|
|
|
||
|
||||
|
אנחנו מדברים בדיוק על אותו דבר - השיטה שדיברתי עליה יצאה מ- TOC. זה למעשה הרחבה של גולדרט לתיאוריה שלו. אצלנו זה ב'אופק העולם החדש' במקרה או שניסו את השטות הזאת בעוד מקומות? |
|
|
|
|
|
|
||
|
||||
|
TOC, נכון. לא מכיר את החברה שאתה מדבר עליה. אני גם לא בטוח שזאת שטות, על הנייר זה נראה משכנע, רק שאצלנו זה לא הלך. |
|
|
|
|
|
|
||
|
||||
|
מנסיוני רב השנים מה שמתפתח היא תרבות ארגונית בה ידוע לכל שאין שום חשיבות למה שמוגדר כלו"ז של הפרוייקט, מאחר ואף אחד לא מתכוון לעמוד בו ממילא. כמו שאמר דוגלאס אדאמס: I love deadlines. I like the whooshing sound they make as they fly by. | |
|
|
|
|
|
||
|
||||
|
לא יודע על מה אתם מדברים. מנסיוני (יותר מ-10 שנים בפיתוח תוכנה), רוב (בערך 70%) הפרוייקטים עומדים בלוח הזמנים שלהם בלי מאמץ מיוחד (למרות שזוכרים טוב יותר את הפרוייקטים שלא עמדו או שהיה צריך להשקיע מאמץ מיוחד על מנת שיעמדו), ורוב הפרוייקטים בהם היה צריך להשקיע מאמץ מיוחד זה נגרם בגלל הערכות לא נכונות של הפיתוח. הבעיה היא שהרבה מפתחים לא לוקחים מראש מרווחי ביטחון מתאימים ומכפילים מספיק גבוהים. | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |