בחברות שבהן האתגר העיקרי הוא 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 – מירי כוריאל