יום שבת, 23 באפריל 2016

הדרך לאפקטיביות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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