מה קורה במחלקת הפיתוח בשלב ה- SCALE?
הרבה פעמים כאשר מדברים על SCALE של מחלקות פיתוח מדברים על תשתיות המוצר שצריכות לתמוך בבת אחת במספר משתמשים גדול בהרבה או על הצורך לפתור בבת אחת הרבה חובות טכניים שהצטברו. אבל כאשר אנחנו עושים Scale למחלקות פיתוח, ישנם כמה שינויים ארגוניים אקוטיים שקורים לחבריה וכדאי לשים אותם על השולחן כדי לדעת לעשות את קפיצת המדרגה בצורה הנכונה. להלן המרכזיים שבהם:
- “אני כבר לא יודע מה עושים בחדר לידי” – הסנכרון בין הצוותים נהיה מורכב: מקבוצה שרגילה לעבוד ביחד ולהתכנס מספר פעמים כדי להיות מסונכרנים על מה עובדים, פתאום הקבוצה נהיית גדולה מדי ולא כולם יודעים מה האחרים עושים, נדרשים הרבה מאוד פגישות בין הרבה מאוד אנשים כדי לייצר תמונת מצב טובה ואז יכולת הסנכרון נפגעת וכמות הפגישות עולה.
- “אני צריך לרדוף כדי לקבל את כל המידע שאני צריך כדי לפתח” – מידע לא זורם בקלות: בעבר התקשורת היתה שוטפת והההיכרות של כל איש צוות היתה מאוד רחבה. ככל שיריעת העבודה גדלה, ההתמקצעות גדולה ומספר ממשקי העבודה גדל ובהתאמה ידע שעבר עד כה בקלות בין האנשים, לא משוקף בשום מקום ולכן צריך לעבוד יותר קשה כדי להשיג אותו.
- “האם כולם עובדים על הדברים הנכונים?” – שיקוף התעדוף ושיקוף משימות באופן רחב: ההנהלה שעד כה הכירה כל משימה ומשימה של כל אחד מהמפתחים פתאום מוצאת שמספר המפתחים גדול מדי והיא לא יודעת מה כל אחד עושה ומהצד השני המפתחים לא תמיד יודעים להתמקד בדבר הנכון ביותר לחברה.
- “מה יהיה מוכן מתי?” – שיקוף לוחות זמנים צפויים: מורכבות המוצר עולה, יותר אנשים עושים חלקים יותר ספציפיים במוצר ונהיה פחות ברור מתי מדלוורים בפועל תוצר מוגמר.
ישנם נושאים מרתקים נוספים כמו “רק אנשים מסוימים יודעים לפתור באגים מסוימים”, “איך נוכל לפתוח tier 2? הפתרונות אצלנו דורשים הבנה עמוקה במוצר” או “למה הכפלנו את כמות המפתחים והורדנו בחצי את הדליברי” שעולה לא מעט בקרב ההנהלה – שכל אחד מהם ראוי לפוסט משל עצמו.
אז מה צריך לקרות בשלב זה?
בשלב הזה נכנסים לפעולה תהליכים אסטרטגיים ארוכי טווח שכמו האמירה המפורסמת צריכים להתחיל בצעד קטן אחד ומטרתם להפוך את הסינרגיה שהיתה קיימת בקרב הקבוצה הקטנה של האנשים לסינרגיה של קבוצה גדולה בהרבה. כיצד עושים זאת?
- יצירת שפה אחידה: ככל שמתרבים האנשים העובדים במחלקות אלו, ובעיקר כאשר מצטרפים עוד ועוד אנשים חדשים, יש צורך ביצירת שפה אחידה לכולם. כאשר אני מסמנת באג בעדיפות: “Critical”, אני צריכה שזה יגיד אותו דבר לכולם – מה זה אומר על דחיפות התיקון. כאשר אני מעריכה את משך זמן הפיתוח ב- 3 ימים, צריך להיות ברור לכולם האם הערכת זמנים זו כוללת גם את זמני הבדיקה או לא. וכך הלאה. תרגיל נחמד שעוזר למפות את השפה: לקחת את השדות המרכזיים בג’ירה (או כל מערכת אחרת..) ולשאול את עצמנו להגדרות שלהם. ספרינט- מהו לוח הזמנים של ספרינט? מה המשך שלו? האם הוא אחיד לכולם?
- האחדת תהליכי עבודה וסנכרון לוחות הזמנים: הרבה צוותים הולכים ומפתחים לעצמם שיטות עבודה משלהן שמאפשרות מיקסום על מהירות ונוחות מקומיים. כאשר הולכים וגדלים, חלק מהתהליך הוא יצירת אחידות של תהליכי העבודה: “כל הצוותים עושים Pre Planning”, כדי שלבסוף תיווצר תמונה ברורה להנהלה של מהם התוצרים הצפויים מהספרינט. “כל הצוותים פותחים באגים בצורה מסוימת”, כדי שכל מי שנכנס לבאג ימצא בו את כל המידע הרלונטי לפיתרון ובצורה ברורה דחיפות הפיתרון. וכך הלאה. אפשר לסמן את רשימת תהליכי המפתח ולייצר סטנדרט: איך נראה תהליך תכנון, איך נראה דיווח של באג, איך נראית תקלה שמגיעה מלקוח וכו’.
- הגדרות תפקידים ברורים: עד לאחרונה, כולם עבדו ועשו “מה שצריך”. ככל שהמחלקות גדלות, צריך לייצר רשימת בעלי תפקידים והגדרה ברורה של מי עושה מה. ברוב המקרים, ישנן הגדרות תפקיד מקובלות על חלוקת האחריות בין אנשי המוצר, הפיתוח והפרויקטים והחלק החשוב הוא לוודא שגם ההגדרות מקובלות אבל גם ברורות מבחינת אחריות הביצוע, מי מקבל את ההחלטה ומי מטמיע במערכות המידע: אוקי, אבל מי מעדכן את הטיקט? מי מחליט בסוף מה עושים בספרינט?
- מידע צריך להיות מועבר בצורה א-סינכרוני: הורדת הצורך בשיחות ותקשורת סנכרונית על מנת לקבל מידע ולהתעדכן. כדי לדעת סטאטוס של משימה – זה צריך להיות מעודכן במערכת ניהול המשימות. כדי להכיר מהם הדברים שבהם כל החברה צריכה להתמקד לתקופה הקרובה- זו רשימה שצריכה להיות נגישה לכולם.
- יצירת התמונה הגדולה / מעבר לעבודה בדשבורדים: שינוי זה טומן בחובו תהליך שחרור מדורג בעיקר בקרב ההנהלה אודות אופן הפעולה השוטפת. לא עוד – לדעת כל מה שקורה לפרטי פרטים בעצמי, אלא היכולת להתבסס על תמונה אגרגטיבית להתמקד רק במקומות שדורשים תשומת לב, שיש בהם נורות אזהרה כמו פעילויות שלא מתקדמות ועשויות להעיד על היתקעות בתהליך או צוואר בקבוק. כמה באגים נפתחו לעומת נסגרו ובהתאמה הבנה האם הפערים הטכניים שאנחנו צוברים הולכים ותופחים בצורה לא סבירה?
אז איך גורמים לכל התהליכים הללו לקרות? איך מביאים את קבוצת האנשים הגדולה הזו לעבוד כמכונה משומנת?
כאשר עושים SCALE, פתאום צריך להעביר הרבה שינויים בשיטות העבודה בבת אחת לקבוצה מאוד גדולה של מפתחים, ראשי צוותים, אנשי מוצר, תמיכה טכנית וכו. צריך לייצר המון תהליכים ולהטמיע אותם במערכות המידע. איך גורמים לתהליכים להיות מוגדרים כהלכה ומגיעים לכל האנשים ומוודאים שהתהליכים אכן הוטמעו? זה כמובן התמקצעות מורכבת שכל הבלוג הזה סובב סביבה, אבל אפשר לדבר על כמה קווים מנחים להטמעת השינויים שיכולים לעזור לתהליך להיות אפקטיבי יותר.
ראשית כל, פרופורציה של זמן: בתוך מערכת שמשתנה באופן אקספוננציאלי, בני האדם ממשיכים להשתנות באופן לינארי. זה אומר שהתהליכים וההטמעה לוקחים זמן רב ושהאפקט שלהם הוא אפקט מושהה, שלוקח זמן להרגיש אותו ביום יום. זה אומר בפועל שכל יום כשקמים בבוקר, מרגישים שחיים בכאוס אבל בהסתכלות של 3 חודשים אחורה כל פעם, מבינים את הדרך שנעשתה. פרק הזמן המוערך הוא בין שנה לשנתיים בארגונים בסדר גודל בינוני עד שהתהליכים מתייצבים באופן משמעותי וקצב השינויים פוחת.
שנית, אי אפשר לטפל בכל הפערים (הרבים!!) בבת אחת ולכן יש להתמקד בכאבים הגדולים תחילה: תהליכים שהכי כואבים לכולם, שגורמים להכי הרבה חוסר נחת. הרבה פעמים זה הדברים הגדולים כמו- איך מעריכים משימות, היקף ושמות הספרינטים וכו’ ולאחר מכן תהליכים קונקרטיים כגון תהליך התכנון של הספרינט או אופן פתיחת הבאגים בעיקר בין צוותים.
שלישית, יצירת מחוייבות של האנשים על ידי העלאת המודעות לצורך ותקשורת שוטפת. קורים הרבה מאוד תהליכים ושינויים במקביל – זה דורש מהרבה אנשים שהתהליכים יהיו שונים ממה שהתרגלו, ולפעמים פחות נוחים משהורגלו – פתאום מכריחים למלא שדות רבים יותר ולעמוד בפגישות קבועות שלא היו מחוייבות בעבר. הצפה ושיח על עצם הצורך בתוך פגישות חברה ושיקוף של כל הצעדים שנעשו והתועלת שנמצאת בהם, מאפשרת לייצר מחויבות בשטח כאשר מבקשים מהאנשים לשנות בפועל את הרך העבודה. שיקוף מתמיד של השינויים שבוצעו ואחת לתקופה על השינויים הגדולים שהתרחשו תיתן חיבור לתועלת ומוטיבציה.
רביעית, תהליכים משתנים לרוב בצעדים קטנים. נכון, היינו רוצים לקחת ישר את התהליך היפה ששרטטנו אותו בשקפים וישר לשנות דרסטית את כל הדרך שבה אנו עובדים. אבל אם אנחנו רוצים לייצר שינוי תוך כדי תנועה, אנחנו כל פעם מכניסים שינוי אחד. עדיף כזה שמשוקף במערכות המידע ונאכף טכנולוגית.
חמישית, התהליכים חייבים להיות משוקפים במערכות המידע. שמות השדות צריכים לשקף את המינוחים האחידים והשדות עצמם לשקף את תהליך המתבצע. כל אכיפה טכנולוגית של שדות מסוימים תביא להטמעה מהירה וטובה יותר. לדוגמא, אם עשינו תהליך שבו אנחנו מטמיעים את שלבי הפיתוח, אז כל שלב משוקף בסטאטוס והעברה בין סטאטוסים דורשת אישור של שדה שמסמן שה- GATE למעבר בין שלבים בוצע. הבאה של אדם ייעודי להטמעת תהליכים במערכות המידע שיש לו ידע מעמיק ביכולות של המערכת להגדרות מורכבות ואוטומציות שמקלות על העבודה יכולה להיות מקפצה משמעותית ביכולת הטמעת השינויים.
שישית ואחרון – מובילי וסוכני השינוי – צוות ה- Engineering Ops. צוות זה מכיל בהגדרתו נציגי אופרצית פיתוח מכל הצוותים. ולכן ערוץ הטמעת השינויים העיקרית היא דרך צוות ייעודי שלוקח את השינויים ודרכי העבודה החדשות לצוותים השונים. אנשי הצוות מגיעים מרקע תהליכי ועם הידע אודות “איך העבודה אמורה להיראות” ויש להם את המנדט לעזור לצוות לעבוד בצורה נכונה. יתר על כן, הם מעורים בעבודת היום יום ולכן מבינים את המורכבויות הייחודיות של הצוותים וגם נמצאים בפגישות השונות ולכן יכולים להטמיע בפועל את התהליכים החדשים. ובנוסף לכל אלו – חלק ממטרת עבודתם ממוקדת בשיפור העבודה בצוותים ולכן הם יכולים להקדיש את הזמן הנדרש מבחינת יצירת התשתיות, הדרכות והטמעה במפגשים אישיים. וגם לזהות ולסמן תהליכים נוספים הבאים בתור שדורשים שיפור וסנכרון.
לסיכום, תהליך הגידול של מחלקת פיתוח הוא תהליך מורכב ומשמעותי שלוקח זמן רב. הגידול עצמו מורכב מהרבה מאוד מרכיבים שונים שצריכים להתייצב יחד לכדי מקשה אחת וכולל גם שינויים דרמטיים באופן העבודה בצוותים, בתפיסות הניהול ושיטות העבודה של ראשי הצוותים ומעלה וביישום שינויים רחב במערכות המידע. התהליך הזה מובל על ידי צוות ה- Engineering Operations בתור מוקדי הידע וסוכני השינוי של התהליך.
האם גם אתם אנשי אופרציה העוסקים בתהליכי עבודה, מתודולוגיות וכלים בעולמות הפיתוח? אם כן, נשמח שתצטרפו לקבוצת Engineering Operations בוואטסאפ ותעקבו אחרינו בעמוד ה- Linked In שלנו.