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