שלום וברוכים הבאים לפודקאסט מספר 406 של רברס עם פלטפורמה - התאריך היום הוא ה-16 במרץ 2021, ואנחנו שוב נמצאים באולפן שלנו בכרכור, בביתו של אורי - שלום אורי, מה נשמע? (אורי) אהלן
(רן) והיום אנחנו מאחרים את ישי בארי, שאני חושב, אבל לא בטוח, שאירחנו אותו כבר פעם אחת פה, אבל בין אם כן בין אם לא - ברוך הבא, או ברוך שובך,
(ישי) תודה רבה, שלום
לפני שנצלול לעסק, בוא ספר לנו קצת עליך - מה הרקע שלך, מאיפה באת ומה אתה עושה היום?
- (ישי) אני, בהכשרה שלי ובמקור שלי, מפתח.
- באתי מ-8200, למדתי באוניברסיטה העברית מדעי המחשב, ואת, נגיד, החצי הראשון של הקריירה שלי - משהו כמו 18 שנים - התעסקתי ב-Consulting.
- מיד אחרי השירות הצבאי הקמתי, עם עוד כמה חבר’ה מהיחידה, חברה בשם Platonix - והתפרנסנו מלכתוב קוד עבור אחרים.
- מוצר ה-Licensing הראשון של Check Point, בימים שזה עוד היה ב -Access DB . . .
- (רן) זה אתה?! [ד”ש מפרק 1 באפריל?]
- (ישי) לא אני אישית - אחד החבר’ה [זוהר?]
- מגוון של פרוייקטים, קצרים ובעיקר ארוכים, לכל מיני חברות, גדולות, קטנות . . .
- (רן) אגב, אנקדוטה - בפרק שעכשיו כבר פורסם, בזמן שאתם שומעים את זה, של 1 באפריל (2021), דיברנו על האפשרות להתקין Access על Cluster של Kubernetes, ובכך לבזר אותו . . .
- (ישי) אני לא רוצה לדעת . . . [אכן]
- (רן) כן . . .
- אז התפרנסנו הרבה שנים, בעצם, מלעזור לחברות לפתור בעיות בעולם של תוכנה - לכתוב מוצרים, לדבג (Debug) דברים קשים, לרוץ יותר מהר.
- הייתה תקופה שגם השקענו בסטארטאפים, ע”י זה שכתבנו עבורם את הקוד ולקחנו Equity בתמורה - סוג של “Sweat Equity” או “Sweat VC” שהפעלנו במשך כמה שנים.
- [לא היה אז NFT, עוד #נישתי1באפריל . . . ]
- ב-2014 “עברתי את הגדר” והפכתי להיות שכיר בפעם הראשונה בחיי - זה היה אחרי שעשיתי פרויקט עבור לסטארטאפ מגניב בשם CloudLock
- אחרי משהו כמו שנה וחצי של עבודה שם כ-Contractor הם שכנעו אותי לבוא ולהצטרף שם כ-Full-timer [בדרך כלל לפרקי 1 באפריל לוקח יותר זמן להפוך לרלוונטיים . . .]
- אז הצטרפתי ל-CloudLock, סטארטאפ בעולם של סייבר ו -Could Security
- הצטרפתי שם ל-CTO Team, עבדתי עם אחד ה-Founders והקמנו את ה-CTO Team
- אחרי שנתיים וקצת נמכרנו ל-Cisco - ביליתי כמה זמן ב-Cloud Security ב-Cisco, ניהלתי קצת את ה-Site של Cisco בתל אביב
- ולפני קצת יותר משנה עזבתי - לקחתי את המשפחה לספארי באפריקה, רגע לפני הקורונה, חזרנו לארץ ב-28 לפברואר (2020) . . .
- (רן) ישר לפיראט האדום . . .
- (ישי) בערך, הרגשנו מאוד ברי מזל . . .
- (אורי) איך אתה זוכר את זה?!
- . . . (רן) אני אגיד לך איך אני זוכר את זה - היום במקרה נסעתי בכביש, לא קורה הרבה שאני נוסע בזמן האחרון אבל במקרה היום נסעתי, וראיתי חנות עם שלט ענקי, בנתניה לדעתי - “הפיראט האדום”, אז נזכרתי בזה . . . [אחלה מיתוג, סוג של . . . ]
- (ישי) כשישבנו שם, בסוף הטיול שלנו בזנזיבר, מוקפים בתיירים מאיטליה, והתחלנו לשמוע מהחדשות בארץ שיש כנראה איזושהי בעיה באיטליה, שיש שם משהו רגיש.
- עוד שבוע קדימה ולא היינו מצליחים לחזור או לצאת בכלל, אז אנחנו מרגישים מאוד ברי-מזל.
- (רן) האמת שגם אני זוכר איפה הייתי בדיוק כשזה קרה כל הסיפור הזה באיטליה - היו לי כרטיסי טיסה לאיטליה ביד . . . במקרה הייתי באילת בחופשה, אבל שבוע אחרי זה הייתי אמור לטוס לאיטליה, והשאר הסטוריה, כמובן. [איטליה? אכן היסטוריה . . .]
- (ישי) כן . . . אז חזרנו, נחתי קצת אחרי Cisco ובמאי הצטרפתי ל-LinearB - סטארטאפ שאת שני הפאונדרים שלו הכרתי מ-CloudLock
- אז הצטרפתי ל-LinearB ומאז אני שם - וזה מה שאני עושה היום.
- (ישי) ב-LinearB אנחנו עוסקים באיך לעזור לצוותים לשפר ולהאיץ את הפיתוח שלהם, להאיץ את ה-Delivery של תוכנה.
- אנחנו, בבסיס, נשענים על מידע שמגיע ממערכות כמו Git - מנתחים אותו, מוצאים Insights, מטריקות, ועוזרים לצוות, למפתח הבודד, לראש הצוות, בסוף גם לאנשי הפרודקט ולמנהלים - למצוא את ה-Bottlenecks, להעיף אותם, לשפר את התהליך ולעבוד חכם.
(אורי) אתה יכול לתת דוגמאות ל-Bottlenecks?
- ישי) כן - כתבתי קוד, הרמתי אותו, יש Pull-request שמחכה שמישהו יסתכל עליו, אבל המישהו הזה לא פנוי, או לא יודע או שכח שהוא צריך להסתכל על הקוד
- אז עכשיו הקוד הזה מחכה, ואם אני לא אזכור להזכיר לו אז זה יחכה יותר מדי.
- מתישהו זה יקרה, מתישהו אני אגיד “רגע, מה קורה עם זה?”, אולי אציק לו, אולי הוא יתפנה או מישהו יתפנה.
- זו דוגמא ל”פקק” שאפשר למנוע.
(אורי) אבל זה פקק שהוא בסדר גודל של שעות? של ימים?
- (ישי) זה מאוד משתנה - זה יכול להיות שעות, ויש צוותים ששעות זה חשוב.
- יש צוותים שימים זה רגיל והבעיה היא כשזה משהו שנגרר ליותר מזה.
(רן) אני גם חושב, אורי, שזה . . . אני לא יודע אם “Bottleneck” זו ההגדרה הנכונה, אבל זה איזשהו גורם מעכב - והשאלה המתבקשת היא האם זה פוגע ב-Latency או ב-Throughput?
- לצורך העניין, כי אם בזמן הזה שאתה לא עושה Review לקוד אתה אולי עושה משהו אחר חשוב, אז לצורך העניין זה אולי פוגע ב-Latency של אותו Pull-Request אבל לא פוגע ב-Throughput שלך כמפתח או ב-Throughput של הצוות כולו . . .
- מניסיוני לפחות, מן הסתם זה פוגע ב-Latency - אבל זה גם פוגע ב-Throughput, כי ככל שהדברים האלה נמשכים . . .
- לצורך עניין: Pull-Request, אם הוא נשאר הרבה זמן באוויר הוא הולך וניהיה חוב טכני, והוא הולך וניהיה יותר ויותר מורכב למרג’ג (To Merge) -
- כי ה-Master זז, כי אנשים שכחו מה הם עשו, כי הם עשו Context-switch למשהו אחר וכשהם יחזרו הם אולי כבר יעשו טעות, ישכחו מה הם עשו או שיניחו שכבר איזשהו Commit נכנס פנימה . . .
- בקיצור, ככל שעובר הזמן ככה אתה צובר סיכון, ובסופו של דבר אני חושב שזה גם יפגע ב-Throughput
- אז אני כן רואה את זה כאיזשהו מכשול, לא יודע . . .
- (ישי) יש באמת לא מעט מחקר סביב השאלות האלה, והאינטואציה שלך נכונה - שמה שפוגע ב-Latency פוגע גם ב-Throughput, גם מהסיבות שאתה תיארת.
- בסופו של דבר, עבודה על קוד, עבודה של מפתחים, היא עבודה שהיא יצירתית - היא דורשת מחשבה, בתקווה ...
- (אורי) היא דורשת פוקוס . . .
- (ישי) . . היא דורשת פוקוס - היא דורשת להיות “In the zone”, ויש מחיר ל-Context-switch, יש מחיר כבד להרבה דברים באוויר
- גם אם ה-Master לא זז - העובדה שיש Pull-Request שאני צריך לדפדף בינו לבין הדבר הבא שאני עובד עליו ולחזור, זה Tax שבסופו של דבר פוגע ב-Throughput
- משם בעצם מגיעה אחת המטריקות שאנחנו . . . העולם הזה, של איך למדוד תפוקה של צוותי Engineering בעולם המודרני - מתמקדים ב-Cycle-time, מתמקדים בשאלות של Latency, כי הן עוזרות ל-Throughput.
(רן) אבל אם נסתכל שנייה וננסה לקחת את זה לפן המוצרי - מה שאני רואה זה איזשהו מוצר שהוא “נודניק”: יש Pull-request פתוח - אם הוא פתוח שעה אז ננג’ס (Nudge), אם הוא פתוח יום אז ננג’ס יותר חזק . . . פתוח שבוע? שולח אליך חץ ומנג’ס יותר חזק.
אבל מה מעבר לזה?
- (ישי) אז יש פה, אולי ברמה הכי בסיסית, איזשהו אלמנט של “נודניק” - אתה יכול לעשות איזשהו Snoozer סביב משהו שתקוע
- אבל אם אתה לוקח את זה קדימה, אז קודם כל בוא תיהיה חכם - לא על כל דבר אתה צריך לנג’ס באותו מידה, ולא תמיד רק ניג’וס זה הדרך לפתור דברים.
- לפעמים Awareness זה הזדמנות למישהו להיכנס ולעזור - אולי לא יעזור להציק לך, אבל יעזור שהצוות יכיר את הבעיה ואת העניין, ואולי מישהו יכול להיכנס ולעזור.
- אולי יש פה “התחפרות” ולאו דווקא בעיה של Attention? יש הרבה בעיות שונות
- תיקח את זה עוד שלב - אתה בעצם יכול להתחיל לעשות דברים חכמים עם ההגדרה של התהליך עצמו, ושל מה אני, כצוות, או אנחנו כצוות, רוצים שיקרה בתהליך הפיתוח שלנו -
(רן) אוקיי - מה שאתה מתאר פה זה תהליך עבודה, אבל איך הכלים שאתם בונים יכולים לשפר את התהליך הזה?
- (ישי) אנחנו קודם כל מתחברים למערכות - קודם כל ל-Git ול-Jira, בתור המערכות שמהן אנחנו שואבים מידע על תהליך הפיתוח ועל האינסטנסים (Instances) של העבודה
- בעולם שלנו זה Branches ו-Pull-requests ו-Merge-request וכו’, Stories ב-Jira או ב-Project Management.
- השכבה הראשונה זה לייצר מטריקות (Metrics) ו-Analytics
- זאת אומרת - מה ה-Cycle-Time, ותיכף אפשר גם להרחיב על מה זה Cycle-Time ולמה הוא חשוב - אבל זאת מטריקה שקל למדוד אותה אם יש לך את המידע הנכון, והיא מאפשרת לצוות ולמנהלים לראות איך אנחנו (עכשיו) ואיך ואיך אנחנו משתפרים.
- אם אני לוקח איזשהו Goal להשתפר - האם אני עומד בו?
(רן) הקלטנו בעבר, לפני כמה חודשים [אוגוסט 2019 זה לפני שנה וחצי, אבל 2020 זה מרחב-זמן אחר], פרק עם בועז מ-Bizzabo, שבו דיברנו על כלים למדידת מפתחים - אני לא בטוח שהכותרת עושה צדק עם הנושא - וכנראה שכל מפתח ששומע את זה, וגם אז . . . ישר נדלקת איזושהי נורה של “רגע! איך אפשרת למדוד אותי?” . . . דרך אגב, אמרת קודם “יצירתיות”, אז איך אפשר למדוד יצירתיות? אז השאלה הראשונה היא
- (1) איך אפשר למדוד?
- ו (2) - האם המדידה עצמה אינה פוגעת ביצירתיות, במורל, אולי בסופו של דבר בשורה התחתונה של החברה, באיזשהו אופן?
- ו (3) - אם כבר קיימת כזו מדידה, אז אנחנו יודעים שטבע האדם הוא לכוון רק למקום שמודדים, ולא לעשות שום דבר אחר, ואז אנחנו עלולים למצוא את עצמנו בבעיה הפוכה - אולי המפתחים משפרים איזושהי מטריקה, אבל הם משפרים רק אותה, וזה, שוב, לא בהכרח עוזר לשורה התחתונה של החברה . . .
אז אני מניח שזה מסוג הבעיות שגם אתם מתמודדים איתן ביום-יום, ואני סקרן לשמוע את דעתך . . .
- (ישי) כן . . . אז יש פה באמת כמה סוגים של בעיות, והן גם משתקפות בהיסטוריה של האיזור הזה בשוק, או של הפתרונות שצצו ושהתפתחו לאורך השנים סביב השאלות האלה.
- אנשים תמיד אהבו למדוד דברים, תמיד רצו להישען על Data, אבל היו כמה False Starts בעולם הזה, כשבאמת זה הציף את הבעיות שאתה מתאר.
- קודם כל, כשאתה מתמקד בלמדוד אנשים, ובודאי אנשים שמתעסקים בעבודה יצירתית ולפעמים גם יצרנית - אתה יכול בקלות לפגוע ב-Culture, לפגוע באותה יצרתיות, לייצר תסיסה.
- ויותר ויותר מבינים שהדבר הנכון הוא לא למדוד אנשים - זה לא שלא דיברו איתנו מכל מיני חברות בהודו ואמרו “אני רוצה כלי שבאמצעותו אני אחליט כמה לשלם במשכורת - תמדוד לי משהו על המפתחים ולפי זה אני אשלם”.
- זו, בנינו, טעות - כשאתה מתמקד בלמדוד אנשים, אתה מהר מאוד הולך להשוות אותם, עושה טבלה - מי למעלה מי למטה - ואנחנו חושבים שזו גישה הרסנית, עד כדי . . . שלא תיתן לך את התוצאות שאתה רוצה.
- אז המוקד הוא לא למדוד אנשים אלא למדוד את התהליך ולמדוד את הצוות, זו רמה אחת.
- דבר שני שראינו שקרה, זה חברות יותר ותיקות, אם תסתכל כמה שנים אחורה, שמייצרות מטריקות ונותנות אותן למנהלים
- יש לך Dashboard לאיזשהו Executive, שמראה מטריקות - אני מודד את הארגון שלי ויש לי KPIs
- אני ה-Consumer של המטריקות האלה ואני “מנחית” KPIs לעובדים שלי של “בואו תשפרו את המטריקות”.
- (רן) סתם, כדי לעשות את זה מוחשי, בוא נגיד KPI בסגנון מספר הפיצ’רים שדולברו (Features delivered), מספר הבאגים שנסגרו, מספר ה-Pull-requests . . .
- (ישי) אני מצטער להגיד לך . . .
- (אורי) . . . או תכנון מול ביצוע . . .
- (ישי) אני מצטער להגיד שיש חברות בעבר, ועוד כאלה היום, ששואלות שאלות כמו “כמה שורות קוד המפתח הזה כתב?” . . .
- (אורי) יש כאלה חברות? . . .
- (ישי) יש . . .
- (אורי) עדיין?
- (ישי) זו דוגמא . . .
- (רן) השאלה שלי היא האם זו בעיה בהגדרת ה-KPI או עצם זה שבכלל יש?
- (ישי) אני אומר שזו בעיה בהגדרה שלהם של מה הסובייקט שאני מודד ומה ה-KPIs שאני מגדיר.
- והבעיה השנייה היא מי הצרכן של המדידות -
- זה גם הולך לכיוון של “מי משתמש בתוצאות האלה ולמה הוא משתמש בהן?”
- אבל גם, כחלק מזה - מי מגדיר מה צריך למדוד?
- (רן) זאת אומרת שהבעיה היא כשהמנהל עם השיער המחודד הזה, ההוא מדילברט - הוא זה שהולך ומסתכל על ה-Dashboard וככה הוא מודד את המפתחים שלו - וזה הולך ליצור בעיה, כנראה שלא חשוב מה ה-KPI, אפילו אם זה ה-KPI הנכון - עצם הסיטואציה שהמנהל מסתכל על ה-Dashboard ולא המפתחים עצמם מסתכלים על ה-Dashboard זה מייצר בעיה.
- (ישי) בהחלט
- (אורי) וגם אם המנהל מחפש למדוד את המנוהלים, במקום למדוד את התהליך של עצמו . . .
- (ישי) נכון.
- אז אנחנו חושבים ששתי הבעיות האלה מזינות אחת את השנייה - הן חיות נפרדות, אבל הן עובדות ביחד.
- מי משתמש במטריקות ובשביל מה, ומה אתה מודד.
- אז הנטייה שלנו - אבל אנחנו לא היחידים בעולם הזה - והדרך, שבנינו היא החיובית, שאפשר לגשת ולפתור בעיות בעולם הזה של ה-Delivery - זה למדוד את הצוות, למדוד את התהליך
- לא את התפוקות - אל תמדוד כמה פיצ’רים (Features) הוצאת או כמה קומיטים (Commits) או כמה שורות קוד
- תמדוד את התהליך עצמו, תבין את ה”בריאות“ של התהליך - ותשתמש במדידות ככלי לאנשים עצמם
- כלי ל-Introspection, כלי לצוות שרוצה לשפר את העבודה שלו, לא ככלי שמודד “ומעניש” או מודד ומצ’פר את מי שעלה במדד.
(רן) אבל זה נשמע כאילו בלתי נמנע שזה יקרה . . . ניקח, לדוגמא, את המאגר הביומטרי: נניח שהמטרה של המאגר הביומטרי בישראל היא מטרה נעלה וטובה והכל - אבל עם זאת, ברגע שנוצר מאגר ביומטרי יש איזושהי סכנה שהוא ידלוף, יש איזושהי סכנה בעצם היצירה של מאגר מידע כזה.
אז הנמשל של זה - גם אם זה כלי שיצרת לצורך המפתחים, כדי שיוכלו לשפר את הביצועים שלהם עצמם, הם תמיד אולי יחשבו “אוקיי, אבל מה יקרה אם המנהל שלי גם יסתכל על זה, ופתאום ימדוד אותי במספרים ולא לפי השיער היפה שלי או לפי האופי המקסים שלי?” . . .
אז אני מנחש שעדיין, גם אם אתה בא ומוכר את זה למפתחים ככלי לעצמם - הם כנראה יסתכלו על זה בחשדנות.
- (ישי) יש סכנה כזאת, אני אנסה לא ליפול לקלישאות סביב איפה הבעיה
- אבל אני אומר - קודם כל, המידע קיים . . . המידע שאנחנו מוצאים - לא המצאנו אותו, חילצנו אותו ממערכות קיימות.
- בהרבה מקרים החברות שאנחנו מדברים איתן הן חברות שלא באות בלי שום מטריקות ובלי שום Practice.
- אז הן “תופרות” את זה בעצמן או בונות סקריפטים או בונות משהו חלקי - כמעט אין ואקום של “אני לא מודד כלום”.
- הסכנה היא שדווקא אם אתה עושה את זה קצת Less informed וקצת יותר פארטצ’, יש סיכוי שתיפול לבורות של המדידות הקלות . . .
- קל מאוד למדוד שורות קוד, הכי קל בעולם - אז יש ארגונים, שאם האלטרנטיבה היא לא לעשות כלום, אז יקום הבוס הזה עם ה Pointy hair וימדוד את השורות קוד, כי זה מה שהוא יכול להרים בסקריפט קטן בצד, או לקנות בזול - וישתמש בזה לרעה.
- האם במטריקות שאנחנו מייצרים אפשר להשתמש ברעה? אני מניח שכן.
(אורי) אבל אני מניח שכמעט כמו כל חברה שנותנת כלים למדידה, בסוף היא חושבת על מה הם ה-KPIs שאתם רוצים למדוד, ומאחורי זה ישנה איזושהי תפיסה של מהו תהליך נכון או מה זה “תהליך טוב” ואיזה KPI מייצגים אותו - אז בואו נמדוד אותם. השאלה האם יש לכם, בהנחת המערכת, איזושהי תפיסה כזו?
- אני יכול להגיד מה זה תהליך טוב מבחינתי - מבחינתי, תהליך טוב זה כשהמפתח הוא כמה שיותר Self-sufficient, אין לו מעצורים - הוא יכול לקחת משהו מרעיון ל-Impact בשוק לבד.
- הרעה החולה, מבחינתי, ביעילות של דברים כאלה זו קבלת החלטות - אם אני נעצר על קבלת החלטות . . . אני לא אראה את הדברים האלה ב-GitHub בכלל - איפה שאני נעצר על קבלת החלטות.
- יכול להיות שאני אראה משהו ב-Jira תקוע או כל מיני . . .
- (ישי) נכון - אז קודם כל, Git לא מייצג את כל התמונה - יש לו יתרונות אדירים, אני חושב שהמעבר של עולם ה-Software ל-Git זה איזשהו Seminal change שמאפשר, בין השאר, גם את העולם שאנחנו מתעסקים בו, ואת החלק הזה של העולם של Analytics על תהליך הפיתוח.
- הוא לא מייצג את כל התמונה - תהליך של פיתוח ויצירת Value בקוד נשען על Git אבל מתחיל הרבה לפני כן, וממשיך הרבה אחרי ה-Git בתהליך של “איך הלקוחות משתמשים” . . .
- (אורי) . . Go to Market . . .
- (ישי) . . . וה-Impact של הקוד על העולם - והכל נחשב, הכל רלוונטי.
- לגבי השאלה של “מהו התהליך הנכון” - אז אנחנו מצד אחד מודעים מאוד לשוני העצום, ואנחנו רואים אותו, בין ארגונים ואיך שהם עובדים
- מה חשוב להם ואיפה הם נמצאים היום - גם ארגונים שיש להם את אותו Target דימיוני, אותו כיוון - הם במקומות לגמרי שונים, אתה לא יכול לשפר את הסוסיתא של שנות ה-60 ואת מכונית המירוץ הכי חדישה באותם כלים, למרות שהמטרה (בשני המקרים) היא “לנסוע יותר מהר”.
- הכלים שונים כי אתה נמצא במקום אחר
- אז מצד אחד, פתרון - גם שלנו וכל פתרון Viable בעולם הזה - חייב להביא בחשבון את השונות
- ומצד שני - יש ערך בלבוא עם Opinions ובלבוא עם . . . לא רק להגיד “שמע, אני מודד לך מיליון דברים, תסתדר ותפיק מזה מה שנראה לך”.
- פה למשל הבחירה שלנו להישען על Cycle Time כאחת המטריקות החשובות זו בחירה שיש מאחוריה Opinion, ונסיון להגיד ש-Latency יותר חשוב מ-Throughputאו ש-Latency מייצר Throughput יותר טוב
- זה (א) טעון הוכחה ו(ב) אולי לא מתאים לכולם.
(רן) נשמע שבכדי למכור מערכת כמו שלכם צריך מאוד “לחנך את השוק”, וזה נשמע ככה אתגר, אתה יודע - א’-ב’ של יזמות זה “במקום שבו יש Market Education, קח הרבה אוויר, זה ייקח הרבה זמן” . . .
- (ישי) האמת שאני קצת מופתע לטובה, בהקשר הזה.
- אני נמצא ב-LinearB קצת פחות משנה, ואני רואה, גם קצת ממה ששמעתי בזמן לפני שהגעתי אבל גם תוך כדי הזמן שאני נמצא - יש לא מעט Educated Market כבר באיזור הזה.
- עיקר ה-Business שלנו מגיע מ-Incoming - אנשי מוצאים אותנו . . . אנחנו עושים Marketing, אבל אנחנו כמעט לא עושים Direct outreach.
- מוצאים אותנו ופונים אלינו עם Intent - “אני מחפש כלי ואני רוצה לקנות”, לא “ספר לי למה זה טוב”.
- לא שאין את זה, אבל ה-Intent כבר קיים - אנשים מבינים יותר ויותר, מחקרים וספרים כמו Accelerate ודור המטריקס וכו’ . . . אנשים כבר מכירים את זה.
- (רן) דרך אגב - אתה חושב שלהשפעה של תקופות הקורונה ושל העבודה מרחוק - שיש לזה השפעה . . .?
- (ישי) כן, בהחלט, חד משמעית - זה לא משנה את ה-Education, אבל זה מייצר יותר דחיפות . . .
- (אורי) אני בטוח שזה היה . . . אתה יודע, אלו שאלות שהגיעו מ-Boards [הנהלות, לא של Jira], מ-Executive Teams - “החבר’ה עברו לעבוד מהבית - איך אתה יודע שה-Velocity נשמר? שה-Throuhput של הצוות נשמר?”
- (ישי) אז או שזה בא למלמעלה, בחברות קצת יותר גדולות, או מהבטן של מנהלים, שאומרים “אני מרגיש שאני מאבד שליטה” - ואחת הדרכים לחזור ולהבין מה קורה “ולחיות את הצוות” זה אולי קצת למדוד ושיהיו לי מערכות . . .
- (אורי) היפה הוא שהאשליה ש”אני נמצא במשרד עם האנשים אז אני יודע שה-Velocity הוא טוב” זה . . . אתה מגלה כמה שזה היה פיקציה . . .
- (ישי) נכון - אז אני חושב ש . . .
- (רן) ה-Velocity של הקפה . .
- (אורי) כן, המכונת קפה . . .
- (ישי) תראה - יש מקרים קיצוניים שבהם לפני Covid-19 ישבו כולם באותו חדר, ישבו 6-7-8 אנשים באותו Space והתקשורת הייתה ב”להרים צעקה” למישהו או להסתובב עם הכיסא, ופתאום הם נשאבו לעולם כזה, למעיין Void שבו כל אחד בבית, ואז אני בהחלט מבין את התחושה של “אני לא יודע מה קורה”
- אז אני חושב שהקורונה ייצרה עוד דחיפות, אולי ייצרה עוד תקציבים לארגונים שפחות יכולים לצטייד ו(עכשיו) יש להם הצדקה.
- היא לא ייצרה מודעות “יש מאין”.
(אורי) אנחנו שלושה אנשים פה, כל אחד מחברה אחרת. כולנו עברנו את הקורונה . . . איך אתם קיבלתם ולידציה (Validation) על עצמכם, שאתם בסדר, במעבר הביתה?
- (ישי) מה שאני עושה כמעט בכל Demo שאני מראה את המערכת . . . אני פותח את המטריקות שלנו.
- ה-Demo-אים שאני עושה זה תמיד LinearB על LinearB . . .
- אין לי Demo Data, יש לי Production Data - ומה שקורה היום זה מה שהלקוחות יראו.
- אני פותח את ה-Metrics שלנו ומסתכל אחורה, לוקח אחורה עד ינואר 2020 - ומראה לכולם את ה-Spike שיש לנו ב-Cycle-time, שקפץ במרץ, ב-Lock-down הראשון, פי איזה 2 . . .
- כי היינו קבוצה קטנה ופתאום נהיינו Remote וה-Cycle Time שלנו סבל, לקח לנו קצת זמן להחזיר אותו.
- כי כל התהליך של תקשורת על איך קוד נכנס והופך ל-Production השתנה . . .
- (אורי) אז סבלתם מזה?
- (ישי) סבלנו מזה - רואים את זה ב-Data
- אני לא הייתי אז בחברה אז . . . אני רואה את זה ב-Data אבל שמעתי את זה גם מאנשים, מה הם עשו ואילו תהליכים הם עברו כדי להתמודד.
- ומה שגם ראו, ושמענו את זה מעוד חברות - גם מלקוחות אבל גם סתם מדיבורים - אנשים כתבו יותר קוד . . . אנשים בבית עברו לעבוד ב-remote והרגישו שהם מפגיזים - כותבים יותר קוד ויש פחות הפרעות, יש פחות פגישות, עוד הייתה קצת רומנטיקה בסגר הראשון . . .
- אנשים הרגישו שיש להם יותר תפוקה.
- מצד שני - האיזורים של התיאום והתקשורת, שצריך כבר 2-3 אנשים לשתף פעולה כדי שמשהו יקרה - הם סבלו.
- אז כתבו יותר קוד - אבל ה-Cycle Time התארך, ולקח יותר זמן לגמור דברים ולהביא אותם ל-Production.
(אורי) איך אצלכם (רן)?
- (רן) האמת שקשה קצת להגיד, משתי סיבות -
- (1) הייתי בהרבה פעמים מנהל, אבל בתקופה שלפני הקורונה דווקא לא היית בפוזיציה של מנהל, ופחות או יותר כשהתחילה הקורונה אז נכנסתי שוב לפוזיציה של מנהל, כך שקרו שני שינויים בו-זמנית, ואין לי Test ו-Control Group, אז קצת קשה לי להשוות . . . [אבל לגמרי רואים את השפעות החשיבה הסטטיסטית….]
- (אורי) אבל השאלה הזו נשאלה - האם אנחנו בסדר? מה המעבר הזה ל-Remote עשה?
- (רן) כן - השאלה הזו נשאלה, אני לא יכול להגיד לך מה התשובה . . . אני לא יודע מה התשובה.
- סליחה - אני כן יכול להגיד לך שברמת המאקרו, התשובה היא שאנחנו הצלחנו לשמר Velocity, אפילו לשפר Velocity, בצורה שמאוד הפתיעה אותנו, ואת השוק
- גם היו עוד כמה שינויים, אגב - אצלנו ספציפית היו גם הרבה שינויים של השוק לאור הקורונה, שגם הם ככה די, אולי בפוקס, רתמו את כולם לאלונקה
- וכולם נכנסו מתחת לאלונקה וכולם עבדו - מה שאולי בחברות אחרות לא קרה.
- בשורה התחתונה, אני אני חושב שאנחנו הצלחנו להפתיע את עצמנו בפרודוקטיביות בתקופה הזו, אבל אני חייב להגיד שאנחנו גם משלמים מס כבד ב-Retention, במוראל, בשחיקה של אנשים, שהוא מאוד מאוד משמעותי
- קשה אולי להגיד אם זה בגלל שעות עבודה או חוסר המסגרת הברורה של העבודה
- אולי זה שפחות רואים אחד את השני . . .
- מכל מיני סיבות, אבל בסופו של דבר - השחיקה מורגשת, השחיקה מאוד מורגשת וכל הזמן מדברים על זה.
- עכשיו - זה נושא אולי לפודקאסט אחר . . .
- (אורי) פוסט-קורונה, נעשה אותו אחרי ש . . .
- (ישי) מסתבר שמפתח הוא חיה חברתית, למרות הכל.
- (אורי) כן . . . אנחנו . . . בדרך כלל אנחנו לא מודדים, ואז באמת שאלנו את עצמנו “רגע - מה אנחנו יודעים?”
- אבל עוד פעם, ברמה של אני ומנהל הפיתוח, אמרנו “בוא נעשה לפחות איזשהו Sanity check, נראה שאנחנו בסדר”.
- והסתכלנו על מספר ה-Deployments, כי פשוט בשבילנו, מספר ה-Deployments הוא ה . . ה-Deployment היא הנקודה שבה המפתח מעביר את ה-”Intellectual Property” שלו למוצר אמיתי בשוק.
- וכשראינו שמספר ה-Deployments היומי ממש לא משתנה לאורך שבועות או . . .אז אמרנו “אוקיי, המצב כנראה בסדר”.
- (רן) כן, זהו - אז זה קצת מביא אותי לשאלה של “אוקיי, אז אתם מודדים מספר Deployments, ישי - אתה מדבר על . . . “
- (אורי) עוד פעם - זה לא שאנחנו יושבים על המפתחים “מה קורה עם מספר ה-Deployments?!” . . . אנחנו מסתכלים על זה באירועים כאלה כדי לעשות לעצמנו ולידציה שהכל בסדר.
- (רן) כן, זה איזשהו מדד-מאקרו, זה לא . . .
- (אורי) לגמרי.
(רן) עכשיו ישי - אתה מדבר הרבה על ה-Cycle-Time - אתם אצלכם מודדים Cycle-Time ואתה חושב שזה משהו חשוב, שה-Latency משפיע האופן מאוד משמעותי על ה-Throughput. . .
בוא נדבר רגע - מה זה “Cycle”? איך מודדים “Cycle”?
- [מעניין גם בהקשר של Effort Estimations]
- (ישי) אז אקדים ואומר ש-Cycle-Time הוא אחד המדדים, ולמשל . . .
- (אורי) כמו ב-Intel, כשמגדילים את ה-Cycle-Time של ה-CPU . . .
- (ישי) אפשר לחשוב על זה כעל סוג של RPM, סוג של סל”ד של הצוות . . .
- אם אתה מסתכל על קצב ה-Deployment אז הוא סוג של דואל (Dual) לחלק מה-Cycle-Time - אתה לא יכול לדלבר (Deliver) ולעשות Deployments תדירים אם ה-Cycle-Time שלך נורא ארוך.
- אז ה-Cycle, בעולם שלנו, זה כמה זמן שלוקח ליחידת עבודה מהשורת קוד הראשונה שנכתבת עבורה ועד שהיא בחוץ, בידיים של הלקוח, עד ה-Deployment.
- זה ה-Cycle שאנחנו מסתכלים עליו.
- (רן) אוקיי, אז אתם לא מודדים את כל מה שלפני שורת הקוד? - Design ו-Product-Market Fit ו . . .
- (ישי) אלה דברים שחיים לפעמים בהגדרות של Lead-Time, והיום אנחנו פחות מתעסקים בהם.
- היום אנחנו עדיין סטארטאפ, אבל הם רלוונטיים לשאלות ולעולם הזה של דליברי (Delivery).
- (רן) אז מרגע כתיבת שורת הקוד ועד מתי?
- (ישי) עד שהוא בחוץ . . . עד שהוא Deployed . . .
- (רן) עד שהוא Deployed, אוקיי . . . ואם, לצורך העניין, הוא Deployed אבל Embarged ועם Rollout אז יש לזה טיפול מיוחד?
- (ישי) אז ההגדרות של מה זה “Deployed” מתחילות בצורה יותר נאיבית של משהו בינארי - זה בחוץ או לא?
- ואם כן אז מתי?
- וזה צריך להתפתח ל-Target - האם זה יצא? האם זה מודלק (On) אצל הלקוחות? האם משתמשים בזה?
- (אורי) כן - כי יש הבחנה בין “Deployed” ל-”Released” . . .
- (ישי) לא כל הארגונים מבחינים . . .
- (רן) לא כולם יודעים, אתה אומר . . .
- (אורי) “Deployed” זה אומר “הקוד שלי יושב כרגע בסביבת Production”, ו-”Released” זה אומר . . . זו החלטה מרקטיאלית (Marketing), זו לא החלטה אנג’ינירית (Engineering) . . .
- (ישי) נכון, אז (א) יש הרבה ארגונים שבהם זה קורה ביחד . . .
- (אורי) מצומד . . .
- (ישי) . . . ולא ממש מבחינים, או שגם לא מייצרים לעצמם את המנגנון שאומר “זה חי ב-Production אבל עוד לא Released”.
- או שהם אומרים “אין אצלי את ההבחנה הזאת, וקוד שיצא הוא GA ללקוחות, כולם רואים אותו, כולם משתמשים בו והכל טוב”.
- אנחנו מאפשרים חופש כלשהו בהגדרה של כל (שלב) שהלקוח עושה לעצמו, או אפילו בכל שלב של Repository, של מה זה אומר “Released” - “אצלי”
- כשהמטרה היא למדוד את מה שמעניין אותו כדי להשתפר
- אם (עבור) צוות מסויים, הדבר שחשוב שחשוב לו זה “שמתי את זה על Staging ומפה זו לא הבעיה שלי Anymore”, אז אני לא אתווכח איתו ואני אעזור לו למדוד את זה.
- יכול להיות שמכאן עכשיו זו בעיה של צוות אחר - DevOps או צוות Deploy או IT . . . יש הרבה Flavours בעולם.
- המטרה היא למצוא את הנקודה שבה ה-Value יצא, וההגדרה מה זה בדיוק “יצא”, זה יכול להשתנות.
- אולי זו ספרייה ואז שמתי Artifact איפשהו וזהו . . .
(רן) בוא ועכשיו אני אהיה “פרקליט השטן”, ואני אגיד “אתה מודד את ה- Cycle-Time? אז אני אקטין את ה-cycles . . .”
- במקום לדלבר פיצ’ר שלם, אני אדלבר ככה חצי-פיצ’ר . . . ואחר כך אני אוסיף עוד קצת ועוד קצת ועוד קצת
- ככה יהיו לי הרבה מאוד Cycles קטנים, כשכל אחד מהם יהיה מאוד מאוד קצר - ושיפרתי את ה-Cycle-Time שלי . . .
למה שאני לא אעשה את זה? אני אראה יותר טוב בעיני המנהלים שלי, נכון?
- (ישי) שתי תשובות, והן משלימות -
- (1) שוב - זו מדידה של תהליך ושל צוות, שהוא עם קצת פחות Incentive to game it, כי אני לא גורם לעצמי להראות יותר טוב כי מודדים אותי אישית, יש קפיצה פה של “בואו נרתום את כל הצוות לתהליך, לשחק עם המטריקה”.
- אבל הדבר היותר חשוב (2) - אם הצלחת לעשות את זה, ויש לך Cycles קצרים כי חתכת את העבודה לאלמנטים קטנים - הרווחת.
- זה חלק מהמטרה של Cycle-Time - אם הצלחת To Game it, בגלל שהוא מקיף את כל התהליך, אם הצלחת לגרום ל-Cycle-Time להיות קצר, אז המוטיבציה שלך פחות חשובה לי, התוצאה היא טובה.
- אם שברת את הפיצ’ר לכמה חתיכות שהן Deployable - אני בעד, זו המטרה.
(רן) אוקיי, אז Cycle-Time - אמרת שזה מדד אחד אבל לא המדד היחידי, ודיברנו עליו והוא באמת מאוד חשוב.
תוכל לתת דגומא למדד אחר, שאתם משתמשים או שהלקוחות שלכם משתמשים?
- (ישי) כן, אז אורי הזכיר את הנושא של Deployment Frequency - כל כמה זמן, באיזו תדירות ובאיזו רציפות אנחנו מוציאים Value החוצה -
- זה אחד המדדים החשובים, וגם הוא מופיע במעמד של כבוד במטריקות של DORA ודומים להם.
- הוא מדד מצויין כדי להבין את הבריאות של תהליך הדליברי.
- שוב - הוא לא יכול להיות טוב אם ה-Cycle-Time לא טוב ולהיפך - הם משלימים אחת את השני באיזור הזה של הצד של ה-Deployment.
- יש ארגונים שעוד לא פיתחו את כל השרשרת של ה-CI/CD ויש שם “בלוק טכני”, מה שנקרא - הם לא בנויים להוציא כל הזמן, לעשות Deploy כל הזמן.
- אז יכול להיות שיש להם ועדה שעושה Deploy ו-Release פעם בשלושה שבועות, אז התוצאה של המדד הזה תיהיה “פעם בשלושה שבועות”, כי זה מה שהחלטנו . . .
- (אורי) כן, אבל איך אומרים - אם אתה לא מודד אתה לא משתפר, אז במקרה הזה, ברגע שמתחילות מדידות, אז “אה, אוקיי - אז איך אני מוריד פה Bottlenecks?” או “איך אני משפר את התהליך?” . . .
- (ישי) נכון - אז חברות כאלה, ויש לנו לקוח שגם כתבו על זה בלוג, על איך שהם עברו ל-Release יומי - ממצב כזה של פעם בכמה שבועות, הם עברו למצב של פעם ביום Release, וזה היה שיפור אדיר מבחינתם.
- אז גם כשאתה עובד במצב של “וועדה” שמייצרת Release פעם בשלושה שבועות - להבין, למשל, כמה זמן הקוד שלך מחכה - זה בממוצע חצי מהשלושה שבועות אבל אתה יכול לקבל קצת יותר הבנה של איזה חלק מהקוד מחכה, האם אני נותן Push לקראת סוף הספרינט ואז יש לי מלא קוד ברגע האחרון ואז הוא בעצם מחכה רק יומיים ל-Release - אז דרך המדידה אתה רואה את אלה.
- גם אם לא תשפר את השלושה שבועות, אתה תבין קצת יותר את הדינמיקה של כמה זמן הקוד שלך “שוכב”, בעצם בלי להביא Value לאף אחד.
- (אורי) זה נשמע לי . . . לא יודע, רן בטח גם לך - קצת . . .
- (רן) שנות ה-80 . . .
- (אורי) . . . פרה-היסטוריה . . .
- (ישי) מה - Delivery פעם בשלושה שבועות?
- (אורי) אפילו פעם ביום . . .
- (ישי) תתפלא . . .
- (רן) . . . פרויקט הלביא . . .
- (ישי) תשמע, יש חברות שה-Delivery שלהם זה Hardware, ואז זה Firmware שנכנס למשהו שהולך ונכנס לקופסא . . . יש כאלה.
- (אורי) לא על זה אנחנו מדברים וזה בטח גם לא רוב קהל הלקוחות שלך, נכון?
- (ישי) נכון - אבל יש לנו גם כאלה שתהליך ה-Delivery שלהם תלוי באישורים מגורמים רגולטוריים, מה לעשות?
- (רן) דרך אגב - גם על זה הולך להיות לנו פודקאסט, על איך עושים Continuous Delivery תחת רגולציה מאוד כבדה - אז !Stay Tuned - אבל לא היום.
אנחנו ממש ככה לקראת הסוף, ורציתי לשאול משהו שמאוד מענין אותי - אז בעצם, דיברת בעיקר על Visibility, ודיברנו על מדידה של Cycle Time ומדידה של מספר ה-Deployments ודברים אחרים שאולי הארגון רוצה למדוד.
אבל אוקיי, עכשיו ראינו - מה עכשיו? האם הכלי הזה גם נותן איזה שהם כלים של פרודוקטיביות (Productivity)? איזושהי אוטומציה או . . .
- (ישי) כן, אז דיברנו על Visibility כי זה ה-Entry Point בעולם הזה
- זה הצעד הראשון - בלי Visibility אתה לא יכול לעשות כלום
- אתה לא יכול לשפר שום דבר בלי למדוד אותו ובלי להבין אותו
- אבל חלק מה-Evolution בתחום הזה, במעבר ממדידה של אנשים למדידה של Process, ממדידה שיושבת אצל הבוס למדדים שמגיעים לידיים של המפתחים ושל הצוות.
- הצעד הבא של ה-Evolution הזה הוא לעבור ממדידות ל-Actions ול-Automations.
- אז דיברנו כבר על ה”נודניק”? הנודניק הזה הוא ההתחלה או המבשר של תהלכי ה-Automation - הוא הופך את זה מ”ראיתי שהייתה בעיה בחודש האחרון - בוא נעשה Retrospective ונלמד למה ה-Deliveries שלי מתעכבים” ל”בוא נפתור עכשיו, טקטית, נקודתית, את האחד הזה שמתעכב”
- והפכתי את זה לבעיה שהיא Reaction לאיזשהו Signal, ולא למידה ממטריקה.
- לשניהם יש מקום, אבל זה צעד קדימה.
- אם תיקח את זה עוד טיפה קדימה, ופה אני קצת נכנס לאיזורים של ה-Vision שלנו - אנחנו מדברים על תהליך פיתוח: איך אני עושה Branches? איך אני מחבר את זה ל-Jira? למה אני נותן עדיפות? איך אני שומר על . . . איך אני עושה Code Review וממרג’ג (Merge) דברים ואיך אני עושה את זה בתוך קבועי זמן שחשובים לי?
- את ה-Dev-Process הזה - אפשר לעשות לו Shift-Left ולהפוך אותו למשהו שהוא Automated, ויש לו Guard rails שהם בעצם מגיעים מהמפתחים
- בוא תגדיר גם אותו בקוד, או ב-Configuration.
- כי היום הוא בסופו של דבר יושב במוח של האנשים בצוות, בתרבות שעוברת מיד ליד - מפתח חדש בא לצוות ואומרים לו “תשמע, אצלנו עושים ככה - ביום ראשון עושים Release” או “ביום חמישי עושים Planning”.
- וכמו כל דבר, כל דבר טוב - צריך לעשות פה Shift-Left: בסוף זה קוד והמפתחים הם ה-Owners של התהליך הזה
- להגדיר מה זה חריג ומה להתריע ולמי להתריע, או לעשות משהו אחר עם הדבר החריג הזה.
- למשל - הם לעצור Release-ים ביום חמישי בערב, מה שאנשים היום עושים מהבטן, כי נהוג לא להוציא Release חשוב רגע לפני שהולכים לסופ”ש?
- את כל הדברים האלה - אפשר לעשות להם Shift-Left וממש להפוך אותם למשהו שהוא גם מוגדר ונשען על המון מדידות מכל המערכות, צריך לעשות Correlation בין כל המידע.
- (רן) אתה, כאילו, בא ואומר “בואו נקודד את התשוב”ע” . . . למדנו מניסיון של הרבה שנים שלא עושים Release ביום חמישי בשבע בערב, כי זה הולך לדפוק לנו את הסופ”ש, אוקיי.
- אז (1) זה באמת לבדוק האם יש . . . האם זו רק תחושת בטן או שבאמת יש Data שתומך בזה
- ו(2) זה שאם יש באמת Data שתומך בזה וזה משהו שאנחנו לא רוצים לעשות - אז שיהיה מי שישמור, ואם באמת מישהו יבוא וירצה לעשות Release בשבע בערב ביום חמישי, אז מישהו יעצור אותו, או לפחות ידליק לו נורה גדולה אדומה מול העיניים, שידע שהוא עושה משהו חריג [שדינו סקילה].
- (ישי) כן, אתה רואה היום התחלות . . . לרוב זה קורה בצורה מאוד Fragmented [נישתי…] - כל מערכת יודעת לייצר Gates ו-Guard Rails לאיזור שלה
(אורי) יש לי שאלה - האם אתה חושבים, ב-Vision של החברה, לחבר לזה ייעוץ? לדוגמא - “מדד מסוים הוא חריג אצלך, מה הכלים שלך להתמודד עם זה? מהם הכלים שלך לשפר את המדד הזה?”
- (ישי) כן, אז מעבר ליצירה של Insights שמבוססים על המדד, על ה-Best Practices ו-Benchmarks - יש תעשייה, יש Data.
- אבל גם Benchmarks שלך - “שים לב! יש לך עלייה באיזשהו רכיב ב-Cycle-Time לאורך זמן, הנה הגורמים ה-Possible של הדבר הזה והנה הדרכים שבהן כדאי לך להתמודד איתם”, זה בהחלט . . .
- (אורי) הרבה פעמים הפתרונות הם לא טכניים - הם תרבותיים לגמרי.
- (ישי) חד-משמעית.
- אני אקח דוגמא שלרוב קל להתחיל איתה, וככה אנחנו ממליצים לארגונים שאנחנו עובדים איתם - תהליך ה-Pick-up:
- ללכת והלתחיל לעשות Review למישהו על ה-Code שלו - זה זמן שהרי בהרבה מקרים מגלים שהוא ארוך, ו-Pull-Requests מחכים רק בשביל שיתחילו.
- ונורא קל לקצר אותו, כי אתה עושה מה שנקרא “Delivery Context switch” -
- לעשות למישהו Code Review זה הרי Context Switch, זו לא העבודה העיקרית שלי -
- אבל אני עכשיו חזרתי מ-Lunch או סיימתי פגישה, ואני עוד לא ב-Zone - עכשיו זה זמן טוב, בוא נעשה את זה באופן Delibrate, נחפש את ההזדמנות לעשות Review - זה משהו שהוא תרבותי לחלוטין.
- צוותים יכולים להחליט שבבוקר ואחה”צ “מנקים את ה-Reviews” - וחתכת את ה-Pick-up time שלך, או לפחות שמת עליו Cap של כמה שעות.
- (רן) יש שיטה לניהול זמן, ברח לי השם שלה, שהיא מתודולגייה דומה לקריאת אימיילים - אתה לא כל הזמן קורא אימיילים אלא קורא אימיילים, נגיד, 3 פעמים ביום, בשעות קבועות . . .
- (אורי) . . אבל ה-Inbox שלך ריק . . .
- (רן) כן, אז יש כמה דברים שם, אבל . . .. לשים איזה שהם קבועי זמן שמייצרים איזושהי שיגרה ואז הרבה יותר ברור . . . [זו אופציה - Pomodoro Technique]
- אתה גם לא נסחף - נגיד, אתה קורא אימיילים בין 1300 ל-1330 אבל לא יותר, ואת מה שלא סיימת אתה תמשיך אח”כ.
- וזה נותן לך איזה שהם מרווחי זמן אחרים, יותר קבועים וברורים, לעשות עבודה אחרת, שהיא כנראה יותר משמעותית כי, סתם בדוגמא של קריאת אימייל, קל מאוד להיסחף לפעמים ולא לתעדף נכון את העבודה.
- (ישי) אז DEV INTERRUPTED זה . . .
- (אורי) רגע! אני אעשה לך Interrupt . . .
- (רן) הוא לא Dev . . רגע, אתה Dev?
- (ישי) אני Dev . . . זה לא יורד במים, להיות Dev . . .
- אז DEV INTERRUPTED זו Community שאנחנו הרמנו -
- יש לנו Discord עם משהו כמו 800 Dev Leaders מכל העולם.
- פודקאסט שהולך ותופס תאוצה, פודקאסט באנגלית
- ואנחנו בעצם בונים חבורה של אנשים שמתעסקים בהובלה של ארגוני פיתוח או של צוותי פיתוח, או מתעניינים בשאלות האלה של מה זה אומר להוביל ולהיות יעיל בעולם של פיתוח.
- וזה ה-DEV INTERRUPTED
- (רן) אוקיי - אז פשוט לגגל (Google) את DEV INTERRUPTED [או ללחוץ על הלינקים . . . ]
- (ישי) . . . ותמצאו אותנו, ותמצאו את ה-Discord.
- (רן) בסדר, ואתה אומר שהשיחה עצמה היא באנגלית כי זה מכל העולם.
- (ישי) השיחה באנגלית - אנחנו עושים קצת Moderation אבל בסך הכל המטרה היא שזה יהיה אורגני ושאנשים ידברו על מה שמעניין אותם.
- אני חושב קצת בראש על לעשות נגזרת בעברית . . .
- (רן) אוקיי - ולמעשה אתם מדברים על נושאים כאלה של איך נכון למדוד ולשפר . . .
- (ישי) אז זה לא רק מדידות - הייתי אומר שכל העולם של מה שמעניין את מה שנקרא Dev Leaders -
- אנחנו מדברים שם גם על Hiring וגם Coaching של אנשים בצוות וגם על תפקיד של Senior שהוא לא Leader.
- השיחות הן באמת מאוד מגוונות - בסוף זה Community שאנחנו הקמנו והיום אנחנו דוחפים אותו, אבל הוא לא Focused רק על המוצר שלנו או אפילו רק על מטריקות ויעילות.
- (אורי) חיפוש של DEV INTERRUPTED ב-Google יגיע אליכם?
- (ישי) חיפוש של DEV INTERRUPTED ב-Google יגיע אלינו . . .
- (רן) וכמובן שגם נקשר ב-Show Notes
- [עוד הפנייה מעגלית? יאללה - DEV INTERRUPTED באתר וה-Discord Channel והפודקאסט]
טוב - ישי תודה רבה! תודה שהגעת לפה, היה מאוד מעניין.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול
אין תגובות:
הוסף רשומת תגובה