ثلاثة عشر عامًا من تدقيق مشاريع البرمجيات تُفضي إلى استنتاج واضح: المشاريع لا تفشل بسبب سوء الحظ، بل تفشل بسبب ثلاثة عشر خطأً
تتكرر هذه المشكلات. أربعة منها تتعلق بالتخطيط (نطاق مفتوح، فريق غير مناسب، موعد نهائي مستحيل، ميزانية مبنية على المعتقدات). وأربعة أخرى تتعلق بالتنفيذ.
(لا اختبارات، لا توثيق، ديون تقنية منذ البداية، قرارات بالتوافق). خمسة منها تتعلق بقضايا الحوكمة (لا يوجد مسؤول واضح، لجان).
(انعدام عملية اتخاذ القرار، ومقاييس غامضة، وانعدام معايير القبول، وتغيير مستمر دون تحديد الأولويات). إن اكتشاف هذه المشكلات في الأسبوعين الأولين يمنع تطبيق قانون الضرائب الإسباني 90%.
من التكلفة.
تزخر الأدبيات المتعلقة بإدارة مشاريع البرمجيات بأفضل الممارسات، لكن ما ينقصها هو الصراحة بشأن الأخطاء. بعد ثلاثة عشر عامًا من تدقيق المشاريع المتعثرة أو الفاشلة، حددنا ثلاثة عشر خطأً تتكرر في معظم الحالات. معرفة هذه الأخطاء بأسمائها تُمكّننا من اكتشافها في الأسبوعين الأولين، حين يكون تصحيحها ممكنًا بتكلفة معقولة. أما اكتشافها في الشهر السادس فيُكلّف ما بين خمسة وعشرين ضعفًا.
نقوم بتصنيفها إلى ثلاث فئات: أخطاء التخطيط، وأخطاء التنفيذ، وأخطاء الحوكمة.
الخطأ 1 · تم توقيع النطاق المفتوح على أنه مغلق. ينص العقد على "تنفيذ نظام إدارة علاقات العملاء" دون تحديد الوحدات أو التكاملات أو مستوى التخصيص المطلوب. يعتقد كل طرف أنه وقّع على نطاق مختلف. يبدأ النقاش حول ما يشمله العقد وما لا يشمله في الشهر الثالث ولا ينتهي. الحل: تحديد نطاق العمل لكل وحدة على حدة مع تحديد واضح للمخرجات.
الخطأ 2 · معدات غير مناسبة لنوع المشروع. استئجار كبير
أربعة أشخاص لإنتاج منتج MVP سريع أمر غير فعال. توظيف مستقل لـ
يُعدّ النظام الحرج الخاضع للتنظيم محفوفًا بالمخاطر. الاستعانة بخبير متخصص رفيع المستوى لـ
الأعمال الصغيرة مكلفة. ويحدد اختيار مقدم الخدمة النتيجة.
أفضل من أي منهجية أخرى.
الخطأ 3 · تم توقيع موعد نهائي مستحيل بسبب ضغوط تجارية. يحتاج العميل
“"لشهر يونيو" لأنه لديه إعلان مؤكد. المورد
يوقع العقد وهو يعلم باستحالة ذلك لأنه يحتاج إليه. المشروع
كان من المقرر إصداره في سبتمبر، لكن الإعلان لم يتم، والجميع يلقي باللوم على بعضهم البعض.
الحل: التقدير بصدق ورفض المستحيل.
الخطأ 4 · الميزانية القائمة على الإيمان. تقديرات "أكثر أو أقل"
هذا "بدون تفصيل للمراحل الرئيسية، وبدون خطط طوارئ، وبدون معايير للتغيير".
عندما ينحرف المشروع بمقدار 30% في الشهر الثاني، فلا توجد طريقة لـ
لتحديد ما إذا كان ذلك معقولاً أم كارثياً. الحل: تقدير مفصل بواسطة
وحدة نمطية مع مخزن مؤقت مُوقّع.
الخطأ رقم 9: لا يوجد مالك مشروع واضح لدى العميل. المشاريع
حيث "يتعلق المشروع بالتكنولوجيا ولكنه يتعلق أيضاً بالعمليات، أيضاً
"في مجال التسويق والمبيعات أيضاً." عندما يكون الجميع مالكاً،,
لا أحد كذلك. القرارات مؤجلة، والتسليمات متأخرة.
تبقى هذه البيانات غير مُدققة، مما يُبطئ وتيرة المشروع. الحل: عنصر واحد
مسؤول بسلطة حقيقية منذ اليوم الأول.
الخطأ 10 · لجان بدون سلطة اتخاذ القرار. اجتماعات نصف شهرية
مع خمسة عشر شخصًا حيث لا يملك أي منهم سلطة اتخاذ القرارات التي
إنها مهمة. فهي تُستخدم للإعلام، لا لاتخاذ القرارات. الحل: اجتماعات من
اتخاذ القرارات بشكل منفصل عن اجتماعات المعلومات، مع وجود توكيل رسمي موقع.
الخطأ 11 · مقاييس غامضة أو غائبة. إنّ "أنّه يعمل بشكل جيد وأنّ المستخدمين راضون" ليس معيارًا. فبدون معايير موضوعية، يصبح القرار بشأن
“يعتمد مفهوم "انتهاء العمل" على مزاج الشخص الذي يقوم به. الحل: تحديد المقاييس قبل أول عملية دمج، وقياسها أسبوعيًا.
الخطأ 12 · لا توجد معايير قبول موقعة. يدخل المشروع مرحلة الاختبار دون وجود تعريف متفق عليه لمصطلح "مقبول".
نقاشات لا تنتهي حول ما إذا كان الخلل X يعيق العمل أم لا. الحل: وضع معايير قبول موقعة في بداية الوحدة، قبل تشغيلها.
الخطأ 13 · تغيير مستمر بدون تحديد الأولويات. يضيف العميل متطلبات جديدة كل أسبوع دون حذف أي منها من قائمة المهام المتراكمة. ويتوسع المشروع دون أن...
لا ينبغي زيادة الإطار الزمني ولا الميزانية، وإلا ستتفاقم الأمور. الحل: سياسة مُوقّعة للتغييرات تسمح بإضافة بنود، ولكنها تتطلب إزالة بنود أخرى.
أو تمديد الموعد النهائي والميزانية.
تُعتبر أول أسبوعين من أي مشروع هما الأهم. فإذا تم اكتشاف ثلاثة أخطاء أو أكثر من الأخطاء الثلاثة عشر خلال تلك الفترة، فإن المشروع يكون في خطر.
نحن في خطر، ويجب أن نتوقف قبل المضي قدمًا. خمسة أسئلة يمكنك طرحها في اجتماع مدته 60 دقيقة:
إذا كانت الإجابة على ثلاثة أسئلة أو أكثر هي "لا" أو "ليس على الإطلاق"، فعليك التوقف و
حسم الأمر قبل المضي قدماً.
لا، ولكن التكلفة تنخفض بشكل ملحوظ عند تحديد المشاكل مبكراً. لا يوجد مشروع مثالي. المشروع المُدار جيداً هو الذي يكتشف الأخطاء في غضون أسابيع، لا أشهر.
بحسب تجربتنا، فإن الخطأ 1 (نطاق مفتوح) والخطأ 9 (لا يوجد مالك واضح) هما الأكثر تكلفة لأنهما يضخمان جميع الأخطاء الأخرى.
ليس بمفردهم. قد يتحول تطبيق منهجية أجايل بشكل سيئ إلى "سكروم بلا انضباط" ويكرر نفس الأخطاء تحت مسمى مختلف. الانضباط أهم من المنهجية.
توجد أدوات (مثل SonarQube و CodeClimate) توفر مقاييس موضوعية. المهم هو قياسها منذ البداية، وليس اكتشافها في الشهر السادس.
عندما تتجاوز التكلفة التقديرية للإنجاز القيمة المتوقعة للمخرجات، يصبح اتخاذ هذا القرار صعباً ولكنه ضروري أحياناً. وقد أوصينا به للعملاء الذين استعانوا بنا لإجراء عمليات التدقيق.
نعم، هذه هي الوظيفة بالضبط. تغطي عملية التدقيق التي تستغرق 10 أيام مع شركة TCG الأخطاء الثلاثة عشر وتقدم تقريرًا موجزًا يسلط الضوء على أهمها بالنسبة للمشروع المحدد.
تشخيصٌ صادق: ما يمكن إنقاذه، وما يحتاج إلى إعادة كتابة، وما يجب إيقافه. أحيانًا يكون بذل جهد إضافي للمضي قدمًا أكثر تكلفة من إعادة جزء منه.
يعتمد القرار على الحالة المحددة، وينبغي اتخاذه من منظور خارجي.
لا تفشل مشاريع البرمجيات بسبب التقنية المختارة أو سوء الحظ، بل بسبب مجموعة متوقعة من الأخطاء.
التخطيط والتنفيذ والحوكمة. إن معرفة الأخطاء الثلاثة عشر بالاسم يسمح لك باكتشافها في الوقت المناسب وتصحيحها بينما لا تزال موجودة.
هذا ممكن. إذا حدد مشروعك ثلاث مشكلات أو أكثر، يُنصح بإجراء تدقيق خارجي قبل استثمار المزيد من الموارد.
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
