5 خطوات للحصول على رضا العميل و كسبه في صفك بدون تملُّق

أثناء تطوير أحد البرامج تفكر هل سيُعجَب العميل بالبرنامج؟ أم سيطلب المزيد و المزيد من التعديلات.

هل كُنت في هذه الحالة من قبل؟

إذا لم تمُر بهذه الحالة فهذه التدوينة لك فدرهم وقاية خيرٌ من قنطار علاج.

و إذا كُنت في هذه الحالة فأقولُ لك: لست وحدك!

هذا هو حال جميع من يعمل على تطوير البرامج “المبرمجين”.

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

لست وحدك، لذا فستجد لدى الآخرين شيئاً يساعدك على تخطي هذه المعاناة.

وهذا هو ما أشاركه معك اليوم.

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

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

ولكن..

هناك حالتان لتطوير البرمجيات:

1. مبرمج يطور برنامجاً طلبه العميل.
2. مبرمج يطور برنامجاً حتى يبيعه للعميل أو يقدمه كخدمة.

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

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

عندما يطور المبرمج برنامجاً طلبهُ العميل.

بإختلاف أنواع البرامج التي يطورها المبرمج (تطبيقات إنترنت، برامج جوال، برامج سطح مكتب) فإن هذه البرامج تصطدم بحاجز تعلمه تماماً.

الحاجز هو رفض العميل لاستلام البرنامج لعدم تلبية حاجاته.

فلنضع الأمر بكلمات أوضح

توقعات العميل لم تتوافق مع طريقة عمل البرنامج أو مخرجاته.

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

لدينا طرفي معادلة (توقعات العميل و طريقة عمل البرنامج و مخرجاته).

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

فما المنطق في أن يطلب المبرمج من عميل طلب برنامجاً يخدم فرعين بأن تطلب منه تسليم برنامج يعمل في فرع واحد؟!!

بحكم عملك كمبرمج محترف اعلم أن بهجة و سعادة عميلك هي في قدرتك على التحكم في الطرف الثاني من المعادلة “طريقة عمل البرنامج و مخرجاته”.

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

هذه سبع نقاط يجب أن تهتم لتطوير برنامج يتوافق مع متطلبات العميل و يوصلك إلى رضاه.

1. البداية الصحيحة في فهم مشكلة العميل

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

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

أغلب الخلافات التي تحدث بين العميل و المبرمج أساسها شيئان:

1. اختلاف في المفاهيم و وجهات النظر.
2. اختلاف في الأمور المالية.

باهتمامك بهذه النقطة تقضي على 50% من الخلافات التي قد تواجهك مستقبلاً مع العميل.

في هذا الوقت المستقطع كل ما عليه فعله هو الاستماع للعميل و أن تعيش حياته.

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

يجب أن تخرج من هذه المرحلة و أنت تملك عقلية العميل و أعماله هي أعمالك.

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

2.  أبعد العميل من الاصطدام بالجدار اقترح حلول و خيارات

أنت الخبير.

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

إستخدام المعارف الناقصة في محاولة إيجاد حلول يؤدي أحياناً إلى الوصول إلى طرق مغلقة.

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

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

المبادرة بإعطاء حلول أفضل و محاولة إقناع العميل بها يعطيه إحساساً بالأمان و الثقة يحتاجه العميل في أول مراحل العمل.

3. أحسبها صح، التحليل أهم من البرمجة

فعلاً، التحليل أهم من البرمجة.

ما بين فهم مشكلة العميل و تطوير البرنامج يحتل تحليل النظام مكانهُ المهم.

عملية التحليل تتضمن فهم مشكلة النظام و ما الذي يجب تطويره و ما الذي يتوقع عمله من البرنامج.

ليس هذا فقط:

بل هناك جزءٌ مهم يغفله كثير من المبرمجين، و هو ما الذي يجب أن لا يفعله البرنامج، أو بمعنى آخر ما الذي يقع خارج مدى تطوير البرنامج.

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

على كل فتحليل النظام هو ما يحدد فعلاً ما الذي سيتوقعه العميل من البرنامج تماماً.

كما أن التحليل أيضاً هو الأساس الذي يُبني عليه العمل البرمجي، فإذا كان الأساس صلباً و صحيحاً كان البناءُ مستقيماً و سهلاً.

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

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

سوف أعطيك مثالاً:

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

إكتشاف الأخطاء المبكر في مراحل تطوير النظام يجعل تكلفة إصلاح الأخطاء أقل.

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

4. لا تترك العميل يخسر و أنت تعلم

أنا أنفذ طلبات العميل أياً كانت.

هذه العبارة يجب أن لا تكون ضمن قاموسك أبداً.

ببساطة هذه العبارة تؤثر على سمعتك البرمجية أولاً، ثم على إنسيابية عملك ثانياً.

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

تبني جملة “أنا أنفذ طلبات العميل أياً كانت” يؤدي إلى موت كثير من المشاريع التي ستعمل بها و تبذل من أجلها الليالي و الأيام سهراً و برمجة و جُهداً.

فما هو احساسُك يا ترى و أنت ترى جهد 6 شهور مثلاً يذهبُ إلى القُمامة بكل بساطة.

هل فهمت ما أعنيه؟

لا كسبت سمعةً ولا أدّى برنامجُك هدفاً في الحياة!

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

الكثير و الكثير من التعديلات.

مرةً أخرى: المزيد و المزيد من التعديلات.

بُعبُع المبرمجين هي التعديلات و حلم المبرمجين هو البرمجة المستمرة بلا تعديلات أثناء البرمجة.

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

5. التواصل مفتاح النجاح و الفشل

التواصل هو مفتاح نجاح البرمجة للعملاء.

إذا راجعت النقاط الأربع السابقة ستجد أنها تعتمد على التواصل.

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

و بنفس القدر أقول: التواصل هو مفتاح فشل للبرمجة للعملاء أيضاً.

لذا ذكرتُ أن التواصل يجب أن يكون بقدر الحاجة.

للتواصل معادلة بسيطة: تواصل أكثر مما يجب = تأخير في تسليم البرامج و إضاعة للوقت.

تواصل أقل مما يجب = نقص في فهم المتطلبات و تطوير برامج لا تُرضي العميل.

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

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

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

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

الخلاصة

إن التواصل مع العملاء مع الإحترافية في العمل هو مفتاح الوصول إلى رضا العميل و رضا المبرمج أيضاً.

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

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