قبل ما تبدأ برمجة مشروع SaaS.. من الفكرة الى قرار البناء

اغلب الناس بتوصل للنقطة دي بنفس الطريقة تقريبا.

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

وبعدين بيحصل واحد من اتنين.

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

الاتنين مش تعطيل.

الاتنين اول مؤشر حقيقي على ان الفكرة لسه مش محسومة بالقدر اللي يسمح بتنفيذها.

الدليل ده مش بيقول "متبدأش"

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

بيقول حاجة اضيق من دي بكتير:

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

Tool داخلي لفريقك، المستخدم معروف، والتجربة قابلة للتعديل والتراجع بسهولة؟

ده قرار سهل نسبيا.. ابدأ واختبر.

منتج SaaS هيتباع لسوق، وهيتبني عليه Business، وداخل على تعاقد تطوير مش سهل تتحمله مرتين؟

ده قرار مختلف.

ويستاهل مساحة اكبر شوية من الفهم قبل التنفيذ.

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

وخليني اكون واضح من البداية

احنا في إتقان بنبني SaaS.

يعني على الورق، كل ما ناس تدخل تطوير بسرعة، ده في صالحنا.

بس اللي بنشوفه عمليا عكس كده.

المشروع اللي بيدخل التنفيذ وال Scope بتاعه لسه بيتحرك بيتكلف اكتر على الطرفين.

صاحب المشروع بيدفع في تغييرات ما كانتش في الحسبان، وفريق التنفيذ بيشتغل على تعريف بيتغير من تحته.

فاللي جاي مش نصيحة عامة عن انك "تخطط كويس".

دي القرارات اللي بتظهر قدامنا من الناحيتين.. لما نستقبل الفكرة من صاحبها، ولما يبقى مطلوب من فريق التنفيذ يسعرها ويبنيها.

هتمشي في كام قرار

الدليل مش بيشرح Methodology كاملة.

هو بيمشي في قرارات مترتبة:

• اللي معاك دلوقتي قائمة Features.. ولا Scope؟
• عندك Evidence.. ولا اراء عن الفكرة؟
• انهي افتراض هو الاخطر لو طلع غلط؟
• هل حجم القرار يستحق شغل منظم ومكتوب قبل التطوير؟
• ايه اقل حاجة تستحق البناء عشان تختبر الافتراض؟
• وامتى المشروع يبقى ناضج كفاية يتسلم لفريق تنفيذ؟

مفيش هنا وعد ان فكرتك هتنجح.

مفيش مرحلة قبل التنفيذ تقدر تقدم الوعد ده.

المطلوب ابسط:

قلل المساحة اللي بتخمن فيها قبل ما التخمين يتحول لشهور تطوير والتزامات اصعب في الرجوع عنها.

ونبدأ من اقرب حاجة ليك دلوقتي.. الورقة اللي كاتب فيها المنتج.

لما فكرة SaaS توصل لمرحلة جدية، نادرا ما بتوصل في صورة "مشكلة" بس.

غالبا صاحب المشروع فكر فيها فترة، شاف منافسين، تخيل شاشات، ويمكن كلم شركة او اكتر.

فالوصف اللي بيوصل في النهاية بيبقى شبه:

"محتاج Dashboard، ونظام صلاحيات، واشتراكات، وNotifications، وتقارير، وAI Assistant..."

المشكلة مش ان ال Features دي غلط.

المشكلة اننا لسه مش عارفين:

كل Feature فيهم بتحل اي مشكلة، ولمين، وليه بالطريقة دي تحديدا؟

وده فرق مهم قبل ما اي حد يبدأ تصميم او تسعير.

ال Feature بتخبي وراها قرار

لما تقول: "محتاج Notifications" — السؤال مش بس Push ولا Email؟ السؤال الاسبق: اي حدث مهم لدرجة ان المستخدم محتاج يعرفه فورا؟

ولما تقول: "محتاج Dashboard" — السؤال مش هنحط فيها كام Chart؟ السؤال: مين هيفتحها؟ وايه القرار اللي المفروض ياخده بعد ما يشوفها؟

ولما تقول: "عايز AI Assistant" — السؤال مش هنستخدم Model ايه؟ السؤال: اي شغل بيتعمل دلوقتي ومحتاج يتغير؟ وليه AI هو الاختيار المناسب اصلا؟

اول ما تبدأ تفك ال Features بالشكل ده، ساعات تكتشف ان جزء منها مطلوب فعلا.

وساعات المشكلة موجودة لكن الحل المقترح اكبر منها.

وساعات Feature مهمة جدا في تصور صاحب المشروع، لكن المستخدم معندوش الموقف اللي يخليه يستخدمها اصلا.

دي مش مناقشة UX متأخرة. دي مناقشة Scope قبل ما ال Scope يتحول لتكلفة.

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

من ناحية صاحب المشروع، قائمة ال Features ممكن تبان تعريف واضح.

ومن ناحية فريق التطوير، نفس القائمة ممكن تفتح اسئلة تغير المنتج نفسه.

مثلا: "ادارة العملاء" — هل المقصود بيانات Contact فقط؟ ولا Pipeline؟ ولا Tasks؟ ولا سجل تواصل؟ ولا صلاحيات؟ ولا Import من نظام موجود؟

كل اجابة ممكن تغير التصميم، ال Data Model، حجم العمل، والتكلفة.

وعشان كده نفس الوصف ممكن يروح لاكتر من فريق، وكل فريق يبني تقديره على فهم مختلف للمطلوب.

المشكلة مش بالضرورة ان حد منهم غلط. المشكلة ان المنتج نفسه لسه بيسمح باكتر من تفسير.

ارجع خطوة واحدة قبل الحل

قبل ما تعتمد Feature رئيسية، حاول تكتب تحتها اربع حاجات:

• الموقف: ايه اللي بيحصل للمستخدم دلوقتي؟
• المشكلة: ايه الصعوبة او الخسارة او التعطيل؟
• البديل الحالي: بيتعامل معاها ازاي النهارده؟
• النتيجة المطلوبة: ايه اللي المفروض يبقى مختلف لو المنتج اشتغل كويس؟

بدل مثلا: "نحتاج نظام تقارير متقدم." ممكن نكتشف ان المشكلة الحقيقية: "مدير التشغيل مش قادر يعرف الطلبات اللي واقفة وسبب التأخير من غير ما يجمع المعلومات يدويا من اكتر من شخص."

دلوقتي السؤال اتغير: هل الحل Reporting Module؟ ولا View واحدة للطلبات المتأخرة؟ ولا Alerts؟ ولا تغيير في ال Workflow نفسه؟

ممكن الاجابة في النهاية تكون "نظام تقارير"، بس الفرق اننا وصلنا له كحل لمشكلة واضحة.. مش ك Feature اتحطت في القائمة من البداية.

مش كل حاجة طلبها المستخدم تتحول Requirement

المستخدم ممكن يقترح حل بنفسه: "اعملولي تطبيق موبايل"، "ضيفوا Chat"، "خلوه بال AI"، "لازم يبقى فيه Approval من المدير".

الكلام مهم.. لكنه Input مش Requirement نهائي.

محتاجين نفهم ليه قاله: يمكن التطبيق مطلوب عشان الفريق مش بيقعد قدام الكمبيوتر. يمكن ال Chat محاولة لحل بطء الوصول للمعلومة. يمكن ال Approval موجود عشان النظام الحالي مفيهوش صلاحيات واضحة.

لو اخدت الحل المقترح حرفيا، ممكن تبني Feature. لو فهمت السبب، ممكن تلاقي حل ابسط او مختلف تماما.

القرار المطلوب هنا

في نهاية الخطوة دي مش مطلوب تكون حددت كل تفاصيل المنتج. المطلوب انك تقدر تبص لاهم ال Features وتقول:

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

لو مش قادر تعمل ده، فقائمة ال Features لسه مش Scope. هي تصور للحل. والفرق بينهم بيبان جدا اول ما المشروع يدخل تصميم وتسعير وبرمجة.

في اغلب المشاريع اللي بتوصل لمرحلة جدية، صاحب الفكرة يكون عمل بحث بشكل او باخر.

كلم ناس من المجال، سأل في مجموعات، بص على منافسين، ويمكن عمل استبيان.

فالمشكلة نادرا ما تكون: "ما اتعملش بحث." المشكلة الاكثر شيوعا ان اللي اتجمع مش قابل يتبني عليه قرار.

اسهل نتيجة تجمعها.. واقلها فايدة

"الفكرة حلوة" — "اه ده هيفيدنا" — "لو نزلت هستخدمها"

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

لكن حتى لو الكلام صادق، هو لسه توقع عن سلوك في المستقبل. والتوقع ده مش بيتحول بسهولة لقرار Scope.

ناس قالت "هنستخدمها".. طب تبني ايه بالظبط؟ اي Feature تتأجل؟ مين المستخدم الاول اللي تصمم له؟ لسه معندكش اجابة.

الاختبار الحقيقي لاي سؤال في البحث

قبل ما تسأل اي سؤال، اسأل نفسك سؤال قبله:

لو الاجابة طلعت عكس اللي متوقعه.. كان هيتغير ايه في المشروع؟

لو الرد "مفيش حاجة" فالسؤال غالبا بيجمع طمأنينة اكتر ما بيجمع معلومة. لكن لو الرد "كنا هنغير الشريحة" او "كنا هنأجل جزء كبير من ال MVP" او "الحل كان هياخد شكل مختلف" — يبقى السؤال ده يستحق وقتك.

دي طريقة بسيطة تفرق بيها بين بحث بيخدم القرار وبحث بيخدم الحماس.

الادلة مش كلها بنفس القوة

بشكل عام، كل ما الدليل قرب من سلوك حصل فعلا ومن تكلفة تحملها المستخدم بسبب المشكلة، كل ما وزنه في القرار يزيد.

• رأي في الفكرة
• وعد بسلوك مستقبلي
• وصف لسلوك حصل بالفعل
• اثر موجود تقدر تشوفه
• تكلفة حقيقية تحملها المستخدم بسبب المشكلة

والتكلفة هنا مش لازم تكون فاتورة اتدفعت لشركة. ممكن تكون وقت، شغل يدوي، موظف بيكرر خطوة كل يوم، فرصة بتضيع، او نظام مؤقت اتعمل عشان الناس تعرف تكمل شغلها.

دور على الاثر.. مش الكلام بس

لو المشكلة موجودة فعلا، غالبا حد عمل حاجة عشان يتعايش معاها:

• شيت Excel بيتحدث يدويا
• مجموعة WhatsApp اتعملت للتنسيق
• موظف بيقضي جزء من يومه في خطوة متكررة
• اشتراك في اداة بيستخدموا منها جزء صغير
• ملف بيتبعت كل اسبوع بنفس الشكل

الحاجات دي مهمة لانك مش بس سمعت ان المشكلة موجودة.. انت شايف اثرها على طريقة الشغل.

البحث اللي مش بيوصل لفريق التنفيذ

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

ممكن يبقى عندك بحث حقيقي ومحترم، لكن نتيجته مكتوبة بالشكل ده: "العملاء عايزين حل اسرع"، "فيه احتياج واضح في السوق"، "المستخدمين مش راضيين عن الادوات الحالية".

الكلام ممكن يكون صحيح، لكن مش بيقول لفريق التصميم ايه اللي يتغير، ولا يساعد في اختيار Feature تدخل ال MVP او تتأجل.

البحث يبقى مفيد لما تقدر تحول نتيجة منه لجملة تبدأ ب "عشان كده هنبني.." او "عشان كده مش هنبني.."

ولمعرفة كيف يؤدي القفز فوق البحث إلى تعثر المشاريع تقنيا وتجاريا، راجع تحليلنا في مقال: لماذا تفشل مشاريع SaaS قبل أن تبدأ البرمجة؟.

طب اكلم كام واحد؟

الاجابة مش رقم ثابت. انت في المرحلة دي مش بتحاول تنتج دراسة احصائية للسوق كله. انت بتحاول تفهم موقف وسلوك وقرار.

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

وبرضه.. عدد كبير من المقابلات مع ناس المشكلة مش جزء حقيقي من حياتهم اقل فايدة من عدد اصغر مع ناس المشكلة متكررة وبتكلفهم حاجة فعلا.

لما البحث يقول حاجة مش عاجباك

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

وساعات الكلام ده يكون صح، وساعات يكون طريقة للاحتفاظ بالفكرة زي ما هي.

السؤال اللي يكشف الفرق: هل غيرت حاجة بناء على البحث؟

لو خرجت من كل البحث بنفس المشروع بالظبط اللي دخلت بيه، فيه احتمال انك كنت بتدور على Confirmation اكتر من انك كنت بتختبر الفكرة. وده مش اتهام، ده طبيعي لما تكون متحمس لحاجة اشتغلت عليها فترة. لكن تكلفته بتظهر بعدين لو القرارات دي دخلت الكود من غير اختبار.

في نهاية البحث.. لازم يبقى عندك

• وصف للموقف اللي بيحصل فعلا عند شريحة محددة
• الطريقة اللي بيتعاملوا بيها معاه دلوقتي
• اثر المشكلة على شغلهم
• اللي اتأكد
• اللي اتغير عن تصورك الاول
• والاسئلة اللي لسه مفتوحة

اللي عرفته من البحث بقى معروف. واللي فضل مفتوح بقى افتراض. وده اللي يحدد الخطوة اللي بعدها.

بعد البحث، الصورة بتتقسم بشكل انضف: فيه حاجات عندك عليها Evidence، وفيه حاجات لسه Assumptions.

الغلط هنا انك تجمع كل الافتراضات في جدول، تكتب جنب كل واحد "مهم"، وتبدأ تتعامل معاهم كأنهم متساويين. مش متساويين.

فيه افتراض غلطه اصلاح.. وافتراض غلطه تغيير مشروع

افتراض ممكن يطلع غلط فتغير شاشة، تنقل خطوة، تغير ترتيب Feature، تضيف Validation.. ده ممكن يضايقك، لكنه اصلاح.

وفيه افتراض لو طلع غلط، اللي بيتغير مش الشاشة. اللي بيتغير هو المشروع.

• الشريحة اللي اخترتها مش هي الشريحة اللي عندها المشكلة.
• الناس مش مستعدة تغير الطريقة الحالية.
• التكلفة التشغيلية تخلي النموذج التجاري غير منطقي.
• الخدمة اللي كنت فاكرها Software بالكامل محتاجة تدخل بشري مستمر.
• او وظيفة تقنية محورية طلع تنفيذها بالشكل المطلوب غير واقعي.

هنا احنا مش قدام UX adjustment. احنا قدام قرار منتج.

وفيه سؤال تاني.. الغلط هيبان امتى؟

في افتراض غلطه ممكن يظهر في Prototype او مقابلة، وده رخيص نسبيا.

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

كل ما الخطأ اغلى ويتكشف متاخر، كل ما يستحق يتحرك لفوق في اولويات الاختبار.

المطلوب مش انك تلغي عدم اليقين كله. المطلوب تعرف اي عدم يقين مينفعش يدخل معاك البرمجة وهو مستخبي.

الترتيب مش لستة.. اختيار واحد

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

الترتيب الحقيقي بيحصل لما تجبر نفسك على سؤال ضيق:

لو مسموحلي اختبر حاجة واحدة بس قبل ما ابدأ ابني.. هي ايه؟

والمعيار اللي بيفرز بسيط: لو الافتراض طلع غلط.. هل اللي هيتغير هو الحل؟ ولا اللي هيتغير هو المشروع؟ النوع التاني هو اللي يستحق تقف عنده الاول.

وغالبا بيطلع من واحدة من مناطق زي: مين العميل فعلا، هل هيغير طريقته الحالية، هل اقتصاد المنتج قادر يشيل تكلفة تقديم الخدمة، هل التشغيل محتاج تدخل بشري اكبر من المتوقع، وهل فيه اعتماد تقني ممكن يقلب التكلفة او شكل المنتج.

مش مطلوب تعمل تحليل ضخم لكل منطقة. اقراها واسأل: لو الاجابة هنا طلعت عكس اللي فاكره.. هيتغير الحل ولا المشروع؟

ولو لقيت نفسك مش قادر تختار افتراض واحد من بينهم، دي معلومة مهمة في حد ذاتها: غالبا معناها ان الفكرة لسه واسعة، واي MVP هتحدده دلوقتي هيبقى مبني على اكتر من مجهول في نفس الوقت.

النتيجة اللي تهمك هنا

• حاجات معروفة ومدعومة ب Evidence
• حاجات لسه افتراضات
• فهم لتكلفة اكتشاف كل افتراض متاخر
• وافتراض واحد متسمي بالاسم.. هو اللي هيتختبر قبل اي بناء

مش لان باقي الافتراضات اختفت، لكن لانك اخترت اي واحد منهم له حق يوقف قرار البناء دلوقتي.

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

قيمتها الحقيقية في حاجة تانية:

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

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

هتخرج من المرحلة دي ماسك ايه فعلا؟

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

1. الادلة (Evidence): اللي عرفناه فعلا من السوق والمستخدمين، مفصول عن اللي لسه بنفترضه. مش مجرد ملخص مقابلات: المهم ايه اللي اتأكد؟ ايه اللي اتغير عن تصورنا الاول؟ وايه اللي لسه مفتوح؟

2. الافتراضات (Assumptions): الافتراضات مكتوبة صريحة، ووزنها معروف حسب تأثيرها على قرار البناء. مش كل افتراض يستحق نفس الاهتمام.

3. نطاق المنتج الاول (MVP Scope): مش قائمة Features. النطاق اللي هيتبني، واللي اتأجل، وليه اتأجل. الجزء التاني مهم بنفس قدر الجزء الاول، عشان الحاجة المؤجلة متتحولش بعدين لقرار منسي.

4. متطلبات المنتج (Product Requirements): الادوار، الرحلات الاساسية، البيانات، الصلاحيات، ال Integrations، وحالات الخطأ المؤثرة. يعني المعلومات اللي تخلي فريق التصميم والتطوير يشتغل من غير ما يخمن Business Decisions مكان صاحب المشروع.

5. الاتجاه التقني (Technical Direction): مش اختيار Stack بدري. المقصود القيود والبدائل والقرارات التقنية اللي ممكن تغير التكلفة او طريقة التنفيذ بشكل جوهري. وده بيبان خصوصا لو فيه AI في وظيفة اساسية، Integration محوري، بيانات حساسة، او اعتماد على خدمة خارجية.

6. المخاطر (Risks): المخاطر مكتوبة بطريقة تقدر تتابعها. مش "ممكن السوق ميستجبش"، لكن: ايه الخطر؟ امتى هيبان؟ وايه القرار لو ظهر؟

7. قرار التنفيذ (Execution Decision): المعلومة لوحدها مش نهاية. لازم في الاخر يتكتب: قررنا نعمل ايه.. وليه؟ ودي من الحاجات اللي بتضيع بسهولة لما المشروع يجمع معلومات كتير من غير لحظة قرار واضحة.

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

القرار قبل وبعد

قبل المرحلة دي، الفكرة ممكن تكون: "عايز ابني منصة اشتراكات لشركات الخدمات فيها ادارة عملاء وطلبات وتقارير ومساعد AI."

بعدها، القرار ممكن ياخد شكل ادق:

• الشريحة اللي عندنا عليها Evidence فعلي هي الشركات الصغيرة اللي بتدير جزء كبير من الطلبات على WhatsApp وExcel
• المشكلة الاوضح مش "ادارة العملاء" بشكل عام، لكن ضياع حالة الطلب بين اكتر من شخص
• ال MVP اصغر من التصور الاول، وفيه Features اتأجلت باسباب مكتوبة
• ال Workflow اتغير بعد ما فهمنا مين فعلا بيدخل البيانات ومين بيتابع الطلب
• ودلوقتي اي فريق تطوير هيقرا نفس تعريف المنتج بدل ما يملا الفراغات من عنده

دي هي النقلة: مش ان التقرير بقى اكتر. ان القرار بقى اقل اعتمادا على التفسير.

الناحية التانية من الطاولة

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

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

طب كل مشروع محتاج دراسة تأسيسية كاملة؟

لا. لو المشروع Tool داخلي لفريقك، والمستخدم معروف، والتكلفة محدودة، والقرار قابل للتراجع بسهولة.. اعمل Discovery مناسب للحجم، حدد اهم افتراض، وابدأ تجربة صغيرة.

الصورة بتختلف لما يكون عندك اكتر من عامل زي: منتج هيتباع لسوق مش لفريق داخلي، تكلفة تطوير مش سهل تتحملها مرتين، اكتر من نوع مستخدم بمصالح مختلفة، Integrations اساسية، AI في قلب الوظيفة، نموذج تجاري لسه ما اتجربش، او صاحب مشروع غير تقني داخل على تعاقد تطوير كبير.

كل ما اتجمع منهم اكتر، كل ما التخمين بقى اغلى.

طب المرحلة دي بتاخد قد ايه؟

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

قد ايه الحاجات اللي هتحدد شكل المنتج لسه مش معروفة؟

الاجابة هي اللي تحدد حجم المرحلة المناسب.

ولو عايز تفهم الدراسة نفسها بتمشي ازاي، ودورك فيها ايه، وازاي تقيم نتيجتها قبل التعاقد، اقرأ دليل الدراسة التأسيسية لمشروع SaaS.

بعد ما تحدد الافتراض اللي ممكن يغير المشروع لو طلع غلط، سؤال ال MVP بيبقى مختلف: مش "اي Features نقدر نحذفها عشان النسخة الاولى تبقى ارخص؟" لكن:

اي جزء من المنتج محتاج يبقى موجود فعلا عشان نعرف اذا كان الافتراض ده صح ولا غلط؟

الفرق كبير، لانك ممكن تبني Product صغير جدا.. وبرضه ميجاوبش على السؤال اللي المشروع واقف عليه.

ال MVP ممكن يكون صغير.. ومش Minimal

تخيل مشروع بيدير طلبات شركات الخدمات. الافتراض الاهم: "فرق التشغيل هتسيب WhatsApp وExcel وتستخدم Workflow مركزي للطلبات."

لو اول نسخة فيها Login وDashboard وCustomers وReports وNotifications، لكن ال Workflow نفسه مش صالح للاستخدام اليومي، فانت بنيت Features اقل من المنتج النهائي، لكنك لسه ما اختبرتش الافتراض الحقيقي.

وفي الناحية التانية، ممكن نسخة فيها Features اقل بكتير، لكنها تسمح لفريق حقيقي يستقبل الطلب، يعالجه، يتابعه، ويقفله من مكان واحد. دي اقرب ل MVP يخدم القرار.

Minimal هنا مش معناها شاشات اقل. معناها: اقل منتج قادر ينتج Evidence مفيد.

من اكتر الحاجات اللي بنشوفها.. MVP معمول من leftovers

الطريقة الشائعة: نكتب كل Features اللي نفسنا فيها، السعر او المدة يكبروا، فنقول: "طيب نشيل ايه لل MVP؟" فتتحول النسخة الاولى للحاجات اللي اتبقت بعد التخفيض.

وده ممكن يشيل Feature ضرورية لاختبار ال Journey، وفي نفس الوقت يسيب Feature شكلها جذاب لكنها ملهاش علاقة بالسؤال الاساسي.

ال MVP مش Budget Version من ال Product Vision.. هو Experiment له شكل Product.

فيه حاجات لازم تشتغل فعلا.. حتى في MVP

كلمة MVP مش مبرر لتجربة مكسورة. لو القيمة الرئيسية للمنتج ان المستخدم يعمل عملية معينة من اولها لاخرها، فالعملية دي لازم تكون قابلة للاستخدام فعلا.

مش لازم تكون كاملة من ناحية الشكل، مش لازم يكون فيها كل Automation، مش لازم تغطي كل Edge Case. لكن مينفعش الاختبار نفسه يكون ضعيف، وبعدها نستنتج ان المستخدم مش مهتم.

لو تجربة ال MVP ضعيفة في الحاجة اللي جاي تختبرها، ال Evidence اللي هتطلع منها هيكون ضعيف برضه.

السؤال اللي بيفصل Core عن Nice-to-have

مع كل Feature في اول Scope، اسأل:

لو شلنا الحاجة دي.. هل لسه نقدر نختبر الافتراض اللي بنينا ال MVP عشانه؟

لو اه، غالبا فيه مساحة للتأجيل. لو لا، فهي جزء من الاختبار حتى لو شكلها صغير. ممكن Dashboard تتأجل، لكن Audit Trail بسيط يكون ضروري. ممكن AI Assistant يتأجل، لكن طريقة واضحة لتصحيح البيانات تبقى اساسية. ممكن Mobile App كامل يتأجل، لكن استخدام ال Workflow من الموبايل يبقى شرط لان المستخدم الحقيقي مش قاعد قدام Desktop طول الوقت.

اسم ال Feature مش هو اللي يحدد اهميتها. علاقتها بالافتراض هي اللي تحدد.

ومش كل خطر يتحل بالكود

لو السؤال الاكبر "هل الشركات مستعدة تدفع السعر ده؟" مش شرط تبني Billing System عشان تعرف. ولو السؤال "هل الفريق مستعد يغير ال Workflow الحالي؟" ممكن تجربة يدوية او Prototype تكشف ده قبل Product كامل. ولو السؤال "هل ال AI قادر يطلع النتيجة بالمستوى المطلوب؟" ممكن Technical Prototype منفصل يكون الخطوة الاولى.

يعني احيانا القرار الصح: لسه مفيش MVP برمجي. فيه اختبار اصغر لازم يحصل قبله.

اللي يتأجل لازم يتأجل بقرار.. مش بالنسيان

Feature خرجت من اول Scope؟ سجل ليه: "دعم اكتر من لغة مؤجل لان مجموعة الاختبار الاولى تعمل بالعربي فقط"، "التقارير المتقدمة مؤجلة لحد ما نعرف فعلا اي مؤشرات يستخدمها المديرون في قراراتهم"، "طبقة توصيات AI مؤجلة لحد ما نتأكد ان ال Workflow الاساسي نفسه صالح للاستخدام بدونها".

القرار المكتوب يخليك ترجع بعدين وتسأل: هل سبب التأجيل لسه موجود؟ مش تفتح Backlog مليان Features ومحدش فاكر ليه كل واحدة اتاخرت.

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

قبل ما تثبت ال MVP.. لازم يكون واضح

• اي افتراض رئيسي النسخة معمولة عشان تختبره
• اي Journey لازم تشتغل عشان الاختبار يبقى صالح
• اي Features موجودة لانها تخدم الاختبار
• اي Features اتأجلت وليه
• وايه Evidence اللي بعد التجربة هيحدد القرار التالي

ال MVP الجيد مش بيحاول يثبت ان رؤية صاحب المشروع كلها صح. هو بيحاول يجاوب السؤال الاهم اللي لسه ممكن يخلي الرؤية دي تتغير.

فيه لحظة في كل مشروع لازم الكلام فيها يتغير: قبلها، النقاش عن المشكلة، المستخدم، الافتراضات، وال MVP. بعدها، فريق التصميم والتطوير محتاج ياخد القرارات دي ويحولها لنظام قابل للبناء.

المشكلة ان الانتقال ده ساعات بيحصل بدري:

فريق التطوير المفروض يقرر ازاي نبني الحاجة.. مش يقرر بالنيابة عن صاحب المشروع الحاجة نفسها المفروض تعمل ايه.

الاختبار قبل التسليم للتطوير

السؤال مش "هل كل التفاصيل مكتوبة؟" لو استنينا كل تفصيلة، مش هنبدأ. السؤال:

هل القرارات اللي لو اتغيرت هتغير ال Scope والتكلفة وطريقة البناء نفسها اتحسمت؟

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

1. الناس والرحلة الرئيسية: مين المستخدمين الحقيقيين؟ مين يعمل، يراجع، يوافق، ويشوف البيانات؟ وايه ال Journey المحورية من البداية للنهاية؟ لو الرحلة نفسها بتتغير كل مرة بنتكلم عنها، فالمنتج لسه بيتشكل.

2. البيانات وقواعد التشغيل: ايه المعلومات الرئيسية؟ مين مصدرها؟ مين يقدر يعدلها؟ وايه الحالات اللي تغير سير العملية لو البيانات ناقصة او الطلب اترفض او خطوة اساسية فشلت؟ مش مطلوب Data Model نهائي، المطلوب ان Business Meaning وقواعد التشغيل يبقوا واضحين قبل ما الفريق التقني يحولهم لتصميم.

3. الاعتمادات الخارجية: Payment Gateway، WhatsApp، CRM، ERP، External API، او AI Provider ممكن يكونوا سطر صغير في ال brief وجزء كبير من المشروع. المهم تعرف: اي اعتماد منهم ضروري لل MVP؟ هل الوصول له متاح؟ وهل فيه شرط او قيد ممكن يغير طريقة التنفيذ؟ ولو AI في وظيفة محورية، لازم يكون معروف ال Input المتوقع، ال Output المطلوب، مستوى الخطأ المقبول، والمراجعة او البديل وقت الفشل.

4. القرارات المفتوحة: مش كل سؤال لازم يتقفل، لكن السؤال المفتوح لازم يكون معروف انه مفتوح. الخطر مش في وجود مجهول.. الخطر لما يكون فيه Product Decision مستخبي جوه ال Scope والفريق التقني يتعامل معاه كأنه قرار محسوم.

ازاي تعرف انك عبرت البوابة؟

المشروع بقى اقرب للتطوير لما فريق التنفيذ يسأل: "هننفذ ال Workflow ده بالطريقة A ولا B؟" مش "هو ال Workflow ده اصلا المفروض يحصل ازاي؟" ويناقش البدائل التقنية لل Integration مش اذا كان ال Integration ضروري للمنتج اصلا.

النوع الاول Technical Decisions، والنوع التاني Product Decisions لسه متقفلتش. وده هو الحد الفاصل.

ومع بناء خارطة الطريق التقنية (Technical Roadmap) الواضحة، يبدأ تسعير التطوير يعكس حقائق البناء بدقة. وللمزيد حول تجنب فخاخ عروض الأسعار المبهمة، طالع مقالنا: ما الذي يجب أن تعرفه قبل طلب عرض سعر لتطوير SaaS؟.

علامة الجاهزية العملية

مش Technical Architecture نهائية، ومش كل شاشة مرسومة. المشروع جاهز للنقاش التقني لما:

• المستخدمين والرحلة المحورية معروفين
• ال MVP Scope ثابت بالقدر الكافي
• البيانات وقواعد التشغيل الرئيسية واضحة
• الاعتمادات الخارجية المؤثرة معروفة
• والقرارات المفتوحة مكتوبة بدل ما تكون مستخبية

عند النقطة دي السؤال بيتغير من "احنا المفروض نبني ايه؟" الى: "ايه افضل طريقة نبني بيها الحاجة اللي قررناها؟" وده هو الانتقال الحقيقي من تخطيط المنتج الى التنفيذ.

لو وصلت للنقطة دي، المفروض السؤال يكون اتغير: في البداية كان "هنبني الفكرة دي ازاي؟" دلوقتي بقى: ايه القرار اللي ال Evidence اللي عندنا يبرره فعلا؟

مرحلة ما قبل التطوير مش معمولة عشان توصل كل مشروع للبرمجة. هي معمولة عشان توصل لقرار تقدر تقول ليه خدته. والقرار ممكن ياخد اكتر من شكل:

Build

المشكلة واضحة بالقدر الكافي، الشريحة اللي هنبدأ بيها معروفة، اهم الافتراضات اللي كان لازم تتقفل قبل التطوير اتفهمت او اتختبرت، وال MVP له وظيفة محددة. هنا الانتقال للتطوير منطقي.

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

اختبر حاجة اصغر قبل ما تبني

ممكن الفكرة منطقية، لكن فيه افتراض واحد لسه اكبر من انك تدخل Development وهو مفتوح: هل العميل هيغير ال Workflow؟ هل الطرف اللي هيشتري هو نفس الطرف اللي هيستخدم؟ هل وظيفة محورية في المنتج معتمدة على مزود خارجي لسه شروطه مش متأكدين منها؟ هل النموذج التجاري نفسه قابل للتجربة؟

لو السؤال ده ممكن يتجاوب بتجربة اصغر من Product كامل (Prototype، تجربة يدوية، Landing Page، Technical Test، او تشغيل محدود للخدمة)، فالاختبار الاصغر اسبق عشان مندفعش تكلفة بناء كاملة للاجابة عن سؤال كان ممكن نختبره بطريقة ابسط.

صغر ال Scope

ساعات المشكلة مش في الفكرة، المشكلة ان اول نسخة بتحاول تجاوب اسئلة كتير مرة واحدة: اكتر من شريحة، اكتر من Workflow، اكتر من نوع مستخدم، Integrations كتير، AI، تقارير، Automation. كل واحدة ممكن تكون منطقية لوحدها، لكن جمعهم في MVP واحد يخلي النسخة الاولى اكبر من ال Evidence اللي عندك.

هنا القرار: نبني الجزء اللي يختبر اهم حاجة الاول، والباقي يفضل قرار مؤجل ومكتوب. وده مختلف عن حذف Features عشوائيا عشان السعر يدخل الميزانية.

غير جزء من الفكرة

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

مش لازم ترمي المشروع كله، لكن مينفعش كمان تكمل بنفس الخطة:

لو ال Evidence غير واحد من القرارات اللي المنتج مبني عليها، يبقى المنتج نفسه لازم يتغير قبل ما الكود يثبت القرار القديم.

مش دلوقتي

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

"مش دلوقتي" مش معناها ان الفكرة ماتت، معناها: القرار الحالي مش مبرر التكلفة الحالية. المهم ان الحماس لوحده ميتحولش لالتزام.

الفرق الحقيقي في نهاية المرحلة

الفرق مش انك بقيت تعرف المستقبل ولا ان المخاطر اختفت. الفرق انك بقيت قادر تفصل بين 3 حاجات:

• اللي عرفناه: Evidence موجود فعلا.
• اللي قررناه: قرارات اتاخدت بناء على اللي عرفناه.
• اللي لسه مش عارفينه: افتراضات معروفة ومتسجلة بدل ما تكون مستخبية جوه ال Scope.

وده هو المطلوب، لانك بعدها ممكن تقرر Build، او اختبار اصغر، او Scope اقل، او تغيير جزء من الفكرة، او مش دلوقتي.. وكل واحدة منهم ممكن تكون القرار الصح.

الخطوة التالية

لو انت بالفعل بتجمع عروض تطوير، لكن كل نقاش جديد بيفتح اسئلة مختلفة عن المستخدم، ال Scope، ال MVP او المتطلبات.. فممكن المشكلة مش انك محتاج عرض سعر جديد. ممكن تعريف المنتج نفسه محتاج يتثبت الاول.

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