484 Architect WTF with Shai Yallin and Ron Klein

רברס עם פלטפורמה

[קישור לקובץ mp3]

פרק 484 (מספר יפה!) של רברס עם פלטפורמה, שהוקלט ב-20 בנובמבר 2024. אורי ורן מארחים באולפן בכרכור את שי ילין ואת רון קליין לשיחה על מגדלי שן (מבחינה ארכיטקטונית).

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

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

[בפרקים הקודמים - 469 Software development in early stage startups with Shai Yallin

478 with Haim Yadid, Software in young startups]

01:05 שי ורון

(רן) אז קודם כל - ספרו קצת על עצמכם. שי, בבקשה . . .

(אורי) בפינה השמאלית, ארכיטקט הניצחון . . . .

• (שי) האמת שאני לא מגדיר את עצמי כארכיטקט . . . . אני שי, אני עצמאי בתחום הנדסת התוכנה.
• לפעמים אני מכנה את עצמי “Fractional Principal Engineer”, או “Principal as a Service”.
• אני מתעסק באיך מהנדסים תוכנה - איך בונים ארגונים ומערכות שקל לעשות להן שינויים, בכל מיני Level-ים של חברות.
• יש לי לקוחות שהם חברות ממש אחרי Seed או אפילו לפני Seed ויש לי חברות שהן כבר אחרי Round E
• וכל מיני דברים באמצע ביניהם.

(רן) וזו לא ההופעה הראשונה שלך פה בפודקאסט . . . . אז מוזמנים לבוא ולהקשיב לפרק הקודם עם שי, שאני כרגע לא זוכר את מספרו [469! הנה שוב - 469 Software development in early stage startups with Shai Yallin, יש שם גם הפניות להרצאות בכנסי רברסים לאורך השנים].

רון!

• (רון) היי, Nice to be here, נתחיל מזה.

(רן) מאזין מפרק אחד!

• (רון) אכן! כשעוד היו קצת תקלות עם האודיו וה-Level של הווליום ודברים כאלה . . .

(אורי) השתפרנו מאז . . .

• (רון) בתחום פיתוח התוכנה - אני לא יודע, 20 שנה + בקטע הזה של “לפרנסתי”
• עוד לפני זה גם היה תחביב.
• בעשר השנים האחרונות אני בתפקידי Tech Leadership ב-Scope-ים ופורמטים שונים.
• יצא לי גם להיות Tech Lead ו-Staff Engineer ובTitle-ים ב-Corporates סטייל ב-eBay וב-Semi-Garage Startups - וכל מיני In-Betweens יצא לי גם לעשות בעשור-פלוס האחרון.

(רן) וכיום אתה . . . .

• (רון) כיום אני ארכיטקט - “ארכיטקט הפלטפורמה”, אפרופו רברס עם פלטפורמה - בחברת Elementor.
• זו חברה שמייצרת הרבה מאוד כלים ל-Web Creators, שזה Title מאוד מגוון, Fluid-י כמעט כמו “ארכיטקט” . . . .
• ובגדול זה אומר שבעבר, כדי לבנות אתר אינטרנט, היינו ככה פונים לאיזה “איש מקצוע” - היום זה הרבה הרבה יותר מורכב.
• ו-Elementor נותנת מענה להרבה מאוד בעיות או Pain Points בכל ה-Life cycle של Websites
• מהתכנון עד ההרצה, Growth, Payments - כל הדברים האלה, Elementor נותנת להם מענה.

(רן) כלומר, רכיבים שאפשר להשתמש בהם בפלטפורמות שונות?

• (רון) לגמרי.

(רן) מעולה, אז Web זה כיף . . . .

• (רון) Web זה Fun-Fun-Fun, זה כן . . . .

03:55 “ארכיטקט”? !There's No Such Thing As A Gruffalo

(רן) אז סיפרתם לנו קצת לפני הקלטה, שבעצם הרעיון לפרק הזה התחיל מאיזושהי שיחה, שאתה ושי דיברתם - ואתה אמרת “אני ארכיטקט!” ושי אמר “אין דבר כזה!” . . . פחות או יותר, אני קצת אולי מתמלל את זה אחרת.

אז מה זה בעצם “ארכיטקט”? בוא נשפוך את זה, בוא נפתח את זה כבר עכשיו - מה בתפקיד? מה זה ארכיטקט?

האם יש דבר כזה? האם צריך דבר כזה?

(אורי) אני לא הייתי שואל מה בתפקיד - אני שואל מה בתפריט? . . . כי מהצד אחד, אתה יכול להגיד “אין דבר כזה?” ומצד שני, זה יכול להיות כל כך הרבה דברים. אז יאללה - המיקרופון שלכם.

• (רון) אז אני רוצה רגע לתת ככה מענה, תשובה.
• אני באמת חושב שזה פחות ה-Title ויותר באמת המהות או התפקיד עצמו, או תחומי האחריות.
• בעיניי, ארכיטקט - יש לו כמה כובעים.
• הוא, מבחינת ה-Leadership, זה כובע משמעותי - הוא צריך להיות “מגדלור” כזה, של מצוינות טכנית ו-Seniority טכנולוגי.
• בנוסף לזה, הייתי אומר שהוא גם אמור לא להיות “היחיד” - כלומר, הוא אמור להעלות את הרף, וליצור סביבו את ה-Next Generation של ארכיטקטים או Tech Leaders בארגון, ב-Scope-ים שונים.
• להיות ה . . . נקרא לזה “בן אדם שאיתו מתייעצים” ויחד איתו מקבלים החלטות שיש להן משמעות מאוד גדולה Moving Forward.
• כלומר אי אפשר - או שיהיה מאוד קשה - To roll back, לקחת את הצעד הפוך ולשנות את ההחלטה.
• וזה בדרך כלל החלטות בתחום הטכני-טכנולוגי, פחות החלטות מוצריות Pre-se.

(רן) כלומר, אז דיברת על העניין של מצוינות - אבל בוא אני אתריס: האם צריך לעבור דרכך דרך כל Code Review, דרך כל Design Review? לקבל אישורים ו”סטמפה” כדי לשחרר פיצ'רים?

• (שי) . . . . ”בשלושה עותקים!” . . .

(רן) האם אתה ה-Gatekeeper?

• (רון) אז שאלה טובה . . . . ולדעתי, יש כאן, כאילו, כמו כל ארכיטקט אני אגיד “זה תלוי . . .. “.
• אני חושב שדבר ראשון, יש כאן פונקציה מאוד משמעותית של Seniority ו-Engineering Level בארגון.
• ואני חושב שהשאלה שאתה שואל, אם ירושה לי לנסח אותה בדרך אחרת, זה עד כמה הארגון מעוניין להיות ב-DNA שלו Centralized לעומת Decentralized.
• כלומר, כמה חופש או מה דרגת-החופש שאנחנו מעוניינים לתת לEngineering Teams או ל-Silo-ים השונים מצד אחד, לעומת . . .
• מצד אחד בסקלה זה “אוטונומיה מוחלטת” - כל אחד שיחליט על הכלים הטכניים שלו וכו’.
• ומצד שני, יש לך את מה שכרגע התרסת - הכל עובר ומתנקז דרך איזושהי פונקציה אחת בארגון - “הארכיטקט!”
• ועל פיו ישק דבר, ומה שהוא מאשר הוא מאשר, ומה שלא - לא.
• אני לא חושב שזה . . . לא חושב שיש כאן תשובה אחת נחרצת.
• אני חושב שזה מאוד מאוד מבטא את ה-DNA הארגוני, בכללי.

(רן) כן, בסדר. יצא לך, דרך אגב, לעבוד במקום שבו באמת היה ה-DNA כזה ריכוזי, ואתה או אולי מישהו אחר היה בתפקיד הארכיטקט והיה ה-Gatekeeper של כל הפיצ'רים?

• (רון) כש . . . בלי להגיד שמות, במקום שבו ה-Engineering Level היה יחסית נקרא לזה “פחות מהממוצע”, היה לי סוג של Carte blanche
• קיבלתי גיבוי מוחלט - “רון, קח אותנו קדימה, קח אותנו ל-Next Level!”.
• ובאמת לא הייתה ברירה - עשינו הרבה הכשרות פנימיות, כדי לייצר איזשהו Baseline, שמשם ואילך כבר היה יותר קל לתת לכל צוות לנוע בקצב שלו, לתת את האוטונומיה.
• אבל בהתחלה, זה היה שלב כזה של “אוקיי, הרבה מאוד דברים עוברים דרכי”
• הרבה מאוד דברים - נקרא לזה “כל מיני Design Reviews” - עוברים דרכי וכו’.

08:30 עניין של מורכבות

(רן) אוקיי, אז דיברנו על העניין הזה של מצוינות ואולי, ככה, “להראות את הדרך” וכל זה.

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

כל מיני דברים.

(אורי) לפעמים יש גם . . . אתה נגעת ב-Debugging, אבל יש “בעיות שרק הארכיטקט יכול לפתור”. כאילו, משהו באיזה Monolith כזה, ש”להכניס את היד ואתה לא יודע איזה נחש ינשך אותך” . . . .

• (רון) . . . . או שמה שאתה מוציא הוא . . . אתה חושב שזה מתחיל באיזה “צ'ופצ'יק קטן”, ולאט לאט אתה מגלה כמה זה מתחבר לעוד סבך מאוד גדול של דברים.
• (שי) אני חושב שאם יורשה לי, יש פה נקודה מאוד מעניינת . . . שבעצם, ה-Role או הצורך הארגוני הוא לא בהכרח ב-Gate-Keeping.
• אני חושב שGate-Keeping זה “שריר” שצריך להיול מסוגלים להפעיל בנקודות מסוימות, ברגעים מסוימים.
• כמו שרון אמר - זה לא דיכוטומי.
• אבל יותר מזה - אני חושב שהארכיטקט זה Variant אחד של איזשהו קונספט יותר רחב, יותר גדול, שבתוכו ישבים גם דברים כמו Principal Engineer או Fellows, כל “הגווארדיה היותר בשלה ומנוסה” שיש בארגון.
• כי באמת, יש מקומות שזה יכול להיות או “ה-Monolith הישן”, או שהמערכת כל כך גדולה, שקשה, כאילו, To Grok the entire thing.
• קשה להכניס את כל המערכת לראש של בן אדם אחד, ואז יש צורך שיהיה בארגון אדם אחד - או כמות של אנשים - שהם אלה שרואים את המערכת “ממעוף הציפור”.
• אבל - שגם יכולה להיות להם יכולת לעשות Zoom-In או Drill-Down איפה שצריך, כדי להיות מסוגלים לדבר גם בשפה שהיא High Level וגם בשפה שהיא Low Level.
• גם בשפה שהיא כללית - כל המערכת - וגם בשפה של Silo ספציפי, Pod ספציפי, מוצר או קו-מוצרים ספציפי.

10:52 רגע, מה ההבדל?

(רן) אז מה, הזכרת “Principal” וכו’ ו-Title-ים אחרים, ולא יודע אם כולם או כל מי שמקשיב לפודקאסט בהכרח מכיר. זה משהו שמקובל בחברות יותר גדולות, שיש בהן Level-ים שונים ל-ICs.

אבל נשאלת השאלה, ככה בגדול - אז מה ההבדל בין Principal או Distinguished או Fellow Engineer כלשהו לבין ארכיטקט? האם יש הבדל ואם כן - מהו או מה הוא צריך להיות, לדעתכם?

• (רון) אני אקח את זה רגע מהצד שלי - אני חושב שזה Title-ים שונים שמייצרים סולם של Tech Leadership, של IC טכני, פשוט עם Scope - עם היקף-פעילות או “Level של מעוף ציפור” יותר ויותר גבוה.
• אני חושב שנדרש מתפקידים “נמוכים” יותר להיות הרבה יותר פעילים ב . . . נקרא לזה ב”Component Level” או ברמת ה-Design הפנימי של תת-מערכת כזו או אחרת.
• ככל שעולים בסולם הדרגות של ה-IC, הכוונה היא להוביל - להיות ה-Focal Point הטכני או הארכיטקטוני, אם נרצה.
• במערכת שהיא כבר יותר Cross-Teams או Cross-Siloes או Whatever.
• וככל שעולים למעלה; יש כנראה גם יותר ויותר מקום לחזון או לכיוון ההתקדמות הטכני-טכנולוגי של הארגון
• הנושא הזה של “האם צריך להחליף שפה?” או, לא יודע - “האם אנחנו רוצים להמשיך להשתמש בכלי הטכנולוגי הזה או אנחנו רוצים לבחון אלטרנטיבות אחרות?”
• וככל שהארגון גדול יותר - ושוב, זה מאוד מאוד פונקציה של גודל הארגון, ה-Dev.
• ככל שהארגון גדול יותר, ככה יש לדרגות הגבוהות יותר יותר מקום.
• ויכול להיות שבארגונים קטנים - זה . . . אפרופו, יכול להיות שבארגונים קטנים, נגיד פחות ממאה מפתחים - אולי לא חייבים שם ארכיטקט או משהו כזה.
• זה יכול להיות באמת איזה משהו שהוא מקביל ל-Principal או משהו דומה, זה לא חייב להיות אחד.
• והם עושים עבודה מצוינת.

(רן) כמה אתם אצלכם בארגון, בפיתוח?

• (רון) ב-Elementor מעל מאה איש בפיתוח, World-wide.

(רן) אוקיי, יש גם CTO?

• (רון) יש, יש . . .

(רן) ואיך החלוקה ביניכם, בינך ובינו?

• (רון) הוא באמת נמצא במקום . . . הוא CTO שהוא גם Co-Founder, והוא נמצא במקום הרבה יותר של “לנווט

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

13:52 ארכיטקט זה המטבע-קריפטו החדש (ישן)?

(אורי) אני רוצה להגיד משהו, קצת, לא יודע - “דרסטי” פה: זה מטבע, הדבר הזה שנקרא “ארכיטקט”. זה בעיקר “חי ב-LinkedIn”. זה סוג של Crypto שחי . . . .

(רן) . . . היום Crypto הולך טוב . . .

(אורי) . . . כן, ה-Bitcoin . . . “עלה דווקא שער הארכיטקט” . . . אבל זה סוג של “מטבע וירטואלי”. בכל חברה זה אומר משהו אחר לגמרי, כמו גם ה-Principal וה-Fellow, זה בכל . . .. זה משהו שאתה יכול לשים ב-LinkedIn שלך, זה לא אומר שום דבר על התפקיד שלך בחברה.

בהרבה מקרים משלמים לך במטבע הזה, “סוג של קידום”, אוקיי? זה לא אומר כלום, נגיד, על השכר שלך.

ואני יכול להגיד שהרבה פעמים, בשלב מסוים מצאנו את עצמנו שזה מה שאנחנו עושים. אם מישהו לא מתקדם כי אין לו שום סולם קידום בחברה כ-IC - “תיהיה ארכיטקט!”. הוא יכול לכתוב את זה ב-LinkedIn, הכל בסדר.

בהרבה חברות, הסולם-קידום היחיד שבעצם יש להן זה בעצם רק בציר ניהולי, אז ב-IC אומרים “קח את הארכיטקט ותעזוב אותנו בשקט” . . . .

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

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

(רן) אורי, אתה זוכר באיזה שלב אתם עשיתם? כמה הייתם אז בארגון לפיתוח כש...

(אורי) מאוחר . . .

(רן) כמה? - מאות?

(אורי) כמה מאות.

(רן) מאות אנשים. . . ואצלכם, רון, יש כבר Leveling כזה?

• (רון) יש “התהוות” של הגדרת התפקיד שנקראת Tech Lead.
• בחברות קודמות שעבדתי בהן, זה היה הרבה יותר מסודר.
• הן כבר עברו את שלב ה-Incubation של הגדרות התפקיד, של ה-Level-ים.
• ואני חושב ש . . . אני כאילו קצת נותן לך פינג-פונג מהכיוון ההפוך - אין לך איזושהי “רגולציה” שאומרת רוחבית “Principal זה ככה!”
• בכל חברה Principal מוגדר X, או Staff Engineer מוגדר ככה, או Tech Lead, או Whatever.

(אורי) מהבחינה הזאת, אמרנו בגדול לאנשים - “שימו מה שאתם רוצים ב-LinkedIn - מבחינתי אתה Level 6”.

• (רון) אוקיי, אבל מה שאתה אומר - ואני מאוד מסכים - זה שיש הגדרה . . .

(אורי) “מבחינתי אתה Level 6 - וזו ההגדרה של ה-Expectations שלי מה-Level”.

• (רון) אבל למה אנחנו . . . אוקיי, למה ה-Title חשוב כאן? אני יכול להגדיר את עצמי כ”שרברב תוכנה”. אני פותח סתימות . . .

(אורי) אגב - זה מה שאתה עושה, כן? אבל... כאילו, כולנו בעולם התוכנה . . .

• (רון) לא המצאתי את זה, אני כבר ראיתי את זה.

(רן) אנחנו קודם מחביאים אותן טוב-טוב, את הסתימות . . . שמים את החומר - ואז פותחים!

• (רון) כן, בדיוק. אבל מה זה משנה ה-Title?

(אורי) אז בגלל זה אני אומר - זה לא כל כך משנה. מה שמשנה זה . . . אני רק יכול להגיד, נגיד ספציפית לארכיטקט, שאמנם היה את הסיפור שאני מספר בסוף, הוא עניין של “כאילו Title”, אבל בנקודה מסוימת, אנחנו רצינו להתחיל גילדות . . . . [הנה, כאן - 367 Guilds at Outbrain]

• (רון) או, הנה - שי נדלק . . .

(אורי) כן, כן . . . ובעצם אמרנו שאנחנו מחפשים מישהו שיוביל את הדבר הזה שנקרא “גילדות”.

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

תכל’ס אמרנו לו “סבבה” - והרווחנו את שניהם באמת ביחד.

וזה יצא מאוד מאוד טוב שמי שנגיד “קובע את הסטנדרטים” של הארכיטקטורה ושל איך שהקומפונננטות (Components) מדברות אחד עם השני ובאיזה פרוטוקולים - הוא גם זה שמצד אחד דואג שהתשתית תיבנה לזה, ומצד שני גם מלמד את האנשים איך זה עובד ואיך צריך לעבוד - והגילדה היא בעצם “הזרוע החינוכית” של הארכיטקט. וזה יצא פגז.

19:45 ה-Title וחותם המלך

• (שי) זה מהמם, זה מהמם . . . אני רוצה להתייחס רגע לסיפור של Title. Title, זה בעיניי זה לא-“לא חשוב”. מכמה סיבות.
• הראשונה היא שאוקיי - אנחנו יודעים שה-Title הוא Meaningless וגם ה-Founder-ים יודעים שה-Title הוא Meaningless.
• אבל כל מיני מנהלי-ביניים, שלא בהכרח מכירים אותי, ואני בא ואני אומר להם “חבר'ה תקשיבו - הרעיון שלכם למוצר, הוא יכול לעבוד ככה ב-Micro, בתוך המוצר הניסיוני הזה שאתם עכשיו מריצים ב-Pod שלכם”
• “אבל אתם חייבים לחשוב גם על שאר הארגון” - על איך “האדוות” שאתם יוצרים ישפיעו ויפגעו במוצרים אחרים, ב-Pod-ים אחרים.
• ואם זה מגיע מתוך IC שאין לו Title - זה יכול להיתפש אחרת, מאשר אם זה מגיע מתוך IC שיש לו Title שנשמע יותר “מפוצץ”.
• אני לא אוהב את זה, זה לא כאילו . . . זה לא “כיף לי” שזה המצב - אבל בהרבה מקומות, זה המצב.
• אז כדי שיקחו אותך ברצינות, כדמות שיש לה “השפעה בלי סמכות”, לפעמים כן צריך לתת - לא בהכרח סמכות ניהולית “עם שיניים”, אבל כן איזשהו Title-ון כזה או משהו.
• שעוזר לאנשים שעדיין לא מבינים בדיוק מי אתה בתוך הארגון - אולי כי הם חדשים, אולי כי לא אכפת להם . . .

(אורי) או שהארגון הוא מאוד גדול - והקשרים שאתה צריך לייצר או ה-Interface-ים שאתה צריך לייצר, הם מעבר לרמת ההיכרות האישית. כי אני מכיר את רון, אני יודע שהוא “אייס”, בסדר? ושיש לו פה . . . “הוא כתב חצי מהמערכת”.

אז כאילו, ברגע שהארגון גדול מעבר לזה - יכול להיות שאתה צריך לבוא גם עם איזשהו Title.

אני לא יודע, אתה [רן] עבדת ב-Google - זה היה שם ככה?

(רן) קודם כל, ה-Google שבה עבדתי וה-Google של היום הן כנראה מאוד מאוד שונות . . .

(אורי) לא, אבל גם ה-Google שבה עבדת הייתה כבר גדולה, עם Interface-ים . . .

(רן) הבת שלי, שנולדה כשהייתי שם - היום היא בת 16 . . . אז עבר הרבה זמן. אבל כן, ללא ספק - כמעט בכל חברה גדולה, במיוחד שזה ככה, “Across the Ocean” ובאנגלית וכל זה, כן, יש - הTitle עוזר. זאת אומרת, תמיד יש אנומליות, אבל זה לגמרי יכול לעזור. זה קצת מזכיר לי שבימי-הביניים היית מסתובב עם “החותמת של המלך” - אף אחד לא היה מכיר אותך, אבל אם היית מציג את החותמת של המלך, אז אוקיי, סבבה, “הבנו מי שמך”. אתה לא בהכרח את הבן אדם הכי טוב, אתה לא בהכרח הכי חכם - אבל מישהו סומך עליך וזה המלך, וזה בסדר, אנחנו צריכים לעשות מה שתגיד,

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

זה לא אותו דבר, זאת אומרת - אותו אחד שיודע לעשות Low-Level Debugging או High-Level Architecture זה לא בהכרח אותו אחד שיסחוב אחריו אנשים לתוך גילדות ולשינוי של מבנה וכל זה . . .

(אורי) אז אחד הדברים שבנינו, כשבנינו את ה-Leveling של ה-ICs, אז אחד הקריטריונים שהולכים ותופסים יותר מקום ככל שאתה עולה ב-Level, זה היכולת-הובלה שלך - היכולת השפעה שלך על אנשים.

• (שי) אבל זה גם בדיוק מה שאמרתי קודם לגבי ה-ICs, מבחינת Level-ים בתוך ארגון.
• הקריטריונים - מה שאתה אומר ה-Expectations, “הציפיות המוגדרות היטב” - מתייחסות גם להיקף של הפרויקטים שהבן אדם אמור להוביל.
• הם יכולים להיות פרויקטים ברמת . . . לא יודע,
• “שני צוותים ומעלה” זה, לא יודע, “זה Level X”
• “להוביל לפרויקטים של, לא יודע, חמישה צוותים, או משהו כזה, או שני Silo-ים, זה Level Y”.
• זה בדיוק זה.
• אני לא מצליח כל כך להבין, איפה הגילדה נכנסת כאן - בקטע הזה של Scope הובלת פרויקטים.
• כלומר, אם אנחנו מדברים על Expectations, נגיד מארכיטקט - אז בעיניי, זו נקודה מאוד משמעותית, של מה היקף הפרויקטים, ברמה טכנית, שהבן אדם יכול לקחת על הכתפיים שלו.

(אורי) אז אני מבדיל בין שני דברים - כשאתה מוביל הובלה טכנית של פרויקט, חלק ממה שמצופה ממך להוביל זה ה-What: זאת אומרת, “מה תעשו כדי שהפרויקט יקרה?”,

• (שי) אוקיי . . .

(אורי) המקום של גילדה, הוא מקום של How? - מה הסטנדרטים שאנחנו מיישרים בארגון, בשביל שהארכיטקטורה מסויימת או שקומפוננטות (Components) - ברמת הארגון - יוכלו לדבר אחת עם השניה, “עושים את זה ככה”.

• (שי) אני רוצה לתת דוגמה לעניין הזה. יש לי לקוח - אני לא אנקוב בשמו - אבל לקוח שמאוד שם בפוקוס את העצמאות של ה-Pod-ים.
• חברה בשלה כבר - יש להם הרבה שנים, מצאו את ה-Product-Market Fit שלהם, הם גדלו לאט ובביטחון
• אבל הם יצרו מספר לא קטן של Pod-ים, שכל אחד עובד לבד - בלי בכלל להתייחס למה ש-Pod-ים אחרים עושים.
• וזה עבד להם מעולה - כשהם היו קטנים.
• אבל ככל שהם גדלו, הצורך ב”משהו מרכזי” נהיה יותר ויותר ויותר ניכר - ובאמת בשנה האחרונה, יחד איתם, התחלנו לבנות להם את הקונספט של גילדת Engineering,
• ושם היה ניכר שיש באמת צורך בשתי הפונקציות - ובאמת שתי הפונקציות האלה יכולות להיות באותם אנשים, או באנשים שונים..
• מצד אחד, הבן אדם שיגיד “לא! אנחנו לא נייצר “God Object” עם מאה שדות, ונשים אותו ב-Mongo”.
• “אנחנו נתחיל לנסות לייצר הפרדה ל-Domain-ים”.
• ומצד שני...

• (רן) ה”שלילי על שלילי” זה בסדר, נכון? “God Object” ו-”Mongo” זה בסדר . . .

• (שי) אני חושב שאם תשאל את העובדים של אותה חברה, הם יגידו לך שלא כל כך כיף להם להתעסק עם ה-God Object” הזה.
• ומצד שני יש צורך לקחת את “הציוויים האלה של המלך” - ולחלחל אותם לשטח.
• עכשיו, אתה יכול לחלחל את זה בציווי - ואתה יכול לחלחל את זה גם בשכנוע ולימוד.
• וגילדה היא פונקציה בארגון, שעוזרת לחלחל דברים - לא בכוח אלא באמת בהובלה, בהשפעה, בפסיליטציה (Facilitation) ולא ב-Prevention.

• (רן) כן, סוג של “הובלה ללא סמכות” - למרות שכן יש את הסמכות, אוקיי? “קורטוב של סמכות”.

• (שי) בדיוק, בדיוק - הסמכות היא “נעלמת” כזה, “היא שם והיא לא שם”.

(רן) כן. זאת אומרת, זה לא מנהל “Line Manager” מה שנקרא, לא מנהל ישיר. כן, אתה לא זה שהולך לקבוע את המשכורות של כל העובדים באותה גילדה, אתה לא הולך לפטר או לגייס - אבל כן יש איזושהי סמכות. היא קצת Implicit, היא שונה בכל חברה, אבל בעצם זה ששם לך את ה-Title של Principal, מנהל גילדה, ארכיטקט או Whatever, נתנו לך איזשהו קרדיט מהנהלה, אוקיי? ויש איזושהי סמכות שהיא לא לגמרי מוגדרת, נכון? אבל זה לא אפס.

• (שי) I beg to defer, מה שנקרא . . . לדעתי, נקרא לזה הפונקציה הזאת של מנהל או מוביל של הגילדה - הוא Facilitator.
• הוא מישהו שיודע לתפעל ולארגן קבוצה כנראה די קטנה של אנשים, או שיש שם איזושהי תחלופה, “מילואים”, לא יודע . . .
• כל ארגון בסוף והגילדה או הגדרת-הגילדה שלו.
• ואני לא בטוח שזה אותו Skill-set. סליחה - זה לא בהכרח אותו Skill-set.
• (רן) זה לא אותו Skill-set, זה מה שאתה רוצה לומר. אל תתבייש . . .
• (שי) זה לא אותו Skill-set, לדעתי, שיש לארכיטקט,
• אחד הדברים שהארכיטקט אמור לדעתי לדעת לעשות זה גם לדבר עם אנשים שהם לא טכניים
• ולתווך להם את ארגון הפיתוח
• ולכן הוא סוג של גם “פונה כלפי חוץ”.
• נגיד, אני יכול לשבת עם צוות ה-Billing ולהסביר לו איך לדעתי כדאי לעשות את, לא יודע . . את צורת ה-Payments וה-Billing שאנחנו עושים בארגון, במוצרים שלנו.
• ולעבוד עם אנשי-מוצר, כדי להבין האם המידול שלהם או האם ה-Business - איך אנחנו יכולים למדל את זה טוב יותר ל-Domain-ים אצלנו ומה יהיו החלטות קשות יותר וקשות פחות.
• ואני צריך לפעמים גם לדבר עם CX, עם Customer Experience Persons, כדי לברר טוב יותר איזושהי בעיה.
• כל אלה - אני לא רואה אותם חיים באותו Facilitator, באותו Guild-Manager.
• ואני חושב שזה ממש סמכויות שונות.
• אגב, אני חושב שיש לארכיטקט סמכות, זה כמו שאתה... “הקורטוב סמכות” הזה - הוא חל גם על הארכיטקט, סוג-של.
• אם בסוף אני לא מצליח לשכנע את, לא יודע, את ה-Product Manager שאנחנו עושים כאן טעות גדולה, אז אני צריך למעשה להפעיל את המנהל שלי - שיתחיל להתקוטט עם המנהל שלו או משהו כזה.
• בסוף יש לי את - אפרופו “חותם המלך” - יש לי את “חותם המלך”, לפחות של המנהל הישיר שלי.
• אז לא... בעיניי זה ממש לא אותו הדבר.

• [זוהר בדיוק דיבר על זה במוצרלה - (Mozzarella - Organizational Politics 101 (feat. Zohar Sacks]

30:00 שובו של (חותם) המלך וה-Fractal שממשיך פנימה

(אורי) אני חושב שפה זה ממש עניין תרבותי, כי במקום שהארגון צריך להיות מאוד גדול ומאוד סקלבילי (Scalable), אתה מתחיל לחלק ל-Domain-ים גם את הארגון. ובסוף, לכל Domain יש את ההתמחות שלו, שהייתי מאוד מעדיף שצוות שמתמחה ב-Domain X יעבוד עם צוות ה-Customer Success או ה-Business ב-Domain X ישירות - בלי להצטרך את “חותם המלך” בסיפור הזה.

ואני ממש מעדיף - ואני גם מגדל את האנשים הרלוונטיים בתוך הצוות הזה - כדי שהם יוכלו לעשות את זה.

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

• (שי) רגע, שנייה - וכשאתה מקצר את התהליכים האלה, סבבה. הלוואי.
• הלוואי ולכל מתכנת או מתכנתת יהיה את ה-Drive הזה.

(אורי) אנחנו לא מדברים על מתכנתת בארגון גדול - אנחנו מדברים כבר על תת-ארגון, קבוצה או צוות.

• (שי) סבבה, אוקיי, מקסים - יצרת את ה-Silo עם הדינמיקה שלו.
• לפעמים בכל זאת, אחרי שבררנו מה שבררנו, צריך לחשוב האם אנחנו רוצים למדל את זה כך או אחרת.

(אורי) הם אמורים לדעת לעשות את זה לבד, כי הארכיטקט נותן להם את זה ב-Push, בחינוך.

• (שי) אז רגע, אז שנייה . . .
• (רון) אני טוען שזה פרקטלי (Fractal), כי בתוך Silo צריך להיות Tech-Lead
• איזשהו Level 3 - 4, לא יודע, תלוי בארגון.
• מישהו שהוא מספיק בכיר או מישהי מספיק בכירה, עם מספיק סמכות וניסיון והשפעה ו-Gravitas, בשביל להיות מסוגלים להשפיע אל מחוץ ל-Silo, מחוץ לפוד.
• אבל היא גם צריכה להיות בחניכה על ידי אנשים שהם ב-Level-ים יותר גבוהים ממנה - שנמצאים בתת-ארגון שמכיל את תת-הארגון שהיא נמצאת בו . . .
• וככה אנחנו הולכים פרקטלית (Fractal) למעלה ולמעלה, עד שאנחנו מגיעים לאיזה CTO או לאיזה Chief Architect או לאיזה Guild Leader.
• ובאמת, השמות משתנים מארגון לארגון, ולפעמים בארגון אחד מי שקוראים לו “גילדה”, בארגון אחר זה יקרה “ארכיטקט” - למרות שהוא עושה בדיוק אותו הדבר.
• ולפעמים לא . . .

(רן) ה-Fractal הזה, שי, ממשיך פנימה - זאת אומרת, בתוך אותו בן אדם: לפעמים אני הארכיטקט-שבי, לפעמים אני המנהל-שבי, לפעמים אני המקודד-שבי. [שירה].

33:03 דייג - אוהב דגים?

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

• (רון). . . את המלבנים והחיצים, זה ממש טוב . . .

(רן) . . . המלבנים והחיצים, כן, Sequence diagrams, דברים כאלה - חייבים, חייבים! את הדמויות של ה-User, לצייר כזה יפה יפה, עם רגליים ישרות . . . וצריך, כנראה, לדעת לכתוב איזשהו Spec טכני וזה.

אבל אתה מקודד? או - ארכיטקטים מקודדים, למיטב ידיעתך?

• (רון) אני חושב - לדעתי, זה שוב, זה מאוד משתנה לפי ה-DNA הארגוני.
• יש ארגונים שיגידו “בוודאי!” ויש ארגונים שיגידו “עזוב אותך, יש דברים יותר חשובים שהיינו רוצים שתעשה”.
• ואני נמצא במקום שבו אני מקודד להנאתי, ככה “בפנאי” - אז זה לא כזה.
• כאילו, הכושר נשמר מצד אחד
• ומצד שני, כשצריך לפתור בעיית עומק - אפרופו, מה שתיארת קודם, כששולחים, “כשמכניסים את היד פנימה לקישקעס, ומנסים להבין מה קרה”
• כאן, לדעתי, נמדדת היכולת של כל הניסיון שצברתי עם הזמן.
• זה לאו דווקא הקידוד - זה הרבה יותר לשאול את השאלות הנכונות, לרדת מה-High Level, “מהמלבנים והחיצים”
• לרדת ולעשות את ה-Drill-Down לתוך הקוד, לתוך הפונקציות עצמן, ולהבין.
• כאילו, התנודתיות הזאת, מרזולוציה גסה לרזולוציה עדינה - זה, לדעתי, אחד ה-Added Value שהארכיטקט אמור להביא איתו.
• לא משנה אם זה כולל לכתוב את הקוד של הפיצ'רים הבאים או לא.
• וזה, שוב - זה קצת DNA, זה קצת מבטא את ה-DNA הארגוני.
• הייתי גם . . “טעמתי מזה ומזה”.
• (שי) אני רוצה להגיד שאני מאוד מסכים עם כל מה שרון אומר - ועם זאת . . .
• (רון) . . . לא יכולת אולי לעצור קודם? . . .
• (שי) . . . מאוד חשוב שהארכיטקט . . . שלא יהיו ארכיטקטים שלא כותבים קוד.
• כאילו, זה לא מספיק בעיניי לכתוב קוד כ-Hobby, בצד - זה צריך להיות לכתוב קוד בתוך המוצר.
• כי אם אתה, כארכיטקט, מייצר כל מיני סטנדרטים ועקרונות, ומכתיב דברים, ועושה ולפעמים גם עוצר דברים - ולא חווה את חוויית-המפתח בתוך המערכות שבסוף אתה בונה, אני מרגיש שאתה עלול לפספס משהו מאוד מאוד חשוב.
• (רון) אני מסכים איתך . . . אני מסכים איתך.

(רן) אבל . . .

• (רון) לא, אני פשוט חושב שזה . . . אבל - זו שאלה של מינון.
• אני בעד פעם ברבעון, או לכל או יותר פעם במחצית, להיכנס, להיות סוג של Shadow או לחבור לאיזשהו צוות ברמת פיצ'ר.
• לכתוב משהו, לראות שזה מגיע ל-Production, לקחת את ה...
• (רן) אתה תגיד לעצמך “מי הדביל הזה שהכתיב את ה-Spec הזה?! אה, זה אני . . .”
• (רון) אה, זה אני . . . מה, זה הסטנדרט?
• (רן) . . . כן, סוג של Eat your own Dog food, למפתחים.
• (רון) כן, אבל רציתי להגיד משהו עוד קודם - בעיניי כל הנושא הזה של הסטנדרטיזציה זה באמת אחד התוצרים של הארכיטקט,
• ואנחנו, לדעתי, כל הזמן בשיחה, תסלחו לי - מדברים על איזשהו ארגון פיתוח על גבול האוטופי . . .
• של מהנדסים ומהנדסות מאוד מוכשרים, שאפשר לתת להם את כל האוטונומיה שבעולם
• והם יכולים לרוץ קדימה כמה שהם רק רוצים, והשמיים הם הגבול.
• המציאות היא לא כזאת.

(רן) זאת אומרת, לפעמים צריך “ללכת אחורה ולדחוף את האלה עם האלונקה” . . . . אלה שקשה להם, אלה שנשארים מאחור.

• (רון) כן, ולמפות . . . . בדרך כלל, אחד הדברים שאני עושה - אני ממפה את הפערים של ה-Engineering Skills
• של ידע, לפעמים, “טהור”.
• וזה חלק מהתפקיד.
• ועד אז - עד שהארגון יהיה “מצוין" - כן, יש מקום ל-Centralism.
• אתה דיברת קודם ככה על ה... אמרת “משהו מרכזי” . . .

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

• (רון) זה מאוד תלוי כמה כבר יש לך חוב טכני עמוק להתמודד איתו, ולפעמים צריכים קצת “פעולות רדיקליות".
• ולפעמים, כמו שאתה אומר, זה... אורי, אתה התייחסת לזה שזה חלק מ”החינוך העקבי והמתמיד”.
• זה מתחיל כאילו, To Pay Off, אפשר להתחיל “לקטוף את הפירות”
• ונדרשת לזה הרבה סבלנות.
• (רון) אבל עד אז, אני שוב אומר - ולא כל ארגון הוא בכלל רוצה לקבל את החינוך הזה, זה גם איזשהו DNA, או איזושהי תרבות ארגונית שהארגון . . .
• שלא כל ארגונים - יש להם את הראש לזה.

(אורי) לכל ארגון יש “מערכת חיסונית” לשינויים . . .

• (רון) תכל’ס . . .

(אורי) אז כאילו, אין מה לעשות. צריך לפעמים...

• (רון) אבל לא כל ארגון - בכלל יש לו אותה “שאיפה למצוינות טכנית”, שאנחנו לדעתי, בשיחה הזאת, איפשהו מניחים שהיא קיימת by default.
• ו”החינוך” הזה שאתה מתאר - לא תמיד אתה מוצא לו את הפרטנרים.
• ואז זה קצת “לחצוב את הדרך” ולעשות צעדים מאוד קטנים.
• וליצור את הדינמיקה שתאפשר את זה.
• אבל לא תמיד יש לך Stakeholders מספיק בכירים בארגון, שבכלל “קונים את הסחורה” הזו.
• ולכן, אני חושב שהדיבור - גם על גילדה, שזה רעיונית . . . אני מאוד מתחבר לזה - אבל היא מתאימה לדעתי לארגון שהוא יותר בשל...

(אורי) . . . או שמצוינות טכנולוגית זה חלק מה-DNA שלו.

• (רון) כן, כן - ואני לא חושב שזה “פתרון קסם” לכל ארגון.
• ויש ארגונים שירצו לפחות להתחיל עם דמויות
• לאו-דווקא “ארכיטקט”, לא משנה איך נקרא לזה ב-Title, אמרנו “זילות ה-Title” . . .
• לא משנה איך נקרא לזה - יש ארגונים שמבינים שבתור התחלה, צריך ליצור כאן פונקציות “בכירות טכנית”.
• עם אימפקט של . . . סוג של “צריך להקשיב להן”.
• ואחר כך, Hopefully, הם יגיעו כבר לאיזשהו מקום יותר טוב.

39:54 מבוא לחוויית הפיתוח

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

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

(רן) והעבודה זה הדבר הזה שמונע ממך ללכת הביתה . . .

(אורי) בדיוק.

(רון) חוסם אותך ביציאה . . .

(אורי) כן, או סתם מלשחק FIFA . . . אצלנו, קראנו לזה הצוות של ה-DevX, ה-Developer Experience - הוא פשוט לוקח את כל הדברים שאפשר לעשות להם אוטומציה, ומכניס אותם לתוך התשתיות ולתוך תהליכי העבודה, ומייצר פשוט סטנדרטיזציה הרבה יותר טובה לתהליך.

• (רון) וכמה ארגונים אתה מכיר, שמחזיקים את הפונקציה הזאת, של Developer Experience, של הצוות DevX הזה? אני מכיר מעט מאוד . . .
• ואני לא בטוח בכלל שזה... אני לא יודע לתת לכם אחוזים, אבל זה שוב - “הלוואי”.
• הלוואי ובכל ארגון הייתה את הראייה הבוגרת והבשלה הזו.
• יצא לי מספיק פעמים בחיים לראות ארגונים וגם לדבר עם אנשים - אני עושה קצת Mentorships, ככה כחלק מהדרך.
• ואני שומע הרבה מאוד אנשים שמדברים איתי, ולמעשה - תכל’ס, אני מזקק את זה ואומר “חבר'ה, זה לא ארגון פיתוח שעשה מצוינות כערך”
• ועכשיו אנחנו צריכים להבין איך אנחנו מתקדמים ואיך מתפתחים בכל זאת שם.
• אוקיי? כאילו זה בסוף, לא כזה פשוט החיים בחוץ. It’s complicated.

• 
  

42:13 לתת בהם סימנים ותיאום ציפיות

(רן) אוקיי, אולי שאלה אחרונה לסיום - נניח שאני מנכ״ל או CTO או VP R&D של איזושהי חברה, ואני קם בבוקר ושואל את עצמי “רגע, רגע, אין לי ארכיטקט! איך זה יכול להיות שאין לי ארכיטקט?! האם אני צריך אחד כזה?”

אז מה הם הסימנים, לדעתכם, שמעידים על כך שאולי שכחתי משהו?

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

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

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

• (רון) For fun, הייתי רוצה ששי יענה על זה . . .
• (שי) בשמחה. מהניסיון שלי, קודם כל, אני חושב שמהרגע הראשון, כדאי שיהיו אנשים שיכולים להתפתח לשם - ויצמחו עם הארגון.
• זאת אומרת, אפילו שה-Founding-team של הסטארטאפ - ה-Founder-ים והמפתחים הראשונים שהם מגייסים, שתיהיה להם את ההבנה שהם יצטרכו מתישהו להתחיל להסתכל על התמונה הכללית.
• מלמעלה יותר, לעשות Zoom-Out.
• אבל כן - הסימפטומים שאנחנו חווים בארגונים שאין להם את הדמויות האלה, הם ארגונים שבהם קשה מאוד לייצר שינוי רוחבי ביחד.
• קשה מאוד לנווט, “אנחנו לא אונייה אחת” - אלא אנחנו “צי” של הרבה מאוד ספינות קטנות.
• אבל הן לא בהכרח כולן שטות לאותו כיוון שאנחנו רוצים שהם ישוטו אליו.
• ואז צריך להבין איך אנחנו מייצרים להם איזשהו “שייט במבנה”.
• (רון) “היד המכוונת”
• (שי) סליחה על השימוש בטרמינולוגיה ימית . . .
• (אורי) לא, לא. אתה בטוב.
• (רן) נניח מטוסים, שלא כולם טסים לאותו כיוון . . .

(אורי) אני רוצה לשאול את השאלה - זה לא כזה משנה אם יש “ארכיטקט” או לא, משנה אם מישהו “עושה ארכיטקטורה” או לא.

• (שי) לגמרי.
• (רון) לא ממש, לא מסכים.
• בעיניי, ארכיטקטורה זה תוצר אחד - אבל לא היחיד.
• בעיניי, ארכיטקט - או לא משנה, ה-Title הטכני הזה - הוא נדרש.
• כשמנהל הפיתוח מבין שה-Velocity של ה-Dev Org שלו הוא לא כמו שהוא היה מצפה
• הוא רואה יותר מדי באגים, הוא רואה יותר מדי עיכובים בלתי צפויים . . .
• וכל אלה מייצרים איזושהי תובנה עמוקה יותר, שה-Engineering Level הנוכחי -או החוב הטכני הנוכחי, זה בדרך כלל בא ביחד - זה בעייתי מדי כרגע לארגון.
• ואנחנו צריכים Somehow לדחוף יותר גבוה או יותר למעלה את הארגון.
• וזה כנראה . . . כוח האדם שנמצא כרגע - כנראה שאין לו את ה-Attention או את היכולת לבצע את זה.
• אחרת זה כבר היה קורה מאליו.

(אורי) או שלא ציפית את זה ממנו . . .

• (רון) לא ציפיתי מהמפתחת או מה...?

(אורי) מכוח-ההאדם הנוכחי - זה מפתחת, זה ראשי צוותים, ראשי קבוצות.

• (רון) ומה זה אומר? אוקיי, אז בוא נפרוט את זה - מה זה אומר “לא ציפית את זה ממנו”?

(אורי) לא הגדרת להם שזה חלק מהתפקיד שלהם.

(רן) אורי מאוד מאמין באנשים . . . אורי, אני קולט את זה עליך.

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

(אורי) זו הגדרת תפקיד . . . . אצלנו, הרבה מאוד שנים, אולי אפילו עדיין ככה, תכל’ס - הארכיטקטים של קומפוננטות (Components) שנמצאות אצל צוותים מסויימים, זה בסוף על הראש-צוות או הראש-קבוצה. בסוף, המצויינות הטכנולוגית של הצוות שלהם - זה על הראש שלהם.

• (רון) אבל מי לוקח? . . . לא, רגע, שנייה - בסוף, יש לך איזשהו ארגון, ולא סתם יש לנו שם מנהל פיתוח, נכון?
• הוא אמור, אתה יודע, הוא שם את ה... סליחה, “התחת שלו על הגריל”, כן?
• זה הוא שאמור לקחת את האחריות על התוצרים.

(אורי) אבל מתחת לתחת שלו, יש את התחת שלהם . . .

(רן) אנחנו יורדים נמוך מאוד פה . . .

• (רון) בסדר - אבל אפרופו פוליטיקה אקטואלית, מה האחריות המיניסטריאלית שלו? הוא אחראי ל...

(אורי) זה נכון שהוא אחראי.

• (רון) הוא אחראי - אבל הוא אחראי גם על ה-DNA הארגוני. הוא אחראי.
• ואם ה-DNA הארגוני בסופו של דבר . . . הוא בסוף רואה את התוצרת בעצמו, נכון?
• וכנראה שהוא לא יכול לבד . . .
• מה שאני מנסה לחדד פה, זה שאם הוא היה - אם ה-DNA הארגוני היה כזה שבאמת התוצרים היו טובים, זה אומר שהוא תקשר ונתן את הציפיות והשקיע מה שהשקיע והכל, כדי לייצר את המצוינות הטכנולוגית שלדעתי אתה מכוון אליה.
• אבל אולי אין לו את זה
• ואני חושב שאני קצת כן נותן לך את התשובה, רן - שלא תמיד יש לך את המנהל הכי הכי טכנולוג או שבאמת מודע למקום הזה, של מצוינות טכנולוגית
• והוא צריך את “ה-Wingman שלו” - להלן “ארכיטקט”, או ראש גילדה או What Not - שהוא יהיה זה שמחזיק את הטיקט של האיכות והשאיפה למצוינות ו-Raising the Bar.
• (שי) אבל איכות זה שאיפה למצוינות . . .

(רן) תגיד “אני מסכים, אבל . . . “.

• (שי) אני מסכים . . .

(רן) . . . “עם כל מה שהוא אמר” . . .

• (שי) . . . . אני אציין ואני אחדד ואני אגיד שמצוינות טכנולוגית ושאיפה למצוינות וכל דבר - הם לא מטרה.
• הם אמצעי - בסוף, כדי שה-Buisness יהיה יותר מוצלח.
• ולכן, אני חושב שזה מאוד מאוד נכון שמצוינות טכנולוגית ופוקוס על טכנולוגיה ועל הנדסה, זה אחד מהדברים ש-IC ב-Level בכיר, בין אם אתה קורא לו ארכיטקט או Principal, צריך לעשות.
• אבל עוד אחד מהדברים האלה שהוא צריך לעשות, זה לעזור לתתי-ארגונים לראות את התמונה הגדולה.
• לראות לאן הארגון הולך.
• לא לעשות אופטימיזיה לוקאלית (Local), אלא לעשות אופטימיזציה לטובת הארגון כולו - גם במחיר של ה-KPI's או של ה-OKR's של התת-ארגון שלי.
• (רון) אני מסכים איתך!

(רן) ונעצור כאן . . . .

• (רון) כן, זהו.

(אורי) הייתי כבר בדיון שבו מישהו אמר “אני מבין מה שאתה אומר - אבל זה חרטא” . . .

(רן) כולם מסכימים, אבל רבים מסכיב . . .

• (רון) כן, אני מקווה שזה . . . אין כאן רמז.

(רן) ובנימה אופטימית זו - לא אתה, לא הדיון הזה כמובן - כמובן שאני גם מבין מה שאתה אומר.

49:47 סיום

(רן) טוב, אז בנימה אופטימית זו, ושנהיה מצוינים - ולא לזנב!

(אורי) ותקנו בתים שעשו בהם ארכיטקטורה . . . .

(רן) לגמרי, ארכיטקטורה זה חשוב!

(רון) רעיון טוב . . .

(אורי) תוודאו שמישהו עשה.

תודה רבה - שי ורון, תודה שבאתם!

תודה רבה ולהתראות לכולם.

האזנה נעימה ותודה רבה לעופר פורר על התמלול!