كيف تكتب وثيقة متطلبات برمجية تستطيع الشركات تسعيرها بدقة؟

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

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

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

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

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

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

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

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