איזה יופי, מקנא במתכנתים שיעבדו עם מנהל מוצר שאכפת לו.
יש את הדברים הבסיסיים שכולנו יודעים ולא בהכרח זוכרים:
1. כשאתה מתמודד עם בעיה, לאורך זמן אתה המומחה שלה, אתה נמצא בקו ה21 ק"מ שלה. כשאתה מציג אותה למישהו שלא מכיר אותה, צריך לזכור להסביר את הדברים מהמטר הראשון. כאן נכנס גם העניין שכתבתי קודם מבחינת להסביר את מה שמחפשים לפתור והמסע שהביא אותך לפתרון המוצע.
2. באותו אופן בטיימליין מקביל, למתכנת יש את הבעיות שהוא רואה ומכיר, מבחינה טכנית, באזור הזה שאתה רוצה לגעת או לשפר. צריך להכיר בזה. אתה כמנהל מוצר רוצה להכיר את זה מכמה סיבות עיקריות:
2.1 לא לירות לעצמך ברגל בעתיד עבור דברים שתרצה לעשות בהמשך אבל יהיה קשה יותר לממש. בין אם זה חוב טכני, בין אם זה אזור לא יציב, אזור שאין עליו טסטים ואין ביטחון לבצע בו שינויים וכו'.
2.2 האק אנושי, אם תבוא לקראת הצוות הטכני ותתמחר פיצ'ר כלשהו יחד עם חוב טכני שהם רוצים לפרוע או יחד עם מהלך הנדסי שנכון מבחינתם לעשות: זה יעשה טוב לשני הצדדים גם לטווח הארוך. או במילים אחרות, כמו שהיינו רוצים שלמתכנת יהיה אכפת יותר מהמוצר, יהיה נחמד אם גם למוצר יהיה אכפת מהמתכנתים.
יצא לי כמה פעמים לראות שכל מיני פיצ'רים לא קשורים התעכבו כי אינדיבידואלית היה יקר לבצע אותם, אבל הסתבר שמאחורי התמחור היקר שלהן עמד אתגר טכני שהיה צריך לפתור. בארגונים גדולים זה מתפספס. פתאום כשאל מול חוב טכני כלשהו יש 20 דברים בחשיבות בינונית, החשיבות של החוב הטכני עולה בכמה מונים.
2.3 אל תיתן לסעיף הקודם להפוך למסחרה שאתה מגיע מראש עם הרבה כדי לצאת עם מה שבאמת רצית. עדיף לא לייצר סביבת עבודה עם אינטרסים כאלה.
כמה נקודות נוספות:
1. מתכנת שהוא product-oriented הוא נכס אדיר בעיניי. אם גם אתה תראה את הדברים האלה ככה, זה מתכנת שמאוד קל לשמר ולעניין בעבודה כשאתה מערב אותו יותר במחשבות המוצריות שלך. יותר קל לרתום מתכנתים כאלה למטרות שאתה רוצה להשיג, ואתם גם עשויים להפרות אחד את השני בפתרונות טובים.
2. אתה יכול להגדיר SCOPE של עבודה על פיצ'ר מסוים, ולתת לצוות לעבוד עליו.
אם ה-SCOPE השתנה, קח בחשבון שבחלק נכבד מהמקרים זה עשוי לעכב את תאריך הסיום ביותר ממה שהיה עולה לבצע את השינוי מלכתחילה. קצת דומה לכמה מהר תוכל להחזיר ירידה של 20% בתיק ההשקעות שלך.
שינויים ב-SCOPE של המשימה זה משהו שלא כ"כ אוהבים, לעיתים זה גורר שינויים קלים יחסית, ולעיתים זה קצת כמו לבנות מחדש יסודות של בניין 2 קומות לפני שתוכל להמשיך לבנות את הקומות הנוספות. המתכנת נקרע בין להוריד את כל הבניין ופשוט לבנות מחדש, לבין להתאים את ה2 הקומות שכבר נבנו לצרכים החדשים בקומה ה3 והרביעית. אתה לא צריך להימנע מלבצע שינויים, אבל הבנה ואכפתיות ללמה שינוי כלשהו מתקבל בחוסר שמחת חיים ומייקר את הפיתוח זה משהו שיכול לעזור מאוד בתקשורת.
3. אם אתה רוצה הגדרת זמנים מדויקת למשימות, קח בחשבון שזה לא באמת אפשרי.
כדי לקבל הערכה כמה שיותר מדויקת, צריך לרוב להשקיע הרבה זמן בתכנון המשימה, יש משימות שזה ממש כבר מאלץ אותך להתחיל לתכנת אותן כדי להבין למה אתה נכנס.
אל תצפה לקבל הערכה מדויקת אם לא ניתן מספיק זמן להבין את המשימה עצמה.
אני באופן אישי מנסה להימנע מלעבוד בצורה כזאת מלכתחילה. אני נותן סדרי גודל... בסטארטפים בכל מקרה אין באמת מספיק זמן לאפיין הכל כראוי ולתמחר כראוי אז אני בעד פלואו של צעדים קטנים כל פעם.
4. אם אתה לא עובד עם ראש צוות אלא ישירות עם מתכנתים, תנסה להבין עם איזה מתכנתים אתה עובד. יש מתכנתים שממש מאוהבים בטכנולוגיה והם אוהבים לתכנת דברים. בסקאלה שלי, בצוותים שאני מנהל, הם בצד השני של ה-product oriented.
עם כל ההבנה וההקשבה למתכנת שמסביר למה משהו צריך להיעשות כך או אחרת. יש כל מיני דרכים לפתור ולפתח כל מיני דברים. יש מתכנתים שיקפצו על ההזדמנות לממש פתרונות מוגזמים יחסית למה שבאמת נדרש. ראש צוות טוב ידע הרבה יותר טוב ממך לראות ולאזן את זה, אבל אם אתה נאלץ לעבוד ישירות מול קבוצה של מתכנתים, תדע שיש אופי מסוים של מתכנתים שהוא לא בהכרח פרגמטי - במיוחד לסביבת סטארטפ שצריך לזוז מהר.
5. ואני יודע שאני חוזר על עצמי כך או אחרת אבל זה פשוט חשוב: מתכנתים לא אוהבים לעבוד סתם. הבנתי עם השנים עד כמה זה מבאס לייצר פיצ'רים מיותרים או יכולות מיותרות שאין בהן צורך. אולי אתה צודק בנוגע לק"מ ה42 שאתה רוצה שמוצר כלשהו יגיע אליו, אבל אולי לא נכון להתחייב לזה כרגע? אולי תתחילו עם ה10 הראשונים (בידיעה חצי מתוכננת מה השאיפה/חזון..), תשיקו את זה, תחוו קצת פידבק, ואז תמשיכו הלאה?
אין פרופורציה תואמת בין התחושות שנוצרות בעקבות צורות פיתוח שונות. לעבוד על משהו הרבה זמן ושלא משתמשים בו זה כואב יותר מאשר השמחה כשעובדים על משהו הרבה זמן וכן משתמשים בו. הכי טוב בעיניי זה לפרק משהו לכמה חלקים וליהנות מניצחונות קטנים לאורך זמן, או "להיכשל" מוקדם יותר במסלול. זה מצמצם את הסיכון ברמת הפיתוח והמוצר, בנוסף לתחושה של הצוות.
באופן כללי, יש אופיים מאוד מגוונים בתעשייה. אני תמיד מנסה להבין עם מי אני עובד ולמה משהו קורה או נאמר כמו שהוא ופועל לפי קווים מנחים יחסית עקביים שתיארתי בתגובה הקודמת. סביבות לחוצות מביאות אנשים לסיטואציות לא פשוטות, לא צריך לקחת הכל ללב, ולא צריך בהכרח להיכנע ללחץ, אפשר לעבוד איתו.
