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

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

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

מה תפקידו של Engineering Manager? איך מעריכים Engineering Manager?

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

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

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

האידאל של מנהל הנדסי הוא לא “מנהל טכנולוגי” ולא “מנהל אנשים” – אלא חיבור של השניים: המנהל שמשלב את שני הגורמים הללו: הטכנולוגי/מקצועי והתפעולי/ניהולי. אציג מודל “אופטימלי” של מנהל מאוזן בשני הקצוות, שאֲדַמֶּה אותו למטוס עם שתי כנפיים מאוזנות. המודל הזה הוא לא דמיוני, ויש לא מעט מנהלים כאלו – אבל אלו לא כולם. אח”כ נמשיך למנהלים בעלי נטייה לצד-אחד, שהם פחות “מאוזנים” – ואולי זקוקים ל”פיצויים”.

ננסה לענות על שתי שאלות חשובות:

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

צלע	התנהלות בקצה הנמוך	התנהלות בקצה הגבוה
מומחיות מקצועית (בחברה טכנולוגית, וככל שקרובים יותר לעשיה / למהנדסים, קשה מאוד להגיע להישגים משמעותיים ללא הבנה עמוקה של המקצוע: הנדסת תוכנה)	* מוביל לא פעם דיוני Design למקומות לא טובים, או לסירוגין: מרחיק עצמו מהחלטות מקצועיות חשובות. נסמך על אחרים שייקחו את ההחלטות במקומו. * “נאלץ” לשחרר פיצ’רים באופן שמסבך את המערכת, מוסיף לה מקרי קצה ו/או כפילויות. הוא והצוות לא נוהגים להשאיר קוד “נקי יותר מכפי שהיה לפני שעברו דרכו” * מאשר PRs עם קוד הזקוק לשיפור, בלי להעיר דבר. * לו היה חוזר להיות מתכנת – היה מהמתכנתים הפחות טובים בצוות.	* “מציל” לא פעם Designs מטעויות גדולות / כיוונים שגויים. * מצליח לאזן בין שחרור “פיצ’רים” למערכת פשוטה, עקבית, ושקל להבין / לעקוב אחריה. * מעלה לדיון ולשיפור פרקטיקות לא טובות ברמת הקוד – ומצליח להוביל לשיפור מתמשך. * מפגין הבנה עמוקה בבעיות טכנולוגיות מורכבות. סמכות מקצועית כלפי הצוות, ובכלל.
הדרכה מקצועית (המנהל לא רק מקצועי בעצמו, אלא נמצא במערכה תמידית ואקטיבית לשפר את המקצועיות של חברי הצוות שלו – זו עבודה שדורשת השקעה רבה) הערה: מכל הצלעות, זו כנראה הצלע שהכי נפוץ להזניח. המנהדסים הם משמעותיים ויקרים, ואי-השקעה אמיתית בהם תוביל את הארגון לבינוניות. הערה: כלל האצבע שיש להימנע מניהול ישיר של יותר מ-6 אנשים נובע מהצלע הזו: כמעט בלתי אפשרי לנהל וגם להדריך מקצועית יותר מ 6 אנשים.	* לא יודע לאבחן את הפערים המקצועיים של אלו שהוא מנהל. מסתמך על “סקר” שנתי כדי לתת פידבק לעובדים – ולא פידבק שוטף. * פיתוח עובדים שנתי מסתכם בשליחה לקורס או גיוון בפרויקטים. אין פידבק קונרטי ומתמשך. * עובדים תחת המנהל המקצועי לא משתפרים – בראייה של הצוותים הסובבים אותם. תלונות על חברי צוות חוזרות על עצמן לאורך זמן. * “סומך” על המנדסים במאה אחוז, ולא מאתגר אותם. הם ילמדו מניסיונם האישי, או מאנשים אחרים בארגון – לא מהמנהל. * מנהל שיודע הרבה, אבל לא מעניין אותו כ”כ ללמד ולקדם אחרים. “שומר את הידע אצלו”	* נותן פידבק משמעותי ותכוף לעובדים תחתיו – פידבק שהם יודעים להעריך כמשמעותי. * פניות למנהל המקצועי לגבי תפקוד העובדים שלו – מסתיימות בדרך כלל בשביעות רצון לאורך זמן (או בהבנה מדוע הפנייה לא נכונה) * מעלה מסביבו את הרף המקצועי, בתחום הנדסת תוכנה. * מפגין תשוקה לקדם את המצוינות המקצועית, תורם הרבה להשכלה, דיונים, והכשרה של עובדים.
הבנה מוצרית (רכיב קריטי ביצירת אימפקט ויעילות אמיתית של הצוות)	* “Yes Man” של אנשי המוצר. ממלא הוראות. * מפספס היבטים לא הגיוניים ברמת המוצר/ביזנס/משתמשים בפיצ’רים – ולא מצליח לעצור / לשנות אותם בזמן הפיתוח.	* מאתגר את אנשי המוצר בעניינים של מוצר / ביזנס / לקוחות – ומוביל למוצר טוב יותר. * יוצר שותפות אמיתית ועמוקה עם אנשי המוצר שעובד איתם (DevProd)
מנהיגות (מילה גדולה, אך יש לה בסיס. הצלע הזו היא לרוב זו שמובילה את המנהל לשלב הבא בקריירה שלו – בעוד שאר הצירים הם התומכים)	* נקבר תחת השוטף / ריאקטיבי – לא יוזם מהלכים משמעותיים. * הצוות שתחתיו ב Engagement בינוני או נמוך כלפי הארגון ומטרותיו. ציניות ותסכול אינם נדירים. * עסוק ב”הגנה על הטריטוריה” ושמירת סטטוס-קוו שהולך והופך לפחות רלוונטי לארגון.	* המנהל ההנדסי מפנה זמן מהעבודה השוטפת להכנה של מה שידרש לשוטף של התקופה הבאה: ניהולי, טכנולוגי, תהליכי. * הצוות מחובר למטרות הארגון וזה ניכר בעבודתו. * עושה סדר היכן שחסר, מתווה כיוון היכן שאחרים מבולבלים או מתקדמים לכיוון שגוי מבלי להבין. * שואל שאלות עמוקות, ומאתגר את הארגון.
ניהול אנשים (יש אנשים, והם לא תמיד יודו בזה: אבל הם זקוקים לאבא ולאמא – וזה במקרה המנהל ההנדסי)	* אנשים בצוות מתפספסים (למשל: תסכול, קשיים שלא נפתרים, בעיות בתוך הצוות) וזה מתבטא בתפקוד נמוך של הצוות / עזיבה / טיפול ע”י HR / מובילים שאינם המנהל ההנדסי. * כל חברי הצוות הם באותה הרמה: “בסדר” או “מצוינים”, אין בולטים לטובה ואין חלשים. * עסוק בלרצות את חברי הצוות הרבה יותר מאשר לאתגר ולדרוש מהם.	* הצוות במוטיבציה גבוהה, מעריך את המנהל, ועובד טוב בינו לבין עצמו. מעט עזיבות. * אנשים חזקים בולטים מהצוות ומוכרים בארגון, אנשים חלשים – מטופלים. * מנהל בהצלחה אנשים מגוונים, עם אופי וסגנון שונה.
האצלת / פיזור סמכויות (האימפקט של המנהל ההנדסי תמיד יהיה חסום ביכולת שלו לייצר מכפילים (multipliers). אנשי הצוות הם המועמדים הטבעיים והעיקריים להיות המכפילים)	* המנהל ההנדסי שולט ביד רמה בכל מה שקורה. קולו נשמע בכל דיון, וכולם מחכים לו / מנסים להשיג אותו, או לסירוגין: המנהל ההנדסי מצטרף לישיבות ולא ברור אם הוא יותר מאורח. קולו לא נשמע. * אין כמעט נושאים שמקודמים בצורה עצמאית ע”י חברי צוות או לסירוגין: יש הרבה כאלו – אך הם לא מתנהלים היטב. * המנהל ההנדסי תמיד עסוק. שבועיים חופש שלו – מסתמנים כפגיעה משמעותית בעבודה השוטפת.	* רוב הנושאים בצוות מובלים ע”י חברי צוות, ורוב חברי הצוות מובילים משהו – תוך שרובם מצליחים, בעוד המנהל ההנדסי יודע בדיוק מתי להתערב ובאיזו מידה. הדבר מאפשר למנהל ההנדסי להוביל יותר נושאים – ממנהלים שלא עושים זאת. * המנהל ההנדסי זמין לדיונים חשובים: הוא לא נעול back to back בישיבות, אלא תמיד יש לו איזשהו זמן פנוי למה שחשוב.
תפעוליות / ביצועיות (ללא תקשורת טובה, ארגון אישי, והתנהלות ארגונית נכונה – כל העבודה של המנהל ההנדסי והצוות שלו – עשויים לרדת לטמיון)	* אין אמון במנהל ההנדסי שמה שהבטיח עומד להתקיים (זמנים / איכות). ישנם פספוסים רבים של תיאום, תקשורת, ותכנון שנוגעים צוות שלו. * תלונות על חוסר עירוב של גורמים / צוותים אחרים במקומות הנחוצים. * לממשקים (צוותים אחרים) ולמנהל שמעל – אין נראות טובה על מה שקורה בצוות, איך הוא מתקדם, ומה האתגרים העיקריים שעומדים לפתחו. * למנהל יש נטייה להמשיך ולהצעיד נושאים / את הצוות בפרויקטים ארוכים, בלי לשים לב שהמטרה השתנתה, או שניתן “לגלח” עבודה משמעותית.	* מצב הצוות והפרויקטים שהוא מוביל מתוקשרים בצורה ברורה ושוטפת לכל הממשקים מסביב. קל לאנשים מסביב להבין מה האתגרים / בעיות, מה נעשה, ומה יעשה – ולמה. * למנהל יש רצף של Deliveries שמוסכמים בארגון. צובר עם הזמן עוד ועוד “קבלות ביצוע”. * המנהל ההנדסי קשוב לנושאים שהוא מוביל, יודע לזהות ולהגיב לשינויים – לא פעם גם לפני שיש הכרה רחבה שזה המצב.

המודל הזה אינו מושלם:

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

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

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

סיכום

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

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

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

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

איך טווטיר / פייסבוק / Whatever – נתנו בשנים הראשונות ערך, שנראה לא רחוק מהערך היום, אבל עם שבריר מהעובדים שיש להם היום?

לתופעה הזו יש כמה הסברים פשוטים:

• כשהארגון הוא קטן – מתמקדים ביכולות (“פיצ’רים”) שהם Low-hanging fruits, מעט השקעה – והמון ערך. הפיצ’רים הללו נגמרים די מהר – ונשארים רק פיצ’רים שדורשים השקעה גדולה יותר.
  • לחברה צעירה (מעט לקוחות/רווחים) לא משתלם להשקיע בפיצר’ים עם ערך לא גבוה. פיצ’ר שיוסיף עוד 1% הכנסות – לא שווה יריקה. כשהחברה גדלה – פיצ’ר שיוסיף עוד 1% הכנסות יכול להיות שווה שנות עבודה רבות, ובצדק.
• מערכות תוכנה נוטות להסתבך ולהיות קשות יותר להרחבה ככל שהן גדלות / הזמן עובר. אם בשנה הראשונה של החברה פיצ’ר חדש צריך להשתלב עם 4 פיצ’רים קיימים, לאחר כמה שנים כל פיצ’ר חדש צריך להשתלב עם 20-30 או יותר פיצ’רים קיימים – ויש הרבה יותר עבודה כך שלא יפריעו / יסתרו זה את זה. כתבתי על כך בפוסטים: איך לנצח את הסיבוכיות? ו סיבוכיות: מקבלים את זה בחינם.
• ביצוע (Execution) – הופך לקשה יותר ככל שהארגון גדול יותר:
  • ארגון גדול הוא מורכב יותר, וכמות האנשים המעורבים בכל פיצ’ר היא גדולה יותר. נדרשים יותר תיאומים ותקשורת.
  • צמצום פוקוס / פיזור הפעילות: ארגונים גדולים נוטים לפזר את כוחם על יותר נושאים, ולרוב נגררים לפיזור-יתר, שלא היה בזמן שהיו קטנים. פיזור היתר גורם לפרויקטים להתמשך, לא לעמוד בלוחות הזמנים – ואז תחת לחץ של עמידה ביעדים => להסתיים בצורה רדודה יותר, מה שיוצר חוב טכני / תפעולי – שמאט עוד את המערכת.

בפוסט הזה אתמקד בבעיות הביצועים של ארגונים גְּדֵלִים: ארגונים גדולים, אם שרדו, כנראה הצליחו להתמודד (לפחות חלקית) עם בעיות הביצועים שלהם. ארגונים גְּדֵלִים, החווים זו בפעם הראשונה – יכולים להגיע “להיתקע”, ואולי אף לא לצלוח יפה את הצמיחה.

צמצום פוקוס – איך זה קורה?

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

• גודל הארגון (למשל: מספר האנשים) – מספק תחושת יכולת. כל אותם דברים שאמרנו לעצמנו “אנחנו ארגון קטן, אין לנו זמן לעשות את זה” – עולים עכשיו על השולחן לדיון מחודש.
  • חלק מהדברים הללו, אולי אפילו חלק גדול מהם – עדיין לא נכון לעשות, אבל הכשל הלוגי הוא הצמדה של הדחייה לטיעון “אבל אנחנו רק 20 אנשים”, וברגע שהפיתוח כולל כבר 50 אנשים – התנאים השתנו ויש לנהוג אוטומטית אחרת.
  • בכל זאת, אנחנו רוצים “לצ’פר” את האנשים הטובים שהביאו אותנו לכאן ולעזור לקדם דברים שהם מאמינים בהם. בכל זאת – הם צודקים: עכשיו יש לנו יותר אנשים.
  • “התמורה לא מצדיקה עדיין את ההשקעה” – הוא קישור לוגי נכון יותר, שיכול להיות תקף גם בחברה של 500 או 1000 עובדים.
• כשהארגון גדול, כבר אין קיום (כמעט) לפרשים בודדים. מעטים הם האנשים / המשימות שאדם יוכל לבצע אותן לבדו – מבלי להזדקק לעזרה, בניגוד לארגון קטן.
  • למשל:
    • איש ה Security לא יוכל לקדם דברים משמעותיים – בלי השקעה משמעותית של מפתחים.
    • איש ה Performance שבא לשפר את המערכת – לא יוכל להתקדם הרבה בלי השקעה משמעותית של מפתחים.
    • איש ה Training – לא יוכל לקדם תוכניות הדרכה בלי מעורבות / השקעה משמעותית של המפתחים הטובים שמבינים בעניין.
  • בכל שלושת הדוגמאות הבאנו לארגון “מומחה שיקדם נושא” – אבל שכחנו להעריך את ההשקעה הנוספת הנדרשת מהפיתוח בכדי לקדם ברצינות את האג’נדה. התוצאות הן לרוב:
    • פיזור הכוח על יותר חזיתות ממה שנכון לארגון.
    • אי קידום רציני של האג’נדות – מה שמבאס את מי שאמור להוביל אותן, ואת מי שקיווה מהן לשיפור ממשי. פגיעה במורל ואולי אף יותר: בהרגל החשוב לסיים את מה שהתחלנו => מקור לעוד התדרדרות ב Execution.
  • אותו מקרה בדיוק קורה גם ביוזמות שהן nice-to-have, למשל:
    • מעבר לטכנולוגיות / ספריות חדשות שנראות טובות יותר (אך הארגון יכול “לסחוב” בסדר עוד כמה שנים בלעדיהן) – הערכה ראשונית היא שמפתח ל x שבועות יבצע את המעבר – אך הוא “מפריע” לפיתוחים אחרים ואף דורש שיתוף פעולה שלא תוכנן.
    • השקעה בתשתית שהציקה לנו והגבילה אותנו, כך שלא תגביל בעתיד (אך מחיר ההשקעה הוא גבוה מדי לתמורה) – לאחר שמתחילים את ההשקעה לפעמים “תחושת החיוניות” של השינוי יורדת – אך לא מרגיש נכון / קשה להפסיק באמצע, וכך ממשיכים גם כאשר החשיבות נראית פחותה.
    • הקמת בלוג / ארגון כנסים / יוזמות חברתיות / וכו’ – אנו נוטים להעריך בחסר את המחיר האמיתי של היוזמה בשעות מפתחים בפועל + קשה מאוד להפסיק אותן בפועל כדי לא לאכזב את האנשים הטובים שהתמסרו להן.
  • תופעות הלוואי העיקריות של “פרשים בודדים” שנדרשו לעזרה מכוח העבודה העיקרי הן:
    • התעכבות בפרויקטים – וגם בפרויקטים הקריטיים לארגון.
    • שחיקה של אנשים, בלי שהם יודעים לתאר הרבה פעמים מדוע: הם רוצים לעזור, היוזמות השונות נראות להן הגיוניות – אבל ה context switch, ואי קיום תחושת ההתקדמות שהם רגילים לה – שוחקים.
• ריבוי תהליכים שטרם הגיע זמנם – כולם יודעים שארגון לא יצליח לגדול בלי תהליכים ונהלים טובים הבנויים ל Scale, אבל לא פעם תהליכים שנדרשים לארגון של 2000 מושתתים על ארגון של 500 עובדים, ותהליכים המתאימים לארגון של 500 עובדים מושתתים על ארגון של 100 אנשים. משלמים היום על צרכים עתידיים – כמו משפחה ששוכרת דירה בת 6 חדרים כאשר הילד הראשון נולד…
  • דוגמאות נפוצות הן:
    • נהלים אחידים ונוקשים ברחבי הארגון, כאשר יחידה לא מסוגלת להתאים אותו לצרכיה – גם כאשר הדבר גורם לתקורה ניכרת.
    • תהליכים “למופת” – היכן שלא נדרש: “צריך כבל USB? הגש בקשה – קבל אישור של המנהל שלך ומנהל ה IT ואז תקבל ביום המחרת”. כבל USB אנחנו לא צריכים הרבה, אבל תהליכי Design, קוד רביו, ושחרור לפרודקשיין גם הם יכולים להסתבך מתוך היגיון שעדיין לא מצדיק את עצמו.
• כל הדוגמאות הנ”ל גרומות לארגון להיות אטי, לדרוש יותר תקשורת / תשומת לב / פעלתנות – בכדי להשיג אותו הדבר.
• פיזור הכוח על מספר רב של חזיתות – נותן את אותותיו:
  • הפרויקטים מתארכים ולא מסתיימים בזמן
  • אנשים נשחקים יותר – כי הם צריכים לעשות יותר בכדי להשיג תוצאה דומה
  • העדיפות בפועל של הפרויקטים הקריטיים יורדות: המפתח המוביל בפרויקט החשוב ביותר בארגון עוזר קצת ליוזמה X, מעדכן את הסביבה שלו לתשתית החדשה, עונה על כמה סקרים, משתתף בקבוצת חשיבה וממלא אחר כמה נהלים חדשים. לכאורה כל אלו בעדיפות שנייה – אך בפועל כל הפעילויות הללו נעשות על חשבון הפרויקט הקריטי ביותר בחברה: כלומר הן הפכו לעדיפות העליונה.
• במקביל: ההנהלה בארגון גדול יותר מנותקת מהפרטים והשטח – ולא מבינה מה מתרחש. תוצאות שליליות אפשריות הן:
  • תחושה שאנשים פחות משקיעים – וצריך לדרבן אותם יותר. דרישה “לחזק כוחות – ולעמוד ביעדים” – לרוב תוביל לתוצאה צפויה, ולא רצויה: ירידה באיכות / בדיוק / ובסגירת הנושאים.
  • ההנהלה בעיקר רואה עמידה / אי-עמידה בלוחות הזמנים (מה שקל למדוד) ורואה פחות ופחות דיוק ואיכות (מה שקשה למדוד, במיוחד מגבוה).
  • התוצאה הטבעית היא ירידה באיכות במקומות הפחות נראית (חובות טכניים) => מה שגורם לאיטיות מצטברת ולמעגל העצמה של הבעיה.
    • הצוותים בשטח לא משקפים עד-הסוף את האיכות היורדת – אבל נאלצים לשלם את מחיריה בהתנהלות השוטפת – מה שפותח להם חזית נוספת לעבודה, ומפזר את הכוח של החברה על מרחב גדול אפילו יותר של פעילויות: התמודדות עם חובות טכניים שאינם על השולחן.
  • בארגון מפתחת שחיקה, תסכול, וציניות = מה שמדרדר עוד את היעילות של הארגון, ופוגע עוד ביכולת של ההנהלה להבין בדיוק מה קורה כאן…
• רוצים להוסיף עוד קצת שמן למדורה? שלחו את ראשי הצוותים שלכם להדרכה על “ניהול זמן”. זה בטח עומד לפתור את הבעיה!
  • קביעת “שעות ללא פגישות” הן וריאציה מוצלחת מעט יותר – אך עדיין לא פוגעת בבעיה העיקרית: ריבוי החזיתות שיש להתמודד איתן.

האם באמת מדובר בבעיית פוקוס?

ביצועיות (Execution) מושפעת ממספר גורמים בארגון: מעורבות (Engagement), כישרון, אפשור (Empowerment) וכו’. פגיעה בכל אחד הנ”ל – יפגע ביכולת ה exection. אם הארגון היה בסדר בכל הדברים, והוא בתהליך גדילה – פיזור הפוקוס הוא המועמד הסביר ביותר לתאר רגרסיה ב Execution. בואו ננסה להציב עוד כמה מאפיינים של בעיית פיזור הפוקוס, בכדי לאשש שאכן בה מדובר:

• פרויקטים הולכים ומתארכים (הערכות הזמנים), בד בבד עם פרויקטים שפחות ופחות עומדים בזמנים. כאשר צוות נדרש להרבה חזיתות – אחוז הזמן שהוא משקיע בפרויקט העיקרי – הולך ופחות.
  • שערוך של שעות העבודה נטו על קוד / דזיין ביום – יכולות לעזור לזהות ירידה בפוקוס. קושי: יש להתחיל בשערוך כשהמצב עוד “טוב”.
• יעדים לא מושגים, או שמתברר בדיעבד שלא הושגו: חשבנו ששיפרנו חוב טכני / חווית משתמש – אבל חודשים אח”כ מתברר שהתוצאה לא הושגה – ואולי יש לחזור ולהשקיע באזור.
  • כשאנחנו מפזרים את הפוקוס – אנחנו יכולים פחות להקפיד שאכן הדברים נסגרו. כשיש פרויקט אחד שהוא עיקר תשומת הלב שלנו – יותר קל וסביר שנסגור דברים “עד הסוף”.
• מאבק עקוב מדם על משאבים (כלומר: אנשים) – הרבה צוותים שמרגישים שאין להם את כוח האדם שהם זקוקים לו בכדי להתקדם / להשיג את היעדים. ש”אם רק היינו מקבלים עוד 2 מפתחים – הכל היה מסתדר”.
• עבודה קשה ו/או היכולת לסיים דברים היא המדד העיקרי להערכת עובדים, בפועל (ולא למשל: עבודה מצוינת וחכמה). זה אומר ש:
  • אנשים כנראה באמת עובדים קשה, וזה יכול להיות סימן שלא עובדים כ”כ יעיל.
  • המנהלים כבר לא מסוגלים להיות בפרטים, ולהבין את העבודה שנעשית – ונאלצים לבצע הערכת עובדים ע”פ “מי נשאר עד מאוחר בערב / מתלונן יותר על הקשיים”.
• אי אפשר להשיג את אנשי המפתח (ראשי צוותים, Tech Leads, וכו’) להתייחסות על נושאי-הליבה. היומן שלהם סגור 8:00 עד 8:00 וניתן להשיג אותם רק בטווח של כמה ימים ל”איזו חצי שעה”.
  • חשוב שאנשי-מפתח יהיו זמינים לדברים החשובים ביותר. אם הם לא – הם ייגרמו לעיכובים מתגלגלים ובעייתיים מאוד – דווקא בפרויקטים הקריטיים.
• לא ברור בארגון מהם הפרויקטים החשובים ביותר. כל אחד חושב שהוא “הכי חשוב” או שמסכימים ש”כולם חשובים” => אף אחד לא מקבל באמת עדיפות => אין תעדוף אפקטיבי.
• צוותים מסוימים משלמים על חוב טכני משמעותי, ולא תמיד שנגרם בגללם. לא אמירות כלליות (שתמיד יהיו; כל פרויקט שרק נגמר “סוחב” חוב טכני כלשהו) – אלא בזבוז זמן ניכר, שקל למדוד ולהעריך.

סיפור לדוגמה הוא שיטת ה prioritization של חברת פנדורה – שהתפרסמה כמודל לחיקוי. השיטה מציגה מנגנון תעדוף ע”פ תקציב (budget). כל stakeholder / איש-מוצר מקבל “תקציב” (נניח $100) של פיתוח – אותו הוא יכול להקצות ל”פיתוחים” לפי ראות עיניו. לכאורה זה מאוד הוגן, נוח, ומסיר חיכוכים – כל אחד מצביע לפי הבנתו, בלי צורך להתווכח בדרך לקונצנזוס. מצד שני: אין מנגנון שווידא ש stakeholders מושכים לאותו הכיוון, לאותה האסטרטגיה. לכאורה יש אפשור שבשתיקה למשוך לכמה כיוונים שונים, בו זמנית, בפיזור מאמץ “by design”. יותר גרוע: כל stakeholder לעצמו עלול “לפזר סיכונים” ולהשקיע בכמה יוזמות – כדי שלפחות יזמה אחת “שלו!” – תצליח. המנגנון בעצם מאפשר להשקיע בעשרות יוזמות במקביל, בלי תיאום, ועם סיכוי הולך וקטן להשיג ערך משמעותי. פנדורה כבר בדעיכה, ולא נחשבת דוגמה ללמוד ממנה. אין לי ידיעה אם זה מה שהוביל לנפילתה – אבל זו בהחלט נראית לי דרך מעולה לאבד פוקוס!

מה אפשר לעשות?

“טוב. אולי יש לנו בעיית פוקוס. אז בואו נתפקס יותר טוב, לא?”

זה נשמע קל, אבל זה לא – במיוחד שהארגון גדל:

• כדי להתמקד ב 10 יוזמות, הארגון דחה כבר 40 יוזמות אחרות. קשה להפנים שלא התמקדנו מספיק, במיוחד כאשר:
  • הארגון הצליח וגדל – “והגיע הזמן קצת ‘לשחרר’ ולעשות יותר דברים”.
  • מצטרפים לארגון עוד ועוד אנשי-מפתח שמעלים נקודות נבונות – היכן לארגון יש חוסרים, ו”חשוב” להשקיע ועכשיו. בשביל זה גייסנו אותם – לא?

המפתח לפוקוס בארגון גָּדֵל הוא:

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

המלצה היא לתת למשימות הארגוניות החשובות שם גדול כמו “Wildly Important Goals” (בקיצור: WIG). שם גדול שלא ניתן להתעלם ממנו. הארגון צריך להתמקד בכמה משימות סופר-חשובות שכאלו בצורה עמוקה. השם גם יגרום לביקורת פנימית – אם המשימה אינה באמת חשובה ומשמעותית עד כדי-כך.

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

אמורים להיות מעט מאוד WIG – בהם אנחנו מתמקדים. (תזכורת למתודולוגית ה OKR, בה יש לקבוע 3-5 יעדים של החברה – ולא יותר. חברות המתחילות לנהל רשימות ארוכות של יעדים, נחשבות כחוטאות למתודולוגיה). מכאן:

• האם ל WIG יש את כל המשאבים (האנשים) כדי לעבוד ביעילות מרבית? אם לא – שקלו לצמצם / לדחות יעדים אחרים, בכדי לאפשר לו להתקדם מהר יותר. אנחנו רוצים לשים על כל WIG כמה שיותר משאבים, כל עוד זה יעיל – ולהתקדם בו כמה שיותר מהר.
• אם יעדים מתעכבים – אל תקבלו את המציאות הזו! אל תלחיצו אנשים לעבוד שעות נוספות! העדיפו:
  • לצמצם את ה scope של היעד – כך שתשיגו את היעד המעודכן – מוקדם/מהר יותר.
  • לצמצם יעדים אחרים – אם ניתן להציב עליו עוד כוח עבודה.
    • פחות יעדים = דבר טוב. פחות תלויות והפרעות הדדיות (שלא תמיד אנו מודעים להן).
  • לפצל את היעד לשני יעדים: שלב א’ משמעותי, ואז שלב ב’ משמעותי.
    • בלי קשר לעמידה ביעדים: אם ניתן לעשות זאת – עשו זאת בהקדם. כל “loop” שסגרתם מוקדם יותר ייתן לכם פידבק עד כמה הוא באמת מצליח / משמעותי – ואתם רוצים ללמוד את הדברים האלו, בעיקר ב WIGs – כמה שיותר מוקדם!
    • כלל מומלץ הוא “כלל 90 היום” – לא יהיה WIG ארגוני שזמן העבודה שלו יותר משלושה חודשים. אם יש – פצלו אותו / הפחיתו scope. לא ניתן לתוצאות קריטיות לחברה להתעכב ולא נסכים שזמן גדול מדי אנו לא יודעים אם ההשפעה שצפויה מהן הושגה.
• הרשו לעצמכם, ביתר קלות, לסרב ליוזמות של אנשים חרוצים, טובים, ואהובים. אנחנו רוצים לתגמל, לחבר (to engage), ולהוקיר את דעתם של האנשים שעובדים למען הארגון – אך חשוב להבהיר שקידום יוזמות “nice-to-have” ברמה הארגונית – היא לא דרך לעשות זאת. הרבה חזיתות יכולות להיפתח בכדי לרצות אנשים טובים. האנשים טובים – אך הנזק אותו הנזק.
• הערה: אנשים שעובדים על יעד משמעותי וברור, שהם מבינים שהוא כזה – יהיו לרוב יותר פרודוקטיביים ומחויבים מאנשים שביקשו מהם “להשקיע מאמץ” – ולעבוד שעות נוספות / קשה יותר.

איזו גישה מרגישה יותר נכונה?

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

מצד שני, גישת ה Parallelize אומרת שנשיג את היעדים שלנו מאוחר יותר. וכנ”ל לגבי למידה מכל יעד – יגיע מאוחר יותר. אם מרגיש שגישת ה Parallelize היא ניהול סיכונים נבון יותר (“לא לשים את כל הביצים בסל אחד”), דווקא כאשר מדובר ב WIGs – גישת ה Maximize Focus היא מסוכנת פחות: אם יש WIG שלא עובד – נגלה את זה מוקדם יותר, וזה יותר חשוב: ללמוד ולהתכוונן מחדש – איך בדרך אחרת, להשיג את היעד הכל-כך חשוב הזה.

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

עבדתי פעם בארגון שהתכונן לצמיחה גדולה, והקים 10 צוותים של 2-3 עובדים כל אחד. כמה מהם – עבדו ללא ראש צוות (שעדיין לא גויס). החשיבה הייתה “איך בונים את הארגון בחשיבה לטווח ארוך”, אך קיבלנו הרבה צוותים בלי “כוח-אש משמעותי”, הרבה ראשי צוותים חדשים בו זמנית, ומכיוון שכל צוות עצמאי – הכנסנו לעבודה הרבה משימות בחשיבות משנית. נראה שהיה טוב בהרבה להקים 5 צוותים משמעותיים – ולגזור מהם בהדרגה צוותים נוספים: למשל, ברגע שהחלטנו שהגיע הזמן לצוות נוסף – להקדים אותו כבר עם 5-6 אנשים (מתוך צוותים קיימים). זה מורכב יותר מבחינת קשר המנהל-עובד, אך זה הרבה יותר בריא לארגון ככלל.

עוד נקודות:

• ליצור תרבות של דיון מתמיד ב WIGs שלנו: האם הם נכונים? מספיק משמעותיים? אנחנו משקיעים בהם את כל מה שאפשר?
  • תרבות כזו מייצרים ע”י דוגמה אישית של מנהלים, וע”פ פרגון אמיתי למי שיוצר דיון איכותי בנושא (חשוב לבדוק, גם אם מסקנת הדיון היא: “בעצם הכל בסדר”).
• מה עושים עם פרויקטים שאינם WIG? איך לא נפגע המורל של מי שלא עובד על WIG – אך עובד על דברים חשובים אחרים? נסו להפוך כל מאמץ ל WIG, או לפחות ל WIG-like: צמצום ה scope להכרחי ביותר הניתן ופוקוס להצלחה. למשל: אם יש בעיה מסוימת – אל תקימו יוזמה לפתור אותה לגמרי: הקימו יוזמה להביא את המצב ל “good enough” – ואז להמשיך ליוזמה הבאה. יהיה קל יותר לחבר את האנשים על היוזמה שהם עושים משהו משמעותי, ולא מבזבזים רגע מיותר. כמו ב WIG.
• יוזמה שראיתי פעם הייתה לצבוע פרויקטים בצבעים:
  • כחול = WIG. “חשוב בטירוף!”. לשם הולך כוח האש העיקרי. כמטאפורה: “כיבוש האי XYZ”.
  • צהוב = Sustainability – “תיקון דליפה בספינה” כדי שנוכל להגיע ליעד (“האי XYZ”). אפילו אם זה לא הפרויקט העיקרי – מובן שזה חשוב ונדרש בכדי להצליח ב WIG.
  • לבן = למידה / POC – פרויקטי גישוש שנחיצות כל אחד מהם אכן בספק – אך מהם יצמח ה WIG הבא “איסוף מודיעין” או “מחקר מדעי לקראת הדור הבא”, לצורך העניין.
  • הצבעים עוזרים להעביר את המקום האסטרטגי של כל פרויקט בבהירות – ולעזור לארגון לכוונן את עצמו נכון יותר לכל פרויקט. למשל: מובן יותר לנסות להימנע שאיש בפרויקט כחול ישקיע זמן בעזרה לפרויקט צהוב – מבלי שזה ייחשב חוסר-קולגיאליות. פרויקט לבן יכול להימנע / לדלג על נהלים – וכך להיות יעיל יותר.
• celebrate scope reduction – כפי שמחיקת קוד הוא דבר שחוגגים (למרות שמישהו השקיע וכתב את הקוד הזה באהבה, פעם) – גם צמצום של Scope הוא דבר לחגוג ולשמוח איתו.
• אחריות ברורה בהחלט – לכל WIG חשוב שיהיה Owner ברור. קפטן שחייב לספק את המשימה. ניסיון (לפזר אחריות) – לרוב נגמר באסון.
  • חשוב שיהיה גם Executive Owner מחויב, בעל יכולת לקבל החלטות משמעותיות. Executive Attention הוא משאב חשוב – שגם אותו צריך לספק ל WIG.
• אם צוות משקיע ביותר מ 2 WIGs בו-זמנית, כנראה משהו לא בסדר. Context Switch הוא “מס” לא רק על תהליכים במערכות הפעלה.

סיכום

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

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

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

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

---

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

• How (and Why) to Stop Multitasking

בחברות שבהן האתגר העיקרי הוא Hyperscaling – הגיוני ונכון שתרבות ה DevOps תהיה המפותחת והעיקרית. בחברות מוצר (רוב חברות התוכנה?) דווקא הגיוני לשים דגש רב יותר על תרבות ה DevProd – כי משם יגיע ה Impact, אבל נראה שזה לא מה שקורה.

אם אתם עובדים בחברת מוצר, חשבו: כמה פעמים אתם שומעים בחודש את המונח “DevOps” וכמה “DevProd”? האם היחס משקף את יחס הכאבים / הפוטנציאל בין השניים?

מהיכן מגיע יותר waste? מחוסר תקשורת / שיתוף פעולה בין מפתחים לאנשי Operations, או בין מפתחים לבין אנשי מוצר?

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

מדוע זקוקים לתרבות של שיתוף פעולה עמוק בין פיתוח (Dev) למוצר (Prod)?

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

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

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

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

They, they sleep in a coma, yeah, yeah, yeah

They, they speak in a code

I don’t under-under-under-understand

…

Talking ’bout the business man

Business Man / Mother Mother

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

תלונות נפוצות של אנשי פרודקט על אנשי הפיתוח:

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

תלונות נפוצות של אנשי-הפיתוח על אנשי המוצר:

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

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

• חוסר-הבנה בין מנהלי-מוצר לאנשי-תוכנה, עוד ברמת הדיונים – גוררים ישיבות ארוכות ולא יעילות, תסכול ושחיקה משני הצדדים. זה מתפתח לחוסר אמון ומעגל של התדרדרות מתמשכת בתקשורת.
• בשלב מסוים “מרימים ידיים”. איש המוצר לוקח החלטה “פחות טובה” (suboptimal) רק “שפיתוח יבינו אותה”. מהצד השני, אנשי-תוכנה מסבכים את התוכנה כדי “להתמודד עם הדרישות הלא-ברורות של איש המוצר” או “מוסיפים הכנה למזגן” (פיתוח מיותר) להתכונן לא-נכון לדרישות הבאות (שנראה לא יגיע).
• אנשי המוצר מנסים לעזור לאנשי הפיתוח להסתדר, אם בהורדת הסטנדרטים במוצר במקומות הלא-נכונים (אין תקשורת שתעזור להבין היכן נכון להוריד) ואולי אף מנסה לארגן את העבודה הטכנית / הקצאת האנשים “בכדי לעזור לאנשי-הפיתוח” ומציב אילוצים לא-הגיוניים והרסניים על הפיתוח.

שורש הבעיה

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

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

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

שורש הבעיה, ש DevProd מצליח לגעת בו (to address) הוא יחסי-התקשורת בין מנהלי-מוצר לאנשי-תוכנה, שדיי התקבעו בתעשייה על הצורה הלא-פרודקטיבית הבאה:

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

סימנים לקיום / אי-קיום DevProd

הנה דוגמאות לסיטואציות / משפטים נאמרים שמעידים על אי-קיום או חוסר בתרבות DevProd:

• “הפרודקט קובעים ‘מה’, מפתחים קובעים ‘איך’ “.
  • זה מטופש! אנשי-מוצר לא יצליחו לקבוע “מה” בצורה נכונה בלי אנשי-התוכנה.
  • לדרוש מאיש המוצר לקבוע מה לעשות, עם ההבנה המוגבלת שיש לו בנבכי המערכת – זו הכשלה. אנחנו לא רוצים להכשיל את אנשי-המוצר, השותפים שלנו.
• “טוב, נשאל את הפרודקט מה הוא רוצה שנעשה”
  • שאלת מוצר לא צריכה אוטומטית “לעבור” לאיש-המוצר. אולי אנשי-התוכנה יכולים בכל זאת לענות עליה (ולכתב את איש-המוצר, כדי לוודא). לסירוגין, לפחות להציע חלופות עיקריות (שכבר עברו סינון טכנולוגי ראשוני).
  • הפינג-פונג בין פיתוח לאנשי-המוצר – צריך להפסק. לא עוד “לזרוק דילמה” לצד השני – ולצפות שהאחריות / כאב הראש ירדה עכשיו מאתנו ובאחריות של מישהו אחר.
  • מיותר לציין שהפינג-פונג הזה הוא דרך מצוינת למרוח זמן, ולעכב את הפרויקט / דליורי / פיצ’ר.
• גרסה נוספת: “ההנחיה מהפרודקט היא לעשות X”
  • אנשי-המוצר לא אמורים “להוריד הנחיות”, המינוח הוא לא נכון. א, חשוב לדייק ובעצם יש לומר “הדעה של הפרודקט היא שנכון לעשות X”. זו דעה חשובה ורבת משקל, אבל עדיין דעה.
  • נכון לבחון את דעת אנשי-המוצר, ולאתגר במידת הצורך. מהנדסים – הפסיקו להסיר מעצמכם אחריות.
  • “עשינו את מה שאיש-המוצר אמר אבל יצא מוצר חרא” – הוא לא טיעון שנכון לקבל אותו, לוגית אפילו. האחריות היא משותפת.
  • “הגדרתי מוצר מעולה, אבל הפיתוח דפק הכל ולא הצליח לייצר אותו” – הוא כשל לוגי באותה המידה. איש-המוצר חייב לרדת לקרקע וליצור את מה שאפשר, ולא ליהאחז ב”חלומות” שלא ניתן לממש (ולכן תמיד הרעיון ישמע טוב, אבל המימוש יכשיל אותו).
• ה DeadLock המוכר בתכנון פרויקט / רבעון / ספרינט:
  • אנשי-מוצר: “אמרו לנו כמה זמן כל דבר ייקח – ונאמר לכם מה נרצה לעשות”
  • אנשי-תוכנה: “אמרו לנו מה אתם רוצים שנעשה – ונאמר לכם כמה זמן זה ייקח”
  • אנשי-מוצר: “אמרו לנו כמה זמן כל דבר ייקח …”
    • תכנון פרויקט / רבעון / ספרינט צריכה להיות פעילות משותפת, Pair Planning של מוביל טכנולוגי ואיש-מוצר. די כבר עם הפינג-פונג המטופש הזה, של הטלת אחריות לצד השני.
• יחסים בין אנשי-מוצר לאנשי-פיתוח שדומים ליחסים של ספק-ולקוח. איש המוצר הוא הלקוח, מספק דרישות ורוצה את המוצר בזמן, וקבוצת הפיתוח היא זו שמחויבת לעמידה בזמנים / להתמודד עם התקלות שעולות בדרך. איש-המוצר – לא מרוצה ולוחץ על קבלת “הסחורה” בזמן, ולא מסייע להתמודד עם הבעיות. זה סוג היחסים הבעייתי יותר – שיש לעצור אותו מיד. הוא מוביל לתרבות כסת”ח, ושהמיקוד יהיה מסביב לזמני אספקה, ולא נכונות/הצלחת המוצר.
• איש-המוצר “נעלם לשבועיים” להכין את ה PRD. לאחר שבועיים, אנשי-הפיתוח שרואים את ה PRD לא מבינים אותו ו/או מוצאים בו אינספור חוסרים / אי-דיוקים / סתירות.
  • PRD שנכתב במעמד צד-אחד הוא לא PRD יעיל. אפשר לקחת פסק זמן למחשבה ותהייה. אפשר לעבוד אסינכרונית. איש-מוצר שכותב PRD ומציג אותו לקראת סיום – הוא לא מצב שצריך לקבל. אלא אם אתם, כעיקרון, עובדים בגישת ה Waterfall – ומרוצים ממנה.
• פרויקטים הנדסיים ה”נעלמים” מעיני אנשי-המוצר: הארגון חייב להקצות זמן לפיתוח, עדכון, והתאמת הארכיטקטורה של המערכת לצרכים המתפתחים / משתנים של הארגון.
  • מצב מציק אחד הוא אנשי-מוצר שמנסים לדלל / לדחות / ולדחוק בהשקעה הסופר-חשובה הזו. מצב בעייתי אחר הוא אנשי-פיתוח ש”מעלימים מהרדאר” פעילויות הנדסיות, כדי שאנשי-מוצר לא ישאלו / יציקו / “יסכנו” אותן.
  • ההשקעות ההנדסיות צריכות להיות גלויות לעיני הפרודקט. אנו רוצים שיסמכו עלינו שאנחנו עושים את הדבר הנכון – גם אם הם לא מבינים הכל. מובן. מצד שני – חשוב לאפשר ביקורת מצד אנשי-המוצר. כמו ועדה בכנסת שבוחנת ומאתגרת חברה ממשלתית. זה לא כיף (בעיקר לאנשי-הפיתוח), אבל זה חשוב מאוד לאמון ההדדי, ולצמצום waste – כי אנחנו יודעים “שפרויקטים הנדסיים” נוטים להסתבך ולגדול ב scope גם מעבר ל scope המינימלי ההכרחי. אם אתם תומכים בביקורת של בית-הנבחרים (כנסת) על הוצאות הצבא – רק הגינוי שתתמכו גם בביקרות של אנשי-המוצר על פרויקטים טכנולוגיים.

אם אתם יושבים ב Open Space ו/או ב Open Zoom ושומעים את אמירות הללו / נתקלים בסיטואציות האלו, ואתם רוצים תרבות DevProd – אתם צריכים לעצור ולתקן אותן.

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

הנה סימנים חיוביים לתרבות DevProd, שיש להגביר ולאמץ:

• איש המוצר משקיע “את הנשמה” ללמד את אנשי-התוכנה כל מה שהוא יודע, ואת כל התובנות הקטנות והמעניינות על השוק, המוצר, והלקוחות. הוא לא “שומר לעצמו” שום דבר מעניין. הוא ממש מרגיש כמו מנטור שצריך לרוקן את כל הידע והתובנות שלו החוצה.
• אנשי-התוכנה מקשים באופן תדיר על איש המוצר. להקשות על איש המוצר בפן העסקי זה לא “מותר”, אלא מה שצפוי מעובדים טובים. קשה להיות איש-תוכנה מוערך אם אתה לא עושה את זה.
• אנשי התוכנה דורשים מאשת המוצר עוד חיזוקים על היעדים העסקיים, כתנאי להשקעה משמעותית: “אבל איך את בטוחה שדווקא זה יעשה את האימפקט? מה זאת אומרת – זו הצלחה עיוורת? דברי במספרים גברת – דברי בנתונים!”
  • (כמובן שהפוסט מדבר על נשים וגברים כאחד, הפעם בחרתי בדמות אישה בשביל הציטוט/חרוז).
• אנשי-התוכנה משקיעים זמן ומאמץ כדי לפרוס את הסיבוכים, העלויות, והתלויות בין הרכיבים בפיתוח המוצר עבור אנשי-המוצר. הם עושים את זה בדאגה ובאהבה כאילו זו אמא שלהם, שצריכה עזרה ב”איך להתחבר לאינטרנט” או ילד, שרוצים ללמד אותו משהו, לתת לו משהו ושיבין לעומק – למרות שיש לו עוד הרבה פערי-ידע.
• מפתחים לא רק מציפים שאלות לאיש-המוצר (“זריקת אחריות מעבר לגדר”) אלא נוטים להציע פתרונות משלהם (שעוזרים להעביר לאיש-המוצר את המבט ההנדסי על הענין). ההחלטה, באידאל – באיזו אלטרנטיבה לבחור – היא משותפת. שום מפתח לא רוצה לשחרר פיצ’ר עם שימושיות לא-טובה ללקוחות.
  • לא פעם, הדרישות – אפילו של חווית המשתמש הן מורכבות לוגית: לחשוב על כל מקרי-הקצה ולארגן אותם. קל לאנשי-התוכנה “להשליך” את הבעיה לאנשי-המוצר, ואז להתאכזב מהם. אולי זה אפילו קצת מהנה / מספק הרגשת-עליונות בפתרון בעיות לוגיות?
    בתרבות DevProd – מצופה מאנשי-הפיתוח לזהות החלטות לוגיות מורכבות ו”להכנס בהן תחת האלונקה” ולעזור לאיש-המוצר להגדיר אותן ולהגיע להחלטה/פשרה הטובה ביותר. העיקרון הזה נקרא גם DBASH (קרי: don’t be a schmuck)
• המידע העסקי זמין לכולם: ישנם מפתחים (בוודאי לא כולם או הרוב) אשר ניגשים לנתונים העסקיים, בוחנים אותם ומחפשים (ובשאיפה: גם מוצאים) בהם תובנות. כפי שה System Monitoring בתרבות ה DevOps לא זמין רק לאנשי ה Operations – כך הנתונים העסקיים (פלח שוק, מתחרים, תוצאות A/B tests) לא צריכים להיות זמינים רק לאנשי-המוצר. איש-המוצר הוא המומחה האולטימטיבי לנתונים (כמו איש ה Operations) – אבל הנתונים זמינים לכל מי שמתעניין ורוצה לעשות קצת מעבר.
  • Dashboard עסקי משותף על מדדי הליבה של הקבוצה / צוות / פרויקט – נשמע כמו צעד הגיוני ורצוי.
  • בתרבות DevProd מצופה בבירור מאיש-המוצר “לדחוף” את הנתונים לאנשי-התוכנה, ולנסות כל הזמן לעניין אותם בהם – ולא רק כתגובה לשאילתה. ברור, הכי נוח לשמור את הקלפים “קרוב לחזה” ולא להיות מאותגר בשאלות קשות – אבל זו לא תרבות DevProd.

מה עוד לעשות, ברמה הפרואקטיבית – לקראת DevProd?

תקנו את הטייטל (תֹּאַר)

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

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

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

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

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

כיוון אחר הוא להסתכל מצד ה Engineering ולנסות להכניס את המונח Product Engineers לשימוש: מהנדסי-תוכנה שיש להם את שאיפה ויכולת לחשוב לא רק “איך” לבנות את המוצר, אלא להבין ולהתעמק ב”למה” לבנות את המוצר. כאלו שיכולים להתחבר לאנשי-המוצר, ללמוד מהם, ולעזור להם. לא כל מהנדס היה כזה, ואנו לא זקוקים שכולם יהיו כאלו – אבל אם כמנהלים נזהה אותם וניתן להם להתפתח לכיוון הזה, ולעבוד עם אנשי-מוצר, הם יכולים להיות ה backbone של תרבות ה DevProd בארגון שלנו.

שקלו להעביר את ניהול הפרויקט מאיש-המוצר

דיי נפוץ שבצוות / SCRUM / SQUAD יש כמה אנשי-תוכנה, אחד מהם כנראה מוביל או ראש-צוות, ואיש מוצר. משום מה, ניהול ומעקב אחרי הפרויקט (הגדרת milestones, מעקב אחריהם, תקשור פנימה לצוות והחוצה לארגון) – נופל לא פעם לידיו של איש-המוצר. מדוע?
כי הוא “מנהל”? כי הוא נתפס כ focal point של הפרויקט מול ההנהלה? כי לו אכפת יותר מההגעה ליעדים העסקיים? כל התשובות לא טובות.

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

תרבות ה DevProd כיעד – להשיג ולהתגאות בו

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

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

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

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

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

סיכום

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

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

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

---

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

Standing Together: 7 Principles for Great Product/Engineering Relationship – מירי כוריאל

בשני הפוסטים הקודמים של “תכנון מתוך דוגמה” (א.ק.א Design By Example), התמקדנו במציאת פתרון לבעיה קונקרטית. זו חלק קריטי בכל תכנון שהוא – אבל יש בתהליך התכנון גם מעבר לזה. בפוסט הזה נרצה להתקדם מעט יותר ב Liorson Software Design Maturity Model ולגעת ברמות השנייה (החצנת כוונות) והשלישית (התאמות לעתיד) של תכנון מערכת. הפשטות (Abstractions), הן כלי מרכזי בשתי הרמות הללו.

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

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

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

עבור שלב 2 של המודל (החצנת כוונות) עומדים לפנינו כמה כלים:

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

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

בואו נתחיל בתיאור של בעיה.

הבעיה שברצוננו לפתור

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

• “שאלון” הוא רמת העל, מקצה לקצה – של כל מה שאנחנו שואלים את בעל העסק.
• השאלון מורכב מדפים, שבכל דף כמה אלמנטים: כותרות, שאלות, ולעתים תמונות / דיאגרמות (התומכות בשאלות).
• בשאלון אנו אוספים מידע על “ישויות” השייכות לעסק. למשל, ברשת מסעדות – אנו רוצים אוספים פרטים על הרכבים של העסק, ועל המבנים (Facilities, יכולים להיות גם מבנים ארעיים).
  • עמוד מיוחד, Facilities למשל, מציג את רשמית המבנים ומאפשר להוסיף / להוריד מבנים מהרשימה.
    • כל הוספת מבנה תציג סט של שאלות שיש לענות לכל מבנה. למשל: 10 שאלות לכל מבנה, המתפרסים על פני שני עמודים.
  • לאחר שמסיימים את איסוף הפרטים על המבנים, לוחצים בדף ה Facilities על הכפתור “Continue” וממשיכים ברצף השאלון.
• אהה… ורק בדף של ה Facilities צריך גם להציג שאלה אחת “Include warehouses?” שמשפיעה על השאלות שישאלו לכל מבנה. זה אמור להיות דיי יוצא דופן, ולא להופיע כמעט אף פעם באובייקטים אחרים (רכבים, שותפויות/מועדוני לקוחות (לרשתות מזון), וכאלו…).

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

החלופות

מרחב האפשרויות למודל נתונים הוא גדול מאוד, עם מספיק זמן פנוי אני כנראה אוכל לתאר 10-20 חלופות (במשפחות שונות) – אבל זו לא תהיה השקעה יעילה של זמן. הרבה יותר הגיוני לבחון 3-4 חלופות, שונות מספיק, שנראות סבירות ברמת תחושת הבטן – ולבחור מהן. כמובן שיש מקום לשיפור ושילוב בין החלופות, תוך כדי שאנחנו מבינים אותן.

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

חלופה 1:

• Step הוא צעד בשאלון, שיכול להיות דף (Page) או צומת לניהול ישויות (Entity Hub). זה השלב שבו אנו יכולים להוסיף ולהסיר רכבים, מבנים וכו’. אשתמש בכל החלופות במונח Entity Hub בכדי לא לבלבל.
• כל דף מכיל סדרה של אלמנטים. ב UML (שפת התרשימים לתיאור מבנה של תוכנה) סימן ה * מתאר יחס של רבים. כלומר: לדף יחיד – יש אלמנטים רבים (1 או יותר), ואולי מסוגים שונים – כפי שתיארנו למעלה.
  • על מנת לוודא שברור: גם דף יש יותר מאחד. השאלון (Questionnaire) מכיל צעדים רבים, ודף הוא Generalization (ראש חץ לבן חלול ב UML) של Step.
• Entity Hub מחזיק קשר למספר דפים, אלו הדפים שצריכים להישאל לכל ישות שמטפלים בה: נניח 2 דפים של שאלות לכל Facility, כמו שראינו בתרשים למעלה.

חלופה 2:

• הפעם אלמנט הוא תכונה של QuestionniareStep (האם זה שם עדיף? מה המשמעות של בחירה בשם זה או הקודם?) כך שבעצם יש לנו אלמנטים (שאלות, למשל) גם ב EntityHub. זה עוזר לכסות את מקרה הקצה ב Facility Hub, בו עלינו לשאול שאלה. מי יודע, אולי אם הזמן נגלה שאנו צריכים להציג עוד אלמנטים בתוך ה Entity Hubs?
• ה Entity Hub לא מחזיק דפים, אלא Questionnaire Steps – מה שמאפשר לו להחזיר שורה של דפים (המקרה הידוע) אבל גם Entity Hubs בנים – מה שיכול לאפשר היררכיה. למשל, איסוף מידע על מחסנים (Warehourses) בכל מבנה (Facility). לא נדרש היום, אבל האם זה לא יהיה חכם לאפשר את זה במודל כבר מעכשיו?

חלופה 3:

• במקרה הזה, אנחנו מגדירים EntityHub כסוג של אלמנט. כלומר: ייתכן שה Entity Hub הוא דף עם אלמנט יחיד: ה EntityHub.
  • הדבר מאפשר להוסיף את השאלה שאנו נדרשים ב FacilityHub, וגם מאפשר בצורה טבעית לשלב בין Hub לאלמנטים נוספים באותו הדף: כמה שאלות, כותרות, או תמונות. הדבר גם מאפשר לצרף 2 EntityHubs באותו דף. למשל: לאסוף רכבים ומבנים – באותו דף של שאלות (כמובן שכל ישות: רכב או מבנה תפנה לשאלות משלה).
• ע”י כך שהפכנו את ה EntityHub לסוג של Element – ייתרנו את ההפשטה של Step/QuestionnaireStep – וכך בעצם פישטנו את התכנון!

חלופה 4:

• המבנה הזה, האמת, דומה מאוד לחלופה הראשונה – אבל מתאר הבדל אחד גדול ומשמעותי: ה EntityHub לא מחזיק דפים, הוא מחזיק Questionnaire.
  • הדבר מאפשר לנו ליצור היררכיה של EntityHubs, דומה למה שתואר בחלופה 2 – אבל בדרך אחרת. (איזו דרך עדיפה? מה היתרונות / חסרונות של כל גישה?)
• יש כאן משמעות עתידית דיי גדולה, בכך ש EntityHub מצביע לשאלון: במקום להחזיק “רשימה של דפים” עם ולהיות מוגבל ליכולות שלהן, כל Entity (רכב, מבנה, וכל אלו שעוד יגיעו) – יזכה לשאלון עם כל היכולות שיהיו קיימות. אלו עשויות להיות יכולות ברמת מבנה הנתונים (למשל: מוסיפים ל Questionnaire שם או צלמית ייחודית שמופיעה ב UI) או ברמת ההתנהגות (יכולת “לאפס” שאלון, יכולת לשנות באופן אקראי את סדר הדפים בשאלון) – שעכשיו יהיו תקפים לשאלון של רכבים / מבנים מעצם היותו של סט השאלות “שאלון” ולא “רשימה של דפים”.
• (יש איזו מידה של עצמאות/כוח שאנחנו נותנים לשאלות של Entities. האם זה דבר טוב או מזיק? מה המשמעות של זה?)

השתתפות הקהל

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

Google Analyhtics טוען שכל פוסט בבלוג נקרא ע”י בין 500 ל 2,000 קוראים (בד”כ). הייתי שמח לבדוק אם אלו בוטים או אנשים אמיתיים 😉.

עוד כשבועיים (סוף נובמבר) – אפרסם את הניתוח שלי על הדברים. אתם תראו שהוא מאוד תלוי סיטואציה, אין פה באמת “נכון” או “לא נכון” – אלא בעיקר “מתאים לסיטואציה X” ו”מתאים לסיטואציה Y”.