الأخطاء الشائعة في التواصل مع العميل: كيف لا تحبط عميلك

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

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

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

لا تفشل في التواصل الأساسي مع العملاء

تخيل التواصل مع العملاء كما تفعل مع التواصل اليومي مع زملائك في العمل أو الأصدقاء أو أي شخص آخر قد تقدم له مجاملة.

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

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

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

ومع ذلك ، فإن الأمور ليست بهذه البساطة أو الخطية في عالم تطوير البرمجيات.

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

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

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

تعزز الاتصالات المعيبة مع العملاء توقعات غير واقعية

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

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

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

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

ستحصل على الجهاز اللوحي في اليوم التالي. لا إضافات ، لا يوجد رصيد تخزين. الآن أنت محبط!

"ماذا؟ بالأمس فقط أخبرتني أنني سأحصل على صفقة أفضل! هذا ليس عدلا! لقد أخبرت الأطفال بالفعل ... "

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

كيف يمكن للمطورين ، وخاصة المستقلين ، تجنب المواقف المماثلة في تواصلهم مع العملاء؟

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

• استمع للعميل.

• حلل مشكلتهم.

• تحليل الحل المقترح.

• تأكد من أنه ضمن الميزانية / الجدول الزمني.

• أخيرًا ، انطلق وقدم اقتراحك.

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

لا تفترض أنك تعرف ما يحتاجه العميل

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

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

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

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

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

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

عدم فهم ما يطلبه العميل

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

ماذا؟؟؟

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

ثانيًا ، ليس كل شخص كاتبًا ماهرًا جدًا ؛ يحاولون أن يقولوا "أ" لكن ينتهي بهم الأمر بوصف "ب".

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

"أوه ، لكن في حالتي ، لم أحصل على أي مستندات. جلست للتو مع العميل وشرحوا لي كل شيء أثناء تدوين بعض الملاحظات ".

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

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

لماذا لا يجب عليك تسليم كل ما يطلبه العميل دون التفكير

حسنًا ، الآن بعد أن عرفت أنه يجب عليك الاستماع إلى العميل وتأكيد ما فهمته ، يمكنك المضي قدمًا وفعل كل ما طلبوه منك ، أليس كذلك؟

خاطئ - ظلم - يظلم!

الآن هي اللحظة التي يمكنك فيها أخيرًا استخدام كل الخبرات التي لديك واسأل نفسك: هل ما طلب منك العميل هو حل مشكلته؟ هل ما طلبوه منك حقًا ما يحتاجونه؟

ستندهش من معرفة عدد المرات التي تكون فيها الإجابة بـ "لا".

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

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

النموذج الأولي - لا تكتب وثائق موسعة

لقد قلت بالفعل إنك وعميلك بشكل عام ليس لديهما نفس المنظور ، أليس كذلك؟ ومن ثم ، فإنه مثلما يؤثر على فهمك لوثائقهم ، فإنه سيؤثر على فهمهم لما تقدمه كتابيًا. إنها مسألة سياق أيضًا.

لذا ، أوافق على أنه بطريقة ما (على مستوى أعلى أو أدنى) ، يتعين علينا توثيق ما نحن على وشك تطويره. لكن تسليم عدة صفحات من النص بدون أي عناصر مرئية لن يفيدك كثيرًا. سوف يشعر العميل بالملل من قراءته ، وسيتوقف عن الانتباه ، وربما لن يكون قادرًا على فهم ما تقصده بقواعد العمل المعقدة تلك - أو سيفسر شيئًا مختلفًا تمامًا عما كنت تتصوره.

ضع في اعتبارك أن سوء الفهم هذا يمكن أن يكون أسوأ إذا لم يكن لدى العميل خلفية فنية.

يمكن أن تؤدي كل هذه العوامل إلى نفس النتيجة الإشكالية: سيشتكي العملاء عند تسليم المنتج لأنه من المحتمل أنه لن يكون ما يفكرون فيه.

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

توقف عن إضاعة الوقت في إقناع العميل بأنك على حق

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

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

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

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

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

تعرف متى تلتزم بالمواعيد النهائية

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

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

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

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

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

أيضًا ، أقترح بشدة (خاصة إذا كنت قد قدمت بالفعل تقديرًا) أن تخبر العميل دائمًا عندما يستغرق الأمر وقتًا أطول من المتوقع حتى يتمكن من التصرف لمساعدتك!