מנהלי מוצר - מי אתם? איזו מין חיה מוזרה.
אתם לא טכנולוגיים, אבל אתם גם לא לא-טכנולוגיים. אתם לא אוהבים להיות בפרטים החשובים, אבל אתם מאוד אוהבים להיות בפרטים הלא חשובים.
או שאולי זה רק אנחנו?
נושא התקשורת בין מנהלי המוצר לצוותי הפיתוח מדובר לא מעט.
למירי כוריאל יש הרצאה נהדרת שעוסקת בזה, ואחת הנקודות המשמעותיות שם היא יצירת אמון הדדי בין הפרודקט לפיתוח, דבר שגם לתחושתנו הוא המפתח להצלחה של הקשר.
משום מה, רוב המאמרים שעוסקים בנושא בוחנים אותו מהצד של מנהלי המוצר - איך מנהל המוצר צריך לדבר עם המפתחים? מה מנהלת המוצר צריכה לעשות בשביל שהמפתחים יבינו אותה?
מהצד של המפתחים בדרך כלל מדברים על דברים כמו ״איך לתקשר למנהלי המוצר את החובות הטכניים שלנו״. כמעט ולא עוסקים בצד ההפוך - איך מפתחת יכולה לחשוב כמו מנהל מוצר ולהתחיל לדבר במושגים שלו?
אז נכון, אנחנו בוטים.
תקשורת בין אנשים היא לא הצד החזק שלנו, מודים.
אבל המטרה של הפוסט הזה היא להוציא אותנו קצת מאזור הנוחות שלנו, ולתת לנו כלים לחשוב כמו מנהלי מוצר.
זה בעצם כמו הבדיחה המוכרת: איך הופכים מפתח לראש צוות? דופקים לו פטיש בראש, אבל לא חזק מדי שלא יצא פרודקט מנג׳ר.
הקצר בתקשורת
אז למה מנהלי מוצר ומהנדסים לא מתקשרים טוב?
האם זה בגלל שמנהלי מוצר הם קופים?
לא סביר, חלקם היו בעבר הלא רחוק מהנדסים.
אולי אם רק מנהל המוצר היה מבין מה המהנדס עושה, הכל היה מסתדר והם יכלו לפצוח בשיח מרגש על הארכיטקטורה של המערכת החדשה.
כנראה שלא.
מנהלי מוצר ומפתחים, בהגדרה, מחפשים דברים שונים.
קחו לדוגמא את שני קינן, מנהל מוצר ב-Databand.ai מתאר איך מנהל מוצר חושב:
״גם אני וגם אתם מפרקים דברים גדולים לחתיכות קטנות ביום יום….״
אוקיי, עד כאן נשמע נכון.
״אבל כשאני ואתם מדברים על 'החתיכה הקטנה ביותר', כל אחד מאיתנו עושה אופטימיזציה לפי דברים שונים״
הממ, למה הכוונה?
״מבחינתכם החתיכה הקטנה ביותר היא איזושהי פונקציה, או שירות שאמור לבצע פעולה מסוימת. אין שום קשר להתערבות של היוזר ולערך שהיוזר מקבל. מבחינתי החתיכה הקטנה ביותר חייבת לכלול מעורבות של המשתמש. אין ל׳חתיכה הקטנה ביותר' שלכם שום משמעות עבורי.״
על מה לעזאזל אתה מדבר בן אדם?
"על הקוסם מארץ עוץ שמעתם?״
אם גם אתם לא הבנתם על מה שני מדבר, זה בסדר. קשה להבין מנהלי מוצר, על זה בדיוק הפוסט!
הקוסם מארץ עוץ
אחת המתודולוגיות המוכרות מעולם ניהול המוצר נקראת ״The Wizard Of Oz״. בשיטה הזאת מייצרים prototype בסיסי ביותר על מנת לשפר את חווית המשתמש של הלקוח ולבדוק אם הוא מקבל ערך. יש כל מיני דרכים לעשות את זה, אבל הדרך הבסיסית ביותר היא אשכרה לקחת בן אדם (כן, יצור חי) ש״יעמוד מאחורי המערכת ויזיז דברים״. בעצם, מייצרים סוג של פיצ׳ר שהלוגיקה שלו מונעת ידנית.
לדוגמא, נניח שמנהלת המוצר אומרת משהו כזה: ״אני רוצה שנעשה מערכת התראות ששולחת אימייל בכל פעם שמישהו נכנס בדלת!״. בזמן שאצלנו בראש מתחיל להירקם שרטוט ארכיטקטורה של התשתית הזאת, מה שיכול לקרות בפועל זה שיואב (תיכוניסט שעובד איתנו) יעמוד וישקיף על הדלת, וישלח מיילים ברגע שהוא רואה שמישהו נכנס.
פיצ'רים מבית היוצר של עוץ יכולים להיות דברים שמנהל המוצר יחשיב כפיצ׳ר טוב, ואפילו פיצ׳ר מעולה. זה ענה על כל הקריטריונים שלפיהם הוא עושה אופטימיזציה:
זה עשה את מה שזה אמור לעשות? צ׳ק!
זה נתן ערך ללקוח? צ׳ק!
הצלחנו להשיג את זה תוך פחות מספרינט? צ׳ק צ׳ק צ׳ק!
אנחנו כמפתחים לא מסוגלים לחשוב על זה בכלל כפיצ׳ר. אתה קורא לדבר הזה מוצר?
איט דאזנט סקייל! בשביל מה שכרתם אותנו למען השם? בשביל זה שכרו אותך?
אנחנו חושבים שהאופן בו אנשי המוצר ואנשי התוכנה תופסים את הפיצ׳ר לעיל הוא מראה טובה להבדל ביניהם כשמדברים על ״לפי מה מאפטמים״ (What do you optimize for?), ועל פי מה כל אחד מהם מודד הצלחה של פתרון מסוים.
מישהו צריך להתפשר
אז עכשיו כשהבנו שאין דרך להגיע להבנה, אפשר לעצור וללכת הביתה.
Problem Solved.
Mischief Managed.
אבל בתכלס, מנהלי המוצר הם לא אנשים רעים (לפחות לא בכוונה). בסוף הם אלה שיקבעו אם החברה שלנו תצליח או לא, ואם לא נהיה מסוגלים לעבוד איתם ולתקשר היטב, לא נוכל להתקדם.
מישהו כאן חייב להתפשר.
אפשר לדבר על הפשרות שמנהל המוצר יכול לעשות, אבל היינו רוצים לעסוק כאן דווקא בפשרות שאנחנו כמפתחים ומנהלי פיתוח יכולים לקחת כדי להפוך את החיים של כולם לטובים יותר.
יאללה להתפשר
אין משהו שמנהלי מוצר אוהבים פחות מאשר את המשפט ״אי אפשר לעשות את זה, צריך להחליף את כל הסיסטם שלנו בשביל זה״.
למה אנחנו אומרים את המשפט הזה כל הזמן?
מההתרשמות שלנו, כמעט את כל הדרישות ש״אי אפשר לעשות״, בעצם אפשר לעשות. כלומר, ברמה הטכנית - ניתן לגרום לדבר הזה לקרות. ואנחנו חושבים שגם צריך לתקשר את זה לפרודקט מנג׳ר (אפרופו יצירת האמון שמירי כוריאל מדברת עליו).
יותר מזה, והנה בא השוס - אפשר ואולי אף רצוי להתפשר.
אנחנו רוצים להציע למפתחים ולמנהלי הפיתוח להתפשר על האיכות של הקוד ועל המבנה שלו נקודתית (לא לאורך זמן, בואו, אנחנו לא חיות) כדי להיות מוכווני Impact וערך ללקוח.
נחזור למערכת ההתראות שלנו, שעכשיו כבר כתבנו אותה והיא יודעת לשלוח מיילים כשמישהו נכנס בדלת (פיטרנו את יואב). אם הפרודקט הייתה נחמדה, היא הייתה אומרת לנו ״אני רוצה עכשיו שתוכלו לשלוח גם הודעות סלאק״. בהנחה שכתבנו את המערכת כמו שצריך - נורא ברור איך להרחיב לה את הפונקציונליות לתמיכה בסלאק, נכון?
כנראה שהייתה לנו אבסטרקציה כלשהי לשליחת התראות דרך ממשק חיצוני, שמימשנו לה יכולת לשלוח מיילים (ואולי לתקשר עם שירותים אחרים שאנחנו משתמשים בהם).
נשמע לא מסובך כל כך.
אבל הפרודקט לא נחמדה. והיא מחפשת ערך ללקוח. ומבחינתה הדבר הנכון כרגע הוא דווקא להעמיק את היכולות של המערכת - אם מישהו נכנס ואז ישר יוצא, אל תשלחו מייל!
נשמה, זה אי אפשר לעשות.
יש לנו מערכת ששולחת התראה ברגע שמישהו נכנס בדלת - את בעצם רוצים לשנות את ההתנהגות שלה! אנחנו עכשיו צריכים להוסיף שירות שיודע לנהל את האירועים שקרו בדלת, אולי להוסיף תור, ואז לקבל החלטה על בסיס רצף של אירועים שקרו - מה קורה איתכם אנשים?
או שלא.
אולי, ותקשיבו לנו עד הסוף, נוסיף איזה sleep קטן של כמה שניות כדי ״לדחות את ההחלטה״ אם לשלוח התראה?
אנחנו מקווים שלא תלשתם את השערות מהראש. מבלי לרדת לפרטים, ההצעה הזאת נשמעת כמו bad practice, תלושה מהמציאות, לא סקיילבילית, ועוד קללות נוספות. מה יקרה מחר כשהפרודקט תרצה לבנות עוד פיצ׳רים על בסיס ההתנהגות הזאת שפיתחנו? האם ה-sleep הזה יעבוד תמיד?
מה חשבנו לעצמנו כשהצענו את זה?
אז זהו, שאולי זה כן הדבר הנכון?
מי מבטיח לנו שהפיצ׳ר הזה יהיה שווה את עבודת ה-Infra? מי מבטיח לנו שהחלק הזה במוצר בכלל יתן ערך ללקוח? למה שנשקיע מחשבה ועבודה כל כך משמעותית בשביל תשתית שלא בטוח שנצטרך אותה בעוד חודש?
אנחנו לוקחים כל הזמן פשרות מהסוג הזה, ובינתיים זה עובד לנו מעולה. במקום לקחת ספרינט ולהקים את התשתית לפיצ׳ר הזה, נעבוד עליו מעט זמן, נדחוף אותו ככה לפרודקשן, ורק במידה ונקבל פידבק חיובי מהלקוח (או כשנחליט שאנחנו רוצים לעשות אותו production-grade) נעבוד על לשפר את התשתית שלו.
כמובן, וחשוב להדגיש את זה, אסור לשכוח לתקשר לפרודקט את הפשרות שלקחנו. אנחנו מצפים ממנו בתמורה להתפשר על המשך העבודה עם הפיצ׳ר הזה, ולהבין שהחוב הטכני הזה הוא פצצה מתקתקת שנרצה להתחיל לטפל בה בספרינט הקרוב או לכל הפחות ברגע שמחליטים שהמוצר החדש הזה נותן ערך.
משא ומתן לצרכי פשרה
אז איך מתנהל תהליך ההגעה לפשרה? על מה צריך לתת את הדעת?
התקשורת עם מנהלי המוצר צריכה להיות מעין משא ומתן של פשרות שהמטרה שלו היא להגיע לנקודת הזהב, נו, זאת שאף אחד לא יוצא מרוצה ממנה. המשא ומתן על מערכת ההתראות יכול להראות מהצד שלנו ככה:
האם אפשר להגדיר ״כניסה-יציאה״ מהדלת בטווח של חצי שניה?
״לא, הערך שאנחנו נותנים ללקוח הוא בזה שהוא יכול להגדיר בעצמו את טווח ה׳כניסה-יציאה׳״
הבנו. מה אם ההתראה לא תהיה מיידית, אלא רק אחרי כמה שניות-דקות?
״אם נגיע למשהו שעובד מהר אבל יהיה עיכוב קל בשליחת ההודעה אפשר לחיות עם זה...״
יש!
״… אבל שימו לב שבהמשך כנראה נצטרך לתמוך בשליחה הודעות מיידית״
יופי חלאה!
זה אמנם היה מתיש, אבל בכל זאת יצאנו מפה עם משהו נחמד:
תכולה שהיא הרבה יותר scoped ואפשר לסיים אותה בפרק זמן סביר - התפשרו לטובת פתרון פשוט.
נכנסו לעובי הקורה והבנו מה חשוב למשתמשים שלנו בפיצ׳ר - אנחנו מכירים יותר טוב את הפרופיל של המשתמש!
עזרנו למנהלת המוצר - לא פתרנו בעיה שהיא עדיין לא בטוחה שצריך לפתור (שליחת הודעות מיידיות).
אם מנהלי המוצר מפרקים את ״מה שצריך לפתור״, ומפתחים מפרקים את ״איך לפתור״ - אפשר לומר הרי שמצאנו דרך לוודא (בקירוב דיי טוב) שה״איך״ שלנו עושה רק את ״מה״ שצריך לעשות.
תודו שאהבתם את המשפט.
סיכום
להיות מסוגלים לתקשר עם מנהל המוצר זו בעיה רצינית. באמת.
מדובר בפונקציה שהתפקיד שלה לחשוב שונה מאיתנו.
אין פלא שבאירגונים רבים המתח הזה בין הגופים השונים פוגע אנושות ביכולת לדלבר (To Deliver, מקווים שלא איבדנו אתכם כאן).
גם אם הבעיות לא יפתרו לגמרי, אנחנו ממליצים לנסות להיכנס לראש של מנהל המוצר ולקחת פשרות מהצד שלנו.
במקום להגיד על פיצ׳ר מסוים שלא ניתן לעשות אותו בלי עבודה רצינית, נסו לחשוב איך אפשר להגיע ל-mvp בסיסי בהשקעה מינימלית, ולטפל בבעיות התשתית בשלב השני.
נסו לנהל משא ומתן שיוביל אתכם לפתרון פשוט, כזה שיעזור לכם להבין טוב יותר את היוזר וימקד אתכם בדיוק בבעיה שאתם מנסים לפתור.
חשוב מאוד לא לשכוח לתקשר החוצה את החובות הטכניים שלקחנו ואת הצורך לטפל בהם בהקדם.
אנחנו אימצנו את הגישה הזאת באחד המוצרים המרכזיים שאנחנו עובדים עליו, והאמת, ה-velocity שלנו השתפר פלאים, והתקשורת בינינו, גם אם היא לא מושלמת, בהחלט מעולה.
בפרק הבא נדבר על מה אנחנו עושים עם החובות הטכניים שיצרנו, איך למה ומתי מטפלים בפצצה המתקתקת הזאת, מה עדיין לא פיצחנו, ואיך זה קשור לתכנון ספרינט.
אז תנסו את זה, מה אכפת לכם? זה לא עולה לכם כסף או משהו (רק לבעלי המניות).
או איך שהפתגם המוכר אומר:
לעשות over engineering זה אנושי, להתפשר זה אלוהי.