ליאור:            היי כולם, הגעתם ל-Startup for Startup, הפודקאסט שבו אנחנו חולקים מהניסיון, מהידע והתובנות שיש לנו כאן במאנדיי.קום וגם מחברות אחרות. הוא מיועד לכל מי שסטארט-אפ מדבר אליו, לא משנה באיזה כיסא הוא יושב ברגעים אלו [מוזיקה]. לפני שנצלול לנושא של היום נזכיר לכם שיש לנו קבוצת פייסבוק שנקראת Startup for Startup, שם תוכלו למצוא אותנו ואת האורחים שלנו. כל סטארט-אפ בצמיחה חווה כאבי גדילה. דברים שעובדים מעולה בצוות של חמישה אנשים לא בהכרח רצים כל-כך חלק במחלקה של 30 איש. בסוף 2019 חיווינו את זה בעצמנו, לאחר תקופה של חריקות משמעותיות שהובילה להבנה שצריך לעשות שינוי במבנה הארגוני של צוותי הפיתוח, המוצר והעיצוב בחברה. הטאסקפורסים, צוותי האד-הוק בהם עבדנו עד אז, הוחלפו בדומיינים – צוותים קבועים שמפתחים מומחיות ומבינים לעומק תחום מסוים במוצר. איך יודעים שהגיע הזמן לבצע שינוי במבנה הארגוני של צוות, מחלקה או חברה? איך נפרדים ממבנה קיים ומה השיקולים שעולים בתוך תהליך כזה? ואיך בכלל מבינים מה המבנה האלטרנטיבי הנכון? בפרק השבוע אנחנו מדברים עם דניאל לריה, Head of R&D, וערן הפט, Product Team Lead במאנדיי.קום, שמפרטים את תהליך השינוי הארגוני שבוצע. החל משלב זיהוי והגדרת הבעיה ועד לאופן בו שיקפו את השינוי לכלל החברה. דניאל וערן משתפים במחירים וברווחים של כל אחת מצורות העבודה, בחששות שליוו את התהליך ובשאלות שצריך לשאול את עצמנו כשמרגישים שהגיע הזמן לשינוי. כל זאת ועוד נשוחח היום עם דניאל לריה, שהוא Head of R&D במאנדיי, וערן הפט, Product Lead בחברה. היי הרן.

ערן:               היי ליאור.

ליאור:            היי דניאל.

דניאל:            היי ליאור.

ליאור:            טוב, הפט, אז ככה… הפט שהוא ערן שהוא הפט, תסביר לנו לפני שנתחיל להיכנס ללמה מבנה, איך מבנה, למה דומיינים, מה זה טאסקפורסים, ממה עברנו למה?

ערן:               מגניב. אז במשך הרבה מאוד זמן היינו במודל של טאסקפורסים, כמו שאמרת. בגדול taskforce הוא מודל אופורטוניסטי בוא נקרא לו. אז מזהים איזושהי בעיה בעולם, קם צוות ייעודי לפתור את הבעיה הזאת, יש לו מטרה מאוד ברורה, KPI מאוד ברור, הוא מדלוור את ה-maximum impact, ובעיקרון הוא מתפרק לאחר מכן. זה גוף שהוא זמני ביסוד שלו. מה שמאפשר לנו מאוד מהר לבנות כאלה, להשיג מטרות, לפרק, להשיג מטרות אחרות, וכן הלאה.

ליאור:            אחלה. דומיינים?

ערן:               דומיינים, להבדיל מ-taskforce, זה גוף שהוא קבוע. כלומר, זה לב הסיפור. אז אם בעצם לקחנו את כל עוגת המוצר נקרא לזה, חילקנו אותה לחתיכות לגדלים בגדול שווים, וכל חתיכה כזאת היא דומיין. כלומר דומיין הוא בעצם אחראי על חלק המוצר, כל חלק כזה הוא מאוד גדול, בסדר? כלומר, דומיין לא באמת יכול בכל רגע נתון להתעסק בכל הדברים שחונים אצלו. הוא בעצם סוג של מחפש את ההזדמנויות בתוך אותו דומיין ומפעיל קצת כמו שיטת הטאסקפורסים, כלומר במה מתמקדים עכשיו, מה הניצחון וכן הלאה. שהיתרון הגדול פה זה שבעצם קבוצת האנשים האלה בתוך הדומיין מכירים את הדומיין לאורך זמן, הם קבועים שמה, יכולים לפתח expertise ועוד דברים שנרחיב עליהם בהמשך.

ליאור:            דניאל, אתה רוצה לתת דוגמאות?

דניאל:            נגיד אם ניקח את עולם הטאסקפורסים, אז בפן הפרקטי גם חשוב להגיד שכשעבדנו בטאסקפורסים אז הייתה איזושהי חלוקה של זמן, זאת אומרת 50 אחוז מהזמן אנשים היו עובדים בטאסקפורסים כמו שערן אמר על איזשהו KPI ו-50 אחוז הם היו עובדים במסגרת אחרת של הצוות האורגני שלהם לפי הדיסציפלינה. ואז לדוגמה taskforce שהיה, אם ניקח אחד מהטאסקפורסים באמת אני חושב אחד מהראשונים, נגיד taskforce שעבד בזמנו על batch action, שזה היכולת שלנו במוצר, בבורד שלנו שזה הטבלה הראשית, לסמן כמה אייטמים בעצם ולעשות פעולה על כולם בבת אחת. אז בזמנו נגיד ה-taskforce הזה היה מורכב מארנון, שהוא היה המפתח באותו הזמן, ויבגני שהוא מעצב, והם בעצם 50 אחוז מהזמן שלהם עבדו ביחד כדי  להשיג את המטרה של בעצם לממש את הדבר הזה שנקרא batch actions ולאפשר פעולות על מספר אייטמים בבת אחת. ואם ניקח דוגמה היום לדומיין, אז נגיד ניקח דומיין קלאסי, יש לנו דומיין שנקרא board score, שזה בעצם דומיין שאחראי על החלק הזה במוצר שהוא הבורדים בעצם, והוא אחראי עליו מקצה לקצה היום.

[00:04:00]     אז ההזדמנויות שם הן מתחלפות כל הזמן, כל Q יש הזדמנויות אחרות תחת עולם התוכן הזה של הבורדים, בתוך עולם התוכן, ובמקביל הוא גם אחראי לכל אותם דברים שבעבר החיו ב-50 אחוז האחרים. זה גם איזושהי נקודת מפתח מאוד מאוד גדולה, נגיד הוא אחראי על ה-quality בבורדים, הוא אחראי על ה-performance בבורדים. הוא אחראי על ה-security בבורדים. הוא אחראי על ה-craftmanship, זאת אומרת על הרמה שבה המוצר בעצם נמצא. ובעצם יש לו אחריות הוליסטית על כל האספקטים.

ליאור:            כי במבנה של taskforce אז בעצם מי אחראי על ה-quality לצורך העניין?

דניאל:            אז במבנה של taskforce בזמנו לדברים הספציפיים שפיתחנו באותו רגע, נגיד אם נחזור לדוגמה של ה-batch actions, אז זה בעצם אנשים שעובדים על ה-batch actions. אבל כל הדברים שהם כבר פותחו ולכל המערכת ולכל האספקטים בה, אז בעצם היה אחריות ריכוזית, זאת אומרת, הסתכלנו על זה ברמה של כל הפיתוח. ואת ה-50 אחוז הנותרים – בין אם זה היה בהתחלה בצוות אחד ואז ביותר מצוות אחד – היינו מנהלים בבקלוגים נפרדים. זאת אומרת היה backlog אחד של quality, היה backlog אחד של performance, היה backlog של כל נושא רוחבי שרצינו. וב-50 אחוז היינו מושכים מאותם בקלוגים ואנשים היו עושים את המשימות האלה דרך שם.

ערן:               אולי שווה להרחיב ולהגיד בסוף מה זה 50-50, נכון? אז 50 אחוז זה אותם טאסקפורסים, זה בעצם מה שקוראים להם product increments, אנחנו רוצים להתקדם בכל-מיני נקודות. אבל בוא נחשוב רגע על מה זה מוצר, אז יש התקדמויות מוצריות, נכון? פיצ'רים חדשים ו-whatever. אבל יש הרבה דברים שעוטפים את זה, נכון? אם זה performance ואינפרה ו-security ועוד מלא מלא דברים שאפשר להרחיב עליהם מלא. ועוד דבר, יש בעצם את כל מה שטאסקפורסים אחרים עשו. Over time הם עברו לדברים אחרים. והפיצ'רים האלה נשארו בלי אמא ואבא, נכון? עכשיו, וזה תוכנה, יש בה באגים, יש בה שיפורים, יש בה דרישות, מישהו צריך לטפל בזה. אז בעצם אפשר להגיד שהיה 50 אחוז, או 50-50 על התקדמויות מוצריות בדברים חדשים, ו-50 אחוז ניהול של כל השאר.

ליאור:            אחלה. תיכף כמובן ניכנס להבין יותר טוב עד מתי זה עבד, מתי זה התחיל להישבר, מה נשבר. שנייה לפני שנצלול ככה ללהבין את האתגר ואיפה הבנו שצרחך להשתנות – דניאל, אם אתה יכול טיפה להרחיב על המספרים באמת.

דניאל:            ה-taskforce הראשון שלנו היה ב-2017, תחילת 2017, אני חושב שקראנו לזה פעם ראשונה taskforce. ובעצם באותה תקופה היינו סדר גודל של עשרה מפתחים. Product היה רק את שירלי בזמנו. ומבחינת מעצבים סדר גודל של שלושה מעצבים בחברה. כשהתחלנו לחשוב על השינוי, עד שהתחלנו לחשוב על השינוי היה הרבה גלגולים של הדבר הזה, אבל סביב אותה מהות של הטאסקפורסים. וב-2019 התחלנו לחשוב, סדר גודל של אפריל התחלנו להבין שאנחנו רוצים לעשות איזשהו שינוי לכיוון הזה. באותה תקופה היינו 35 מפתחים, בערך שבעה אנשי Product. וסדר גודל של 15 מעצבים בחברה. ואת השינוי בפועל עשינו בסוף 2019, אוקטובר או נובמבר. ובעצם היינו אז 45 מפתחים. 11 אנשי Product, 25 מעצבים. עכשיו, המספרים הם roughly, כן? אני לא זוכר בדיוק, אבל זה הסדר גודל, כלומר אפשר להבין את הסדרי גודל מזה. [מוזיקה]

ליאור:            אז אוקיי, אז הבנו איפה היינו ולאן הגענו. עכשיו בוא נבין מה קרה באמצע ומה גרם לזה שהבנו שצריך לעשות שינוי.

ערן:               אז קודם-כל אני חושב שנורא חשוב להבין שבסוף ה-structure והמבנה שבו עובדים הוא קצת מכתיב את ה-day to day, נכון? זה קצת, אם אני אתן אנלוגיה יותר קלה, אם יש לך מחלקה מסוג

[00:08:00]    מסוים אז עושים את הדבר הזה ואם אין לך אותה אז לא עושים את זה. אז גם בעבודה השוטפת זה היה ככה. אז כשדיברו קודם בעצם על 50-50, נכון? 50 אחוז מהזמן עובדים ב-taskforce על התקדמויות ו-50 אחוז מטפלים בכל השאר-

ליאור:            זאת הייתה המציאות באיזשהו שלב.

ערן:               זו הייתה המציאות. וזה היה נורא קשה. כי ה-50 אחוז האלה הם היו שונים אצל כל בן אדם. בסדר? נגיד היו מפתחים מכמה צוותים שונים, שעובדים על כמה דברים. כל אחד מהם בעצם ניהל את ה-50 שלו מתי שבא לו. ואז אתה בא לעבוד עם הבן אדם הזה, הוא אומר לך "לא לא לא, עכשיו אני ב-50 השניים"-

ליאור:            אה, זה היה פרסונלי?

ערן:               היה פרסונלי. כל אחד קובע לעצמו את ה-50, הכול בקטע טוב-

ליאור:            מבחינת לוחות זמנים או מבחינת כמות עבודה?

ערן:               גם כמות עבודה וגם החלוקה שלה לפי לוחות זמנים. ואז זה יכול להיות שאתה ב-money time של איזה משהו, ואתה בא לאחד המפתחים שאתה עובד איתם ואומר לו יאללה, בוא נרביץ את זה. לא, אבל הוא עכשיו ב-50 הנוספים. עכשיו, זו חוויה נורא מתסכלת מצד אחד לי, כ-Product בחברה. מצד שני גם לאותו בן אדם זו חוויה מתסכלת, כי גם הוא רוצה להצליח ולתת בראש ולהתקדם עם הצוות, אבל יש לו עוד דברים שהוא עושה.

ליאור:            רגע, לפני שאתה ממשיך אבל, דניאל, מתי למבנה הזה כן היה, מתי הוא עשה שכל?

דניאל:            אז אני חושב ש-

ליאור:            בוא, תגן על התזה [צוחקת]

דניאל:            לא, א' אין לי איזה אהבה מיוחדת למבנה אחד ספציפי. אבל אני כן חושב ש… א' היינו הרבה יותר קטנים. ואני חושב שבאותה תקופה היינו בחוסר שיווי משקל גם בין פיתוח ל-Product, ואז בעצם מה שנוצר מצב זה שהיה כל הזמן starvation בנושא הזה של ה-Product, ואז היה המון המון משימות שגם שעובדות על המוצר הן היו בלי Product. אז היה לזה הרבה פחות משמעות כשאת חושבת על זה ככה, כי בעצם כל האנשים שעובדים עובדים ביחד, בסדר? אז מה שכן הרווחנו מזה זה המון המון דינמיות, היכולת לשנות דברים מאוד מאוד מהר. אנשים הרגישו שהם מאוד מאוד שולטים בזמן שלהם, ושיש להם המון המון אוטונומיה על הזמן שלהם והם יכולים לרוץ ולעשות דברים. Bottomline, זה עבד מאוד מאוד טוב כי היה המון הומוגניות בכוח, כאילו, שעבד על הדברים. ואני חושב שככל שהכוח הופך להיות יותר הטרוגני וגם שקול אז נכנסנו בעצם למצב שה-50-50 יצר המון המון תיאומים שאנחנו מלכתחילה לא רצינו להתעסק עם התיאומים האלה. זאת אומרת-

ליאור:            אוקיי, אז מה היה השינוי מה-50-50, לאן עברנו?

ערן:               אז בעצם מ-50-50 עברו בעצם ל-7-3. כלומר שבעה ימים בעצם בתוך ה-taskforce, עושים Product Increment ומתקדמים, ושלושה ימים בעצם באותו מודל של כל המסביבים, בסדר? ה-performance ו ה … [לא ברור] , דברים חשובים. וזה מאוד שיפר את המצב, כי קודם-כל עכשיו ידעת אני כ-Product שיש לי שבעה ימים מלאים עם הצוות שלי לעבוד איתם, זה לא כל אחד הולך מתי שבא לו. אבל מצד שני, פתאום אתה מתחיל להגיד רגע רגע, אתה עובד, אתה מתקדם, אתם ב-money time של משהו, ואז פתאום מגיע השלוש ואתה אומר "זה לא חשוב" במרכאות כמו מה שאני רואה לנגד עיניי, בוא נטרוף את זה.

ליאור:            ממש כמו שאמרת שהמבנה מכתיב את החשיבות, אז כשיש לך משהו שהוא 70 אחוז מהזמן ומשהו שהוא 30 אחוז מהזמן, והוא נכפה עליך בלי קשר לסדרי עדיפויות.

ערן:               ועכשיו אתה גם שואל איך מתעדפים, נכון? כלומר, פתאום יש שני קונטיינרים, יש קונטיינר השבע ואת קונטיינר השלוש, ואנחנו עושים תיעדוף פנימי בתוך כל קונטיינר. אבל מה אם אני מחזיק ביד של השבע במירכאות את הדבר הכי גדול בעולם? הוא לא מתועדף בכלל בתוך השלוש. ואז הדבר הזה, אחד הוא יוצר, שוב, את אותם תסכולים מפעם, נכון? כי כולם רוצים להתקדם וכולם גם רוצים לשפר את ה-performance, ונוצר פה איזה מין מבנה שהוא יוצר friction אינהרנטי. כאילו זה מצחיק, נכון? תמיד האמת היא בפרטים הקטנים. כי נגיד כבר אפשר להסתדר עם ה-7-3, אנחנו מכירים את החיים, משימה שהתחילה ב-3 יכולה לקחת 4. ואז אני מורט שיערות מהראש, נכון? אני חייב את היום הזה, אנחנו חייבים לנצח, והשטות הזאת, משימה ש… ודרך אגב, גם בכיוון ההפוך-

ליאור:            בדיוק, רציתי להגיד גם בכיוון ההפוך.

ערן:               גם אנחנו נגסנו מה-3, הכול בסדר, כאילו-

ליאור:            לא, וגם בכיוון ההפוך של "טוב, אני לא אכנס לאיזושהי משימה כי אני רואה מלכתחילה שזה ייקח לי 6 ולא 3?

ערן:               לא, זה אין אצלנו [צוחקים].

[00:12:00]

דניאל:            אני כן יכול להגיד גם עוד משהו שאפשר אפילו לראות אותו בשיחה פה בינינו, שבאמת היו פה שני וקטורים שכאילו התחרו. שזה לנצח ב-7 ולנצח ב-3, כשהמציאות היא לא כזאת, כאילו, המציאות היא פשוט יש לך מוצר שאתה מפתח ושאתה רוצה לראות שהוא טיפ-טופ all the way. וזה גם לא נכון להכתיב בצורה גורפת עבור כל המאמצים שלנו כמה אנחנו צריכים להשקיע בכל דבר, כי באמת יש דברים מסוימים נגיד, ניקח אזורים מסוימים במוצר שהם במצב ממש ממש לא טוב. היה לנו פה באמת קשה מאוד לייצר שיחה שבה מי שרוצה לקדם איזשהו פיצ'ר increment ב-7 מבין את הדבר הזה של ה-quality, וגם להיפך. ואני חושב שמה שזה יצר זה יצר בעצם באמת שני אינטרסים, שהמציאות היא לא כזאת קודם-כל. אני חושב שגם בהקשר הזה חשוב מאוד להגיד, יש פה איזה pitfall שאני חושב שהוא היה סופר-סופר-משמעותי והוא גם סביב מתי לעבור בדיוק לדבר כזה. כשהיינו בעיקר פיתוח, היה מאוד ברור מה זה הצוות. מי נמצא ב-daily, מי ברטרו. כאילו, ופתאום אתה עובר, כאילו ופתאום מצטרפים עוד אנשים וכו', ושמנו לב שב-7-3 בעצם יש לי split personality כזה. כי ב-7 אני בצוות עם המעצב ועם האיש Product וכו', וב-3 אני רק פיתוח. ואז כאילו השאלה היא באמת מה הצוות, איפה עושים רטרוספקטיב. איפה כאילו מתקיים השיח על הדברים של התנהלות של צוות וכו'. אז אני חושב שגם בהקשר הזה זה משמעותי.

ליאור:            לא צריך Product ב-3? לא צריך Product בכל מה שקשור לאינפרה ו-quality?

ערן:               ווה ווה. זה היה אחת מהשיחות אני חושב הכי חמות, נכון? כלומר, בסוף – אמרתי את זה בהתחלה – אנחנו כולם בחברה מבינים את החשיבות של quality ושל performance, זה חלקים אינהרנטיים מהמוצר. אז איך מודדים אותם, אני מתעדפים אותם, איך אומרים מה חשוב ממה? אנחנו שאלנו את אותה שאלה – אם לא צריך לשנות Product, מי עושה את זה בכלל? ובאותה נשימה גם אני חושב על החבר'ה מ-R&D שצריכים בעצם ברגע אחד לעשות סוויץ', להרוג את ה-7 במירכאות בראש, להסתכל על איזה backlog מלא דברים בכל הכיוונים, ומהרגע להרגע להתחיל לראות איך אוכלים אותו בכלל ומה יותר חשוב ממה. והדבר הזה פשוט יצר friction אינסופי לכולם.

ליאור:            אני לא מאמינה שאני אביא את הדימוי הצבאי בחדר, אבל זה קצת נשמע כאילו יש לך את התפקיד בצבא ואז יש לך את המשמרות, נכון? את התורנות מטבח, את האבט"שים. את כל הדברים האלה שאתה עושה אותם כי אתה חייב, לא כי זה התפקיד שלך. וככה אתה מצייר את ה-3 פה. כאילו, backlog, כאילו, אפילו השפה שלכם על זה-

דניאל:            אז זהו, אז הנקודה שזה לא בדיוק ככה, כי כן ב-3 היה נגיד increments קטנים במוצר ודברים שאנחנו קוראים להם צ'יזים, כלומר איזשהם שיפורים במוצר שהופכים את הדברים ליותר טובים. הנקודה היא כן, אני יכול להגיד מהצד שלי בוא נגיד את ה-frustration שאני הייתי בו, שכשעבדנו בטאסקפורסים אז היה המון המון דברים שנוהלו בצורה centralized. נגיד מה עושים עם משהו עכשיו שהוא לא קשור לשום דבר, בסדר? נגיד סתם דוגמה, אנחנו רוצים לשפר את ה-CSO בכלל ב-website, ב-homepage שלנו של מאנדיי.קום, לא בפלטפורמה, לא קשור לשום פיצ'ר, לא כלום. עכשיו, כשהיינו קטנים ובניהול centralized אז מאוד מאוד קל לגעת בכל דבר, מאוד מאוד קל לתת את המכה שאתה צריך, לא יותר ולא פחות. וע"י זה אתה משיג efficiency מטורף. זאת אומרת, היה לנו באמת, סדר גודל של שנה וחצי שהספקנו דברים, אנשים לא היו מאמינים בכלל שאנחנו ככוח כזה קטין יכולים לעשות כזה דבר. וכשגדלנו והיינו עם ה-7-3 וזה כאילו כבר לא התאים, אז גם היה כל הזמן את הקטע הזה שבאים כל-מיני דברים מכל-מיני מקומות שהם לא סביב הדברים המרכזיים שאנחנו עובדים עליהם כרגע, ולי הייתה הרגשה שאני מאוד צריך להכיל את הכול בראש. זאת אומרת, לתכנן את השלושה ימים, זה היה משימה שנגיד ראשי הצוותים היו לוקחים וזה היה טירוף, כי זה היה באמת קשה, כי זה היה לחפות פתאום בשלושה ימים על כל הדברים שבשבעה ימים לא נגעו בהם.

[00:16:00]     ואני חושב שפה היה באמת, מכל צד שאתה לא מסתכל על זה הרגשנו שזה פשוט לא עובד וזה לא משרת לנו את המטרות יותר כמו שהרגשנו בעבר, כאילו, לפני זה, אם נחזור לפרק על האימפקט שהוא מלפני שנתיים אני חושב, אז שם כאילו עוד היינו במבנה של הטאסקפורסים והרגשנו שזה הדבר, כאילו, שפיצחנו את האטום. ופה פשוט הבנו פתאום שזה לא עובד.

ערן:               גם אם תחשבו על taskforce זה כאילו הארגון הכי סקסי שיכול להיות, נכון? אתה מזהה בעיה, אתה פטור מכל צרות העולם, ואתה רק הולך לגעת כירורגית במקום כאילו הכי טוב שיש במוצר. אז כל דבר הוא כאילו מחוויר ליד זה. אבל ברור ש-taskforce לא יכול להתקיים בלי כל השאר, נכון? זה כאילו מין מתח שנורא קשה להכיל אותו. ויותר מזה אני גם חושב ש, עוד בעיה שנוצרה, אני יכול להגיד מהצד שלי כ-Product, זה בעיה של ownership, נכון? עכשיו-

ליאור:            תסביר.

ערן:               בוא נחשוב על זה. אם ב-3 יש קבוצת אנשים, שאני לא יודע מי הם, שמטפלים בכל הבאגים וכל השיט והאדמה החרוכה שהשארנו אחרינו – נשמע לי סידור לא רע. כלומר, אני הייתי שמח אם היום כל סופ"ש היו מגיעים כל-מיני אנשים שאני לא יודע מי הם במירכאות-

ליאור:            מנקים לך את הבית.

ערן:               מנקים לי את כל הדברים שעשינו לא טוב.

ליאור:            החלודה ככה בדלתות עליהם.

ערן:               כן, אז אני יכול להגיע בראשון בבוקר ולטרוף את העולם.

ליאור:            ולרוץ.

ערן:               נכון? אז כאילו אוקיי, אז מה זה אומר… עכשיו, מה זה אומר על ההשקעה ב-quality? אה, ב-craftmanship? עכשיו, שום דבר פה לא נעשה בכוונה רעה, כן? זה קצת חוזר למנטרה שלנו שהמבנה מכתיב את המציאות, נכון? אני יכול לייצר יותר delivery, אם אני לא צריך לתפור all the way את כל הדברים. כי אותם אנשים, אנשי ה-3 שאני לא יודע מי הם, הם יעשו את זה.

ליאור:            אגב, אני חושבת שהעיקרון הזה ברור גם, גם אם אתה מסתכל על taskforce מלמעלה ולא רק על החלוקה ל-50-50 או ל-7-3, כי taskforce במהותו זה צוות זמני כמו שאמרת. אז נגיד שאתה עכשיו עובד על אזור חדש במוצר. נגיד נקרא לו אוטומציות ואינטגרציות למשל.

ערן:               למשל.

ליאור:            אתה רץ על זה. זמן שהגדרנו מראש, 12 שבועות נגיד. אחר-כך אתה נותן את זה למישהו אחר. הגעת להצלחה, לא הגעת לניצחון, הגעת לניצחון מסוים, אתה רואה באופק עוד ניצחונות אבל הם לא שלך-

ערן:               לא, גם יותר מזה, בואי נחשוב נגיד-

ליאור:            אני שואלת, כן? אגב-

ערן:               לא, זה נגיד דוגמה נהדרת.

ליאור:            לא לא, אז תסבירו.

ערן:               האוטומציות למשל, בסדר? אתה מתחיל אותן-

ליאור:            אתה מתחיל אותן.

ערן:               אני מתחיל אותן. אתה לא יודע אם זה… כלומר, יש vision ויש אמונה, אבל אף אחד לא באמת יודע עד שלא יוצאים החוצה לעולם. וזה מאוד מאוד הצליח. אבל פתאום צריך תשתית למשל פי אלף רובסטית למשהו שמצליח בכזה קנה מידה. עכשיו, אם הדבר הזה קיים חצי שנה ולקח חצי שנה להגיע למקום סופר-מוצלח, ועכשיו צריך תשתית שמתאימה לגדול עם זה שנתיים. מי עושה את זה? כלומר, זה פשוט לא מתאים אפילו יותר.

דניאל:            כן, בצורה יותר כללית, כאילו, השיטה של הטאסקפורסים היא לא, כל המאמצים שהם long term הם צריכים להיות מחוץ ל-taskforce. זאת אומרת הם צריכים שמישהו אחר יהיה ה-mastermind בגדול של התוכנית הזאתי ויסתכל על הדברים בצורה הוליסטית, בעוד שבעולם של הדומיינים זה אחרת. כל דומיין הוא אחראי לכל האספקטים. אני יכול רק להגיד על הנושא הזה של ה-ownership, שגם, תראו, אחד הדברים שחשוב להגיד, זה נשמע כזה… לכולם פה היה את ה-best intentions, וזה היה מדהים פשוט לראות שאנחנו כולנו ביחד מנסים למצוא את הדרך שהדבר הזה יקרה והדבר הזה יהיה יותר טוב. והמון המון דברים ותסכולים אני חושב שהם נבעו באמת – זה קצת אמר כאילו הפט, שהמבנה מכתיב את היומיום. אני נגיד הרגשתי שאחד ה-learnings הכי משמעותיים שלי זה שהיה המון המון דברים שאני הרגשתי שמחזיקים אותם ב-3 במרכאות ואנשים אחרים אפילו לא מודעים אליהם. וזה לא שהם לא רוצים וכאילו זה לא שהם לא חושבים על זה וזה לא שכאילו העולם שלהם הוא מצומצם רק ל-increments במוצר. ובאמת כשהתחלנו כאילו להסתכל על הדברים בצורה יותר הוליסטית אז היה לנו תהליך של להגיד מה זה להסתכל על performance, מה זה להסתכל על כאילו quality. איך מתמודדים עם interruptions,

[00:20:00]    כאילו שהם לא קשורים, ומי עושה אותם וכו'. וזה היה תהליך נורא מעניין, אני זוכר, סתם ככה בהקשר של ה-ownership עשינו… [00:20:10] איך היה התהליך, אבל באחת השיחות שדיברנו על ה-structure הזה אז פתאום התחלנו… אני זוכר, התחלנו להציף את כל הדברים שצריך לעשות ולמפות אותם, ופתאום אחד מאנשי ה-Product תופס את הראש ואומר רגע, איך נעשה את כל זה? וזה היה רגע נהדר, כי זה היה רגע פתאום שהבנתי שזה שהחזקנו את זה בעצם מנענו מאנשים אחרים להבין. ומנענו מאנשים אחרים לקחת על זה ownership. וזה לדעתי נקודה מאוד מאוד משמעותית, של בעצם-

ערן:               קצת כמו כל דבר בחברה, לא? כלומר, אם בן אדם לא יודע ולא חושפים אותו – לא בקטע רע, זה לא עניין של מידור, כך יצא –

דניאל:            כן, לגמרי.

ערן:               אז אי אפשר לצפות מאותו בן אדם לעשות משהו about it. כאילו, זהו.

דניאל:            כן. רק חשוב לי פה כדי לאזן את זה קצת, כי אנחנו כאילו, בגלל שאנחנו היום בדומיינים וכאילו אנחנו לגודל שלנו זה ברור שזה מתאים פי מיליון, אתם יודעים, בנקודה שהגענו לנקודת רתיחה זה כבר היה ממש ממש הרגיש לא טוב. אבל לפני זה, אם נסתכל על טאסקפורסים במבנה שהוא יותר קטן, באמת כאילו הכמות דברים שהתמודדנו איתם היא עשרות מונים, זאת אומרת, אני יכול להגיד שגם בעבר היה לנו ניסיונות קודמים – בכל-מיני חלקים של ה-R&D – לקחת איזשהו אזור ולפרק אותו לדומיינים מה שנקרא. אבל זה היה בן אדם אחד בכל דומיין או משהו כזה, כי היינו נורא קטנים-

ליאור:            זה היה מאוד מלאכותי, כן.

דניאל:            וזה פשוט קרס, כי אתה היית צריך את הדינמיות ואתה היית צריך את ההמון דברים, אז כאילו יש פה את הנקודה של קו פרשת המים, שהוא באמת סביב גודל וסביב הומוגניות של לקוח, כאילו אם זה Product-Dev-Design, רק Dev, רק זה וכו'.

ליאור:            וגבם סביב מה שנקראה לי הפט נגד בו קודם, סביב הבשלות והמידה שהמוצר כבר קיים, כן? כי אני חושבת ש-

דניאל:            כן, ה-complexity מה שנקרא.

ערן:               ה-complexity, בדיוק.

דניאל:            ה-complexity, כן. כמה ה-complexity וכמה אתה מרגיש גם שאתה צריך באמת פרספקטיבה שהיא long term. ואנחנו אוהבים להגיד ש, זה כמו ה-rule of thumb  שלנו כזה למתי להקים צוות חדש או למתי להקים דומיין חדש, וזה כמו כזה פרקטל, שזה צורה שאתה עושה עליה זום ואתה רואה את אותה צורה בדיוק. כלומר, אנחנו רוצים… לדעתי הנקודה הטובה לעבור והנקודה הטובה להקים דומיינים זה ברגע שאתה מרגיש שברגע שפיצלת את זה לדומיין עדיין הדומיין הוא עולם ומלואו, בסדר? ואני יכול להגיד שכשהיינו קטנים לא הרגשנו ככה, אמרנו "אם אתה תתעסק רק בזה, זה נורא מצומצם, זה נורא קטן, זה לא מספיק, כאילו יש לך עוד מלא דברים שאתה יכול לעשות." היום בדומיינים זה עולם. יש לזה את ה-quality של זה ויש לזה performance ויש לזה את ה-long term planning של זה ויש את ההזדמנויות הארוכות וכו' וכו'.

ערן:               אני גם חושב שיש עוד נקודה שאולי נשמעת קצת טריוויאלית, אבל לא הזכרנו אותה. היו פשוט אזורים שלא רצינו להפסיק לעבוד עליהם, נכון? כלומר, דיברנו על דינמיות וכן הלאה, אבל יכול להיות משהו, או שהוא נורא ב-core של המוצר, כמו הבורדים שלנו, או המאמץ שמאוד מאוד הצליח ו… אם המבנה מחייב אותנו כל חצי שנה לפרק את הצוות הזה בשביל לבנות צוות אחר, אז בהגדרה אנחנו לא יכולים להמשיך להתקדם שמה. אבל זה משהו נורא מוצלח או נורא בכוח, אנחנו רוצים להמשיך לעבוד עליו והמבנה לא מאפשר לנו בכלל. זה אסור לנו לפי חוקי הפורמט.

דניאל:            כן, אפילו ניקח את זה צעד אחד יותר קדימה. כלומר, היה טאסקפורסים שהמשיכו כמה מחזורים, אבל יש קטע כזה של תחרות מה שנקרא על משאבים. שתמיד דברים שהם חדשים ודברים שהם הזדמנויות חדשות הם נוטים לגנוב את כל ה-attention. והרבה פעמים הבנו שבשלב מסוים של החברה יש דברים מסוימים שאנחנו רוצים להשקיע בהם, להמשיך להשקיע בהם, לא משנה עכשיו מה יש עוד על השולחן, ודרך מאוב טובה זה להגיד זה separate effort, עולם בפני עצמו, והוא לא חלק מה-pool הזה במשחק. [מוזיקה]

ליאור:            השאלה היא איפה בן אדם, כשהוא מגיע למבנה הזה של ה-taskforce – הנשבר, בסדר? אני לא מדברת על ה-taskforce האידיאלי – אבל בימים הלא טיובים שלו, כשאני קמה בבוקר בתור Product או R&D או developer פה, איפה אני מתיישבת? על מי אני מסתכלת סביבי? האם יש כיסאות מוזיקליים מסביבי? זה מרגיש

[00:24:01]

נורא לא יציב, אוקיי? ברמה הפרסונלית עכשיו, ברמת הבן אדם.

ערן:               התשובה היא תלוי באיזה יום קמת. [צוחקים].

דניאל:            זה מאוד מאוד דינמי. ואני חושב שזה חלק ממה שרצינו להוביל. אחד הדברים שגרמו לנו להבין שזה שבור בעצם, זה שלא היה ברור מי הצוות שלי, לא היה ברור עם מי אני נמצא ביומיום, לא היה ברור מי האנשים שאותם אני מגדיר כשותפים ליומיום שלי, עם מי אני מתיישב בבוקר, עם מי אני הולך לאכול, כל הדברים האלה. ובתפיסה שלנו בחברה אנחנו רואים את זה שזה צריך להיות כל האנשים שעובדים ביחד. זאת אומרת Product-Dev-Design – זה צריך להיות הצוות האורגני ביחד. ולכן עוד דבר שבאמת גרם לנו מאוד מאוד לזוז לכיוון הזה של דומיינים ושהדומיין יהיה הטרוגני באנשים שבונים אותו, זה שרצינו לשים את הפוקוס שם. זאת אומרת רצינו שהיומיום של האנשים יהיה ביחד, שהוא יהיה, זה היחידה שנגדיר אותה כצוות ולא צוות שמוגדר ע"י דיסציפלינות עם ממשקי תקשורת בין הדיסציפלינות השונות.

ליאור:            אגב, עוד מחשבה בכיוון הזה – כשיש מעט מאוד אנשים באמת ואז הטאסקפורסים בנויים ממעט אנשים קבועים, כולם דוגמים את כולם ויש כבר איזה מערכת יחסים-עבודה עם כולם. אני מדמיינת עכשיו שלושים איש מנסים ללמוד כל פעם לעבוד עם עשרה פרודקטים. רק תהליך הלמידה וההיכרות של איך עובדים נכון כצוות לוקח המון משאבים.

ערן:               קשה מאוד.

דניאל:            לגמרי, זה מאוד קשה. זה מאוד קשה בגדלים כאלה, ואתה מאבד את היתרון של זה, שזה לעבוד עם הרבה אנשים, להכניס מוח חדש לאתגרים קיימים, שמאוד נהנינו ממנו בטאסקפורסים, אבל כשזה גדול זה נהיה מאוד קשה והדינמיקה של העבודה עד שאתה לומד אותה אתה כבר מתפרק והולך לדבר הבא. ובאמת, אני חושב שבנקודה שהבנו שזה לא מתאים זה כבר היה ממש ממש לא מתאים בוא נגיד ככה.

ליאור:            שוב, אנחנו משתפים את זה גם כדי באמת ככה הזמנה לכל אחד שיושב ומקשיב להסתכל פנימה ולהגיד "וואו, הדינמיות הזאת מלהיבה אותי וזה נשמע לי בול מה שאני צריך כרגע וזה כל מה שהיה חסר לי", או "אוי ואבוי, איזה כאב ראש"-

דניאל:            לגמרי.

ליאור:            וגם לשאול פנימה מה הסימנים ביומיום, אני חושבת שזה ה-Q הכי טוב פה, מה הסימנים ביומיום, שזה פשוט כבר לא מתאים ואנחנו מאלצים על עצמנו מודל שכבר מזמן לא משרת אותנו.

דניאל:            כן.

ערן:               כאילו, לא בקטע רע, זה שאנחנו מדברים על זה עכשיו בכזאת בהירות וצחוק – אנחנו לא ראינו את זה ככה אז. כלומר, ראינו הרבה דברים טובים בטאסקפורסים, היה הרבה חשש להיפרד מהטאסקפורסים, זה לא היה… היום כשאנחנו בדומיינים אנחנו מדברים נורא באיזו נמרצות על מה היה גרוע בטאסקפורים. יש סיבה שלקח לנו כמה חודשים טובים לנהל את התהליך הזה, נכון? לא ידענו מה המודל החדש, היום אנחנו עושים את זה כזה השוואתי, נכון? החדש מול הישן. בזמנו לא ידענו מה החדש. ידענו שהטאסקפורסים יש להם חסרונות אבל יש להם גם המון המון יתרונות. מה יקרה כאילו בשיטה החדשה. אז זה קצת כזה חוכמה של עכשיו, ואני מניח שנקליט את הפרק הזה בעוד שנה ונצחק על הדומיינים.

ליאור:            אז איך באמת, בוא ניקח את זה לשאלה דניאל, איך באמת אתה מסתכל? כי באמת, טאסקפורסים הביאו אותנו, זאת אומרת, היו להם ניצחונות ברורים, כן? זה לא מבנה רנדומלי, לא דבקנו בו כי לא היו אלטרנטיבות ופעלנו בוואקום, ראינו איך זה מוביל אותנו למקומות טובים. איך אתה משחרר מזה בלי לדעת בוודאות שהמבנה הבא כאילו… ברור שכשעושים משהו חדש יש ריסק, אבל הריסק פה הוא מאוד גדול.

דניאל:            אני יכול לגשת לזה אולי מכיוון של הפחדים שהיו לנו, של מה פחדנו לאבד קצת. א' פחדנו פתאום שאנשים ישרטטו קווים מאוד ברורים בין הדומיינים ואז כאילו משהו שלא יהיה super well defined הם יגידו "זה לא שלי, זה כן שלי", ואחד מהדברים שאנחנו נורא אהבנו, שכל בעיה היא בעיה של כולם.

ערן:               משרד ממשלתי, זה באגף אה-

דניאל:            זה בבורד סקור, תלך-

ערן:               כן, דבר איתם.

דניאל:            דבר איתם וכו'. פחדנו מאוד לייצר ראייה צרה אצל אנשים, כי מאוד חשוב לנו שאנשים יראו את כל העולם ופחדנו מאוד מחוסר סינרגיה בין מאמצים. כי פתאום איך אתה, יש לך עכשיו עשרה דומיינים לצורך העניין, איך הם עובדים על פרויקטים שהם cross-domain? היה לנו הרבה שאלות לגבי המיקום, מה זה leadership של דומיין-

ליאור:            מה הכוונה?

דניאל:            נגיד היה לנו מאוד, ערן דיבר על זה קודם, היה לנו התלבטות מאוד גדולה לגבי המקום של ראש הצוות.

[00:28:00]     כי פתאום אם אתה אומר ראש צוות הוא חד-ערכי לדומיין, לפני זה ראש צוות היה מנהל אופרציה הרבה יותר גדולה. אז רגע, שנייה, אז מה זה אומר עכשיו? שאנחנו צריכים פי שניים אנשים כדי לנהל בדיוק את אותה כמות של content וכו'? הרי זה לא הגיוני ו… וגם הדברים האלה בסופו של דבר הם כולם סביב אותו פחד שאולי דומיין זה קצת לצמצם את האנשים ולהגיד להם "תקשיבו, זה העולם שלכם, תתעסקו בעולם שלכם, ה-bigger picture זה כאילו בדומיין של מישהו אחר.

ליאור:            בכלל אם כדי לנסות מבנה חדש אתה אומר שבהגדרה צריך לגייס עכשיו פי שניים אנשים זה נשמע ריסקי ולא הכיוון.

ערן:               כן, וזה גם לא מה שעשינו? רצינו לפתור את זה ורצינו בעצם להגיע למצב שאנחנו… בוא נגיד ככה, אנחנו, עם כל הזה שיש לנו מבנים מאוד מאוד מוגדרים, אנחנו מסתכלים על מבנה כעל גלגלי עזר וכל המטרה שלו היא לעזור לנו. זאת אומרת שברגע שהוא מפריע לנו אז אנחנו מנסים לשנות אותו, ויש לנו גם המון דברים שהם customized בדומיינים, גם בדומיינים לדוגמה עכשיו, יש לנו מקרים מסוימים שראש צוות, שהוא ראש צוות בוא נגיד מאוד מנוסה ובכיר, הוא מצליח להיות leadership של שני דומיינים, בסדר? ואנחנו מרגישים ששם נגיד הקסטומיזציה היא מאוד מאוד נכונה. אז גם הכללים האלה, גם בתוך המבנה של הדומיינים, נגיד היום איך שהמובייל עובד, שמובייל זה פלטפורמה שלמה בפני עצמה לעומת איך עובד דומיין שחי עם דומיינים אחרים ב-proximity ועובדים על אזורים יחסית קרובים, זה שונה לגמרי. אז אני חושב שב-bottom line אין מה לפחד… כאילו, אני הדבר שהכי מפחיד אותי זה לא להשתנות. זאת אומרת אני מאוד מאוד מפחד מזה שנהיה בסטגנציה ו… אין מה לפחד מזה.

דניאל:            אני יכול לשתף שלי היה פחד אדיר שהחזקתי מאוד חזק ובדיעבד כאילו הייתי צריך לשחרר אותו הרבה יותר מוקדם.

ליאור:            בוא נשמע, בוא נשמע.

דניאל:            שאמרתי רגע, כאילו, זה באמת complex ברמה, יש פה קונטקסט מטורף, כדאי עכשיו להחליט האם ה-security issue הזה יותר חשוב מהבאג הזה ויותר חשוב… יש פה קונטקסט מטורף כאילו שצריך לתת כלים כלפיו. וצריך פתאום שנגיד בישיבות synch שאנחנו עושים, שעד אותו רגע רק דיברו על מה הדברים החדשים שעשינו ואיך הם משפיעים על העולם וכו' – פתאום רגע, צריך לדבר על מה שאנחנו קוראים לו "מדדי חום מנוע" – איך אתה יודע שאתה לא רץ מהר מדי ונשרף, ואיך אתה מודד quality, ואיך אתה מודד craftmanship, ואיך דברים שעד היום, נגיד דיברנו על הצ'יזים האלה, כן? השיפורים הקטנים במוצר. אז היה, היה לנו בורד אחד שכל הצ'יזים היו שם. היה פורום של צ'יז שמסתכל על זה ומחליט מה צריך לעשות. פתאום רגע, מה, עושים בורד כזה לכל דומיין? איך עושים education לחברה בכלל? עכשיו מה, נהפוך את זה מסובך לכל החברה לדווח על צ'יז כי הם רק רצו להציע שיפור במוצר? אני חושב שאחד הדברים המגניבים בשינוי הזה שבעצם לקחנו את העולם… כאילו באיזשהו מקום כמו שערן אמר, היום דומיין הוא מספיק גדול ויש לו את הדינמיות של הטאסקפורסים בתוכו, ואני מאוד אוהב את זה שכל דומיין עובד בצורה אחרת, ואני מאוד אוהב את זה שבאמת אנחנו עושים קסטומיזציה של המבנה שלנו בתוך כל דומיין לגבי המאמצים שהדומיין הזה צריך לעשות. יחד עם זה שיש לנו איזו ראייה עם סטנדרטים מסוימים על איך מסתכלים על quality, על איך מסתכלים זה, ועדיין אספקטים שאנחנו מסתכלים עליהם ברמה כוללת. ואני סתם ככה אגיד עוד דוגמה אחת שהיא מעולם הפיתוח שאני חושב שהיא סופר נגיד, אני זוכר שאז היא ישבה לנו נורא כבד, נגיד יש עכשיו production incident, כן? רגע, זה משנה את כל ה-on call. כי מה עושים עכשיו ה-on call, נהיה פי עשר יותר מסובך. פעם production incident היה בן אדם אחד On call, הוא היה יודע כמעט הכול, לרוץ בכל המקומות במערכת וכולם היו קופצים איתו.

ליאור:            היום זה תלוי-דומיין.

דניאל:            היום יש דברים מסוימים שהם עדיין ברמה כללית. כאילו אם המערכת למטה אז כולם יעזבו מה שהם עושים וילכו על זה. אבל יש הרבה דברים שהם כבר ברמת דומיין, דומיין בנה לעצמו את ה-on call, כל התהליכים שלנו של טיפול בבעיות של לקוחות היו צריכים לעבור שכלולים ואלבורציות כדי שבעצם הם יישארו פשוטים לאנשים בחברה שמדווחים נגיד את הדברים. אבל בפנים יהיה dispatching ל-domains, ונראה ששום דבר לא נופל בין בכיסאות, ונראה שעדיין באיזושהי ראייה הוליסטית ה-quality של המערכת כמכלול הוא טוב. מאוד פחדנו גם לפתח Product בהמשכים כזה.

ערן:               זה גם מעלה שאלות, נכון? נגיד צריך לעשות, לתת ויזיביליות לתוך ה-quality של ה-Product. אז האם כל דומיין מייצר לעצמו מיני-מוצר שמודד את זה? האם זה משהו שהחברה במרכאות נותנת לכולם ביחד, אותו דבר לכל דבר, נכון? איך מנמהלים באגים.

ליאור:            האם יש דומיין שאחראי לתת שירותים לכל שאר הדומיינים במובן הזה.

ערן:               למשל. עכשיו, אנחנו יכולים להתחיל לדבר פה, הרי בסוף … [לא ברור] מורכב ממיליון דברים, נכון? דרישות לקוחות דניאל אמר, באגים, quality, Marketing, איך מסנכרנים את הדבר הזה. מיליון ואחת דברים. וקצת כמו, נכון שאמרנו שבאמת ה-structure מכתיב את ה-day to day, אז הוא גם מכתיב את נהלי העבודה יותר נקרא לזה הלוגיסטיים, נכון? איזה בורדים יש לנו… במאנדיי הכול מנוהל על גבי מאנדיי, אז אני לא אגיד איזה כלים מחזיקים, כי בעצם אנחנו רק מקסטים את מאנדיי מחדש. אז איזה בורדים אנחנו מחזיקים, ומה ה-flow של המידע בתוך הבורדים ו… זה מייצר בעצם נוהל עבודה חדש לגמרי. כלומר, זה לא להגיד הופה, דומיינים וסיימנו, כל השאר עכשיו צריך לעבור אדפטציה לדבר הזה.

ליאור:            מעולה, שזה באמת מוביל אותי לשאלה הבאה, בעוד שטאסקפורסים

[00:32:00]    כמו שתיארתם מאוד בנויים מהזדמנויות, אז אוקיי, צצה הזדמנות, נגיד שעשינו לה איזושהי ולידציה שהיא אכן הזדמנות – יאללה, בונים על זה כוח עבודה. זאת אומרת מאוד bottom up, נכון? פתאום כאן דומיינים נשמע כמו תהליך שטיפה… מה זה טיפה, הרבה יותר top down. איך אתה יודע להתחיל? דניאל, כאילו, איך אתה חותך את העוגה? אתם כל הזמן אומרים "העוגה גדולה, העוגה גדולה". איך מתחילים ואיך לא עושים עכשיו אובר-אנליזה אינסופית למבנה הזה ובעצם רק מזה משתתקים? כי רק עכשיו העלינו פה כמות אפשרויות אינסופית של איך לחתוך את זה.

דניאל:            אז קודם-כל מבחינת החלוקה של המוצר, אחד העקרונות שאמרנו מההתחלה זה שאנחנו לא רוצים להגיע לחלוקה מדויקת. זאת אומרת, כן חשוב לנו שתהיה חלוקה שהיא מוגדרת, אבל עדיין יהיו אזורים אפורים, ובהגדרה זה טוב שיש אזורים אפורים ואנחנו סומכים על האנשים שאם יהיה נגיד משהו שהוא נופל בין שני דומיינים, נגיד ניקח אצלנו לדוגמה, יש את הבורד, ואותו בורד בדיוק מופיע גם בדשבורדים, כן? שזה צוות אחר, זה צוות ה-insights, דומיין אחר. אז כאילו נגיד יש עכשיו בעיה. אז אנחנו מאוד מאוד רצינו להגיע למצב שגם הדומיינים מדברים ביניהם-

ליאור:            שיש חפיפות ויש חיכוכים.

דניאל:            שיש חפיפות ושיש חיכוכים. אנחנו כן מאוד רצינו שכל דומיין יהיה אוטונומי ועצמאי, אבל עדיין יש המון המון פרויקטים שאנחנו רצים ביניהם גם ביחד. נגיד היום, השבוע רץ פרויקט שאנחנו עושים אותו שארבעה דומיינים מעורבים בו ביחד. ואני חושב שזה אחד הדברים, זאת אומרת-

ליאור:            אז מוגדר ולא מדויק, זה הדבר הראשון.

דניאל:            מוגדר ולא מדויק בהגדרה מה שנקרא.

ערן:               אני גם אוסיף על זה שזה נשמע שיש לנו כזה נורא דברים מוגדים וזה – בפועל אנחנו מגדירים בצורה סבבה אני חושב את ה-high level כזה לאיפה אנחנו אולי כביכול רוצים ללכת. ומשאירים הרבה פלסטלינה בלמטה. כאילו, משרטטים קווי מסגרת ואז אומרים טוב, כולם פה ילדים גדולים, כל אחד יסתדר עם השכן שלידו. זה לא באמת הכול נוקשה ומוגדר כמו שאולי זה נשמע. אנחנו משחקים בעיקר עם המסגרות אני חושב.

דניאל:            כן. דרך אגב, המעבר הזה, הוא בדיוק מעבר מ-top down ל-bottom up. בעולם של הטאסקפורסים, היה מישהו שניהל. נגיד באה עכשיו איזושהי דרישה מלקוח שיכולה לפתוח לנו עסקה מדהימה וכו', אז הייתה איזו החלטה של איזשהו צומת מרכזי שמנהל את הדבר הזה, האם הולכים על זה, לא הולכים על זה, מי הולך ללכת על זה, על חשבון מה זה הולך לבוא וכו'. ועכשיו הדבר הזה מגיע לדומיינים.

ליאור:            החזרת את הכוח לשטח במובן הזה.

דניאל:            במאה אחוז, ואני חושב שזה גם מה שמאוד מאוד רצינו. הרגשנו… שוב, כשהיינו קטנים, כולם היו בזה ביחד. כאילו, זה באמת… כשגדלנו פתאום הרגשנו שיש איזשהו ניהול מרכזי, שזה הדבר הכי גרוע מבחינתנו, אנחנו רצינו שכל דומיין יהיה עצמאי לגמרי, יוכל לקבל החלטות, ידע למדוד את עצמו וכו'. ובמובן הזה זה היה ממש לתת את כל ה… זה היה ממש לשחרר. במובן הכי הכי משמעותי של זה. [מוזיקה]

ליאור:            דיברנו על הפחדים, דיברנו על איך מבינים. איך בפועל מתקשרים לכמות מאוד גדולה כבר של אנשים בארגון את זה שהם קמים למבנה עבודה… עוד פעם, הבנו שזה עמוק, כן?

[00:36:00]     אני חושבת שעד כאן אין מישהו שמקשיב ואומר "אה, זה עניין קוסמטי-פוליטי" – זה הולך להיות שינוי באיפה שאנשים יושבים, עם מי שהם עובדים, על מה הם חושבים. איך מתקשרים שינוי כזה?

דניאל:            אז התחלנו בלהגדיר פורום של אנשים שהוא בעצם ה-leadership של ה-Product, Dev וה-Design. ובעצם קבענו סשנים, וקבענו להם אג'נדה. הסשן הראשון היה סביב למפות את הבעיות, למפות מה אנחנו רוצים לשמר.

ערן:               אני חושב שבאמת רגע כשיו, צחוק בצד, ניגשנו לדבר הזה כמו שאנחנו ניגשים לבניית המוצר. כשאני אומר "אנחנו" זה אנשי המוצר, זה החברה. קודם-כל באמת, כתבנו על לוח מה הבעיות שלנו. ברמה הכי… כמו שאומרים מה הבעיות של לקוח? מה הבעיות שלנו, ואיפה זה כואב לנו ולמה זה כואב לנו – והתעסקנו עם הבעיות שלנו, שעכשיו כזה ירינו אותן כאילו כלום, הרבה זמן. ואני חושב שאחרי שירינו את הדבר הזה בעצם העלינו כל-מיני רעיונות למה פותר את הדברים האלה, והיה פה הרבה משחק של כזה "הנה הבעיות שלי, הנה הפתרון, האם הפתרון הזה פותר את הבעיות". בערך, אוקיי, עושים איזה אדפטציה. האם זה פותר את הבעיות? כלומר, וכשהבעיות מגודרות בצורה טובה, כמו כל דבר שאנחנו עושים, אז הפתרונות הם הרבה יותר קלים… אני לא יודע אם קלים, אבל הרבה יותר קל להסתכל עליהם ולהגיד האם מה שהצעת פותר את הבעיה המקורית שהעלית.

ליאור:            ולא להתאהב באיזה פתרון ולרוץ מהר מהר לעשות אותו.

ערן:               לגמרי.

דניאל:            אחרי זה כולם עשו digest לדברים, היה כל-מיני הצעות לפתרונות. ואז ההצעות לפתרונות היו נקודתיות והיינו צריכים קווים שמחברים, אז עשינו סשן אחד של איך אנחנו מחלקים את העבודה. בסדר? שזה היה סשן נהדר. כי פתאום ציפיות מלא דברים שעד אותו רגע לא כולם היו עליהם, חלק כן, חלק לא וכו', מיפינו את העולם-

ערן:               אני זוכר שגם היה משחקי סימולציות, נכון? ממש, כמו בזה, אמרנו אוקיי, ואם קורה כזה וכזה וכזה, איך המבנה מכיל את התרחיש הזה. אה, זה לא עובד. אה, בלה בלה בלה, צריך לשנות את זה ויפה.

ליאור:            מעולה, כמה שיותר להוריד את זה לפרקטיקה ולא להישאר ב-high level.

דניאל:            כן, להוריד את זה לפרקטיקה ודוגמאות, וגם לא לנסות לפתור הכול בסשן אחד. כלומר, לאפשר זמן בין סשן לסשן לדברים לשקוע. יש המון דברים שעושים שינוי כזה, שאתה אומר טוב, נעשה ככה וככה ואז התגובה הראשונה של כולם זה "רגע רגע רגע, עצור". אז ברגע שאתה עושה את זה איזי, ועשינו באמת במשך לדעתי ארבעה או חמשיה שבועות כל שבוע סשן של 3-4 שעות, שישבנו-

ליאור:            כן, מאוד צריך להכיל את כל ה…

דניאל:            אני זוכר אחרי הסשן הראשון שעשינו, שדיברנו על כל הבעיות, ובאמת, היה שם שיח מדהים וכזה פתוח ועם כוונות טובות ו… זה היה פשוט מדהים. וכאילו אחרי הסשן, זה עוד היה לפני שהיה לנו פתרון וזה, אבל פשוט הרגשתי הקלה כזאתי. אמרתי "טוב, זה כבר יהיה פתור, כי אנחנו מבינים את אותה בעיה." ואנחנו מסתכלים על זה… זה פעם ראשונה באותו רגע שהרגשתי שכל הצדדים מסתכלים על כל הצדדים של התמונה. וזה היה נורא כיף ו… ומשם באמת המשכנו. הגדרנו את הדברים. צריך גם להיות פה בקטע של לא להגדיר עד הסוף ולהבין שכאילו עוד יהיה שינויים ומה עקרוני ומה לא עקרוני ולהתקדם פשוט. ואז בעצם דיברנו על איך אנחנו הולכים לתקשר את זה ו-to roll out. אז מהפרטים הלוגיסטיים של מתי effectively מתחילים לעבוד ככה עד פרטים של איך אנחנו משמרים ניבול של אנשים שאנחנו רוצים שיש להם career growth ודברים כאלה, אז ניסינו להתאים את זה ככה שגם יהיה שינויים שנראים לנו הגיוניים.

ערן:               אני חושב שבסוף, כאילו, היינו בחדר כמות מסוימת של אנשים, ויש הרבה יותר אנשים שזה משפיע עליהם. ויש עוד כאילו איזה שלב בדרך לחשוב בעצם על מה כל אחד ישמע כשנציג את הדבר הזה. כלומר, אנחנו רוצים להגיד משהו אחד, לא בטוח שכולם ישמעו את אותו דבר.

ליאור:            או בהכרח בטוח שלא כולם ישמעו את אותו הדבר.

ערן:               כנראה שבהכרח לא כולם, ואז אתה אומר "אוקיי, אז בוא רגע נחשוב מה אנשים עלולים לשמוע שזה לא מה שהתכוונו"-

ליאור:            ואיך לנטרל את זה מראש.

ערן:               איך עושים לדבר הזה מיטיגציה כלשהי, איך מחדדים את הנקודות האלה. כלומר, זה לא כזה שיחה שמקשקשים אותה ויוצאים לדרך. ממש צריך לחשוב טוב מה כל אחד עלול לשמוע, מה זה יגרום לו להרגיש.

[00:40:00]     בסוף השינוי הזה הוא נורא נורא חיובי וצריך לשקף לכולם בצורה מאוד מאוד טובה את כל התהליך ואת הבעיות ואת מה שהם אולי ישמעו, לחדד בצורה מאוד טובה, לנסות להעביר את זה בצורה הכי קלה שאפשר. ואני ממש זוכר שב… הייתה את השיחה, דניאל עוד שנייה ירחיב, אבל בסוף השיחה הייתה ממש רשימה של שאלות, נכון? כמו FAQ באתר. "האם זה אומר שאני 1-2-3". ומדברים על זה. "האם זה אומר ש…" ומדברים על זה. כלומר, וזה נורא נורא חשוב, גם כי אני חושב שזה נוגע בנקודות שאולי בטעות איכשהו התפספסו במהלך ה-flow. אני חושב שזה גם משדר שהאנשים הם בפוקוס.

דניאל:            במרכז.

ערן:               רוצים שיהיה להם טוב, רוצים, איכפת, זה משדר אכפתיות. ובסוף אני חושב שזה הבסיס של הכול.

ליאור:            אולי, אני רוצה להגיד, לא יודעת אם זה הבסיס של הכול אבל זה הבסיס של כל הפחדים כשמישהו שומע על שינוי כזה. ששכחו אותו. בין אם זה ברמת ה … [לא ברור] צוות.

דניאל:            או שדברים השתנו ולא יהיו לטובה ביומיום שלו וכו', ואני חשוב שעוד משהו, שה-FAQ זה באמת, בכל שינוי ארגוני שאנחנו עושים אנחנו עושים את זה בסוף, כאילו, השאלות האלה של התכלס, אפילו ברמה הבסיסית. "אז מתי משנים מקומות ישיבה?" עוד דבר שאני חשוב שהיה נהדר ועוד חלק שחייב להיות בשיחה כזאתי, קודם-כל זה להסביר את הלמה. להתמקד ממש בלהסביר את הלמה, להגיע למצב שאנשים מבינים את הבעיה קודם-כל. לפני שמציגים את הפתרון ומהו וכו'. דבר שני זה לדבר על הדברים שבאמת מפחידים אותנו בשקיפות. זאת אומרת, נגיד היה לנו פחד מאוד שאנשים יהיה להם ראייה פתאום יותר צרה, כן? שיתפנו את זה, אמרנו את זה בצורה הכי ברורה שיש ואמרנו בדיוק מה מפחיד ואיך אנחנו נראה שזה קורה ומה הדברים שאנחנו רוצים, איזה סיגנלים נגיד הם דברים שאנחנו צריכים להיזהר מהם ולשים לב אליהם. ואני חושב שבאמת לשתף בכל המידע. זאת אומרת-

ערן:               אולי נקודה אחרונה, שזה לא done deal. כלומר זה לא התנ"ך, אף אחד לא ירד עם ספר הפתרונות משום מקום. זה קונספט ראשוני, שהיה בהתהוות. הוא נראה יש בו מלא חורים שלא חשבנו עליהם. בסוף צריך שכולם יירתמו לדבר הזה וימצאו את החורים ביחד, כדי לפתור אותם, לא כדי להגיד "הנה, יש פה חור." אנחנו לא עובדים ככה, אנחנו… זה למה ה"למה" הוא נורא חשוב. כי כנראה שהפתרון יש בו טעויות, בסדר? כמו כל דבר שאנחנו עושים בחברה הזאת. אבל אם כולם מבחינים את ה"למה" אז כולם ביחד פותרים את הטעויות האלה שלא שמו לב אליהן.

ליאור:            כן, וזה גם בעצם לשחזר את התהליך שעשיתם אתם בתור ה-leadership, כי כשאתה אומר דניאל שברגע שהבנתם שהבעיות הן משהו שכולם חולקים, הייתה איזו רגיעה, הייתה הבנה שכולם רוצים את אותו הדבר ועכשיו רק צריך להבין מה זה הדבר הזה. אז אם אתה מתחיל מה"למה" כולם מבינים שכולם מיוצגים כאן, ה-design, ה-R&D, ה-Product, אני זוכרת שזו שיחה שבאמת עשיתם כולכם ביחד והובלה ע"י אנשים שונים מכל אחד מהאזורים האלה באמת כדי שזה יהיה מאוד מאוזן.

דניאל:            וגם דרך אגב, היה לנו שקף שאומר בדיוק מה הדברים שלא סגורים. כאילו, המון המון דברים, והוא היה ענק. מלא דברים-

ליאור:            הוא היה ארוך, נכון.

דניאל:            ומתוך כוונה להגיד בדיוק את מה שערן אמר. כאילו, אין צורך להגדיר עד הסוף, הכול זה, אנחנו נבין את זה תוך-כדי.

ערן:               דרך אגב, תקן אותי אם אני טועה, עד היום מעולם לא חזרנו לשקף ההוא ועדכנו את ההגדרות. הדברים כאילו הסתדרו.

דניאל:            כי המהות הייתה שם ואנשים כבר לקחו את זה.

ערן:               כן, הדברים הסתדרו, ואנשים פתרו את זה ברמתם, ומעולם לא אמרנו "טוב, עכשיו חוזרים לשקף הלא סגור ואומרים מה קורה בכל נקודה", כאילו, סבבה, אינרציה חיובית בוא נקרא לזה. אנשים קיבלו, הבינו, פתרו, אמרנו.

ליאור:            מה שבאמת מוביל אותי לשאלה הבאה ואולי האחרונה לפני שנסגור את הפרק, זה איך יודעים שזה עובד, כן? האם היו דברים, כאלה נורות אדומות, גבולות שאמרתם אם נגיע לשם זה סימן שזה נשבר, שזה לא עובד? והאם היו דברים שהגדרתם שאמרתם כשנראה את זה נדע שהכול דופק?

ערן:               התשובה היא שאי אפשר לדעת. אפשר לראות את הבעיות, אפשר לחשוב שנתת פתרון. אני חושב שאם זה לא היה עובד היית יודע. ואם אתה לא מרגיש משהו לא נוח באופן קבוע אז כנראה שזה עובד,

[00:44:00]    גם אם אולי יש דרך יותר טובה לעשות את זה, אבל הפתרון כרגע עובד.

דניאל:            אני גם חושב שזה תהליך שהוא לא flip the switch וממחר כאילו דומיינים, אלא יש פה המון המון דברים. נגיד סתם, היה דוגמה נהדרת, שזה היה שונה בדומיינים שונים, דומיינים מסוימים לקחו את השינוי הזה, עשו אותו מייד. דומיינים אחרים היו צריכים יותר הכוונה ויותר עזרה, דומיינים מסוימים היינו צריכים לדבר איתם על skill set חדש שצריך לבנות בתוך הדומיין, ואת כל הכלים שלנו לעדכן. את כל הדשבורדים שלנו, את כל הפרוססים שלנו. נגיד סתם, אני אתן איזו אנקדוטה אחת, אבל לדעתי משקפת את זה ממש טוב. אמרנו טוב, עכשיו צריך לקחת את התהליך של הבאגים, של איך מטפלים בו, שהוא היה centralized, ומה עושים איתו עכשיו. אז שני אנשים, אורון ואורון, ראש צוות פיתוח ואחד מאנשי ה-Product שלנו, פתאום פעם ראשונה התמודדו עם השאלה הזאת. הדבר הראשון שהם עשו זה לעבור על כל הבאגים. תחשבו, עד אותו רגע-

ליאור:            לא היה אדם שעבר על כל הבאגים.

דניאל:            היה כאילו מעט מאוד אנשים שהכילו את התמונה הזאת בראש והתחילו לבנות את זה, בסדר? ולפרק את זה לבורדים, ולחשוב על צורה כזאתי, דיווח כזה ומעבר כזה ואיך אנחנו יודעים שזה לא מתפספס ואיך אנחנו מודיעים לאנשים שמטפלים בדברים שלהם, כי זה פתאום מיליון אנשים. מה שאני מנסה לומר זה שזה באמת שינוי שהוא מאוד מאוד רחב, משפיע על המון המון דברים. ואני חושב שעשינו אותו gradual, תוך-כדי training של דברים. בהתחלה היה הרבה דברים שלא עבדו טוב. אני חושב שגם יש בעיות שפתרנו אחרי זה באמצעות adjustments על המבנה הזה.

ליאור:            תן דוגמה.

דניאל:            דוגמה נהדרת זה ה-performance נגיד של המערכת, שאני חושב שהבנו שזה אתגר עומק, הבנו… נגיד המהירות של הגלילה של הבורד, בסדר? זה-

ערן:               אולי גם רגע נחדד את זה. אמרנו שכל דומיין מחזיק בתוכו גם את ה-performance. עכשיו, אתה יכול לבנות דברים טוב, אבל performance הוא עולם תוכן בפני עצמו. זה אני חושב החידוד.

דניאל:            כן, בוא נגיד ככה, הבנו שיש בעיות מסוימות בדומיינים שהם לא יוכלו להכיל כרגע, כי הן דורשות מומחיות מאוד מאוד מסוימת והן דורשות פוקוס מאוד מאוד גדול והבעיה עצמה אם נתמודד איתה לא נעשה שום דבר אחר בדומיין. וכתוצאה מזה הקמנו עוד צוותים. נגיד במקרה הזה יש לו צוות שנקרא client foundations. שאחד מהדברים שלו, באמת אחד מה-goals שלו זה לראות איך הוא פותר בעיות עומק כאלה, עם מומחיות ועם זה שהם, זה אנשים שהם מאוד מאוד חזקים בדברים האלה ונמצאים על זה כל הזמן. וזה נכון גם להרבה דברים שהם בכלל מאמצים רוחביים שאתה רוצה לעשות. נגיד עכשיו אתה רוצה להכניס סטנדרט חדש או אתה רוצה לעשות, לשדרג, סתם אני אומר, את ה-framework שאיתו אתה עובד. צריך לעשות שינויים בכל הדומיינים. אז איך אתה מוביל כזה דבר וכו' ו-

ליאור:            איך אתה מוביל כזה דבר?

דניאל:            אז נגיד במקרה הזה באמת הצוותים הרוחביים הם צוותים שביחד עם הדומיינים הם עוזרים לקואורדינציה והם עוזרים לתת את ה-vision הזה.

ליאור:            אבל הם אנשים שיושבים בדומיין אחר או הם פשוט אנשים שצפים מעל דומיינים?

דניאל:            אז אני חושב שאחד הפיצוחים שלנו, שבניגוד לנגיד גילדות, שהן הרבה פעמים גוף מייעץ, אז אצלנו הצוות הזה של ה-client foundation, ויש לנו צוות כזה גם של ה-server foundation, זה צוות גם שהוא עומד בפני עצמו. כלומר, יש לו אנשים. אני חושב שזה מה שעשינו שונה בצורה מאוד מאוד משמעותית. וחלק מה-framework שאנחנו מגדירים ועד היום אנחנו עובדים על זה, זה איך אנשים בצוותים האלה עובדים ביחד עם האנשים בצוותים בדומיין ואיך מנחילים פרויקטים ארוכי טווח וכו' וכו'. ואני חושב שככל שעובר הזמן זה נעשה גם יותר ברור וגם יותר ברור ומצליחים באמת להניע דברים ב-scale ענק, שזה כיף גדול לראות את זה.

ליאור:            אמרת קודם שאנחנו בנקודת הזמן הנוכחית כבר יודעים להגיד שדברים נשברים לנו. אז אם אתה יכול ככה לדבר על העתיד. דווקא לא על מה שנשבר כרגע – מה אנחנו מזהים, מה השאלות הפתוחות שכרגע יש על הפרק.

ערן:               אז אני חושב שכשהתחלנו את הפרק, נכון דיברנו על זה שכבר הגענו לאיזו נקודת רתיחה. שחייבים לעשות שינוי.

ליאור:            עם הטאסקפורסים.

ערן:               עם הטאסקפורסים. אז היום אנחנו עוד לא בנקודת רתיחה. אבל אנחנו גם מתחילים להרגיש את הכאבים החדשים של הדבר הזה. נכון, דניאל נתן דוגמה אחת. של איך מנהלים תהליך רוחבי, את זאתי פתרנו. אבל הליכים רוחביים כאלה שדורשים הרבה דומיינים וזה, הם מתחילים להיות טיפה יותר קשים לצורך העניין.

[00:48:00]     ואנחנו מתחילים להרגיש כל-מיני כאבים במודל החדש, שהם לא אומרים לנו תשנו משהו מחר בבוקר, אבל הם כן אומרים לנו בואו תתחילו להיות במודעות, וכשמתחילים לרתוח בוא נתחיל להניע את התהליך הזה. ובתחושה שלי, וזה נראה לי סובייקטיבי… עכשיו, אין בעיה לחכות להגיע לנקודת רתיחה, בסדר? לא חייבים להקדים את הרתיחה. כי אם אתה מקדים אותה אז אתה לא באמת מבין את הכאבים עד הסוף, אתה חושב שאתה אולי מתחיל להבין. ואני חושב שזה בסדר שיש דברים שהיום הם מתחילים להיות אולי קצת טיפה חורקים, טיפה לא יותר קשים. ואנחנו יכולים להמשיך לרתוח איתם, להבין אותם יותר לעומק, ואני לא יודע מה יהיה בעתיד. אנחנו נצטרך לחשוב מחדש.

דניאל:            כן, הקטע של ה-premature optimization הוא מטורף וצריך מאוד להיזהר מזה גם לטעמי. כשאנחנו עברנו לדומיינים נגיד, אחד הכאבים פתאום שהיה לנו זה שהיינו צריכים הרבה יותר אנשים בכל דומיין. ולקח לנו זמן להגיע לשיווי משקל שם. ואם היינו עושים את זה יותר מוקדם זה פשוט היה קורס השיטה לתוך עצמה, כאילו, לא היינו… אז אני חושב שאני מאוד מתחבר לדברים. ובאמת, אין פתרון אחד במבנה שמתאים להכול. מבנה זה משהו שהוא customized, שצריך בכל נקודת זמן להבין מה אנחנו רוצים. וגם לא צריך לנסות לייצר איזשהו template ולהחיל אותו על כל הארגון. אני חושב שאחד הדברים שאנחנו מאוד מאוד אוהבים ומבינים היום זה שצריכים להיות לנו המון המון סוגים של שרירים, והמון המון סוגים של מבנה. ושיש שונות מסוימת בצוותים שהיא נהדרת והיא עוזרת. וצריכים צוותים מכל-מיני סוגים על כל-מיני מאמצים, וזהו, זה כזה…

ליאור:            סיכום שלך.

דניאל:            סיכום, כן.

ליאור:            אני אוסיף שני דברים. אחד שככה באמת נעצתי בהם במהלך הפרק. שכשמשהו שאתה מאוד מאוד יודע להסביר לעצמך למה הוא עבד לך ולמה הוא טוב לך פשוט מפסיק לעבוד לך – זה סימן שצריך להסתכל על זה, כן? לא צריך להתעלם מזה. כשיתרון הופך לחיסרון. והדבר השני המאוד מעניין שאמרתם וככה שווה לסגור איתו את הפרק זה באמת העניין הזה של הכוונות הטובות. שניכם דיברתם על זה וזה חשוב לעצור בעיניי להתעכב על זה, כי בארגון, כשיש הרבה אנשים ומחלקות וצוותים, קל לחשוב שמישהו פה התבלבל, כן? אבל דווקא כשמבינים וזוכרים שלכולם יש את אותן כוונות, כולם באים לדחוף את אותן המטרות ולנצח, וכשמישהו מתנהג או משהו מתנהג בחריקה או בצרימה מה-pattern הזה כנראה שזה לא הבן אדם שהתבלבל, כנראה שהשיטה שמה צריך להסתכל עליה מחדש.

ערן:               האמת זה מצחיק שאת אומרת את זה, אבל כשאני חושב על זה, אם יושבים שלושה אנשים שונים וכולם רוצים את אותה מטרה אבל איכשהו זה לא מתחבר להם, כאילו הם רוצים את אותה מטרה אבל כל אחד בא לזה בזווית אחרת ויש איזה מין דיסוננס בין הרצון לבין הפרקטיקה, אולי – לא תמיד, אבל אולי זה סימן שהמבנה קצת, או משהו מקשה עליהם.

ליאור:            צריך להסתכל עליו לעומק.

ערן:               צריך להסתכל עליו.

ליאור:            אני אגיד רגע אפרופו קיר שאלות המשך, שאם יש מישהו שרוצה להבין יותר טוב משהו על השינוי, על עבודה בטאסקפורסים, על עבודה בדומיינים, אז גם הפט וגם דניאל יותר מישמחו לענות. אתם יכולים למצוא אותנו בקבוצת הפייסבוק שלנו ובאתר. ותודה הפט.

ערן:               תודה ליאור.

ליאור:            תודה דניאל.

דניאל:            תודה.

ליאור:            אם הייתם יודעים כמה זמן הפרק הזה מתוכנן הייתם מבינים את הערך של התודה [צוחקת]. ותודה שהאזנתם. [מוזיקה]