איך מעבירים פרויקט לצוות אחר בלי לאבד חודש

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

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

מה באמת נתקע

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

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

מסמך ההעברה

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

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

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

מה לדרוש בחוזה מראש

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

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

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

מתי מתחילים להתכונן

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

הבדיקה הפשוטה היא לשאול בכל רבעון אם מפתח חדש יכול להריץ את המערכת לפי המסמך בלי לשאול אף אחד. אם התשובה לא, ההעברה כבר יקרה — פשוט עוד לא שילמתם עליה.

מה שהצוות הנכנס צריך לעשות

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

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

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