🤝 العميل الشريك vs العميل الآمر

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

العميل الآمر يأتي بوصف مشروع جاهز في ذهنه — حتى التفاصيل التقنية: "أبي الزر هنا، واللون كذا، والقاعدة بتكون MySQL". يرفض النقاش ويعتبره مضيعة وقت.

من أوضح الأمثلة: رون جونسون — نائب رئيس Apple السابق لمتاجر التجزئة — عندما أصبح مديراً تنفيذياً لسلسلة JCPenney الأمريكية عام 2011. جونسون قرر إلغاء جميع العروض والتخفيضات واستبدالها بـ "أسعار يومية منخفضة" — ضد نصيحة فريقه وأبحاث السوق التي أظهرت أن زبائن JCPenney يعشقون التخفيضات. رفض الاستماع: "أنا أعرف التجزئة أكثر منكم — نجحت في Apple وسأنجح هنا".

النتيجة حسب Forbes وBloomberg؟ انخفضت إيرادات الشركة من 17.3 مليار إلى 13 مليار دولار في سنة واحدة — خسارة 25%. أُقيل جونسون في أبريل 2013 بعد أقل من سنتين.

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

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

من أفضل الأمثلة: إميلي وايس مؤسسة Glossier — علامة التجميل التي وصل تقييمها إلى 1.2 مليار دولار حسب Vanity Fair. وايس بدأت بمدونة "Into the Gloss" عام 2010 تسأل فيها القرّاء عن روتين العناية بالبشرة. عندما قررت إطلاق Glossier عام 2014، لم تملِ على فريقها ما يصنعون. بل نشرت سؤالاً: "ما هو غسول الوجه الذي تحلمين به؟" — وحصلت على أكثر من 400 تعليق تفصيلي على المدونة ومئات الردود على إنستغرام حسب Business of Fashion. هذه الردود وجّهت فريق التطوير لصنع منتج Milky Jelly Cleanser الذي أصبح من أكثر منتجاتهم مبيعاً.

السبب: عندما يتعاون صاحب الرؤية مع المتخصصين ويستمع لجمهوره، يُنتجون حلاً يجمع بين فهم السوق والكفاءة التقنية — بدلاً من منتج مبني على تخمينات شخص واحد.

قبل أن نلوم العميل الآمر، لنفهم أسبابه:

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

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

ثقافة "المقاول": اعتاد التعامل بمنطق "أطلب وأستلم" بدلاً من "نبني سوا".

هذه ليست عيوباً شخصية — إنها ردود فعل طبيعية لتجارب حقيقية. المبرمج المحترف يستطيع تحويل العميل الآمر إلى شريك بالتدريج.

في عام 2007 كانت Nokia تسيطر على 49.4% من سوق الهواتف العالمي حسب Gartner. ثقافتها كانت من أعلى لأسفل: الإدارة العليا تحدد المنتجات والمهندسون ينفّذون. المطوّرون الذين اقترحوا شاشات لمس والتركيز على التطبيقات قُوبلوا بالرفض — الإدارة "تعرف السوق أكثر".

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

حسب كتاب "The One Device" للكاتب Brian Merchant (2017)، الآيفون مرّ بعشرات التكرارات والنقاشات الداخلية قبل أن يصل لشكله النهائي. لم يكن أمراً من أعلى — كان حواراً مستمراً.

النتيجة؟ بحلول 2013 انهارت حصة Nokia وبيعت لـ Microsoft. والآيفون غيّر صناعة الهواتف للأبد.

الدرس: عندما يكون القرار فوقياً — حتى في شركة عملاقة — تموت الابتكار. وعندما تكون الشراكة حقيقية بين الرؤية والتنفيذ، تُولد منتجات تُغيّر العالم.

بحث نُشر في MIT Sloan Management Review (2019) درس أكثر من 200 مشروع تقني ووجد أن المشاريع التي يشارك فيها العميل بفاعلية — يحضر اجتماعات دورية، يقدم ملاحظات منتظمة، يشارك في اتخاذ القرارات — تنجح بنسبة أعلى بـ 60% من المشاريع التي يكتفي فيها العميل بتسليم المتطلبات وانتظار النتيجة.

ودراسة أخرى من Standish Group في تقريرها السنوي CHAOS Report أظهرت أن "مشاركة المستخدم" (User Involvement) هي العامل الأول في نجاح مشاريع تقنية المعلومات — أهم حتى من خبرة الفريق التقني.

لكن المشاركة لا تعني التدخل في التفاصيل التقنية. المشاركة الصحية تعني: - حضور اجتماعات المراجعة الأسبوعية. - تقديم ملاحظات واضحة ومحددة. - اتخاذ قرارات بشأن الأولويات والأهداف. - ترك التفاصيل التقنية للمتخصصين.

الفرق بين الشراكة والتدخل: الشريك يقول "هذا لا يخدم جمهوري" — المتدخل يقول "غيّر الكود هنا".

للمبرمج/المصمم: - في أول اجتماع اسأل: "ما الهدف من المشروع؟" قبل "ما المطلوب؟". الأولى تفتح حواراً والثانية تفتح قائمة مهام. - اشرح "لماذا" وراء كل اقتراح تقني. لا تقل "هذا أفضل" — قل "هذا أفضل لأن جمهورك يفعل كذا". - قدّم تقارير أسبوعية قصيرة تُشعر العميل بالاطمئنان والمشاركة.

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

كما يقول المثل العربي: "إذا أنت أمير وأنا أمير، مين يسوق الحمير؟" — الشراكة تعني توزيع أدوار لا صراع سلطات.

خذ مثالاً من واقعنا العربي: شركة كريم (Careem) التي تأسست في دبي عام 2012. فريقها التقني لم يكن ينفّذ أوامر فقط — بل كان شريكاً حقيقياً في فهم احتياجات السوق العربي. هذا التعاون بين الرؤية التجارية والخبرة التقنية هو الذي أنتج ميزات مثل الدفع النقدي — وهي ميزة لم تكن موجودة في Uber وقتها لأنهم لم يفهموا أن كثيراً من الناس في المنطقة يفضلون الكاش. النتيجة: استحواذ Uber على كريم بـ 3.1 مليار دولار عام 2019.

أو بالشامي: "لمّا الشغلة شراكة حقيقية، بتطلع النتيجة ما بتزبط أحسن من هيك!" من Nokia التي أمرت فسقطت إلى Apple التي تشاركت فأبدعت — التاريخ واضح. أفضل التطبيقات والمشاريع لم تُبنَ بأوامر — بُنيت بحوار. والأبحاث من MIT Sloan وStandish Group تؤكد ذلك بالأرقام. العميل الذي يتعامل كشريك يحصل على منتج أذكى. والمتخصص الذي يُشعر عميله بالشراكة يحصل على علاقة عمل أطول وأثمر. الشراكة ليست تنازلاً عن السلطة — إنها توزيع ذكي للأدوار.