כך אפשרנו לצוותי הפיתוח שלנו לגדול – ואפילו הצלחנו לשמור על היצירתיות שלהם

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

מתודולוגיית Core Vs. Playground מתאימה לכל ארגון וסביבת פיתוח (צילום: dreamstime)

מאת חן סלומון, מוביל קבוצת Framework במחלקת הפיתוח, monday.com

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

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

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

הכל נגיש לכולם

בשלב הראשון של האסטרטגיה מיפינו את הפיתוח לשלוש רמות על פי ה-Level of concerns: בליבה נמצאת רמת הפיתוח, מעליה רמת ה-R&D ובמעגל הרחב ביותר – רמת החברה. לכל רמת אחריות שייכנו משפחות של משימות כגון Maintenance debt ,Developer efficiency ,Stability ,Security Technical product ו-Decision debt. הנחת היסוד הייתה שארכיטקטורת התוכנה (ברמת החברה הגבוהה ביותר) אמורה להתוות סטנדרטים, קווים מנחים ודרכים להתקשרות יעילה בין בעלי העניין, וגם לעודד יצירתיות ועבודת צוות. בשתי הרמות שמתחתיה הגענו לחלוקה המטריציונית.

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

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

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

העומסים פחתו והיצירתיות נסקה

לשינוי המהותי הזה בניהול משימות הפיתוח יש תנאי חשוב: שה-Core המוצרי יהיה טוב, נהיר ובר שימוש נרחב, שאכן יאפשר ליתר הצוותים להסתפק ב-Playground. ברירות המחדל צריכות להיות חכמות, אבטחת המידע חייבת להיות מובנית וכך גם הבקרה. משום כך, כדי לנסות את ה-Core בדקנו את ה-Playground: כינסנו Hackathon test וביקשנו מכלל המפתחים לממש את הלוגיקה וליישם את הפיצ’ר. השקנו גם סדרה של Hackathon apps בעזרת מפתחים חיצוניים לארגון: הם קיבלו מאיתנו API כדי לבדוק אם התשתית טובה ומספיקה גם להם, כמי שהגיעו לפיצ’ר “טאבולה ראסה”, באופן נקי מידע ארגוני קודם. הם יצרו אפליקציות על בסיס הפלטפורמה – וזה עבד.

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

מתודולוגיית Core Vs. Playground מתאימה לכל ארגון וסביבת פיתוח, ולא רק לחברה גדולה ורוויית צוותים. כשיש Owner לכל פיצ’ר במוצר שצולל הכי לעומק שאפשר, ושאר צוותי הפיתוח מסונכרנים על המינימום ההכרחי מבחינתם, תוך הקפדה על כך שלא נוצרים פערי ידע שפוגעים בניהול ובתפקוד השוטף ואין משימות שנופלות בין הכיסאות – זו דרך טובה ויעילה ל-Scale מוצלח ושפוי.

הכתבה בחסות monday.com

מאנדיי היא מערכת הפעלה לעבודה (Work OS), באמצעותה ארגונים בכל סדר גודל יכולים ליצור את הכלים והתהליכים הדרושים להם לניהול כל היבט בעבודתם. מאנדיי מאפשרת דרך יעילה ואינטואטיבית לניהול צוותים, פרויקטים, תהליכים עסקיים, אופרציות מורכבות ומאפשרת לצוותים להצטיין בכל היבט בעבודתם. למאנדיי צוותים בתל אביב, ניו יורק, סן פרנסיסקו, מיאמי, שיקגו, לונדון, קייב וסידני. הפלטפורמה מאפשרת התאמה אישית כך שתתאים לכל תעשייה וכיום משמשת מעל ל- 127,000 לקוחות בלמעלה מ- 200 תעשיות ביותר מ -190 מדינות. לעמוד המשרות שלנו, לחצו כאן.

כתב אורח

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

הגב

2 תגובות על "כך אפשרנו לצוותי הפיתוח שלנו לגדול – ואפילו הצלחנו לשמור על היצירתיות שלהם"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.

סידור לפי:   חדש | ישן | הכי מדורגים
ג\'ון
Guest

כתבה מצויינת (לא קורה הרבה, לצערי).
תודה רבה

גיא
Guest

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

wpDiscuz

תגיות לכתבה: