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

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

١. الهدف في ثلاثة أسطر

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

السؤال الثالث أهم مما يبان. بدون مقياس نجاح، كل ميزة تبان ضرورية، وما عندك معيار تحذف فيه شي. ومع المقياس، تقدر تسأل عن كل ميزة: هل تقرّبني من الهدف ولا لا؟

٢. المستخدمين وأدوارهم

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

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

٣. الرحلة الأساسية، خطوة بخطوة

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

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

٤. التفاصيل اللي تغيّر السعر

هذي البنود اللي إذا ما ذكرتها الحين، بتنذكر بعدين كـ«إضافة». جاوب على كل وحدة بنعم أو لا:

• دفع إلكتروني داخل التطبيق؟ وبأي طرق دفع؟
• حجز مواعيد أو تقويم؟
• خرائط أو تتبّع موقع؟
• إشعارات؟ ومتى تنرسل؟
• محادثة بين المستخدمين؟
• رفع صور أو ملفات أو فيديو؟
• أكثر من لغة؟
• ربط مع نظام موجود عندك، مثل نظام محاسبة أو مخزون؟
• لوحة تحكم ويب للإدارة؟
• تطبيق جوال، أو موقع، أو الاثنين؟

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

٥. اللي عندك واللي ناقصك

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

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

٦. الحدود: الميزانية والوقت والنسخة الأولى

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

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