📋 العميل لا يعرف ماذا يريد

"أبي تطبيق مثل أمازون بس أبسط". "أبي موقع حلو واحترافي". "أبي شي يشدّ الانتباه". كل مستقل سمع هذه العبارات. وكل عميل يعتقد أنها واضحة كفاية.

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

هذا ليس عيباً في العميل — بل هو طبيعي تماماً:

ليس متخصصاً: لا يعرف مصطلحات مجالك. لا يعرف ما هو ممكن وما هو مستحيل. لا يعرف كيف يترجم رؤيته لمتطلبات تقنية.

يرى النتيجة لا العملية: يعرف أنه يريد "تطبيقاً ناجحاً" لكن لا يعرف ما المطلوب تقنياً لتحقيق ذلك.

يتأثر بما يراه: شاهد تطبيقاً أعجبه فيريد "مثله". لكن "مثله" ليست وصفاً — لأن التطبيق الذي أعجبه فيه مئات الميزات والقرارات.

لم يُجبَر على التفكير بعمق: لم يسأله أحد الأسئلة الصعبة: من جمهورك بالضبط؟ ما المشكلة التي يحلها التطبيق؟ ما أهم 3 ميزات؟ فبقيت رؤيته ضبابية.

وصف المشروع هو وثيقة مختصرة — صفحة أو صفحتان — تُجيب على الأسئلة الأساسية:

1. ما المشروع؟ وصف بجملتين: ما هو وماذا يفعل.

2. لمن؟ الجمهور المستهدف بأكبر تحديد ممكن: "شباب سعوديون 20-30 سنة مهتمون بالرياضة" وليس "الجميع".

3. ما المشكلة التي يحلها؟ أو ما الحاجة التي يلبيها.

4. ما الميزات الأساسية؟ ليس كل ما تتخيله — فقط الأساسي الذي بدونه المشروع لا يعمل. 5 ميزات كحد أقصى في النسخة الأولى.

5. ما الذي لا يشمله المشروع؟ هذا أهم مما تتخيل. التوضيح بأن المشروع "لا يشمل تطبيق جوال" أو "لا يشمل نظام دفع" يمنع سوء الفهم لاحقاً.

6. الميزانية والوقت؟ حتى لو تقريبياً. هذا يساعد المستقل على اقتراح الحل المناسب ضمن الإمكانيات.

كتابة وصف المشروع ليست مسؤولية العميل وحده ولا المستقل وحده — بل هي عملية مشتركة:

العميل يقدم: الرؤية، الجمهور، الميزانية، أمثلة على ما يعجبه.

المستقل يقدم: الأسئلة الصحيحة، ترجمة الرؤية لمتطلبات واضحة، تحديد ما هو ممكن ضمن الميزانية.

من أشهر الأمثلة على ما يحدث عندما لا تُحدَّد المتطلبات بوضوح: دار أوبرا سيدني. عام 1957، فاز المعماري الدنماركي يورن أوتزون بمسابقة التصميم. الميزانية الأصلية: 7 ملايين دولار والمدة 4 سنوات. لكن المتطلبات كانت غامضة ومتغيرة باستمرار — الحكومة غيّرت المواصفات عدة مرات، ولم يكن هناك اتفاق واضح على التفاصيل الهندسية.

النتيجة حسب Sydney Morning Herald وموقع دار الأوبرا الرسمي: المشروع استغرق 16 سنة وكلّف 102 مليون دولار — أي 1,457% فوق الميزانية. أوتزون نفسه استقال من المشروع عام 1966 بسبب الخلافات ولم يرَ المبنى المكتمل. المشروع الذي كان يحتاج حواراً واضحاً عن المتطلبات من البداية أصبح أشهر مثال على تجاوز التكاليف في تاريخ البناء.

من أشهر قصص "العميل الذي لا يعرف بالضبط" هي قصة تطوير الآيفون الأول داخل Apple.

حسب كتاب "Creative Selection" لـ كين كوتشيندا (2018) — أحد المهندسين الأساسيين في فريق الآيفون — طلب ستيف جوبز "هاتفاً ذكياً" لكنه لم يكن يعرف الشكل النهائي. في البداية كان الفريق يعمل على نموذج بعجلة تمرير (مثل iPod)، ثم تحوّل لشاشة لمس، ثم تغيّرت لوحة المفاتيح عدة مرات.

المفتاح كان أن جوبز — رغم أنه "لم يكن يعرف بالضبط ما يريد" — كان يعرف ما لا يريد: "لا أريد هاتفاً معقداً. لا أريد قلم stylus. لا أريد لوحة مفاتيح فيزيائية". هذه "اللاءات" وجّهت الفريق التقني أكثر من أي وصف إيجابي.

الدرس: أحياناً العميل لا يستطيع وصف ما يريد — لكنه يستطيع وصف ما لا يريد. وهذه معلومة لا تقل قيمة. اسأل عميلك: "ما أسوأ شيء يمكن أن يحصل في هذا المشروع؟" — إجابته ستكشف أولوياته الحقيقية.

إطار Jobs to be Done (JTBD) — الذي طوّره البروفيسور كلايتون كريستنسن من Harvard Business School في كتابه "Competing Against Luck" (2016) — يقوم على فكرة بسيطة وعميقة: العميل لا يشتري منتجاً — بل يشتري حلاً لمشكلة.

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

كيف تطبّق هذا مع عميلك؟

بدلاً من أن تسأل: "ماذا تريد في الموقع؟" — اسأل: "ما المشكلة التي يحلها الموقع لزبائنك؟".

- "أبي موقع لمطعمي" → المهمة الحقيقية: يريد زبائن جدد يعرفون القائمة والعنوان. - "أبي تطبيق" → المهمة الحقيقية: يريد أن يتواصل مع عملائه بطريقة أسهل من الاتصال الهاتفي. - "أبي متجر إلكتروني" → المهمة الحقيقية: يريد بيع منتجاته لأشخاص خارج مدينته.

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

إذا كنت عميلاً أو مستقلاً ولا تعرف من أين تبدأ، أجب على هذه الأسئلة:

1. لو شرحت المشروع لصديقك في 30 ثانية، ماذا ستقول؟

2. ما هي الـ 3 أشياء التي يجب أن يفعلها المشروع بالحد الأدنى؟

3. ما هو أسوأ سيناريو تريد تجنبه؟ (مثال: "لا أريد أن يكون بطيئاً" — هذا يحدد أولوية الأداء). تذكّر درس جوبز: اللاءات ترسم الخريطة.

4. ما المشكلة التي يحلها المشروع لزبائنك؟ (إطار Jobs to be Done)

5. هل هناك مشروع موجود يشبه ما تريد؟ وماذا ستغيّر فيه؟

6. ما هي الميزانية القصوى؟ وما هو آخر موعد للتسليم؟

هذه الأسئلة الستة تكفي لإنتاج وصف مشروع واضح. ليس مثالياً — لكن أوضح بمراحل من "أبي شي حلو".

يقول المثل العربي: "اللي ما بيعرف الصقر بيشويه" — واللي ما بيعرف يوصف مشروعه، بيضيّع وقته ووقت اللي بيشتغل معه.

وفي سوقنا العربي، مشكلة وصف المشروع لها بُعد ثقافي إضافي. كثير من العملاء العرب يعتبرون أن الكلام الشفهي كافٍ — "يا أخي أنا قلتلك بالتلفون شو بدي، ليش بدك توثيق؟" — وهذا وصفة مضمونة للخلاف. شركة حراج السعودية مثلاً — من أكبر مواقع الإعلانات المبوبة عربياً — نجحت جزئياً لأنها أجبرت البائعين على كتابة وصف واضح ومحدد للمنتج بدلاً من الاعتماد على "اتصل وسأشرح لك".

أو كما يقولون بالمصري: "يا عم اكتب اللي عايزه على ورقة — الكلام في الهوا بيروح في الهوا!"

حتى ستيف جوبز لم يكن يعرف الشكل النهائي للآيفون — لكنه كان يعرف ما لا يريد، والفريق ترجم ذلك لمنتج غيّر العالم. العميل لا يعرف ماذا يريد — وهذا طبيعي. مهمة المستقل المحترف أن يساعده على اكتشاف ما يريد من خلال الأسئلة الصحيحة وأطر التفكير مثل Jobs to be Done. ووصف المشروع ليس بيروقراطية — إنه خارطة طريق تحمي الطرفين من الضياع. ساعة واحدة في الأسئلة اليوم توفر أسابيع من سوء الفهم غداً.