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

מכאן, הפוסט ייכתב בגוף ראשון בשם דוד.

פרודקט? למה?

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

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

החלקים הטובים יותר

השפעה

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

משמעות

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

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

שיפור היכולת הלשונית

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

מקצוענות

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

פחות התאים לי

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

עבודה מסדר ראשון

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

חשיבה לוגית

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

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

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

הנעת אנשים

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

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

כתיבת מסמכים

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

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

סיכום

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