מנהל R&D בישראל מצרף את המפתח המרוחק הראשון שלו. הוא שולח לו הודעה בבוקר עם משימה בשתי שורות, ומקבל בערב קוד שעובד בדיוק לפי מה שכתב, ובכל זאת לא מה שהתכוון. הוא מתעצבן, המפתח מתבלבל, ושניהם בטוחים שהצד השני לא הקשיב.
המטה שלנו נמצא בישראל ומרכז הפיתוח בפיליפינים. כאן מה שלמדנו על מה שמבדיל בין צוות מרוחק שעובד לבין צוות שרק עולה כסף. רובו חל על כל צוות מרוחק בכל מקום, והמיקום משפיע בעיקר על חלק קטן ממנו.
תקשורת ומשימות
1. העבודה הכתובה היא הממשק
כשצוות יושב בחדר אחד, שאלה עוברת במשך עשר שניות ליד המטבחון. כשהצוות מרוחק, אותה שאלה היא הודעה, תשובה אחרי כמה שעות, ושאלת המשך. מה שהיה פער זניח הופך לעיכוב של יום.
לכן אצלנו המשימה נכתבת כך שאפשר לבצע אותה בלי לשאול: מה הבעיה, איפה בקוד נוגעים, איך נראה מצב סופי תקין, ואיך בודקים. משימה של שתי שורות מתאימה לשני אנשים שיושבים ביחד. למפתח מרוחק היא מפת דרכים עם חורים.
הלקח המעשי: אם משימה לא עוברת "מבחן הזר", כלומר מפתח שלא היה בשיחה הקודמת יכול להבין אותה, היא לא מוכנה להעברה.
2. הגדרת "גמור" חייבת להיות מפורשת
אחת הסיבות הנפוצות לתסכול בצוותים מרוחקים היא פער בין "סיימתי" ל"זה מוכן". מפתח אחד מתכוון שהקוד כתוב. מנהל מתכוון שהוא נבדק, נבדק שוב על סביבה אחרת, ונוסף לו תיעוד.
כדאי לכתוב את ההגדרה פעם אחת ולתלות אותה בראש ה-board: קוד נבדק, בדיקות עוברות, יש review, התיעוד עודכן, והפיצ'ר רץ בסביבת הבדיקות. מרגע שהיא כתובה, הדיון הופך מ"למה לא סיימת" ל"איזה סעיף חסר".
ברוב המקרים, אי-הבנה בין לקוח למפתח לא נובעת מרמה מקצועית. היא נובעת ממשימה שנכתבה בקיצור, עם הנחות שהיו ברורות רק לכותב. כשמוסיפים לכל משימה שתי שורות של "מה נחשב גמור" ודוגמה אחת, מספר הסבבים חוזרים יורד, והשיחות הופכות קצרות יותר.
אנשים וקליטה
3. ותק מקצר את הדרך
אנחנו לא מגייסים מפתחים עם פחות מחמש שנות ניסיון. הסיבה פרקטית: מפתח ותיק יודע לזהות מה לא ברור במשימה ולשאול בזמן, ומי שמתחיל את הדרך נוטה לנחש. בצוות מרוחק, ניחוש עולה יום שלם.
כל מועמד עובר אצלנו שני ראיונות, אחד של משאבי אנוש ואחד טכני. רק מי שעבר אותם מגיע לראיון אצל הלקוח. הלקוח לא מבזבז זמן על מי שלא עמד ברף, והוא עדיין מחליט בעצמו מי מצטרף אליו.
4. הקליטה קובעת את החודש הראשון
מפתח חדש שמקבל גישה לריפו ו"תתחיל להסתכל" יבזבז שבועיים. מפתח שקיבל מראש רשימה כזו מתחיל לעבוד מהר יותר:
- מסמך קצר שמסביר את הארכיטקטורה ואת ההחלטות שלא הגיוני לשנות.
- סביבת פיתוח שמתקינים ומריצים לפי הוראות כתובות, ולא לפי "תשאל את מי שהיה פה".
- משימה ראשונה קטנה, עם בדיקה ברורה, שעוברת את כל זרימת העבודה עד פרודקשן.
- אדם אחד מצד הלקוח שאפשר לפנות אליו בשאלות בשבועות הראשונים.
זו גם הזדמנות לבדוק את הצד שלכם: האם המסמכים מעודכנים, האם הגישות מוכנות מראש, האם ה-pipeline עובד כפי שחשבתם. מפתחים חדשים הם בודקי תהליך מצוינים, כי הם קוראים הכל בפעם הראשונה.
המשימה הקטנה הראשונה חושפת בעיות בגישות, בהרשאות ובתהליכי ה-CI כשהמחיר שלהן עדיין נמוך. עדיף לגלות אותן ביום השלישי מאשר בשבוע השלישי.
שגרה וניהול
5. שעות עבודה: מתאימים לצוות, אבל מתכננים לא-סינכרוני
שעות העבודה אצלנו מותאמות ללקוח. אבל גם כששעות העבודה מתואמות היטב, צוות מרוחק שנשען על שיחות בלבד יתקשה ביום שבו מישהו חולה או שהשיחה נדחתה. המשמעות המעשית:
- סבב יומי קצר, כתוב או בשיחה, שבו כל אחד מעדכן מה עשה, מה הוא עושה עכשיו ומה חוסם אותו.
- החלטות שמתקבלות בשיחה נרשמות בערוץ, כדי שמי שלא היה שם לא יצטרך להסתמך על זיכרון של אחרים.
- שאלות חוסמות מסומנות כחוסמות, ויש מי שאחראי לענות עליהן באותו יום.
תחזוקה של השגרה הזו דורשת משמעת מצד שני הצדדים, ולכן כדאי שמישהו אחד אצלכם יהיה אחראי עליה. אחרת היא דועכת אחרי שלושה שבועות, בדיוק כשהיא מתחילה להועיל.
מי שבונה את העבודה כך מגלה שהיא עמידה גם בשגרה רגילה ולא רק בימים טובים.
6. ללמוד לשמוע "כן" שאינו הסכמה
בכל צוות מרוחק, "כן" בשיחה יכול להיות "הבנתי", "אשתדל" או "מקובל עליי". זה קורה גם בצוותים הכי טובים, כשלא רואים את הפנים של מי שמולך. התיקון פשוט: מבקשים סיכום כתוב בסוף כל החלטה, ושואלים שאלות פתוחות במקום שאלות שעונים עליהן בכן או לא. "איך אתה מתכנן לגשת לזה" חושף יותר מ"ברור?".
כדאי גם להסביר מראש שמצפים לשמוע על חששות ושעדיף להעלות אותם מוקדם. מפתח שמרגיש בטוח להגיד "לא נראה לי שנספיק" ביום השני חוסך לכם שבועיים.
7. לא להשאיר את הניהול ריק
זה הלקח שהכי קל לפספס, כי הוא לא נראה כמו בעיה בשבוע הראשון.
צוות של מפתחים טובים בלי מי שמתעדף נראה עסוק ומתקדם לאט. בהרחבת צוות הניהול נשאר אצל הלקוח, ולכן צריך לתכנן אותו: מי בצד שלכם מתעדף, מי מאשר, מי עונה. מי שלא יכול להקדיש זמן כזה יכול לרכוש כתוספת מנהל מישראל, או לעבור למודל שבו אנחנו מנהלים. ההבדל בין המודלים מפורט במאמר על הרחבת צוות מול מיקור חוץ.
כדאי לסכם את המשותף לשבעת הלקחים: כולם עוסקים בהפיכת ידע שבראש של אדם אחד לדבר כתוב ושיתופי. צוות שמצליח לעשות את זה בקלות מתפקד גם כשמישהו בחופשה, וגם כשמצרפים אליו מפתח חדש.
הצד המשפטי והמעשי
הסדר הזה חשוב לצוותים שרגישים לשאלה מי מעסיק את מי, ומה קורה עם מידע רגיש.
המפתחים מועסקים אצלנו בפיליפינים ולא אצל הלקוח. אם הלקוח מבקש, העובד חותם גם על NDA. על נושאי אבטחת מידע וקניין רוחני כתבנו בנפרד במאמר על עבודה עם צוות חיצוני.
החודש הראשון הוא חודש ניסיון בתשלום, ואנחנו ממליצים להשתמש בו ככלי מדידה אמיתי: להגדיר מראש שלוש משימות ולבדוק איך נראית התקשורת, איכות הקוד והיכולת לשאול שאלות טובות.
השורה התחתונה
מה שקובע אם צוות מרוחק יצליח הוא איכות המשימות, הגדרות ברורות ל"גמור", קליטה מסודרת ומפתחים עם ניסיון. המיקום הגיאוגרפי הוא שיקול משני, והחיסכון של 25% עד 40% לעומת גיוס מקומי שווה הרבה יותר כשהשגרה הזו קיימת. מי שמשקיע בה מקבל צוות שעובד, וגם כזה שקל להרחיב.
אם אתם שוקלים לצרף מפתחים לצוות שלכם ולנהל אותם בעצמכם, התחילו מהעמוד על הרחבת צוות.
