
77: איך יודעים שהגיע הזמן לשינוי במבנה הארגוניEpisode 64דניאל לריה וערן הלפט
דניאל לריה
ערן הלפט
77: איך יודעים שהגיע הזמן לשינוי במבנה הארגוני
אנחנו מדברים על שינוי מבנים ארגוניים בחברה. אורחים: דניאל לריה, Head of R&D וערן הלפט, Product Team Lead במאנדיי.קום.
Every startup experiences growing pains. Processes that are working great in a team of five, can become ineffective or inefficient in a rapidly scaling team. At the end of 2019 we experienced such a growing pain ourselves. It was when after a few months of process slowdown, we realized there is a need for a structural change in the R&D, Product and Design teams. We replaced the “Task Forces”, ad-hoc teams structure we were using then, with “Domains” - permanent teams who are developing a deep understanding and expertise in a certain area in the product.
No matter what is the current size of your company - this topic will probably be relevant to you during your startup journey. How do you know when it is time for a change in the organizational structure of a team, department, or company? How do you ‘say goodbye’ to an existing structure, and what do you need to consider when making such a change? And how do you know what is the right alternative structure for you?
This week we are speaking with Daniel Leraya, Head of R&D, and Eran Helft, Product Team Lead at monday.com. Daniel and Eran detail the process of the organizational change we did at the company, starting from identifying the problem to the way this change was portrayed to the company. They share the advantages and disadvantages in each of the structures, the concerns they had along the way, and the questions we need to ask ourselves when we realize it’s time for a change.
Episode transcript
Automatically transcribed — it may contain errors.
היי כולם, הגעתם לסטארטאפ פור סטארטאפ, הפודקאסט שבו אנחנו חולקים מהניסיון, מהידע והתובנות שיש לנו כאן במאנדי.com וגם מחברות אחרות, הוא מיועד לכל מי שסטארטאפ מדבר עליו, לא משנה באיזה כיסא הוא יושב ברגעים אלו. סטארטאפ פור סטארטאפ. לפני שנצלול על נושא של היום, נזכיר לכם שיש לנו קבוצת פייסבוק שנקראת סטארטאפ פור סטארטאפ, שם תוכלו למצוא אותנו ואת האורחים שלנו. כל סטארטאפ בצמיחה חווה כאבי גדילה. דברים שעובדים מעולה בצוות של חמישה אנשים לא בהכרח רצים כל כך חלק במחלקה של שלושים איש. בסוף 2019 חווינו את זה בעצמנו, לאחר תקופה של חריקות משמעותיות שהובילה להבנה שצריך לעשות שינוי במבנה הארגוני של צוותי הפיתוח, המוצר והעיצוב בחברה. מטאסק פורסים, צוותי עד הוק, בהם עבדנו עד אז, הוחלפו בדומיינים, צוותים קבועים שמפתחים מומחיות ומבינים לעומק תחום מסוים במוצר. איך יודעים שהגיע הזמן לבצע שינוי במבנה הארגוני של צוות, מחלקה או חברה? איך נפרדים ממבנה קיים ומה השיקולים שעולים בתוך תהליך כזה? ואיך בכלל מבינים מה המבנה האלטרנטיבי הנכון? בפרק השבוע אנחנו מדברים עם דניאל לריה, Head of R&D, ועירן פט, Product Team Lead במאנדי.קום, שמפרטים את תהליך השינוי הארגוני שבוצע. החל משלב זיהוי והגדרת הבעיה, ועד לאופן בו שיקפו את השינוי לכלל החברה. דניאל ועירן משתפים במחירים וברווחים של כל אחת מצורות העבודה, בחששות שליוו את התהליך ובשאלות שצריך לשאול את עצמנו כשמרגישים שהגיע הזמן לשינוי. כל זאת ועוד, נשוחח היום עם דניאל לריה, שהוא Head of R&D במאנדי, ועירן פט, Product Lead בחברה. היי עירן. היי ליאור. היי דניאל. היי ליאור. טוב, הפט אז ככה, הפט שהוא עירן שהוא הפט, תסביר לנו לפני שנתחיל להיכנס ללמה מבנה, איך מבנה, מה זה דומייני, מה זה טסק פורסים, ממה עברנו למה. מגניב. אז במשך הרבה מאוד זמן היינו במודל של טסק פורסים, כמו ש רת. בגדול טסק פורס הוא מודל אופורטוניסטי, בוא נקרא לו. אז מזהים איזושהי בעיה בעולם, קם צוות יהודי לפתור את הבעיה הזאת, יש לו מטרה מאוד ברורה, KPI מאוד ברור, הוא מדלוור את המקסימום אימפקט, ובעיקרון הוא מתפרק לאחר מכן, זה גוף שהוא זמני ביסוד שלו, מה שמאפשר לנו מאוד מהר לבנות כאלה, להשיג מטרות, לפרק, להשיג מטרות אחרות וכן הל . אחלה. דומיינים? דומיינים, להבדיל מטסק פורס, זה גוף שהוא קבוע, כלומר זה לב הסיפור. אז אם בעצם לקחנו את כל הוגת המוצר נקרא לזה, חילקנו אותה לחתיכות בגדלים בגדול שווים, וכל חתיכה כזאת היא דומיין, כלומר דומיין הוא בעצם אחר חלק במוצר, כל חלק הזה הוא מאוד גדול, בסדר? כלומר דומיין לא ב ת יכול בכל רגע נתון להתעסק בכל הדברים שכונים אצלו, הוא בעצם סוג של מחפש תזדמנויות בתוך אותו דומיין ומפעיל קצת כמו את שיטת הטסק פורסים, כלומר במה מתמקדים עכשיו, מה הניצחון וכן הל . שהיתרון הגדול פה זה שבעצם קבוצת האנשים האלה בתוך הדומיין מכירים את הדומיין לאורך זמן, הם קבועים שם, יכולים לפתח אקספרטיז ועוד דברים שנרחיב עליהם בהמשך. דניאל אתה רוצה לתת דוגמאות? נגיד אם ניקח את עולם הטסק פורסים, אז בפן הפרקטי גם חשוב להגיד שעבדנו בטסק פורסים, אז הייתה איזושהי חלוקה של זמן, זאת אומרת 50% מהזמן האנשים היו עובדים בטסק פורסים כמו שאירן ר על איזשהו KPI, ו50% הם היו עובדים במסגרת אחרת של הצוות האורגני שלהם לפי הדיסציפלינה, ואז לדוגמה הטסק פורס שהיה, אם ניקח אחד מהטסק פורסים ב ת אני חושב, אחד מהראשונים, נגיד טסק פורס שעבד בזמנו על Batch Actions, שזה היכולת שלנו במוצר, בבורד שלנו שזה הטבלה הראשית, לסמן כמה אייטמים בעצם ולעשות פעולה על כולם בבת אחת. אז בזמנו נגיד הטסק פורס הזה היה מורכב מארנון שהוא היה המפתח באותו זמן, והפגני שהוא מעצב, והם בעצם 50% מהזמן שלהם עובדים ביחד כדי להשיג את המטרה של בעצם לממש את הדבר הזה שנקרא Batch Actions, ולאפשר פעולות על מספר אייטמים בבת אחת. ואם ניקח דוגמה היום לדומיין, אז נגיד ניקח דומיין קלאסי, יש לנו דומיין שנקרא Board Score, שזה בעצם דומיין שאחראי על החלק כזה במוצר שהוא הבורדים בעצם, והוא אחראי עליו מקצה לקצה היום. אז ההזדמנויות שם מתחלפות כל הזמן, כל קיוא יש הזדמנויות אחרות תחת העולם תוכן הזה של הבורדים בתוך העולם תוכן, ובמקביל הוא גם אחראי לכל אותם דברים שבעבר היו ב-50% האחרים. שזה גם איזושהי נקודת מפתח מאוד מאוד גדולה, נגיד הוא אחראי על ה-Quality בבורדים, הוא אחראי על ה-Performance בבורדים, הוא אחראי על ה-Security בבורדים, הוא אחראי על ה-Craftmanship, זאת אומרת על הרמה שבה המוצר בעצם נמצא, ובעצם יש לו אחראיות הוליסטית על כל האספקטים. כי במבנה של Task Forces בעצם מי אחראי על ה-Quality לצורך העניין? אז במבנה של Task Forces בזמנו…
הדברים הספציפיים שפיתחנו באותו רגע, נגיד אם נחזור לדוגמה של ה-back actions, אז זה בעצם אנשים שעובדים על ה-back actions, אבל לכל הדברים שהם כבר פותחו ולכל המערכת ולכל האספקטים, בעצם הייתה אחריות ריכוזית, זאת אומרת הסתכלנו על זה ברמה של כל הפיתוח, ואת החמישים אחוז הנותרים, בין אם זה היה בהתחלה בצוות אחד ואז ביותר מצוות אחד, היינו מנהלים כ-backlogים נפרדים, זאת אומרת היה backlog אחד של quality, היה backlog אחד של performance, היה backlog של כל נושא רוחבי שרצינו, ובחמישים אחוז היינו מושכים מאותם backlogים, ואנשים היו עושים את המשימות האלה דרך שם. כן, אולי שווה להרחיב להגיד, בסוף מה זה חמישים חמישים, חמישים אחוז זה אותם task forces, זה בעצם מה שקוראים להם product increments, אנחנו רוצים להתקדם בכל מיני נקודות, אבל בוא נחשוב רגע על מה זה מוצר, אז יש התקדמויות מוצריות, נכון? פיצ'רים חדשים ווואטאבר, אבל יש הרבה דברים שעוטפים את זה, נכון? אם זה performance ואינפרה וסיקיוריטי ועוד מלא מלא דברים שאפשר להרחיב עליהם מלא, ועוד דבר יש בעצם כל מה שtask forces אחרים עשו, over time הם עברו לדברים אחרים, והפיצ'רים האלה נשארו בלי עם ואבא, נכון? עכשיו, זה תוכנה, יש בה בגים, יש בשיפורים, יש בדרישות, מישהו צריך לטפל בזה. אז בעצם אפשר להגיד שהחמישים אחוז או חמישים חמישים על התקדמות מוצרית בדברים חדשים, וחמישים אחוז ניהול של כל השאר. אחלה. תכף כמובן ניכנס להבין יותר טוב עד מתי זה עבד, מתי זה התחיל להישבר, מה נשבר. שנייה לפני שנצלול ככה להבין את האתגר ואיפה הבנו שצריך להשתנות. דניאל, אם אתה יכול טיפה להרחיב על המספרים ב ת, הטספורס הראשון שלנו היה ב-2017, תחילת 2017, אני חושב שקראנו לזה פעם ראשונה טספורס, ובעצם באותה תקופה היינו סדר גודל של עשרה מפתחים, פרודקט היה רק את שירלי בזמנו, ומבחינת מעצבים סדר גודל של שלושה מעצבים בחברה. כשהתחלנו לחשוב על השינוי, עד שהתחלנו לחשוב על השינוי היה הרבה גלגולים של הדבר הזה, אבל סביב אותה מהות של הטספורסים, וב-2019 התחלנו לחשוב סדר גודל של אפריל, התחלנו להבין שאנחנו רוצים לעשות איזשהו שינוי לכיוון הזה. באותה תקופה היינו 35 מפתחים, בערך שבעה אנשי פרודקט, וסדר גודל של 15 מעצבים בחברה, ואת השינוי בפועל עשינו בסוף 19, אוקטובר או נובמבר, ובעצם היינו אז 45 מפתחים, 11 אנשי פרודקט, 25 מעצבים. עכשיו המספרים הם רפלי, כן? אני לא זוכר בדיוק, אבל זה הסדר גודל, כלומר אפשר להבין את הסדר הגודל מזה. אז אוקיי, אז הבנו מאיפה היינו ולאן הגענו, עכשיו בוא נבין מה קרה ב צע ומה גרם לזה שהבנו שצריך שינוי. אז קודם כל אני חושב שזה נורא חשוב להבין שבסוף הסטרקצ'ר והמבנה שבו עובדים, הוא קצת מכתיב את ה-day to day, נכון? קצת אם אני אתן אנלוגיה יותר קלה, אם יש לך מחלקה מסוג מסוים, אז עושים את הדבר הזה, ואם אין לך אותה, אז לא עושים את זה. אז גם בעבודה שוטפת זה היה ככה. אז כשדיברנו קודם בעצם על החמישים חמישים, נכון? חמישים אחוז מהזמן עובדים בטאסקפולס התקדמויות וחמישים אחוז מטפלים בכל השאר. זאת הייתה המציאות בשושליים? זאת הייתה המציאות, וזה היה נורא קשה, כי החמישים אחוז האלה הם היו שונים אצל כל בן אדם, בסדר? נגיד היו מפתחים מכמה צוותים שונים שעובדים על כמה דברים, כל אחד מהם בעצם ניהל את החמישים שלו מתי שבא לו, ואז אתה בא לעבוד עם הבן אדם הזה ואומר לך, לא, לא, לא, עכשיו אני בחמישים השניים. זה היה פרסונלי? היה פרסונלי, כל אחד קובעת עצמנו את החמישים, הכל בקטע טוב. מבחינת לוחות זמנים או מבחינת כמות עבודה? גם כמות עבודה וגם החלוקה של הפלוחות זמנים. ואז יכול להיות שאתה במאניתיים של איזה משהו, ואתה בא לאחד המפתחים שאתה עובד איתם ואומר לו, יאללה בוא נרביץ את זה, לא, אבל הוא עכשיו בחמישים הנוספים. עכשיו זה חוויה נורא מתסכלת מצד אחד לי כפרודקט בחברה. שאני גם לא אותו בן אדם זה חוויה מתסכלת, כי גם הוא רוצה להצליח ולתת בראש ולהתקדם בצוות, אבל יש לו עוד דברים שהוא עושה. רגע לפני שאתה ממשיך, אבל דניאל, מתי למבנה הזקן היה, מתי הוא עשה שכל? אז אני חושב ש… תגן על התזה. לא, א', אין לי איזה בה מיוחדת למבנה חד ספציפי, אבל אני כן חושב שא', היינו הרבה יותר קטנים, ואני חושב שבאותה תקופה היינו בחוסר שיווי משקל גם בין פיתוח לפרודקט, ואז בעצם מה שנוצר מצב זה שהיה כל הזמן סטרוויישן בנושא הזה של הפרודקט, ואז היה המון המון משימות שגם כשעובדות על המוצר הן היו בלי פרודקט. אז היה לזה הרבה פחות משמעות כשאת חושבת על זה ככה, כי בעצם כל האנשים שעובדים, עובדים ביחד. בסדר? אז מה שכן הרווחנו מזה זה המון המון דינמיות, יכולת לשנות דברים מאוד מאוד מהר. אנשים הרגישו שהם מאוד מאוד שולטים בזמן שלהם, ושיש להם המון המון אוטונומיה על הזמן שלהם, והם יכולים לרוץ ולעשות דברים. bottom line, זה עבד מאוד מאוד טוב, כי היה…
המון הומוגניות בכוח, כאילו, שעבד על הדברים, ואני חושב שככל שהכוח הופך להיות יותר הטרוגני וגם שקול, אז נכנסנו בעצם למצב שה-50-50 יצר המון המון תאומים שאנחנו מלכתחילה לא רצינו להתעסק עם התאומים האלה. אוקיי, אז מה היה השינוי מה-50-50, לאן עברנו? אז בעצם מ-50-50 עברנו בעצם ל-7-3, כלומר שבעה ימים בעצם בתוך הטאסק פורס, עושים פרודקט אינקרימנט ומתקדמים, ושלושה ימים בעצם באותו מודל של כל המסביבים, בסדר? הפרפורמנט והכל, דברים חשובים. וזה מאוד שיפר את המצב, כי קודם כל עכשיו ידעת אני כפרודקט שיש לי שבעה ימים מלאים עם הצוות שלי לעבוד איתם, זה לא כל אחד הולך מתי שבא לו. אבל מצד שני, פתאום אתה מתחיל להגיד רגע רגע, אתה עובד, אתה מתקדם, אתם במני טיימס של משהו, ואז פתאום מגיע השלוש, ואתה אומר, זה לא חשוב במרכאות כמו מה שאני רו לנגד עיניי, בוא נטרוף את זה. ממש כמו ש רת שם, יבנה מכתיב את החשיבות, אז כשיש לך משהו שהוא 70% מהזמן ומשהו שהוא 30% מהזמן, והוא נכפה עליך בלי קשר לסדרי עדיפויות. ועכשיו אתה גם שואל איך מתעדפים, נכון? כלומר פתאום יש שני קונטיינרים, יש את קונטיינר השבע ואת קונטיינר השלוש, ואנחנו עושים תעדוף פנימי בתוך כל קונטיינר. אבל מה אם אני מחזיק ביד של השבע במרכאות את הדבר הכי גדול בעולם? הוא לא מתועדף בכלל בתוך השלוש. ואז הדבר הזה חד הוא יוצר שוב את אותו תסכולים מפעם, נכון? כי כולם רוצים להתקדם וכולם גם רוצים לשפר את הפרפורמנס, ונוצר פה איזה מין מבנה שהוא יוצר פריקשן אינהרנטי. זה כאילו זה מצחיק, נכון? תמיד ה ת היא בפרטים הקטנים, כי נגיד כבר אפשר להסתדר עם השבע שלוש, אנחנו מכירים את החיים, משימה שהתחילה בשלוש יכולה לקחת ארבע. ואז אני מורד שערות מהראש, נכון? אני חייב את היום הזה, אנחנו חייבים לנצח. והשטות הזאת, נכון? משימה, דרך אגב, גם בכיוון ההפוך. בדיוק, רציתי להגיד גם בכיוון ההפוך. גם אנחנו נגסנו מהשלוש, הכל בסדר. לא, וגם בכיוון ההפוך של טוב, אני לא אכנס לאיזושהי משימה, כי אני רו מלכתחילה שתיקח לי שש ולא שלוש. לא, זה אין אצלנו. אני כן יכול להגיד גם עוד משהו שאפשר אפילו לראות אותו בשיחה פה בינינו, שב ת היו פה שני וקטורים שכאילו התחרו, שזה לנצח בשבע ולנצח בשלוש, שהמציאות היא לא כזאת. כאילו המציאות היא פשוט, יש לך מוצר שאתה מפתח ושאתה רוצה לראות שהוא טיפ טופ all the way. וזה גם לא נכון לכתיב בצורה גורפת עבור כל המ צים שלנו כמה אנחנו צריכים להשקיע בכל דבר, כי ב ת יש דברים מסוימים, נגיד ניקח אזורים מסוימים במוצר שהם במצב ממש ממש לא טוב. היה לנו פה ב ת קשה מאוד לייצר שיחה שבה מי שרוצה לקדם איזשהו פיצ'ר אינקרמנט בשבע, מבין את הדבר הזה של הקואליטי, וגם להפך. ואני חושב שזה מה שזה יצר, זה יצר בעצם ב ת שני אינטרסים שהמציאות היא לא כזאת קודם כל. אני חושב שגם בהקשר הזה חשוב מאוד להגיד, יש פה איזה פיטפול שאני חושב שהוא היה סופר סופר משמעותי, והוא גם סביב מתי לעבור בדיוק לדבר כזה. כשהיינו בעיקר פיתוח, היה מאוד ברור מה זה הצוות. מי נמצא בדיילי? מי ברטרו? כאילו פתאום מצטרפים עוד אנשים וכולי. ושמנו לב שבשבע שלוש בעצם יש לי ספליט פרסונליטי כזה, כי בשבע אני בצוות עם המעצב ועם האיש פרודקט וכולי, ובשלוש אני רק פיתוח. ואז כאילו השאלה היא ב ת מה הצוות? איפה עושים רטרוספקטיב? איפה כאילו מתקיים השיח על הדברים של התנהלות של צוות וכולי? אז אני חושב שגם בהקשר הזה זה משמעותי. לא צריך פרודקט בשלוש? לא צריך פרודקט בכל מה שקשור לאינפרו וקואליטי? וואו וואו, זה היה אחת מהשיחות אני חושב הכי חמות, נכון? כלומר בסוף רתי את זה בהתחלה, אנחנו כולם בחברה מבינים את החשיבות של קואליטי ושל פרפורמנס, זה חלקים אינהרנטיים מהמוצר. אז איך מודדים אותם? איך מתעדפים אותם? איך אומרים מה חשוב ממה? אנחנו שאלנו את אותה שאלה, אם לא צריך שם הפרודקט, מי עושה את זה בכלל? ובאותה נשימה גם אני חושב על החברה מהR&D שצריכים בעצם ברגע אחד לעשות סוויץ', להרוג את השבע במרכאות בראש, להסתכל על איזה בקלוג מלא דברים בכל הכיוונים, ומהרגע לרגע להתחיל לראות איך אוכלים אותו בכלל, ומה יותר חשוב ממה, והדבר הזה פשוט יצר פריקשן אינסופי לכולם. אני לא מ ינה שאני ב את הדימוי הצבאי כן בחדר, אבל זה קצת נשמע כאילו יש לך את התפקיד בצבא, ואז יש לך את המשמרות, נכון? את התורנות מטבח, את ההבטאשים, את כל הדברים האלה שאתה עושה אותם כי אתה חייל, לא כי זה התפקיד שלך. וככה אתה מצייר את השלוש פה. כאילו בקלוג, אפילו השפה שלכם… אז הנקודה שזה לא בדיוק ככה, כי כן בשלוש היה נגיד אינקרמנטס קטנים במוצר, ודברים שאנחנו קוראים להם צ'יזים, כלומר איזה שהם שיפורים במוצר שהופכים את הדברים ליותר טובים. הנקודה היא כן, אני יכול להגיד מהצד שלי, בוא נגיד את הפרוסטריישן שאני הייתי בו, כשעברנו בטאספורסים, אז היה המון המון דברים שנועלו בצורה סנטרליז. נגיד מה עושים…
תשוח עכשיו שהוא לא קשור לשום דבר, בסדר? נגיד סתם דוגמה, אנחנו רוצים לשפר את ה-SEO בכלל ב-Website, ב-Homepage שלנו של monday.com, לא בפלטפורמה, לא קשור לשום פיצ'ר, לא כלום. עכשיו שהיינו קטנים ובניהול Centralized, אז מאוד מאוד קל לגעת בכל דבר, מאוד מאוד קל לתת את המקש שאתה צריך, לא יותר ולא פחות, ועל ידי זה אתה משיג אפישנסים טורף. זאת אומרת, היה לנו ב ת סדר גודל של שנה וחצי שהספקנו דברים, אנשים לא היו מ ינים בכלל שאנחנו ככוח כזה קטן יכולים לעשות כזה דבר. וכשגדלנו והיינו עם ה-73 וזה כאילו כבר לא אתים, אז גם היה כל הזמן את הקטע הזה שבאים כל מיני דברים מכל מיני מקומות שהם לא סביב הדברים המרכזיים שאנחנו עובדים עליהם כרגע, ולי הייתה הרגשה שאני מאוד צריך להכיל את הכל בראש. זאת אומרת, לתכנן את השלושה ימים, זה היה משימה שנגיד הרשת צוותים היו לוקחים וזה היה טירוף, כי זה היה ב ת קשה, כי זה היה לחפות פתאום בשלושה ימים על כל הדברים שבשבעה ימים לא נהגו בהם. ואני חושב שפה היה ב ת מכל צד שאתה לא מסתכל על זה, הרגשנו שזה פשוט לא עובד וזה לא משרת לנו את המטרות יותר כמו שהרגשנו בעבר. כאילו לפני זה, אם נחזור לפרק על האימפקט שלפני איזה שנתיים אני חושב, אז שם כאילו עדיין במבנה שהטס פורסים, והרגשנו שזה היה דבר שפיצחנו את האטום, ופה פשוט הבנו פתאום שזה לא עובד. כי גם אם תחשבו על טס פורס, זה כאילו הארגון הכי סקסי שיכול להיות, נכון? זה בעיה. אתה פטור מכל צרות העולם, ואתה הולך לגעת חירורגית במקום כאילו הכי טוב שיש במוצר. אז כל דבר הוא כאילו מחביר ליד זה, אבל ברור שטס פורס לא יכול להתקיים בלי כל השאר, נכון? זה כאילו איזה מין מתח, נורא קשה להכיל אותו. ויותר מזה אני גם חושב שעוד באש נוצרה. אני יכול להגיד מהצד שלי כפרודקט, זה באש של אונרשיפ, נכון? עכשיו… תסביר. בואו נחשוב על זה. אם בשלוש יש קבוצת אנשים, שאני לא יודע מי הם, שמטפלים בכל הבאגים וכל השיט והאדמה החרוכה שישרנו אחרינו, שמע לי סידור לא רע. כלומר, אני הייתי שמח אם היום כל סופה שהוא מגיע עם כל מיני אנשים שאני לא יודע מי הם במרכאות. מנקים לך את הבית. מנקים אית כל הדברים שעשינו לא טוב. אכלו דק ככה בדלתות. כן, ואני יכול להגיע בראשון בבוקר ולטעוף את העולמות, נכון? אז כאילו, אוקיי. אז מה זה אומר? עכשיו, מה זה אומר על ההשקעה בקוליטי ובקרפטמנשי וכן, עכשיו, שום דבר פה לא נעשה בכוונה רעה, כן? זה קצת חוזר למנטר שלנו שהמבנה מכתיב את המציאות, נכון? אני יכול לייצר יותר דליברי אם אני לא צריך לטפור all the way את כל הדברים, כי אותם אנשים, אנשי השלוש, אני לא יודע מי הם, הם יעשו את זה. אגב, אני חושבת שהעיקרון הזה ברור גם אם אתה מסתכל על טספורס מלמעלה ולא רק על החלוקה ל-50-50 או ל-73, כי טספורס במהותו זה צוות זמני, כמו ש רת. אז נגיד שאתה עכשיו עובד על אזור חדש במוצר, נגיד נקרא לו אוטומציות ואינטגרציות, למשל. למשל. למשל. אתה רץ על זה, זמן שהגדרנו מראש, 12 שבועות, נגיד. אחר כך אתה נותן את זה למישהו אחר. הגעת להצלחה, לא הגעת לניצחון, הגעת לניצחון מסוים, אתה רו באופק עוד ניצחונות, אבל הם לא שלך. לא, גם יותר מזה, בואי נחשוב. אני שואלת, כן? כן, לא. זה נגיד דוגמה נהדרת. לא, לא, תסבירו. האוטומציות, למשל, בסדר? אתה מתחיל אותם. אתה מתחיל אותם. אני מתחיל אותם. אתה לא יודע אם זה יהיה, כלומר, יש ויז'ן ויש ונה, אבל אף אחד לא ב ת יודע עד שלא יוצאים מחוץ על העולם. וזה מאוד מאוד הצליח, אבל פתאום צריך תשתית, למשל, פי אלף רובסטית למשהו שמצליח בכזה קנה מידה. עכשיו, אם הדבר הזה קיים חצי שנה, ולקח חצי שנה להגיע למקום סופר מוצלח, ועכשיו צריך תשתית שמתאימה לגדול עם זה שנתיים. מי עושה את זה? כלומר, זה פשוט לא מתאים אפילו יותר. כן, בצורה יותר כללית, כאילו, השיטה של הטסט פורסים היא לא… כל המ צים שהם לונג טרם, הם צריכים להיות מחוץ לטסט פורס. זאת אומרת, הם צריכים שמישהו אחר יהיה המאסטר מיינד בגדול של התוכנית הזאת, ויסתכל על הדברים בצורה הוליסטית, בעוד שבעולם של הדומיינים זה אחרת, כל דומיין הוא אחראי לכל האספקטים. אני יכול רק להגיד על הנושא הזה של ה-ownership, שגם זה היה אחד הדברים שחשוב להגיד, זה נשמע כזה לכולם פה, היה את ה-best intentions, וזה היה מדהים פשוט לראות שאנחנו כולנו ביחד מנסים למצוא את הדרך שהדבר הזה יקרה, והדבר הזה יהיה יותר טוב. והמון המון דברים ותסכולים, אני חושב שהם נבעו ב ת, זה קצת ר כאילו אלף שהמבנה מכתיב את היום-יום. אני נגיד הרגשתי שאחד ה-learnings הכי משמעותיים שלי, זה שהיה המון המון דברים שאני הרגשתי שמחזיקים אותם בשלוש במרכאות, ואנשים אחרים אפילו לא מודעים אליהם. וזה לא שהם לא רוצים, וזה לא שהם לא חושבים על זה, וזה לא שהעולם שלהם הוא מצומצם רק לאינקרמנטס במוצר. וב ת כשהתחלנו להסתכל על הדברים בצורה יותר אוליסטית, זה היה לנו תהליך של להגיד מה זה להסתכל על פרפורמנס, מה זה להסתכל על קוליטי.
איך מתמודדים עם interruptions, כאילו שהם לא קשורים ומי עושה אותם וכולי? וזה היה תהליך נורא מעניין. אני זוכר, סתם ככה בהקשר של האונרשיפ, עשינו, תכף נספר איך היה תהליך, אבל באחד השיחות שדיברנו על ה-struktur הזה, אז פתאום התחלנו, אני זוכר, התחלנו להציף את כל הדברים שצריך לעשות ולמפות אותם, ופתאום אחד מאנשי פרודקט הזה תופס את הראש ואומר, רגע, איך נעשה את כל זה? וזה היה רגע נהדר, כי זה היה רגע פתאום שהבנתי, שזה שהחזקנו את זה, בעצם מנענו מאנשים אחרים להבין, ומנענו מאנשים אחרים לקחת על זה אונרשיפ, וזה לדעתי נקודה מאוד מאוד משמעותית. כמו כל דבר בחברה, לא, כלומר אם בן אדם לא יודע ולא חשפים אותו, לא בקטע רע, זה לא עניין של מידה, הוא כך יצא, אז אי אפשר לצפות מאותו בן אדם לעשות משהו about it, כאילו זהו. כן, רק חשוב לי פה כדי להזן את זה קצת, כי אנחנו כאילו, בגלל שאנחנו היום בדומיינים, וכאילו הגודל שלנו זה ברור שזה מתאים פי מיליון, וזה, אתם יודעים, בנקודה שהגענו לה, לנקודת רתיחה, זה כבר היה ממש ממש הרגיש לא טוב, אבל לפני זה, אם נסתכל על טספורסים במבנה שהוא יותר קטן, ב ת כאילו הכמו דברים שהתמודדנו איתם היא עשרות מונים, זאת אומרת, אני יכול להגיד שגם בעבר היה לנו ניסיונות קודמים בכל מיני חלקים של ה-R&D, לקחת איזשהו אזור ולפרק אותו לדומייני מה שנקרא, אבל זה היה בן אדם אחד בכל דומיין או משהו כזה, כי היינו לא רק קטנים, וזה פשוט קרס, כי אתה היית צריך את הדינמיות ואתה היית צריך את המון דברים, אז כאילו יש פה את הנקודה של הקו פרשת מים, שהוא ב ת סביב גודל וסביב הומוגניות של הכוח, כאילו אם זה פרודקט דב דיזיין, רק דב, רק זה וכולי. וגם סביב מה שנר לי אף נגע בו קודם, סביב הבשלות והמידה שהמוצר כבר קיים, כן? כן, והקומפלקסיטי. או הקומפלקסיטי בדיוק. כן, כמה קומפלקסיטי וכמה אתה מרגיש גם שאתה צריך ב ת פרספקטיבה שהיא long term. ואנחנו אוהבים להגיד שזה כמו הרול אוף סתם שלנו כזה, למתי להקים צוות חדש או למתי להקים דומיין חדש, ואנחנו, זה כמו כזה פרקטל, שזו צורה שאתה עושה לה זום ואתה רו את אותה צורה בדיוק. כלומר, אנחנו רוצים, לדעתי הנקודה הטובה לעבור, והנקודה הטובה להקים דומיינים, זה ברגע שאתה מרגיש שברגע שפיצלת את זה לדומיין, עדיין הדומיין הוא עולם ומלואו. בסדר? ואני יכול להגיד שהיינו קטנים, לא הרגשנו ככה. רנו, אם אתה תתעסק רק בזה, זה נורא מתומצם, זה נורא קטן, זה לא מספיק, כאילו יש לך עוד מלא דברים שאתה יכול לעשות. היום בדומיינים זה עולם. יש לזה את הקואלטי של זה, ויש לזה את הפרפורמנס, ויש לזה את הלונג טרם פלנינג של זה, ויש את ההזדמנויות הארוכות וכו' וכו'. אני גם חושב שיש עוד נקודה שאולי נשמעת קצת טריוויאלית, אבל לא הזכרנו אותה. היו פשוט אזורים שלא רצינו להפסיק לעבוד עליהם, נכון? כלומר, דיברנו על דינמיות וכן הל אבל יכול להיות משהו, או שהוא נורא בקור של המוצר, כמו הבורדים שלנו, או מ ץ שמאוד מאוד הצליח, ואם המבנה מחייב אותנו כל חצי שנה לפרק את הצוות הזה בשביל לדון צוות אחר, אז בהגדרה אנחנו לא יכולים להמשיך להתקדם שם, אבל זה משהו או נורא מוצלח או נורא בקור, אנחנו רוצים להמשיך לעבוד עליו, והמבנה לא מאפשר לנו בכלל, זה אסור לנו לפי חוקי הפורמט. כן, אפילו ניקח את זה צעד אחד יותר קדימה, כלומר היה טספורסים שהמשיכו כמה מחזורים, אבל יש קטע כזה של תחרות על מה שנקרא על משאבים, שתמיד דברים שהם חדשים ודברים שהם הזדמנויות חדשות, הם נוטים לזה שלגנוב את כל האטנשן, והרבה פעמים הבנו שבשלב מסוים של החברה יש דברים מסוימים שאנחנו רוצים להשקיע בהם, להמשיך להשקיע בהם, לא משנה עכשיו מה יש עוד על השולחן, ודרך מאוד טובה זה להגיד זה ספרייט אפורט, עולם בפני עצמו והוא לא חלק מהפול הזה במשחק. השאלה היא איפה בן אדם כשהוא מגיע למבנה הזה של הטספורס הנשבר, בסדר? אני לא מדברת על הטספורס האידיאלי, אבל בימים הלא טובים שלו, כשאני קמה בבוקר בתור פרודקט או R&D או דיבלופר פה, איפה אני מתיישבת? על מי אני מסתכלת סביבי? האם יש כיסאות מוזיקליים מסביבי? זה מרגיש נורא לא יציב, אוקיי? ברמה הפרסונלית עכשיו, ברמת הבן אדם. התשובה היא תלוי באיזה יום קמת. זה מאוד מאוד דינמי, ואני חושב שזה חלק מה מה שרצינו להוביל. אחת הדברים שגרמו לנו להבין שזה שבור בעצם, זה שלא היה ברור מי הצוות שלי, לא היה ברור עם מי אני נמצא ביום יום, לא היה ברור מי האנשים, שאותם אני מגדיר כשותפים ליום יום שלי, עם מי אני מתיישב בבוקר, עם מי אני הולך לאכול, כל הדברים האלה. ובתפיסה שלנו בחברה, אנחנו רואים את זה שזה צריך להיות כל האנשים שעובדים ביחד, זאת אומרת פרודקט דב דיזיין, זה צריך להיות הצוות האורגני ביחד, ולכן גם עוד דבר שב ת גרם לנו מאוד מאוד לזוז לכיוון הזה של דומיינים, ושהדומיין יהיה הטרוגני באנשים שבונים אותו, זה שרצינו לשים את הפוקוס שם. זאת אומרת רצינו שהיום יום של האנשים יהיה ביחד, שזה היחידה שנגדיר אותה כצוות, ולא צוות שמוגדר על ידי דיסציפלינות עם ממשקי תקשורת בין הדיסציפלינות השונות.אגב…
זה מחשבה בא בכיוון הזה, כשיש מעט מאוד אנשים ב ת ואז הטסק פורסים בנויים ממעט אנשים קבועים, כולם דוגמים את כולם ויש כבר איזה ש רתי חצי עם עבודה עם כולם, אני מדמיין את עכשיו שלושים איש מנסים ללמוד כל פעם לעבוד עם עשרה פרודקטים, רק תהליך הלמידה וההיכרות של איך עובדים נכון כצוות לוקח המון משאבים. לגמרי, לגמרי, זה מאוד קשה, זה מאוד קשה בגדלים כאלה ואתה מאבד את היתרון של זה, שזה לעבוד עם הרבה אנשים, להכניס מוח חדש לאתגרים קיימים שמאוד נהננו ממנו בטסק פורסים, אבל כשזה גדול זה נהיה מאוד קשה והדינמיקה של העבודה עד שאתה לומד אותה אתה כבר מתפרק והולך לדבר הבא וב ת אני חושב שבנקודה שהבנו שזה לא מתאים זה כבר היה ממש ממש ממש לא מתאים בוא נגיד ככה. שוב אנחנו משתפים את זה גם כדי ב ת ככה הזמנה לכל אחד שיושב ומקשיב ולהסתכל פנימה ולהגיד וואו הדינמיות הזאת מלהיבה אותי וזה נשמע לי בול מה שאני צריך כרגע וזה כל מה שהיה חסר לי אוי ואבוי איזה כאב ראש ואולי וגם לשאול פנימה מה הסימנים ביום יום אני חושבת שזה הקיוא הכי טוב פה מה הסימנים ביום יום שזה פשוט כבר לא מתאים ואנחנו מאלצים על עצמנו מודל שכבר מזמן לא משרת אותנו. כאילו לא בקטע רע זה שאנחנו מדברים על זה עכשיו בכזאת בהירות וצחוק אנחנו לא ראינו את זה ככה אז כלומר ראינו הרבה דברים טובים בטסק פורסים היה הרבה חשש להיפרד מהטסק פורסים זה לא היה היום שאנחנו בדומיינים אנחנו מדברים נורא באיזה נחרצות על מה יגרו בטסק פורסים יש סיבה שלקחנו כמה חודשים טובים לנהל את התהליך הזה נכון לא ידענו מה המודל החדש היום אנחנו עושים את זה כזה השוואתי נכון החדש מול הישן בזמנו לא ידענו מה החדש ידענו שהטסק פורסים יש להם חסרונות אבל יש להם גם המון המון יתרונות מה יקרה כאילו בשיטה החדשה אז זה קצת כזה חוכמה של עכשיו ואני מניח שנקליט את הפרק הזה בעוד שנה ונצחק על הדומיינים. אז איך ב ת בוא ניקח את זה לשאלה דניאל איך ב ת אתה מסתכל כי נכון טסק פורסים הביאו אותנו זאת אומרת היו להם ניצחונות ברורים כן זה לא מבנה רנדומלי לא דבקנו בו כי לא היו אלטרנטיבות ופעלנו בוואקום ראינו איך זה מוביל אותנו למקומות טובים איך אתה משחרר מזה בלי לדעת בוודאות שהמבנה הבא כאילו ברור שכשעושים משהו חדש יש ריסק אבל הריסק פה הוא מאוד גדול. אני יכול לגשת לזה אולי מכיוון של הפחדים שהיה לנו של מה פחדנו לאבד קצת וא. פחדנו פתאום שאנשים יסרטטו קווים מאוד ברורים בין הדומיינים ואז כאילו משהו שלא יהיה סופר וולד דיפיינד ויגידו זה לא שלי זה כן שלי ואחד מהדברים שאנחנו נורא בנו שכולם הבעיה כל בעיה היא בעיה של כולם. המשרד ממשלתי זה באגף. זה בבורדס קורד תדבר איתם. תדבר איתם וכולי פחדנו מאוד לייצר יצרת אנשים כי מאוד חשוב לנו שאנשים יראו את כל העולם ופחדנו מאוד מחוסר סינרגיה בין מ צים כי פתאום איך אתה יש לך עכשיו עשרה דומיינים נגיד לצורך העניין איך הם עובדים על פרויקטים שהם קרוס דומיין. א. לנו הרבה שאלות לגבי המיקום מה זה לידרשיפ של דומיין. מה הכוונה. נגיד היה לנו מאוד רן דיבר על זה קודם היה לנו התלבטות מאוד גדולה לגבי המקום של הראש צוות כי פתאום אם אתה אומר ראש צוות הוא חד חד הרכי לדומיין לפני זה ראש צוות היה מנהל אופרציה הרבה יותר גדולה אז רגע שניה אז מה זה אומר עכשיו שאנחנו צריכים פי שניים אנשים כדי לנהל בדיוק את אותו כמות של קונטנט וכולי הרי זה לא הגיוני וגם הדברים האלה בסופו של דבר הם כולם סביב אותו פחד שאולי דומיין זה קצת לצמצם את האנשים ולהגיד להם תקשיבו זה העולם שלכם תתעסקו בעולם שלכם הביגר פיקצ'ר זה כאילו בדומיין של מישהו אחר. בכלל גם אם כדי לנסות מבנה חדש אתה אומר שבהגדרה צריך לגייס עכשיו פי שניים אנשים זה נשמע ריסקי ולא הכיוון. כן וזה גם לא מה שעשינו רצינו לפתור את זה ורצינו בעצם להגיע למצב שאנחנו בוא נגיד ככה אנחנו עם כל הזה שיש לנו מבנה מאוד מאוד מוגדרים אנחנו מסתכלים על מבנה כל גלגלי עזר וכל המטרה שלו היא לעזור לנו זאת אומרת שברגע שהוא מפריע לנו אז אנחנו מנסים לשנות אותו ויש לנו גם המון דברים שהם קאסטומייזד בדומיינים גם בדומיינים לדוגמה עכשיו יש לנו מקרים מסוימים שראש צוות שהוא ראש צוות בוא נגיד מאוד מנוסה ובכיר הוא מצליח להיות לידרשיפ של שני דומיינים בסדר ואנחנו מרגישים ששם נגיד הקאסטומיזציה היא מאוד מאוד נכונה אז גם הכללים האלה גם בתוך המבנה שהדומיינים נגיד היום איך שהמובייל עובד שמובייל זה פלטפורמה שלמה בפני עצמה לעומת איך עובד דומיין שחיים דומיינים אחרים בפרוקסימיטי ועובדים על אזורים יחסית קרובים זה שונה לגמרי אז אני חושב שבבטן ליין אין מה לפחד כאילו אני הדבר שהכי מפחידתי זה לא להשתנות זאת אומרת אני מאוד מאוד מפחד מזה שנהיה בסטגנציה ואין מה לפחד מזה אני יכול לשתף שלי הפחד אדיר שהחזקתי מאוד חזק ובדיעבד הייתי צריך לשחרר אותו הרבה יותר מוקדם. בוא נשמע בוא נשמע. ש רתי רגע זה ב ת קומפלקס ברמה יש פה קונטקסט מטורף כדי עכשיו להחליט האם הסקיוריטי אישו הזה יותר חשוב מהבאג הזה ויש פה קונטקסט מטורף שצריך לתת כלים כלפיו וצריך פתאום שנגיד בישיבות סינק שאנחנו עושים שעד אותו רגע רק דיברו על מה הדברים.
החדשים שעשינו ואיך הם משפיעים על העולם וכולי פתאום רגע צריך לדבר על מה שאנחנו קוראים לו מדדאיך או מנוע איך אתה יודע שאתה לא רץ מהר מדי ונשרף ואיך אתה מודד quality ואיך אתה מודד craftsmanship ואיך דברים שעד היום נגיד דיברנו על הצ'יזים האלה כן השיפורים הקטנים במוצר אז היה עלינו בורד אחד שכל הצ'יזים היו שם היה פורום של צ'יז שמסתכל על זה מחליט מה צריך לעשות פתאום רגע מה עושים בורד כזה לכל דומיין איך עושים education לחברה בכלל עכשיו מה נהפוך את זה מסובך לכל החברה לדווח על צ'יז כי הם רק רצו להציע שיפור במוצר ואני חושב שאחד הדברים המגניבים בשינוי הזה זה שבעצם לקחנו את העולם כאילו באיזשהו מקום כמו שאירן ר היום דומיין הוא מספיק גדול ויש לו את הדינמיות של התספורסים בתוכו ואני מאוד אוהב את זה שכל דומיין עובד בצורה אחרת ואני מאוד אוהב את זה שב ת אנחנו עושים קסטומיזציה של המבנה שלנו בתוך כל דומיין לגבי המ צים שהדומיין הזה צריך לעשות יחד עם זה שיש לנו איזה רי עם סטנדרטים מסוימים על איך מסתכלים על quality על איך מסתכלים על זה ועדיין אספקטים שאנחנו מסתכלים עליהם ברמה כוללת ואני סתם ככה אגיד עוד דוגמה אחת שהיא מעולם הפיתוח שאני חושב שהיא סופר נגיד אני זוכר שאז ישבה לנו נורא הכבד נגיד יש עכשיו production incident כן רגע זה משנה את כל הon-call כי מה עושים עכשיו הon-call נהיה פי עשר יותר מסובך פעם production incident היה בן אדם אחד on-call הוא היה יודע כמעט הכל לרוץ בכל המקומות במערכת וכולם היו קופצים איתו היום זה תלוי דומיין היום יש דברים מסוימים שהם עדיין ברמה כללית כאילו אם המערכת למטה אז כולם יעזבו מה שהם עושים וילכו על זה אבל יש הרבה דברים שכבר ברמת דומיין דומיין בנה לעצמו את הon-call כל התהליכים שלנו של טיפול בבעיות של לקוחות היו צריכים לעבור שכלולים ואלבורציות כדי שבעצם הם יישארו פשוטים לאנשים בחברה שהם דווחים נגיד את הדברים אבל בפנים יהיה dispatching לדומיינס ונר ששום דבר לא נופל בין הכיסאות ונר שעדיין באיזושהי ראייה הוליסטית הquality של המערכת כמכלול הוא טוב מאוד פחדנו גם לפתח פרודקט בהמשכים כזה זה גם מעלה שאלות נכון נגיד צריך לתת visibility לתוך הquality של הפרודקט אז האם כל דומיין מייצר לעצמו מיני מוצר שמודד את זה האם זה משהו שהחברה במרכאות נותנת לכולם ביחד אותו דבר לכל דבר נכון איך מנהלים בגים האם יש דומיין שאחראי לתת שירותים לכל שאר דומיינים במובן הזה למשל עכשיו איך יכולים להתחיל לדבר פה הרי בסוף הפרוס מורכב עם מיליון דברים נכון דרישות לקוחות דניאל ר בגים quality מרקטינג איך מסנחרנים את הדבר הזה מיליון ואחת דברים וקצת כמו נכון ש רנו שבעצם הסטראקציה מכתיב את הday to day אז הוא גם מכתיב את את נעלים בדבר יותר נקרא לזה הלוגיסטים נכון איזה בורדים יש לנו במנדיה כל מיני נועל גבי מנדיה אז אני לא אגיד איזה כלים מחזיקים כי בעצם רק מקסטים את מנדיה מחדש אז איזה בורדים אנחנו מחזיקים ומה הפלו של המידע בתוך הבורדים וזה מייצר בעצם נועל עבודה חדש לגמרי כלומר זה לא להגיד אופה דומיינים וסיימנו כל השאר עכשיו צריך לעבור אדפטציה לדבר הזה מעולה שזה ב ת מוביל אותי לשאלה הב אם מאוד שטספורסים כמו שתיארתם מאוד בנויים מזדמנויות אז אוקיי צצה הזדמנות נגיד שעשינו לה איזושהי ולידציה שהיא אכן הזדמנות יאללה בונים על זה כוח עבודה זאת אומרת מאוד בוטומאפ נכון פתאום קם דומיין נשמע כמו תהליך שטיפה מה זה טיפה הרבה יותר טופ דאון איך אתה יודע להתחיל דניאל איך אתה חותך את ההוגה אתם כל הזמן אומרים ההוגה גדולה ההוגה גדולה איך מתחילים ואיך לא עושים עכשיו אובר אנליזה אינסופית למבנה הזה ובעצם רק מזה משתתקים כי רק עכשיו אין לנו פה כמות אפשרויות אינסופית של איך לחתוך את זה אז קודם כל מבחינת החלוקה של המוצר אחד העקרונות ש רנו מההתחלה זה שאנחנו לא רוצים להגיע לחלוקה מדויקת זאת אומרת כן חשוב לנו שתהיה חלוקה שהיא מוגדרת אבל עדיין יהיו אזורים מפורים ובהגדרה זה טוב שיש אזורים מפורים ואנחנו סומכים על האנשים שאם יהיה נגיד משהו שהוא נופל בין שני דומיינים נגיד ניקח אצלנו דוגמה יש את הבורד ואותו בורד בדיוק מופיע גם בדשבורדים שזה צוות אחר זה צוות האינסייטס דומיין אחר אז כאילו נגיד יש עכשיו בעיה אז אנחנו מאוד מאוד רצינו להגיע למצב שגם הדומיינים מדברים ביניהם שיש חפיפות ויש חיכוכים אנחנו כן מאוד רצינו שכל דומיין יהיה אוטונומי ועצמאי אבל עדיין יש המון המון פרויקטים שאנחנו רוצים עליהם גם ביחד נגיד היום השבוע רץ פרויקט שאנחנו עושים אותו שארבעה דומיינים מעורבים בו ביחד ואני חושב שזה אחד הדברים אז מוגדר ולא מדויק זה הדבר הראשון מוגדר ולא מדויק בהגדרה מה שנקרא אני גם אוסיף על זה שכשנשמע שלנו כזה נורא דברים מוגדרים וזה בפועל אנחנו מגדירים בצורה סבבה אני חושב את ההייליבל כזה לאיפה אנחנו אולי כביכול רוצים ללכת ומשאירים הרבה פלסטלינה בלמטה כאילו כזה מסרטטים קווי מסגרת ואז אומרים טוב כולם פה ילדים גדולים כל אחד יסתדר עם השכן של ידו וזה לא ב ת הכל נוקשה ומוגדר כמו שאולי זה נשמע אנחנו משחקים בעיקר עם המסגרות אני חושב אני חושב דרך אגב המעבר הזה הוא בדיוק מעבר מתופ דאון לבוטום
זאת אומרת, בעולם של הטספורסים היה מישהו שניהל. נגיד ב עכשיו איזושהי דרישה מלקוח שיכולה לפתוח לנו עסקה מדהימה וכולי, אז היה איזו החלטה של איזשהו צומת מרכזי שמנהל את הדבר הזה, האם הולכים על זה, לא הולכים על זה, מי הולך ללכת על זה, על חשבון מה זה הולך לבוא וכולי, ועכשיו הדבר הזה מגיע לדומיינים. החזרת את הכוח לשטח במובן הזה. ב-100 אחוז, ואני חושב שזה גם מה שמאוד מאוד רצינו. הרגשנו, שוב, שהיינו קטנים, כולם היו בזה ביחד, כאילו זה ב ת, שגדלנו פתאום הרגשנו שיש איזשהו ניהול מרכזי, שזה הדבר הכי גרוע מבחינתנו. אנחנו רצינו שכל דומיין יהיה עצמאי לגמרי, יוכל לקבל החלטות, ידע למדוד את עצמו וכולי, ובמובן הזה זה היה ממש לתת את כל ה… זה היה ממש לשחרר, במובן הכי הכי משמעותי של זה. דיברנו על הפחדים, דיברנו על איך מבינים, איך בפועל מתקשרים לכמות מאוד גדולה כבר של אנשים בארגון, את זה שהם קמים למבנה עבוד… עוד פעם, הבנו שזה עמוק, כן? אני חושבת שעד כאן אין מישהו שמקשיב ואומר, זה איזה עניין קוסמטי פוליטי, זה הולך להיות שינוי בדרך, באיפה שאנשים יושבים, עם מי שהם עובדים, על מה הם חושבים, איך מתקשרים עם שינוי כזה? אז התחלנו בלהגדיר פורום של אנשים, שהוא בעצם הלידרשיפ של הפרודקט והדיזיין, ובעצם קבענו סשנים וקבענו עליהם אג'נדה. הסשן הראשון היה סביב למפות את הבעיות, למפות מה אנחנו רוצים לשמר. אני חושב שב ת רגע עכשיו, צחוק בצד, ניגשנו לדבר הזה, קצת כמו שאנחנו ניגשים לבניית המוצר, רק כשאני אומר אנחנו זה לא אנשי המוצר, זה החברה. קודם כל, ב ת, כתבנו על לוח מה הבעיות שלנו, ברמה הכי, כמו שאתם אומרים, מה הבעיות של לקוח, מה הבעיות שלנו, ואיפה זה כואב לנו, ולמה זה כואב לנו, והתעסקנו עם הבעיות שלנו, שעכשיו כזה ירינו אותן, כאילו כלום הרבה זמן. ואני חושב שאחרי שירינו את הדבר הזה, בעצם העלינו כל מיני רעיונות למה פותר את הדברים האלה, והיה פה הרבה משחק של כזה, נכון? כזה, הנה הבעיות שלי, הנה הפתרון. האם הפתרון הזה פותר את הבעיות? בערך, אוקיי, עושים איזו אדפטציה. האם זה פותר את הבעיות? כלומר, וכשהבעיות מוגדרות בצורה טובה, כמו כל דבר שאנחנו עושים, אז הפתרונות הם הרבה יותר קלים, או לא יודעים קלים, אבל הרבה יותר קל להסתכל עליהם ולהגיד האם מה שהצעת פותר את הבעיה המקורית שהעלית. ולא להת ב באיזה פתרון ולרוץ מהר מהר לעשות אותו. לגמרי. הסשן, אחרי זה כולם עשו דייג'סט לדברים, היה כל מיני הצעות לפתרונות. ואז הצעות לפתרונות היו נקודתיות, והיינו צריכים קווים שמחברים. אז עשינו סשן אחד של איך אנחנו מחלקים את ההוגה. בסדר? שזה היה סשן נהדר, כי פתאום מפינו מלא דברים שעד אותו רגע לא כולם היו עליהם, חלק כן, חלק לא וכולי, מפינו את העולם. אני זוכר שגם היה משחק כזה סימולציות, נכון? ממש, כמו בזה רנו, אוקיי, ואם קורה כזה וכזה וכזה, איך המבנה מכיל את התרחיש הזה? זה לא עובד. בלה בלה בלה, צריך לשנות את זה טיפה. מעולה, כמה שיותר להוריד את זה לפרקטיקה, ולא להישאר בחיים. כן, להוריד את זה לפרקטיקה ודוגמאות, וגם לא לנסות לפתור הכל בסשן אחד. זאת אומרת, לאפשר זמן בין סשן לסשן, לדברים לשקוע, יש המון דברים שעושים שינוי כזה, שאתה אומר, טוב, נעשה ככה וככה, ואז התגובה הראשונה של כולם זה, רגע, רגע, רגע, עצור. אז ברגע שאתה עושה את זה איזי, ועשינו ב ת במשך לדעתי ארבע או חמישה שבועות, כל שבוע, סשן של שלוש, ארבע שעות, ישבנו. כן, מאוד צריך להכיל את כל ה… אני זוכר אחרי הסשן הראשון שעשינו, שדיברנו על כל הבעיות, וב ת, היה שם שיח מדהים, וכזה פתוח, ועם כוונות טובות, ומכל הצדדים, זה היה פשוט מדהים, וכאילו אחרי הסשן, זה עוד היה לפני שהיה לנו פתרון, וזה היה, ופשוט הרגשתי הקלה כזאת, רתי, טוב, זה כבר יהיה פתור, כי אנחנו כולנו מבינים את אותה בעיה, ואנחנו מסתכלים על זה, זה פעם ראשונה באותו רגע שהרגשתי שכל הצדדים מסתכלים על כל הצדדים של התמונה, וזה היה נורא כיף, ומשם ב ת המשכנו, הגדרנו את הדברים, צריך גם להיות פה בקטע של לא להגדיר עד הסוף, ולהבין שכאילו עוד יש שינויים, ומה עקרוני ומה לא עקרוני, ולהתקדם פשוט, ואז בעצם דיברנו על איך אנחנו הולכים לתקשר את זה, וטו רול אוט, אז מהפרטים הלוגיסטיים של מתי אפקטיבלי מתחילים לעבוד ככה, עד פרטים של איך אנחנו משמרים ניהול של אנשים, שאנחנו רוצים שיש להם קרייר גרופא ודברים כאלה, אז ניסינו להתאים את זה ככה, שגם יהיה שינויים שנראים לנו הגיוניים. אני חושב שבסוף, כאילו היינו בחדר כמות מסוימת של אנשים, שיש הרבה יותר אנשים שזה משפיע עליהם, ויש עוד כאילו זה שלב בדרך לחשוב בעצם על מה כל אחד ישמע כשנציג את הדבר הזה, נכון? כלומר, אנחנו רוצים להגיד משהו אחד, לא בטוח שכולם ישמעו את אותו דבר. או בהכרח בטוח שלא כולם ישמעו את אותו דבר. כנר שבהכרח לא כולם, ואז אתה אומר אוקיי, אז בואו נחשוב מה אנשים עלולים לשמוע שזה לא מה שהתכוונו. ואיך לנטרל את זה מראש. איך עושים לדבר הזה מיטיגציה כלשהי, איך מחדדים את הנקודות האלה, כלומר, זה לא כשיחה שמקשקשים אותה ויוצאים לדרך, ממש צריך לחשוב טוב, מה כל אחד…
לא לשמוע מה זה גרום לו להרגיש, בסוף השינוי הזה הוא נורא נורא חיובי, וצריך לשקף לכולם בצורה מאוד מאוד טובה את כל התהליך ואת הבעיות ואת מה שהם אולי ישמעו לחדד בצורה מאוד טובה, ולנסות להעביר את זה בצורה הכי קלה שאפשר, ואני ממש זוכר שהייתה את השיחה, דני עוד שני ארכיב, אבל בסוף השיחה היה ממש רשימה של שאלות, נכון כמו אפיקיו באתר, אתה אומר האם זה אומר שאני אחד שתיים שלוש, ומדברים על זה, האם זה אומר ש… מדברים על זה, כלומר וזה נורא נורא חשוב, גם כי אני חושב שזה נוגע בנקודות שאולי בטעות איכשהו התפספסו במהלך הפלואו, אבל זה גם משדר שאנשים הם בפוקוס, רוצים שיהיה להם טוב, רוצים, אכפת, זה משדר אכפתיות, ובסוף אני חושב שזה הבסיס של הכל. או אולי אני רוצה להגיד, לא יודעת אם זה הבסיס של הכל, אבל זה הבסיס של כל הפחדים כשמישהו שומע על שינוי כזה, ששכחו אותו. בין אם זה ברמת האינדיבידואר, או שדברים השתנו ולא יהיו לטובה ביום יום שלו וכו', ואני חושב שעוד משהו שזה ה-FEQ זה ב ת בכל שינוי אורגני שאנחנו עושים או אנחנו עושים את זה בסוף, כאילו השאלות האלה של התכלס, אפילו ברמה הבסיסית, אז מתי משנים מקומות ישיבה? עוד דבר שאני חושב שהיה נהדר ועוד חלק שחייב להיות בשיחה כזאת, קודם כל זה להסביר את הלמה, להתמקד ממש בלהסביר את הלמה, להגיע למצב שאנשים מבינים את הבעיה קודם כל, ולפני שמציגים את הפתרון ומהו וכו', דבר שני זה לדבר על הדברים שב ת מפחידים אותנו בשקיפות, זאת אומרת נגיד היה לנו פחד מאוד שאנשים יהיה להם ראייה פתאום יותר צרה, שיתפנו את זה, רנו את זה בצורה הכי ברורה שיש ו רנו בדיוק מה מפחיד ואיך אנחנו נר שזה קורה ואיזה סיגנלים נגיד הם דברים שאנחנו צריכים להיזהר מהם ולשים לב אליהם ואני חושב שב ת לשתף בכל המידע. אולי נקודה אחרונה שזה לא דן דיל, כלומר זה לא התנח, אף אחד לא ירד עם ספר הפתרונות משום מקום, זה קונספט ראשוני שהיה בהתאבות, כנר יש בו מלא חורים שלא חשבנו עליהם, בסוף צריך שכולם ירתמו לדבר הזה וימצאו את החורים ביחד כדי לפתור אותם, לא כדי להגיד הנה יש פה חור, אנחנו עובדים ככה, זה למה הלמה הוא נורא חשוב, כי כנר שהפתרון יש בו טעויות, בסדר? כמו כל דבר שאנחנו עושים בחברה הזאת, אבל אם כולם מבינים את הלמה, אז כולם ביחד פותרים את הטעויות האלה שלא שמנו לב אליהם. כן, זה גם בעצם לשחזרת התהליך שעשיתם אתם בתוך הלידרשיפט, כי כשאתה אומר דניאל שברגע שהבנתם שהבעיות הן משהו שכולם חולקים, הייתה איזה רגיעה, הייתה הבנה שכולם רוצים את אותו הדבר ועכשיו רק צריך להבין מה זה הדבר הזה, אז אם אתה מתחיל מהלמה, כולם מבינים שכולם מיוצגים כאן, ה-dizine, ה-R&D, הפרודקט, אני גם זוכרת שזו שיחה שב ת עשיתם כולכם ביחד והובלה על ידי אנשים שונים מכל אחד מהאזורים האלה, ב ת כדי שזה יהיה מאוד מאוזן. וגם דרך אגב היה לנו שקף שאומר בדיוק מה הדברים שלא סגורים, כאילו המון המון דברים, והוא היה ענק, הוא היה מלא דברים, ומתוך הכוונה להגיד בדיוק את מה שרן ר, אין צורך להגדיר עד הסוף, הכל זה אנחנו נבין את זה תוך כדי. זה לא מגדול, אף אחד לא חזרנו לשקף ועדכנו את ההגדרות, הדברים כאילו הסתדרו. כן, המהות הייתה שם ואנשים כבר לקחו את זה. כן, הדברים הסתדרו ואנשים פתרו את זה ברמתם ומעולם לא רנו טוב, עכשיו חוזרים לשקף הלא סגור ואומרים מה קורה בכל נקוד, כאילו סבבה, היא נרצייה חיובית בוא נקרא לזה. אנשים קיבלו, הבינו, פתרו, התקדמנו. מה שב ת מוביל אותי לשאלה הב ואולי האחרונה לפני שסגור את הפרק, זה איך יודעים שזה עובד, כן? האם היו דברים כאלה נורות אדומות, גבולות ש רתם אם נגיע לשם זה סימן שזה נשבר, שזה לא עובד, והאם היו דברים שהגדרתם ש רתם כשנר את זה נדע שהכל דופק. התשובה היא שאי אפשר לדעת, אפשר לראות את הבעיות, אפשר לחשוב שנתת פתרון, אני חושב שאם זה לא היה עובד היית יודע, ואם אתה לא מרגיש משהו לא נוח באופן קבוע אז כנר שזה עובד, גם אם אולי יש דרך יותר טובה לעשות את זה, אבל הפתרון כרגע עובד. אני גם חושב שזה תהליך שהוא לא flip the switch ואם מחר כאילו דומיינים, אלא יש פה המון המון דברים, נגיד סתם היה דוגמה נהדרת שזה היה שונה בדומיינים שונים, דומיינים מסוימים לקחו את השינוי הזה, עשו אותו מיד, דומיינים אחרים היו צריכים יותר הכוונה ויותר עזרה, דומיינים מסוימים היינו צריכים לדבר איתם על סקילסט חדש שצריך לבנות בתוך הדומיין ואת כל הכלים שלנו להתקן, את כל הדשבורדים שלנו, את כל הפרוססים שלנו, נגיד סתם הן תן איזה אנקדוטה אחת אבל דעתי משקפת את זה ממש טוב, רנו טוב עכשיו צריך לקחת את התהליך של הבאגים, של איך מטפלים בו, שהוא היה centralized ומה עושים איתו עכשיו? אז שני אנשים אורון ואורון ראש צוות פיתוח ואחד מאנשי הפרודקט שלנו, פתאום פעם ראשונה התמודדו עם השאלה הזאת, הדבר הראשון שהם עשו זה לעבור על כל הבאגים, שזה הדבר כאילו תחשבו עד אותו רגע, לא היה אדם שעבר על כל הבאגים, היה כאילו מעט מאוד אנשים שהכילו את התמונה הזאת בראש והתחילו לבנות את זה ולפרק.
ולכת זה לבורדים ולחשוב על צורה כזאת שדיווח כזה ומעבר כזה ואיך אנחנו יודעים שזה לא מתפספס ואיך אנחנו מודים לאנשים שמטפלים בדברים שלהם כי זה פתאום מיליון אנשים. מה שאני מנסה לומר זה שזה ב ת שינוי שהוא מאוד מאוד רחב משפיע על המון המון דברים ואני חושב שעשינו אותו גרג'ואל תוך כדי טרנינג של דברים בהתחלה היה הרבה דברים שלא עבדו טוב זאת אומרת אני חושב שגם יש בעיות שפתרנו אחרי זה ב צעות adjustments על המבנה הזה. תן דוגמה. דוגמה נהדרת זה הפרפורמנס נגיד של המערכת שאני חושב שהבנו שזה אתגר עומק הבנו נגיד המהירות של הגלילה של הבורד. אולי גם נחדד את זה נכון רנו שכל דומיין מחזיק בתוכו גם את הפרפורמנס עכשיו אתה יכול לבנות דברים טוב אבל פרפורמנס הוא עולם תוכן בפני עצמו זה אני חושב החידוד. בוא נגיד ככה הבנו שיש בעיות מסוימות שבדומיינים שהם לא יוכלו להכיל כרגע כי הם דורשות מורכיות מאוד מאוד מסוימת והם דורשות פוקוס מאוד מאוד גדול והבעיה עצמה אם נתמודד איתה לא נעשה שום דבר אחר בדומיין וכתוצ מזה הקמנו עוד צוותים נגיד במקרה הזה יש לנו צוות שנקרא client foundations שאחד מהדברים שלו ב ת אחד מהגולס שלו זה לראות איך הוא פותר בעיות עומק כאלה ועם מורכיות ועם זה שהם זה אנשים שמאוד מאוד חזקים בדברים האלה ונמצאים על זה כל הזמן וזה נכון גם להרבה דברים שהם בכלל מ צים רוחביים שאתה רוצה לעשות נגיד עכשיו אתה רוצה להכניס סטנדרט חדש או אתה רוצה לעשות לשדרג סתם אני אומר את הפרמורק שאיתו אתה עובד צריך לעשות שינויים בקוד בכל הדומיינים אז איך אתה מוביל כזה דבר וכולי וכולי. איך אתה מוביל כזה דבר? אז נגיד במקרה הזה ב ת הצוותים הרוחביים הם צוותים שביחד עם הדומיינים הם עוזרים לקורדינציה והם עוזרים לתת את הוויזיון הזה. אבל אלה הם אנשים שיושבים בדומיין אחר או שהם פשוט אנשים שהם צפים מעל דומיינים. אז אני חושב שאחד הפיצוחים שלנו שבניגוד נגיד גילדות שהם הרבה פעמים גוף מייעץ אז אצלנו הצוות הזה של הclient foundations ויש לנו צוות כזה גם של הserver foundations זה צוות גם שהוא עומד בפני עצמו כלומר יש לו אנשים אני חושב שזה מה שעשינו שונה בצורה מאוד מאוד משמעותית וחלק מהפרמורק שאנחנו מגדירים ועד היום אנחנו עובדים על זה זה איך אנשים בצוותים האלה עובדים ביחד עם האנשים בצוותים בדומיין ואיך מנחילים פרויקטים ארוכי טווח וכולי וכולי ואני חושב שככל שעובר הזמן זה גם נעשה יותר גם יותר ברור וגם יותר טוב ומצליחים ב ת להניע דברים בסקייל ענק שזה כיף גדול לראות את זה. רת קודם שאנחנו כבר בנקודת זמן הנוכחית כבר יודעים להגיד שדברים נשברים לנו אז אם אתה יכול ככה לדבר על העתיד דווקא לא על מה שנשבר כרגע מה אנחנו מזהים מה השאלות הפתוחות שכרגע יש על הפרק. אני חושב שכשהתחלנו את הפרק נכון דיברנו על זה שכבר הגענו לאיזה נקודת יתיחה שחייבים לעשות שינוי עם התסק פורסים אז היום אנחנו עוד לא בנקודת רתיחה אבל אנחנו גם מתחילים להרגיש את הכאבים החדשים של הדבר הזה נכון דני נתן דוגמה אחת של איך מנהלים תהליך רוחבי זאת פתרנו אבל תהליכים רוחביים כאלה שדורשים הרבה דומיינים וזה הם מתחילים להיות טיפה יותר קשים לצורך העניין ואנחנו מתחילים להרגיש כל מיני כאבים במודל החדש שהם לא אומרים לנו תשנו משהו מחר בבוקר אבל הם כן אומרים לנו בואו תתחילו להיות במודעות וכשמתחילים לרתוח בואו נתחיל להניע את התהליך הזה ובתחושה שלי ונר לי סובייקטיבי גם אין בעל לחכות להגיע לקצת רתיחה בסדר לא חייבים להקדים את הרתיחה כי אם אתה מקדים אותה אז אתה לא ב ת מבין את הכאבים עד הסוף אתה חושב שאתה אולי מתחיל להבין ואני חושב זה בסדר שיש דברים שהיום הם מתחילים להיות אולי טיפה חורקים טיפה לא יותר קשים ואנחנו יכולים להמשיך לרתוח איתם להבין אותם יותר לעומק ואני לא יודע מה יהיה בעתיד אנחנו נצטרך לחשוב מחדש. הקטע של הפרימוטשור אופטימיזיישן הוא מטורף וצריך מאוד להיזהר מזה גם לטעמי כשאנחנו עברנו לדומיינים נגיד אחד הכאבים פתאום שהיה לנו זה שהיינו צריכים הרבה יותר אנשים בכל דומיין ולקח לנו זמן להגיע לשיווי משקל שם ואם היינו עושים את זה יותר מוקדם זה פשוט היה קורס השיטה לתוך עצמה כאילו לא היינו אז אני חושב שאני מאוד מתחבר לדברים וב ת אין פתרון אחד במבנה שמתאים להכל מבנה זה משהו שהוא קאסטומייז שצריך בכל נקודת זמן להבין מה אנחנו רוצים וגם לא צריך לנסות לייצר איזה איזשהו טמפלייט ולהכיל אותו על כל הארגון אני חושב שאחד הדברים שאנחנו מאוד מאוד אוהבים ומבינים היום זה שצריכים להיות לנו המון המון סוגים של שרירים והמון המון סוגים של מבנה ושיש שונות מסוימת בצוותים שהיא נהדרת והיא עוזרת וצריכים צוותים מכל מיני סוגים על כל מיני מ צים וזהו זה כזה סיכום שלך סיכום כן אני אוסיף שני דברים אחד שככה ב ת נעצתי במהלך הפרק שכשמשהו שאתה מאוד מאוד יודע להסביר לעצמך למה הוא עבד לך ולמה הוא טוב לך פשוט מפסיק לעבוד לך זה סימן שמשהו צריך להסתכל על זה כן לא צריך להתעלם מזה כשהיתרון הופך לחיסרון והדבר השני שמאוד מעניין ש רתם וככה שווה לסגור את אותו פרק זה ב ת העניין הזה של הכוונות הטובות שניכם דיברתם על זה
וזה חשוב לעצור בין הלהתקייב על זה כי בארגון כשיש הרבה אנשים ומחלקות וצוותים קל לחשוב שמישהו פה התבלבל, אבל דווקא כשמבינים וזוכרים שלכולם יש את אותן כוונות, כולם באים לדחוף את אותן המטרות ולנצח, וכשמישהו מתנהג או משהו מתנהג בחריקה או בצרימה מהפאטרן הזה, כנר שזה לא הבן אדם שהתבלבל, כנר שהשיטה שם צריך להסתכל עליה מחדש. ה ת זה מצחיק שאת אומרת את זה, אבל כשאני חושב על זה, אם יושבים שלושה אנשים שונים וכולם רוצים את אותה מטרה, אבל איכשהו זה לא מתחבר להם, הם רוצים את אותה מטרה אבל כל אחד בא לזה בזווית אחרת ויש איזה מין דיסוננס בין הרצון לבין הפרקטיקה, אולי, לא תמיד, אבל אולי זה סימן שהמבנה קצת או משהו מקשה עליהם. צריך להסתכל עליו. אני אגיד רגע אפרופו כי כן, שאלות המשך שאם יש מישהו שרוצה להבין יותר טוב משהו על השינוי, על עבודה בטסקפורסים, על עבודה בדומיינים, אז גם יפת וגם דניאל יותר מסמכו לענות. אתם יכולים לסיעו אותנו בקבוצת הפייסבוק שלנו ובאתר. ותודה יפת. תודה ליאור. תודה דניאל. תודה. אם הייתם יודעים כמה זמן הפרק הזה מתוכנן הייתם מבינים את הערך של התודה. תודה שהזנתם.