מי שניהל צוות מרוחק מכיר את הרגע הזה. יום ראשון בבוקר, ההודעה האחרונה בערוץ היא מיום חמישי: "ממשיך לעבוד על זה". מאז שקט. אי אפשר לדעת אם הפיצ'ר כמעט מוכן או שהמפתח תקוע מאז יום שלישי ומהסס לשאול.
הבעיה כמעט אף פעם אינה המרחק עצמו. בצוות שיושב באותו חדר המנהל קולט מידע מכל מקום: שיחת מסדרון, מבט חטוף על מסך, ההבעה של מי שנתקע. בצוות מרוחק כל הערוצים האלה נעלמים, ואם לא בנינו להם תחליף מסודר, המנהל מנווט בעיוורון. השגרה השבועית היא התחליף הזה.
כלל אחד שהכל נשען עליו: מה שלא כתוב, לא קרה
כל החלטה, כל שאלה וכל שינוי בדרישה נרשמים במקום קבוע: ticket, תגובה ב-PR או הערה בערוץ הצוות. שיחת וידאו מצוינת לפתרון בעיות, אבל בלי סיכום כתוב היא מתאדה תוך יומיים, ואז שני אנשים זוכרים אותה בשתי גרסאות.
מזה נגזרים שני הרגלים קטנים. מי שסיים שיחה כותב שתי שורות: מה הוחלט, מה הצעד הבא ומי אחראי עליו. ומי שנתקע כותב איפה בדיוק, מה ניסה ומה ציפה שיקרה. ההודעה "לא עובד לי" עולה לכולם יום עבודה. הודעה שמצורפות אליה הודעת השגיאה, צעדי השחזור ומה כבר נוסה נפתרת לא פעם בעשר דקות.
השבוע יום אחרי יום
הנה השגרה שאנחנו ממליצים עליה. היא קלה במכוון, כי שגרה כבדה מתחילים לדלג עליה כבר בשבוע השלישי.
- תחילת שבוע, תכנון (כחצי שעה): עוברים על המשימות של השבוע. לכל משימה כותבים מה אמור להיות גלוי בסופה, למשל "אפשר להיכנס למסך ההזמנות ולשמור טופס". משימה כמו "לעבוד על מודול ההזמנות" אי אפשר לבדוק, ולכן מפרקים אותה.
- כל יום, עדכון כתוב של שלוש שורות: מה נסגר אתמול, מה מתוכנן להיום, מה חוסם. העדכון נכתב בתחילת יום העבודה של המפתח ולא בסופו, כדי שחסם ייחשף לפני שנשרף עליו יום.
- אמצע שבוע, בדיקת כיוון (כרבע שעה): מסתכלים על מה שרץ בסביבת ה-staging ולא על הסטטוס ב-ticket. מה שרץ הוא האמת, וכל מה שנשאר בסטטוס "כמעט" הוא סימן שאלה.
- סוף שבוע, דמו: כל מפתח מראה בעצמו על staging מה סיים. זה דוחף לסגור דברים עד הסוף ולא להשאיר אותם ב"כמעט", ונותן למנהל המוצר הזדמנות לתפוס אי-הבנה כשתיקון עולה שעה ולא שבוע.
- שיחה אחד על אחד, אחת לשבועיים: עשר עד חמש עשרה דקות עם כל מפתח, בלי ניהול משימות. זה המקום לדברים שלא נכתבים בערוץ הפתוח: תחושת תקיעות, חוסר בהירות לגבי מה מצופה, רעיון לשיפור.
- רטרו קצר, אחת לשבועיים: שלוש שאלות: מה האט אותנו, מה משנים, מה ממשיכים. התוצאה היא לכל היותר שני שינויים קונקרטיים עם אחראי, לא רשימת משאלות.
הדמו השבועי הוא המקום שבו אי-הבנות מתגלות מוקדם. מספיק שהלקוח רואה מסך עובד, ולא רק שומע עליו, כדי שישאל "רגע, זה לא אמור להתנהג אחרת?". שאלה כזו ביום חמישי חוסכת שבוע של עבודה בכיוון הלא נכון.
השבוע הראשון של מפתח חדש שונה מהשגרה. מומלץ להקדיש לו שיחת היכרות עם המערכת ועם מי שיענה על שאלות, ומשימה קטנה ומוגדרת שאפשר לסגור תוך ימים ספורים. הניצחון המהיר הזה בונה ביטחון, ומראה לשני הצדדים אם סביבת העבודה, ההרשאות והתהליך באמת מתפקדים.
כללי עבודה קטנים שחוסכים ימים שלמים
זמן תגובה ל-review. קבעו יעד של יום עבודה אחד, ועמדו בו גם מהצד שלכם. בצוות מרוחק, כשיש הפרש שעות, review שמחכה יום מתארך בקלות לשלושה ימים של המתנה, והמפתח עובר בינתיים למשימה אחרת ומאבד הקשר. PR קטן נבדק מהר וביסודיות, PR ענק נבדק בשטחיות או יושב. לכן מבקשים PR קטנים.
הגדרת "סיימנו" אחת לכולם. הקוד מוזג, הבדיקות עוברות, הפיצ'ר נבדק ב-staging, אם שונה API יש הערת תיעוד קצרה, וה-ticket מעודכן. רשימה כזו תלויה במקום גלוי חוסכת את הוויכוח המוכר על מה זה אומר ש"זה מוכן".
חלון זמינות קבוע. שעות העבודה של הצוות מותאמות אליכם. עדיין כדאי להגדיר חלון קבוע שבו מי שמחליט בצד שלכם זמין לשאלות מהירות בצ'אט. שאלה שמקבלת תשובה תוך שעה שומרת על רצף העבודה, ושאלה שנשארת פתוחה עד מחר עוצרת משימה.
כתובת אחת לשאלות מוצר. שאלה של מפתח על התנהגות המערכת חייבת לקבל תשובה משם מסוים, לא מ"מישהו מהמוצר". מפתח שמחכה לתשובה עובר למשימה אחרת, וה-ticket החסום מסומן ככזה כדי שלא ייעלם.
חסם מדווחים מיד, לא במפגש הבא. אם חסם מחכה לסטנדאפ של מחר, עלות ההמתנה היא יום. לכן העדכון היומי כולל שורה ייעודית לחסמים, והנורמה בצוות היא שמי שמדווח על חסם מתוגמל בתגובה מהירה ולא בשאלת "למה לא חשבת על זה קודם".
מה כדאי למדוד, ומה לא
מספר שעות ישיבה וכמות הודעות בערוץ הם מדדים שקל לשחק בהם, ואין להם קשר לתוצר. שלושה מדדים שימושיים יותר:
- זמן ממוצע מתחילת משימה ועד מיזוג. מגמת עלייה אומרת שמשהו נתקע: בדרישות, ב-review או בסביבה.
- כמה משימות חוזרות מבדיקה עם בעיות. אם זה קורה שוב ושוב באותו סוג משימות, כמעט תמיד הבעיה באפיון ולא במפתח. על זה כתבנו באיך כותבים אפיון שמפתחים באמת מבינים.
- כמה זמן PR מחכה ל-review. המדד הזה נמדד אצל הלקוח כמעט באותה מידה כמו אצל המפתחים.
מי מחזיק את השגרה
במודל הרחבת הצוות המפתחים מצטרפים לצוות שלכם, ואתם מנהלים את העבודה, כך שהשגרה הזו יושבת אצלכם. אם אין לכם מנהל שיכול להקדיש לה זמן, אפשר להוסיף כשירות נוסף מנהל מישראל. במודל מיקור החוץ אנחנו מנהלים את העבודה מול תוכנית עבודה עם לוחות זמנים מחייבים, והשגרה היא חלק מהשירות.
כשצוות מרוחק מתקדם לאט, הסיבה היא בדרך כלל לא המפתחים. בדרך כלל זה זמן ההמתנה: לתשובה, לאישור או ל-code review. שינוי קטן בשגרה, כמו עדכון יומי כתוב או התחייבות לענות על review בתוך יום עבודה, משפר את הקצב יותר מכל תוספת של אנשים.
השורה התחתונה
צוות מרוחק שמנוהל היטב נראה משעמם מבחוץ, וזה סימן טוב: אותם עדכונים, אותו דמו, אותו קצב. זה המצב הרצוי, כי הוא מאפשר לראות חריגה ביום שהיא נולדת ולא שלושה שבועות אחריה. מי שמתחיל עם שגרה ברורה מקבל שליטה, ומי שמחכה שהבעיות יקרו קודם מגלה אותן ברגע הכי פחות נוח. השגרה נבנית בשבוע הראשון, וקל יותר להתחיל איתה מההתחלה מאשר להכניס אותה לצוות שכבר התרגל לעבוד אחרת.
אם אתם שוקלים להרחיב את הצוות שלכם, אפשר לקרוא איך נראה מודל הרחבת הצוות ומה המנהל הנוסף מישראל מוסיף לו.
