اگر پیمانکار یا نفر کلیدی تیم ناپدید شود، چه می‌شود؟
برنامه‌نویسی که سه سال سامانه‌تان را ساخته، دو هفته پیش گفته مهاجرت می‌کند. یا پیمانکاری که همه‌چیز را در دست داشت، چند ماه است دیر جواب می‌دهد و حالا اصلاً جواب نمی‌دهد. یا شرکتی که قراردادتان را با آن بسته‌اید، دیگر آن شرکت نیست.
هیچ‌کدام از این‌ها نادر نیست و هیچ‌کدام از آن‌ها عیب «پیمانکار بد» نیست. در شرکت بزرگ، نفر کلیدی می‌رود. در شرکت کوچک، شرکت می‌ماند و آن نفر هم می‌رود. هیچ ساختاری ریسک را صفر نمی‌کند.
چیزی که واقعاً فرق می‌کند، این است که آن روز، سامانهٔ شما چقدر زنده بماند.
این مقاله دربارهٔ همان است: چه چیزی را باید از روز اول داشته باشید که اتفاق بدی که قطعاً ممکن است، فقط بد باشد و نه فاجعه. مقالهٔ وابستگی به تأمین‌کننده از انواع وابستگی و آزمون خروج سالانه گفته؛ این‌جا سناریوی اضطراری است.
سه جور ناپدید شدن
نفر کلیدی می‌رود. پیمانکار هنوز هست، ولی کسی که سامانه را می‌فهمید نیست. تأخیر و سردرگمی، نه توقف.
پیمانکار ساکت می‌شود. نه اعلام کرده، نه جواب می‌دهد. شما نمی‌دانید موقت است یا نه.
پیمانکار منحل می‌شود یا قطع همکاری می‌کند. اختلاف حقوقی یا تجاری، یا بسته شدن شرکت.
در هر سه، سؤال یکی است: با آنچه الان دستتان است، می‌شود ادامه داد؟
آنچه باید دستتان باشد
این فهرست را به‌عنوان کمینهٔ «زنده ماندن» بخوانید، نه مستندسازی کامل:
۱. حساب‌ها. دامنه، سرور، مخزن، فروشگاه اپلیکیشن به نام شما (برای همین موضوع مقالهٔ جداگانه‌ای داریم). بدون این، بقیه فهرست بی‌معناست.
۲. همهٔ کد، شامل چیزهایی که کد به نظر نمی‌رسند. اسکریپت ساخت و انتشار، پیکربندی سرور، فایل‌هایی که تعیین می‌کنند محیط‌ها چطور راه می‌افتند. سامانه‌ای که فقط روی لپ‌تاپ یک نفر «ساخته می‌شود»، در واقع تحویل نشده.
۳. یک سند «چطور راهش می‌اندازیم». نه صدها صفحه؛ یکی دو صفحه که بگوید کد کجاست، چطور اجرا می‌شود، چطور منتشر می‌شود، چه سرویس‌های بیرونی دارد، و رمزها از کجا می‌آیند. اگر یک برنامه‌نویس تازه نتواند با این سند سامانه را روی سیستم خودش راه بیندازد، سند ناقص است. (مستندات نرم‌افزار، و مستندسازی زیرساخت جزئیاتش را دارند.)
۴. دانش در بیش از یک سر. بپرسید هر بخش سامانه را دست‌کم دو نفر دیده‌اند؟ اگر یک نفر همه‌چیز را می‌داند، آن نفر خودش خطر است، نه فقط یک آدم خوب.
۵. راهی برای اینکه بدون پیمانکار هم بتوانید بازیابی کنید. نسخهٔ پشتیبان در جایی که شما دسترسی دارید، و تجربهٔ اینکه واقعاً بازیابی‌شده — نه اینکه هر شب گرفته می‌شود.
۶. یک بند قرارداد. اگر قرارداد دارید: مدت اخطار برای قطع همکاری، و تعهد به همکاری برای انتقال دانش در آن مدت. در فهرست بندها هست؛ فقط مطمئن شوید که نوشته شده، نه قرار شفاهی.
پنج سؤال از پیمانکار
این‌ها را در جلسهٔ اول بپرسید، نه وقتی بحران آمده. و از هر پیمانکاری، از جمله ما.
- اگر مسئول فنی پروژه وسط کار برود، چه کسی جایش را می‌گیرد و چطور؟
- چند نفر از تیم سامانهٔ ما را دیده‌اند، و می‌توانم با آن‌ها صحبت کنم؟
- کد را چه کسی به‌جز نویسنده‌اش بازبینی می‌کند؟
- مستندات را کی و چطور تحویل می‌دهید، و با چه آزمونی می‌فهمیم کافی است؟
- اگر فردا بخواهیم همکاری را تمام کنیم، در روز اول چه چیزهایی به ما می‌رسد؟
پاسخ روان و مشخص، نشانهٔ خوبی است. پاسخی که از «ما این مشکل را نداریم» شروع شود، نه.
اگر اتفاق افتاده
اول، چیزهایی که فوراً مهم‌اند:
- دسترسی‌ها. هر چه به نام شما نیست، همین امروز اولویت دارد. به ترتیب: دامنه، سرور، مخزن.
- یک نسخه از همه‌چیز. کد، داده، پیکربندی؛ جایی که شما دسترسی دارید.
- نگران نشوید که کد را کسی نمی‌فهمد. یک مهندس باتجربه معمولاً در زمانی کوتاه می‌تواند بگوید وضع چطور است. نخستین کار را ساختن نیست؛ ارزیابی است. (برای همین، بازبینی مستقل یک راه معقول است حتی پیش از هر بحران.)
- نوشتن آنچه می‌دانید. هر چیزی که از حافظهٔ آدم‌های خودتان می‌آید: چه چیزی کجا بود، چه چیزی قرار بود شود.
بعد، نظم بدهید: یک نفر از طرف شما «نگهبان فنی» باشد، حتی اگر فنی نیست. کسی که می‌داند حساب‌ها کجاست و با چه کسی تماس بگیرد.
برای نگه داشتن
سامانه‌ای که قابل اتکاست، سامانه‌ای نیست که هیچ‌وقت آدمی را از دست نمی‌دهد. سامانه‌ای است که اگر دست‌اندرکارش برود، شما فقط کمی زمان می‌خواهید تا بفهمید چه کار باید کرد.
شش مورد بالا را کنار سامانه‌تان بگذارید و ببینید کدام جاست. جای خالی هر کدام، کار فردای شماست.