מעבר לחברת פיתוח חדשה: מה צריך לקבל, לבדוק ולמסור?

מה מטרת המעבר — ומה הגבולות שלו

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

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

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

מאפיין קוד, נתונים ותשתית: טבלת הנכסים

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

מה בודקים לפני קבלת אחריות?

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

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

מתכננים מעבר מדורג

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

איך יודעים שהמסירה הושלמה?

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

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

מתי להמשיך ומתי לשדרג?

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

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

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