الوضع الحالي، والفخ الكامن فيه
كان يُفترض أن ينتهي المشروع منذ مدة. ربما ما زالت شركة التطوير تقول إنه أوشك على الانتهاء، وربما توقف المطوّر عن الرد، وربما نفدت الميزانية والنظام لا يصلح للاستخدام إلا جزئياً. لديك شيء ما، لكنك لست متأكداً مما هو، وكل خيار يبدو مكلفاً.
والفخ أن تقرر بحسب شعورك. فالتمسك بالخطة الأصلية وبالمال المدفوع يدفعك إلى الاستمرار دون تغيير، والإحباط يدفعك إلى البدء من الصفر. وكلا الطريقين قد يكون خاطئاً. أما التقييم فيضع الحقائق مكان الشعور، ويمكن عادةً إنجازه في مدة قصيرة ومحددة.
أمّن أولاً ما هو موجود
قبل أن تطرح مخاوفك على الفريق الحالي، تأكد أن ما دفعت ثمنه في يدك. فالعلاقات قد تسوء بسرعة حين يوضع المشروع موضع تساؤل.
- 01
احصل على الشيفرة المصدرية كاملة
بسجل تعديلاتها الكامل، في مستودع تتحكم فيه مؤسستك. وتحقق من تاريخ آخر تعديل.
- 02
ضع الحسابات تحت سيطرتك
الاستضافة، وأسماء النطاقات، وصفحات التطبيق في متاجر التطبيقات، وخدمات الأطراف الأخرى. يجب أن تكون مؤسستك صاحبة الحساب، وأن يكون المسؤولون عنه من فريقك.
- 03
انسخ البيانات احتياطياً
أي قاعدة بيانات حية أو تجريبية، والملفات المرفوعة، والإعدادات، في مكان تتحكم فيه.
- 04
اجمع المستندات
العقد، والنطاق، وطلبات التغيير، والتصاميم، والفواتير، وتقارير سير العمل، والمراسلات المهمة.
- 05
راجع الاتفاقية
شروط الملكية والترخيص محددة في اتفاقية المشروع، فاقرأ ما تقوله عن العمل الذي سُلّم حتى الآن، وعن إنهاء التعاقد.
وتسرد قائمة التحقق من تسليم المشاريع البرمجية كل ما ينبغي أن تطلبه بتفصيل أكبر.
حدّد ما الذي يعمل فعلاً
خذ النطاق الأصلي وراجعه ميزةً بعد ميزة على نسخة تعمل من النظام، بصحبة شخص سيستخدمه، وضع كل بند في واحدة من أربع فئات. هذا عمل بطيء، لكنه أثمن يوم في التقييم كله.
| الحالة | المعنى | القيمة |
|---|---|---|
| تعمل | تؤدي ما ينص عليه النطاق، ببيانات حقيقية، بما في ذلك الحالات الصعبة | قيمتها كاملة، إن كانت الشيفرة التي تحتها سليمة |
| تعمل في العرض التجريبي فقط | تنجح في المسار المتوقع وتفشل خارجه | جزئية، والعمل المتبقي كثيراً ما يكون أكبر مما أُنجز |
| بدأ العمل عليها | توجد شاشات أو شيفرة، لكن الميزة غير قابلة للاستخدام | قليلة، ما لم يثبت العكس |
| لم يبدأ العمل عليها | لا يوجد شيء | لا قيمة لها |
تشكّك في النسبة المئوية المعلنة. فالمشروع الذي يوصف منذ شهور بأنه مكتمل بنسبة تسعين في المئة يخبرك بأن العُشر المتبقي يضم الأجزاء الصعبة: الربط مع الأنظمة الأخرى، والصلاحيات، ومعالجة الأخطاء، ونقل البيانات، والأداء.
اطلب مراجعة مستقلة للشيفرة
قد تقوم ميزات تعمل على شيفرة لا يستطيع أحد أن يبني عليها بأمان. لذلك ينبغي أن يجيب مطوّر مستقل، لا مصلحة له في النتيجة، كتابةً عن قائمة قصيرة من الأسئلة.
- 01
هل يمكن بناء النظام وتشغيله من المستودع وحده؟
لماذا يهم ذلكإن لم يستطع فريق جديد تشغيل النظام مما في يدك، فهناك شيء أساسي ناقص.
- 02
هل البنية متسقة ومفهومة؟
لماذا يهم ذلكيجب أن يستطيع المطوّر الجديد أن يجد طريقه فيها، فالفوضى تضاعف تكلفة كل تغيير لاحق.
- 03
هل توجد اختبارات مؤتمتة؟
لماذا يهم ذلكمن دونها، قد يكسر كل إصلاح شيئاً آخر، دون أن يعلم أحد.
- 04
ما مدى حداثة التقنيات المستخدمة؟
لماذا يهم ذلكالمكوّنات القديمة أو التي توقف دعمها تعني أن التحديث يسبق أي عمل جديد.
- 05
هل توجد مشكلات أمنية؟
لماذا يهم ذلكالأسرار المكتوبة في الشيفرة، وغياب التحقق من الصلاحيات، والبيانات غير المحمية، كلها شائعة في المشاريع المستعجلة.
- 06
كم منها أصلي، وكم منها قالب جاهز أو منسوخ؟
لماذا يهم ذلكفهذا يؤثر في الجودة، وفي ما يحق لك استخدامه.
ويقدّم التدقيق التقني للشيفرة هذه الإجابات، مع تقدير لما يلزم لجعل الشيفرة قابلة للصيانة.
اعرف لماذا تعثّر المشروع
السبب مهم لأن بعض الأسباب تلاحق المشروع إلى أي فريق جديد. فاقرأ المراسلات، وقارن النطاق الأصلي بطلبات التغيير، وتحدّث إلى المعنيين من الطرفين.
| السبب | العلامات | هل يلاحق المشروع؟ |
|---|---|---|
| نطاق لم يستقر أبداً | متطلبات تتغير كل شهر، ولا نسخة أساسية موقّعة | نعم، إلى أن تعالجه |
| قرارات بطيئة جداً | أسئلة تبقى بلا إجابة أسابيع، ولا صاحب قرار واحد | نعم |
| فريق تنقصه المهارة | الأمور البسيطة استغرقت وقتاً طويلاً، والجودة ضعيفة في كل شيء | لا |
| فريق نُقل إلى مشاريع أخرى أو تقلّص | بداية سريعة، ثم فترات صمت طويلة | لا |
| تقنية أو منهجية غير مناسبة | حلول التفافية مستمرة، ومشكلات في الأداء | لا، لكنه قد يحدّ مما يمكن إنقاذه |
| سعر أقل من الحقيقي | سعر ثابت أقل كثيراً من العروض الأخرى، واختصارات على حساب الجودة | جزئياً، فالتكلفة الحقيقية كانت أعلى منذ البداية |
كن صريحاً مع نفسك في الصفّين الأولين. فإن لم يستقر النطاق قط، فسيتعثر أي فريق جديد في الموضع نفسه، ما لم يتغير ذلك أولاً.
مثال تطبيقي
منصة حجز متأخرة عاماً كاملاً
هذا مثال افتراضي يوضح كيف تغيّر الحقائق القرار. شركة تدريب طلبت بناء منصة لحجز الدورات، تأخرت عن موعدها عاماً كاملاً، وتوصف بأنها أوشكت على الاكتمال.
- الأصوليتبين أن الشيفرة في مستودع المطوّر الخاص، وأن الاستضافة باسمه، فيُنقل الاثنان إلى الشركة قبل أي خطوة أخرى.
- ما يعملمن أصل 46 ميزة في النطاق، تعمل 19، و11 تعمل في العرض التجريبي فقط، و9 بدأ العمل عليها، و7 لم يبدأ العمل عليها. والمدفوعات والفوترة من بين الميزات التي لم يبدأ العمل عليها.
- الشيفرةتجد المراجعة المستقلة بنية معقولة وتقنيات حديثة، لكن بلا اختبارات، ومع ثغرتين خطيرتين في التحكم بالصلاحيات. ويقدّر المراجع أن الشيفرة تستحق الإبقاء عليها.
- السببتولّى مطوّر واحد العمل بمفرده بسعر ثابت يساوي نصف أقل العروض الأخرى. وكان النطاق مستقراً، فالسبب لا يلاحق المشروع.
- القرارتكلّف الشركة فريقاً جديداً بالاستكمال على الشيفرة الحالية: إصلاح الثغرات الأمنية أولاً، ثم إضافة اختبارات حول الميزات التي تعمل، ثم بناء المدفوعات. وتقدير تكلفة الإكمال يقارب السعر الثابت الأصلي.
كانت التكلفة الحقيقية للمنصة منذ البداية نحو ضعف العرض الأول. وحين عرفت الشركة ذلك، صار بإمكانها أن تقارن الإكمال بالتوقف على أرقام حقيقية، فاختارت الإكمال.
قارن الخيارات الحقيقية
يكون الاستكمال منطقياً حين
- تعمل نسبة جيدة من الميزات فعلاً
- يمكن تشغيل الشيفرة وفهمها والتوسع فيها
- يمكن إزالة سبب التأخير
- حاجة العمل لم تتغير
- تكلفة الإكمال من الآن أقل من تكلفة إعادة البناء
تكون إعادة البناء أو التوقف أنسب حين
- معظم الميزات لا تعمل إلا في العرض التجريبي
- لا يمكن تشغيل الشيفرة، أو تغييرها غير آمن
- التقنية توقف دعمها أو غير مناسبة
- حاجة العمل تغيّرت
- صار منتج جاهز يلبي الحاجة
أياً كان الطريق الذي تختاره، لا تقارن إلا التكاليف والفوائد المستقبلية، فما أُنفق قد ذهب في كل الأحوال. وإن قررت الاستكمال، فليكن ذلك بشروط جديدة: نطاق مستقر، ودورات قصيرة تنتهي كل منها ببرمجيات تعمل، ودفعات مرتبطة بما تستطيع اختباره.
قائمة التحقق لتقييم المشروع
قائمة التحقق لتقييم مشروع لم يكتمل
0 من 10 منجزةماذا تفعل الآن
اليوم، تأكد أين توجد الشيفرة، وباسم من حساب الاستضافة. وغداً، خصّص نصف يوم مع شخص سيستخدم النظام، وراجعا النطاق معاً. هاتان الخطوتان لا تكلفان شيئاً تقريباً، وتزيلان معظم الغموض.
تشرح صفحة استكمال وإنقاذ المشاريع البرمجية كيف نقيّم المشاريع المتعثرة ونتسلّمها. أخبرنا أين وصل مشروعك، وسنقول لك ما الذي سننظر فيه أولاً.
أسئلة شائعة
هل نبدأ من الصفر من جديد؟
لا تفعل ذلك إلا إذا أوصى به التقييم. فالبدء من جديد يبدو بداية نظيفة، لكنه يتخلى عن كل ما يعمل، ويكرر المخاطرة نفسها. إن كانت الشيفرة قابلة للتشغيل والفهم والتوسع، فالاستكمال أرخص عادةً. وإن لم تكن، أو كانت التقنية غير مناسبة، فالطريق الأسلم إعادة بناء تستفيد من التصاميم والدروس، وربما من بعض المكوّنات.
هل يستطيع فريق جديد أن يتسلّم شيفرة كتبها غيره؟
نعم، شرط أن تكون الشيفرة كاملة، وأن يمكن تشغيلها من المستودع، وأن تكون بنيتها معقولة. والفريق الكفء سيطلب وقتاً لمراجعتها قبل أن يلتزم بأي تقدير، وسيبدأ عادةً بإضافة اختبارات حول ما يعمل. واحذر ممن يعدك بالإنجاز السريع دون أن يقرأ الشيفرة.
كم يستغرق التقييم؟
في معظم أنظمة الأعمال، تكفي مدة قصيرة ومحددة لمراجعة الميزات واحدة واحدة ولمراجعة مستقلة للشيفرة، ما دامت صلاحيات الوصول متاحة. أما جمع المستندات والحسابات فيمكن أن يبدأ فوراً، وكثيراً ما يستغرق أطول وقت، لأنه يتوقف على تعاون الفريق الحالي.
ماذا لو رفض المطوّر تسليم الشيفرة؟
ارجع إلى الاتفاقية، وقدّم طلبك كتابةً. فكثير من النزاعات تدور حول فواتير غير مدفوعة من جهة، وعمل لم يُسلَّم من جهة أخرى، ويمكن حلها بالاتفاق على ما يُسلَّم مقابل ماذا. وإن لم ينجح ذلك، فاطلب استشارة قانونية دون تأخير. والتزم في تواصلك بالوقائع، فقد تظل بحاجة إلى تعاون المطوّر لإتمام تسليم سليم.
كيف نتجنب تكرار ذلك؟
احتفظ بالمستودع والحسابات منذ اليوم الأول. واعمل بدورات قصيرة تنتهي كل منها ببرمجيات تستطيع اختبارها. واربط الدفعات بما استلمته وتحققت منه. وثبّت النطاق قبل التطوير، وأدِر التغييرات كتابةً. ثم قارن العروض بعين ناقدة: فالسعر الأدنى بكثير من غيره نذير متاعب، لا توفير.