تلقينا مئات الموجزات على مر السنين. بعضها أدى إلى مكالمات أولى منتجة ومشاريع موقعة خلال أسابيع. وبعضها الآخر أدى إلى ثلاث اجتماعات حيث لم يكن أحد متأكدًا ماذا نبني فعلًا.
الفرق لا يأتي تقريبًا أبدًا من حجم المشروع أو الميزانية. إنه يأتي من الموجز.
الموجز الجيد يوفر الوقت للجميع — وقتكم ووقتنا. الموجز السيء يخلق دورة من التوقعات غير المتوافقة، والتقديرات الغامضة، والاجتماعات الضائعة. والأسوأ: معظم الموجزات السيئة لا يكتبها أشخاص لا يعرفون ما يريدون. يكتبها أشخاص يعرفون تمامًا ما يريدون لكنهم يصفونه بطريقة مستحيلة التحديد.
هذا المقال هو الدليل الذي نتمنى لو نستطيع إرساله لكل عميل محتمل قبل المكالمة الأولى. وقد حولناه أيضًا إلى قالب Word قابل للتعبئة يمكنكم تحميله وإرساله لأي شركة — بما فيها نحن.
ما الهدف الحقيقي من الموجز
الموجز ليس عقدًا. ليس وثيقة مواصفات. ليس ملف PDF من 40 صفحة مع إطارات سلكية ومخططات قواعد بيانات.
الموجز هو نقطة بداية لمحادثة. وظيفته أن يعطي الشركة سياقًا كافيًا لعقد اجتماع أول ذكي — اجتماع نطرح فيه الأسئلة الصحيحة بدلًا من قضاء ساعة في فهم الأساسيات.
أفضل الموجزات قصيرة وواضحة وصادقة حول ما هو معروف وما ليس كذلك.
الأسئلة السبعة التي يجب أن يجيب عنها موجزك
لا تحتاج قالبًا. لا تحتاج عناوين وتنسيقًا. تحتاج فقط أن تجيب على هذه الأسئلة السبعة بوضوح. صفحة أو اثنتان تكفيان.
1. ما المشكلة التي تحلها؟
ليس «ما الذي تريد بناءه» — ما المشكلة الموجودة اليوم؟ «فريق المبيعات لدينا يتتبع العملاء المحتملين في جداول بيانات ويفقد 30% من المتابعات» مفيد. «نحتاج نظام CRM» ليس كذلك — لأن الحل قد لا يكون CRM أصلًا.
ابدأ بالمشكلة. الحل يأتي لاحقًا.
2. من سيستخدم هذا البرنامج؟
اذكر الأشخاص الفعليين. «فريق العمليات المكون من 12 شخصًا» واضح. «أصحاب المصلحة المختلفون عبر المؤسسة» ليس كذلك. ما مستواهم التقني؟ كم مرة سيستخدمونه؟ هل هم موظفون داخليون أم عملاء خارجيون؟
ملف المستخدم يحدد كل قرار تصميم وتقني.
3. ما الموجود اليوم؟
ما الأدوات أو العمليات التي يستخدمها الناس حاليًا لمعالجة هذه المشكلة؟ جداول بيانات؟ أداة منافس؟ ورق؟ لا شيء؟ إذا كان هناك نظام موجود، ما الذي يعمل فيه وما الذي لا يعمل؟
هذا يخبر الشركة إن كانت تستبدل شيئًا، أو تحسّن شيئًا، أو تبني من الصفر — ثلاثة مشاريع مختلفة تمامًا.
4. كيف يبدو النجاح؟
ليس ميزات — نتائج. «وقت معالجة الطلبات ينخفض من 3 أيام إلى 4 ساعات.» «نتوقف عن فقدان بيانات العملاء بين الأقسام.» «يمكننا تأهيل موظف جديد بدون أسبوع من التدريب.»
إذا لم تستطع وصف النجاح بدون سرد الميزات، قد تكون تبحث عن حل بدلًا من حل مشكلة.
5. ما نطاق ميزانيتك؟
هذا السؤال الذي يتجنبه الجميع، وهو الأهم.
لا تحتاج رقمًا دقيقًا. لكن «ما بين 20 ألف و50 ألف دولار» أفيد بما لا يُقاس من «سنناقش الميزانية لاحقًا.» السبب: حل بـ 20 ألف وحل بـ 200 ألف لنفس المشكلة يبدوان مختلفين تمامًا. بدون نطاق، الشركة إما تخطئ التقدير أو تعطيك عرضًا لا يتوافق مع واقعك.
الشفافية حول الميزانية ليست نقطة ضعف في التفاوض. إنها توفير للوقت. الشركة الجيدة ستخبرك بما هو ممكن ضمن نطاقك — وما ليس كذلك.
6. ما جدولك الزمني؟
هل هناك موعد نهائي صارم — متطلب تنظيمي، إطلاق منتج، تاريخ بدء عقد؟ أم الجدول الزمني مرن؟ كلاهما مقبول، لكن الشركة تحتاج معرفة أيهما قبل تحديد النطاق.
«نحتاج هذا في الإنتاج بحلول سبتمبر» و«نريد البدء عندما يتوفر الشريك المناسب» يؤديان لخطط مشاريع مختلفة جدًا.
7. ما الذي قررتموه بالفعل — وما المفتوح؟
هل اخترتم منصة بالفعل؟ هل يجب أن يعمل مع أدوات محددة؟ هل التصميم جاهز؟ هل هناك قيود تقنية من فريق تكنولوجيا المعلومات لديكم؟
وبنفس الأهمية: ما الذي لستم متأكدين منه؟ أين تريدون رأي الشركة؟ أفضل المشاريع هي تلك التي يكون فيها العميل صادقًا حول ما لا يعرفه.
ما يجب تركه خارجًا
الموجز ليس مواصفات. قاوموا الرغبة في تضمين:
إطارات سلكية شاشة بشاشة رسمتموها بأنفسكم. هذا يقفل المحادثة على حل محدد قبل أن تُفهم المشكلة بالكامل. شاركوها كمرجع إن أردتم، لكن لا تعاملوها كمتطلبات.
متطلبات تقنية مفصلة وجدتموها على الإنترنت. «يجب استخدام معمارية الخدمات المصغرة» أو «يجب البناء بـ React» — ما لم يكن لديكم فريق تقني اتخذ هذا القرار، اتركوا التقنية للشركة. هذا ما توظفونها من أجله.
مستند من 30 صفحة. إذا كان موجزكم أطول من 3 صفحات، فهو لم يعد موجزًا. إنه مواصفات ستحتاج الشركة للتحقق منها على أي حال.
ما يجعلنا نأخذ الموجز بجدية
بعد سنوات من قراءة موجزات المشاريع، إليكم الإشارات التي تخبرنا أن العميل المحتمل فكّر جيدًا:
يصف المشكلة قبل الحل. صادق حول ما لا يعرفه. يتضمن نطاق ميزانية دون أن نطلبه. شرح من هم المستخدمون وما يستخدمونه اليوم. والموجز موجز — لأن الوضوح يتطلب جهدًا، والموجز المختصر يشير إلى عميل يحترم وقت الجميع.
في المقابل، الموجزات التي تقول «نحتاج تطبيقًا» بدون سياق، والموجزات المكونة من 40 صفحة من مواصفات منسوخة من مشروع آخر، والموجزات بدون ميزانية ولا جدول زمني — هذه عادةً تؤدي إلى دورات مبيعات طويلة وتوقعات غير متطابقة.
حمّلوا القالب
حولنا هذه الأسئلة السبعة إلى قالب من صفحة واحدة يمكنكم تعبئته وإرساله لأي شركة — بما فيها نحن. مستند Word بسيط مع إرشادات لكل قسم. لا بريد إلكتروني مطلوب، لا تسجيل.
تحميل قالب موجز المشروع البرمجي (Word) →
استخدموا هذا كقائمة مراجعة
قبل إرسال موجزكم القادم لأي شركة — ليس فقط نحن — راجعوا الأسئلة السبعة أعلاه. إذا استطعتم الإجابة على السبعة بلغة بسيطة، اجتماعكم الأول سيكون منتجًا، تقديركم سيكون أدق، والمشروع سيبدأ على أساس أقوى.
كتبنا عن كيف نسلّم المشاريع بمجرد بدء العمل وعن كيف نقيّم قرارات التطوير مقابل الشراء. لكن كل ذلك يبدأ بموجز واضح. سقف جودة المشروع يُحدد قبل أول سطر كود.
لديكم مشروع في ذهنكم وتريدون مناقشته؟ لنبدأ المحادثة →