מחשבות על טופלוגיה של צוותי תוכנה

מודל ה Squads של ספוטיפי

מודל ה Squads (ספוטיפי, 2012) סחף את התעשייה והפך למאוד פופולרי. לעיתים ביישום מלא (למרות שכנראה מעולם לא הצליח בספוטיפי עצמה, מקור נוסף) – ולעיתים בהשראה.

הערכים הבולטים של המודל:

• הרכבת צוותים אוטונומיים (״self-organizing team״), להלן Squads.
  • תקשורת בין צוותים היא תקורה, ולכן נרצה צוות הכולל את כל מגוון הדיסיפלינות (״cross-functional״: בעיקר מהנדסים, אבל גם פרודקט, ניהול פרויקט, אנשי-נתונים, וכו׳) – כך שהצוות יוכל לעבוד עצמאית, ועם מינימום (בשאיפה: אפס) תלויות בצוותים אחרים.
  • הדגש הוא על מהירות. מה יאפשר לנו לנוע מהר יותר? אוטונומיה? אז בואו ניתן הרבה ממנה.
• לצוות תהיה אחריות קצה לקצה על התוצר. הצוות יעבוד על הדרישות מול אנשי המוצר עד לשחרור לפרודקשיין ותמיכה בתוצר.
• Guilds ו Chapters, כמנגנון המפצה על חוסר בבסיס משותף ברמה המקצועית הנובעת מהעצמאיות של ה Squads. הגילדה הוא פורום של בעלי עניין (למשל: פיתוח Backend, אבטחה, או UX) שבו מתקיימת הפריה הדדית והעברת ידע בין אנשים עם מומחיות / תחומי עניין דומים. ה Chapter הוא יותר ממוקד (מערכות Payment, או Graph Databases) המשתפים ידע, בין אנשים באותו הלוקיישן / אותו Tribe. כ 10% מהזמן של המהנדסים אמור להיות מושקע ב Chapter ופעילויותיו.
  • בעצם, כל מפתח שייך ל Squad שמוביל פעילות עסקית, וגם ל Chapter שמוביל מומחיות מקצועית ממוקדת, ואולי גם חבר בכמה Guilds.
  • ה Services ותתי המערכות הן באחריות ה Squads (ע״פ ספוטיפי). לפעמים מאמצים את המודל של ספוטיפי אך מנהלים את השירותים / תתי-המערכות ברמת ה Chapter (מה שדומה יותר למודל הבא שאסקור: Product/Platform Teams).

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

• איזו צלע נכונה שתהיה יותר דומיננטית עבור המפתח? ה Squad (קרי: delivery) או ה Chapter (קרי: מומחיות מקצועית)? על פניו נראה מקריאה, שה Squad הופך להיות הצלע הדומיננטית ברוב הפעמים.
• איך בעצם מפתחים פיצ׳רים שנוגעים ב services שבאחריות כמה squads? ברור שהאידאל הוא שכל פיצ׳ר יוכל להיתרגם ל service יחיד, או לפחות לאלו שבבעלות squad יחיד, אך במערכות מורכבות – השאיפה הזו לרוב לא מושגת.
• מה קורה כאשר יש שינוי עדיפויות בארגון, וזקוקים להרבה עבודה באזור ב׳ ולא באזור א׳? מה קורה עם ה squads שעובדים על א׳ – ואיך מחלקים מחדש את האחריויות?

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

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

• בניית תשתיות מקומיות ומאוד ספציפיות ל use case לו נדרש הסקוואד => מעט שימוש חוזר => תשתיות כפולות => חוסר יכולת להשקיע בתשתיות ארוכות טווח שישתלמו לארגון עם הזמן.
  • כידוע, שימוש חוזר אינו חזות הכל, ולעתים נכון לשכפל קוד ומנגנונים כדי להסיר תלויות בין חלקי המערכת. במבנה הסקוואדים התמריץ הדומיננטי הוא לכיוון עצמאות מרבית (מינימום תלויות) – כך שב Tradeoff הקלאסי בין עצמאות מרבית לשימוש-חוזר מירבי – סביר שנמצא את עצמו בקצה הראשון של הסקאלה, שהוא לעיתים נדירות רק יהיה נכון לארגון לטווח ארוך.
• חוסר התלות עשוי לחלחל גם ל Technology Stack וארכיטקטורת המערכת, אזורים הקשים מאוד לשינוי. אם וכאשר הארגון ירצה ״ליישר״ את ה Stack או ארכיטקטורה – זו עשויה להיות עבודה גדולה מדי מלהחיל (״too big to happen״).
• הסכנה המצטברת היא שהארגון יגיע ל״דרך ללא מוצא״ כאשר השקעה גדולה מדי נעשתה בראייה מקומית (קרי: צורכי הסקוואד הבודד), והדרך היחידה הישימה לאחד את המערכת לראיה אחת הוא לכתוב אותה מחדש. לא פעם ארגונים מגיעים לרגע שהשלב הבא בביזנס דורש יישור רוחבי עמוק, שלא ייתכן כאשר המערכת בנויה כמערכת של Silos.

צוותי מוצר ופלטפורמה

מודל ה Product / Platform Teams צמח במקביל למודל ה Squads. הוא דומה לו בכמה אופנים, אבל כולל גם כמה הבדלים משמעותיים.

• בדומה ל Squads, צוותי המוצר (Product Teams) הם Cross-functional (קרי, מכילים מגוון מומחיויות) ועצמאים במידת האפשר.
  • הם יכולים להיות אחראים על Flow קבוע, לקוח קבוע וכו׳ – או להיות מוקמים ולפעול לצורך משימה ספציפית (פיצ׳ר X).
  • צוותי מוצר אחראים למיקרו-שירותים הקבועים לתחום האחריות שלהם: אפליקציות / UI, ושירותים המנהלים Flows רוחביים במערכת (הרבה פעמים צוות מוצר אחראי על Flow).
• בניגוד למודל ה Squads, ישנו עוד סוג של צוותים, צוותי התשתית (Platform) המפתחים יכולות רוחביות בארגון, בהם ישתמשו מספר צוותי מוצר. הדוגמאות הקלות הן שירותים תשתיתיים בהגדרה, כגון Authentication/Authorization, שירותי Notification, תשלומים, וכו׳. שירותים נוספים שיהיו אצל צוותי הפלטפורמה הם שירותים ב core business של החברה, שמשמשים למגוון Flows / אפליקציות. למשל: שירות לניהול לקוחות, שירות לניהול הזמנות, שירות המנהל את מוצרי החברה, וכו׳.
  • אפשר לומר שצוותי תשתית, הם צוותי מוצר, כאשר הלקוחות שלהם הם פנימיים: צוותי המוצר. יש אפילו ארגונים המצרפים אנשי מוצר לצוותי תשתית.
  • צוותים כמו צוותי Operations (גם אם נקראים בטעות ״צוות DevOps״), או אבטחה – נופלים לקטגוריה של צוותי תשתיות.

גם כאן, אין ״אב״ ברור גם למודל זה, ואין ״שירות תמיכה״ שיכול לענות על שאלות שנשארות פתוחות. כמובן, שצבא של יועצים יסכימו לעבוד בשבילכם ולספק מגוון עצות איך ליישם את המודל. מכיוון שאין להם ״ספרי קודש״ להסתמך עליהם, הם לא פעם ינסו להתחבר למודל מוגדר יותר כמו המודל של Spotify או SAFe (אאוץ׳) – ממנו יגזרו מקור-סמכות.

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

המגבלה הברורה ביותר של המודל יחסית למודל של ספוטיפי היא שצוותי מוצר כבר אינם עצמאיים (אפילו לא בתאוריה) – הם זקוקים לחלק גדול מהפיתוחים שלהם לעבודה של צוותי תשתית. כל פיתוח של פיצ׳ר רוחבי הוא מורכב יותר לתיאום, כי צריך ״להזמין עבודה״ אצל צוותי תשתית שונים, שלא תמיד זמינים כאשר צוות המוצר זקוק להם. התיאומים האלו הם מורכבים, מוסיפים ל Lead Time הממוצע של פיצ׳רים והתקשורת בארגון (להלן: תקורה נוספת). שני ה mitigations הנפוצים למורכבות הזו הם:

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

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

• צוותי מוצר שרואים בצוותי התשתית חסם / גורם מעכב להשגת מטרותיו – ומוצאים דרכים לעקוף אותם (ובעצם, בונים תשתית כפולה, ולא בראיה ארגונית רחבה / ארוכת-טווח). כאשר צוות התשתית הרלוונטי מגלה שעוקפים אותו (במיוחד: אחרי שהפיתוח כבר בפרודקשיין) – הוא לרוב לא מרבה נחת.
• צוותי תשתית המזלזלים בצוותי המוצר, שהם לא מבינים את התשתית של הארגון מספיק טוב, שהם פזיזים ולא יסודיים, ומפתחים הרגשה שהם צריכים ״לפקח״ על צוותי המוצר. לא פעם יטענו צוותי המוצר שצוותי התשתית בונים תשתית-יתר (Over-Engineering) – ולא פעם הם צודקים.
• בקיצור: הרמוניה ושיתוף פעולה בריא בין צוותי המוצר לצוותי התשתית הם חמקמקים וקשים להשגה / שימור.
• התקשורת בין צוותי התשתית וצוותי המוצר היא קריטית, אבל לא פעם ארגונים (ברמותיהם השונות) מסווגים אותה כתקורה ולא כהשקעה. למשל: האם השתתפות של אנשי צוות תשתיות רלוונטי ב Planning של צוותי המוצר להבין טוב יותר למה הם נדרשים היא נכונה, או מיותרת ומקשה (״הם לא בקיאים בפרטי המוצר והלקוחות״). סיווג התקשורת הזו כתקורה (נדרשת, אפילו) יוצר לחץ לצמצם את התקשורת הזו, מה שמקשה יותר על פעולה תקינה של המודל.

לסיכום, מודל ה Product/Platform Teams מתאים יותר לארגון בטווח הארוך, אך הוא דורש השקעה ותיאומים גדולים הרבה יותר => פחות פריון פר מפתח. אני מדמיין שארגונים שמתחילים במודל ה Squads מגיעים לנקודה בה הם לא יכולים להמשיך לפעול במודל שמעודד ראייה קצרת טווח ונאלצים לעבוד למודל קרוב יותר למודל ה Product/Platform Teams.

סתם צוותי Components

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

אין הגדרות של ״סוגים של צוותים״. כל צוות אחראי על רכיב או מספר קטן של רכיבים בארכיטקטורת המערכת (למשל: מיקרו-שירותים) והוא הדואג העיקרי לחשיבה ארוכת-הטווח של אותו הרכיב. לכל צוות יש Inbox של דרישות (או Tickets) שמבקשים ממנו לבצע שינויים במערכת / לחשוף API והוא מבצע את המשימות לפי הגדרת עדיפות מסוימת.

בעצם אין בארגון צוותים אוטונומיים המסוגלים (כמעט) לדלוור פיצ׳רים קצה לקצה. אין צוותים שהם Cross-Functional (המכילים אנשים ממגוון התמחויות). יש צוותים שמתמחים בדומיין ו/או טכנולוגיה ויודיעם לעשות עבודה מצוינת שם.

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

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

• המודל הזה הוא בעצם המודל ההופכי למודל של סופטיפי – המון מומחיות ועומק, אבל מעט מאוד עצמאות של צוותים וקושי גדול לספק Deliveries תדירים. אני מאמין שהרוב המודלים האחרים בפוסט הם תגובה לאכזבה ותסכול מהמודל הזה.
• אני לא חושב שהמודל בהכרח רע. עם TPM מצויינים, ותרבות ארגונית של שיתוף וחתירה לעזרה – הדברים יכולים לעבוד טוב. כמובן שהמודל מתאים למערכות הכבדות, המסובכות ביותר – ושבהן מוכנים להקריב את את המהירות הכללית – בכדי לשמר מערכת נכונה לאורך זמן.
  • כמובן שבניית טופולוגיה שטוחה של צוותי רכיב (Component) היא לא ערובה למצויינות הנדסית. המצוינות ההנדסית צריכה לנבוע מתרבות ומפעילויות נוספות של הארגון בכדי לבנות ולשמר אותה.
• בעייה נפוצה של המודל הזה היא התחפרות ב Silos טכנולוגיים: צוותים שמתקשים לעבוד זה עם זה, ושבנו ארכיטקטורה מקומית של השירותים שלהם – שלא ידידותית לשאר הסביבה, כי אין להם מספיק חיבור לתמונה הגדולה, ולהיכן הארגון מתקדם. דרושה הרבה תקשורת יזומה כדי לחדור לכל הצוותים וליישר אותם לכיוון שאליו הארכיטקטורה והביזנס מתקדמים – וכדי לעזור שכולם יתקדמו ביחד לאותו הכיוון.
• קושי גדול נוסף הוא חוסר גמישות ארגונים לאזן בין משאבים. נניח שבשנה מסוימת הארגון זקוק להרבה יותר פיתוח באזורים A ו B והרבה פחות באזורים C ו D. תהליך הגיוס של צוותים C ו D לעבודה באזורים A ו B – אינו פשוט מכיוון שלצוותם יש זהות חזקה מאוד עם הרכיב הטכנולוגי עליו הם עובדים. הצוותים האחראיים על A ו B יגלו כנראה התנגדות וביקורת למפתחים נוספים שמגיעים ו״משנים להם את הקוד, מבלי שיהיו כאן שנה הבאה להתמודד עם התוצאות ארוכות הטווח של השינויים האלו״.

מודל ה Stream-Aligned Teams

מודל זה חדש יחסית (הוצג בספר Team Topologies: Organizing Business and Technology Teams for Fast Flow, שפורסם ב 2019) אך זוכה לאזכורים רבים. המודל הוא בעצם שילוב בין המודל ספוטיפי למודל ה Product/Platform Teams. האם זהו הפתרון האידאלי? שילוב בין שתי הגישות?

לתחושתי, הספר הנ״ל מציג תאוריה מהונדסת להפליא שמסתדרת יפה מאוד עם עצמה, מקשרת כמה וכמה רעיונות משפיעים בעולם התוכנה (Conway’s Law (ביטוי המופיע בספר 110 פעמים), הספר ״Accelerate״, Cognitive Load Model, מצטטים את דניאל פינק, מיקל ניגארד – ועוד כמה של כוכבים) תוך כדי שהכל ״מתקמפל״ ברמת הסיפור – ונשמע נהדר. בפועל הוא קצת יותר דומה למודל של סופטיפי, גם בדגש שלו על Velocity, וגם בזה שיש לו המון PR בצד אחד – וחורים ושאלות פתוחות גדולות, מצד שני. כמו Black Adam (דוגמה עדכנית ליום כתיבת הפוסט) – בהחלט מדובר ברב-מכר, עם ספקות להיותו קלאסיקה מאריכת ימים. זה טוב מאוד ל Team Topologies Academy (חברת יעוץ) – וספק עד כמה משרת באמת את התעשיה.

• המודל מציג ארבע סוגים של צוותים בארגון:
  • Stream Aligned Team (להלן צוות רצף-עבודה; בספר מציינים במפורש שנמנעו מלקרוא להם Product Team או Feature Team) – צוות המיושר (Aligned) לשטף מתמשך של עבודה: פיצ׳ר (גדול), רצף של פיצ’רים בעלי אופי מסוים, או סוג משתמש מסוים, כאשר הדגש הוא על רצף מתמשך של עבודה, שלא ידרוש פירוק/הרכבה כאשר הצרכים והעדיפויות של הארגון משתנים. הצוותים האלו (להלן צוותי רצף-עבודה) מהווים את עיקר הצוותים בארגון, והם אוטונומיים ו Cross-Functional, כמו Squads. הם גם בעלי אחריות ארוכת טווח על מיקרו-שירותים שהם מנהלים (מלבד כמה יוצאי דופן). שאר סוגי הצוותים מכוונים לתמוך ולסייע לצוותי רצף-העבודה לעבוד מהר ויעיל יותר.
  • Enabling Team (להלן צוותים מאפשרים) – צוותים המרכזים ידע בתחום מסוים, ומנגישים אותו לצוותי רצף-העבודה, ע״פ הצרכים של צוותים אלו. למשל: צוות שמתמחה ב SQL ובסיסי-נתונים, ויכול לספק לצוותי רצף-העבודה את ההדרכה והעזרה שהם צריכים, תוך כדי שהוא מפתח את הידע בצוות (כדי שצוות רצף העבודה יהיה אוטונומי יותר) – ולא מקבל ממנו משימות ספציפיות. במקרים בהם נדרש מחקר עמוק, פתרון בעיה מסובכת במיוחד בתחום – הצוות המאפשר ייקח את העבודה על עצמו. בקיצור: חכה ולא דגים, מלבד דגים שמנים במיוחד.
  • Complicated Subsystem Teams (להלן: צוותי עומק) – אלו בעצם סוג של צוותי פלטפורמה (ע״פ המודל הקודם) אך הם בודדים ומוגבלים לנושאים המורכבים ביותר, שלא סביר שצוותי רצף-עבודה יכולים לקחת. הדוגמאות כוללות בעיקר צוותי אלגוריתמים / ML / אנליזה עמוקה (מזכירים שאם יש דוקטורים בחברה, הם כנראה יהיו בצוות כזה). מטרת הצוותים היא להוריד עומס קוגניטיבי מצוותי רצף-העבודה, כך שיוכלו להתמקד במשימה העיקרית שלהם. נחזור לנושא זה בהמשך.
    • על פניו, הורדת עומס קוגניטיבי זה לא רק אלגוריתמים, אלא גם לוגיקה עסקית מורכבת – ולעתים יש הרבה כזו בארגון. לא הצלחתי להתחבר שסוג הצוות הזה נדרש רק במקרים ספורים וקיצוניים כל-כך.
  • Platform Teams (להלן צוותי פלטפורמה) – על אף השם הזהה, אין הכוונה לצוותי פלטפורמה בנוסח מודל ה Product/Platform Teams בכך שאלו פחות צוותי תוכנה ויותר צוותי Infrastructure/Operations. למשל: צוותי Cloud Operations/Security/Data Engineering/Devex וכו׳. צוותי הפלטפורמה במודל הם הצוותים שמספקים את הפלטפורמה למערכת, ולא מפתחים את המערכת עצמה (עליה אמונים צוותי רצף-עבודה). מטרתם כמובן היא לשרת את צוותי רצף העבודה, לייעל את עבודתם, ולהוריד מהם עומס קוגניטיבי.
• רעיונות מרכזיים במודל הם:
  • יישום ה Inverse Conway manoeuvre – קרי, יש לארגן את הצוותים ע״פ הארכיטקטורה הרצויה, ולא לצפות שהצוותים יתאימו את עצמם לארכיטקטורה במבנה ארגוני אקראי. כל רכיב / תת-מערכת בארכיטקטורה – צריכה להתמפות לצוות רצף-עבודה שאחראי עליה, ורכיבים קרובים ברמת הארכיטקטורה צריכים להיות מנוהלים ע״י צוותים קרובים במבנה הארגוני.
  • צמצום ה Cognitive Load על צוותי-רצף העבודה, בכדי שיהיו יעילים. כלי אחד הוא הצוותים התומכים, כלי נוסף הוא מין סקר ששואלים כל פרק זמן את צוותי רצף-העבודה, וממנו מסיקים כיצד להשתפר. כלומר: מנגנון קבוע על מדידה (לא מדויקת, אבל בכל זאת) של העומס הקוגניטיבי (=> יעילות) של צוותי רצף-העבודה, ושיפור מתמיד שלו.
  • צמצום התקשורת בין צוותים (״Fast Flow requires restricting communication between teams״). ״תקשורת היא לא תמיד דבר טוב״ והשאיפה היא להחליף Collaboration (תקשורת עמוקה) בתיעוד, Self-Serve APIs ונוהלים מסודרים איך לפנות לצוות בבקשות. בספר ממש ממליצים להימנע מ Open Space כי לא כולם צריכים לדבר עם כולם, וה Open Space מעודד תקשורת אקראית ולא דרך המנגנונים היעילים יותר. כנ״ל לגבי כלי כמו Slack.

כפי שאמרתי, המודל דומה למודל של ספוטיפי, עם כמה צעדים לכיוון של מודל ה Product/Platform Teams. יש במודל צוותים שאחראים על נושאים מורכבים / עומק / ראייה לטווח-ארוך, אבל ה Guideline הוא שכל הצוותים שאינם צוותי רצף-עבודה ירכיבו ביחד כ 10% מהארגון. הרבה מהשיח במודל הוא על Velocity ברמת הצוות – מה שבאופן טבעי מטה את הארגון לחשיבה קצרת טווח.

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

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

מחשבות

לאחר הקדמה ארוכה, וסקירה של כמה מודלים פופולאריים, אנסה לשתף בכמה מחשבות:

• בטופולוגיה של צוותי-תוכנה יש כמה Tradeoffs שהם כמו חוקי-טבע, שאין דרך להימנע מהם:
  • חשיבה לטווח קצר (צוותים ממוקדי Delivery) מול חשיבה לטווח ארוך (צוותים ממוקדי רכיבים טכניים – והאחריות עליהם לזמן ארוך).
    • בווריאציה: אוטונומיה מול ריכוזיות.
    • בווריאציה נוספת: יישור למוצר (Product-Alignment) מול יישור למודל המערכת (Architecture-Alignment). כמובן שטוב שהארכיטקטורה תתמפה בצורה ישירה עד כמה שניתן לצרכי המוצר – אך לא תמיד ניתן להשיג זאת.
    • חשוב לי לציין ש Delivery הוא מרכיב חשוב לא רק לביזנס, אלא גם לארכיטקטורה: הצורך לספק משהו מוחשי וספציפי בטווח נראה לעין עוזר לצוותים לבנות ארכיטקטורה מעשית יותר. ברגע שמצמצמים את לחץ ה Delivery מתחת לרף מסוים – הארכיטקטורה והיכולת לטפל בטווח הארוך דווקא יורדים, ולא ממשיכים להעלות.
  • התמחות ועומק מול גמישות להזיז את הכח בין נושאים – ע״פ צורכי הארגון המשתנים.
    • משליך על: האם להשקיע הרבה בתשתיות / כלים / תיעוד / הדרכה – כדי לאפשר למהנדסים לזוז מאזור לאזור? זה עוד Tradeoff בין השקעה בתשתית, מול גמישות.
    • וריאציה: האם זה נכון שיהיו בארגון 30 סוגי מהנדסים (המשקפים עומק והתמחויות שונות, אפילו שכולם הם מהנדסי ג׳אווה) או שהארגון חייב שלא יהיו יותר מ 10 סוגי מהנדסים, והוא מוכן להשקיע רבות בכדי לאפשר זאת?
• נקודת האופטימום, תשתנה כמובן בין ארגון לארגון, ובתקופות או שלבים שונים של כל ארגון.
  • ארגון שמפתח תריסר אפליקציות מובייל פשוטות ובלתי תלויות – מוטב שיאמץ מודל הדומה למודל של ספוטיפי. אפילו: אם הוא קרוב לשם, כדאי שיתאמץ ויפרק את המערכת שלו למבנה כזה, כדי שיוכל להיות שם.
  • ארגון שמפתח מערכת מורכבת, עם הרבה תלויות פנימיות – מוטב שיאמץ מודל יותר קרוב למודל ה Product/Platform Teams או אפילו מודל ה Component Teams. כמובן שלו היה יכול לחלק את המערכת / לעצב ארכיטקטורה ללא תלויות פנימיות רבות – עדיף היה, אבל לא תמיד זה אפשרי.
  • הניסיון להגדיר מודל יחיד לכל הארגונים, לאורך כל ימי חייהם – הוא שטותי כמובן. אפילו אם יש גמישויות מסוימות במודל (נניח: צורת התקשורת).
• חשוב שמובילי הארגון יבינו את ה Tradeoffs האלו לעומקם, ויבינו שאין ״מודל קסם״ טוב יותר: השמיכות שבמְצַאי הן כולן קצרות, וההחלטה הנדרשת היא האם להשאיר את הרגליים חשופות, או את הראש – איפה ועד כמה.
  • ארגון בוודאי יכול לומר לעצמו (ברגע של כנות) האם הוא מפתח מערכת מורכבת ואינטגרטיבית, או סדרה של תתי מערכות פשוטות. האם יש לו יכולת לחזות / לתכנן לטווח הארוך היכן ידרשו המהנדסים, או שהוא חייב להיות גמיש ולהיות מסוגל להזיז תדיר מהנדסים ממקום למקום (על אף המחיר הגבוה של זה).
    כמובן שהתשובה הפופולארית היא ״המערכת שלנו היא סופר מורכבת ומאתגרת, והשוק דינאמי – אז אנחנו זקוקים למירב המומחיות ולמקסימום גמישות״, אבל זה לא תמיד המצב, ובחירה בנקודה הזו במודל ה Tradeoffs אומר הרבה תקורה, תקשורת, וגופים מרכזיים בארגון => פחות מהירות.
  • ארגונים משתנים, וכמובן שכל פרק זמן נכון להעריך מחדש היכן נמצא הארגון, ומה הטופולוגיה הארגונית שנכונה לו בשלב זה. שווה להזכיר שטופולוגיה של צוותים היא יותר מקום-מגורים מגרביים – להחליף אותה זה יקר מאוד, ועלול ליצר הרבה After shocks (בניגוד לגרביים).
  • ל Coupling במערכת יש מחיר אסטרטגי, כלומר: ברמה הגבוה ביותר של הארגון. חשוב מאוד לנסות ולפרק את המערכת ואת הארגון, לתתי-מערכות ותתי-ארגונים יותר עצמאיים, גם במחיר מסוים.
    • למשל: כשעבדתי בחברת נייס, שכפלו את חטיבת ההקלטות לשתי חטיבות מקבילות בכדי לתת להן יותר עצמאות: חטיבת הקלטות הקול, וחטיבת הקלטות הוידאו. הקוד שוכפל ומספר המהנדסים כמעט הוכפל – אך בדיעבד נראה שזו הייתה החלטה נכונה.
    • בחברת SAP רצו ליצר הפרדה משמעותית יותר בין ה Core לבין ה UI ברמת ה Backend. הם כל הזמן התערבבו – והמערכת מאוד הסתבכה. החליטו להעביר את כל פיתוח ה UI ל Stack Technology אחר (במקרה: ג׳אווה) בכדי שהחיבור בין הרכיבים יהיה רק דרך API מוגדרים היטב, ולא יאפשר (או לפחות יקשה) על Tight coupling. כמובן שנדרשה כתיבה מחדש של כל ה UI Backend, והעברת מאות (אולי אלפי) מהנדסים ל Stack חדש. חשבו איזו השקעה זו.
• כמובן שניתן לשחק בפרמטרים וב Tradeoffs השונים:
  • אפשר בהחלט להחליט שחלק מסוים מהארגון / מוצר (אזור) עובד במודל א׳, וחלק אחר במודל ב׳. זה מוסיף בלבול ומורכבות ניהול – אבל היא עשויה להיות שווה זאת, בכדי להקל על היומיום של הצוותים.
• נושא טופולוגית הצוותים בארגון הוא נושא מורכב, שקל להרים בו ידיים, ולחפש עזרה. עזרה כזו תמיד זמינה (יועצים, מנהלים מקבילים בחברות אחרות שישמחו לעזור) – אך כנראה שהכי טוב שתעשו את זה בעצמכם, מתוך מחויבות עמוקה (מה לעשות: לכם תמיד יהיה אכפת יותר) ומתוך הבנה עמוקה של האפשרויות והקיים. זה לפחות הניסיון שלי.

שיהיה בהצלחה!