المدونة

مقدمة

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

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

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

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

ما هي عقلية المنتج

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

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

ولتبني عقلية المنتج بشكل كامل، يجب أن نسأل: لماذا يوجد هذا المنتج من الأساس؟ الإجابة: يوجد لحل مشكلة يواجهها العديد من المستخدمين. أحب النظر إلى هذا المفهوم من خلال إطار «الوظائف المراد إنجازها» (Jobs-to-Be-Done). رغم أن الاسم قد يبدو غريبًا في البداية، إلا أن هذا الإطار يقدم رؤى قيّمة.

الوظائف المراد إنجازها (Jobs-to-Be-Done)

«الوظيفة المراد إنجازها» (Job-to-Be-Done) هي عبارة تصف بدقة ما يحاول مجموعة من الأشخاص تحقيقه في موقف معين. ويقدم هذا الإطار وهذه النظرية التجارية تفسيرًا لسبب شراء العملاء للمنتجات: فهم لا يشترون المنتج لذاته، بل من أجل الحل الذي يقدمه لهم.

إطار «الوظائف المراد إنجازها» (Jobs-to-Be-Done) هو نهج لتطوير المنتجات يعتمد على فهم الهدف المحدد للعميل (أو «الوظيفة») والعمليات الفكرية التي تدفع العميل إلى «توظيف» منتج معين لإتمام تلك الوظيفة. عندما نفحص المنتج من خلال هذه الزاوية، سوف نكتشف ما يحاول المستخدمون تحقيقه عندما يشترون منتجًا أو خدمةً ما.

كيف يمكنك تطبيق هذا النهج في التطوير؟

تتضمن نظرية «الوظيفة المراد إنجازها» العديد من المفاهيم، لكن الفكرة الأساسية بسيطة: ركّز على ما يحاول العميل تحقيقه، وليس على المنتج نفسه. تساعدنا هذه النظرة على تحديد ما إذا كانت المتطلبات والتطبيق يتوافقان مع احتياجات العميل. تأمل الأمثلة التالية:

• مثال المثقاب:
  العملاء لا يريدون بالضرورة المثقاب نفسه — بل يحتاجون ثقبًا في الحائط. ربما يكون الحل البديل أفضل إذا استطاع المستخدم الحصول على الثقب دون مثقاب. وعند طرح أسئلة أعمق، مثل: “لماذا يحتاج المستخدم إلى ثقب؟”، يمكن اكتشاف دوافع أعمق، كالرغبة في تعليق صورة لأجل خلق مساحة ترحيبية في المنزل.
• مثال Uber Eats
  عندما يطلب شخص ما عبر Uber Eats، فهو لا يطلب مجرد طعام — بل “يوظّف” الخدمة لإشباع جوعه بسرعة وراحة دون الحاجة إلى الطبخ أو الخروج لتناول الطعام. يساعد هذا الفهم في التركيز على تبسيط عملية الطلب، وضمان سرعة التسليم، والحفاظ على جودة الطعام أثناء النقل.

تبنّي هذه العقلية سيساعدك بشكل كبير على التعرف على المتطلبات وتحليلها لزيادة الفائدة المقدمة للعملاء.

تحديد منطق المنتج (Business Logic)

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

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

الاستكشاف التعاوني

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

1. خرائط العمليات (Process Maps)

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

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

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

2. رحلات المستخدم (User Journeys)

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

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

رحلة المريض الجديد تتضمن العديد من نقاط التفاعل على مدار فترة طويلة.

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

توضيح حدود نطاق العمل (Nailing Down the Scope)

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

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

بعد إدراكنا لخطر توسّع النطاق، بادرنا بعقد اجتماع مع مدير المشروع والعميل لإعادة النظر في الهدف الأساسي من المشروع. طرحنا السؤال التالي: «ما المشكلة الحقيقية التي نحاول حلّها؟». جاءت الإجابة واضحة: الهدف الأساسي هو ضمان تجربة تسجيل مستخدمين سلسة وآمنة.

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

إليك بعض الاستراتيجيات العملية لتضييق نطاق المشاريع الخاصة بك:

• تحديد الأولوية للوظائف الأساسية:
  حدّد الميزات الأساسية التي تعالج حاجة المستخدم الرئيسية مباشرة. اسأل نفسك: «هل هذه الميزة تحل مشكلة حرجة؟» إذا لم تكن كذلك، فكّر في تأجيلها إلى مرحلة لاحقة.
• المناقشات المبكرة مع أصحاب المصلحة: تعاون بشكل وثيق مع مدراء المشاريع والعملاء وغيرهم من أصحاب المصلحة للاتفاق على أهداف المشروع. استخدم خبرتك التقنية لتوضيح التعقيدات المحتملة وتقديم المشورة بشأن التنفيذ الواقعي والتدريجي.
• استخدام النماذج الأولية والمنتجات الأولية:
  طوّر منتجًا أوليًا بحد أدنى من الميزات يشمل الميزات الضرورية فقط. يساعد ذلك على الحفاظ على تركيز المشروع وتقديم منتج ملموس يمكن لأصحاب المصلحة التفاعل معه، مما يمكّنهم من اتخاذ قرارات مدروسة بشأن التحسينات المستقبلية.
• وضع معالم واضحة ونقاط مراجعة:
  حدّد نقاط مراجعة واضحة للتحقق من التقدم المحرز مقارنةً بالنطاق المتفق عليه. يسمح ذلك بالكشف المبكر عن أي انحرافات، ويتيح إجراء التصحيحات اللازمة قبل أن تتراكم التغييرات الصغيرة وتتحول إلى مشكلة أكبر.

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

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

الملخص

في الختام، الانتقال من العقلية التقنية البحتة إلى تبنّي عقلية المنتج (Product Thinking) قد يُحدث تحولًا جذريًا في أسلوبك في تطوير البرمجيات. من خلال التركيز على حل مشكلات المستخدمين الحقيقية، وكشف التعقيدات الخفية، والتعاون الفعال مع فريقك، والحفاظ على نطاق مشروع واضح، فإنك تضع الأساس اللازم لإنشاء منتجات ذات قيمة حقيقية. تذكّر دائمًا أن التكنولوجيا لا تتعلق فقط بكتابة الأكواد—بل تتعلق بصناعة حلول تُحسّن حياة الناس.

بينما تواصل رحلتك، تذكّر دومًا أن:

«البساطة هي جوهر الإتقان.»

إن التحوّل من عقلية تقنية بحتة إلى عقلية المنتج يساعدك في إنشاء برمجيات أبسط وأكثر فائدة للمستخدمين.