👞 👨🏽‍⚕️ ✍🏿 जटिल ग्राहक: अपनी टीम को उनसे कैसे बचाएं 🕳️ 🔱 🍺

मैं लाइव टंकण के लिए एक परियोजना प्रबंधक के रूप में काम करता हूं। पिछले साल, हमने अपने कॉरपोरेट ब्लॉग में लिखा था कि यदि समय सीमा टूट जाती है, तो मुख्य बात यह नहीं है कि यह एक आश्चर्यचकित करने वाला है और ग्राहक को चेतावनी देता है। लेकिन जितनी देर हम काम करते हैं, उतना ही हमें एहसास होता है कि टूटी हुई डेडलाइन से भी बदतर केवल जटिल हो सकती है, भावनात्मक ग्राहकों और टीमों को उनके दबाव में जला दिया गया।

जिन कंपनियों ने काम के दौरान नियमित ग्राहकों के एक जोड़े का अधिग्रहण किया है, वे जानते हैं कि पहली कॉल के चरण में भी संदिग्ध फ़िल्टर कैसे किया जा सकता है, और इसे वहन कर सकते हैं। काश, युवा स्टूडियो अनुभव और कमाई की तलाश में, ऐसे ग्राहकों के बिना नहीं कर सकते।

विभिन्न उद्योग रेटिंग के शीर्ष दस में आने से पहले, लाइव टंकण ने एक ग्राहक के साथ काम किया, जिसने टीम को इतना आबंटित किया कि लोगों ने कंपनी छोड़ना शुरू कर दिया। जिन कारणों के लिए मैं नीचे चर्चा करूंगा, हम ग्राहक के साथ फिर से सहमत हुए। संबंधों में एक नए संकट के डर से, मैंने टीम को सुरक्षित और स्वस्थ रखने के लिए एक विशेष प्रबंधन रणनीति विकसित की। आखिरकार, एक अच्छा डेवलपर ढूंढना मुश्किल है, और एक पुराने कर्मचारी को रखने की तुलना में एक नए कर्मचारी को प्रशिक्षण और प्रशंसा करना अधिक महंगा है। इसके अलावा, आउटसोर्सिंग की बारीकियां ऐसी हैं कि इस परियोजना के बाद, डेवलपर्स अगले एक को ले जाएंगे, और यह महत्वपूर्ण है कि वे इसे उन दिमागों के साथ करते हैं जो पूरी तरह से नष्ट नहीं हुए हैं।

मैंने इसे कैसे किया, इसके बारे में लेख पढ़ें।

स्पष्ट कारणों के लिए, मैं ग्राहक को बस "ग्राहक" कहूंगा। यहां तक कि परियोजना पर, बार-बार सहयोग के साथ, हमने टीम के अंदर इसे और कुछ नहीं कहा। क्यों? इसके बारे में नीचे।

प्रागितिहास

दो साल पहले, एक प्रोजेक्ट हमारे पास आया था। हमारे पास पहुंचने से पहले, लगभग पांच टीमों ने इस पर काम किया, और उन्होंने एक सभ्य विरासत कोड जमा किया।

पिछली टीमों के साथ ग्राहक के संबंध साझेदार से बहुत दूर थे, इसलिए उसके साथ उसने स्वचालित रूप से एक आक्रामक स्थिति लेने और अविश्वास की दीवार के साथ खुद को बंद करने का फैसला किया।

संचार और विकास को गति देने के लिए, पहले प्रोजेक्ट मैनेजर ने क्लाइंट और टीम के लिए स्लैक कॉमन में चैट किया - एप्लिकेशन को हमारे द्वारा विकसित नहीं किया गया था और बहुत सारे सवाल उठाए थे, जो क्लाइंट को जल्दी से संबोधित करना था। ज्यादातर मामलों में, यह कार्यप्रणाली टीम के सदस्यों के बीच सूचना के हस्तांतरण को गति देती है, लेकिन हमारे ग्राहक ने खुद को चैट में या किसी विशिष्ट व्यक्ति में असभ्य टिप्पणी करने के अवसर से इनकार नहीं किया।

क्लाइंट ने व्यक्तित्वों की ओर रुख किया, जिसके परिणामस्वरूप खुले संघर्ष हुए और उनका नाम उन लोगों से भी सुना गया जो शामिल नहीं थे। नतीजतन, कंपनी ने कम से कम एक कर्मचारी खो दिया, जो इस रवैये के साथ नहीं रख सकता था, और कई और कुछ महीनों के बाद छोड़ दिया। छोड़ने के औपचारिक कारण अलग-अलग लग रहे थे, लेकिन हम कुछ जानते हैं।

जब ग्राहक पैसे से बाहर भाग गया, तो हम टूट गए। पैसा, यह ध्यान देने योग्य है, चला गया, जिसमें विरासत-संहिता के लिए समर्थन और कार्यक्षमता के लिए कार्यक्षमता का विकास शामिल है।

ग्राहक बाद में लौट आया। उन्होंने हमें आश्वस्त किया कि वह स्क्रैच से एप्लिकेशन विकसित करना चाहते हैं, पुराने कोड को छोड़ देते हैं, कार्यक्षमता को कम करते हैं और एक अलग शैली में संवाद करते हैं। हमने इसे स्वीकार कर लिया, लेकिन कुछ समय बाद कहानी खुद को दोहराना शुरू कर दिया।

क्लाइंट को हमारी रेटिंग और ऑफर पर भरोसा नहीं था। उनका अपना विचार था कि उत्पाद कैसे काम करना चाहिए। हमें इस बात की भी समझ थी कि कैसे किया जाए, लेकिन ग्राहक को तर्कों का अनुभव नहीं था और एक भागीदार के बजाय अनुप्रयोग विकास में विशेषज्ञता के साथ, उसने हमें केवल हाथों में देखा जो उसकी विशलिस्ट को जीवन में बदल देते हैं। हम उन कारणों को नहीं जानते हैं कि ग्राहक खुद को ऐसी स्थिति में क्यों रखता है और अटकलें नहीं लगाएगा।

स्थिति गर्म हो रही थी। अतीत में घटनाओं का विकास कैसे हुआ, यह याद करते हुए, हमने हमारे लिए एक असामान्य क्रम में प्राथमिकता दी: सबसे पहले, आपको टीम को बचाने की आवश्यकता है, और उसके बाद ही सफलतापूर्वक परियोजना को बंद करें और यदि संभव हो तो ग्राहक की वफादारी बनाए रखें।

जटिल ग्राहकों के लिए सुरक्षा रणनीति

अब हम उन तकनीकों पर एक नज़र डालते हैं जो हमें हमारे लक्ष्य को प्राप्त करने में मदद करती हैं, गलतियाँ जिन्हें आपको दोहराना नहीं चाहिए, और निष्कर्ष जो आप अपने काम में उपयोग कर सकते हैं।

डिजाइन का मूल्य स्पष्ट कीजिए

तो, परियोजना खरोंच से शुरू हुई। इस निर्णय के संदर्भ में, एक प्रस्ताव एमवीपी करने और फिक्स प्राइस मॉडल के अनुसार हमारे काम के लिए भुगतान करने के लिए उत्पन्न हुआ। यह तर्कसंगत लग रहा था, क्योंकि यदि किसी और का कोड नहीं है, तो इसके साथ कोई जोखिम नहीं हैं।

एक भुगतान मॉडल के रूप में फिक्स प्राइस का माइनस यह है कि यह लचीलेपन की परियोजना से वंचित करता है: जबकि कार्यक्षमता को कार्यान्वित किया जा रहा है, जो पार्टियां तकनीकी कार्य में सहमत हैं, बाजार बदल सकता है और काम का परिणाम अब वास्तविक उपयोगकर्ता समस्याओं को हल नहीं करेगा। एमवीपी को एक निश्चित मूल्य पर विकसित करना केवल तभी संभव है जब आपने पूरी तरह से और पूरी तरह से सभी परिकल्पनाओं का परीक्षण किया हो, तकनीकी विनिर्देश तैयार किए हों, और विस्तृत दस्तावेज लिखा हो। हमारे ग्राहक ने केवल डिजाइन की उपेक्षा की, या बल्कि, इसे खुद पर ले लिया।

चैट के लिए एक सेवा की पसंद के साथ कहानी सांकेतिक है। ग्राहक ने स्वयं संभावित तकनीकी समाधानों की जांच की, और हमें कई सेवाओं का विकल्प दिया: "कौन सा बेहतर है?" हमने सेवा ए को चुना क्योंकि यह एपीआई विधियों के एक सेट पर परियोजना के अनुकूल है, और विकास और एकीकरण के दृष्टिकोण से यह सेवा बी से बेहतर था। हमने सेवा को अपने बुनियादी ढांचे के साथ काम करने के लिए डिज़ाइन नहीं किया और इन औपचारिक मानदंडों के अलावा कुछ भी जाँच नहीं की: न तो स्थिरता , कोई प्रतिक्रिया गति, कुछ भी नहीं - कोई बजट नहीं था। अगर जाँच करने का समय होता तो चैट अधिक धीरे-धीरे जवाब देता।

“यदि आपको किसी कार्य को पूरा करने के लिए इसकी आवश्यकता है, तो आप इसे करने की भावना में मत पड़ो। आपको इसे अच्छी तरह से करना होगा! ”अगर ऐसे हैं: आउटसोर्सिंग के विकास का सार ग्राहक के पैसे के लिए ग्राहक की समस्याओं को हल करना है।

विश्लेषक को डिजाइन करना चाहिए। उनके पास वह ज्ञान है जो उन्हें स्पष्ट रूप से समझने और स्पष्ट करने की अनुमति देता है कि ग्राहक को अंतिम रूप से क्या चाहिए, और एक सामान्य सिस्टम आर्किटेक्चर का निर्माण करने के लिए: उत्पाद में क्या सेवाएँ होंगी, क्या तृतीय-पक्ष प्रणालियों के साथ एकीकरण हैं, कैसे अनुरोध सेवाओं के बीच जाते हैं, जहां जानकारी संग्रहीत की जाती है, कैसे। यह वितरित किया जाता है, आदि यह आवश्यक है, सबसे पहले, ताकि ग्राहक का उत्पाद जल्दी और मज़बूती से काम करे, और दूसरा, यह सलाह देने के लिए कि आप क्या बचा सकते हैं, और वास्तव में इसके लायक क्या नहीं है।

एमवीपी का अर्थ सभी के लिए समान बनाएं

MVP का हमारे लिए क्या मतलब है:

हम आवेदन की मूल कार्यक्षमता पर सहमत होते हैं और आदर्श से पॉलिश करते हैं, केवल उन विशेषताओं से जो इससे संबंधित हैं। अन्य विशेषताओं को काम करना चाहिए ताकि आवेदन को बंद करने की कोई इच्छा न हो;
हम व्यवसाय की समस्या को हल करने के लिए आवश्यक न्यूनतम कार्यक्षमता बनाते हैं, और कोई डिज़ाइन किया गया व्यवस्थापक क्षेत्र नहीं;
हम बाद तक अनुकूलन को स्थगित कर देते हैं, अर्थात, हम डिज़ाइन में ऐसे घटकों का उपयोग करते हैं जिन्हें कई स्क्रीन पर पुन: उपयोग किया जा सकता है, जटिल लेआउट तत्वों को मना कर सकते हैं और यदि आवश्यक हो तो डिज़ाइन को सरल बना सकते हैं।

लेकिन एमवीपी ग्राहकों की अलग-अलग व्याख्याएं हैं। यह हमारे लिए क्या मतलब था:

न्यूनतम पैसे के लिए न्यूनतम कार्यक्षमता।

भविष्य में, यह किसी तरह हुआ कि "कम से कम पैसा" बना रहे और स्थिति "हम जानते हैं कि यह कैसे करना है, इसलिए जैसा हम कहते हैं वैसा ही" जोड़ा गया।

इस तरह की स्थिति से सामान्य साझेदारी को खतरा होता है। खतरे को केवल डिजाइन और एक कार्यात्मक कार्य द्वारा हटाया जा सकता है, जो हर चीज को मंत्र देता है जो आवेदन करने में सक्षम होना चाहिए। क्या नई अप्रयुक्त आवश्यकताएं और सुझाव हैं? फेडरल लॉ का संदर्भ लें और समय खरीदने की पेशकश करें। हो सकता है कि यह औपचारिकता है और ग्राहक के बारे में नहीं, लेकिन यह आपकी कंपनी के संबंध में उचित है।

एक बार फिर: एमवीपी को डिजाइन के साथ फिक्स के साथ जोड़ा जाता है। हमारे पास यह नहीं था, लेकिन आपके पास यह होना चाहिए।

डेवलपर्स आपसे बहस करते हैं

और कभी भी क्लाइंट से बिना डिजाइन के काम नहीं करते, हमने कैसे काम किया।

डेवलपर्स सबसे अधिक बार बंधुआ होते हैं: जैसे ही कार्य निर्धारित किया जाता है, वे ऐसा करेंगे। लेकिन सीमित बजट वाली परियोजनाओं पर, प्रत्येक संभावित जटिल कार्य के कार्यान्वयन को इसे फ्लेक्स करने और समय सीमा को पूरा करने के लिए प्रश्न में बुलाया जाना चाहिए।

ऐसे कार्यों का स्रोत अप्रत्याशित रूप से डिज़ाइन था जिसे क्लाइंट-साइड डिज़ाइनर ने निपटाया। हमारे डेवलपर्स को बताया गया था कि यदि वे कुछ सुधारों के लिए कहते हैं, तो उन्हें तुरंत प्रस्तुत किया जाएगा, इसलिए हमने डिज़ाइन के स्थैतिक संस्करण के साथ काम करना शुरू नहीं किया, बल्कि फिगमा संपादक में, जहाँ यह डिज़ाइन बनाया गया था। डेवलपर्स ने एक मूल्यांकन दिया और काम करने के लिए मिला।

और फिर, डिजाइन में एक-एक करके, तत्व दिखाई देने लगे जो मूल रूप से नहीं थे - यह बैकअप से देखा जा सकता है, जिसे मैंने सिर्फ मामले में बनाया था। लेकिन विकास शुरू करने से पहले, यह जांचना असंभव है कि क्या डिजाइन का एक विशेष टुकड़ा बदल गया है - कम से कम क्योंकि डेवलपर एक सुविधाजनक क्रम में कार्यों को लेता है।

पहचानें विसंगतियों में मदद की है कि भाषण की स्वतंत्रता। डेवलपर मेरे पास आ सकता है और न केवल उन तत्वों को अपील कर सकता है जो जल्दी से नहीं बन सकते हैं, बल्कि ऐसे तत्व भी हैं जो क्लाइंट के डिज़ाइन में हैं - यह समझ में आता है, क्योंकि डिजाइनर ने खुद को गुप्त रूप से वहां पेश किया था - लेकिन हमारी कॉपी में नहीं। इन तत्वों को मूल्यांकन में शामिल नहीं किया गया था, जिसका अर्थ है कि हमें अपने स्वयं के खर्च पर उनसे निपटना नहीं चाहिए।

स्वस्थ विकास की दुनिया में, फिक्स प्राइस काम की मात्रा बढ़ाने और जाने पर स्थितियों को बदलने की अनुमति नहीं देता है।

क्लाइंट को टीम से दूर रखें

पिछली बार हमने डेवलपर्स और क्लाइंट को सीधे कनेक्ट किया था - ऐसी टीमें हैं जहां यह माना जाता है कि प्रबंधक को सबसे पहले शर्तों और बजट की निगरानी करनी चाहिए, न कि क्लाइंट आवश्यकताओं के ट्रांसमीटर के रूप में काम करना चाहिए।

यह अपने फायदे के साथ एक उत्कृष्ट कार्यप्रणाली है: प्रत्येक पक्ष की प्रतिक्रिया तेज है, टीम व्यवसाय के कार्य को बेहतर ढंग से समझती है, इसका अधिकार बढ़ता है, और प्रबंधक एक ट्रांसमीटर के रूप में नहीं मरता है। लेकिन यह जानकर कि ग्राहक व्यक्तिगत हो सकता है, मैंने उसे टीम से अलग कर दिया। केवल ग्राहक, खाता प्रबंधक और परियोजना प्रबंधक, अर्थात्, मैं चैट में रहा।

इसने हमें क्या दिया? मैंने संचार को मॉडरेट किया और व्यक्तिगत रिश्तों को काम की दिनचर्या में जहर नहीं डालने दिया। ऐसे क्षणों में जब क्लाइंट ने टीम की उनके तरीके से आलोचना की, मैंने जवाब दिया कि हम कार्रवाई करेंगे और कर्मचारी को दंडित करेंगे। टिप्पणियों से पता चलता है कि कुछ ग्राहकों को आश्वस्त करने के लिए, टीम के किसी व्यक्ति को मज़े के लिए भी बलिदान करना पर्याप्त है, इसलिए कर्मचारी शांति से काम करता रहा और उसे यह भी पता नहीं चला कि उसे दंडित किया गया था।

यदि आपको संदेह है कि ग्राहक बेचैन है, तो कम से कम थोड़ी देर के लिए उसके साथ टीम न लाएं, जब तक कि आप विपरीत के बारे में आश्वस्त न हों।

ग्राहक से टीम के लिए प्रतिक्रिया का सुधार करें

निरंतर अविश्वास और आलोचना के माहौल में, टीम अब उस फॉर्म में फीडबैक को संसाधित करने का प्रबंधन नहीं करती है जिसमें वह आता है, और ग्राहक यह सोचना शुरू कर देता है कि टीम केवल बुरे इरादों के साथ काम करने के लिए आती है - और उन्हें मूर्त रूप देती है।

इस प्रबंधक के साथ क्या करना है? कॉस्मेटिक संपादन को चोट नहीं पहुंचेगी: मैंने प्रतिक्रिया से व्यक्तित्व मूल्यांकन को हटा दिया, केवल अर्थ के नुकसान के बिना त्रुटि के शब्दों को छोड़ दिया। और चूंकि आपको क्लाइंट से कोई प्रशंसा नहीं मिलती है, इसलिए मैं टीम को अपनी प्रतिक्रिया देना नहीं भूलता - उन कार्यों के लिए जो सवाल नहीं उठाते थे, जिसका अर्थ है कि उन्हें क्लाइंट के दृष्टिकोण से अच्छा प्रदर्शन किया गया था।

यह था: “आवेदन भुगतान काम नहीं करता है। आपने क्या किया? "
यह बन गया: "दोस्तों, आवेदन में कुछ भुगतान करना है, ग्राहक इसे पता लगाने के लिए कहता है, यहां स्क्रीनशॉट हैं। और उन एनिमेशनों के साथ जो एक हफ्ते पहले पिछड़ गए थे, सब कुछ ठीक था। "

कीड़े प्राप्त करने के लिए जल्दी मत करो

क्लाइंट से प्राप्त होते ही कार्य प्रबंधक में बग दर्ज करना अनुभवहीनता से है। एक महत्वपूर्ण आंख के साथ सशस्त्र, प्रबंधक डेवलपर्स और एक परीक्षक के घंटे बचाने में मदद करेगा। बस क्लाइंट से बात कर रहा है या त्रुटि के लिए अग्रणी कार्यों को वापस खेलने और वीडियो रिकॉर्ड करने के लिए कह रहा है, आप समझ सकते हैं कि बग एक प्राथमिकता नहीं है या प्रकट नहीं हुआ है क्योंकि क्लाइंट कुछ गलत कर रहा था - और अब, आपको इसे संपादित करने की आवश्यकता नहीं है। इसलिए मैंने आने वाली बग्स के एक चौथाई हिस्से को बाहर निकाला, और एकीकृत सेवा समर्थन सेवा से संबंधित एक और हिस्सा - परियोजना पर पर्याप्त तृतीय-पक्ष एसडीके थे।

ग्राहक के नाम का उल्लेख न करें

शायद सबसे महत्वपूर्ण अंतर्दृष्टि। टीम के एक हिस्से की पुरानी मेमोरी के अनुसार, किसी ग्राहक के नाम को आवाज़ देना उसके पक्ष में किसी भी टिप्पणी के लिए एक पक्षपाती रवैया को उकसाता है, चाहे वह कितना भी पर्याप्त क्यों न हो। और मैं क्लाइंट को सिर्फ क्लाइंट कहने के साथ आया, जिसने नकारात्मक को कम कर दिया। ऐसा लगता है कि हर कोई समझता है कि वे किसके बारे में बात कर रहे हैं, लेकिन मेरा विश्वास करो - इस बारीकियों ने परियोजना की पारिस्थितिकी में सुधार किया है।

निष्कर्ष

स्पष्टता के लिए, मैंने "कैसे नहीं और कैसे करना है" के सिद्धांत पर उपरोक्त सभी को एक तालिका में कम करने का निर्णय लिया।

लेकिन हमारी सलाह आपके लिए एक उपयोगी होगी यदि आपकी कंपनी में आने वाले ग्राहकों के साथ काम करने के लिए जिम्मेदार व्यक्ति या खाता प्रबंधक बातचीत के चरण में ग्राहक की खामियों का खुलासा करता है।

यहां कुछ महत्वपूर्ण बिंदु दिए गए हैं, जिन पर अब हम ध्यान दे रहे हैं:

ग्राहक पिछले ठेकेदार के बारे में क्या कहता है, अगर वह था। यदि वह उसके बारे में नकारात्मक रूप से बात करता है, तो इस बात की संभावना है कि वह अपने अलावा किसी अन्य राय का अनुभव नहीं करता है और अपने फैसले लागू करेगा।
क्या क्लाइंट के पास आईटी में अनुभव है। अनुभव के साथ एक ग्राहक के लिए, विकास प्रक्रिया कम सवाल उठाती है।
वह हर पैसे के लिए मोलभाव करता है या नहीं। कम भुगतान करने की ग्राहक की इच्छा जितनी अधिक होती है, उतनी ही स्वेच्छा से और दृढ़ता से वह तर्क देता है।

मुझे उम्मीद है कि यह लेख किसी के लिए उपयोगी होगा। और यदि आप पहले से ही मेरी जगह पर थे, तो हमें बताएं कि आपने ऐसे कठिन ग्राहकों को कैसे हल किया।

जटिल ग्राहक: अपनी टीम को उनसे कैसे बचाएं