التعامل مع زحف النطاق والطلاء الذهبي في مشاريع البرمجيات

في حالة مشاريع تكنولوجيا المعلومات، فإن زحف النطاق (القادم من موقع المالك) والطلاء الذهبي (القادم من مدير المشروع أو Scrum Master أو المطورين) هما التهديدان الشائعان. التغييرات غير المنضبطة في المشروعأو إضافة وظائف جديدة أو إدخال تغييرات تنتمي بلا شك إلى التهديدات التي تؤثر على كفاءة وسرعة المشاريع. وقد أتيحت لنا في الماضي فرصة التعاون مع شركات ناشئة وشركات أكبر مثل Livenation / Ticketmaster أو Stroer أو Agora (أكبر مجموعة إعلامية في أوروبا). خلال هذا الوقت، قمت بتنسيق العديد من مشاريع تكنولوجيا المعلومات - خاصة تلك المتعلقة بـ تطوير البرمجيات. وقد أتاحت لي هذه التجربة أن أفهم أنه لا يهم إذا كنت تعمل في شركة صغيرة أو كبيرة: إذا كنت تريد النجاح، يجب أن تكون متقدمًا على منافسيك بخطوة واحدة.

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

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

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

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

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

4. التنمية. يجب أن يبدأ بناء التطبيق بتجربة المستخدم والتصميم والواجهة الخلفية والواجهة الأمامية. باختصار، يبدأ كل شيء بالمهام البسيطة "التي يجب أن تكون" التي تشكل منتج MVP. بعد الوصول إلى مرحلة التطوير هذه، يمكنك التركيز على تطوير الوظائف التي تسمى "يجب أن يكون".

الملخص

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

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

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