كيفية تحديد نطاق مشروع برمجي قبل التعاقد مع مطور

السبب الأول وراء تجاوز المشاريع البرمجية للميزانية:لم يتم تحديد النطاق قبل بدء التطوير.المطورين ليسوا سيئين. ليست تكنولوجيا خاطئة. نطاق غير واضح. وجدت دراسة لمؤشر مديري المشتريات (PMI) لعام 2024 أن 52% من المشاريع تشهد زحفًا في النطاق، وأن تلك المشاريع تتجاوز الميزانية بنسبة 27% في المتوسط.

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

هذا هو الإطار الذي نستخدمه في Savi عند تشغيل جلسات تحديد نطاق المشروع مع العملاء. يمكنك القيام بذلك بنفسك خلال 2-4 ساعات.

ما الذي يجب أن تتضمنه وثيقة النطاق

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

1. أدوار المستخدم.من يستخدم النظام؟ يكلف التطبيق الذي يواجه العملاء بدور واحد أقل بكثير من النظام الأساسي الذي يحتوي على خمسة أدوار (العميل، البائع، المسؤول، وكيل الدعم، المشرف المتميز). يحتاج كل دور إلى طرق العرض والأذونات وقواعد الوصول إلى البيانات الخاصة به. قم بإدراج كل الأدوار، حتى تلك التي تعتقد أنها واضحة. "المسؤول" ليس واضحا؛ يمكن أن يعني 10 مستويات إذن مختلفة.

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

3. التكامل.كل نظام خارجي يلمسه منتجك: بوابات الدفع، وموفرو البريد الإلكتروني، وواجهات برمجة تطبيقات الرسائل القصيرة، وأدوات التحليلات، وأنظمة إدارة علاقات العملاء، وبرامج المحاسبة. يضيف كل تكامل ما بين 1000 إلى 4000 دولار أمريكي إلى المشروع اعتمادًا على جودة واجهة برمجة التطبيقات (API) وتعقيدها.

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

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

ما الذي لا ينبغي أن تتضمنه وثيقة النطاق

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

قرارات المكدس الفنية.لا تحدد "استخدام PostgreSQL مع التخزين المؤقت لـ Redis والنشر على AWS." هذه هي وظيفة المطور. أنت تحدد ما يفعله النظام؛ يقررون كيف يفعل ذلك. إذا قمت بإملاء اختيارات التكنولوجيا دون سياق هندسي، فإما أن تحد من خياراتك أو تدفع مقابل حزمة لا تناسب المشكلة.

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

نماذج واجهة مستخدم مثالية بالبكسل.تعتبر الإطارات السلكية والتخطيطات التقريبية مفيدة. ملفات Figma المثالية للبكسل قبل تحديد النطاق أمر سابق لأوانه. ستعيد تصميم 40% من شاشاتك بمجرد رؤية المستخدم يتدفق أثناء العمل. استثمر في التصميم التفصيلي بعد تحديد النطاق، وليس قبله.

كيفية تحديد أدوار المستخدم والتدفقات

استخدم هذا القالب لكل ميزة في مستند متطلبات البرنامج الخاص بك:

أمثلة:

• كعميل، يمكنني تصفية المنتجات حسب الفئة والنطاق السعري حتى أتمكن من العثور على ما أحتاج إليه في أقل من 10 ثوانٍ.
• باعتبارهمسؤل، يمكنني تصدير جميع الطلبات من آخر 30 يومًا كملف CSV حتى أتمكن من التوفيق مع برنامج المحاسبة الخاص بي.
• كبائع، يمكنني تحديد أسعار المنتجات وعدد المخزون الخاص بي حتى أتمكن من التحكم في واجهة متجري دون الاتصال بالدعم.

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

اكتب 10-30 من هذه العبارات. هذه هي قائمة الميزات الخاصة بك. هذا ما ترسله إلى المطورين عندما تطلب عروض الأسعار.

كيفية تحديد أولويات الميزات: طريقة MoSCoW

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

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

يجب أن يكون:مهم ولكن يمكن إطلاق المنتج بدونها. تتبع الطلب، وإشعارات البريد الإلكتروني، وتنبيهات المخزون. إنها تجعل التجربة أفضل، ولكن لا يزال بإمكان العملاء شراء الأشياء بدونها.

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

لن يكون (في هذه الجولة):الميزات التي قررت تأجيلها إلى مرحلة لاحقة. تطبيق جوال، دعم متعدد اللغات، نموذج السوق. من المهم تدوينها؛ يمنع زحف النطاق عن طريق جعل الحدود واضحة.

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

كيفية التعامل مع عمليات التكامل

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

لكل تكامل، قم بتوثيق ثلاثة تفاصيل:

• ما النظام:Stripe وSendGrid وTwilio وGoogle Analytics وQuickBooks وما إلى ذلك.
• ما هي البيانات التي تتدفق حيث:"تنتقل معلومات الدفع الخاصة بالعميل إلى Stripe. ويرسل Stripe خطافًا على الويب لتأكيد الدفع. يقوم نظامنا بتحديث حالة الطلب ويقوم بتشغيل رسالة تأكيد عبر البريد الإلكتروني من خلال SendGrid."
• ماذا يحدث عندما تفشل:"إذا كان Stripe معطلاً، أظهر للعميل رسالة خطأ واحفظ سلة التسوق الخاصة به. أعد محاولة الدفع خلال 5 دقائق."

يقوم معظم المؤسسين بإدراج الأولين ويتخطون الثالث. تمثل معالجة الأخطاء 20-30% من أعمال التكامل. إذا لم تحدده في النطاق، فسيقوم المطور بتخطيه (سيء) أو يخمن ما تريده (سيء أيضًا).

تحديد معايير النجاح

"ينتهي المشروع عندما ينجح" ليس معيارًا للنجاح. إنها وصفة لمراجعات لا نهاية لها. تحديد النتائج القابلة للقياس قبل بدء التطوير:

• يمكن للمستخدم الجديد الاشتراك وإكمال عملية الشراء الأولى في أقل من 3 دقائق.
• تقوم لوحة تحكم المشرف بتحميل جميع الطلبات من آخر 90 يومًا في أقل من ثانيتين.
• يتعامل النظام مع 500 مستخدم متزامن دون أن تتجاوز أوقات الاستجابة ثانية واحدة.
• يتم تسجيل جميع معاملات الدفع باستخدام الطوابع الزمنية ويمكن تصديرها للتدقيق.
• حصل التطبيق على 90+ في Google Lighthouse من حيث الأداء وإمكانية الوصول.

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

أخطاء النطاق الشائعة

بعد إجراء المئات من جلسات تحديد نطاق المشروع، هذه هي الأنماط التي تؤدي باستمرار إلى تجاوز الميزانية:

كتابة رواية بدلا من قائمة المراجعة.وثيقة المتطلبات المكونة من 40 صفحة لا تجعل المشروع أكثر وضوحًا. ويجعل من الصعب تقديرها. يقوم المطورون بمسح المستندات الطويلة. يقرؤون قوائم المراجعة. احتفظ بمستند النطاق الخاص بك في أقل من 5 صفحات مع نقاط نقطية وقصص المستخدم وقائمة الميزات ذات الأولوية.

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

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

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

قالب نطاق بسيط

استخدم قائمة المراجعة هذه كنقطة بداية عند كتابة متطلبات البرامج لمشروعك التالي:

ماذا يحدث بعد تحديد النطاق

بمجرد اكتمال مستند النطاق الخاص بك، تصبح جاهزًا للحصول على عروض الأسعار. أرسل نفس المستند إلى 2-4 وكالات أو مطورين. يتيح لك النطاق الواضح مقارنة المقترحات على أساس "التفاحة إلى التفاحة". إذا اقتبست إحدى الوكالات مبلغ 8000 دولار أمريكي واقتبست وكالة أخرى 25000 دولار أمريكي لنفس النطاق، فيمكنك طرح أسئلة محددة حول السبب.

إليك التسلسل النموذجي:

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

2. مراجعة المقترحات.قارن على ثلاثة أبعاد: السعر، والجدول الزمني، ومن يقوم بالعمل. عرض أسعار بقيمة 10000 دولار أمريكي من أحد كبار المهندسين الذي يقوم بالشحن خلال 4 أسابيع يتفوق على عرض أسعار بقيمة 7000 دولار أمريكي من فريق مبتدئ يقوم بالشحن خلال 12 أسبوعًا. اقرأ المزيد عن وكالات التقييم في دليلنا الخاص بذلككيفية استئجار وكالة التنمية.

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

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

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

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