"سيتم الانتهاء من تطبيقك يوم الثلاثاء." - أي الثلاثاء؟!

10 أسباب فشل مشروعات تطوير البرمجيات

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

"بحلول عام 2020". بالنسبة لأولئك الذين لا يتحدثون "مهندس برمجيات" ، هذا يعني 2040.

بصفتي الرجل الوحيد في Crane.ai الذي لا يكتب الكود ، فقد ابتليت بهذه المشكلة لأطول وقت. بالطبع ، غير المبرمجين هم أيضًا جزء من المشكلة ؛ كان هذا المنشور في الأصل حوالي 5 أسباب لفشل مشاريع تطوير البرمجيات ، ولكن بطريقة العميل بالكامل قمت بتغيير المواصفات في منتصف المشروع وبالتالي سيكون الآن حوالي 10 أسباب لفشل مشاريع تطوير البرمجيات.

1. ضعيف المعرفة (أو إن شاء الله ، غير محدد!) النتيجة

"تطبيق جوال؟ بنينا الجسر ، هل هذا العمل؟ "

واحدة من أكبر المشاكل التي تعاني منها مشاريع تطوير البرمجيات هي نتيجة سيئة التعريف. بدون تعريف مناسب لما يجب أن يكون عليه "المنتج النهائي" ، يضمن المشروع الفشل.

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

2. حل المشكلة الخاطئة.

"لقد قمنا ببناء جسر خشبي جديد يبدو أجمل من الجسر القديم. السيارات؟ أوه ، لا ، لا يمكنها دعم السيارات. إلى حد كبير أي شيء أثقل من الطيور سوف يكسره ".

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

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

3. لا يكفي التواصل.

"لقد بنينا نصف الجسر ، بنوا نصف نفق."

يمثل الدخول في المرتبة الثالثة المشكلة الأساسية التي يعاني منها كل مشروع ، والصناعة ، والاتصالات - التجارية. الاتصالات أمر حيوي في كل مستوى من مشروع تطوير البرمجيات.

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

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

عدم الاتصال على هذا المستوى يمكن أن يسبب مشاكل تحطيم المشروع ؛ يمكن أن ينتهي الأمر بفصل المنتج بشدة عما تم بيعه ووعده وبنائه واحتياجاته.

4. لا خطة أو الجدول الزمني.

"نعم ... سوف يتم ذلك مثل ... ربما بضعة أسابيع؟ لست متأكدًا مما سنفعله بعد ذلك ... "

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

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

5. عدم المساءلة.

"يتوقف باك ... هناك ، وداعًا!" - على الأرجح هاري ترومان

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

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

6. نقل أهداف المرمى في كثير من الأحيان.

"حسنًا ، ولكن يجب أن يكون الجسر أيضًا بمثابة مدرج ، ولديه 10 حارات أخرى ، وماذا عن حديقة في منتصفها؟"

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

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

7. عدم كفاية الوثائق والتتبع.

"تشير تعليمات نزع فتيل هذه القنبلة إلى سحب السلك الأحمر بمجرد انقطاع التيار الكهربائي ، لكن جميع الأسلاك حمراء وكان من المفترض أن تنقطع الطاقة قبل 10 دقائق!" - جيمس بوند ، في ما سيكون نهاية حياته المهنية

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

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

8. تعريف النظام بشكل سيء.

"هل تعني WTF أن هناك 5 أرغفة وسمكتين فقط لكل 5000 منا ؟!"

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

9. ضعف الإعداد.

"لا نزال نطير نصف سفينة".

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

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

10. توقعات غير واقعية.

"حسنًا ، يبدو التطبيق جيدًا - ولكن لماذا لا يتغير نظام الألوان تلقائيًا لمطابقة حالة هاتف المستخدم؟"

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

نأمل ، من خلال تجنب هذه العثرات العشر ، سيكون مشروع تطوير البرمجيات التالي نجاحًا مذهلاً! ما هي المشكلات التي واجهتك في مشاريع البرامج الخاصة بك؟

مهلا! أنا تومر ، رجل أعمال ، وصانع. ربما تعرفني من Mevee و Crane و Shots و Slides و investorintelligence.io من بين المنتجات الأخرى التي أطلقتها! هذا المقال جزء من سلسلة أكثر اتساعًا أكتبها استنادًا إلى تجربتي وهي مصنوعة أساسًا من رأيي وآراء فريقي.

آمل أن يكون هذا يساعدك على تجنب ارتكاب نفس الأخطاء التي ارتكبت ، وتذكر أن تستمر في الشحن!

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