أنا أعمل كمدير مشروع لـ Live Typing. في العام الماضي ، كتبنا في مدونة شركتنا أنه إذا تعطل الموعد النهائي ، فإن الشيء الرئيسي هو عدم جعل هذه مفاجأة وتحذير العميل. ولكن كلما عملنا ، كلما أدركنا أن المواعيد النهائية الأسوأ من الانهيار لا يمكن أن تكون إلا معقدة وعملاء وفرق محترقة تحت ضغطهم.
تلك الشركات التي اكتسبت عميلين منتظمين أثناء العمل ، تعرف على كيفية تصفية العملاء المتوقعين المشبوهة حتى في مرحلة المكالمة الأولى ، ويمكنها تحمل تكاليفها. للأسف ، لا يمكن الاستوديوهات الشباب في السعي وراء الخبرة والأرباح ، للأسف ، دون هؤلاء العملاء.
قبل الدخول في المراكز العشرة الأولى من التصنيفات الصناعية المختلفة ، عملت
Live Typing مع عميل قام بإلغاء تنشيط الفريق لدرجة أن الناس بدأوا في مغادرة الشركة. للأسباب التي سأناقشها أدناه ، اتفقنا مع العميل مرة أخرى. خوفًا من أزمة جديدة في العلاقات ، قمت بتطوير تكتيك إدارة خاص للحفاظ على سلامة وسلامة الفريق. بعد كل شيء ، العثور على مطور رائع أمر صعب ، والتدريب وتكيف موظف جديد هو أغلى من الاحتفاظ بموظف قديم. بالإضافة إلى ذلك ، فإن تفاصيل الاستعانة بمصادر خارجية هي أنه بعد هذا المشروع ، سوف يأخذ المطورون المشروع التالي ، ومن المهم أن يفعلوا ذلك مع العقول التي لم يتم تفجيرها بالكامل.
حول كيف فعلت ذلك ، اقرأ المقال.
لأسباب واضحة ، سأتصل العميل ببساطة "العميل". حتى في المشروع ، وبالتعاون المتكرر ، لم نطلق عليه داخل الفريق أي شيء آخر. لماذا؟ عن ذلك أدناه.
قبل التاريخ
قبل عامين ، جاء مشروع إلينا. قبل الوصول إلينا ، عمل حوالي خمسة فرق على ذلك ، وقام بتجميع كود قديم جيد.
كانت علاقات العميل بالفرق السابقة بعيدة عن علاقة الشريك ، لذلك قرر معه أن يتخذ موقفًا مسيئًا تلقائيًا وتسييج نفسه بجدار من عدم الثقة.
لتسريع الاتصال والتطوير ، جعل مدير المشروع الأول الدردشة في Slack شائعة بين العميل والفريق - لم يتم تطوير التطبيق من قبلنا وطرح الكثير من الأسئلة التي كان يجب توجيهها بسرعة إلى العميل. في معظم الحالات ، تسرع هذه المنهجية في نقل المعلومات بين أعضاء الفريق ، لكن عميلنا لم يحرم نفسه من فرصة الإدلاء بتعليقات وقحة سواء في الدردشة أو في شخص معين.
التفت العميل إلى شخصيات ، مما أدى إلى صراعات مفتوحة ، وسمع اسمه حتى من أولئك الذين لم يشاركوا. ونتيجة لذلك ، فقدت الشركة موظفًا واحدًا على الأقل لم يستطع تحمل هذا الموقف ، وغادر العديد منهم بعد شهرين. بدت الأسباب الرسمية للمغادرة مختلفة ، لكننا نعرف شيئًا ما.
عندما نفد العميل المال ، انفصلنا. المال ، تجدر الإشارة ، ذهب ، بما في ذلك دعم رمز القديمة وتطوير وظائف من أجل الوظيفة.
عاد العميل لاحقا. لقد أقنعنا أنه يريد تطوير التطبيق من البداية ، والتخلي عن التعليمات البرمجية القديمة ، وتقليل الوظائف والتواصل بأسلوب مختلف. قبلنا ذلك ، ولكن بعد مرور بعض الوقت بدأت القصة في تكرار نفسها.
لم يثق العميل في تقييماتنا وعروضنا. كان لديه فكرته الخاصة حول كيفية عمل المنتج. لقد كان لدينا أيضًا فهم لكيفية ذلك ، لكن العميل لم يدرك الحجج ، وبدلاً من أن يكون شريكًا له خبرة في تطوير التطبيقات ، لم ير فينا سوى الأيدي التي حولت قائمة الأمنيات إلى الحياة. لا نعرف الأسباب التي تجعل العميل يضع نفسه في مثل هذا الموقف ولن يتكهن.
كان الوضع يسخن. إذ نستذكر كيف تطورت الأحداث في الماضي ، فقد أعطينا الأولوية بترتيب غير عادي بالنسبة لنا: أولاً وقبل كل شيء ، تحتاج إلى إنقاذ الفريق ، وعندها فقط إغلاق المشروع بنجاح ، وإذا أمكن ، الحفاظ على ولاء العملاء.
تكتيكات الحماية للعملاء المعقدين
الآن دعونا نلقي نظرة على التقنيات التي ساعدتنا على تحقيق هدفنا ، والأخطاء التي يجب ألا تتكرر ، والاستنتاجات التي يمكنك استخدامها في عملك.
اشرح قيمة التصميم
لذلك ، بدأ المشروع من نقطة الصفر. في سياق هذا القرار ، نشأ اقتراح للقيام MVP ودفع ثمن عملنا وفقًا لنموذج سعر الإصلاح. بدا هذا منطقيًا ، لأنه إذا لم يكن هناك رمز لشخص آخر ، فلن تكون هناك مخاطر في ذلك.
ناقص سعر الإصلاح كنموذج للدفع هو أنه يحرم المشروع من المرونة: في حين أن الوظيفة يتم تنفيذها ، والتي وافق عليها الطرفان في المهمة الفنية ، فقد يتغير السوق ولن تؤدي نتيجة العمل إلى حل مشاكل المستخدم الفعلية. لا يمكن تطوير MVPs بسعر ثابت إلا إذا كنت قد اختبرت بشكل شامل وشامل جميع الفرضيات ، وقمت بتصميم المواصفات الفنية ، وكتبت الوثائق التفصيلية. لقد أهمل عملائنا التصميم ، أو بالأحرى ، أخذ الأمر على عاتقه.
القصة مع اختيار خدمة للمحادثات هو مؤشر. قام العميل بالتحقيق في الحلول التقنية الممكنة بنفسه ، وقدم لنا مجموعة من الخدمات: "أيهما أفضل؟" لقد اخترنا الخدمة A لأنها تناسب المشروع على مجموعة من أساليب API ، ومن وجهة نظر التطوير والتكامل كانت أفضل من الخدمة B. لم نقم بتصميم الخدمة لتعمل مع بنيتنا الأساسية ولم نتحقق من أي شيء آخر غير هذه المعايير الرسمية: لا الاستقرار ، لا سرعة الاستجابة ، لا شيء - لم يكن هناك ميزانية. انتهى الحديث عن الاستجابة بشكل أبطأ مما يمكن إذا كان هناك وقت للتحقق.
لا تسقط للتلاعب بروح "إذا كنت في حاجة إليها لإكمال المهمة ، فقم بذلك مجانًا! إذا كان هناك مثل هذا: جوهر تطوير الاستعانة بمصادر خارجية هو حل مشاكل العميل مقابل أموال العميل.
يجب على المحلل تصميم. لديه المعرفة التي تسمح له بفهم وتوضيح ما يحتاجه العميل بالضبط في النهاية ، وبناء بنية نظام مشتركة: ما هي الخدمات التي ستكون في المنتج ، هل هناك أي تكامل مع أنظمة الطرف الثالث ، وكيف تذهب الطلبات بين الخدمات ، أين يتم تخزين المعلومات ، وكيف يتم تسليمها ، وما إلى ذلك. هذا ضروري ، أولاً ، بحيث يعمل منتج العميل بسرعة وبشكل موثوق ، وثانياً ، لتقديم المشورة بشأن ما يمكنك توفيره ، وما هو بالضبط لا يستحق كل هذا العناء.
اجعل معنى كلمة MVP هي نفسها للجميع
ماذا يعني MVP بالنسبة لنا:
- نحن نتفق على الوظيفة الأساسية للتطبيق ونلميع فقط تلك الميزات التي تتعلق به. يجب أن تعمل الميزات الأخرى بحيث لا توجد رغبة في إغلاق التطبيق ؛
- نقدم الحد الأدنى من الوظائف اللازمة لحل مشكلة العمل ، وليس هناك منطقة مسؤول مصممة ؛
- نؤجل التخصيص إلى وقت لاحق ، أي أننا نستخدم مكونات في التصميم يمكن إعادة استخدامها على شاشات متعددة ، ونرفض عناصر التخطيط المعقدة ونبسط التصميم إذا لزم الأمر.
لكن عملاء MVP لديهم تفسيرات مختلفة. ماذا يعني هذا بالنسبة لنا:
- الحد الأدنى من الوظائف لأدنى حد من المال.
في المستقبل ، حدث بطريقة ما أن "الحد الأدنى من المال" قد بقي وأضيف الموقف "نحن نعرف كيفية القيام بذلك ، وكذلك نفعل كما نقول".
مثل هذا الموقف يهدد الشراكة الطبيعية. لا يمكن إزالة التهديد إلا عن طريق التصميم والمهمة الوظيفية ، والتي تحدد كل شيء يجب أن يكون التطبيق قادرًا على القيام به. هل هناك متطلبات واقتراحات جديدة غير ملتزم بها؟ الرجوع إلى القانون الاتحادي وعرض لشراء الوقت. ربما هذا شكل من أشكال الشكليات وليس التركيز على العملاء ، ولكنه من العدل بالنسبة لشركتك.
مرة أخرى: يتم دمج MVP مع الإصلاح عندما يكون هناك تصميم. لم يكن لدينا ذلك ، لكن يجب أن تحصل عليه.
دع المطورين يجادلون معك
ولا تعمل أبدًا مع تصميم غير ملتزم به من العميل ، كيف عملنا.
غالبًا ما يتم ربط المطورين: بمجرد تعيين المهمة ، سيقومون بذلك. ولكن في المشروعات ذات الميزانية المحدودة ، يجب أن يكون تنفيذ كل مهمة معقدة أمرًا موضع تساؤل من أجل استعراضه والوفاء بالموعد النهائي.
كان مصدر هذه المهام بشكل غير متوقع هو التصميم الذي تعامل معه المصمم من جانب العميل. قيل للمطورين إنهم إذا طلبوا بعض التصحيحات ، فسيتم إرسالها على الفور ، لذلك بدأنا العمل ليس مع الإصدار الثابت للتصميم ، ولكن في محرر Figma ، حيث تم إنشاء هذا التصميم. أعطى المطورين تقييما وحصلت على العمل.
وبعد ذلك ، واحدة تلو الأخرى في التصميم ، بدأت تظهر العناصر التي لم تكن في الأصل - وهذا يمكن أن ينظر إليه من النسخة الاحتياطية ، التي قمت بها في حالة. لكن قبل بدء التطوير ، من المستحيل التحقق مما إذا كان هناك جزء معين من التصميم قد تغير - على الأقل لأن المطور يأخذ المهام بترتيب مناسب لنفسه.
تحديد التناقضات ساعد في نفس حرية التعبير. يمكن للمطوِّر أن يأتي إليّ ويطالب ليس فقط بالعناصر التي لا يمكن تكوينها بسرعة ، ولكن أيضًا العناصر الموجودة في تصميم العميل - وهذا أمر مفهوم ، لأن المصمم نفسه قدمهم سرا هناك - ولكن ليس في نسختنا. لم يتم تضمين هذه العناصر في التقييم ، مما يعني أنه لا ينبغي لنا التعامل معها على نفقتنا الخاصة.
في عالم التنمية الصحية ، لا يسمح سعر الإصلاح بزيادة حجم العمل وتغيير الظروف أثناء التنقل.
الحفاظ على العميل بعيدا عن الفريق
في المرة الأخيرة التي وصلنا فيها بين المطورين والعميل مباشرةً - هناك فرق يُعتقد أنه يجب على المدير أولاً وقبل كل شيء مراقبة البنود والميزانية ، وليس بمثابة مرسل لمتطلبات العميل.
هذه منهجية رائعة بمزاياها: رد فعل كل جانب أسرع ، والفهم أفضل لمهمة العمل ، ونمو سلطته ، ولا يموت المدير كجهاز إرسال. لكن مع العلم أن العميل يمكن أن يصبح شخصيًا ، فقد عزلته عن الفريق. لم يبق في الدردشة سوى العميل ومدير الحساب ومدير المشروع ، أي أنا.
ماذا أعطانا؟ قمت بإدارة الاتصالات ولم تسمح للعلاقات الشخصية بتسميم روتين العمل. في لحظات عندما انتقد العميل الفريق في طريقته ، أجبته بأننا سوف نتحرك ونعاقب الموظف. تشير الملاحظات إلى أنه من أجل طمأنة بعض العملاء ، يكفي أن يتم التضحية بشخص ما من الفريق حتى من أجل المتعة ، لذلك استمر الموظف في العمل بهدوء ولم يعلم حتى أنه عوقب.
إذا كنت تشك في أن العميل لا يهدأ ، فلا تحضر معه الفريق لفترة على الأقل ، حتى تكون مقتنعا بالعكس.
إعادة صياغة التغذية المرتدة من العميل إلى الفريق
في جو من عدم الثقة والنقد المستمر ، لم يعد الفريق قادرًا على معالجة ردود الفعل بالشكل الذي وصل به ، ويبدأ العميل في التفكير في أن الفريق لا يعمل إلا بنوايا شريرة - ويجسدها.
ماذا تفعل مع هذا المدير؟ لن يضر التعديل التجميلي: لقد أزلت تقييم الشخصية من الملاحظات ، ولم يتبق سوى صياغة الخطأ دون فقدان المعنى. ونظرًا لعدم حصولك على أي ثناء من العميل ، لم أنسى أن أقدم للفريق تعليقاتي الخاصة - فيما يتعلق بالمهام التي لم تثر أي أسئلة ، مما يعني أنه تم تنفيذها جيدًا من وجهة نظر العميل.
كان:
"التطبيق لا يعمل الدفع. ما اليدين فعلت؟ "أصبح:
"يا شباب ، التطبيق لديه ما يدفعه ، يطلب العميل معرفة ذلك ، إليك لقطات الشاشة. ومع الرسوم المتحركة التي تأخرت قبل أسبوع ، كان كل شيء على ما يرام. "لا تتسرع في الحصول على الحشرات
إدخال الأخطاء في مدير المهام بمجرد استلامها من العميل يكون من الخبرة. مسلحًا بالعين الحرجة ، سيساعد المدير في توفير ساعات من المطورين واختبار. مجرد التحدث مع العميل أو طلب إعادة تشغيل الإجراءات التي تؤدي إلى الخطأ وتسجيل الفيديو ، يمكنك أن تفهم أن الخطأ ليس أولوية أو ظهر لأن العميل كان يقوم بشيء خطأ - والآن ، لم تعد بحاجة إلى تحريره. لذا ، تمكنت من فرز ربع الأخطاء الواردة ، وكان جزء آخر مرتبطًا بخدمة دعم الخدمة المتكاملة - كان هناك عدد كافٍ من أدوات تطوير البرامج (SDK) الخاصة بطرف ثالث في المشروع.
لا تذكر اسم العميل
ولعل أهم البصيرة. وفقًا للذاكرة القديمة لأحد أعضاء الفريق ، فإن التعبير عن اسم العميل أثار موقفًا متحيزًا تجاه أي ملاحظة من جانبه ، بغض النظر عن مدى كفايتها. وتوصلت إلى استدعاء العميل فقط العميل ، مما قلل من السلبي. يبدو أن كل شخص يفهم من يتحدثون عنه ، ولكن صدقوني - فقد حسّن هذا الفارق بيئة المشروع.
استنتاج
من أجل الوضوح ، قررت أن أقصر كل ما ذكر أعلاه على جدول حول مبدأ "كيف لا وكيف نفعل ذلك".
لكن نصيحتنا ستكون مفيدة لك إلى الحد الأدنى إذا كان الشخص المسؤول عن العمل مع العملاء الجدد في شركتك ، أو كشف مدير الحساب عن عيوب العميل في مرحلة التفاوض.
فيما يلي بعض النقاط المهمة التي نوليها الاهتمام الآن إلى:
- ماذا يقول العميل عن المقاول السابق ، إذا كان. إذا كان يتحدث سلبًا عنه ، فهناك احتمال أنه لا يرى أي رأي غير رأيه ويفرض قراراته.
- هل لدى العميل خبرة في تكنولوجيا المعلومات؟ بالنسبة للعميل ذي الخبرة ، تثير عملية التطوير أسئلة أقل.
- سواء كان مساومات لكل قرش أم لا. كلما زادت رغبة العميل في دفع مبلغ أقل ، كلما جادل عن طيب خاطر وعناد.
آمل أن تكون هذه المقالة مفيدة لشخص ما. وإذا كنت بالفعل في مكاني ، فأخبرنا كيف حلت هؤلاء العملاء الصعبين.