7 ההרגלים של אנשי תוכנה אפקטיביים במיוחד (חלק ב)

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

הרגל שלישי: עשה ראשית את הדברים החשובים (AKA איזון בין חשוב ודחוף)

אנשים רבים בתעשיית התוכנה "מכורים לדחוף" (urgent).

עניינים דחופים הם בולטים וברורים יותר.
יש משהו מרגש בלעשות משהו בלחץ זמן.
פתרון דברים דחופים – מוביל להכרה מיידית.
"אני עובד טוב יותר תחת לחץ"

נחלק את סוגי המשימות שיש בידנו ל-4 רבעים:

רובנו, נוטים להשקיע את עיקר זמננו ברביע של הדברים החשובים והדחופים (רביע I).

כמו כן ישנן שיטות שונות לניהול זמן, שרובן מתנהל בד"כ כך:

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

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

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

ההסבר לכך הוא כזה:

השינויים המהותיים ביותר – דורשים בד"כ עבודה ארוכת טווח. שינויים שכאלה לא נוטים להתפס כדבר דחוף.
הדברים החשובים והלא דחופים (רביע II), הם חשובים באותה מידה כמו הדברים הדחופים (רביע I) = הרי שניהם "חשובים". מדוע לתת להם פחות משקל? אפילו:
- הם עשויים להיות חשובים יותר – בשל הטיעון הראשון.
- הם עשויים להיות חשובים יותר – כי גם הרבה אנשים אחרים בארגון מזניחים אותם.
אין מה לדאוג. בכל מקרה אנו נקדיש גם זמן לדברים הדברים הדחופים (רביע III, I). מטבעם, יש להם נטייה להתפרץ ללוח הזמנים שלנו.
כלומר: ההתכוונות לדברים לא דחופים-אך חשובים (רביע II), הוא סוג של "אפליה מתקנת". אם נתמקד בהם – סביר שנגיע לאיזון נכון בין כל הדברים החשובים, דחופים או לא.

ניתן לזכור זאת ע"י הטיפוסים הסטראוטיפיים שמתמקדים בכל רביע:

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

ההחלטה מה לא לעשות היא החלטה קשה יותר מההחלטה מה כן לעשות, אבל לעתים חשובה יותר.

תמיד יהיו דברים שלא נעשה.

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

כשאנו במנטליות של "מה לא לעשות" – אנו מאפשרים לעצמנו לאזן בין דברים חשובים-ודחופים (רביע I), ודברים חשובים ולא-דחופים (רביע II).

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

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

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

עוד כמה המלצות:

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

ההרגל השלישי מתואר בהרחבה בספר של קווי שנקרא First Things First.

הרגל רביעי: חתור לפתרונות Win/Win עם אחרים (AKA החיים הם לא משחק סכום 0)

כאשר יש חוסר הסכמה מסוים, ובסביבה ארגונית יש הרבה כאלו – באיזה פרדיגמת פעולה אתם בוחרים?

אנשים אפקטיביים נוהגים להתנהל בפרדיגמה של מנצח/מנצח (רביע I).

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

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

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

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

אמון ניתן לשפר בעזרת:

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

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

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

קווי מתאר מודל של התפתחות אישית לאפקטיביות, ובו 3 שלבים:

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

ההרגל הרביעי (חשוב "מנצח/מנצח") הוא זה שמכניס אותנו לעולם התלות-ההדדית.

קווי כתב ספר ביחיד עם בנו שמוקדש לנושא. הספר נקרא The speed of trust.

הרגל חמישי: קודם הבן, ורק אח"כ – היה מובן (AKA שתי אוזניים, ופה אחד)

כשמישהו מדבר איתנו, אנו נמצאים באחת מ-4 רמות הקשבה:

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

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

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

אלמנט חשוב בהקשבה אמפתית הוא ניסוח מחדש של דברי האחר, על מנת ש:

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

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

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

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

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

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

הרגל שישי: יצירת סינרגיה (AKA מציאת אלטרנטיבה שלישית)

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

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

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

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

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

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

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

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

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

הרגל שביעי: חדד את המסור (AKA למידה מתמשכת)

ההרגל הזה הוא יחסית טריוואלי: תמיד תמשיך להתפתח.

הלימודים לא מסתיימים באוניברסיטה, לא בחודשיים הראשונים בעבודה, ולא בסמינר שארגן ראש הצוות או ההיא מה HR.

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

"טוב לחטוב את היער הנכון – אבל טוב יותר לעשות את זה עם מסור חד!"

כמה השגות נוספות:

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

אז כיצד הופכים התנהגות – להרגל

הרגל נבנה מתהליך בן כמה שלבים:

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

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

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

לדוגמה ארוחה במסעדת מקדונלדס לילדים:

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

דוגמה נוספת:

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

דוגמה קונקרטית לתחום שלנו:

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

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

כדאי שהטריגר יהיה פשוט וברור.

הפרס יכול להיות חיצוני ("שבחים מאחרים") או פנימי (אתם שבעי-רצון מהתוצאה).

סיכום

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

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

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

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

שיהיה בהצלחה!

7 ההרגלים של אנשי תוכנה אפקטיביים במיוחד! (חלק א)

מעט ספרי ניהול יכולים להתהדר בקונצנזוס מוחלט של התעשייה לגביהם: כאלו שכולם מעריכים, מצטטים, ונוטים לחזור אליהם כ reference. אחד מהספרים המעטים הללו הוא הספר The 7 habits of Highly Effective people מאת סטפן קווי (Stephen R. Covey).

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

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

נתחיל בשם הספר: "7 ההרגלים של אנשים אפקטיביים במיוחד", אני רוצה לתת כמה דגשים:

ציון מספר (לא גדול) בכותרת של ספר או מאמר זו דרך מצוינת לקסום לאנשים ולעודד אותם להתעניין בו: "היי אני לא מגילה בלתי נגמרת! כולה x חתיכות לא גדולות של תוכן. תוכל אפילו לעבור עליהן בזריזות להתרשמות מהירה" – הוא מסר שמקל מאוד על תחושת הקלות לעיכול של החומר.

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

הרגלים

שימו לב: כ 40-50% מהפעולות שאנו עושים מידי יום הן כתוצאה מהרגל ולא החלטה [א], הרגל הוא כמו החלטה אוטומטית עבורנו, ואם ההרגל הוא טוב – אזי "נזכה" בהחלטות אוטומטיות טובות (כנ"ל ההיפך).

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

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

אפקטיבי

לצורך הפוסט אשתמש במינוחים הבאים:

יעיל (efficient) – משתמש במינים של משאבים בכדי להשיג תוצאה רצויה (מצב טוב).
אפקטיבי (effective) – משיג תוצאה רצויה, בעזרת פעולה מחוללת שינוי (מצב טוב יותר!)

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

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

זה אירוע יפיפה בו מצליחים לשנות את כללי המשחק ולעשות בפחות מאמץ (שוטף) – הרבה יותר.

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

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

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

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

הרגל ראשון: נקיטת יזמה (AKA[ב] התמודדות עם נסיבות מכשילות)

משמעות ההרגל של "נקיטת יזמה" עשוי להישמע דיי פשוט: טוב יותר לנקוט יזמה מאשר להתנהג בצורה ריאקטיבית.

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

האם אנחנו ריאקטיבים או פרואקטיביים? – ניתן לבחון זאת בעזרת השפה בה אנו משתמשים.

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

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

הערה: פה אני נכנס לנושא מאוד "רך" / שאינו מוגדר היטב ושאינו טיפוסי לבלוג. נכון.

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

הבדל מהותי בין חשיבה ראקטיבית לפרואקטיבית הוא ייחוס המגבלה:

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

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

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

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

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

"וואי…. אתה גאון"
"אתה לא מבין שום דבר"
"הוא תמיד מאחר"
"ב sometech – הוא יודע יותר טוב מכולם. נקודה."

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

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

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

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

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

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

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

מכאן, יש מחזור של העצמה:

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

הבהרה: כשאני מדבר על מעגל השפעה גדול יותר, הכוונה למרחב גדול יותר של דאגות שאני מאמין שאני יכול להשפיע עליהן.

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

הרגל שני: "התחל בחשיבה על סוף-דבר"(AKA התמקדות בתוצאות, לא במעשים)

"דבר מאוד לא אפקטיבי, הוא לכרות בצורה יעילה (efficient)… את היער הלא נכון."
אנשים אפקטיביים הם אלו שמכוונים לעשות את הדברים "הנכונים".

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

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

שם ההרגל במקור הוא Begin with the End in Mind.

הספר מציין מחקר של בחור בשם Dr. Charles Garfield (מאוחר יותר הוציא את הספר "Peak Performers") שעקב אחרי ספורטאים ואנשי-עסקים מצטיינים. כמעט כל המצטיינים ידעו לתאר את "תמונת הניצחון שלהם". כלומר: הייתה להם מטרה ברורה ומוגדרת – שעזרה להם להתמקד.

העיקרון שהספר מנסה להעביר כאן הוא שיצירה גשמית, מתחילה קודם כל ביצירה תודעתית-אישית. ("Mental creation precedes physical creation")

"לעבור עוד שנה במקום העבודה ולעשות מה שהמנהל שלי מבקש" היא לא מטרה ממוקדת.

מקור

מה אם כן היא המטרה הממוקדת?
– רק אתם תוכלו לומר.

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

הקבלה כמעט ישירה לעצה הזו היא גישת ה Lean Startup:
ב SCRUM נהוג שמשימה מוגדרת באופן הבא: "משתמש מסוג X הייתי רוצה ללחוץ על כפתור ולהזמין חברים למערכת".
ב Lean Startup על משימה להיות מוגדרת כך: "אנו מעריכים שיכולת הזמנת חברים למערכת תוסיף y% לכמות המשתמשים החדשים המצטרפים כל חודש. נוסיף כפתור שיאפשר למשתמש להזמין חברים למערכת".

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

ע"פ Lean Startup, אם התוצאה הצפויה לא הושגה שוקלים, בכל שלב, אם לעשות עוד איטרציות של שיפורים ואף שינויים מהותיים – עד שמשיגים אותה.

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

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

סיכום

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

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

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

תגובות והערות יתקבלו,כרגיל, בשמחה!

שיהיה בהצלחה!

—-

[א] – ע"פ הספר "The Power of Habit" – ספר מעניין שבמקרה, או לא במקרה, שייך לקבוצה לא קטנה של ספרים פופולריים שעוסקים בהרגלים.

[ב] קיצור של Also Known As. השימוש בו נעשה כמחווה לסדרת הטלויזיה Jessica Jones – בה אני צופה בימים אלו. הסדרה היא בהחלט הפתעה נעימה.

ביג דאטה: מחסני נתונים, אגמי נתונים, ומרכולי נתונים – סדר בבלאגן

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

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

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

כאשר אנו רוצים לבצע ניתוחים מקיפים על הנתונים במערכת האופרטיבית – יש בעיה אמיתית פשוט "להריץ שאילתות על בסיס הנתונים האופרטיבי":

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

Data Reservoir, השם הקודם (או הפחות נפוץ) של Data Lake. מקור: O'Reilly Radar.
יש הטוענים ש"מאגר נתונים" הוא מונח מדויק יותר, אך אין ספק ש "אגם נתונים" הוא המונח הפופולרי.

התמודדות עם בסיס נתונים אופרטיבי "גדול מדי"

מה עושים?

בתור שלב ראשון אפשר לייצר Replica של בסיס הנתונים האופרטיבי – ולהריץ עליה את השאילתות.
אבל:

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

השלב הבא בהתפתחות הוא ליצור מחסן נתונים (Data Warehouse, או בקיצור DWH או DW) – בסיס נתונים בו מאוחסן עותק של הנתונים מבסיס הנתונים האופרטיבי (ייתכן שב delay מסוים, נאמר שעה עד יממה) – אבל עם החופש ליצור סכמה שונה, ואינדקסים שונים.

מקור: הבלוג של James Serra

ה ETL (קיצור של Extract, Transform, and Load) הוא התהליך ששלוף נתונים מבסיס הנתונים האופרטיבי, ממיר אותם לסכמה של בסיס הנתונים האנליטי וטוען אותם לשם.

כעת אנו יכולים לבצע שאילתות אנליטיות "כבדות" על ה DWH. הן:

ירוצו מהר יותר – כי מבנה הנתונים / האינדקסים מותאמים לשאילתות.
לא ישפיעו על הביצועים או ה Stability של בסיס הנתונים האופרטיבי (!Hurray)

בנוסף ב DWH מקובל:

לשמור נתונים לטווח ארוך – וכך לשחרר את המערכת התפעולית מלאחסן אותם.
נאמר: ה DWH יכיל נתונים עשר שנים אחורה, בעוד בסיס הנתונים האופרטיבי – נתונים של חצי שנה אחרונה בלבד.
עבור הנתונים שיש הרבה מהם – שומרים לרוב סיכומים, ולא את כל הנתונים המקוריים שהיו במערכת התפעולית.
למשל: במקום סכום של כל עסקה – שומרים רק את סכום העסקאות היומי, מה שיכול לצמצם את כמות הנתונים בסדרי-גודל, ובהתאמה להקל על השאילתות האנליטיות (שרצות עכשיו על פחות נתונים).
יש לזה מחיר: אנו מאבדים נתונים – היכולת להבין את הפיזור המדויק של סכומי העסקאות, למשל.
להשתמש במהדורה מעט שונה של Database Server שמתאימה בצורה טובה יותר לצרכים אנליטיים. למשל: Vertica, Greenplum, Sybase IQ – הם בסיסי נתונים שמיועדים לשמש כ DWH.

מהפיכת הביג דאטה

בעשור האחרון התחוללה מהפיכה של ממש בכל עולם הנתונים:

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

הגידול בכמות הנתונים לחץ על מערכי ה DWH הקיימים, וטכנולוגיות ה NoSQL/BigData החדשות – יצרו הזדמנות לשינוי.

מקור: הבלוג של James Serra

ה DWH היה בשלב זה כבר פתרון מקובל, אך היו לחצים שהלכו וגברו:

חלק מהנתונים החלו לנהל בבסיסי נתונים לא-רלציונים – שלא נתמכים / נתמכים בצורה חלקית ע"י כלי ה ETL המסורתיים. מצבים של אי-עקביות בנתונים (inconsistency) וסכמה דינמית (למשל ב Document Databases) הפכו את מלאכת ה ETL ל"גיהינום" עבור ה DBAs.
כמות הנתונים במערכת האופרטיבית גדלו בצורה דרמטית – מה שגם הקשה על ה ETL להתבצע בזמנים טובים ו / או להישאר מעודכן לכל סוגי הנתונים שנוספו.
ברגע שה DWH לא מעודכן בכל הנתונים האחרונים, מערכות ה BI הן כבר פחות טובות – והמשתמשים הזקוקים לנתונים מתחילים למצוא "דרכי-מעקף" על מנת להשיג ולנתח את הנתונים שלהם.

בעזרת אכסון "אינסופי" וזול – נוצר מודל חדש לאיסוף וניתוח נתונים: אגם הנתונים (Data Lake):

כל המידע נאסף, בצורה גולמית וללא עיבוד ("as-is"), מהמערכות התפעוליות – ונשמר על גבי שטח האכסון האינסופי (Hadoop, S3, או Azure Data Lake).
- נתונים שהמערכת התפעולית לא יכולה להמשיך ולשמור (משיקולי ביצועים) – נשמרים ולא נזרקים.
- נגמר המירוץ של ה DBAs לעקוב ולהתאים את ה ETL לשינויי הסכמה במערכת התפעולית. המנגנון החדש יודע לאסוף את כל הנתונים.
מאוחר יותר, כשיהיה צורך מעשי בנתונים – ינקו אותם, יסכמו אותם, וינתחו אותם, באותו הרגע.
- ה Stack של Hadoop – נבנה ממש לצרכים שכאלו.

תהליך העברת הנתונים ל Data Lake נקרא ELT (קיצור של Extract, Load…. ואז Transform), כאשר שלב ה Transform הוא לרוב ארגון מאוד בסיסי של הנתונים, כמו סידור שלהם בתיקיות / המרת פורמט הקבצים לכאלו שקל יותר לסרוק.

ב Hadoop למשל, נהוג להמיר את הנתונים (שמגיעים לרוב כהרבה קבצי JSON או CSV) לאחד מהפורמטים הבאים:

Avro – פורמט כללי, שדוחס את הנתונים ומאפשר לחלק קובץ ל-2 מבלי לקרוא את כולו (כי הנתונים שמורים במבנה ידוע). זו תכונה חשובה ל Map-Reduce.
Parquet – פורמט ששומר את הנתונים בצורה Columnar ומאפשר לקרוא מהדיסק את עמודות ספציפיות של הנתונים. הדחיסה כאן היא אפילו גבוהה יותר, כי הדמיון בין ערכים באותה עמודה – הוא באופן טבעי גבוה יותר.

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

תהליך ELT. מקור: www.ironsidegroup.com

ה Data Lake הוא בעצם גישה הפוכה לגישת ה DWH:

מהגישה החרוצה: ניקוי, ארגון, וסיכום הנתונים ואז שמירה שלהם מה DWH – המאפשרת שליפה קלה.
לגישה העצלה: שמירת כל הנתונים המלוכלכים, raw, עם כפילויות וחוסרי התאמות ב Data Lake. ניקוי וסידור הנתונים יתבצע – רק ברגע שרוצים לתשאל אותם.

מקור: Martin Fowler

מי שבקיא ברזי ה Agile יודע בוודאי שדחיינות ועצלות הם Best Practices. זה כנראה נשמע רעיון טוב לאמץ את הרעיונות החשובים הללו בעולם הנתונים.

מי שהלך רחוק עם רעיונות ה laziness ב Data Lake שלו, עלול לגלות שהוא יצר לעצמו ביצת הנתונים (Data Swamp): מצב בו הנתונים ב Data Lake כ"כ מבולגנים ו"מלוכלכים" – שהערך מניתוחם לא מצדיק את העלות הגדולה בניקוי והסידור שלהם בדיעבד. הנתונים הם שם, שמורים ב Data Lake – אבל בעצם לא משתלם להתחיל ולהתעסק איתם (במקרים מסוימים – כמובן).

סידור נתונים בשלב מוקדם הוא לעתים רבות זול ופשוט הרבה יותר מסידור שלהם בדיעבד. למשל:

הסכמה וצורת שמירת הנתונים השתנו עשרות פעמים בתקופה – ואין לנו דרך לדעת בדיוק ממתי השינוי. שמירת שדה "version" על הנתונים במקור – היה יכול להיות השקעה קטנה שתחסוך זמן רב בעתיד.
נתונים שחסר איזה מפתח או נתון לקשר ביניהם. אם היינו מוסיפים זאת במקור – זו הייתה תוספת קטנה מאוד, אבל כיום צריך להתחיל להריץ יוריסטיקות וניתוחים – רק על מנת לקשר את הנתונים שהיו עד לא מזמן "במרחק נגיעה".
שמירת נתונים בצורה אחידה, למשל שמירת תאריכים בפורמט אחיד (האם 1/4/12 זה אפריל או ינואר?) – או הקפדה על שמירת ה timezone הרלוונטי. נתונים שלא נשמרו כך – בדיעבד קשה לנקות ולסדר.
שמירת פרטים על המערכת ממנה מגיעים כל מקבץ-נתונים – יכול לסייע מאוחר יותר לקבוע את האיכות שלהם, או לשפר אותה.
לאסוף "חוסרי-נתונים". יש סיפור על חברת טלקום שבנתה מערך Big-Data מרשים, אבל שכחה לאסוף אינדיקטור על ניתוק שיחה (שלא נשמר בבסיס הנתונים האופרטיבי – אני מניח). אחרי שנה+ של צבירת נתונים, היא לא הייתה מסוגלת לנתח בעיות במערכת – כי היה לה רק "מידע חיובי".
נקודה זו מתייחסת גם לנתונים שהמערכת האופרטיבית "תיקנה", למשל – כאשר היא קובעת "ערך מקסימום" לסוג נתון כלשהו, עדיין עשוי להיות מעניין מה היה הערך המקורי.
כדאי לעקוב ולתעד את השמירה של מידע רגיש (מספרי טלפון של משתמשים, למשל) – כדי שיהיה ניתן להגן עליו. לא כל אנליסט עסקי אמור להיות מסוגל לגשת לנתונים הללו.

הנה דוגמה לארגון מקובל של נתונים בתוך ה Data Lake:

ה RAW הם נתונים שהגיעו מהמערכות התפעוליות ללא כל עיבוד, כאשר ה Gold הוא storage של הנתונים לאחר עיבוד מסוים. ה Work הוא אזור העבודה של ה Data Scientists, ויש אזור Sensitive אליו מעבירים את כל הנתונים הרגישים (שמחליטים לשמור. לפעמים פשוט מטשטשים אותם).

נוטים לרוב להבחין בין אנשי BI / Data Analysts שעובדים מול נתונים נקיים יחסית ("Gold") ל Data Scientist – שמבינים טוב יותר את הבעיות השונות של נתונים (חוסר עקביות, פורמטים לא-אחידים, סתירות), ויכולים אף לכתוב custom code בכדי "לנקות נתונים קשים".

DWH ו Data Lake הם לא רק גישות הפוכות: בד בבד – הן גם גישות משלימות.
יש נתונים שנכון יותר לאחסן ב DWH, ויש כאלו שב Data Lake, ועצם קיום שני הכלים זה-לצד-זה – מאפשר מנעד רחב יותר של יכולות.

חלוקת הנתונים בארגון

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

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

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

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

מקור: datamartist.com

מתוך כך צצו, עוד בימי ה DWH – "מרכולי הנתונים" (Data Marts), שהם סוג של DWH קטן וממוקד.

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

ישנן עוד כמה שאלות הנוגעות לקשר בין ה DWH ל Data Marts. למשל: האם קודם יוצרים את ה DWH ואז גוזרים ממנו Data Marts, או האם נותנים ליחידות Data Marts ואז אוספים אותם ליצירת DWH ארגוני? אם ישנם נתונם שנכונים ל-2 Data Marts, האם להחזיק אותם ב Data Mart שלישי או ב DWH? וכו'…

מקור: datamartist.com

באופן דומה ל DWH, גם ב Data Lake צפוי שיהיו אזורים מיועדים ליחידות / רמות עסקיות שונות. כל אחד – והצרכים הייחודיים שלו. מרטין פאוולר, למשל, קרא להם "Lakeshore Data Marts".

מה ההבדל בין Data Mart ל "Data Silos" – מאגרי מידע שיחידות בארגון שומרות לעצמן ולא משתפות עם אחרים?

אני מניח שאלו הבדלים של נקודות מבט: החצי המלא והחצי הריק של אותה הכוס.

סיכום

כמה Best-practices שכדאי לשקול בעבודת ארגון הנתונים:

איסוף וארגון נתונים:

להשתדל לאסוף ל Data Lake נתונים ברזולוציה של אירועים בעלי משמעות עסקית (קנייה, הצעת מחיר, רישום, וכו').
- זו הרזולוציה שלרוב יהיה מעניין לנתח.
לשלוח את הנתונים ל Data Lake לא כשהם ממש Raw, אלא לאחר עיבוד-קל ("Medium-Rare"):
- להשתדל "לשטח" לתוך האירוע נתונים חשובים שיהיה קשה לקשר אותם מאוחר יותר. למשל: באירוע הצימוד בין נהג ונוסע, מעניין לשמור את המיקומים המדויקים שלהם באותו הרגע, כפי שהם ידועים לשרת. חלק הקוד שמפיק את אירוע-הנתונים יכול לספק נתון כזה בקלות יחסית, אבל להגיע לתובנות כאלו בדיעבד – זה יכול להיות קשה, ואפילו לא מדויק. הבנה עמוקה של הביזנס – היא כמובן המפתח להחלטה.
- להוסיף metadata שבסבירות גבוה יכול להיות שימושי בעתיד: גרסה של מבנה הנתונים, מה לא נשמר ומאיזו סיבה, ציון תיקונים שנעשו בנתונים או ציון נתונים רגישים, וכו'
להחליט ע"פ הצורך אילו נתונים רוצים להכין / "לנקות" ב Data Lake בצורה יזומה ("Golden Data" או "tidy data") – כדי שיהיו זמינים לניתוח מהיר. אלו לרוב הנתונים שמתארים את המדדים הביצועיים החשובים של הארגון.
לנסות ליצור סדר מובן ב Data Lake, ולא להפוך אותו ל Data Swamp. איזה סדר? מה שמתאים לצרכים הייחודיים של הארגון שלכם.
- אנשים בתחום מדברים על תכון ה data pipeline (תהליך ניהול הנתונים) ו / או ה data lineage (המסלול והתחנות בו עוברים הנתונים לאורך חייהם).
(שנוי במחלוקת): נסו להוסיף נתונים ל Data Lake ב Pull (כלומר: ע"פ צורך ניתוח ממשי), ולא ב Push (כלומר: כי הם שם).
- היתרון: יהיה לכם הרבה פחות "זבל" ו"בלאגן" ב Data Lake.
- החיסרון: לא תוכלו לחקור נתונים שלא שמרתם.

שימוש בכלים:

"לשחק" בציר היכולות (ה trade-offs) בין Data Warehouse ובין Data Lake.
"לשחק" בציר היכולות בין ארגון מידע ריכוזי (DWH או Data Lake מרכזי) לארגון מידע מבוזר ע"פ צרכים (Data Marts או אזורים ספציפיים ב Data Lake).

בסופו של דבר, אלו הם כלים: הם לא "טובים" או "לא-טובים". הם פשוט שימושיים – למקרים וצרכים מסוימים.

שיהיה בהצלחה!

—-

לינקים רלוונטיים

מרטין פאוולר על אגמי נתונים – http://martinfowler.com/bliki/DataLake.html

KD Nuggets על אגמי נתונים – http://www.kdnuggets.com/2015/09/data-lake-vs-data-warehouse-key-differences.html

הכנס השני לארכיטקטורת תוכנה (30 לנובמבר – 1 בדצמבר)

בסוף החודש הקרוב, 30 בנובמבר – 1 בדצמבר, יתקיים בהרצליה הכנס השני לארכיטקטורת תוכנה.

הכנס מאורגן ע\"י IASA ואילתם.

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

ILTAM, היא קהילה מקצועית, רחבה יותר, המורכבת בעיקר מחברות הייטק גדולות ומבוססות (לא רק חברות תוכנה נטו: אלתא, 3M, וצה\"ל למשל – הם חברים) במטרה לקדם ולשתף ידע.

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

היום ראשון מורכב מהרצאות. הנה התכנית:

ביום שני מתקיים Tutorial בהדרכתה של Rebecca Wirfs-Brock (שהגיעה לארץ במיוחד, אני מניח), בנושאי ארכיטקטורה באג\'ייל ו Quality Attributes בפרט (הנה פוסט שפירסמתי בנושא, אם אתם רוצים לקבל מושג במה מדובר).

האם כדאי לבוא?

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

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

אני נותן הרצאה על מיקרו שירותים (עדיין לא החלטתי בדיוק איך להעביר את הנושא…). אם אתם מגיעים – קפצו לומר שלום!
קצת אחרי ייתן הרצאה יונתן ממן, שכתב כאן פוסט אורח בנושא – ממש לאחרונה.
הנה אתר הכנס: http://conference70.wix.com/sw-architecture
בטופס ההרשמה שבאתר, ניתן לקבל הנחה אם מזינים את המילה \"Presenter\", בסעיף של קבוצת שיוך (אופס, אני מקווה שבאמת היה מותר לי לספר את זה…).

שיהיה בהצלחה!

ליאור

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

בשנת 1975, נכתב הספר האלמותי "The Mythical Man-Month" ע"י בחור בשם פרדריך ברוקס (שכדרך אגב היה מנהל טכני בכיר בחברת יבמ, בימים בהם הייתה בחזית הטכנולוגיה). הספר זכה להערכה רבה בקהילת התוכנה, ונחשב עד היום כבעל מקום של כבוד בספריה של אנשי תוכנה "רציניים" [א].

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

הוא העלה בספר שלוש טענות חשובות:

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

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

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

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

לקוח של התוכנה – ניצב בפני ממש אותן ברירות.

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

רק עוד דקה…

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

ישנן משימות צפויות, שכבר עשינו אותן כבר כמה פעמים (לרוב: "משימות copy-paste") – אותן ניתן פחות או יותר לחזות בצורה טובה. משימוש שלא נעשו בדיוק כמותן לאחרונה – קשה הרבה יותר להעריך.
יש שוני גדול בין משימה x במערכת קטנה, לביצוע משימה x במערכת גדולה. ביצוע משימה במערכת גדולה יותר – היא תובענית משמעותית יותר. (חשבו על פאזל, למשל: מה יותר קל? להוסיף עשרה חלקים לפאזל חצי-מורכב של 50 חלקים או לפאזל חצי-מורכב של 500 חלקים?)
יש שוני גדול בין מורכבויות של סוג התוכנה. למשל: מערכות הפעלה נכתבת הרבה יותר לאט מקומייפלר, שכתב הרבה יותר לאט ממערכת עסקית / מערכת ווב.
לרוב: המתכנים לא יצליחו להקדיש יותר מ 50% משעות העבודה לכתיבת קוד / טיפול בבאגים. מפתיע?!
1. זמן בדיקות – הוא החלק שנוטים להעריך בצורה חסרה ביותר הוא בדיקת התוכנה ותיקון שגיאות. "יהיה בסדר!".
הערכות הזמנים שלנו – משתפרות ככל שאנו מתקרבים למועד תחילת המשימה הספציפית.
בגרסה מעט אחרת: הערכות זמנים בתוך הפרויקט משתפרות ככל שהוא מתקרב לסופו.
לסיכום: ככל שאנו מעריכים זמנים מאוחר יותר – אנו עושים זאת טוב יותר. (הערכות בדיעבד – הן הכי טובות!)
את זה אני כותב מהזיכרון (לא מצאתי בספר. אולי זה מספר אחר?!): בשקלול של דיוק וצמצם – המתכנת הוא זה שעדיף שיעשה את ההערכה.
למשל: אם מנהל מעריך "12 יום" – המפתח יקפיד בד"כ לעמוד בהערכה. אם נשאל את המתכנת עצמו, הוא יאמר "8 ימים" – וישיג את התוצאה הרצויה בתשעה – וזה מה שעדיף לפרוייקט.
כל זה עוד לפני העובדה שמנהל יש אחד – והוא מהווה צוואר בקבוק, ומתכנתים יש יותר.
אווירת לחץ, באופן דיי עקבי – פוגעת בפריון.

עוד תובנות מקובלות (אין לי רפרנס ברור) של ימנו:

קביעת מסגרת זמן היא חשובה מאוד בכדי להתמקד במטרה ולא להתבזר [ג].
כלומר: אם נותנים למפתחים "את כל הזמן שנדרש" בכדי להשיג תוצאה – הם יהיו משמעותית פחות יעילים מאשר כאשר יש להם מסגרת זמן, ידועה שעוד אנשים בוחנים אותה (רפרנס קרוב: חוק פרקינגסון). אפילו אם מסגרת הזמן הזו הוגדרה ע"י המתכנתים עצמם.
חוק ה"90-90" (הומריסטי) : תשעים אחוז מהקוד – ייכתב בתשעים אחוז מהזמן. יתר עשרת האחוזים מהקוד – ייכתבו ב 90 אחוז נוספים מהזמן. בקיצור: הערכת זמנים נועדה להערכת-חסר.

פרויקטי תוכנה בתקופתנו

האם פרויקטים כיום מצליחים יותר מהזמן בו כתב ברוקס את ספרו?

ע"פ המקור הזה – ניתן אכן לראות שיפור לאורך השנים.

הנתונים שהציג ברוקס בספרו – היו בכלל מזעזעים: רק 2% מפרויקטי התוכנה של ממשלת ארה"ב הצליחו, 3% הצליחו לאחר שעשו בהם שינויים. כחצי מהם פשוט לא הועברו ללקוח.

למה ניתן לייחס את השיפור?

ע"פ גרסה אחת – ניתן לייחס אותה למהפיכת האג'ייל (נושא שכתבתי עליו הרבה בבלוג). למשל:

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

גורם אחר שיש מייחסים אליו את השיפור, הוא התמסדות מקצוע "מנהלי הפרויקטים", כדוגמת תואר ה PMP של ארגון PMI. זה הארגון שיצר את "Project Management Body of Knowledge", והסמיך יותר מחצי מליון מנהלי פרויקטים ברחבי העולם.

תובנות של "עולם ה Enterprise"

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

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

הנה למשל תובנה נפוצה ראשונה: מודל שנקרא Cone Of Uncertainty.

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

ככל שהפרויקט מתקדם, ניתן להניח שהערכת זמנים שתינתן תהיה מדויקת יותר. למשל: בשלב ה detailed requirements (יש פה איזו הנחה סמויה על מבנה waterfall) – הטעות היא כבר לא גדולה מפי-2.

מה המודל בעצם נותן לנו?

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

זווית אישית

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

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

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

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

חזרה להערכות זמנים "קלאסיות":

עקרון בסיסי בביצוע הערכות "בשיטות הקלאסיות" הוא לבצע את הערכות ב-2 שלבים: הערכות אילו משאבים (מומחיויות) יידרשו למשימה (QA, מתכנת שרת שמכיר מודול Y, מעצב גרפי, וכו') ואז הערכה כמה זמן כל אחד נדרש.
אני מניח יש כאן הנחה סמויה שהמשאבים הם "טיפשים", או לפחות חסרי-מודעות מספקת לגבי הפרויקט – ולכן זקוקים למנהל פרויקט "שינהל אותם". התהליך הוא לתחקר את העובדים על הקשרים בין המשימות שלהם ולסדר להם אותם בצורה "אופטימלית" ע"פ מודל סמי-מתמטי (הוא לא ממש "מתמטי" כי הוא בנוי על קירובים גסים למדי).

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

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

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

משפחת כלים: Expert Estimation

בה יש מומחה (מתכנת / ראש צוות) שמכיר את העבודה היטב – וההערכות הזמן מתבססת על ההערכה הסובייקטיבית שלו.

Bottom-Up – מומחים (מתכנתים/ראשי צוותים) מעריכים את כל המשימות בפרויקט, ואז מחברים את ההערכות הללו (עם באפרים ופאקטורים) לתמונה אחת. החיבור של ההערכות נעשה באקסל או ב"תוכנה לניהול פרויקטים" – קשה לעשות אותו בלי איזה כלי. וריאציות של טכניקה משתמשות במונח בשם WBS (קיצור של Work Breakdown Structure) – כאשר החלוקה היא למשימות, או RBS (קיצור של Resource Breakdown Structure) – כאשר הבסיס לחישוב הוא המשאבים (תחומי-מומחיות) להם זקוקים. כלומר: החישוב הוא לא כמה זמן המשימה תיקח, אלא לכמה אנשים נזדקק (פה 2 אנשי QA ושם עוד אחד – אז סה"כ שלושה).

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

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

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

משפחת כלים – Analogy-Based-Estimation

בה הבסיס הוא להשתמש במידע קיים מהעבר – בכדי לבסס את ההערכות הזמנים לעתיד.

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

Function Points – סופרים את מספר ה APIs שיש לממש, מספר המסכים ב UI, מספר הכפתורים במסך – או כל דבר אחר שמאמינים שיכול לייצג, בידיעה שיחידה כזו "לוקחת בערך זמן x לפתח". למשל: אם מסך ב UI הוא שבוע – אז עשרים מסכים הם חמישה חודשים (ואולי אז מעגלים לשישה חודשים – ליתר בטחון).

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

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

למרבה ההפתעה הן מפורמלות ע"י מסמכים אקדמים וע"י כל מיני סטנדרטים בתעשייה (COSMIC הוא כמובן ISO/IEC 19761:2011, או IFPUG שהוא ISO/IEC 20926:2009, וכו') – מה שעלול להעלות את השאלה כיצד גופים רציניים שכאלו לא פסלו אותם מכל-וכל. התשובה: א. כנראה שלעתים זה הכי-טוב שיש. ב. כנראה שנוח לגופים הללו להמשיך להתעסק בזה.

משפחת כלים: גם וגם…

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

אחסוך מכם את ההתנסות הזו – ואומר שיש כל מיני טכניקות שמנסות לעשות על מיני ממוצעים בין 2 סוגי הערכות ולהיות גם "יחסית מדויקות" וגם "לא יקרות".
דמיינו אותן לרגע בעצמכם… – וזהו כנראה ה State Of The Art של עשרות שנות מחקר באקדמיה (סליחה על הביקורת הלא-מרומזת…, אולי קצת הגזמתי).

ההערכות בעולם ה Agile

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

עקרון: לא מנסים להעריך את כל הפרויקט מראש

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

מוטיבציה:

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

הערה: יש גישה שכן מנסה לבצע הערכה גסה של הפרויקט בכללותו: מנסים להגדיר את כל ה backlog items "בערך באותו הגודל" וכך אם רוצים שכל ספרינט מתקדמים ב (נאמר) 5 פריטים, ובכל הרשימה יש עוד 30 פריטים – ניתן לומר בצורה גסה שעוד שישה ספרינטים יסתיים הפרויקט (סוג של Function Points estimation).
הערכות מסוג זה הן מאוד לא מדויקות (במיוחד כאשר באמת מה שחשוב הוא הערך למשתמש – וצפויים שינויים גדולים ב backlog תוך כדי התקדמות) – וחוזרות לטווח הטעות של The Cone of Uncertainty.

עיקרון: מנהלים רשימת פיצ'רים – מבלי להציב אותן על לוח-שנה

כותבים רשימה ארוכה של כל היכולות שאנו רוצים במוצר (product backlog) – וממיינים אותם ע"פ סדר חשיבות / סדר בניה נכון של הפרויקט.
בתחילת כל ספרינט (שבועיים עד ארבעה, בד"כ), שולפים משימות מה product backlog ומעריכים אותן. הן נכנסות לרשימה שנקראת ה Sprint Backlog. ממשיכים בתהליך הערכות הזמנים עד שיש לנו מספיק משימות מוערכות (נניח: 5 שבועות עבודה, אם אנו עובדים בספרינטים של 4 שבועות).

עכשיו מתרכזים בספרינט ומבצעים את המשימות.

תוך כדי הספרינט מרעננים את ה product backlog (לא נוגעים ב sprint backlog) בעקבות תובנות שאנו רוכשים במהלך הזמן.

מוטיבציה:

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

וריאציה: Planning Poker היא טכניקה שהכרתי קודם מעולם האג'ייל – ורק אח"כ למדתי שהיא טכניקה "קלאסית".

Planning Poker בפעולה! בפרויקט אחד אפילו רכשנו את "הקלפים המקוריים של CRISP". אם רוצים להעריך 31 שעות – מניחים על השולחן 3 קלפים (20+10+1). בחפיסת הקלפים שלנו – היו מספרים לא עגולים (7, 21, 44 אך ללא 10 או 5) – בכדי להזכיר לנו שהערכות הן לעולם לא מדויקות.

עיקרון: מניחים שהזמן של המתכנתים אינו מוקצה רק לכתיבה של קוד

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

הרציונל: לבני-אדם הרבה יותר קל להעריך רצף אירועים פשוט ("יום מושלם") על פני המציאות המורכבת ("יום מלא הפרעות").

במהלך כל ספרינט לומדים מה הפער בין "היום המושלם" ל"יום המעשי". הפער נובע מזמן שהמפתחים מקצים לדברים אחרים, כמו הטיות שלהם בהערכה. זה לא משנה. לאורך כמה ספרינטים ניתן ללמוד שצוות x מספיק בין 50% ל 60% מהמשימות שהעריך – ועל כן קובעים לו Velocity של 55%. כלומר: אם בספרינט יש 20 ימי עבודה – נעריך שבפועל יש לנו ספרינט של "11 ימים מושלמים". נבצע כיול של המציאות של הצוות הזה. ה Velocity הוא לרוב אינדוודואלי לשילוב צוות+פרויקט, ויש ללמוד אותו כל פעם מחדש.

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

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

מוטיבציה:

מציאות – בואו לא "נשלה את עצמנו".
הבנה שהערכה היא מלאכה לא מדויקת ולא-פשוטה, ועל כן נקל את המתכנים שלנו (= חשיבה ב"ימים מושלמים", נקראים לעתים גם "Story Points", הגבלת גודל התכולות אותן מעריכים).

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

מילת סיכום אישית

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

למשל:

פעמים רבות: התחייבנו על תכולה ולוחות זמנים חודשים קדימה (ולכן הוספנו "באפרים"). לא מיסדנו "חוזה אג'ילי" עם ההנהלה או הלקוח.
התעלמנו מהרעשים שיש למפתחים ביום העבודה – ובמשך שנה+ המופע בו צוותים לא סיימו 70% מתכולת הספרינט חזרה על עצמה כל ספרינט, וללא תיקון – כאמת עצובה שאין לה פתרון.
שימוש בבאפרים ואומדני "Function Points" שונים ברמת ההנהלה הזוטרה (במקום לבצע הערכות ע"י מפתחים).
מנהל פרויקטים שמרכיב תוכנית שבועיים קדימה: מה עושה בדיוק כל אדם בכל יום (ואז זו תוכנית שלמתכנת יש קשיים לזוז ממנה).
וכו'….

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

שיהיה בהצלחה!

——

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

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

אם יש לכם מנוי ל"הארץ" שווה לקרוא: http://goo.gl/82IwZb – צוות מדענים בינלאומי שבחן 100 מחקרים בפסיכולוגיה לא הצליח לשחזר את תוצאות 64% מהם: "הקורא הממוצע צריך ללמוד שאין להתייחס לשום מחקר בודד כאל המלה האחרונה"

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