חלק ב - Best Practice 1-9 בבניית צוות פיתוח מעולה - מאת * וייס שי
(המשך של חלק א - מה זה בעצם צוות פיתוח מעולה ומה תפקידו של מוביל הצוות)
טיפ מספר 1 - התמקצעות טכנולוגית.
כאשר שואלים מרואיין בראיון עבודה מה הוא בעצם מחפש במקום עבודה אחת התשובות הכי פופולאריות היא "אתגר מקצועי וטכנולוגיות חדשות".
בימינו אנו ניתן לראות שהטכנולוגיה מתקדמת בקצב מהיר וקדימה, לפי בדיקה שנעשתה טכנולוגיה נעשית מיושנת כל שנתיים ולכן יש צורך להיות עם יד על הדופק הטכנולוגי כל הזמן. הדרכים לשמירה על דופק טכנולוגי לעובדים הן די פשוטות – לשלוח עובדים לימי עיון מקצועיים, העברת הרצאות ע"י העובדים לצוות בנושאים חדשים, שילוב טכנולוגיות חדשות במשימות הפיתוח. עובד אשר ירגיש שהוא מעודכן בטכנולוגיות החדשות באופן שותף יהיה עובד שמרוצה ממקום עבודתו שמרגיש שיש לו אתגר.
טיפ מספר 2 - לאט זה מהר.
כל מוביל צוות פיתוח רוצה שחברי הצוות שלו יכירו וישלטו בנושאים השונים (טכנולוגיות, צד עסקי, סביבות...) מצב שכזה לא יקרה מעצמו, על מוביל הצוות לדעת לפתח בצוות שלו את הידע והניסיון ע"י השקעה של זמן בעובד. בעת גישה למשימות יש לתת לעובד זמן ללמוד את הנושאים לבד ולא להאכיל את העובד עם כפית. ללמד את העובד כיצד להגיע לפתרון של הבעיות ולא את הפתרון עצמו, אומנם בטווח הזמן הקצר הדבר דורש הרבה יותר זמן ומאט את קצב המשימות אבל בטווח הרחוק פעולה שכזו שווה זהב, עובד שיודע לבד לפתור בעיות ולהתמצא במערכות השונות משפר את היעילות של העובד עצמו של ראש הצוות וכפועל יוצא של הצוות כולו.
טיפ מספר 3 – לדבר בגובה העיניים.
הרבה מובילי פיתוח הם בעצם מנהלים צעירים שקיבלו על כתפיהם אחריות ניהולית ומקצועית חדשה, אחריות זו גורמת לפעמים למובילים לחטוא בחטא היוהרה וגורמת למובילי הפיתוח להסתכל על העובדים שלהם כמישהו שנמצא תחתיו, שנחות ממנו שצריך לעשות מה שאומרים לו ושלא חייב לדעת את הכול. התנהגות שכזו גורמת לעובדים לא לחשוב מחוץ לקופסא ולעשות בדיוק מה שאומרים להם ומתי שאומרים להם – צוות פיתוח מעולה לא מתנהג ככה!. בתור מוביל צוות פיתוח עליך להסתכל לעובדים שלך בגובהה העיניים, כולנו בבסיס אותו דבר, לכולם יש את המשפחות שלהם, הבית שלהם וההבדל היחידי ביניכם הוא התפקיד תהיה בן אדם, אל תדבר בגסות ובהתנשאות, מותר לך להיות חבר של העובדים שלך אבל חשוב מאוד עליך לדעת להפריד בין הצד המקצועי והאישי – אתה יכול להיות חבר שלהם אבל שזה מגיע לצד המקצועי אם אתה מבקש משהו אז העובדים צריכים לדעת לקבל את הבקשה בלי בעיות.
* טיפ זה הינו טיפ הדורש אינטילגציה רגשית גבוהה כדי שתוכל לדעת לתמרן בין הצד החברי לצד המקצועי.
טיפ מספר 4 – התחלקות בקרדיט.
יש משפט שאומר "להצלחה אבות רבים אבל לכישלון יש רק אבא אחד" לצערי זו הגישה שנהוגה היום בארגונים שונים, לטעמי גישה זו מוטעית. מנהל טוב יודע להוריד את הקרדיט שהוא מקבל כלפי מטה, להציג לרמה שמעליו את העבודה הרבה שנעשתה על ידי הצוות שלו בגאווה. חוזק המנהל נמדד כחוזק הצוות והצלחה של העובד היא בעצם הצלחה של המנהל. בתור מוביל פיתוח עליך לתת לצוות שלך לדעת ולהרגיש שאתה מעריך את ההצלחות שלהם ושמי שמעליך בארגון גם מעריך את עבודת הצוות הדרכים לבצע פעולות שכאלה הן די פשוטות - ניתן להזכיר בישיבות הנהלה את עבודת הצוות, במידה והמנהל שלך אומר לך מילה טובה תבקש ממנו שיעביר את הדבר גם לצוות, במידה וקבלת מאחד מאנשי צוותך מייל תשובה לשאלה שנשאלת ע"י המנהל שלך תעשה העברה של המייל כדי שהמנהל שלך יראה ממי הגיע המייל במקור(אל תשכח לכתב את העובד).
טיפ מספר 5 – לקיחת אחריות.
אם נרצה ואם לא, בעולם של ציוותי הפיתוח תקלות קורות ויקרו. תמיד שמתגלה תקלה השאלה השנייה שנשאלת (לאחר האם זה טופל) היא מי אחראי על הבעיה. בתור מוביל צוות תמיד תיקח אחריות על מה שצוות הפיתוח שלך עשה. תשובה לשאלה מי אחראי על זה צריכה להיות שהבעיה היא באחריותך וטיפולך ואתה תעשה את סדר הבית הנדרש אצלך. אל תיתן למי שמעליך להתערב לך בצוות. הצוות שלך ילמד להעריך אותך הרבה יותר אם הוא יידע שאתה מגבה אותו ולכן יהיה מוכן לתת לך יותר מעצמו. מצד שני אל תהיה סלחן על תקלות כלפי הצוות שלך, במידה ותקלה קורת עליך לשבת עם האחראי על התקלה להסביר לו את החשיבות וההשלכות של התקלה לבצע תחקיר של הסיבות לעניין. תחקור בצורה של "מה כן" ולא "מה לא" ומה עלינו לעשות פעם הבאה כדי למנוע הישנות תקלה שכזו. חשוב – השקעת זמן בתחקורים אלו יחסכו לנו זמן בעתיד וישפרו את התפוקה של צוות הפיתוח.
טיפ מספר 6 – שיחות צוות/מחלקה.
קביעת ישיבות צוות במועדים קבועים ישפרו את איכות ההחלטות והביצועים של הצוות יגבשו את הצוות עצמו ויתרמו לתגבור השייכות של הצוות לארגון. ישנה מתודולוגיה שלמה על איך וכיצד יש לנהל ישיבות צוות, במאמר זה מובאת על קצה המזלג מספר טיפים לישיבות צוות ע"פ ניסיוני בתחום.
תדירות ישיבות הצוות צריכה להיות אחת לשבוע או אחת לשבועיים תלוי בגודל הצוות. שיחת הצוות אמורה להיות על נושאים ארגונים-מחלקתיים כגון יעדים ומטרות, נהלים חדשים של הארגון, פרויקטים עכשווי וכל נושא אחר הנוגע לרוב אנשי הצוות. בישיבות צוות ניתן גם לדון על נושאים שונים ולשאול שאלות.
אין לאלתר את תוכן הישיבה, כדי להימנע מאלתור יש להכין agenda או רשימת נושאים לישיבה. דרך קלה ליישום agenda מסודרת היא לפתוח קובץ על שולחן העבודה במהלך השבוע להוסיף אליו דברים לפי הזמן שהם קורים, מסמך זה יהווה את הבסיס לישיבת הצוות הבאה. agenda מוכנה וברורה תגרום לישיבה עניינית ואפקטיבית אפילו ניתן להגדיל ולשלוח מראש את agenda למשתתפים כל שיוכלו להיות מוכנים לישיבה מראש.
יש להימנע מישיבות ארוכות מדי המנקזות את האנרגיה מהמשתתפים וגורמים לאיבוד עניין ואיבוד הנקודה המרכזית אותה רצית להעביר. מה גם שזה יקר (6 משתתפים * 2 שעות = יום וחצי עבודה).
במהלך ישיבת הצוות תן במה לצוות לדבר על דברים שמפריעים לו בהתנהלות היומיומית, עקוב אחרי שאלות ונושאים שעולים ועבור עליהם בישיבה הבאה אפילו אם עדיין אין לך תשובות.
אל תהפוך את ישיבת הצוות לדיון טכני דבר שיגרום לאנשים אשר אינם קשורים לנושא זה לאבד עניין בדיון.
טיפ מספר 7 – שיחות אחד על אחד.
פגישות שבועיות של אחד עם אנשי הצוות ייתנו לך אפשרות להכיר ולכסות את הנושאים השונים גם ברמה המקצועית וגם ברמה האישית. במידה ויש יותר מ 6 אנשים בצוות כדאי לבצע את הפגישות הללו אחת לשבועיים.
פגישות של אחד על אחד יתנו לכם אפשרות לשפר את יחסי האמון עם אנשי הצוות ולהכיר את הנושאים הקשורים לכל אחד מאנשי הצוות בצורה מלאה. תן לעובד להתחיל את הדיון בנושאים החשובים לו. נסה להימנע בתחילת השיחה מלדון על משימות נוכחיות וסטאטוס של דברים, במידה ועובד ממאן לדבר ניתן לדובב אותו על ידי שאלות מפתח כגון
- האם יש לך בעיות כלשהן בעבודה?
- האם יש לך רעיונות לשיפור של דברים?
- האם חסר לך משהו כגון ציוד, תוכנה, חומרה?
- האם יש לך רעיונות שהיית רוצה לשתף או לקדם?
שיחות אחד על אחד הן קרקע אידיאלית לדיון בבעיות, מתן עצה, השכמה על פתרון לבעיה ובקשה של פתרון לבעיה. העבר לעובד את המשימה בצורה ברורה אבל הימנע מלתת לו את הפתרון בצורה ברורה, תן לעובד להגיע לבד לפתרון – הדבר חשוב מאוד להתפתחות הביטחון המקצועי של העובד. בצע מעקב על הנושאים העלו בכל שיחה ועבור עליהם בתחילת השיחה הבאה.
טיפ מספר 8 – חלוקת משימות
חלוקת משימות זה חלק מהותי בתפקידך כמוביל צוות פיתוח. בדרך כלל יש נטייה לחלק משימות על פי תחומי התמחות של עובדים, צורת עבודה זו היא לרוב נכונה אך יש בה בור לא קטן, מצב של חלוקת משימות על פי התמחויות יוצר עובדים אשר מומחים בנושא מסוים (שזה דבר טוב שלעצמו), אבל מצד שני אותם אנשים לא מכירים תחומים אחרים (שזה כבר לא כל כך טוב). תאר לך שבצוות שלך יש רק אדם אחד שמכיר מודול מסוים ואותו אדם חולה, אתה בבעיה, כי אינך יכול לתת תמיכה לנושא זה, בתור מוביל צוות אפקטיבי אינך יכול להרשות לעצמך מצב כזה, אתה תמיד צריך לדעת לתת מענה לכל הנושאים. הדרך לעמוד במטרה זו היא על ידי חלוקת ידע בין מספר אנשים. כדי שמספר אנשים יכירו את אותו נושא יש לבצע חלוקת משימות נכונה.
חלוקת משימות נכונה צריכה להתחיל ביחס של 20 – 80 בזמן עומס עד למצב אידיאלי של 50-50 בזמן שקט יחסית, הכוונה היא שבשעת עומס 20 אחוז מהמשימות שעובד מקבל על עצמו הן בתחומים שהוא איננו שולט בהם ודרך הטיפול במשימות הוא יכיר אותן. בתור מובילי צוות עליכם לקחת בחשבון שעובד אשר מטפל במשימה השייכת לתחום שהוא איננו מכיר לעומק יכולה לקחת עד פי שלוש זמן מעובד שמכיר את התחום, אבל חשוב לזכור לאט זה מהר, מחר שתצטרך תמיכה לנושא הזה יהיה לך עוד עובד שידע להתמודד עם הנושא ובמידה והיה לך עומס משימות על תחום מסוים לא תתקל במצב של "צוואר בקבוק" בגלל שיש רק עובד אחד שיכול לטפל בבעיה.
טיפ מספר 9 – אחריות על משימות.
טיפ זה לדעתי הוא אחד הטיפים היותר קשים מבחינת ניהולית – הוא דורש יכולות בין אישיות גבוהות. הרעיון שעומד מאחור טיפ זה הוא לגרום לעובד לקחת אחראיות על המשימות שלו ולהרגיש מחויב לתוצרים שלו. הדרך להגיע לשביל הזהב הזה כולל מספר נקודות שמה שעומד מאחוריהן הוא ש אל לך לפחד לדרוש מהעובדים שלך, תסמוך עליהם שהם מספיק חכמים להתמודד עם דברים שגם אתה מתמודד איתם:
- דרוש מהעובד לקרוא את החומר ה אפיוני הנוגע למשימה שלו ולהכיר אותו.
- דרוש מהעובד לתכנן את המשימה, שב איתו לאשר את התכנון ותציע נקודות לשיפור במידה שיש.
- דרוש מהעובד שילמד ויכיר את הטכנולוגיה שבה הוא משתמש לפני שהוא.
- דרוש מהעובד כתיבה נכונה ואיכותית ע"פ סטנדרטים גבוהים של קוד.
- דרוש מהעובד לבצע בדיקות מקיפות של הפיתוח שלו ולוודא שלא ניזוקו מודולים אחרים כתוצאה מהפיתוח שהוא עשה.
- דרוש מהעובד בסיום הפיתוח לעבוד מול הדרישה/אפיון ולוודא שהכול עובד ע"פ הדרישה/אפיון.
- בצע סקר קוד מקיף למשימה ודרוש מהעובד לטפל בכל הנקודות שעלו בסדק קוד עד תום.
המשמעות של ביצוע הסעיפים הללו הוא זמן פיתוח רב יותר ומשימה שיכולה להסגר ב 3 ימים כנראה תיסגר ב 5 ימים, אבל – לאט זה מהר, במידה ותעבוד בצורה כזו התוצרים שתקבל מהעובד שלך הם:
- העובד ירגיש מחויבות ואחריות אישית כלפי המשימה.
- העובד יכיר את המשימה ברמה גבוהה מאוד גם בצג העסקי וגם בצד הטכנולוגי.
- המשימה תבוצע באופן מלא ע"פ האפיון/הדרישה.
- כמות הבאגים תהיה נמוכה מהרגיל.
- הקוד יהיה רשום ברמה גבוהה, דבר שיגרור תחזוקה קלה ויכולות להתמודד עם שינוים ותוספות לפיתוח בצורה קלה מאוד.
- העובד ירגיש סיפוק מהעבודה שלו בגלל שהוא אחראי על כל מכלול המשימה.
* אודות שי וייס:
וייס שי , מהנדס תוכנה.
בשנים האחרונות מתמחה בהובלת ציוותי פיתוח בסטארטאפים וחברות פיננסיות.
