لماذا يتأخر مشروعك البرمجي (وماذا تفعل حيال ذلك)

وجد تقرير الفوضى لعام 2024 الصادر عن مجموعة ستانديش ذلك66% من المشاريع البرمجية تتجاوز جدولها الزمني أو ميزانيتها. يتم إلغاء واحد من كل خمسة على الفور. ظلت هذه الأرقام ثابتة بشكل مستمر لأكثر من عقد من الزمن.

الأسباب ليست غامضة. وهي تتكرر عبر الصناعات وأحجام الشركات ومجموعات التكنولوجيا. بعد شحن العشرات من مشاريع العملاء في Savi، هناك ستة أنماط تمثل الغالبية العظمى من حالات التأخير التي نراها. كل منهم يمكن الوقاية منها. إليك كيفية اكتشاف كل منها وما يجب فعله بدلاً من ذلك.

1. زحف النطاق يقتل مشاريع أكثر من التعليمات البرمجية السيئة

يعد زحف النطاق هو السبب الوحيد الأكثر شيوعًا لتأخر مشاريع البرامج. يبدأ صغيرًا. يقول أحد أصحاب المصلحة "أثناء قيامنا بذلك، هل يمكننا أيضًا إضافة..." في وضع الوقوف. أومأ رئيس الوزراء. يضيف المهندس مهمة. اضرب ذلك بثلاثة طلبات أسبوعيًا على مدى ثمانية أسابيع، وسيصبح مشروعك الأصلي الذي يستغرق 6 أسابيع الآن مشروعًا مدته 14 أسبوعًا دون نهاية في الأفق.

هذه هي الرياضيات التي تجعل النطاق يزحف بشكل مدمر للغاية:تغيير المتطلبات في الأسبوع الأول يكلف حوالي ساعة واحدة من وقت الهندسة. نفس التغيير في الأسبوع الثامن يكلف 10 أضعاف. بحلول الأسبوع الثامن، تحتوي قاعدة التعليمات البرمجية على تبعيات مبنية على التصميم الأصلي. تغيير الاتجاه يعني إعادة هيكلة كود العمل، وتحديث الاختبارات، وإعادة التحقق من عمليات التكامل، وإعادة اختبار الميزات التي قمت بتسجيل الدخول إليها بالفعل.

نشر معهد IBM Systems Sciences Institute بيانات توضح أن العيوب التي تم العثور عليها أثناء مرحلة الصيانة تكلف إصلاحها 100 مرة أكثر من العيوب التي تم العثور عليها أثناء مرحلة التصميم. تتبع تغييرات المتطلبات نفس منحنى التكلفة.

ماذا تفعل بدلاً من ذلك:اكتب مستند متطلبات المنتج (PRD) قبل كتابة أي رمز. قم بإدراج كل ميزة، وكل تدفق مستخدم، وكل نقطة نهاية لواجهة برمجة التطبيقات. الحصول على موافقة من كل أصحاب المصلحة. ثم تعامل مع PRD كعقد. الأفكار الجديدة تدخل في "تراكم الإصدار الثاني"، وليس السباق الحالي. في Savi، نقضي من أسبوع إلى أسبوعين في تحديد المتطلبات قبل بدء التطوير. إن هذا الاستثمار الذي يبلغ 1500 دولار في التخطيط يوفر أكثر من 10000 دولار في إعادة العمل في منتصف المشروع.

2. طبقات الاتصال تضيف أسابيع، وليس الوضوح

تخيل إعدادًا نموذجيًا للوكالة: حيث تشرح طلب الميزة الخاص بك لمدير الحساب. يقوم مدير الحساب بكتابة تذكرة ويعينها لمدير المشروع. يقوم مدير المشروع بترجمتها إلى مواصفات فنية وإرسالها إلى القائد الفني. يقوم القائد الفني بتعيينه للمطور. المطور لديه سؤال، وبالتالي فإن السلسلة بأكملها تنعكس.

كل عملية تسليم في هذه السلسلة تؤدي إلى مشكلتين. أولا، فقدان المعلومات. طلبك الأصلي كان له فارق بسيط؛ وبحلول الوقت الذي تصل فيه إلى المطور، تكون قد تمت إعادة صياغتها ثلاث مرات. ثانيا، الكمون. تضيف كل عملية تسليم ما بين 4 إلى 24 ساعة من وقت الانتظار. السؤال الذي يمكن حله في مكالمة مدتها 5 دقائق يستغرق 3 أيام ذهابًا وإيابًا عبر سلسلة الاتصال.

وجدت دراسة أجراها معهد إدارة المشاريع أن56% من ميزانية المشروع معرضة للخطر بسبب ضعف التواصل. في مشروع بقيمة 50.000 دولار، يعني ذلك أن 28.000 دولار معرضة لإهدار سوء الاتصال.

ماذا تفعل بدلاً من ذلك:تحدث مباشرة إلى الشخص الذي يكتب الكود الخاص بك. في Savi، كل عميل لديه قناة Slack مباشرة مع كبار المهندسين المعينين له. لا يوجد مديرو حسابات ينقلون الرسائل. لا يوجد مدراء مشاريع يترجمون المتطلبات. أنت تصف ما تحتاجه؛ يسأل المهندس أسئلة توضيحية في الوقت الحقيقي؛ يتم إنشاء الميزة بشكل صحيح في المرة الأولى. يؤدي هذا التغيير الفردي إلى التخلص من 30-40% من التقلبات التي تؤدي إلى تضخيم الجداول الزمنية.

3. التكوين الخاطئ للفريق يحرق الميزانية عند عمليات التسليم

يعمل لدى العديد من الوكالات مشاريع تضم 4-6 مطورين: اثنان من المطورين، واثنان من المطورين الخلفيين، ومهندس ضمان الجودة، وشخص DevOps. هذا يبدو مثمرا. ومن الناحية العملية، فهو يفرض ضريبة تنسيق تلتهم 30% إلى 40% من إجمالي الميزانية.

يقوم فريق الواجهة الأمامية ببناء مكون النموذج ويحتاج إلى نقطة نهاية API. يقومون بتقديم تذكرة للفريق الخلفي. فريق الواجهة الخلفية في منتصف السباق على ميزة مختلفة. تمر ثلاثة أيام. ينتقل مطور الواجهة الأمامية إلى مهمة أخرى. عندما تكون نقطة النهاية جاهزة، يتعين على مطور الواجهة الأمامية تبديل السياق مرة أخرى. تقوم نقطة النهاية بإرجاع البيانات بشكل مختلف عن المتوقع. تبدأ رحلة ذهابًا وإيابًا أخرى.

إن التوظيف مع عدد كبير جدًا من المطورين المبتدئين يخلق نفس المشكلة بطريقة مختلفة. يكتب المبتدئون التعليمات البرمجية التي تعمل على أجهزتهم المحلية ولكنها تفشل في التدريج. يقضي أحد كبار المهندسين 3 ساعات في تصحيح مشكلة النشر الخاصة بالمبتدئين بدلاً من إنشاء الميزات. تنخفض السرعة الفعالة للفريق إلى 40-50% من قدرته النظرية.

ماذا تفعل بدلاً من ذلك:يقوم طاقم العمل بمشاريع تضم 1-2 من كبار المهندسين المتخصصين الذين يمتلكون قاعدة التعليمات البرمجية بأكملها. أحد المهندسين الذي يقوم بإنشاء واجهة برمجة التطبيقات (API)، وكتابة الواجهة الأمامية، وتكوين قاعدة البيانات، ونشر التطبيق، لا يتحمل أي تكاليف تسليم. في سافي، هذا هو خيارنا الافتراضي. يتفوق مهندس واحد كبير يشحن مشروعًا بقيمة 20 ألف دولار في 5 أسابيع على فريق من أربعة مبتدئين يشحن نفس المشروع في 12 أسبوعًا مع المزيد من الأخطاء وتكلفة إجمالية أعلى.

4. لا توجد معايير "تم" محددة للميزات

"إنشاء لوحة تحكم المستخدم" ليس من مواصفات الميزات. إنها بداية المحادثة. وبدون معايير قبول صريحة، يقوم المهندسون بوضع افتراضات. في بعض الأحيان تتطابق هذه الافتراضات مع ما يريده العميل. في كثير من الأحيان، لا يفعلون ذلك.

النتيجة: يقوم المهندس بإنشاء لوحة معلومات تحتوي على ثلاثة مخططات وجدول بيانات. توقع العميل خمسة مخططات، ومرشح النطاق الزمني، وزر تصدير CSV، وعرض المقارنة. المهندس يعيد بناءه. يقدم العميل ملاحظات حول إعادة البناء. الميزة التي كان من المفترض أن تستغرق 3 أيام تستغرق 10 أيام.

هذا النمط شائع جدًا لدرجة أن له اسمًا في إدارة المشاريع:فخ "90٪ تم إنجازه".. تبقى الميزة في وضع "على وشك الانتهاء" لأسابيع لأنه لم يحدد أحد كيف تبدو كلمة "انتهى". يستمر المهندسون في التلميع. يستمر العملاء في طلب التغييرات. المشروع ينزف الوقت.

ماذا تفعل بدلاً من ذلك:اكتب معايير القبول لكل ميزة قبل بدء التطوير. استخدم هذا التنسيق: "تتم هذه الميزة عند [حالة محددة وقابلة للاختبار]." على سبيل المثال: "يتم الانتهاء من لوحة المعلومات عندما تعرض الإيرادات والأوامر ومعدل التحويل للنطاق الزمني المحدد، باستخدام زر تصدير CSV الذي يقوم بتنزيل جميع البيانات المرئية." المهندس يعرف بالضبط ما يجب بناءه. العميل يعرف بالضبط ما يمكن توقعه. لا أحد يجادل حول ما إذا كان قد تم "الانتهاء".

5. التقليل من تعقيد التكامل

تبدو عبارة "نحن بحاجة إلى التكامل مع Stripe" وكأنها مهمة تستغرق يومًا واحدًا. في الواقع، يتضمن تكامل Stripe على مستوى الإنتاج ما يلي: إنشاء نية الدفع، ومعالجة خطاف الويب للأحداث غير المتزامنة (نجاح الدفع، فشل الدفع، إلغاء الاشتراك، فتح النزاع)، ومفاتيح العجز لمنع الرسوم المكررة، ومنطق إعادة المحاولة لخطافات الويب الفاشلة، وبوابة عميل لإدارة الاشتراكات، وحالات الخطأ المناسبة في واجهة المستخدم لكل وضع فشل.

تستغرق "مهمة اليوم الواحد" هذه من 3 إلى 5 أيام للمهندس الكبير و7 إلى 10 أيام للمهندس المبتدئ. اضرب هذا التقدير المنخفض عبر 3-4 عمليات تكامل (بوابة الدفع، وموفر البريد الإلكتروني، والتحليلات، وKYC)، وستكون قد أضفت 2-4 أسابيع إلى مشروع لم يخصص له أحد الميزانية.

تختلف جودة واجهة برمجة تطبيقات الطرف الثالث بشكل كبير. يحتوي Stripe على وثائق وبيئات رملية ممتازة. تحتوي العديد من واجهات برمجة التطبيقات الخاصة بالصناعة (الخدمات المصرفية والخدمات اللوجستية والحكومة) على مستندات غير مكتملة وصناديق حماية غير موثوقة وفرق دعم تستجيب خلال 48 إلى 72 ساعة. تضيف كل واجهة برمجة تطبيقات سيئة التوثيق 2-3 أضعاف وقت التكامل المقدر.

ماذا تفعل بدلاً من ذلك:تدقيق كل التكامل خلال مرحلة المتطلبات. بالنسبة لكل خدمة تابعة لجهة خارجية، أجب عن ثلاثة أسئلة: هل تحتوي على بيئة اختبار معزولة؟ ما مدى اكتمال التوثيق؟ ما هو وقت استجابة الدعم؟ ثم قم بتقدير وقت التكامل بثلاثة أضعاف ما يبدو معقولًا. أنشئ إثباتًا للمفهوم للتكامل الأكثر خطورة قبل الالتزام بالجدول الزمني الكامل للمشروع. في Savi، نقوم بإعداد نماذج أولية لعمليات التكامل عالية المخاطر خلال الأسبوع الأول ونضبط الجدول الزمني بناءً على ما نجده، وليس ما تعد به صفحة التسويق الخاصة بواجهة برمجة التطبيقات.

6. إطلاق الانفجار الكبير يؤدي إلى فشل الانفجار الكبير

يعد نهج "بناء كل شيء، وإطلاقه مرة واحدة" هو استراتيجية التسليم الأكثر خطورة في تطوير البرمجيات. تقضي الفرق من 3 إلى 6 أشهر في البناء بمعزل عن غيرها. لا أحد خارج فريق التطوير يرى المنتج. في يوم الإطلاق، تم إنتاج العشرات من الميزات في وقت واحد. مجمع البق. يواجه المستخدمون تدفقات مكسورة. يقضي الفريق الأسبوعين التاليين في وضع مكافحة الحرائق بدلاً من التكرار.

تعمل عمليات إطلاق Big Bang أيضًا على إخفاء انزلاق الجدول الزمني. عندما يكون المشروع بأكمله عبارة عن نتيجة واحدة متجانسة، فمن المستحيل قياس التقدم بدقة. يمكن للفريق الإبلاغ عن "اكتمال 80%" لمدة 6 أسابيع متتالية لأن آخر 20% تحتوي على أصعب المشكلات: اختبار التكامل، وحالات الحافة، وتكوين النشر، وترحيل البيانات.

ماذا تفعل بدلاً من ذلك:السفينة تدريجيا. قم بتقسيم المشروع إلى مراحل رئيسية تتراوح مدتها من أسبوع إلى أسبوعين، ينتج كل منها ميزة عملية وقابلة للنشر. في Savi، نقوم بتشغيل عروض تجريبية أسبوعية حيث يرى العميل البرامج العاملة، وينقر على التدفقات الحقيقية، ويقدم تعليقات حول بيئة العرض المباشر. إذا كان هناك خطأ ما، فإننا نكتشفه في الأسبوع الثاني، وليس الأسبوع الثاني عشر.

يمنحك التسليم المتزايد أيضًا فتحة هروب. إذا تغيرت الميزانية أو الأولويات في الأسبوع الرابع، فهذا يعني أن لديك منتجًا صالحًا للعمل مع أربعة أسابيع من الميزات المنشورة والقابلة للاستخدام. مع تسليم الانفجار الكبير، ليس لديك أي شيء قابل للاستخدام حتى يتم شحن المشروع بأكمله.

قائمة مرجعية قبل أن تبدأ مشروعك القادم

هذه المشاكل الستة ليست حتمية. إنها عمليات فاشلة، وفشل العمليات له حلول عملية. قبل أن يبدأ مشروعك التالي، تحقق من هذه الشروط الستة:

• تتم كتابة المتطلبات وتوقيعها.كل ميزة لها معايير القبول. اتفق أصحاب المصلحة على النطاق كتابيًا، وليس عبر مكالمة لم يوثقها أحد.
• يمكنك التحدث مع المهندس الذي يقوم ببناء منتجك.لا يوجد وسطاء يترجمون متطلباتك. الوصول المباشر عبر Slack أو البريد الإلكتروني أو مكالمة الفيديو.
• الفريق صغير وكبير.1-2 مهندسين متكاملين يمتلكون قاعدة التعليمات البرمجية بأكملها. ليس فريقًا مكونًا من 6 أشخاص مع عمليات تسليم بين الواجهة الأمامية والخلفية وضمان الجودة وDevOps.
• كل ميزة لها تعريف "تم".شروط محددة وقابلة للاختبار. ليس "إنشاء لوحة التحكم" ولكن "عرض الإيرادات والطلبات ومعدل التحويل من خلال تصدير ملف CSV".
• يتم وضع نماذج أولية للتكامل مبكرًا.يتم اختبار اتصال الطرف الثالث الأكثر خطورة في الأسبوع الأول، وليس الأسبوع الثامن.
• ترى برامج العمل كل أسبوع.عروض تجريبية أسبوعية على بيئة التدريج. نقرات حقيقية، بيانات حقيقية، حلقات تعليقات حقيقية.

يتم شحن المشاريع التي تتحقق من جميع الصناديق الستة في الوقت المحدد. المشاريع التي تتخطى حتى واحدة منها تتأخر. العلاقة هي أن متسقة.

الأسئلة المتداولة