Product Owner בישראל: מה התפקיד עושה, שכר, ואיך נכנסים
זמן קריאה: 7 דקות
Product Owner אחראי/ת על כך שצוות הפיתוח יעבוד תמיד על הפריט הבא בעל הערך הגבוה ביותר, ועל כך שכל פריט יהיה מוגדר מספיק כדי שאפשר יהיה לסיים אותו ולהסכים שהוא הסתיים. בלוח HiTakeJob פתוחות כרגע 26 משרות שמזכירות Agile ועוד 26 שמזכירות Jira - הכלים שהתפקיד חי בתוכם.
למה הכותרת נדירה בישראל, ומה זה אומר לחיפוש עבודה
נתחיל בעובדה שחוסכת חודשים: בבדיקת כותרות המשרות הפעילות בלוח, הביטוי product owner אינו מופיע כלל בכותרת אף משרה. זו אינה אנומליה נקודתית אלא מאפיין של השוק הישראלי - הכותרת המקובלת כאן היא Product Manager, וגם כשהעבודה בפועל היא עבודת PO, המודעה תקרא לה אחרת.
שלוש מסקנות מעשיות:
- לחפש לפי תוכן ולא לפי כותרת - מודעות שמדגישות backlog, ספרינטים, כתיבת דרישות ועבודה צמודה לצוות פיתוח הן משרות PO בכל דבר.
- לתרגם את הקורות חיים - מי שכיהן/ה כ-PO בחו"ל או בחברת שירותים צריך/ה לתאר את התפקיד במונחי ניהול מוצר, אחרת המסננת הראשונה מפספסת אותו/ה.
- לשים לב לסוג החברה - הכותרת שכיחה יותר בארגונים גדולים, בחברות פיננסים וביטוח, בגופים ציבוריים ובחברות שירותי תוכנה, ופחות בסטארט-אפים.
נקודות התחלה בלוח: 26 משרות שמזכירות Agile, 39 משרות שמזכירות Jira ו87 משרות בקטגוריית מוצר.
עוד סימן מובהק שכדאי לחפש במודעה: אזכור של Scrum או של ספרינטים לצד תיאור מפורש של עבודה מול צוות פיתוח יחיד. מודעה שמדברת על אסטרטגיה, שוק ומתחרים מתארת תפקיד PM קלאסי, גם אם היא מזכירה backlog בשורה אחת. ההבחנה הזו חוסכת ראיונות שבהם מגלים באמצע שהציפייה שונה לגמרי ממה שהובן.
בעלות על ה-backlog
זהו הליבה, ומשמעותה הפשוטה היא: לאדם אחד יש סמכות לקבוע סדר. ברגע שהסדר נקבע בוועדה, התפקיד מתרוקן מתוכן. בעלות בפועל מורכבת מארבע פעולות חוזרות:
- סידור לפי ערך - רשימה מסודרת, לא ערימה מתויגת ב"גבוה".
- פירוק - הפיכת בקשה גדולה לפריטים שצוות יכול לסיים בספרינט.
- ליטוש - הבהרה של הפריטים העליונים לפני שהצוות מתחייב אליהם.
- גיזום - מחיקה של פריטים שלא ייעשו. backlog שרק גדל הוא backlog שאף אחד אינו סומך עליו.
מבחן פשוט לבעלות אמיתית: כשמנהל/ת מכירות מבקש/ת לדחוף פריט לראש הרשימה, מי מחליט/ה בפועל. אם התשובה היא "מי שצועק חזק יותר", אין PO.
קריטריוני קבלה שמונעים ויכוח
קריטריוני קבלה הם הרשימה שמגדירה מתי פריט הסתיים. הם מנוסחים לפני הפיתוח, לא בסופו, וזו ההפרדה בין צוות שמסיים ספרינטים לבין צוות שמנהל מחלוקות בסקירה:
| ניסוח חלש | ניסוח שאפשר לבדוק |
|---|---|
| המסך יהיה ידידותי | המשתמש משלים הרשמה בשלושה שדות ובלי ניווט נוסף |
| יהיה תמיכה בקבצים גדולים | קובץ עד 50MB נטען ומציג שגיאה ברורה מעל הגודל |
| הביצועים יהיו טובים | העמוד נטען תוך 2 שניות ב-95% מהבקשות |
| יטופלו מקרי קצה | משתמש ללא הרשאה מקבל 403 והפעולה נרשמת ביומן |
הכלל: קריטריון שאי אפשר לענות עליו כן או לא אינו קריטריון. על מבנה הפריט עצמו אפשר לקרוא במה זה User Story.
טקסי הספרינט - ומה תפקיד ה-PO בכל אחד
| מפגש | מה ה-PO עושה | הכשל הנפוץ |
|---|---|---|
| תכנון ספרינט | מציג/ה מטרה וסדר עדיפויות | PO שמכתיב/ה כמה פריטים ייכנסו |
| דיילי | זמין/ה לשאלות, לרוב מאזין/ה | הפיכת הדיילי לדיווח סטטוס ל-PO |
| ליטוש backlog | מבהיר/ה, מפרק/ת, עונה על שאלות | הגעה בלי הכנה והעברת הפגישה לשיחת ניחושים |
| סקירת ספרינט | מקבל/ת או דוחה לפי הקריטריונים | קבלה בדיעבד של משהו שלא הוגדר |
| רטרוספקטיבה | משתתף/ת כחבר/ת צוות | נוכחות שמונעת מהצוות לדבר בכנות |
המסגרת המלאה והתפקידים שבה מוסברים במה זה Scrum. חשוב לזכור שהתחייבות הספרינט שייכת לצוות ולא ל-PO - זו ההפרדה שעליה נשענת כל השיטה.
איך נראה שבוע של PO
בניגוד לתפקידי ניהול בכירים, כאן היום-יום יציב ודי צפוי, וזו אחת הסיבות שהתפקיד מתאים כנקודת כניסה לעולם המוצר:
| סוג עבודה | מה זה כולל |
|---|---|
| הכנה מראש | כתיבת פריטים, קריטריוני קבלה, איסוף תשובות מבעלי עניין |
| עבודה מול הצוות | ליטוש, מענה לשאלות במהלך הספרינט, קבלה של פריטים שהסתיימו |
| עבודה מול בעלי עניין | איסוף בקשות, הסבר למה משהו נדחה, עדכון על מה יצא |
| בדיקת מה שיצא | שימוש בפועל בפיצ'ר, קריאת פניות תמיכה, מעקב אימוץ |
השורה האחרונה היא זו שנופלת ראשונה כשעמוסים, והיא גם זו שמבדילה בין PO שמייצר/ת פריטים לבין PO שמשפיע/ה. בלי מעקב אחרי מה שכבר יצא, התעדוף מבוסס על מי ביקש אחרון ולא על מה עבד.
נקודה מעשית על ניהול בקשות: כדאי להחזיק מסלול קבלה יחיד. ברגע שבקשות מגיעות גם במייל, גם בהודעה ישירה וגם בפגישות מסדרון, אי אפשר להראות לאיש מה קורה עם הבקשה שלו/ה, וזה מקור אי האמון העיקרי בתפקיד הזה.
PO מול PM מול BA
| Product Owner | Product Manager | Business Analyst | |
|---|---|---|---|
| אופק | ספרינט עד רבעון | רבעון עד שנה | לפי פרויקט |
| שאלה מרכזית | מה נבנה עכשיו ואיך יודעים שגמרנו | מה כדאי לבנות ולמה | מה התהליך הקיים ומה נדרש ממנו |
| מול מי | צוות הפיתוח | שוק, לקוחות, הנהלה | בעלי עניין עסקיים |
| תוצר | backlog מסודר וקריטריונים | אסטרטגיה ומפת דרכים | מסמך דרישות וניתוח תהליך |
בישראל, כפי שנאמר למעלה, שתי העמודות הראשונות מתמזגות לרוב לתפקיד אחד שנקרא Product Manager. זה יתרון למי שנכנס/ת: מרחב האחריות רחב יותר מהגדרת ה-PO הקלאסית. זה גם חיסרון - אין מי שיגן על הצוות מריבוי כובעים, והאחריות לניהול הזמן היא של האדם עצמו.
שכר - הערכת שוק
במפורש: אין באתר נתוני שכר, והטווחים כאן הם הערכת שוק ולא נתון שנאסף מהמשרות בלוח.
| הקשר | הערכת שוק - שכר חודשי ברוטו |
|---|---|
| PO בתחילת הדרך (0-2 שנים בתפקיד) | הערכת שוק: 18,000-26,000 ש"ח |
| PO מנוסה (3-6 שנים) | הערכת שוק: 26,000-38,000 ש"ח |
| PO בכיר/ה או במרכז פיתוח רב-לאומי | הערכת שוק: 35,000-50,000 ש"ח |
בסטארט-אפים נלווה לעיתים מרכיב אופציות; המנגנון מוסבר במה זה ESOP. אין כאן מסקנה מיסויית או משפטית.
שלוש שאלות שמגלות אם המשרה אמיתית
מודעות רבות מתארות תפקיד PO אך מסתירות תפקיד רכז/ת משימות. שלוש שאלות בראיון מפרידות ביניהם:
- מי מחליט/ה מה נכנס לספרינט הבא? אם התשובה היא מנהל/ת הפיתוח או מנהל/ת המכירות, אין בעלות על ה-backlog והתפקיד הוא תיעוד.
- מתי לאחרונה נדחתה בקשה של לקוח גדול, ומי דחה? ארגון שלא זוכר דחייה אחת הוא ארגון שבו מפת הדרכים נקבעת בחוץ.
- איך יודעים שפיצ'ר הצליח אחרי שיצא? אם אין תשובה, לא תהיו חלק ממחזור הלמידה אלא רק מהייצור.
שאלה רביעית שכדאי לשאול היא כמה צוותים תשרתו. זה הפרט שמשנה את איכות החיים בתפקיד יותר מכל דבר אחר, והוא כמעט אף פעם לא מופיע במודעה.
המסלול המעשי לתפקיד
זה אחד המקומות הבודדים בשרשרת המוצר שאליהם נכנסים לרוב מבפנים ולא מבחוץ. הדפוסים החוזרים:
- מ-QA - היכרות עמוקה עם המערכת ועם מקרי קצה, שהופכת ישירות לקריטריוני קבלה טובים.
- מתמיכה או הצלחת לקוח - הבנה של מה באמת שובר אצל לקוחות, שהיא נכס בתעדוף.
- מניתוח עסקי או תפעול - יכולת למפות תהליך ולתרגם אותו לדרישה.
- מפיתוח - נדיר יותר, אבל מקצר מאוד את הדיון הטכני.
המעבר כמעט תמיד קורה באותה חברה, כי הוא נשען על היכרות קיימת עם המוצר ועל אמון של הצוות. מי שרוצה לזרז אותו יכול/ה להתחיל בלקיחת בעלות על חלק קטן מה-backlog בתפקיד הנוכחי, לכתוב קריטריוני קבלה לפריטים שנוגעים אליו/ה, ולהוביל ליטוש אחד בחודש. אלה שלושת הדברים שמוזכרים בפועל בראיון לתפקיד הראשון.
שאלות נפוצות
מה ההבדל בין Product Owner ל-Product Manager?
PO עוסק/ת בביצוע קרוב - סדר ה-backlog, פירוק פריטים וקריטריוני קבלה מול הצוות. PM עוסק/ת בשאלה מה כדאי לבנות ולמה, מול השוק וההנהלה. בישראל שני התפקידים ממוזגים לרוב תחת הכותרת Product Manager.
האם יש בכלל משרות Product Owner בישראל?
יש עבודה כזו, אבל הכותרת נדירה. בלוח כרגע אין אף משרה שהביטוי product owner מופיע בכותרתה, ולכן החיפוש צריך להיעשות לפי תוכן המודעה - אזכור של backlog, ספרינטים ועבודה מול צוות פיתוח.
צריך הסמכת PSPO או CSPO?
ההסמכה עוזרת בעיקר במעבר פנימי ובארגונים גדולים שמחפשים שפה משותפת, והיא בהחלט לא תנאי. מה שנבחן בראיון הוא דוגמאות: פריט שפירקתם, קריטריון שמנע ויכוח, ובקשה שדחיתם ולמה.
כמה מרוויח Product Owner בישראל?
הערכת שוק: כ-18,000-26,000 ש"ח בתחילת הדרך, כ-26,000-38,000 ש"ח עם ניסיון וכ-35,000-50,000 ש"ח בתפקיד בכיר. אלה הערכות שוק בלבד - אין באתר שדה שכר.
האם PO מנהל/ת את הצוות?
לא. ה-PO קובע/ת סדר עדיפויות ומגדיר/ה מה נחשב הושלם, אבל הוא/היא אינו/ה המנהל/ת של המפתחים ואינו/ה מחליט/ה כמה עבודה תיכנס לספרינט. ההתחייבות שייכת לצוות.
כמה צוותים PO אחד יכול/ה להחזיק?
המלצה מקובלת היא צוות אחד, ובפועל בישראל נפוץ שניים. משלושה ומעלה הליטוש הופך שטחי, הקריטריונים נכתבים ברגע האחרון, והצוותים מתחילים להשלים פערים בניחוש.
אילו כלים צריך לדעת?
Jira הוא ברירת המחדל בישראל - בלוח פתוחות כרגע 39 משרות שמזכירות אותו. מעבר לכך: כלי מסמכים משותף, כלי עיצוב לקריאת מוקאפים, ולעיתים גישה בסיסית לנתוני שימוש כדי לתעדף לפי מה שקורה בפועל.