2019 היתה שנה סופר משמעותית באוריבי. הגדלנו את ההכנסות ב 800% (כן, כן), יש לנו מעל 400 לקוחות משלמים חדשים והגדלנו את כמות המידע שאנחנו מנתחים פי 10 – לניתוח פעולות של מאות מיליוני משתמשים בחודש. התחלנו את 2019 עם צוות פיתוח של ארבעה מתכנתים מופלאים ולמרות כל הגדילה העצומה הזו, אנחנו עדיין צוות פיתוח קטן יחסית, של שבעה. עם ההקדמה הזו, זה די ברור שמתחנו את כל הגבולות הטכנולוגיים והניהוליים בשנה הזו – מאיך מתמודדים עם scale כזה, איך שומרים על ה DNA המיוחד של הצוות עם הגדילה מסביב ואיך שומרים על איכות תוך כדי ריצה.
הרבה פעמים, שואלים אותי למה בחרתי להקים עוד סטארטאפ, אחרי שכבר הקמתי שניים. המשך השאלה לרוב הוא למה לא בחרתי לעבור לצד השני ולעסוק בהשקעות. התשובה מאד ברורה לי, במהות שלי אני builder-ית, אני אוהבת לדמיין דברים, לתכנן דברים ולהרכיב אותם, עד שהם בנויים ופועלים. עם כל העבודה המדהימה של כל שאר הצוותים בחברה, צוות הפיתוח לדעתי הם הכי builders – ובעבודת אומנות הופכים רעיונות למציאות שימושית. זו גם הסיבה שאני תמיד מאד קרובה לצוות הפיתוח. אני לא נכנסת לפרטים הטכניים העמוקים אבל בהחלט מעורבת בעבודת היצירה הזו.
כאשר עוסקים בתרבות של פיתוח, לרוב השיחה היא סביב המתודולוגיות שבהן עובדים, איך מנהלים משימות, איך בוחרים טכנולוגיות וכו'. אני חושבת שאלה נושאים משמעותיים, אבל, לא הנשמה של היצירה הטכנית. בפוסט הזה אעסוק במה הופך לדעתי מתכנתים למעולים ומה הבסיס לבניית מערכת סופר מורכבת ב scale כ"כ משמעותי.
קוד טוב מתחיל בהבנה אמיתית של המוצר
עבדתי עם עשרות מתכנתים מוכשרים. חכמים, מנוסים, לומדים מהר. לקח לי שנים לזהות מה בדיוק ה X פקטור שמבדיל בין אלה שבסוף מייצרים תוצאות מעולות ואלה שפחות. התשובה נשמעת טריוויאלית אבל היא לא. המתכנתים עם ה X פקטור, מבינים בדיוק על מה הם עובדים. הם לא רואים את המשימות שהם עובדים עליהן כמשימות טכניות נטו אלא רואים את החזון של אותה משימה – איך הולכים להשתמש במה שהם בונים, באיזה scale, באיזה תדירות. אני רוצה לכתוב שהם מבינים טוב את המוצר אבל זה אפילו מעבר לכך – הם מבינים את כל המערכת ומבינים אנשים. ההבנה העמוקה לא רק דוחפת אותם לבנות משהו הרבה יותר נכון, אלא גם עוזרת להם להבין במה לא להתעסק… היו לי הרבה מקרים בעבודה עם מתכנתים בהם המון זמן בוזבז על מקרי קצה שאף משתמש מעולם לא הגיע אליהם או התאמה ל scale שבכלל לא רלוונטי בעתיד הנראה לעין. אני חושבת שההבנה המוצרית העמוקה היא בחלקה תכונת אופי בסיסית של חלק מהמתכנתים אבל ללא ספק ניתנת גם ללימוד. באוריבי, אנחנו שמים הרבה דגש על הבנה של המוצר ו'חופרים' בזה לא מעט – איך ישתמשו בפיצ'ר, מי, כמה פעמים. כל פיצ'ר חדש שאנחנו משחררים עובר סוג של 'תחקור' – בשבועות אחרי היציאה של הפיצ'ר אנחנו אוספים את כל האנליטיקות של השימוש בו, צופים בהקלטות של משתמשים ואוספים פידבק. אנחנו משפרים את הפיצ'רים הטובים ומנסים להבין לעומק למה בכלל יצאו פיצ'רים שהיה להם שימוש נמוך ואיך נמנעים מזה בעתיד. ה state of mind שיש בצוות הפיתוח הוא שלכולם יש מילה לגבי המוצר, וטוב שכך. החל מההגדרות של הפיצ'רים עצמם ועד שינויים ברגע האחרון של ה ux. כמה דוגמאות מהחודשים האחרונים – ביוזמת ובהשתתפות המפתחים הכנסו design system מאד מפורט לכל ה UI, פיצ'ר תשתיתי לגמרי של כתיבה מחדש של אזור שלא עמד ב scale התרחב לפונקציות נוספות עם הרבה ערך למשתמשים ובהרבה פיצ'רים קטנים המתכנתים עשו את ה'פיניש' העיצובי. זה לא אומר שהם אחראים על המוצר כמובן, אבל כמו שמנהל מוצר שמבין לעומק את כל הניואנסים הטכניים עושה עבודה הרבה יותר טובה, כך גם להיפך.
כל הצוותים באותו מיקום פיסי, כל המספרים והתוכניות חשופים, כל הנקודות מתחברות
ההתייחסות להבנה של המוצר משקפת למעשה ראיה מערכתית. אם נדמיין רגע את כל הקווים שנמתחים בין כל הנקודות בחברה, עבור הפיתוח, רוב החוטים המשמעותיים הם בין המוצר לטכנולוגיה, אבל, לא רק. אחד הדברים שעובדים מאד לטובתינו באוריבי, הוא, שבניגוד להרבה סטארטאפים אחרים, כל החברה נמצאת בישראל וכולם ממוקמים באותו משרד. יש אינטרקציה יום-יומית בין הפיתוח, המכירות, השיווק, העיצוב והתמיכה. כולם יודעים איך כל דבר משפיע על האחר. הפיתוח מבינים למשל איך עיכוב של שחרור של פיצ'ר השפיע על המכירות וחברי צוות המכירות יכולים להבין איך בקשה של משהו שנראה להם טריוואלי השפיעה על הפיתוח. בבניית התכנון השנתי ל 2020, ביקשתי מכל העובדים בחברה לכתוב, בין השאר, מה לדעתם עובד הכי טוב היום בחברה. אחת התשובות שחזרו לא מעט היתה עבודת הצוות המעולה בין הצוותים השונים. זה גרם לי להתנפח מגאווה 🙂. אני מכירה לא מעט חברות שבהן יש קשר אפסי בין הצוותים ולעיתים אפילו נהיית סוג של יריבות. בתפיסה שלי, כל צוות מוצא את העבודה של הצוותים האחרים מרתקת – איך מה שהמתכנתים פיתחו משפיע על המכירות, איזה בעיות חוזרות על עצמן בתמיכה, מה מוביל עכשיו את השיווק. החיבור הזה מאד מפרה ומוביל לתוצאות טובות יותר.
החלק המשלים של עבודה צמודה בין הצוותים היא שקיפות, וכמה שיותר. אני מקפידה מאד על שקיפות מלאה – כל המספרים, התוכניות והתוצאות פתוחים לכולם. כולם יודעים בכל רגע נתון מה התוצאות העיסקיות, מה העלויות ומה האתגרים הכי משמעותיים שאנחנו מתמודדים עימם. הסיבה העיקרית שבגללה אני מקפידה על שקיפות היא כי זו הדרך היחידה לדעתי שהעובדים יוכלו לראות את התמונה המלאה – מה עובד ומה לא, איפה יש לנו בעיות, באיזה קצב אנחנו עתידים לצמוח. הנתונים האלה, מעבר להבנת המוצר, מאפשרים תכנון טוב יותר והבנה עוד יותר עמוקה של איפה להתמקד, ולא פחות חשוב, איפה לא.
ניהול משימות ופיצ'רים מא' ועד ת' ולקיחת ownership
כפי שכתבתי בתחילת הפוסט, אני עוסקת פה בנשמה ובפילוסופיה של צוות פיתוח בחברה ופחות בנושאים כמו agile, scrum וכו'. למרות שיש לי הרבה מה להגיד גם בנושאים האלה :). אני עוסקת כאן בקונספט של ספרינטים בשל ההשלכות שראיתי שיש להם על הפיתוח. כמו הרוב המוחלט של החברות, גם אנחנו עובדים בספרינטים. אחד מתוצרי הלוואי הפחות מוצלחים של ספרינטים הוא הפירוק של קונספטים מוצריים ליחידות טכניות קטנות. כמובן שכאשר בונים פיצ'ר גדול (או קטן), או כותבים חלק מהתשתית, חייבים לפרק את הפרוייקט להמון משימות קטנות. אחד הדברים שראיתי קורה לאורך השנים הוא שכאשר עושים את זה לא מספיק נכון, הספרינטים והמשימות הקטנות שמרכיבות אותם דווקא מאיטים את הפיתוח ו'מקטינים' את המפתחים. כאשר ההסתכלות היא שהשבוע אני צריכ/ה לעמוד במספר משימות קטנות, עם הקשר רופף לפרוייקט הגדול, הרבה מתכנתים ומתכנתות נשאבים לרוח קרב של לנקות את הרשימה ולתקתק את המשימות במקום להבין למה הם עושים כל משימה ואיך הכל מתחבר ביחד. באוריבי, אנחנו מקפידים שאותו מתכנת/ת יובילו פרוייקט מההתחלה עד הסוף. ה'שבירה' למשימות קטנות היא אמצעי להתקדמות ולא באה על חשבון ההבנה העמוקה של למה ולמי כותבים את זה. כמובן שיש פרוייקטים שכוללים מעורבות של כמה חברי צוות אבל לכל פרוייקט יש את ה owner שלו. התפיסה של ה ownership היא משהו שאנחנו מנסים להנחיל גם לחברי הצוות החדשים וכמה שבועות אחרי שמתכנת/ת חדשים מצטרפים לצוות הם כבר מקבלים פרוייקט להוביל.
לא להקשר לכלום ולהיות כל הזמן במצב של למידה
אחת הסיבות שאני מאד אוהבת עבודה ב scale גבוה ועבודה עם אלפי משתמשים על בסיס יומיומי היא שיש דרך אמיתית ללמוד מה אנשים באמת רוצים. אם לפני כמה שנים, בחברות הקודמות שלי, החלטות מכל הסוגים היו נסגרות בדיונים סוערים בתוך החברה, הרי שהיום אנחנו מוציאים דברים החוצה ופשוט רואים מה עובד ומה לא. היופי הגדול ב scale כ"כ אינטנסיבי הוא גם ה crowd sourcing של חלק מההחלטות וגם המהירות הגדולה שבה סדקים מתגלים – ברמה הטכנית וברמת המוצר. אני מאמינה שאחד המאפיינים הברורים של יזמים מצליחים היא היכולת לזוז מהר, וכשמשהו לא עובד – לשנות. זה נכון גם לכל החלקים בחברה – זה אומר שאם יצא פיצ'ר שאף אחד לא משתמש בו – נשכתב או פשוט נמחוק (במקום להוסיף עוד גיבנת שנצטרך לסחוב שנים), שאם משהו בתשתיות לא עובד מספיק טוב ,אפשר בהרבה מקרים לחזור לנקודת ההתחלה. זה אולי יכול להשמע כמו זלזול בעבודה לפעמים, אבל, מבחינתי זה בדיוק להיפך, אני לא רוצה שהצוות ימצא את עצמו בעתיד חופר באיזה קוד legacy של פיצ'ר שאף אחד לא משתמש בו אלא רוצה שיעבדו רק על הדברים המהותיים.
לסיכום,
אני מכירה הרבה סוגי מתכנתים, כל אחד מתרגש מדברים שונים לחלוטין – מאלגוריתמים מורכבים, טכנולוגיות חדשות, באגים קשים – כל אחד ואחת וההעדפות שלהם. מה שמשותף לכולם זה שאף אחד לא אוהב לכתוב למגירה. ההתרגשות האמיתית היא לבנות משהו שמשתמשים בו, שאנשים רואים ממנו ערך ואפילו רוצים לשלם עבורו. מבחינתי זו סגירת המעגל האולטימטיבית והיא גם מנחה את הפילוסופיה של הפיתוח – הרצון לבנות משהו בעל ערך ושיהיה בשימוש, ההבנה של הערך וההצלחה של המוצר בזכות זה.
וכמובן – מוזמנים להסתכל על התפקידים שאנחנו מגייסים אליהם, בפיתוח ובכלל –oribi.io/careers
