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

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

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

תוכלו לספר בכמה מילים מה זה ביגבריין?

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

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

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

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

בסופו של דבר אפשר לתרגם את המספרים האלו לרווח נקי של החברה ותרומה לגדילה שלה.

מה אתם עושים כדי לוודא שהאינטרסים של כולם מיושרים ושכולם מדברים את אותה השפה?

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

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

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

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

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

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

כמה חשוב לדעתכם שהפיתוח יכיר את העבודה של המוצר (והפוך)? ואיך אפשר לבנות מתודה שתאפשר את זה?

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

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

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

זה כן דורש הקרבה/השקעה של זמן, אבל כשזה עובד טוב לדעתי זה שווה את זה.

אשמח לשמוע מכם טיפ על העבודה עם הצוות השני 

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

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

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

למי שעוד לא קרא את הבלוג של נעה ודניאל, תוכלו לקרוא אותו פה.