היחס בין מוצר לפיתוח

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

כדי לפתור זאת נכון להתחיל ברמה אחת למעלה, בקשר שבין המחלקות הארגוניות – פיתוח ומוצר. זה יכול להיות במעורבות של הבכירים שאמונים על כך: CEO, CTO, COO, VP R&D. עליהם להגדיר היכן עובר הגבול שבין המוצר לבין הפיתוח. יתכן ונכון שאנשי המוצר יתנו ספציפיקציה יותר ברורה לדרישות שלהם, תוך שיציגו כיצד הדרישות האלה עונות על הצרכים או הרצונות של הלקוח.

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

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

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

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

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

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

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

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

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

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

מומלץ לקרוא על ניהול לפי ערכים בשיטת אימ.

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