לפני שהגעתי לחברה הנוכחית, עבדתי במשך כ-3 שנים בסקראם, בתור product owner. בחברה הנוכחית חזרתי לתפקיד פיתוח, והגעתי כדי להרים פיצ'ר גדול חדש (לאחר תקופת לימוד של המערכת שכללה כמה פיתוחים קטנים במערכת הקיימת).
התובנה המרכזית שלי מתקופת הסקראם בחברה הקודמת, היתה שכל מפתח רציני בחברה שמנסה לייצר מכירות של המוצרים שלה (להבדיל מחברה שמנסה לייצר בעיקר טכנולוגיה) צריך לפתח תפיסה עסקית של האירגון. זה שם את העבודה שלנו בפרופורציות - אני לא מפתח משהו "כי זה נכון הנדסית" - אלא "כי זה יתרום מבחינה עסקית".
כשחושבים בצורה כזו, קל בהרבה "לקלף" מרכיבים מיותרים במוצר חדש, או בפיצ'ר חדש, ולהתמקד במה שיספיק כדי למכור אותו מוקדם ככל האפשר. מהצד השני, כשהמוצר או הפיצ'ר נמכר, לומדים לבסס את המשך ההשקעה במוצר או בפיצ'ר על פי המצב בשטח, ועל פי צרכים שלקוחות מוכנים לשלם עבורם (להבדיל מצרכים שהלקוחות היו שמחים שיהיו, אבל לא יגרמו להם לפתוח את הארנק).
זה גם אומר שמוותרים על תכונות שאינן דרושות למכירות הראשוניות, ומוסיפים אותן על פי התרחבות מעגל הלקוחות. זה אומר שמשקיעים מהותית ביכולות תמיכה של המוצר לפי קצב ההתפשטות שלו אצל לקוחות - יכולות התמיכה הדרושות כשיש עשרה לקוחות נמוכות בהרבה מאשר כשיש חמישים לקוחות, וכן הלאה. כמובן שזה אומר שככל שהמחיר ליחידת מוצר (כלומר פר לקוח) נמוך יותר - צריך יכולות תמיכה גבוהות יותר, כי זה לא כלכלי ולא סקיילאבילי להפיל על אנשי התמיכה פרוצדורות מסורבלות כשכל איש תמיכה צריך לטפל באלפי/עשרות אלפי לקוחות - אבל זה כן כלכלי כשכל איש תמיכה צריך לתמוך ב-5-10 לקוחות.
מה שראיתי שגם להרבה מפתחים וגם למרבית אנשי המוצר קשה להסתגל לצורת החשיבה הזו - צריך לעסוק הרבה ב"חינוך" שלהם לחשוב ככה. זה נובע משנים ארוכות של הטמעת חשיבה "מפל-מיימית" ובדיקות ידניות, והסברה לאנשים ששיכתוב חלקים מקוד קיים מהווה ביזבוז זמן. מפה נובעת הגישה להכין את התשתיות בצורה מאוד עמוקה, על חשבון הגעה לשוק, מהחשש ש"אי אפשר יהיה לתקן את זה אחר כך" - במקום לעשות את ההבחנה בין מה שיהיה קל לתקן, מה שיהיה קשה (אבל אפשרי ומעשי) - לבין מה שיהיה בלתי מעשי (ורק בו להשקיע הרבה מראש) - ועוד יותר - לתכנן מראש את המערכת לשינויים ויכולת שדרוג - בין אם זה אומר לשים מספר גרסה על כל אובייקט פרסיסטנטי, לדאוג למבני נתונים ופרוטוקולים שיהיו ניתנים להרחבה, וכדומה.
לפני כמה שבועות שוחררה גרסה שכללה פיצ'ר גדול שהתחלנו לעבוד עליו לפני כשנה וחצי. כל התיכנון היה בשיטת "קיצוץ בבשר החי" - כל תכונה לא הכרחית - עפה ל-backlog למטה. כל צורת הפיתוח היתה בסיגנון של "בואו נפתח כמה שיותר מהר משהו בסיסי שאפשר יהיה להפעיל בסביבה אמיתית - ואז נתחיל להוסיף את כל מה שמסביב. זה כלל קיצורי דרך שונים שבשיטת "המפל" לא היו מעיזים לחשוב עליהם. למשל - החלפת חלק מורכב למימוש בשליחת הודעות מוקלטות מראש בצורה ש"מזייפת" תהליך שמתבצע לפני שהמשתמש יכול להתחיל לעבוד. מימוש אמיתי של החלק הזה בוצע בהמשך ולקח לאדם מנוסה בערך חודשיים של עבודת פיתוח. או למשל טיפול קודם רק בפעולות קריאה של נתונים "בסביבה האמיתית" - כשיצירת אובייקטים נעשתה באמצעים פנימיים של סביבת הבדיקות. או למשל מימוש של פעולות לקוח "באופן ריק" במקומות שבהם זה לא מונע מהלקוח להמשיך לעבוד (ה"לקוח" פה הוא לא אדם - אלא תוכנה שמבצעת הרבה פעולות לא חשובות במיוחד מבלי שהמשתמש יבקש את זה).
הגדרנו המון איטרציות לתהליך הפיתוח, כשכל אחת מתמקדת בתכונה אחת, לפי סדר החשיבות עבור משתמשים (למעט תלויות הנדסיות שלא ניתן היה לעקוף אותן - הללו כוסו בחמש האיטרציות הראשונות מתוך כמה עשרות איטרציות שנדרשו לגרסה הראשונה) - וכל התיעדוף התבצע לאחר שיחות עם כמה לקוחות פוטנציאליים (לקוחות שהיו בפייפליין, ובהמשך גם לקוחות קיימים של המוצר שלא כלל את הפיצ'ר הזה). בשיחות הללו ניסינו למפות את הצרכים העסקיים של הלקוחות הללו ולפרוט אותן לתכונות טכניות של המוצר. זה דרש להבין מה הלקוח חושב שהוא צריך, ומה בפועל הוא באמת צריך מתוך זה. במקרים מסויימים היינו צריכים לבצע דגימה של מה שקיים כיום בסביבה של הלקוח כי הוא לא ידע לאמר אם הוא זקוק לתכונה טכנית מסויימת או לא.
אחרי חודשיים מתחילת הפיתוח (שהתחיל אחרי חודשיים של לימוד הנושא ותיכנון ארכיטקטורה) עשינו דמו ראשון (שכמעט לא עושה כלום חוץ מלהציג דף אחד עם אובייקטים מוכנים מראש) בתוך החברה, שבאופן פלאי הצליח לעבוד (לדמואים כאלו יש חשיבות מאוד גדולה - אי אפשר "לזייף" בהם יותר מדי, והם חושפים כשלים שבתור מפתח כבר "התרגלת אליהם" או לא שמת לב אליהם. בהמשך היה לנו דמו שכשל בצורה כל כך קולוסאלית, שהוא חשף להנהלה בעיה קשה בסביבת הבדיקות האוטומטיות, והוביל למיקוד תשומת לב ניהולית גדולה יותר לפרוייקט, ובהמשך להקצאת משאבים גדולה משמעותית - הן מבחינת כח אדם והן מבחינת משאבי חומרה. את מה שהתקשיתי להבהיר להנהלה במילים במשך חודש - עשה הכישלון הזה בחצי שעה). לאחר עוד חודש הבאנו דמו שני שבו ניתן היה להראות פעולות בסיסיות של יצירת ועריכת אובייקטים, וכעבור כמה חודשים הגענו לשלב האלפא - עם לקוחות ש"התנדבו" להריץ את האלפא, מתוך אינטרס לקבל מוצר שמתאים לדרישותיהם ומתוך אינטרס לראות שאנחנו נוכל לספק את הסחורה המלאה. באלפא הזו גילינו כמה בעיות, כולל אזור שבו פיספסנו בגדול בתיכנון בדיקות האיכות - אזור שקיבל השקעה מאסיבית לקראת הבטא. גם הבטא נבדק אצל אותם לקוחות האלפא (שגם ראו שיפור ניכר באזור הבעייתי, וגם ראו שאנחנו לוקחים ברצינות את הפידבק והבקשות שלהם), ולקוחות אחרים, שחשפו כמה צרכים חדשים.
בשורה התחתונה - הצלחנו להביא לשוק תוך כ-1.5 שנים פיצ'ר שבחברות דומות אחרות לקח 2-3 שנים להביא גרסה ראשונה שלו לשוק - וכבר מתחילים לראות עסקאות חדשות נסגרות בעקבותיו. סביר להניח שאת כלל התכונות של הפיצ'ר לא נפתח משמעותית מהר יותר מחברות אחרות - אבל כשנסיים אותן כבר נהיה עמוק בשוק, עם פיצ'ר הרבה יותר בשל מבחינת יציבות, מבחינת תמיכתיות ומבחינת התמקדות במה שהלקוחות באמת צריכים ומפריע להם במוצרים דומים אחרים.
התובנה המרכזית שלי מתקופת הסקראם בחברה הקודמת, היתה שכל מפתח רציני בחברה שמנסה לייצר מכירות של המוצרים שלה (להבדיל מחברה שמנסה לייצר בעיקר טכנולוגיה) צריך לפתח תפיסה עסקית של האירגון. זה שם את העבודה שלנו בפרופורציות - אני לא מפתח משהו "כי זה נכון הנדסית" - אלא "כי זה יתרום מבחינה עסקית".
כשחושבים בצורה כזו, קל בהרבה "לקלף" מרכיבים מיותרים במוצר חדש, או בפיצ'ר חדש, ולהתמקד במה שיספיק כדי למכור אותו מוקדם ככל האפשר. מהצד השני, כשהמוצר או הפיצ'ר נמכר, לומדים לבסס את המשך ההשקעה במוצר או בפיצ'ר על פי המצב בשטח, ועל פי צרכים שלקוחות מוכנים לשלם עבורם (להבדיל מצרכים שהלקוחות היו שמחים שיהיו, אבל לא יגרמו להם לפתוח את הארנק).
זה גם אומר שמוותרים על תכונות שאינן דרושות למכירות הראשוניות, ומוסיפים אותן על פי התרחבות מעגל הלקוחות. זה אומר שמשקיעים מהותית ביכולות תמיכה של המוצר לפי קצב ההתפשטות שלו אצל לקוחות - יכולות התמיכה הדרושות כשיש עשרה לקוחות נמוכות בהרבה מאשר כשיש חמישים לקוחות, וכן הלאה. כמובן שזה אומר שככל שהמחיר ליחידת מוצר (כלומר פר לקוח) נמוך יותר - צריך יכולות תמיכה גבוהות יותר, כי זה לא כלכלי ולא סקיילאבילי להפיל על אנשי התמיכה פרוצדורות מסורבלות כשכל איש תמיכה צריך לטפל באלפי/עשרות אלפי לקוחות - אבל זה כן כלכלי כשכל איש תמיכה צריך לתמוך ב-5-10 לקוחות.
מה שראיתי שגם להרבה מפתחים וגם למרבית אנשי המוצר קשה להסתגל לצורת החשיבה הזו - צריך לעסוק הרבה ב"חינוך" שלהם לחשוב ככה. זה נובע משנים ארוכות של הטמעת חשיבה "מפל-מיימית" ובדיקות ידניות, והסברה לאנשים ששיכתוב חלקים מקוד קיים מהווה ביזבוז זמן. מפה נובעת הגישה להכין את התשתיות בצורה מאוד עמוקה, על חשבון הגעה לשוק, מהחשש ש"אי אפשר יהיה לתקן את זה אחר כך" - במקום לעשות את ההבחנה בין מה שיהיה קל לתקן, מה שיהיה קשה (אבל אפשרי ומעשי) - לבין מה שיהיה בלתי מעשי (ורק בו להשקיע הרבה מראש) - ועוד יותר - לתכנן מראש את המערכת לשינויים ויכולת שדרוג - בין אם זה אומר לשים מספר גרסה על כל אובייקט פרסיסטנטי, לדאוג למבני נתונים ופרוטוקולים שיהיו ניתנים להרחבה, וכדומה.
לפני כמה שבועות שוחררה גרסה שכללה פיצ'ר גדול שהתחלנו לעבוד עליו לפני כשנה וחצי. כל התיכנון היה בשיטת "קיצוץ בבשר החי" - כל תכונה לא הכרחית - עפה ל-backlog למטה. כל צורת הפיתוח היתה בסיגנון של "בואו נפתח כמה שיותר מהר משהו בסיסי שאפשר יהיה להפעיל בסביבה אמיתית - ואז נתחיל להוסיף את כל מה שמסביב. זה כלל קיצורי דרך שונים שבשיטת "המפל" לא היו מעיזים לחשוב עליהם. למשל - החלפת חלק מורכב למימוש בשליחת הודעות מוקלטות מראש בצורה ש"מזייפת" תהליך שמתבצע לפני שהמשתמש יכול להתחיל לעבוד. מימוש אמיתי של החלק הזה בוצע בהמשך ולקח לאדם מנוסה בערך חודשיים של עבודת פיתוח. או למשל טיפול קודם רק בפעולות קריאה של נתונים "בסביבה האמיתית" - כשיצירת אובייקטים נעשתה באמצעים פנימיים של סביבת הבדיקות. או למשל מימוש של פעולות לקוח "באופן ריק" במקומות שבהם זה לא מונע מהלקוח להמשיך לעבוד (ה"לקוח" פה הוא לא אדם - אלא תוכנה שמבצעת הרבה פעולות לא חשובות במיוחד מבלי שהמשתמש יבקש את זה).
הגדרנו המון איטרציות לתהליך הפיתוח, כשכל אחת מתמקדת בתכונה אחת, לפי סדר החשיבות עבור משתמשים (למעט תלויות הנדסיות שלא ניתן היה לעקוף אותן - הללו כוסו בחמש האיטרציות הראשונות מתוך כמה עשרות איטרציות שנדרשו לגרסה הראשונה) - וכל התיעדוף התבצע לאחר שיחות עם כמה לקוחות פוטנציאליים (לקוחות שהיו בפייפליין, ובהמשך גם לקוחות קיימים של המוצר שלא כלל את הפיצ'ר הזה). בשיחות הללו ניסינו למפות את הצרכים העסקיים של הלקוחות הללו ולפרוט אותן לתכונות טכניות של המוצר. זה דרש להבין מה הלקוח חושב שהוא צריך, ומה בפועל הוא באמת צריך מתוך זה. במקרים מסויימים היינו צריכים לבצע דגימה של מה שקיים כיום בסביבה של הלקוח כי הוא לא ידע לאמר אם הוא זקוק לתכונה טכנית מסויימת או לא.
אחרי חודשיים מתחילת הפיתוח (שהתחיל אחרי חודשיים של לימוד הנושא ותיכנון ארכיטקטורה) עשינו דמו ראשון (שכמעט לא עושה כלום חוץ מלהציג דף אחד עם אובייקטים מוכנים מראש) בתוך החברה, שבאופן פלאי הצליח לעבוד (לדמואים כאלו יש חשיבות מאוד גדולה - אי אפשר "לזייף" בהם יותר מדי, והם חושפים כשלים שבתור מפתח כבר "התרגלת אליהם" או לא שמת לב אליהם. בהמשך היה לנו דמו שכשל בצורה כל כך קולוסאלית, שהוא חשף להנהלה בעיה קשה בסביבת הבדיקות האוטומטיות, והוביל למיקוד תשומת לב ניהולית גדולה יותר לפרוייקט, ובהמשך להקצאת משאבים גדולה משמעותית - הן מבחינת כח אדם והן מבחינת משאבי חומרה. את מה שהתקשיתי להבהיר להנהלה במילים במשך חודש - עשה הכישלון הזה בחצי שעה). לאחר עוד חודש הבאנו דמו שני שבו ניתן היה להראות פעולות בסיסיות של יצירת ועריכת אובייקטים, וכעבור כמה חודשים הגענו לשלב האלפא - עם לקוחות ש"התנדבו" להריץ את האלפא, מתוך אינטרס לקבל מוצר שמתאים לדרישותיהם ומתוך אינטרס לראות שאנחנו נוכל לספק את הסחורה המלאה. באלפא הזו גילינו כמה בעיות, כולל אזור שבו פיספסנו בגדול בתיכנון בדיקות האיכות - אזור שקיבל השקעה מאסיבית לקראת הבטא. גם הבטא נבדק אצל אותם לקוחות האלפא (שגם ראו שיפור ניכר באזור הבעייתי, וגם ראו שאנחנו לוקחים ברצינות את הפידבק והבקשות שלהם), ולקוחות אחרים, שחשפו כמה צרכים חדשים.
בשורה התחתונה - הצלחנו להביא לשוק תוך כ-1.5 שנים פיצ'ר שבחברות דומות אחרות לקח 2-3 שנים להביא גרסה ראשונה שלו לשוק - וכבר מתחילים לראות עסקאות חדשות נסגרות בעקבותיו. סביר להניח שאת כלל התכונות של הפיצ'ר לא נפתח משמעותית מהר יותר מחברות אחרות - אבל כשנסיים אותן כבר נהיה עמוק בשוק, עם פיצ'ר הרבה יותר בשל מבחינת יציבות, מבחינת תמיכתיות ומבחינת התמקדות במה שהלקוחות באמת צריכים ומפריע להם במוצרים דומים אחרים.
