אם יש שני דברים שאנחנו בטוחים לגביהם זה שהסטארטאפ צועד על קיבתו, ושצוותים הם מה שמניע את החברה ואת הפיתוח של המוצר.
לגבי המזון - נשאיר את זה לפוסט אחר.
לגבי הצוותים - יש חשיבות רבה לאופן שבו בונים אותם.
קראנו לאחרונה את הספר Team Topologies של Matthew Skelton ו-Manuel Pais, ורצינו לשתף בכל מיני תובנות מתוכו.
הספר מציג רעיון לגבי מבנים של צוותים, ואיך נכון לבנות את ה-R&D בכל מיני שלבים שונים של הארגון.
כשאנחנו בונים ארגון פיתוח (צוות, קבוצה, R&D שלם) - יש לפנינו מטרות עסקיות שעליהן אנחנו רוצים לתת מענה.
כדי לתמוך את הבעיות העסקיות האלה, אנחנו נדרשים לכתב המון קוד בצורה איכותית וגמישה לשינויים. זה מצריך מאיתנו לתכנן ארכיטקטורת מערכת בצורה נכונה ולייצר אותה כך שיהיה קל להתקדם ולתמוך בקוד שמשתנה.
את כל זה ניתן להשיג רק באמצעות צוותים שבנויים חכם.
בעצם, אפשר להסתכל על זה קצת ככה:
איך בונים צוותים שעוזרים לנו להגיע למטרות העסקיות שלנו מהר ומבלי להתפשר על האיכות?
זה מריח כמו שאלת ארכיטקטורה מתוך ראיון עבודה בWebos.
או שזה הריח של הבחור שהוריד נעליים ברכבת. תיכחד :(
ואכן, יש קשר ישיר בין המבנה של הצוותים שלנו לבין הארכיטקטורה של המערכת.
אם עד לפני מספר שנים כל ארגוני הפיתוח היו מחלקים את הצוותים שלהם לפי קומפוננטות (צוות Backend, צוות Frontend, צוות QA, צוות ג׳וניורים בני יומם), מאז מהפכת ה-Squads & Tribes של ספוטיפיי ב-2012 נראה שהדברים קצת השתנו.
במקום לבנות צוות סביב קומפוננטה - צוות טוב נבנה היום סביב בעיה עסקית, והמטרה שלו היא לבנות ארכיטקטורה טובה, כדי שיהיה מסוגל לדלוור מהר מאוד פתרון לבעיות עסקיות (יענו Velocity גבוה בשפת הילידים).
אז הבאנו לכם את הנקודות המרכזיות מתוך Team Topologies, עם פרשנות שלנו כמובן, כי אחרת בשביל מה אנחנו פה אם לא כדי להרוס?
Inverse Conway Maneuver
בערך כל מחשבה מודרנית על צוותי פיתוח מתבססת על Conway's Law. הספר Team Topologies לא שונה בקטע הזה. כנראה שרובכם כבר שמעתם עליו בדרך זו או אחרת - אבל הרשו לנו ליישר קו לגביו.
על-פי Conway: ״כל ארגון שבונה מערכת, יתכנן אותה ככה שהארכיטקטורה שלה מבוססת על המבנה שבו הארגון מתקשר״.
פואטי משהו.
במילים אחרות, ישנו קשר ישיר ודו צדדי בין האופן שבו הארגון מתקשר, לבין האופן שבו נראה הדיזיין של המערכת שלו.
הרעיון של Team Topologies הוא לעשות Reverse Engineering לקונספט הזה, דרך מה שנקרא Inverse Conway Maneuver.
כלומר, לבנות את הצוותים כך שייצרו מערכת עם ארכיטקטורה נכונה - כפי שהיינו רוצים אותה.
הצוות במרכז
בתפיסת העולם של Team Topologies הצוותים נמצאים במרכז. הצוות הינו יחידה אוטונומית קטנה יחסית (הם הולכים חזק עם חוק 2 הפיצות של בזוס) שיש לה אחריות על בעיה מסוימת והוא מייצר לעצמו את המשימות באמצעות מנהלת המוצר, הלקוחות, או הביזנס.
המשמעות היא שראשי הצוותים הם פונקציה מאוד משמעותית בארגון, יש להם אחריות על ההצלחה והכישלון של המוצרים והפרויקטים שהם אחראים עליהם, והם השכבה העליונה ביותר מבחינת המעורבות בפרטים.
לצורך העניין, ה-VP R&D או ה-Group Manager, או ה-Director (נו, זאת שמנהלת את ראשי הצוותים), לא אמורה להיות מעורבת בפרטים, ואסור שדברים קריטיים יעברו דרכה והיא תהווה צוואר בקבוק.
התפקיד שלה הוא בעיקר להוריד חסמים עבור הצוותים שהיא אחראית עליהם, לבחון כל הזמן את מבנה הצוותים שתחתיה ואת תחומי האחריות שלהם, לזהות התנגשויות ביניהם, ולהזיז מכשולים בירוקרטיים או אחרים.
נשמע כיף.
אחד הדברים החשובים בצוות הוא היציבות שלו.
לצוות לוקח זמן להיבנות. לוקח זמן עד שמתקיימת תקשורת טובה בין חברי הצוות למנהלים ובין חברי הצוות לבין עצמם. לכן, צריך להשתדל להימנע מהעברה של אנשים בין צוותים ולתת לכל צוות לרוץ ביחד לאורך זמן.
בנוסף, יש חשיבות קריטית להגבלת ה-Cognitive Load של הצוות. לצוות צריכה להיות מטרה מוגדרת עם גבולות ברורים, ובעיקר חשוב שיהיה ברור לכל צוות על מה הוא לא אחראי.
4 סוגים של צוותים
יאללה, הגענו לתכלס.
הספר מתאר 4 סוגים של צוותים, וכל סוג צוות תפקידו לפתור סוג מסוים של בעיות.
Stream-Aligned Team
זהו הצוות הבסיסי והמרכזי ביותר בארגון התוכנה, ורוב הצוותים בארגון צריכים להיות מהסוג הזה.
מדובר בהגדרה מחדש ל-Product Team או Feature Team המפורסמים.
לצוות מהסוג הזה יש משימה מוגדרת - בעיה עסקית שהוא צריך לפתור עם KPIs ברורים, והוא אחראי עליה מקצה לקצה.
תפקידם של כל סוגי הצוותים האחרים בארגון הוא להוריד את העומס הקוגניטיבי מהצוות הזה, כלומר, לדאוג שה-Stream Aligned Team יעסוק אך ורק בבעיה שהוא אחראי עליה ולא יצטרך לחשוב על כל מה שמסביב (תשתית CI\CD, אלגוריתמים מורכבים מאוד, Happy Hour וכו׳).
הצוות הזה מורכב מכל מה שהוא צריך להיות מורכב ממנו בשביל לפתור את הבעיה.
זה משפט דיי מעצבן, אנחנו יודעים. הכוונה היא: אם הצוות צריך מפתחי פולסטאק - אז הם שם. אם הוא צריך דאטה אנליסטים - הם שם. אם צריך מוזיקאים - הם שם. אם צריך שף פרטי - לגמרי שם.
דוגמא לסוג כזה של צוות: צוות Orders, שאחראי על כל נושא ההזמנות מקצה לקצה, החל מאיך נראה ה-UI דרך הלוגיקה העסקית ועד העברת ההזמנה לשירותים אחרים (מחסן, הפצה וכו׳).
Platform Team
צוות שתפקידו לספק תשתית רחבה ל-Stream-Aligned (SA) Teams ( נמאס לנו לכתוב את השם הארוך הזה אז נתחיל לכתוב SA במקום).
הצוות הזה ינגיש סביבות פיתוח וכלי עבודה נוספים כדי להבטיח שהצוותים האחרים לא יצטרכו לחשוב עליהם בעצמם.
מדובר בסוג צוות שלא מורגש ישירות על ידי הלקוחות אבל הוא כן מייצר מוצר. מוצר פנימי - פלטפורמה.
הלקוחות של המוצר הזה הם שאר צוותי הפיתוח.
בצוות הזה יהיו מפתחי Infra ו-Devops - מומחים שמפתחים כלים פנימיים להרמת סביבות בקליק, כלים לניתוח לוגים או מדידות, ותשתית למנגנון אירועים (אירועים יענו Events, לא שבת תרבות עם שמעון פרנס).
Enabling Team
צוות שתפקידו להגדיל את היכולות של ה-SA Team.
הצוות הזה לרוב מכיל מהנדסים עם תחומי מומחיות מוגדרים יותר, שמטרתם לשפר את ה-Developer Experience של ה-SA ולאפשר להם לקדם את הפיתוח.
אפשר להגיד שהחבר׳ה האלה הם כמו סיירת - הם חוברים לצוות SA לתקופה מוגבלת, ועובדים על לפלס את הדרך ולצמצם מכשולים עבור אותו הצוות. לא שאנחנו מבינים בצבא יותר מידי, אמרו לנו שזה מה שהסיירת עושה אז זרמנו עם האנלוגיה.
הם מסוגלים להכניס טכנולוגיות חדשות לפיתוח, ללמד ולהכשיר את המפתחים בצוותי ה-SA, ולאחר השלמת הפרויקט המשותף לעבור לפתור בעיה עבור צוות SA אחר.
Complicated Sub-Systems Team
צוות המורכב ממומחים שאחראים על רכיב מסוים שיש בו מורכבות חריגה, כלומר, רכיב שלא ניתן לשים תחת אחריות של צוות SA רגיל.
התפקיד של הצוות הזה הוא לדלוור את אותו הרכיב בצורה איכותית יותר ממה שצוות ה-SA היה יכול.
מדובר לרוב במערכת שמריצה אלגוריתם מאוד מורכב, משתמשת בטכנולוגיה ייחודית (נגיד משהו מעולמות ה-Low Level), קומפוננטה עם רגישות חריגה מבחינת אבטחת מידע וכיו״ב.
דוגמא לסוג כזה של צוות: צוות שאחראי על אלוגריתם המלצות שיש לו חשיבות משמעותית בחוויה של היוזר.
דרכי תקשורת בין צוותים
תקשורת בין צוותים היא אחת הבעיות הכי גדולות בארגונים, במיוחד בשיטת העבודה המסורתית של ״צוותי קומפוננטה״.
למשל, ראינו לא מעט ארגונים בהם צוות ה-Frontend נהיה צוואר בקבוק, שכל הארגון מחכה לפיצ׳רים ממנו ואנשי הבקאנד צריכים להילחם על המשאבים שלו.
גם כשעובדים בשיטה של Team Topologies, הרבה פעמים מצליחים להתקדם מהר מאוד עד שמגיעים לנקודה בה אחד הצוותים תלוי בצוות אחר בשביל לפתור בעיה מסוימת שהוא מתמודד איתה.
דוגמא 1: צוות SA שאחראי על ההזמנות רוצה לברר מידע נוסף על היוזר שביצע את ההזמנה, ואת המידע על היוזרים מנהל צוות SA אחר.
דוגמא 2: צוות SA שאחראי על ההזמנות רוצה לשלוח נוטיפיקציה ליוזר שההזמנה הושלמה, ועל הפלטפורמה של הנוטיפיקציות אחראי צוות Platform מסוים.
הספר מתאר 3 דרכי תקשורת מרכזיות בין צוותים:
תקשורת Collaboration, יעני שת״פ: שני צוותים חולקים קומפוננטה (או חלק ממנה) ועושים CR אחד לשני.
למי זה מתאים: השיטה הזו יכולה להתאים לעבודה בין צוות SA לצוות Complicated Sub-System. לדוגמא: אזור במנוע ההמלצות שקשור להזמנות, וצוות ההזמנות (SA) כותב כדי להשתמש בו.
תקשורת X-as-a-Service, יעני XaaS: צוות אחד מספק לצוות השני יכולת לעבוד עם הקומפוננטות שלו כשירות. הוא חושף API מסוים, או מגדיר Topic שאליו אפשר להירשם כדי לקבל מידע מהשירות.
למי זה מתאים: זאת כנראה צורת התקשורת הכי סטנדרטית ונפוצה במודל הזה, והיא מתאימה לשני צוותי SA שחושפים אחד לשני API במיקרו-סרוויסים שבאחריותם למשל. צוות הפלטפורמה יכול גם הוא להציע את התשתית שלו כשירות לצוותים האחרים (מישהו אמר AWS?).
תקשורת Facilitating, יעני סיוע: צוות אחד אחראי על מערכת מסוימת, בונה אותה מ-0, מתחזק אותה, ואז מעביר אותה ואת האחריות עליה לצוות אחר.
למי זה מתאים: צורת התקשורת הזו מתאימה במיוחד בין צוות SA לצוות Enabling. ה-Enabling יכול למשל לכתוב מחדש קומפוננטה עם קוד לגאסי (שבאחריות SA מסוים), ובסיום הפרויקט להעביר את הקומפוננטה המחודשת ל-SA ולהכשיר אותם לטפל בה.
סיכום
אם יש משהו אחד שאנחנו לקחנו מהספר הזה הוא שאין תחליף לארוחת צהריים ב-12:00, וגם את הצורך לעבוד במודל של צוותים עם מטרה עסקית. ברגע שמסדרים את ה-R&D בצורה כזאת, המון צווארי בקבוק נפתחים וקצב ההתקדמות של הארגון כולו משתפר פלאים.
בקיצור, ספר חמוד מאוד, ואנחנו ממליצים מאוד לקרוא אותו (נראה לכם שהם צריכים לשלם לנו על זה?).
מעניין אותנו לשמוע אילו בעיות יש בצורה שבה ה-R&D שלכם בנוי שאתם חושבים שסוגי צוותים כאלה יכולים לעזור לפתור אותן, ובכלל - ספרו לנו סיפורים, זה מעניין אותנו מאוד.
טו בשבט שמח לכולם.