ما يجب وضعه في طلب تقديم العروض لتطوير البرمجيات (والبنود الخمسة التي تحميك)

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

ما الذي يحتويه طلب تقديم العروض الجيد لتطوير البرمجيات؟

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

1. المشكلة والهدف. صف ما هو مكسور أو مفقود وكيف يبدو النجاح بعبارات واضحة. بائع جيد يقترح البناء؛ تصف النتيجة. إذا قمت بتحديد الحل بالتفصيل، فستعرف فقط ما إذا كان بإمكانهم اتباع التعليمات.
2. القيود والسياق. نطاق الميزانية، والجدول الزمني، والأنظمة التي يجب أن تتكامل معها، والبيانات التي ستتطرق إليها، وأي التزامات تنظيمية. إن إخفاء الميزانية يضيع وقت الجميع وينتج عنه عروض أسعار لا يمكنك مقارنتها.
3. النطاق، واضح على كلا الجانبين. قم بإدراج ما هو موجود، وما لا يقل أهمية عن ذلك، ما هو خارج. تبدأ معظم الخلافات في الفجوة بين ما افترض أحد الطرفين أنه تم تضمينه وما لم يفعله الطرف الآخر.
4. معايير التقييم. اذكر كيفية تقييم العروض: الخبرة ذات الصلة، والنهج الفني، والفريق، والسعر، والشروط الواردة أدناه. يكتب البائعون ما تقيسه.
5. شروط الحماية. الخمسة أدناه. إن وضعها في طلب تقديم العروض، وليس في العقد اللاحق، هو أكبر شيء يفصل بين المشتري الذي يظل مسيطرًا والمشتري الذي لا يفعل ذلك.

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

ما هي البنود الخمسة التي تحميك في طلب تقديم العروض البرمجي؟

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

بند	ما يؤمن	ما العيب بدونه
ملكية IP	أنت تمتلك الكود المصدري والأصول وحق تعديلها	يمتلك البائع الكود وتقوم أنت بترخيص نظامك الخاص منه
معايير القبول	اختبار موضوعي لـ "تم" قبل الدفع النهائي	جدل لا نهاية له حول ما إذا كان العمل يلبي المواصفات
التسليم والتوثيق	التعليمات البرمجية وبيانات الاعتماد والمستندات التي تسمح لفريق آخر بتولي المسؤولية	أنت مقيد لأنهم فقط هم الذين يفهمون كيفية تشغيله
تغيير التحكم	عملية ومعدل متفق عليهما للتغييرات في النطاق	فواتير مفاجئة، أو رفض التعديل كما تعلم
الدعم والصيانة	أوقات الاستجابة المحددة والتكاليف بعد الإطلاق	نظام حي ولا يلزم أحد بإصلاحه

لماذا تنتمي ملكية IP إلى طلب تقديم العروض وليس العقد؟

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

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

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

كيف يبقيك التسليم وتغيير التحكم والدعم مسيطرًا؟

يقرر هؤلاء الثلاثة ما إذا كنت تمتلك نظامًا أم أنك تقوم فقط بتأجير الوصول إلى الأشخاص الذين قاموا ببنائه.

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

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

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

##الوجبات العملية

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