ما ينبغي تقريره قبل بناء منتج أوّلي

المنتج الأوّلي ليس نسخة أصغر من كل فكرة في خارطة طريقك. إنه أصغر منتج مفيد يتيح لمجموعة محدَّدة من الناس إتمام سير عمل مهم ويمنح الفريق أدلة للقرار التالي.

وتلك الكلمة — الأدلة — تستحق وقفة.

درس تحليل CB Insights لأسباب فشل الشركات الناشئة (يفتح في تبويب جديد)، المنشور في مارس 2026، 431 شركة مدعومة باستثمار المخاطر أغلقت أبوابها علنًا منذ 2023. ووجد نفاد رأس المال في 70% من الحالات وضعف ملاءمة المنتج للسوق في 43%.

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

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

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

ما ليس منتجًا أوّليًا

ثلاثة سوء فهم تتسبب في معظم الضرر، ويجدر تسميتها قبل بدء التخطيط:

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

السؤال المفيد ليس «ما أقل ما يمكننا بناؤه؟» بل «ما أقل ما يمكننا بناؤه ويظل يعلّمنا شيئًا نتصرف بناءً عليه؟»

هل تحتاج أصلًا إلى بناء مخصّص؟

قبل تحديد نطاق بناء مخصّص، يجدر السؤال عمّا إذا كنت تحتاج إليه بعد.

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

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

والتسلسل المفيد هو التحقق من الطلب بأرخص ما ينجح، ثم البناء المخصّص بعد أن تعرف أي الأجزاء يحتاج إليه فعلًا.

كثير من المنتجات الناجحة تبدأ عملية يدوية أو مجموعة أدوات مركّبة. ولا تصير برمجيات مخصّصة إلا حيث يبدأ ذلك التركيب في الإيلام.

البناء المخصّص مبكرًا جدًا ينفق ميزانيتك على إثبات ما كان اختبار أرخص بكثير ليخبرك به. والبناء متأخرًا جدًا يتركك تصارع أدوات لم تعد تناسبك.

أجب عن ذلك بصدق قبل أن تبدأ تحديد النطاق، لا بعده.

ابدأ من سير عمل المستخدم

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

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

وتُصنّف هيئة الخدمات الرقمية الحكومية البريطانية ذلك كمرحلة استكشاف. ويأتي دليل الخدمات لديها (يفتح في تبويب جديد) صريحًا بشأن الترتيب: «قبل أن تلتزم ببناء خدمة، عليك أن تفهم المشكلة التي يجب حلها».

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

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

حدّد ما ينتمي إلى النطاق

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

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

1. لا يستطيع المستخدم الأول إتمام سير العمل الأساسي بدونها
2. تقلّل خطر تسليم سبق أن حدّدته
3. يمنح الفريق التحكّم الذي يحتاجه منذ اليوم الأول
4. تركها سيفرض إعادة كتابة بدل إضافة

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

قرّر كيف ستعرف أنه نجح

قبل بدء البناء، اتفقوا على النتيجة التي تبرّر الاستمرار أو تغيير الاتجاه أو التوقف. من دون ذلك تبدو كل نتيجة مشجّعة.

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

• يتمّ الناس سير العمل الأساسي دون أن يُقادوا خطوة بخطوة
• يعودون دون تذكير
• انخفاض واضح في العمل اليدوي الذي حلّ المنتج محله
• يطلب أحدهم الميزة التالية بدل إصلاح أساسي

اكتب ما تتوقع رؤيته ومتى. ومقارنة ذلك بما يحدث هي كل الغاية من الإطلاق المبكر.

اكتب ما يعنيه «منجَز»

حدّد ما يعنيه «يعمل» قبل بدء التطوير. استخدم معايير قبول قابلة للملاحظة، مثل: يستطيع المستخدم تقديم طلب، ويستطيع الشخص المناسب مراجعته، ويسجّل النظام النتيجة بشكل صحيح.

وتصف إرشادات GDS حول كتابة قصص المستخدم (يفتح في تبويب جديد) معايير القبول بأنها «قائمة من النتائج تستخدمها كقائمة تحقق للتأكد من أن خدمتك أدّت عملها»، وتُصاغ كل منها بصيغة يكون منجزًا عندما… كعبارة.

وقيمتها في أن يستطيع التحقق منها شخص لم يبنِها.

وعلى مستوى الإصدار، يُعرّف The Scrum Guide (يفتح في تبويب جديد) تعريفَ الإنجاز بأنه «وصف رسمي لحالة الزيادة حين تستوفي مقاييس الجودة المطلوبة للمنتج».

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

ضع قواعد البيانات قبل المخطط

قرّر ما المعلومات التي يجب أن يخزّنها المنتج ومن يجوز له الوصول إليها. فالخصوصية والصلاحيات والاحتفاظ والنسخ الاحتياطي واحتياجات التدقيق أسهل تخطيطًا قبل وجود أول جداول قاعدة البيانات والتكاملات.

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

أما إرشادات المفوضية الأوروبية بشأن حماية البيانات بالتصميم وبالإعداد الافتراضي (يفتح في تبويب جديد) فتصف تدابير تبدأ في أبكر مراحل تصميم المعالجة، مع إعدادات افتراضية موضوعة بحيث «تُعالَج البيانات الشخصية بأعلى مستوى من حماية الخصوصية».

واعتمد المجلس الأوروبي لحماية البيانات إرشادات بشأن المادة 25 (يفتح في تبويب جديد) في صيغتها النهائية في أكتوبر 2020، إن احتجت إلى الموقف التفصيلي للجهة التنظيمية.

وعمليًا هذه قائمة قصيرة تُكتب: ماذا تجمع، ولماذا، ومن يستطيع رؤيته، وكم تحتفظ به، وكيف يحصل أحدهم على حذفه.

الإجابة عن ذلك قبل تصميم قاعدة البيانات أرخص بكثير من إضافته لاحقًا.

اختر التقنية والذكاء الاصطناعي بعناية

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

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

وثمة الآن سبب مقيس للحذر. فتقرير 2025 DORA report (يفتح في تبويب جديد)، المستند إلى إجابات نحو 5,000 من المهنيين التقنيين، يفيد بأن «اعتماد الذكاء الاصطناعي لا يزال ذا علاقة سلبية باستقرار تسليم البرمجيات».

فالإنتاج الأسرع بلا اختبار ومراجعة متينين لا يتراكم تسليمًا أسرع، بل يتراكم إعادةَ عمل.

خطّط للمراجعات والوصول والتسليم

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

ويعرض مكتب المساءلة الحكومية الأمريكي حجة المخاطر في Agile Assessment Guide (يفتح في تبويب جديد): فالتسليم التدريجي مع التقييم المستمر «يمكن أن يقلّل مخاطر تمويل برنامج يفشل أو ينتج تقنية عفا عليها الزمن».

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

وتحدّد قدرة DORA المسماة التحكم في الإصدارات (يفتح في تبويب جديد) بدقة ما ينتمي إليها: شفرة التطبيق وتبعياته، وأدوات إنشاء البيئات، وملفات تركيب الحاويات، وإعدادات السحابة، ومصنوعات الذكاء الاصطناعي مثل المُوجّهات.

وأساسها المعلن أن «البحث يُظهر باستمرار أن الاستخدام الشامل للتحكم في الإصدارات يتنبأ بالتسليم المستمر».

وتضيف إرشادات GDS حول التحكم في الإصدارات (يفتح في تبويب جديد) النصف الآخر من القاعدة، وهو المراجعة: «كل تغيير في الشفرة يراجعه شخص لم يكتبه».

ومعًا تجعل هذه العادات التسليم ممكنًا. فإذا كانت إعادة إنشاء النظام تعتمد على حاسوب أحدهم المحمول، فليس لديك مُخرَج قابل للتسليم — لديك تبعية.

خطّط الجدول الزمني والميزانية

غالبًا ما يمكن تخطيط منتج أوّلي مركّز حول نافذة تسليم من 6–8 أسابيع حين يناسب النطاق ذلك الشكل. وهذا مرجع تخطيطي لا وعد شامل؛ فالتكاملات والموافقات والأنظمة القديمة المجهولة قد تغيّر الجدول.

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

وخلصت دراسة شملت 5,392 مشروعًا لتقنية المعلومات نُشرت في Journal of Management Information Systems (يفتح في تبويب جديد) إلى أن تجاوزات الكلفة تتبع قانون قوى لا توزيعًا طبيعيًا.

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

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

وذلك مقابل إنفاق سنوي يتجاوز 100 مليار دولار. فالحجم والميزانية لا يحلان هذا؛ بل ينضباط النطاق وحلقات التغذية الراجعة القصيرة.

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

مثال مُطبَّق

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

غير أن سير العمل الأساسي ضيّق: يجد عميل موعدًا متاحًا ويحجزه، ويرى مقدّم الخدمة الحجز. وكل ما عدا ذلك يدعم هذا أو يمكنه الانتظار.

وقد يبدو إصدار أول منضبط هكذا:

• ضمن النطاق: توافر مقدّم الخدمة، وحجز العميل، وتأكيد، وعرض بسيط لمقدّم الخدمة بالحجوزات القادمة.
• مؤجَّل: المدفوعات داخل التطبيق (تحصيل عربون يدويًا في البداية)، والتذكيرات الآلية، والتقييمات، والبحث عبر عدة مقدّمي خدمة، ولوحة الإدارة.
• مقرَّر مسبقًا: ما بيانات العميل التي تُخزَّن وكم مدةً، ولمن يعود المستودع، وما الذي يعنيه «نجح الحجز» كمعيار قبول.

والقائمة المؤجَّلة ليست متروكة — إنها خارطة الطريق. لكن إطلاق النواة أولًا يجيب عن السؤال الوحيد المهم مبكرًا: هل سيبقي مقدّمو الخدمة تقويماتهم محدَّثة، وهل سيحجز العملاء؟

فإن فعلوا، فبقية العمل تستحق البناء. وإن لم يفعلوا، فما كان أي تكامل مدفوعات لينقذها.

البداية

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

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