Posts tagged ‘System thinking’

מטריקות בע”מ

לפני כשבוע השתתפתי בקורס של יורגן אפלו בנושא ניהול ומנהלים בסביבה אג’ילית. שם הקורס הוא זהה לשם הספר שהוא כתב Management 3.0.

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

 photo

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

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

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

במסגרת הנושא יורגן הציג טבלה ובה שבע עמודות שמייצגות את הישויות שהארגון מייצר משהו עבורן, וכמו כן 7 פרספקטיבות של המשהו הזה, דברים כגון: זמן, כלים, ערך פונקציונליות ועוד, יורגן ביקש שנמצא KPI’s שונים בשביל למדוד את הדברים הללו.
לדוגמא: מדד לשימוש בכלים מהפרספקטיבה של האינדיבידואל יכול להיות “WTH(What the hell) Per minute” – למי שלא מבין, למדוד כמה פעמים בדקה אומר “מה לעזעזל?” מי שמשתמש בכלי מסוים.

photo

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

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

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

You get what you measure

מה שאנשים אינטליגנטיים עושים, ואם אתם קוראים את הבלוג הזה אתם בוודאי אינטליגנטיים, הם מוצאים דרכים להגיע ליעד הזה, למשל: לייצר באגים.
כשיש הרבה באגים קל לפתור הרבה באגים, לא? הנה קיבלתי בונוס של 150%, יופי!

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

צוותי פיצ’ר – Feature teams

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

component_teamרוב הארגונים שאני פוגש עדיין עובדים במבנה צוותים שמבוסס על מודול או קומפוננט. המונח המקצועי הוא Component team.
כלומר, במצב שבו יש מספר קומפוננטות במערכת, למשל: GUI, BL, SERVER, INFRA אז כל צוות הוא מומחה בקומפוננט מסוים. קלאסי.

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

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

נתחיל מדף חלק – יום 0 של הפרויקט.
יש לנו רשימת פיצ’רים לגירסה הקרובה, חמישה במספר. הפיצ’רים הללו לא דורשים רמת מאמץ זהה מכל הצוותים, יש פיצ’רים שדורשים יותר עבודה ב-Gui ויש כאלה שיותר עבודה ב- Server וכו’. הנה דוגמא: הטבלה מציגה עבור כל פיצ’ר את התפלגות המאמץ באחוזים לפי מודול.

מספר פיצ’ר A B C D
1 20 30 50 0
2 40 20 0 40
3 0 80 20 0
4 50 0 50 0
5 20 0 70 10

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

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

מה האפשרות שרוב הארגונים לא שוקלים (אולי כי הם לא מכירים אותה) לשנות את המבנה של הצוותים כך שלא יהיה מאורגן לפי מודולים אלא לפי איזורים פונקציונאליים, או כפי שקוראים למבנה הזה בשפה המקצועית: צוותי פיצ’ר -  Feature teams.

צוותי פיצ’ר הם צוותים שלא מסודרים לפי התמחות של מודול אלא לפי התמחות של איזור פונקציונאלי, לדוגמא: צוות Security, צוות דוחות, צוות ניהול פריטים וצוות אדמיניסטרציה,כשכל צוות בעצם מפתח התמחות באיזור פונקציונאלי מסוים ולא באיזור טכני מסוים, רגע…בעצם  אני מניח שלמרות שהצוות של הדוחות למשל “נוגע” בכל המודולים, ברוב הפעמים הוא נוגע באותם איזורים בקוד, כלומר בכל זאת ישנה התמקדות טכנית מסוימת.

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

באופן אישי אני לא מצליח להבין ארגונים שלא רוצים לעבוד למבנה כזה, אבל, זה לא הדבר היחיד שאני לא מבין… :)

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

כלים אג’ילים – יש דבר כזה?

לא פעם ולא פעמיים אני נשאל:
“אנחנו מתחילים לעבוד בסקראם (או כל שיטה אג’ילית אחרת) באיזה כלי כדאי להשתמש בכדי לנהל את הפרויקט שלנו?”
וכמעט תמיד התשובה שלי היא משהו בסגנון “מה רע בלוח עם פתקים או כרטיסיות?” או במקרה הגרוע “מה רע באקסל או בכל גיליון אלקטרוני אחר?”  למה אני חושב ככה?

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

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

נסקור את הסיבות לשימוש ב”כלים אג’ילים” שאני נתקל בהן:

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

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

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

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

עקרון חשוב ומנחה במניפסט האג’ילי (עקרון 5) הוא:

Build projects around motivated individuals, give the environment and the tools they need, and trust them to get the job done.

עקרון נוסף חשוב (עקרון 11) הוא:

The best architectures, requirements and design emerge from self-organizing teams

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

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

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

לסיום אני רוצה לצטט משפט מתוך ספר של בס וודה וקרייג לרמן:
If you automate a mess, you will get an automated mess.

רבותי, ההיסטוריה חוזרת.

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

בשנת 1980 שודרה תוכנית ברשת NBC שנקראה
“אם יפן יכולה למה אנחנו לא” – “if Japan can… why cant we”,
בתוכנית בין השאר הוצג דמינג שטען שהבעיה הגדולה ביותר של המוצרים האמריקאים היא האיכות הנמוכה שלהם, האפקט של התוכנית הזאת היה כה משמעותי, שהוא גרם להתפרסמות של דמינג בגיל 80!!! וזאת למרות שהתוכנית שודרה רק פעם אחת. מאותו רגע ועד מותו (1993) דמינג נחשב לאדם שנמצא בחזית התנועה לשיפור האיכות.
למה אני מספר את זה ?
דמינג פרסם מאמרים רבים, בין השאר ישנו מאמר משנת 1982 עם סיכום ב-14 נקודות של העקרונות שלפיהם צריכה להתנהל חברה מסחרית, אותם עקרונות שהוא האמין בהם בשנות ה-50.
מבלי לדון בהן, אני אתרגם אותן כמיטב יכולתי בפוסט הזה, ואגיש לכם אותן כחומר למחשבה.

  1. יש להתמקד במטרות ארוכות הטווח של החברה, לא צריך להתמקד ברווח בטווח קצר, המטרה היא להמשיך להתקיים ולייצר מקומות עבודה.
  2. העולם משתנה, ומנהלים צריכים לשנות את צורת החשיבה בהתאם: עיכובים, טעויות, עובדים לא טובים ושירות גרוע לא מקובלים עוד.
  3. לא להסתמך על תהליכי בדיקות לזיהוי פגמים, תתחילו לבנות את האיכות בתוך המוצר תוך כדי ייצורו.
  4. אל תבחרו ספקים על בסיס תמחור בלבד, תמזערו הוצאות לטווח ארוך ע”י יצירת קשר ארוך-טווח עם הספקים, קשר שמבוסס על אמון ונאמנות.
  5. באופן המשכי וקבוע יש לעבוד על שיפור תהליך הייצור, שיפור אינו מאמץ חד פעמי, על כל פעילות במערכת להשתפר ע”מ לצמצם פעולות לא מועילות ולשפר את האיכות. כל הזמן.
  6. מיסוד ההכשרה. על המנהלים לדעת איך לבצע את העבודה עליה הם מפקחים, ולהיות מסוגלים לאמן עובדים, מנהלים גם זקוקים להכשרה ע”מ להבין את המערכת כולה.
  7. מיסוד מנהיגות. התפקיד של המנהלים הוא לסייע לאנשים לעשות עבודה טובה יותר, ולהסיר מכשולים שמפריעים לעובדים להשלים את המשימות שלהם בגאווה. הבזבוז הגדול ביותר באמריקה הוא אי השימוש ביכולתם של אנשים.
  8. למגר את הפחד. אנשים זקוקים להרגיש בטוחים ע”מ לבצע את עבדות כראוי, לעולם לא צריך להיות קונפליקט בין ביצוע הדבר הטוב ביותר לחברה, ועמידה בציפיות של האדם ממשימתו הנכחית.
  9. הסירו את החוצצים בין המחלקות. צרו צוותים מולטידיסיפלינארים כך שכולם יוכלו להבין את הפרספקטיבה זה של זה. אל תמעיטו בכוחם של צוותים ע”י תגמול עובדים על בסיס ביצועים אישיים.
  10. הפסיקו להשתמש בסיסמאות, תוכחה ושידול. זאת המערכת עצמה, ולא העובדים אשר מייצרת פגמים ופוגמת בפרודוקטיביות, סיסמאות לא ישנו את המערכת, בשביל זה יש מנהלים.
  11. הסירו מכסות אישיות לעובדים. זוהי צורה של ניהול ע”י פחד (Management by fear), נסו מנהיגות במקום.
  12. הסירו חוצצים ששודדים מהעובדים את זכותם לגאווה בעובדתם. הפסיקו להתייחס לעובדים לפי שעה כמו משאבים, הסירו דירוגים של הערכות ביצועים שנתיות לעובדים.
  13. תעודדו למידה ושיפור עצמי לכולם. עובדים והנהלה מלומדים, הם המפתח לעתיד.
  14. תפעלו למען השגת השינוי. הנהלה הבכירה חייבת להוביל את המאמץ באמצעות פעולות, ולא רק תמיכה ודיבורים.

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