מה זה Roadmap? הסבר פשוט + משרות פתוחות בישראל

Roadmap, מפת דרכים למוצר, היא מסמך שמתאר לאן המוצר הולך ולמה - לפי בעיות שרוצים לפתור ולא לפי רשימת משימות עם תאריכים. היא כלי תקשורת בין מוצר, פיתוח, מכירות והנהלה. בלוח HiTakeJob פתוחות כרגע 81 משרות בקטגוריית ניהול מוצר, 24 שמזכירות ניהול מוצר ו-39 שמזכירות Jira.

מה זה לא

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

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

המבנה שעובד

המבנה הנפוץ מחלק לשלושה אופקים, וזה פותר את בעיית התאריכים:

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

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

איך מתעדפים

התיעדוף הוא עיקר העבודה, והמפה היא רק התוצר שלו. השיקולים שחוזרים:

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

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

איך זה נראה בפועל ברבעון

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

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

מי צורך אותה ומה כל אחד מחפש

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

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

מה משתבש

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

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

איך מתקשרים שינוי במפה

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

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

מה זה אומר למפתחים

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

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

מה שווה לשאול עליה בראיון

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

שאלות נפוצות

מי בונה אותה?

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

כל כמה זמן מעדכנים?

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

האם מראים אותה ללקוחות?

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

מה ההבדל בינה לבין ה-backlog?

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

איך מתמודדים עם בקשה דחופה מלקוח גדול?

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

מה ההבדל בין מפה לתוכנית עבודה?

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

האם יש כלי מיוחד לזה?

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

האם צוותי תשתית צריכים מפה כזו?

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