علامات تدل على أن منتجك الأولي يحتاج إنقاذاً، وماذا تفعل في أول أسبوعين
المواعيد الفائتة والإصدارات الهشة والفريق الذي لا يمكن استبداله أعراض لا أسباب. يبدأ الإنقاذ الهادئ خلال أسبوعين بالوصول والحقائق وإصدار مستقر واحد، قبل أي إعادة كتابة.
في هذه الصفحة
نادراً ما تفشل المنتجات في لحظة درامية واحدة، بل تنجرف تدريجياً. مهمة الأسبوعين تستغرق ستة أسابيع. كل إصدار يعطّل شيئاً كان يعمل. المطور الذي بنى معظم المنتج يصبح الوصول إليه صعباً. إن بدا لك هذا مألوفاً، فقد يحتاج منتجك إلى إنقاذ، وطريقة تعاملك مع أول أسبوعين تحدد إن كان سيتعافى أم سيتحول إلى إعادة كتابة مكلفة.
علامات تدل على أن وقت التحرك قد حان
- التقديرات تتأخر باستمرار ولا أحد يستطيع شرح السبب بلغة بسيطة.
- الإصدارات مخيفة. يتجنب الفريق النشر، أو ينشر في وقت متأخر من الليل ويأمل أن يمر الأمر بسلام.
- الأخطاء نفسها تعود بعد تصنيفها على أنها أُصلحت.
- شخص واحد يحمل كل المعرفة، وليست لديك صلاحيات إدارية على الشيفرة أو الخوادم أو حسابات متاجر التطبيقات.
- العملاء يكتشفون المشكلات قبل الفريق، لعدم وجود أي مراقبة.
قد تحدث أي علامة منها في مشروع سليم، لكن اجتماع ثلاث منها أو أكثر في الوقت نفسه يعني عادة أن المشكلة بنيوية.
الأيام 1 إلى 3: أمّن الوصول
قبل أي عمل تقني، تأكد أن شركتك تتحكم في أصولها: مستودع الشيفرة، وحسابات الاستضافة والسحابة، والنطاق وإعدادات DNS، وحسابات متاجر التطبيقات، ومزوّد الدفع، وخدمة إرسال البريد، وأي مفاتيح لواجهات برمجية خارجية. يجب أن يكون كل منها مملوكاً لحساب الشركة، وأن يستطيع شخصان على الأقل الدخول إليه.
ليس الأمر انعداماً للثقة، بل ضماناً لاستمرار العمل مهما حدث مع أي فرد، بمن فيهم من يحاولون المساعدة.
الأيام 3 إلى 7: اجمع الحقائق
قاوم الرغبة في الحكم على الشيفرة من مظهرها، واجمع الحقائق بدلاً من ذلك:
- هل يستطيع مهندس جديد تشغيل المشروع على جهازه من التعليمات المكتوبة وحدها؟
- هل توجد بيئة تجريبية منفصلة، أم أن كل تغيير يذهب مباشرة إلى العملاء؟
- هل توجد نسخ احتياطية، وهل جرّب أحد استعادة واحدة منها؟
- أي أجزاء المنتج تسبب معظم الأخطاء وطلبات الدعم؟
- هل توجد ثغرات أمنية واضحة، مثل كلمات مرور داخل الشيفرة، أو صفحات إدارة بلا تسجيل دخول سليم، أو مكتبات قديمة بثغرات معروفة؟
تُنتج الإجابات خريطة قصيرة وصادقة: ما المتين، وما المحفوف بالمخاطر، وما الذي يؤذي المستخدمين فعلاً.
الأيام 7 إلى 14: إصدار مستقر واحد
الهدف الأول ليس ميزات جديدة، بل إصدار واحد يُنشر بهدوء ولا يعطّل شيئاً. عملياً يعني ذلك بيئة تجريبية، ونشراً قابلاً للتكرار، ومراقبة أساسية للأخطاء، وإصلاح المشكلتين أو الثلاث الأكثر إيذاء للمستخدمين.
هذا الإصدار الهادئ الأول يغيّر مزاج المشروع كله. يستعيد الفريق ثقته، ويرى العملاء تحسناً، وتحصل أنت على تصور واقعي لسرعة تقدم المنتج.
إعادة كتابة أم إصلاح؟
يسأل المؤسسون غالباً في اليوم الأول إن كان يجب إعادة بناء كل شيء. أحياناً يجب ذلك، لكنه استنتاج يأتي بعد الحقائق لا قبلها. إعادة الكتابة توقف التقدم لأشهر وتحمل مخاطرها الخاصة. معظم المنتجات تستفيد أكثر من التثبيت أولاً، ثم استبدال أسوأ الأجزاء واحداً تلو الآخر، بينما يواصل العملاء استخدام المنتج.
تكون إعادة الكتابة منطقية عندما لا تستطيع الأسس دعم ما تحتاجه الشركة لاحقاً: نموذج البيانات لا يناسب المنتج، أو التقنية لم تعد مدعومة، أو المشكلات الأمنية أعمق من أن تُرقَّع.
ما الذي يجب أن تملكه بعد أسبوعين
- كل الحسابات تحت سيطرة الشركة، مع توثيق صلاحيات الوصول.
- تقييم مكتوب للمخاطر، مرتب حسب أثرها على المستخدمين والشركة.
- بيئة تجريبية، وعملية نشر يستطيع أي فرد في الفريق تنفيذها.
- إصدار مستقر واحد أُصلحت فيه أكثر المشكلات إيلاماً.
- خطة واقعية للأسابيع الستة التالية، مع توصية واضحة بالإصلاح أو إعادة البناء.
إن كان منتجك يُظهر عدداً من هذه العلامات، فالمراجعة الخارجية غالباً أسرع طريقة للتمييز بين ما هو معطل فعلاً وما هو غير مألوف فقط.
يتبع سبرنت الإنقاذ وإعادة البناء لدينا هذا الترتيب تماماً: مراجعة، ثم تثبيت، ثم قرار مكتوب بالإصلاح أو إعادة البناء. وإن كان المنتج مبنياً بأدوات البرمجة بالذكاء الاصطناعي فابدأ بفحص جاهزية التطبيق.