פודקאסט מספר 374 של רברס עם פלטפורמה - אורי ורן מארחים בכרכור (שוב חם) את בועז כץ - CTO ומייסד-משותף (Co-founder) בחברת Bizzabo (ומיישן/ משמר נקניקים מקצועי)לשיחה על מדידת מפתחים (אולי באמת צריך ליישן אותם לפני המדידה . . .).
אז בועז -
- בן 38, גר 11 דקות (אם כבר מודדים) מאורי בחדרה, נשוי + 3 ( + 2 כלבים + 2 חתולים), ה - founder on the” ground” במשרד בישראל (ערן בן-שושן ואלון אלרואי יושבים בניו-יורק)
- בוגר מדעי המחשב במרכז הבינתחומי, עבר באלביט (באלגוריתמיקה מתקדמת של טרום ימי ה - Machine Learning).
- כבר שבע שנים ב - Bizzabo עם מגוון תפקידים לאורך תהליך הגדילה של החברה - “איש מוצר במהותי יותר מאשר איש טכנולוגיה”
- בשנתיים האחרונות הוביל את הפיתוח בחברה (עד שנמצא VP R&D מעולה), הגיע Fresh מתוך עולם ה - Product אל ניהול פיתוח, מה שאולי קצת “הפריע” לשגרה היומיומית - ותמיד אמרנו ש - Disruption זה דבר טוב.
ו - Bizzabo ?
- החברה נותנת שירות בתחום הכנסים העסקיים - מוכרים לחברות (בעיקר חברות Mid-Market ו - Enterprise) פתרון שעוזר למקסם את כל הכנסים שהן עורכות.
- לקוחות כמו Microsoft, Elastic, Docker, dji וכו’
- 100 עובדים בשני המשרדים (ישראל, ארה”ב), מתוכם כ-30 אנשי פיתוח (8 מהם באוקראינה - חלק מהצוותים ולא כצוות עצמאי)
- עובדים במודל ה- Squads של Spotify (ככה כבר 4 שנים).
- בועז חווה את הגדילה בעיקר בשלב המעבר, מבערך 10 עובדים לכיוון ה - 25-27, שם הופיעו האתגרים סביב מדידה (והחברה גדלה מאוד בשנתיים האחרונות).
- בגדול אנחנו מדברים בעיקר על B2B?
- כן, אולי יותר B2B2C - יש המון C (לקוחות קצה, End-Consumers) בתוך הדבר הזה, אבל מבחינת המכירה והלקוחות זה B2B לגמרי.
- והמוצר עצמו - נמצא על טלפונים? Web? איך רואים אותו?
- המוצר הוא בעיקרו פלטרפורמה וובית (Web-platform), שרובה רץ על הענן של AWS
- אנחנו מאוד רגישים ל - Up-time - זו פלטרפורמה שהיא Mission Critical עבור הלקוחות שלנו - הם שמים את עצמם אל מול הלקוחות שלהם
- היינו נוהגים להגיד שלפני שיש איזשהו down-time - חמישה לקוחות מתקשרים לפני שהמוניטור קופץ (אז לא רק ישראלים מצפצפים בכתום?)
- היום לשמחתנו המוניטור קופץ לפני הלקוחות, שזה יותר טוב.
- יש לנו שני Mobile Clients - שניהם ב React Native - אנדרואיד ואייפון
- אז אם אתם למטה באמצע כנס (עם כמות הלקוחות בטח יש בממוצע כל הזמן כנס של לקוח) . . .
- ל - Bizzabo יש כיום בממוצע כ-15 כנסים ביום - וזה נוגע בהכל
- זה לא רק כשהכנסים רצים ומישהו עומד על הבמה או בצ’ק אין אלא גם בשלב ההרשמות - כל אתרי הכנסים הם על הפלטרפורמה שלנו.
- סולקים סדר גודל של $20M בחודש (שווי כרטיסים).
- אז נפל Bizzabo (מתישהו, איכשהו - נפל) - הלך כנס של לקוח?
- נגיד את זה בצורה יותר אגרסיבית - הלך לקוח.
- אם פישלת, הדרך לבנות את עצמך חזרה כמעט לא קיימת בעולם הזה, וזה אחד האתגרים הגדולים שלנו.
- במקרה כזה - ביישת את הלקוח אל מול הלקוחות שלו, ואין כנראה גרוע מזה.
אז כשהגעת לנהל את הצוות הטכנולוגי הייתם משהו כמו עשרה עובדים, ועכשיו באיזור השלושים.
אחד האתגרים שבטח ניצבת בפניהם הוא “איך אני הופך את המפתחים שלי לאפקטיביים? איך אני מתמרץ אותם? איך אני הופך את המוצר ליותר טוב ויותר אמין?” (דיברנו בדיוק עכשיו על אמינות) -
איך ניגשים לדבר הזה? מה עשית בימים הראשונים?
- שאלת ה - 100% up-time . .
- הדבר הראשון בתור מישהו שנכנס למקום חדש זה קודם כל לשמור על הסטטוס-קוו
- לא לעשות נזקים ולהבין שמי שהיה לפניך מעולה (ועדיין מעולה - טל, שעבר ל - Torii)
- אז המשכנו את מה שהוא עשה - תכנון מול ביצוע כמיטב המסורת הידועה
- במשך כמעט חצי שנה ניסיתי להחזיק את זה לפי האמונה שלי - ומכיסא ה - VP R&D זה נראה לי כפחות ופחות רלוונטי לאורך התקופה הזו
- אז הגיע תקופת החקירה - לפתוח את הראש, להיפגש עם המון אנשים
- ראיינו המון VP R&D - בממוצע פעמיים בשבוע, פנים אל פנים - במשך כמעט שנתיים
- ככה יצא לי לשבת עם מיטב המוחות בתעשיה, מכסא של מראיין, ולתחקר אותם - “איך אתם מודדים?”
- רוב התשובות שקיבלנו היו בסגנון “אה, זה ככה וככה, ו”כן באמת עובד” ו”לא באמת עובד” וכו’
- לקח המון זמן להבין כיוון שהאמנתי בעצמי שיביא לאיזושהי תוצאה, משהו שהוא לא רק לשם התכנון מול ביצוע בפני עצמו, אלא משהו שישפיע על הדברים החשובים.
תכנון מול ביצוע, במיוחד כשהחברה גדלה ומתחילות תלויות בין מערכות ותלויות בין צוותים - זו כבר לא מדידה של המפתח היחיד אלא מדידה של הארגון - של יכולת ה - Execution שלו, של יכולת קבלת ההחלטות שלו . . .
- זה מאוד נכון שתכנון מול ביצוע הוא חשוב - וגם היום אנחנו מודדים אותו - אבל הוא לא היה המדד העיקרי לדעתי באותה תקופה, ועבודת ה - squads אצלנו היא מאוד לא תלויה
- אם אנחנו עוצרים לרגע על התלות בין צוותים - היא לא קיימת אצלנו
- גם היום - יש לנו חמישה Squads (מה שנקרא אצלנו חמישה “בתים”) - והם לא תלויים, ברמה הטוטאלית לחלוטין: אפס תלות בין הבתים - ותלות בתכנון מול ביצועים בשחרורים (Releases), לדוגמא, לא קיימת.
- כן היינו צריכים להתמודד עם אתגרים של סנכרון ו - Code Base וכו’, אבל זה אולי כן הקל, ואני מבין שזה חשוב וחלילה מלזלזל - יש המון משמעות לתכנון מול ביצוע לתוכניות עבודה, והתחייבויות ללקוחות וכו’
- ועדיין - זה לא הספיק בשביל להפוך את הארגון ליותר טוב וזה מה שהפריע לי, אם נלך לרגע למקום הזה
- נכון - עמדנו בזמנים שתכננו, אבל זה הביא אנשים לקחת אולי יותר Buffers, ולא בהכרח לדחוף, ועד כמה חשיבות יש לזה שלא עמדת בזמנים? האם אתה מקצץ תכולה או לא? האם אנחנו “מקדשים את הזמן”? וכו’ . . .
- חיפשתי דברים שיעזרו לנו לעשות Impact יותר גדול על הארגון ולהשתפר - זה היה המדד
- התחלתי לחפש את המדדים האחרים האלה
- אף פעם, אגב, לא מדדתי את המפתח הבודד, וגם היום רוב המדידה היא של הצוות - מעניין אותי יותר איך ה”בית” מתפקד מאשר המפתח הבודד
הסאבטקסט שאתה מעלה הוא “אני מודד תכנון מול ביצוע - אבל בסופו של דבר המפתחים / החברה / העובדים ימצאו דרך לשחק עם המדד הזה” - בין אם זה לקחת Buffer יותר גדול, להגדיר בצורה אחרת וכו’ - וזה קצת (מניסיון) כנראה הטבע האנושי: כל סוג של מדד שתשים מול בנאדם - הוא ימצא איכשהו דרך למדוד את זה אחרת או לעקם או לעשות את העבודה שלו כך שהמדד ישתפר אבל לא בהכרח הביצועים של החברה ישתפרו או שהלקוחות יהיו יותר מרוצים, וזו אחת הבעיות היותר משמעותיות בהצבת מדדים כאלה, וזה גם בטוח משהו שאתה מכיר והבנת.
כתגובה לכל זה - אחת הטענות שעולות לפעמים היא - “טוב, אז בואו לא נמדוד בכלל” (ובגרסת ה - Agile - בואו לא נתכנן…). ניתן לאנשים את “המוטיבציה” בלי למדוד אותם (ואז הם לא יחפשו דרכים לשחק עם המדדים), ואני מניח שזה גם אחד הדברים שהיו על הכוונת.
בסופו של דבר החלטת כן למדוד - אולי לא כל אדם באופן אישי, אבל כן למצוא את המדדים שגורמים לעובדים להתנהג בצורה יותר טובה ולחברה להצליח יותר. האם הייתה איזושהי נקודת התלבטות כזו (“האם בכלל נכון למדוד?”), ואם כן - איך זה נראה בעיניך?
- זוכה פרס השאלה הארוכה, בטח לשנה זו . . .
- נגיב רגע על ה - Gaming . . . לא באנו משם כי עם 10-12 אנשים שהם Committed, אתה לא חושב שהם משחקים עם המערכת, אבל גם לא חשבתי שזה היה השיקוף הנכון למדד הביצוע של הצוות
- הצוות עושה את כל מה שהוא יכול ואנחנו עדיין מאחרים בזמנים, לצורך העניין
- זה לא משקף כראוי את המאמצים או את ההצלחה / אי הצלחה של הצוות, ושם היה קונפליקט
- אי-מדידה לא היה על הפרק, כיוון שאנחנו מכירים בחשיבות המדידה, ושאם דברים עובדים ונכונים, גם אם לפעמים זה לוקח קצת זמן - בסוף זה הופך אותך ליותר טוב, כך שאי מדידה לא הייתה על הפרק, וחיפשנו דברים שכן "יזיזו”.
- אם דיברנו קודם על האתגר של ה - Up-time שהיה מאוד אקוטי, כמו גם “טיב הפלטפורמה” שגם כן היה מדד אקוטי (“איכות” - כמות באגים, חוויית הלקוח מבחינת כמה מהם הוא רואה וכמה לא רואה וכו’) - אלו שני מדדים יותר “טריויאלים”.
- את ה - Up-Time, למשל, קל למדוד ואפשר להציב יעד ולהתחיל לשאוף אליו - אפשר להתחיל מיעד של 99.95% (כי זה מה שמעניין בסדר גודל שהזכרנו) והיום אנחנו כבר על יעד של 99.98%, כשהפלטפורמה משיקה ל-100% כל הזמן.
נגעת בשני מדדים מאוד מעניינים - כעקרון, אם לא תעשה כלום, יהיה אחלה Up-Time ולא יהיו באגים . . .
- נכון, עד כדי מצב שבו פתאום יש Usage משוגע (שלא צפית) . . . - הקונפליקט הקלאסי בין Dev לבין Ops: “אל תעשה כלום והמערכת תישאר יציבה” אל מול “תעשה הרבה והמוצר ישתפר”
- זה גם עניין של Opportunity vs. Risk או דברים כאלה
- השאלה היא איך אתה מאזן את זה? המדד של Up-time היה מאוד קל ושמנו אותו יחסית בהתחלה - מעיין “כוכב צפון” שגרם לדברים מאוד טובים כמו מעבר מלא ל Kubernetes ול-Docker ו - Auto-Scaling שלא היה לנו ,ושכפרויקט זה היה עבורינו דבר מאוד משמעותי שדחף אותנו קדימה.
- זה היה “קל”
- באגים - לקח לנו זמן להגדיר איך קובעים מדד לבאגים שהוא טוב וחזק ומחזיק גם כשהצוות גדל וזה היה מאוד קשה
- חיפשתי קורלציה בין הבאגים שמדווחים לבין מה שמשפיע עליהם - איך מורידים את כמות הבאגים?
- “ישבתי עם אקסלים” (Any project manager, ever), עם כל קורלציה אפשרית - Delay של שבוע, של שבועיים, מ- Release מסויים, מנקודות מסויימות וכו’ - לא מצאנו שום דבר בהיבט הזה.
- הגענו למדד שדיבר על יחס שבין כמות Pull-requests merged (“כמה שינויים הכנסתי לפלטפורמה”) לבין כמות הבאגים שמדווחים
- לצורך העניין - לכמה באגים אתה “מרשה להיכנס” אל מול כמות השינויים שאתה מכניס למערכת
- היעד שלנו כרגע הוא של 0.2 - משמע: על כל חמישה שינויים שנכנסים למערכת אנחנו “מרשים” באג אחד מדווח (ב - Production), ויש לנו מדד נוסף שמדבר על “Zero Urgent” . . .
- “מדווח” - הכוונה על ידי לקוח
- (רן) קצת מזכיר את המדד של Google ל - Error Budgets - ובגדול קצת מזכיר את עניין ה - Up-time:
- יש SLA מול הלקוחות (נגיד 99.95% Up-Time), ונגיד שיש גם SLO פנימי (שהוא בעצם המטרה - בדרך כלל קצת מעל, נגיד 99.96%).
- אם יש חריגה מה - SLO - היא “יורדת מתקציב השגיאות שלך” - אפילו אם ה-SLO הרבה יותר מחמיר מה-SLA עצמו - אם ירדת מה - SLO שלך, אתה עכשיו“בחוב שגיאות” ואתה“צריך לשלם אותו” - לעבוד על יציבות ולא על פיצ’רים חדשים.
- במובן הזה זה מזכיר את מה שאמרת - “יש לי חוב של באגים” (נראה ששחררתי יותר מדי את הרסן ויש לי יותר מדי באגים), עכשיו “נעצור את הסוסים” ונעבוד על יציבות ועל תיקוני באגים?
- לא בהכרח - זה יותר לכיוון עבודה על שחרורים יותר “בטוחים” - Quality over Delivery.
- בשלב הזה זו הייתה אמירה מאוד חזקה בחברה: מעדיפים לשחרר ב - Quality יותר גבוה על פני שחרור יותר מהיר בשלב הזה.
אחד הדברים אצלנו (אורי ב - Outbrain), עכשיו עם צוות מאוד גדול וכו’ - ויוצאים באגים, כשלכל באג יש Impact כספי לא קטן - ב - Scale של Outbrain המינימום הוא באיזור המאות אלפי דולרים.
אחת הבעיות היא שאנחנו יודעים למדוד מה היה ה - Impact על ה - Business (בכסף, זו לא הבעיה) - אבל אנחנו לא יודעים את “המכנה”: כמה “Value” הכנסנו למערכת ע”י הפיתוח שעשינו (עבור המחיר ששילמנו)
- הכוונה ב”מכנה” היא לא לכמה צריך עכשיו להוריד לאנשים במשכורת :-)
אוקיי - אז הייתה לא X פגיעה ב - Business - כמה impact אני מייצר תמורת זה? זה משהו שהרבה יותר קשה למדוד, בטח במקום שהוא B2B . . .
- זה באמת מאוד קשה למדוד, ואנחנו (Bizzabo) חיפשנו את ה - Balance שבין ה - Delivery שכל הזמן גדל וגדל וכל הזמן עושים יותר דברים יותר מהר - אל מול כמות באגים שתמיד תגדל אם מכניסים יותר קוד (ובכן…) - ועדיין היחס צריך להישמר
- ההבדל המשמעותי שקרה הוא שרואים את הגרף מול העיניים - והמפתחים והצוותים רואים אותו בכל חודש - ורואים אותו יורד, רק מעצם זה ששמנו אותו ככה בולט.
- “אתה לא יכול לשפר את מה שלא מדדת”
- אנחנו רואים את המדד יורד תוך חמישה חודשים מרמה של כמעט 0.8 עד כדי הגעה ל-KPI (אותו 0.2).
עכשיו נשחק לרגע את פרקליט השטן - זה גורם להם פשוט ליצור Pull-Requests או Merge Requests יותר קטנים (להגדיל את המכנה)? או לדווח על פחות באגים? או על שני באגים כאחד כו’ . . .
- בוא נוסיף לזה - אחד המדדים שהוספנו בשביל למדוד יעילות ו - efficiency היה Average Pull-request למפתח - עוד יותר גרוע ועוד “סיבה טובה” לשחק עם מערכת.
- מה שעשינו בתהליך הזה היה לנסות ולהבין מהו ה - Average Pull Request האידיאלי עבורנו, לפחות בסדר גודל
- איך עושים כזה דבר? קראנו והתייעצנו הרבה, והרעיון היה לגשת לזה מכיוון של “כמה זמן לוקח לעשות Code Review?” (לא המצאנו שום דבר), ו -
- גילינו ששעה של Code Review זה משהו סביר, שאפשר לעשות בלי הפסקות ובתוך context switch אחד, וזה טוב
- אז בדקנו לאילו Pull Requests לוקח שעה של Code Review וראינו שמדובר בסדר גודל של סביב ה -300 שורות קוד במקרה שלנו.
- הגדרנו את כמות ה - Pull Requests הממוצעת שאנחנו רוצים, ובדקנו בכל פעם שהממוצע לא משתנה, כלומר - שאף אחד לא משחק עם המערכת ע”י שחרור Pull Requests קטנים.
- ועדיין - עודדנו Pull Requests קטנים בהגדרה - 50 או 100 שורות קוד זה מעולה, מוכן לחתום על זה כל יום. מעט קוד - מעט באגים. מתימטיקה פשוטה.
- אז אנשים לא סתם שמו שורות עם הערות, כדי להגדיל את מספר השורות? . . . אין סוף ליצירתיות כנראה, וממוצע זה כר פורה.
אז לסיכום ביניים -
- מדד ראשון - Up-time: השפעה ברורה ומשמעותית על הלקוחות ועל ה - Business
- מדד שני (לאחר בחינה של שלל קורלציות) - היחס בין מספר ה - Pull Requests למספר הבאגים: רוצים בערך יחס של 1:5 (באג אחד על כל חמישה Merges).
היו עוד כאלה?
- כמות Pull requests ממוצעת למפתח (על מנת להבין מדד ליעילות)
- חיפשנו עוד מדדים של תכנון מול ביצוע לדבר הזה - אצלי במשמרת לא הצלחנו למצוא משהו שהוא חכם מדי והמשכנו לעשות את הדברים הרגילים.
- היום הכנסנו לחברה מדד של “כמה זמן לוקח עד ששורת הקוד הראשונה נכתבת”, מרגע ה - Handover בין ה - Product ל - R&D
(אורי) כל השלב הזה - מרגע שמגיע הצורך ועד שמתחילים לכתוב - אם מסתכלים על זמן פיתוח, אני משער שזה תופס את רוב הזמן . . . רוב הזמן הולך על קבלת החלטות
- הכל שאלה של “מה אתה רוצה לשפר?”
- איפה החברה מרגישה שהיא טובה ואיפה היא צריכה להשתפר, והמדדים משתנים גם אצלנו מרבעון לרבעון או אחרי חצי שנה - אנחנו אוהבים לשנות KPI כשמרגישים שהם מספיק טובים, ובוחרים את “הגדולים” לפי המקומות שאנחנו חושבים שה - ROI יהיה הכי מהיר, איפה שאנחנו חושבים שיש את הפער הכי גדול.
- במקרה הזה - הרגשנו שיש פער גדול ב - Process של התכנון של ה - R&D, ומשם בא המדד של “אוקיי - בתכנון נכון או תהליך נכון נוכל לייעל את הזמן הזה”.
תחשוב שאתה עובד בבתים שהם מאוד לא תלויים (עדיין) - ברגע שמתחילות תלויות, המערכת הופכת הרבה יותר גדולה ומורכבת, ומתחילות להיות עוד יותר תלויות - וקבלת ההחלטות הופכת להרבה יותר מורכבת, ואתה מוצא את עצמך, ברוב הזמן, מתעסק בקבלת החלטות ולא בפיתוח עצמו.
- נכון, אבל אתה יכול לטעון שככל שאתה משקיע יותר זמן בקבלת ההחלטות הזו, זמן הפיתוח הנדרש קטן כי אתה מתכנן טוב יותר, כמובן (?)
- אהה . . . בוא נגיד ככה: לפעמים כשזה קורה, אתה לא בטוח שבאמת התקבלה ההחלטה הנכונה, כי לפעמים לא נלקחים “ביסים” גדולים מידי, או שכשאתה מגיע לשלב שבו כן צריך לעשות Refactoring, ואתה מחליט שלא על מנת לקצר את זמן הפיתוח - אתה אוכל את זה אחר כך, ובגדול.
- זה מה שנפלא בעולם המדידות - שום דבר הוא לא שחור או לבן, וכשמבינים ומשלימים עם זה, יכול להיות שהפחד ממדידה יורד
- זה לפחות מה שקרה לי (בועז) ברמה האישית - בהתחלה אתה נרתע מזה כי אתה אומר “אני לוקח מדד ואני נצמד אליו ונראה מה יקרה . . .”, ואז אתה לומד שלא נורא, ומקסימום נשנה, ותמיד יש יוצאי דופן.
- בסוף אם זה הביא (ואני בטוח שיביא) לתהליכי תכנון מסודרים יותר וטובים יותר ומובנים יותר - גם אם בסופו של דבר המדד יעלה, אני חי עם זה בשלום, וזו המהות, ה - Drive, של המדידות מבחינתינו.
- (אורי) - ואשריך שאתה מתעסק בזה כשהחברה היא רק עם 30 מפתחים . . . (קרא את הפרק הראשון של Parkinson’s law)
- (בועז) - מסכים, ונותן קרדיט לערן, המנכ”ל והשותף שלי - בלעדיו, אני אישית לא הייתי שם.
עוד מעט כמה שאלות שהן יותר Meta - אבל לפני כן קצת Micro:
יש מדדים שהם ידועים בתעשייה - Code Coverage למשל, או Complexity . . . אילו גם דברים שעלו אצלכם לדיון?
- אז Complexity זה משהו שתקפנו קצת לפני כן, והורדנו לרמת No Complexity בקוד - אנחנו מאמינים ב”אפס דוקומנטציה”, אז הקוד פשוט ואין לולאות ואתה רק צריך להיכנס ולקרוא אותו, וזה משהו שתקפנו קודם לכן, בלי למדוד.
- לגבי Code Coverage - אנחנו עובדים בלי QA לחלוטין כבר המון שנים, כך שזה “בדמינו” (אוטומציה וכו’) - אז גם שם אנחנו אמנם לא ב - Code Coverage מושלם אבל במקום מאוד טוב ועם משהו לא עובד אז החברה עוצרת, אתה לא מסוגל -
- אנחנו ב - Continuous Integration ו - Continuous Deployment החל משלב מאוד צעיר בחברה, כך שזה מאוד מוטמע (המון קרדיט לאנשים אחרים שהכריחו אותנו להגיע לשם ולעשות את זה).
- אלו מקומות שהם טובים אצלנו, ואנחנו לא “תוקפים” אותם כ - KPI כיוון שה - ROI של למדוד ולפעול שם הוא לא גדול - לא שם החורים שלנו כרגע.
אז שאלות Meta . . .
איך מפתחים מקבלים את כל זה? מתעוררים בוקר (ציורי) אחד ומגלים שמודדים אותם. Brave New world.
איך הם מקבלים את זה?
- קודם כל - דוחפים ועושים Push-back כמו כולנו . . . זה טבעי, ו Challenge מתקבל בברכה
- המשפט שאני תמיד אומר הוא “בואו ננסה” - מה אפשר להפסיד? (Add your favorite“what can wrong” Meme here). מקסימום נשנה - זו מהות העניין.
- היום זה נמצא רק ברמת ראשי הצוותים - המפתח הבודד ביום-יום לא מתעסק בזה, ואני (בועז) אישית בסדר עם זה.
- אני חושב שהם מפסידים, ושזה יהיה להם מאוד מעניין ויכול להפוך אותם ליותר טובים אם וכאשר הם כן יתעסקו עם זה ביום-יום, אבל אני נותן להם להנות מספק - הם מכירים את זה ומסתכלים על זה, אבל לא מטייבים את ה - Pull requests שלהם לפי המדד הזה
- … (אורי) שזה מצד אחד מונע את ה - Gaming, ומצד שני - “אתה לא יכול להשתפר במשהו שאתה לא מודד”.
- . . .אני כן מודד, וראש הצוות שלהם כן רואה את זה . . . אף אחד לא יכול להשתפר אם הוא לא מודד.
- יש היום טרנד של חברות בתחום כמו Velocity(של Code Climate) ו - LinearB(ויש עוד מתחת לראדר) - חברות שתוקפות את עולם המדידה של הפיתוח
- אנחנו לקוחות של Velocity משלב הבטא שלהם, והכלי מדהים - אתה מקבל Visuals ו - data שהיה אולי בלתי אפשרי לקבל עבור חברה עם המשאבים כמו שלנו.
- מה זה עושה? בגדול - מתחבר ל - Git שלך, שואב את כל המידע (כל המדדים שדיברנו עליהם עכשיו), וכל המדדים שהזכרנו הופכים להיות גלויים, באפס מאמץ - גודל Pull-requests, זמן שחלף מ - Merge עד Code Review, משך ה - Code Review, כמה לוקח כל ה - cycle של הפיתוח.
- לא מודדים באגים, אבל את כל מה שהזכרנו אתה יכול לראות
- היתרון הגדול - יש לך את כל המידע הזה החל מה - Repo הראשון, אי שם ב-2014 כשהתחלנו עם GitHub, ועד היום - ואתה יכול לראות איך זה משתנה לאורך הזמן. מאוד מעניין, וטרנד שאני חושב שמאוד יתחזק בתעשייה - לא רואה איך התעשייה תעבוד בלי זה בשלב כזה או אחר בשנים הקרובות.
שאלת Meta נוספת - איך זה משפיע על שאר הארגון? בסך הכל אתם לא חיים בואקום, והזכרנו שאחד המדדים הוא זמן שחלף מצורך שעלה אצל לקוח ועד שנכתבת שורת הקוד הראשונה, אז אני מניח שזה עובד דרך צוות המוצר ואולי עוד כמה גורמים בחברה, שאם הם לא ימדדו (באותו אופן) אז גם אתם נפגעים.
מעבר לזה - האם זה בכלל משפיע תרבותית על שאר הארגון? לדוגמא - כמה פגישות יש? מה היעילות של הפגישות? מדדים אחרים אולי?
- הארגון הוא “מדיד מאוד”, בכל המקומות
- ה -R&D, יחד עם ה - Product, הוא כראה המקום הכי קשה למדידה, בעולמות שלנו היום - הכי “רך”.
- “קוד זה אמנות, מוצר זה אמנות” - יש הרבה אלמנטים “רכים”
- ה - Challenge שתמיד הייתי מקבל היה מכיוון עולם ה - Sales - אם אפשר למדוד את עולם ה - Sales - והרי גם למכור זה אמנות בסופו של דבר - אין שום סיבה שלא נוכל למדוד גם את עולם ה - R&D, ולהפוך אותו לבר חיזוי (Predictable) באופן זה או אחר
- תכל’ס - הצוותים שלי היו “מאחורה” מבחינת הארגון - הארגון מודד, ואנחנו “הכבשה השחורה, שלא מצליחה להוכיח שהיא טובה ועובדת יעיל ומעולה, כי היא לא מודדת את עצמה”.
- לבוא מאחורה למצב ש”הצוות הזה טוב ומעולה - ומדיד”.
- מאוד חשוב (לא ציני!).
(אורי) ארגון ה - Sales מאוד מודד את עצמו כיוון שגם מודל ה - Compensations ב - Sales עובד ככה, בשיטת “מקל וגזר” - מאוד קל ומאוד פשוט לנהל בצורה הזו (או שלא . . .) ו . . .
- (בועז) יכול להיות שזה נובע מכך שעולם ה - Sales מאוד דומה בין חברות (לפחות בהשוואה ל - R&D), ולתעשייה מאוד טוב (ונוח) לייצר את ה - Benchmarks האלה, של “כמה Quota לכל אחד” וכו’ - בעוד שהצד הטכנולוגי מאוד שונה בין חברה לחברה.
- (אורי) נכון - וכיוון שכך עובדת התעשייה, היא גם חייבת למדוד את עצמה (ככה). בעולם הפיתוח (“שלנו”), זה לא ככה - וזה קודם כל יוצר מתחים בין Sales ל - R&D בהרבה מאוד מקומות (אנשי ה - Sales מצפים מאנשי הפיתוח שימדדוד את עצמם באותו אופן, או שיהיה להם את אותו Level of Commitment כמו שלהם (ב - Sales) יש, כיוון שזה מובנה בחוזה העבודה שלהם (אגב - רואים את זה יפה גם אצל אנשים טכניים שעוברים לצד הניהולי יותר של הפרויקט, ופתאום עובדים מול אנשי Finance וכו’ . . .)
- איש מכירות מחוייב ל - Quota של X בתקופה - ואם לא, הוא “נענש”, בעוד לאיש פיתוח אין Quota, הוא “לא נמדד ולא נענש”
- אחד הדברים ששמעתי (אורי) לאחרונה הוא על חברה . . . הרי מה מפתח הכי רוצה? שהקוד שלו יגיע ל - Production והוא יוכל לקבל Feedback - אז יש Train של Releases ל - Production, וה - Baseline הוא “לשחרר על ה - Train”.
- מזכיר את ג’ואי שמחון מפייסבוק, שהתחיל ב - Everything.me(ז”ל) עם קונספט הרכבת.
- ל”רכבת” יש את הזמן שהיא נכנסת לתחנה ויוצאת מהתחנה, וכו’.
- אבל - אם אתה טוב ומוכיח שאתה סבבה, אתה יכול גם “לשחרר מחוץ לרכבת”.
- אין בעיה - עברת לרכב! אתה לא חייב לנסוע על הפסים, ואתה יכול להגיע “מתי שאתה רוצה”.
- ואז - אם יש לך באגים, או אם אתה גורם ל - Down-time, או דברים כאלה - הניקוד שלך יורד, ו . . . תכל’ס - לוקחים לך את הרכב, סוגרים לך את הליסינג, You name it . . .
- (רן) אגב פייסבוק - היה סיפור כזה גם בימים המוקדמים של פייסבוק על מערכת ה - Releases שלהם -
- לכל אחד הייתה “קארמה”, והיה “צאר” שהיה אחראי על כל ה - releases, והיית צריך לבוא אליו, הוא היה בודק את הקארמה שלך ומחליט האם מותר לך לעבור, מי צריך לשמור עליך וכל זה.
- מאז הם כבר שינו, ועברו לשחרור אחד (או ארבעה?) ביום, בזמנים קבועים - ואתה מחוייב להיות מוכן בזמן שהקוד שלך משתחרר הלאה.
- בכל אופן - הייתה מערכת קארמה כלשהי, שהרבה יותר מעצם ההנאה (העילאית) מכך שהקוד שלך מגיע ל - Production, גם יש קארמה ומספר “להשוויץ בו”, משהו שאתה “הרווחת” (האם זה שונה מהותית מילד שמקבל “נקודה חיובית”? :-))
- וגם זה - סוג של מדידה, וגם סוג של “מקל וגזר”: לוקחים לך את היכולת לשחרר ל - Production.
- (בועז) גם אצלנו אנחנו עם Continuous Deployment, “כשזה מוכן זה יוצא” . . .
- (אורי) גם אנחנו, אבל אני חושב שה - Scale, התלויות, גודל המערכת … - אנחנו לא במצב שאנחנו מוכנים לוותר על החופש של השחרור ל - Production “מתי שאתה רוצה”.
- אנחנו הרבה יותר עוטפים, עם כל מיני מערכות שיכוונו את המפתח לעשות “שחרור כמו שאנחנו רוצים” (למיטיבי שמע - פרק 368).
- עכשיו יש לנו פרוייקט מאוד גדול של בניית Continuous Deployment “חדש”, שהוא אוטומטי ברמה כזו שבסוף מגן, ושומר את התורים, ומשחרר, ויודע לעשות Roll-back כשצריך, כי אכן ב - Scale מסויים זה ניהיה קשה.
- (אורי) גם ה - Best Practices מתחילים . . . כשאתה עובד בצוותים מאוד קטנים מאוד קל (יחסית) לשמור על ה - Best Practices, וכשהצוות גדל מתפתחות “תת תרבויות” בתוך ה - Engineering, וחייבים להשקיע - גם באיחוד של ה - Best Practices וגם במערכות שישמרו על Best Practices האלה (ושוב למיטיבי שמע - פרק 367).
עוד נושאים שלא כיסינו? לא (זה לא קורה הרבה . . .). היה אחד מהמעניינים.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול
