תמלול: אסף שוחט אבידע וסטס וישנבצקי | פרודקט וR&D - הכל על השולחן: פרק מיוחד

אייל דוד: [01:15] היי חברים, זה אייל. הגעתם לפרודקט בילדר, ופה תוכלו להקשיב לשיחות המוצר הכי מעניינות. המסע שלי החל ב-2012 כשלמדתי מה זה פרודקט בסטארט-אפ שלי. מאז עבדתי בתעשייה ומ-2017 החברה שלי מייעצת למגוון חברות. הדרייב שלי הוא לעזור לכולנו להשתפר כאנשי מוצר. ולפני שמתחילים, אם אתם נהנים להאזין לפרודקט בילדר, דרגו אותנו בבקשה בחמישה כוכבים בספוטיפיי. זה ייתן לי אחלה פידבק שהפודקאסט נותן לכם ערך, וזה ישמח אותי מאוד. אז יאללה, מתחילים. אהלן חברים, מה העניינים? נמצאים איתנו כאן סטס ואסף, כבר נציג, היום יש פרק מיוחד, אנחנו בעצם בפורום של שלושה. אני אציג אתכם זריז, תגידו שלום. היי, אהלן. אז כן, יש פה אנשים. אז נמצא איתנו כאן אסף שוחט אבידע, שמגיע לנו מאווינסד, הוא בעצם מגיע כפרונט אנד טק ליד, וסטס וישנבצקי, שהוא בעצם דירקטור of engineering ממליו. אהלן חברים. ואנחנו הולכים לדבר בעצם, לחשוף את כל השיט ואת כל הדברים שנמצאים בעצם ביחסים בין פרודקט לבין דב, והחבר'ה כאן הגיעו כדי לייצג את דב, תהיה שיחה סופר מעניינת. אז אסף, בוא תגיד על עצמך כמה מילים, מה אתה עוד עושה בעצם מלבד אווינסד?

אסף שוחט אבידע: [02:36] אז מלבד אווינסד, אני בעיקר אבא לשלושה, וגם אוהב להרצות, את הדבר בכנסים, קצת כותב. בריאקט נקסט האחרון, איתן, נכון? נכון, בריאקט נקסט האחרון, יש כנס בטסטקון, שיהיה בלטביה,

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

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

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

הסקילס הכי חשובים במנהל מוצר

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

אייל דוד: [04:46] של היכולת החשובה ביותר בשביל שתהיה אפקטיבי בתפקיד. זה גם כאילו משהו שדי פוגש בעצם את dev, נכון? כי אם לא עושים מחקר מספיק עמוק, אם לא מעדכנים מספיק בעצם את הדרישות, אז בעצם מתחילה קונטרה ומתחילות שאלות, ואז פתאום, נכון? אולי נרחיב על זה בהמשך. משהו נוסף שאתה אולי רוצה להעלות?

אסף שוחט אבידע: [05:08] יש עוד כל מיני כישורים, נגיד היכולת לתקשורת ורבלית היא מאוד חשובה. העבודה היא מאוד cross-functional, אתה עובד עם כל מיני מקצועות, זה יכול להיות legal, sales, engineering, אז היכולת להיות אפקטיבי בשיחה, גם בתקשורת כתובה, היא מאוד חשובה. מהמם. אסף, משהו מהצד שלך? אני חושב שפרודקט זה מהתפקידים שבהם אתה קצת איש מכירות, ולא כל כך ברור לך מי הלקוחות, כי יש, וגם לא כל כך ברור מה אתה צריך למכור, כי זה כל פעם משהו אחר. כלומר, יכול להיות שאתה צריך עכשיו, לדעת, למכור את הפיצ'ר למפתחים, כי אתה מנהל, אבל אתה מנהל עם סמכות מאוד מסוימת, אתה לא המנהל הישיר של המפתחים, אבל אתה צריך לגרום להם לעשות את הדברים לא מתוך שוט, אלא מתוך הבנה ורתימה. מצד שני, אתה צריך אחר כך לשמוע את הפידבקים שלהם ולמכור למעלה למה הדבר יעלה כמו שהוא יעלה בצורה נכונה. כלומר, אתה צריך לדעת לשקף את כל הצדדים וגם להביא את האינפוט שלך.

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

מקור המתח: כשפרודקט נכנס ל"איך"

סטס וישנבצקי: [06:28] מי רוצה להתחיל? זו שאלה מעולה. אני חושב שכאילו, אני גם, נראה לי שאנחנו נדבר על זה עוד בהמשך, וגם אני אדבר על זה בפוסט שאני כותב, וזו גם נראה לי הנקודה שהכי משכה אותי לנושא הזה. יש המון המון מתח בין פרודקט לפיתוח, ויש כאילו כל מיני דרכים לפרק את זה, נדבר על זה, אבל המתח קורה בגלל שאלה שני מקצועות, שביחד הם משתפים פעולה בשביל להוציא איזשהו משהו לאוויר. ומה שלי הכי הפריע בפרודקט, והיום אני כבר יודע לשלב את זה ולהבין מאיפה זה מגיע, אבל זה הצורך של פרודקט to scope את התכולה. ולפעמים זה גם עובר איזשהו קו, גבול כזה, שבו האינג'ינירים מרגישים שפרודקט נכנס גם לאיך לעשות משהו. וזה מקור לסטרס מאוד גדול, זה יכול ליצור עבודה מאוד לא נעימה בין הצוותים, זה יכול כאילו לשבש מערכות יחסים, וזה יכול גם לפגוע במוצר.

אייל דוד: [07:29] כי כאילו בעצם מעבר לזה שדורכים לך על האצבעות בעצם, ואומרים לך מה לעשות, אתה אולי גם לא מאמין בפתרון?

KPI משותף: פרודקט כ-API של הפיתוח לביזנס

אסף שוחט אבידע: [07:36] זה, אם נגיד, יש שאלה מקבילה למה ששאלת אותי, מה אתה חושב שהתכונה הכי חשובה של פרודקט? ויש גם שאלה כזאת לשאול אינג'ינירס. והמהנדס כנראה יגיד שהתכונה הכי חשובה זה היכולת שלו לתכנן ולבצע את הדבר הזה שבונים. וכשמגיע נגיד אדם ממקצוע אחר שכאילו מרגיש מאוד מעורב בלהגדיר את מה בונים, ואז גם את האיך, אז זה מרגיש כמו דריסה, זה מרגיש כאילו דריכה, וזה מרגיש גם שהפרספקטיבה שפרודקט לוקח ללהציע איזושהי הצעה היא פרספקטיבה שהיא לא מיטבית ל-KPI, נגיד, שחשובים לאנג'ינירינג. אולי באמת זה גם הדבר, ה-KPI's הם לא תמיד אותם KPI's לשני הצדדים. אז בהמשך למה שאמרת על KPI's, יש פה באמת איזושהי אנומליה, איזשהו משהו שהוא יכול להיות כל כך, יכול לא כל כך לעבוד טוב. זאת אומרת, אם יש KPI מסוימים לפרודקט ו-KPI אחרים לפיתוח, למשל, לדוגמה, כן, היפותטית, נגיד אם ה-KPI של הפרודקט זה כמה... קונברז'ן. כן, למשל קונברז'ן של המוצר, כמה רכשו, כמה לחצו על איזשהו משהו, ומצד שני ה-KPI של הפיתוח זה כמות הבאגים. אוקיי? אם, ולפעמים זה יכול לדבר, אבל אם זה לגמרי שונה, אז יש פה איזושהי בעיה בתהליך. כי המקרה הכי הכי טוב, זאת אומרת, אני בתור פיתוח, בתור מי שרוצה להסתכל על פיתוח קצת ברמה היי-לבל, אני מאוד מאוד רוצה KPI'ים של פרודקט. למה? כי, שוב, מתוך אמון ביכולות של הפיתוח, זאת אומרת, אני מניח שאם אנחנו נעבוד לאותו KPI, אז עכשיו אני בתור פיתוח יודע לתרגם את זה. לצורך העניין, אם עכשיו החברה רוצה להגיע לכמה שיותר קונברז'ן, יכול להיות שהמפתח זה quality, יכול להיות שלא. יכול להיות שעכשיו המפתח זה קוויק אנד דרטי. כן? זאת אומרת, אז אם מה שחשוב לחברה, אגב, ה-KPI של כולם צריכים להיות בעצם הביזנס, זה בעצם מה שמעניין. כלומר, הפרודקט הוא בעצם הגשר בין, שלי בתור R&D, כן? הוא ה-API שלי החוצה לביזנס. אז אם עכשיו הביזנס עושים למשל איזשהו קמפיין, כן? שאני יודע שלחלק מסוים מהמוצר יגיעו אליו מאיזשהו דף נחיתה, אז אני צריך לדעת את זה, אני צריך לאפטם אותו ולא את כל, לא את שאר המוצר, לעשות לחלק הזה מוניטורינג ואז אנחנו נוכל להגיע למצב הזה, על חשבון דברים אחרים. אבל ברגע שה-API מחובר, אז גם ה-KPI מחובר, אז גם הסיפור נורא נורא ברור, ואז גם עבודת המכירה של הפרודקט נורא נורא קלה, כי בעצם הוא אומר, תקשיבו, יש פה קמפיין של כל החברה, וזה מה שצריך לעשות. אינג'ינירים יקרים, מה צריך לעשות? איך אתם מציעים? זה כאילו מצחיק, מה שאתה מדבר עליו בעצם זה תיאום ציפיות בסופו של יום. מה שאני מדבר עליו זה תיאום ציפיות, אבל תיאום ציפיות ברמה של לא רואים את הידיים אבל מדמיינים שבידיים יש שרשרת, כן? אם אתה מתאם ציפיות בעצם בין הביזנס לפרודקט לבין הפיתוח, שגם פה אנחנו אומרים פיתוח כאילו בתור שזה בן אדם אחד, אבל לתאם בתוך הפיתוח זה גם סרט משלו, כן? במיוחד כשהארגון גדל. אבל אם יש פונקציית מטרה אחת, זה מיישר את כל הארגון. ברגע שזה מתחיל להתפצל,

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

אסף שוחט אבידע: [11:18] אה, שאנחנו לא באותו כיוון? אה, כל הזמן. לא, זה קורה, ברור, ברור, קורה גם בחברה הזאת, גם בחברות אחרות, כן? זה משהו שהוא, שצריך לעבוד עליו. כן? זה תקשורת שהיא של כל ארגון, שאם אתה קרוס מדינות, קרוס טיים זונס, והתקשורת היא היום, כלומר, לא כולם באים למשרד ביחד, שאני בעד, אגב, אבל בסוף בסוף בסוף זה תקשורת, כן? תקשורת זה החלק הכי כואב בארגון בכל הרמות, בין המחלקות, בתוך המחלקות. אני יכול לתת דוגמה שזה כן עובד, למשל, כן? שאם עושים עכשיו launch, לא ארוחת צהריים, השקה של מוצר חדש, אז, כלומר, זה לא צריך להיות משהו פומפוזי, זה לא צריך להיות משהו שעכשיו שולחים מיילים לכל החברה, עובדים על הדבר הזה, לא, אלא אפילו ברמת, עכשיו עושים דמו ללקוח, אז לפני שהדמו מוצג ללקוח, אומרים לאינג'ינירים, תקשיבו, אנחנו הולכים עכשיו להציג את המוצר ללקוח גדול, אינג'ינירים, בבקשה תבדקו את זה לפני, כולם יהיו מיושרים על אותו דבר, הבאגים שהולכים לפתור זה הבאגים שעכשיו קשורים לדמו. זה בסוף יעזור לביזנס, וזו דוגמה ממש ממש קטנה שאפשר לממש אותה גם בחברה גדולה.

אייל דוד: [12:24] נכון, וזה גם נותן בעצם הרבה יותר trust אולי גם בין שני הצדדים, כשמדברים בשפה כזאת. יש פה גם עניין בעצם של ownership, אני חושב, שברגע שאתה מסביר לצד השני, או לכל הצדדים, אם אתה הולך ובונה בניין, בסדר? וגם בשלב התכנון, וגם בשלב הביצוע, כולם מכוונים לזה שהבניין יעמוד, ויעמוד בתקנים, ובסוף נמכור אותו. יהיה ownership טוב בשלבים השונים, בעצם על ידי הגורמים השונים, כי כולם נעים לאותה נקודה, וכל אחד אחראי על משהו אחד ספציפי שאמור להביא אותנו לשם. אם לא מתקשרים את זה, כמו שאתה אומר, אז זה פוגע גם בתחושת ה-ownership, וזה כל כך חשוב. טוב, אני אומר, הדוגמה של הבניין זה ממש טוב, כי אם יצא לך לראות בניין שמוכרים אותו,

אנלוגיית הבניין, השכונה וסטרייפ

סטס וישנבצקי: [13:11] אז אתה לא בונה את כל הבניין, ואז מתחיל את כל הגימור פנים, וכל הגימור חוץ, וכל הדברים האלה. דבר ראשון, עושים דירה לדוגמה. דירה לדוגמה. נכון? זה הדבר הראשון שאתה עושה. כי אתה אומר, מה המוטיבציה של כולם? כן, כנראה מבחינת לוח זמנים, כנראה הכי הגיוני זה לעבוד בשלבים. קודם כל את השלד של הכל, שלד עולה צריך לקרוא, אני לא מבין בבנייה כלום, כן? אבל קודם שלד של הכל, ואז את כל התשתיות, ואז את כל הצנרת, ואז את הכל, ובסוף להביא את הצביעה לכל ביחד. אבל הווקטור פה הוא מכירות, זה נורא נורא ברור. כן, בעל הבית רוצה למכור. אז דבר ראשון, עושים דירה לדוגמה, מביאים את אנשי הגימור, את המעצב פנים, משהו כזה. שיהיה פצצה. כן. ואז ממשיכים. מצד שני, אבל כאילו, אני מתחבר לאנלוגיה של הבנייה, זה מעניין, אבל רוב החברות שאנחנו עובדים בהן, ורוב החברות שקיימות בתעשייה, הן לא בונות בניין, הן בונות חברות לבניית בניין. כלומר, הדפינישן אוף דאן של איפה מסיימים, נגיד כשבונים, אז זה בניין, ואז למכור אותו, וסיימנו. יש בניין אחר לבנות. אבל זה לא ככה בחברת, נגיד, חברות פינטק, חברות סייבר. אתה בונה מוצרים, שאתה כל הזמן מתחיל ב-MVP ומרחיב ומרחיב. זה בעצם בניית בניין שלא מסתיימת לעולם. בניית שכונה. כן, כן. ואז כאילו, נגיד, נכנסים אלמנטים חדשים של שכונה. פתאום כזה, אוקיי, פתרונות חינוך, גני משחקים וזה. הדברים מתרחבים. גם בעבודה אצלנו, נגיד, יהיה איזשהו MVP, משהו בסיסי כזה בסטארט-אפ שדרכו אתה יכול להשיג משקיעים, ואז אתה מנסה לייצר יותר אמצעים להשיג לקוחות, ואז אתה מאפשר יותר ויותר פיצ'רים, יותר פונקציונליות וזה. אז זה תמיד מתרחב. יש איזושהי אנלוגיה מתחרה לבניין של אמצעי תשלום. נגיד, אנחנו עובדים בסטרייפ בתחילת דרכה, ויחסית בהתחלה הם כזה, אוקיי, בוא נחבר, נגיד, את אמצעי התשלום של כרטיס אשראי. וכאילו, ב-Engineering עשו איזשהו דיזיין, ובנו איזושהי מערכת, וזה אפשרי, והכול טוב. ואז נגיד, נכנס פתאום שחקן מוזר של, אוקיי, עכשיו אנחנו רוצים להכניס את האפשרות לשלם בהעברה בנקאית. שזה כאילו, זה מודל אחר לגמרי. כאילו, the flow of funds הוא שונה, זה כאילו, ה-APIים אפילו שונים. אם נגיד, בהתחלה עשית APIים כמו authorize ו-capture, אז כאילו, אלה מילים שהן לא רלוונטיות בכלל בהעברות בנקאיות. ושם יש קשיים, ואני חושב שהרבה מהמתח בין פרודקט לאנג'ינירינג, הוא כשבאים למטרה, נגיד, של לבנות בניין, אז יודעים איפה מסיימים. סיימת את הבניין, הוא גמור, יש את הדירה לדוגמה. כאילו, ברור לכולם, יש קו מלא לגבי איפה מסיימים. אבל בסטרייפ, נגיד, זה לא ברור איפה אתה מסיים. אתה מתחיל בכרטיס אשראי, אחרי זה יבואו בנקים, אחרי זה יבואו הדברים, אחרי זה ביטקוין.

אייל דוד: [15:54] אבל מה שאתה מתאר פה זה בעצם שלביות, נכון? הרי בכל שלב כזה יש definition of done, כל שלב כזה הוא בניין, הוא הרחבה של הבניין, נכון? אפשר כן, בעזרת תיאום ציפיות טוב, וראיתי את זה קורה המון פעמים, גם לבנות פלטפורמה, או גם לבנות כאילו ערימה של שירותים שבעצם מתווספים לשכונה.

סטס וישנבצקי: [16:14] לגמרי. אני חושב שאחת הנקודות שבהן KPI נהיה נושא שיחה מעניין בין פרודקט לאנג'ינירינג, הוא בנקודות מבט שהן טיפה שונות בין פרודקט לאנג'ינירינג. נגיד כשהאינג'יניר בסטרייפ קיבל את המשימה של לממש API לכרטיסי אשראי, עלו לו שאלות כמו, ומה יבוא אחרי? תהיה העברה בנקאית, כי אני רוצה אולי לחשוב פה על איזושהי אבסטרקציה שכאילו אומרת שתשלום הוא תשלום, regardless of the end method. ואם נגיד ההחלטה של הסקופ היא מוצרית, אז ייתכן וכאילו אנחנו מתפקסים על מה שהביזנס צריך כרגע. כי לפעמים השיקולים של פרודקט ב-KPI ביזנסי זה כאילו קונברז'ן, להגיע ללקוח כמה שיותר מהר, לראות כאילו את השימוש על ידי יוזרים. ובאנג'ינירינג יש KPI טיפה מורכבים יותר, שהם גם לאגינג, גם למדוד אותם לוקח יותר זמן, כמו dev velocity או quality, מה שנגיד עניין את אותו מהנדס בסטרייפ, לגבי איך אני אאפשר גם עם סרטים תשלום של בנק בעתיד. ואז זה טיפה כאילו, זה נוגע במתח בין שתי הפונקציות. ובדרך כלל מה שמקל על מתח כזה, גם את זה ראיתי קורה, זה שיש vision מאוד מאוד חזק מהצד של פרודקט, או הצד הביזנסי, ואז דברים יותר, קל יותר לענות עליהם, יותר נופלים למקום בעצם כשנענות השאלות האלה. הם גם, כנראה שזה לא קורה ב-day one של סטרייפ, זה קורה באמת אחרי שכבר, אחרי שכבר יש משהו, נכון? כן, כן. אני אצביע על עוד דבר בעצם בין המתחים, אני חושב שבסוף זה ריכוז של הדברים שדיברנו עליהם, והכל נובע מאיזשהו תיאום ציפיות שחסר. הדבר שאני הכי מרגיש זה באמת ה... יש בעצם את העניין של הערכות זמנים הכי בסיסי, נכון? מה זה, כל הערכות הזמנים. בואו נדבר על הערכות זמנים. החלק הכי קל ב-engineering. שזה נורא נצמד גם לאיך, אני רואה את זה כשריר, ממש. כאילו, זה משהו שבהרבה צוותים שעבדתי, מתחיל גרוע מאוד, אובר טיים אנחנו משתפרים יחד, זה נורא גם באמת נוגע בטראסט. יש פה סיפורים נורא מצחיקים שאפשר לדבר על הדברים האלה, הערכות שלוקות בחסר, הערכות שאפילו היו יותר מהירות ממה שחשבנו, כי מישהו פשוט חשב על הדברים טיפה אחרת בצד השני והפתיע אותנו.

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

הערכות זמנים, design review ותיאום ציפיות

אסף שוחט אבידע: [18:51] אבל אז אתה פוגע בעצם, או שבסופו של דבר, פוגע באמון, פוגע גם במוצר, בדרך כלל, אוקיי, אז הפרודקט ייקח אחורה, יגיד, טוב, זה מה שאני יכול לקבל, בואו נקצץ, בדרך כלל אנחנו נחזור עם מוצר פחות טוב. נכון. אני חושב שהמפתח פה, דבר שיש פה, זה בעיה שהיא באמת קשה. כן? זאת אומרת, לחזות את העתיד זה בעיה קשה. כי זה בעצם אומר, בשביל לדעת, מהצד של אינג'ינירים, בשביל לעשות הערכת מאמצים זה אומר שאני חייב להבין מה רוצים שאני אעשה, להניח שזה לא יזוז, וזה יזוז. דבר שני, לדעת בגדול מה הפתרון, ולדעת מה היכולת שלי. כל אחד מהדברים האלה זה דבר שלוקח זמן להבין אותו. כן? לדעת מה היכולת שלי בתור מפתח, משהו אחד, כמה וכמה, כמה וכמה עם הפיצ'ר הזה כולל כמה מפתחים, בכמה רמות, בכמה צוותים, שלאחד מהם יש לו פתאום און-קול, אחד פתאום יכול להתחייב לשבוע, אבל בעצם יעשו לו כזה שיפטינג למשימה, ואז כועסים עליי בתור הפיצ'ר אונר, למה זה לא מתקדם? אבל הוא לא אצלי בצוות. כלומר, זה באמת, יש פה הרבה משתנים. מה שהרבה פעמים עוזר קצת להנמיך את הלהבות, כי הרבה פעמים זה באמת נהיה, כמו שאמרת, זה מניעה מין כזה, מלחמת האשמות כזאת, זה שוב המילה של תיאום ציפיות, או שיתוף. למשל, אם אני בתור עכשיו אינג'ינרינג, יש לי פיצ'ר שאני אחראי עליו, אז אני אזמין את הפרודקט לדיזיין ריוויו, כדי שהוא יבין קצת יותר את עולם הבעיה שלי. שאני אגיד לו עכשיו, תשמע, אני צריך ליצור פה, שוב נגיד, מעולם של פרונט-אנד, אני צריך עכשיו ליצור חמש קומפוננטות חדשות שלא קיימות, וגם שיהיו נגישות, אז זה ייקח לי איקס זמן. בוא נחשוב יחד, כאילו, מה ניתן לעשות. נכון, ואני אגיד, אוקיי, תשמע, זה ייקח לי איקס זמן, אולי אפשר לחסוך את זה קצת, נגיד, בשלושים אחוז, עדיין, אז זה שבעים אחוז מהאיקס זמן הזה שאמרתי, נגיד, שמנסה אופטימיזציה, ויש לי פה עוד אינטגרציה עם צוות אחר, ובצוות האחר צריך עוד משהו כזה. אז לצורך אני אבוא, זאת אומרת, אני שם את הדברים על השולחן הכי הכי פתוח, ואני אוסיף איזשהו buffer של יוניט טסטים, אנד טו אנדים, כן, כל מיני טסטים שצריך להוסיף. עכשיו אנחנו פה ביחד, זה לא שאני אומר לך, זו התמונה שיש לי, תסתכל. אתה חושב שנוריד, אני גם אבוא, גם אני בתור אינג'ינרינג, אני אבוא אליך עם הצעות. זהו, זהו, זהו, אני אגיד. תשמע, הפיצ'ר, וזה הדבר שאני חייב לעשות, כשאני מקבל פיצ'ר, זה לחשוב עכשיו, לשים את עצמי בנעליים של הפרודקט, עוד רגע אני אגיד למה זה גם לא טוב, כן, לשים את עצמי בנעליים של הפרודקט ולראות מהפיצ'ר הזה, מה אני יכול לחתוך החוצה. כלומר, אם אני עכשיו בתור לקוח מקבל את זה, מה פה יכול להיות לי בעל ערך בדרופ ראשון, דרופ שני, דרופ שלישי, כן, אני, בתיאום הציפיות שלי עם הפרודקט, הייתי מצפה שהפרודקט יבוא עם זה, אבל אני מבין שזה גם לא תמיד ככה, כי באמת הפרודקט לא יודע מה הדלתא של המאמץ עבור כל אחד מהכפתורים. יכול להיות שיש איזשהו כפתור קטן, שהפרודקט חושב שהוא מאוד מאוד מסובך לעשות אקספורט לאיזשהו פורמט נגיד של טבלה ואני אומר, תשמע, עשינו את זה במוצר אחר, זה ייקח לי יום, בוא נוסיף את זה, כן, ויכול להיות גם להפך. עכשיו אמרת שתיגע בעצם בחיסרון של זה, העלו לי כמה, אבל... אז החיסרון זה בעצם קצת לגבי מה התפיסה שלי של פרודקט, שזה לא פרודקט טוב, פרודקט שבדרך שבה אני עובד, פרודקט שאני מרגיש כאילו שבאמת כאילו שהתיאום ציפיות איתו הוא טוב, אוקיי? שזה, הפרודקט צריך להביא, זה שוב, בעיה שלי, איזשהו דאטה, איזושהי נקודת מבט שלי אין, אוקיי? כי אם אנחנו עכשיו מדברים רק על ה-UI/UX, ואני אומר, לדעתי הכפתור פה צריך להיות למעלה וזה צריך להיות למטה, והוא אומר, לא, לדעתי זה למטה וזה למעלה. אז אוקיי, אז מה, אנחנו עכשיו במאבקי כוח, כאילו ש... עזוב, אוקיי, לקחת. זאת אומרת, אנחנו מדברים על משהו תאורטי UI/UXי. מה שיכול לנצח את הוויכוח הזה, או לאחר, תשמע, הפרודקט יכול להגיד, תשמע, הראיתי את זה לשלושה לקוחות. שלושתם אהבו את האופציה הראשונה. אוקיי, אין לי מה להגיד. מעולה, בדקת, מצוין. הבאת דאטה מבחוץ, או לחלופין, הבאת דאטה אנליטי. מתי יש לנו מוצר אחר שבו זה הפוך, ושם זה לא עובד, אז בוא נעשה כאן משהו אחר. אוקיי, עוד מידע. או שהביזנס אמרו, אנחנו חייבים לעשות את זה דליבר למחר, אז פשוט תעשה את הכי מהר. אוקיי, זה גם input שלי אין בתור מי שמסתכל על הביטים. כן, אם מביאים מידע מבחוץ,

אייל דוד: [23:13] זה, פה הפריה הדדית היא באמת לא על נכונות של הפיצ'ר, או נכונות במרכאות, כן, של ה-UI, שיהיה נכון גלובלית כזה.

Confidence בהערכות ואיזון בין budget ל-scope

סטס וישנבצקי: [23:23] כן, תראה, אני חושב שזה תמיד נכון. עדיין, יש דברים שאין עליהם תשובות, ואז, אתה יודע, וזו באמת עבודה הדדית, דווקא אני כפרודקט מאוד מעריך שמהצד לשמוע את כל חברי הצוות, ויחד לגבש בעצם משהו שעושה שכל, וגם מבחינת ה-ROI של כמה שהוא עולה, שהוא עושה שכל. אז זו לגמרי הפריה הדדית, אני חושב, בהיבט הזה. בהיבט של back end, סטס, יש גם הרבה לוגיקות שאולי אנחנו יכולים לחשוב איך לרדד אותן, או איך זה, אז אתה גם ככה מגיע בעצם עם הצעות. כן, האמת שכאילו, הנקודה של הערכות זמנים היא נקודה מאוד רגישה, במיוחד אצל מנהלי פיתוח בתחילת הקריירה שלהם, זו נקודה שיש הרבה מאוד שיח בין פרודקט למנהלי פיתוח, על נניח שאנחנו עושים את איקס, כמה זה יעלה, כמה זמן זה ייקח, והשיחות מהסוג הזה. אני חושב שדרך פרגמטית, שברגע שאני הבנתי אותה, זה הוריד, ניטרל ממני הרבה מאוד מהלחץ סביב השאלות האלה, זה ההבנה שבעצם בשיחות של הערכות זמנים, המימד שאפשר לשחק איתו הוא confidence. ועם פרודקט, בשלבים, תהליך התכנון הוא משהו איטרטיבי, הוא לא כאילו זמן וגמרנו. יש תהליך תכנון שנתי או רבעוני או של האיטרציה הקרובה של הספרינט הקרוב של השבועיים הקרובים, והתהליכים האלה הם משתנים כל הזמן בצורך שלהם בדיוק ובקונפידנס. אז כשיבואו, כשנתכנן את הרבעון ונשב בין פרודקט ופיתוח, ואנחנו נחשוב על פיצ'ר כזה, פיצ'ר אחר, הערכות הזמנים הממש בול פארק של small, medium, large או שמונה שבועות, ארבעה שבועות, שבועיים, זה משהו שיכול לתת את הסדרי גודל או את ההבנה של האם כדאי או לא כדאי עסקית להיכנס להרפתקה הזאת. זה בעצם מה שפרודקט צריך, פרודקט תמיד ירצה למצוא את הבנפיט הטוב ביותר בין כמות הזמן שאני אשקיע, שזה בעצם budget, ל... המאמץ עצמו. כן, וכאילו, מה אני מקבל מזה? איזה ביזנס KPI אני אקדם ובכמה? האמת, אם השאלה שאלת בהתחלה מה הכלי הכי חשוב של פרודקט, אז אולי זה זה בעצם. זה היכולת to balance בין budget ל-scope. ROI, בעצם.

אייל דוד: [25:47] אתה תעדף על פי זה. ואתם מרגישים שמהצד של פרודקט, פרודקטים שעבדתם איתם, אז ההערכות מהצד העסקי הן נכונות בדרך כלל? אתם מקבלים אותן בכלל? יש dollar sign על כל פיצ'ר שאתם עושים? הרי זה לא תמיד שחור ולבן. אם אנחנו גם נדבר על, יש דברים שאנחנו עושים לצורך שיפור חוויית משתמש, יש דברים שאנחנו עושים לצורך technical debt בכלל, נכון?

סטס וישנבצקי: [26:13] כן, האמת, אני חושב שמאוד קשה לתת מחיר או רווח פוטנציאלי שיגיע. יש חברות שממש טובות בזה, יש חברות שבהן הדאטה הוא כל כך זמין, שאתה יכול ממש לדעת. אני זוכר, נגיד, בעבר בוויקס, אז כל פיצ'ר יוצא כ-A/B Test, ואפשר ממש למדוד את ה-KPI ואת ההשפעה של כל פיצ'ר, וגם באופן דיפנסיבי, ההשפעה של פיצ'ר על KPI שהם פוטנציאלית לא קשורים. ואתה יכול לעשות הרבה מאוד מחקר, עוד לפני שאתה נכנס לפיצ'ר מסוים, בשביל להעריך את הרווח שאתה תשיג מהפרויקט הזה, ואז כזה to balance between the effort and the KPI. אבל יש פרויקטים שהם לא ככה. גם במיוחד ב-accessibility, נגיד, זה לא... זה לא בהכרח שאתה נכנס לשפר אקססביליטי או לעבוד בסטנדרטים של אקססביליטי בגלל רווח. יש דברים שהם פשוט נחוצים. או GDPR, או סקיוריטי, יש כל מיני קונסרנים בעשייה שלנו שכזאת.

אייל דוד: [27:12] כמו במליאת בית, כשהוא לא ייפול, זה לא מייצר רווח עסקי, אבל זה נחוץ. זה ממש נכון, אתה יודע מה חשבתי כשדיברת על Wix, לצורך העניין, חברה שעובדת עם A/B testing. אוקיי, אז תמיד שמים איזושהי הערכה, על כמה שווה לנו להתמקד עכשיו בפיצ'ר הזה, אולי אפילו שמים על זה אפילו איזשהו איזשהו טי-שירט סייז או דולר סייז או וואטאבר. אף פעם לא מכמתים את העניין של, אוקיי, זה לא יצליח בפעם ראשונה, ואז אנחנו נעשה איטרציה, זה ייקח זמן, זה ייקח זמן פיתוח, פעם שנייה, פעם שלישית, כמישהו שעבר את זה, אז אף פעם לא מתייחסים לדבר הזה, וזה דבר, ממד, של ממד הריסק, שאף פעם לא מתייחסים אליו. אם גם מדברים על תיאום ציפיות, זה, לדעתי, משהו שהיה מאוד עוזר. אז אני חושב שמעבר לזה, יש תמיד גם מתחים, אתם הזכרתם את זה סתם בשיחת קפה לפני, של, אוקיי, מתי אנחנו מתעדפים בכלל דברים שחשובים לדב? מתי הדבר הזה נכנס, נכון? אז כל עולם התעדוף הוא קשוח מאוד. זה דבר שהיום אתם מרגישים שיותר מתמקדים בהיבט של סקיילביליטי, אז אולי נותנים לזה יותר דגש בעצם?

איך מתעדפים חוב טכני ופרויקטי תשתית

אסף שוחט אבידע: [28:17] אני חושב שיש הרבה ערך. כמו שאני מצפה שהפרודקט ידע לתרגם את הדרישה שלו לשפה שאני מבין, כלומר, ייקח את היעד של למכור פי 500 את המוצר ויתרגם אותו ל... תעשה חמישה כפתורים, כן? או תעשה API חדש, אני מצפה מה-Engineering שידעו לקחת את ה-Backlog וידעו לתרגם אותו לשפה של פרודקט, ואז אני אהיה אפקטיבי. אני אתן דוגמה. בבקשה. אוקיי? נגיד שיש לי עכשיו, שוב בעולמות רביעי יש לי ספרייה תשתיתית של קומפוננטות. נגיד, סתם דוגמה. אוקיי? עכשיו, להכניס אותה, ויש כמה מוצרים, ואחד המוצרים לא משתמש בספרייה הזאת, לא חשוב שמות. בסדר? עכשיו, הפרויקט הזה של לגרום לו להשתמש, זה פרויקט שהוא ייקח זמן, איקס זמן, סדר גודל, נגיד סתם, ייקח חצי שנה. אוקיי? אני מגזים. בסדר? בשביל שאני אתעדף אותו, כן? אני רוצה שהפרודקט יבינו למה אני רוצה לדחוף את זה. כן? למה הדבר הזה יגרום בסוף לוולוסיטי יותר גבוה? כי זה יגרום לשיתוף פעולה בין הצוותים. זה יגרום לזה שכולנו נעבוד באותו סטק טכנולוגי. זה יגרום לזה שהאקססביליטי יהיה יותר טוב, כי נשתמש בקומפוננטות שהן בספרייה הכוללת. מונגשות. והן כבר מונגשות, כן? אז אם אני צריך לעבוד ממש ממש חזק בשביל לשכנע את הפרודקט, זאת אומרת, אני שם את זה לעצמי בתור בתור אתגר, ככה נכון לעבוד. להכניס אותם לתוך הבקלוג. פשוט יש דברים שהם לא מעניינים, שהם טיקטים שהם קטנים מאוד, שלוקחים יום-יומיים עבודה, אפילו עד שבוע, חבל על הזמן. יש תקציב לטכניקל בקלוג, נעשה אותם. הדברים הגדולים, אני רוצה לתעדף אותם לא מתחת לשולחן, אני רוצה לתעדף גם שהפרודקט גם בסוף ידע להגיד לי, תשמע, עשית את זה, למה, איפה השיתוף פעולה? כן, זאת אומרת, שיעזור לי לעשות את הבקרה, כי פרודקט בסופו של דבר הוא גוף, עברתי על מונחים צבאיים, הוא גוף מכווין, הוא גוף שעושה גם בקרה על הפיתוח מאיזשהו מקום, גם על התהליכים. אני רוצה לעצור אותך באמצע דוגמה ולשאול שאלה,

אייל דוד: [30:22] אז אוקיי, הכנסת דבר כזה, נגיד והצלחת, יש עליו איזה שהם KPIs? הרי כל דבר שאנחנו עושים בא לשרת משהו, נכון? גם כולנו עובדים באותה חברה, לכולנו יש אותה מטרה עסקית, לבנות את הבניין ובסוף למכור אותו, אבל איך, כאילו, המטרות הן טיפה שונות בסוג הזה של פרויקט, אז איך זה משתלם? אז לצורך העניין, כאן ה-KPI פה הוא,

אסף שוחט אבידע: [30:42] זאת אומרת, יכול להיות שהוא יותר רך, לאכול את זה, למשל, שאני רוצה לראות שבטווח של שלושה חודשים מאז סיימת את הפרויקט, אז עכשיו לפרודקט יש לו אפשרות לתעדף, זאת אומרת, לעשות הסטת משאבים בין שני צוותים לאותו פרויקט. למשל, או למשל, אם שנייה נסתכל על זה, אז אתה אומר שרמת ה-quality תעלה over time, נכון? אז למשל, ה-UI designer, כן, או ה-UI Specialist, לא יצטרך לתכנן את הקומפוננטה פעמיים, כי ברגע שהוא יגיד לצוות פיתוח, תוסיפו פה drop-down, אז הם יגידו, אה, אוקיי, יש לנו כבר drop-down, אל תחפור, לא צריך לחפור על זה, ניקח את מה שקיים, וזהו. אני רוצה לגעת בנקודה, לתת איזושהי אנלוגיה, ה-KPI שבפיתוח לפעמים מנסים לעשות את זה במטריפיקציה, כמו למשל ה-velocity, או מה שאמרת, נגיד אם אנחנו נשנה את הקומפוננטה באופן שבו בעתיד יקל יותר לעשות לה accessibility, והיא תשתלב באופן טוב יותר. זה דברים שלפרודקט לפעמים מאוד קשה לתעדף אותם, כי הצורך שלהם יותר אסטרטגי מאשר טקטי. זה קצת כמו איך לגשר על הפער התקציבי במדינת ישראל בעקבות המלחמה. אפשר להעלות מע"מ, זה פתרון נגיש, קל, מהיר, ומיד מכניס כסף לקופה, ויש דברים כמו, באופן אסטרטגי אנחנו רוצים להעלות את הפריון של כל תושבי מדינת ישראל, ולהשקיע בזה, זה גם השקעה יותר גדולה באפורט, וגם כאילו ה-ROI שלה הוא רחוק יותר. ולפרודקט, כאשר ה-KPI, נגיד קונברז'ן הוא KPI מהותי וחשוב, אז לעשות איזשהו שיפור accessibility בקומפוננטה מסוימת שתשפר את מהירות הפיתוח בעתיד, זה משהו שמאוד קל לפרודקט להחליט שלא לתעדף. ויש מצב שזה הגיוני. הקושי נראה לי, וזה מעניין אותי לשמוע ממך, איך אתה עושה את זה, איך אתה משכנע את פרודקט, איך אתה מעביר את הנקודה שעכשיו זה הזמן הנכון להעלות את הפריון של תושבי מדינת ישראל, או לשפר את הקומפוננטה. דבר ראשון, יכול להיות שעכשיו לא הזמן הנכון. יכול להיות. יכול להיות שעכשיו הפרויקט הזה צריך לצאת לבטא בעוד חודש, ועכשיו זה לא הזמן הנכון, ואני מקבל את זה. כן? זאת אומרת, הדעה שלי היא דעה, זה יכול להיות שהיא נכונה, יכול להיות שהתזמון לא נכון, יכול להיות שבכלל הפרויקט לא נכון, יכול להיות שזה פרויקט שילך לכיוון אחר, ולא צריך לזה. אבל אם כן, זה הכל, הכל מגיע לנקודה של אמון. זאת אומרת, אני מצפה שהפרודקט, זאת אומרת, לא יאמין לי באופן עיוור, כן? זה לא עניין של להאמין בלי לבדוק, אבל שתבין שהמניעים, אם המניעים שלנו הם אותו דבר, אנחנו חושבים שנינו לטווח רחוק. זאת אומרת, אם יש כאילו פיתוח שחושב לטווח קרוב ופרודקט שחושב לטווח רחוק, זה בעיה. אם יש פיתוח שחושב על מה שיעזור לנו בעוד שלוש שנים והפרודקט מעניין אותו עכשיו, עכשיו, עכשיו, זה גם לא יעבוד. נכון, לגמרי. מה שאולי אפשר להסכים, זה שנייה חושב בראש טיפה יותר יזמי, זה...

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

אסף שוחט אבידע: [34:25] אז בעצם אני מנסה לבנות, זאת אומרת, דבר ראשון, לבוא, יש מקרים שבהם ה-R&D הוא הפרודקט. זאת אומרת, R&D צריך לבוא, שיש לי עכשיו קייס, אני בונה PRD. כי אני אומר, זה, זאת אומרת, אני לא מצליח לעשות אינטגרציה. אני אומר, מה זה אומר? מה השלבים? מה ה-definition of done שלי לאינטגרציה הזאת? כי אינטגרציה בין שתי מערכות יכולה לקחת גם נצח. אני אומר, לא, יש לי איזה שלב ראשון. זה שלב שני, זה שלב שלישי. השלב הראשון יש לו תועלת בפני עצמו, תגידו לי, יש תקציב רק לזה? נלך על זה, אני מעדיף עד לשלב שלוש. אבל אם יש תקציב לשלב הראשון, אני לוקח.

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

שפה משותפת, טראסט ו-North Star

סטס וישנבצקי: [35:25] באיזושהי רמה. אני חושב שגם קיימת ציפייה הפוכה, שמפיתוח לדבר מוצרית. זה המשך המשפט. כן. בדיוק. אני חושב שככל שהקריירה שלנו מתקדמת, כאילו נגיד כ-Engineers אנחנו מתפתחים או לתפקיד של הובלה טכנית או הובלת אנשים, אתה נחשף יותר לממשקים עם מקצועות שונים, כמו נגיד פרודקט, או לפעמים גם דאטה, או אנחנו רחמנא ליצלן DevOps וקוברנטיס, אבל גם זה צריך לפעמים, או AI, ואז אתה לומד לעשות חלק מהיכולות של אנשי המקצוע האלה, ואתה מפתח גם שפה משותפת לאיך לעבוד איתם ביחד. אני חושב שקודם דיברנו, נגענו בטראסט כמה פעמים. אני חושב שכאשר קיים הטראסט, אז אפשר באמת לבנות מערכות ביחד באיזושהי הרמוניה כזאת, שבה אנחנו מדברים באותם מונחים, ואנחנו מתכננים את אותו בניין שאנחנו נבנה בסופו של דבר. אבל בינתיים, טראסט הוא משהו שהוא לוקח זמן לבנות, גם במערכות יחסים פרטיות, כאילו זוגיות וכל מיני דברים כאלה. אבל בינתיים, הדרך של לפצל את הריסורסים, כמו שציינת מקודם, נגיד יש הרבה חברות שכאיזשהו כלל אצבע, נגיד מחלקים בין הפרודקט בקלוג לטכניקל בקלוג, כ-80%-20%, 20% טק בקלוג, ואז הפריוריטיזיישן והעבודת מוצר של הבקלוג הזה תקרה על ידי אנג'ינירינג. אני חושב שזה פתרון פרגמטי, קצר טווח, לא רע בכלל, אבל זה לגמרי לא כזה החזון, אני חושב שמשהו שיכול מאוד לעזור בבניית הטראסט הזה, או כזה שיתוף פעולה בין פרודקט לאנג'ינירינג, הוא איפשהו בשלבים יחסית ראשוניים של בניית המוצר, לשבת ביחד על איזשהו נורת' סטאר, על איזשהו כזה כוכב צפון, לאן אנחנו מכוונים, גם מנקודת מבט מוצרית, גם מנקודת מבט פיתוחית, ולהגיע להסכמות. וכשההסכמות האלה קיימות, זה איזשהו חוזה או מכנה משותף, שכל פעם שצץ הדיון של בוא נוסיף API לכרטיסי אשראי, והאם עכשיו גם נתמוך בבנקים, אז אנחנו נוכל לשלוף מהמגירה, את הנורת' סטאר הזה, או חוקה כמו במדינה. תהיה מתוקנת. מתוקנת. ולהתייחס להאם זה הזמן או לא הזמן, האם זה נחוץ, האם נגיע לשם בכל מקרה.

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

סטס וישנבצקי: [38:13] כן. אתה מכיר את המונח Work Wife? כן, זה נקודה רגישה, אשתי, נגיד, ממש שונאת את המונח הזה. ולי זה עוזר, האמת, שאשתי ב-HR, אז כאילו, יש לי הרבה יכולת להתייעץ על הדברים האלה גם בבית. אבל יש, המערכת יחסים הזו בעבודה, היא מערכת יחסים של שותפות. זה לא במקרה שבארגוני תוכנה, אנחנו בדרך כלל רואים מוביל טכני יחד עם מוביל מוצרי. הם צמדים. כי ביחד אלה שני מקצועות שנחוצים בשביל להוביל כל כזה מחלקה עסקית או זה, והשיתוף פעולה ביניהם, היכולת שלהם לתקשר באופן אפקטיבי והיכולת שלהם לסמוך אחד על השני, שהטיעונים שכל אחד מביא לגבי בעד או נגד, הם גם מסתכלים באיזושהי נקודת מבט גם על הצד השני. כשהטראסט הזה ייבנה, אז הם אפילו יכולים להחליף אחד את השני באיזשהו מובן.

אייל דוד: [39:11] על זה קמים ונופלים סטארט-אפים. בעצם הדבר הראשון שאתה מחפש זה CTO או ההפך, ואם אין שם את הטראסט הזה או את מערכת היחסים. לגמרי. להחליף לא נשמע מעניין, אתה מכיר מקרה כזה?

סטס וישנבצקי: [39:25] כן, נגיד, יצא לי לא מעט פעמים שבהם לא היה לי את הפרטנר הזה, לא היה לי נגיד מקבילה מוצרית. ואז נגיד, חברי הצוות, מאוד חשוב להם שיבנה איזשהו חזון, אנחנו הולכים, מה המטרה של המוצר הזה, אחרי הבניין שנבנה, איך תיראה השכונה. נתת ל-ChatGPT לכתוב לך ויז'ן? כן, זה היה לפני ChatGPT. אבל נגיד, היום זה קל יותר עם ChatGPT, כמו שאתה אומר. וזו נקודה שקשה לעשות אותה כשאין לך את המקבילה המוצרית, ואז לפעמים אתה מוצא את עצמך עושה את זה, או כמו שאתה סליחה קודם אמרת, שאתה מוצא את עצמך כותב PRD. שכאילו, פרודקט הוא לא המקצוע שלך, אבל אתה מרגיש שלפעמים זה נחוץ לשימושים מסוימים. וגם, אתה כנראה לא תעשה את זה באופן מיטבי כמו שפרודקט יעשה את זה, אבל זה כן משפר איזושהי זווית של הפרויקט הזה שאתה הרבה מנסה לקדם.

אייל דוד: [40:21] אני חושב שזה מאוד מעניין, כי גם יש פה המצב שבו R&D כותב את ה-PRD, שהוא PRD לא טכני, שהוא PRD, זה תת-נושא אחר, כן, שה-R&D מזהה שחסרה פה דרישה מוצרית, אז הוא בונה מסמך מוצרי. ואז יש פה קצת שאלה של מי שמך, מצד אחד. מצד שני, זאת אומרת, זה יכול ליצור שקט, זה ייצור שקט ב-Engineering כשיש vision, אבל זה יכול להיות גם ה-vision הלא נכון, כן, שפה, כלומר, אתה בא עם הרבה מאוד ביטחון לפתח את הדבר הלא נכון, כי אתה עשית לעצמך את הדרישה.

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

אייל דוד: [41:23] ואם נסכם אותן, הן בסופו של יום מסתכמות בתיאום, ממש בקטע זוגי, בעצם תיאום ציפיות, שפה משותפת וטראסט. זה ממש, יש לכם איזה שהן המלצות, איך אפשר, סטס, העלית את זה כמה פעמים, אבל יש איזה שהן המלצות שאפשר לאמלק פה, שבעצם, אפשר להאיץ את התהליך הזה, אם מישהו נמצא בקשר זוגי לא טוב? לי יש,

המלצות: בלי שטויות, ניצחונות משותפים ו-EQ

אסף שוחט אבידע: [41:45] המלצה לשני הצדדים, שזה לא להתעסק בשטויות. אוקיי, מה זה אומר לא להתעסק בשטויות? יש כלל אצבע שהוקם בהרבה חברות, שאומר שמשימות שהן, נגיד, בנות יום או יומיים, לא צריך לדבר עליהן, פשוט צריך לעשות אותן. אוקיי, למה? כי אם עכשיו על כל פיפס קטן שאני רוצה לעשות, אני רוצה לכתוב טסט לפונקציה הזאת, אני רוצה להעביר את הקובץ מפה לפה, אני אבלבל גם לראש צוות שלי וגם לפרודקט שלי את המוח, אז אני עושה הצפה של מידע, וזה לא עוזר לתמונה הגדולה. אני רוצה שפרודקט יחזיק את התמונה הגדולה. לא לבלבל את השכל עם דברים קטנים. אם מבלבלים את השכל עם דברים יותר מדי קטנים, זה אומר שיש לנו פה בעיה בתהליך.

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

סטס וישנבצקי: [42:35] אני חושב שגם לי יש משהו לחלוק, אני חושב ש... מקודם נגעתי בבניית כזה כוכב צפון, North Star, אני חושב שזה דבר שיכול ממש לעשות בוסט משמעותי לטראסט בין שתי הפונקציות האלה, בין פרודקט לאנג'ינרינג, וגם בגלל התהליך הנדרש בשביל לבנות דבר כזה, והאמת שזה אולי כאילו נושא לפרק כזה בפני עצמו, אבל התהליך של בניית כוכב צפון בין אנג'ינרינג לפרודקט הוא כזה שייצר טראסט אינהרנטי מעצם התהליך, או שהוא ייכשל ואז כאילו הטראסט הזה יישבר, או זה גם משהו בונה את זה. עוד משהו, אני חושב שזה ניצחונות משותפים. אני חושב שכשמסיימים לבנות בית בדרך לבניית השכונה, כשמסיימים לבנות בית, לחגוג אחד עם השני את הניצחונות שצברנו במהלך הדרך, הקומה הזאת שהשתבשה ואז הצלחנו לסדר אותה, דברים כאלה. לאנץ' גדול, עבודה עם לקוחות, פשוט כזה לעודד אחד את השני, כמו בזוגיות. ממש.

אייל דוד: [43:36] אם אתה נכנס לדיאטה לשם הסולידריות, ואתה מצליח לעודד גם את הצד השני, אז כזה לעודד אחד את השני.

סטס וישנבצקי: [43:46] עוד דבר שנגענו בו פה די הרבה זה תקשורת פתוחה. ומשהו נוסף כזה, זה מעולם, זה טיפה רגיש. לא מתאים לי בתור בקאנד אינג'ניר להגיד את זה, אבל אימושנל אי-קיו גבוה הוא משהו שמאוד נחוץ להצלחה עסקית בסביבה שבה אנחנו עובדים. יש הרבה מאוד מהעשייה שלנו שהיא מבוססת על קולבוריישן. לא תמיד האיש החכם ביותר או המוצלח ביותר בכתיבת קוד קוברנטיס הוא זה שזוכה במטרות עסקיות. לפעמים זה דווקא השיתוף פעולה בין אנשים. ואז, בעולם של שיתוף פעולה, אז לייצר אמפתיה עמוקה בין אנשים, והיכולת לזהות בצד השני שמדבר, כשהוא מדבר על, לא יודע, מקום מסוים שבו יש technical debt מאוד גבוה וזה פשוט, זה מייצר חוויה פיתוחית לא נעימה. משהו שגם פוטנציאלית לא יודע, אם זה יכול לגרום לאנשים לרצות לעזוב את מקום העבודה שלהם או סתם להיות לא מרוצים. לראות גם את זה, לראות שגם לזה יש מחיר, הוא לא ביזנס KPI, הוא לא קונברז'ן, קונברז'ן, אבל הוא עוד איזשהו Lagging Metric, כמו ה-Velocity ו-Quality, שהם חשובים באופן אסטרטגי להשיג את המטרות.

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

סטס וישנבצקי: [45:23] כן, לינקדאין זה מעולה. מדיום, בלוגים שאני כותב. אה, מה, מה, מה, לא ידעתי? גדול. לא יודע אם עברתי את חוק השש, נכון? דיברנו קודם עם הקפה.

אייל דוד: [45:32] מתי אתה הופך להיות הבלוגר? כמה בלוגים צריך בשביל להגיע למסה הקריטית של הבלוגר? אז אנחנו נקווה שעד שזה יתפרסם כבר יהיו לך שישה.

אסף שוחט אבידע: [45:40] אז גם אני בלינקדאין, תשלחו הודעה, תגידו שלום. מה, מה, ואצלך גם יש לינקים לסרטונים? כן, יש לי אתר פוגרמן.נט, שם תוכלו למצוא את כל ההרצאות ועוד 13-13 בלוגים שעברו את כלל השש.

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

המלצת ספר: Peopleware

אסף שוחט אבידע: [46:05] אולי ברמת החברה שלו, אולי בכלל ברובד הבסיסי, מה אתם ממליצים? אני רוצה להמליץ על ספר שהוא לא על להבין דברים טכניים. אם אתה פרודקט שהוא בא... יש הרי מלא סוגים של פרודקט, כן? אם אתה בא להכווין צוותי מוצר שזה בעצם פרונט-אנד פולסטאק מהכיוון הזה, שווה שתלמד קצת HTML, להבין קצת את העסק. אני רוצה להמליץ על ספר שקוראים לו Peopleware, שהוא מדבר דווקא על הדינמיקה. הדינמיקה בין צוותים, בין אנשים, הוא פונה לאנשי תוכנה, אבל לא רק, אין שם הרבה קטעים של קוד, הוא ספר די ישן, אבל מאוד מאוד מוצלח. מהנה. מגניב. טוב,

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