Когато някой поиска проект, трябва да приемем, че той е много важен и че той много се грижи за продукта, по който ще работите. Така че е безопасно да се предположи, че клиентът е длъжен да изгради много очаквания около крайния продукт и следователно може да стане емоционален, когато става въпрос за доставка.

По време на проекта клиентът може да се развълнува супер за доставената функция и да ви обича, а на следващия ден може да открие, че нещо не работи и тази привързаност ще изчезне. По-често това е въпрос на объркана комуникация с клиенти.

Въпреки че няма рецепти за успех, когато става въпрос за дистанционно разработване на софтуер , Вярвам, че има няколко неща, които трябва да се избягва да поддържате здравословни и продуктивни взаимоотношения с клиенти, които са ви доверили толкова много доверие.

Не се проваляйте в основната комуникация с клиенти

Представете си комуникацията с клиенти, както бихте общували всеки ден с колеги, приятели или друг човек, към когото бихте отправили учтивост.

Ако стар приятел посещава дома и се съгласите да се насладите на местния деликатес „на старото си място“ по обяд, няколко седмици по-късно, бихте ли се появили там? Бихте ли поддържали връзка междувременно, обадете се, за да потвърдите няколко дни предварително? Или може би бихте предположили, че са твърде заети и не биха искали да ги притесняват без основателна причина? Бихте ли очаквали те да ви уведомят, когато пристигнат?

Вероятно няма да продължите да чатите всеки ден, освен ако не сте го направили много за да говорите, но ще поддържате някаква форма на комуникация, като въпрос на учтивост и практичност: Не искате другият да мисли, че сте забравили за тях, но определено не искате да шофирате наполовина през града без добра причина.

В даден момент вероятно сте преживявали подобни ситуации и в професионалната си комуникация, дори с дългогодишни партньори и колеги. Някои проекти се изпълняват с минимална комуникация, точно като да се каже „обичайното, на обяд, ще се видим там“, за да се потвърди лек обяд. Дори и да се появи нещо, отсрещната страна със сигурност ще ви уведоми и вие ще се съгласите да разсрочите.

Нещата обаче не са толкова прости или линейни в света на разработването на софтуер.

Ако започнете да работите по проект, особено когато имате работа с нов клиент, ако той никога не се чуе от вас, те ще започнат да се замислят за вашата работа и ангажираност. Дори ако се появите с безупречен продукт след няколко седмици, клиентите може вече да имат по-малко от идеалното възприятие за вас.

Въпреки че понякога е задължително да се чувствате неловко, не боли да говорите с клиента, дори ако нямате нищо необичайно за докладване! Имате ли съмнения относно една малка точка от потребителска история? Ако смятате, че е важно, уведомете ги. Закъснявате малко и не сте сигурни дали ще успеете да спазите прогнозната дата, за която сте се договорили? Обадете се на клиента възможно най-скоро! По-добре да чуят за това веднага.

Нямате никакви съмнения и проектът е напълно в съответствие с графика, но клиентът не говори много? Защо просто не изпращате имейл, описващ напредъка ви на всеки няколко дни? Това няма да навреди, защото имейлите няма да досаждат на никого, освен това ще документирате напредъка си и ще поддържате редовна комуникация с клиента.

Неправилната комуникация с клиенти насърчава нереалистични очаквания

И така, в началото споменах, че клиентът ще има много очаквания за проекта, нали? Нали. Месечен цикъл.

Клиентът вече очаква много от продукта. Ако не върви по начина, по който са си представяли, клиентите неизбежно ще бъдат разочаровани. И така, защо някой да обещава повече, отколкото може да достави, като по този начин създава още по-нереалистични очаквания?

Ето един бърз паралел: Купили сте таблет онлайн и сте обещали 10-дневна доставка. На 8-ия ден магазинът ви съобщава, че има проблем, и забавя доставката със седмица. За да ви компенсират за неудобството, обещанието на търговеца ви дава кредит от 75 долара в магазина.

Вероятно не сте наистина ли така или иначе имате нужда от тази таблетка за следващите няколко дни, така че смятате, че е добра сделка! Сега можете да се насладите на таблета, плюс използвайте кредита от магазина, за да купите на децата си нещо хубаво. Но магазинът се обажда на следващия ден, казвайки, че всичко е подредено за една нощ.

Ще получите таблета на следващия ден. Без екстри, без кредит в магазина. Сега е Вие това е разочаровано!

'Какво? Точно вчера ми каза, че ще имам по-добра сделка! Не е честно! Вече казах на децата ... “

Превъртете няколко дни назад и така или иначе очаквахте само таблета. Ако никой не ви обеща по-добра сделка, щяхте да останете доволни от вашата играчка, когато пристигне на следващия ден. Но сега се чувствате сякаш пропускате без основателна причина, освен решението на магазина да ви уведоми.

Как разработчиците, особено на свободна практика, могат да избегнат подобни ситуации в комуникацията си с клиенти?

Като не полудявате и казвате всичко, което първо ви хрумне. Предложенията не са забранени; всъщност са много добре дошли, ако смятате, че конкретна заявена функция не е много добра възможност за решаване на проблема. Но ключът е: Помислете първо.

• Слушайте клиента.

• Анализирайте техния проблем.

• Анализирайте предложеното решение.

• Уверете се, че е в рамките на бюджета / графика.

• И накрая, продължете и представете вашето предложение.

Ето защо уменията за комуникация с клиента могат да бъдат трудни, тъй като ако не успеете само на една от първите четири стъпки, в крайна сметка може да загубите времето си и, което е още по-лошо, времето на клиента си.

Не предполагайте, че знаете какво е необходимо на клиента

Перифразирайки Мери Шмич , Дами и господа от класа на ‘17: Слушайте клиента. Ако можех да ви предложа само един съвет за в бъдеще, слушането на клиента би било това.

Ако сте били призовани за проект, това е защото някой има нужда от нещо. И кой би знаел по-добре за тази необходимост от вашия клиент? Може да изглежда очевидно, но понякога в реалния свят хората го забравят.

Позволете ми да ви дам пример. Търговец на дребно иска „софтуерна система“ за своя бизнес. Веднага щом го видите, стигате до заключението, че това, което те искат, е нещо, за да регистрирате всички налични продукти, да запишете всяка направена покупка, да генерирате разписки за клиенти и да докладвате за това какво е продавано периодично и за кои артикули изчерпват наличност.

И така, на първата си среща искате да покажете, че сте ефективни, и да им представите какво сте подготвили, предложените функции, основен дизайн, който да съответства на визуалната идентичност на магазина и всичко останало. Но тогава озадаченият клиент казва, че всъщност това, от което се нуждаят, е алгоритъм за изчисляване на по-доброто излагане на продуктите на рафтовете, целящ да събере приходи за конкретни марки и продукти!

Грешката тук просто не е идентифицирала какъв проблем трябва да решите. Разбира се, в този случай, тъй като беше много рано в проекта, щеше да има достатъчно време, за да се оправи, но понякога този вид грешка се случва и по-нататък. Дори това не може да бъде толкова драстично, както в предишния пример, пак може да навреди на проекта и / или отношенията ви с клиента.

Моето предложение е следното: Говорете с бъдещите си потребители, много, ако е възможно, и се консултирайте с различни заинтересовани страни в проекта. Те са тези, които имат добър преглед на ситуацията и знаят от какво се нуждаят. Опитайте се да разберете какво правят в момента на всяка стъпка и да обясните как софтуерът би бил полезен. Обичам да казвам, че когато се опитвам да разбера какво желае клиент, целта ми е почти да мога да изпълнявам работата си сам. Ако се доближите до този момент, тогава наистина сте разбрали какви са техните нужди.

Неразбиране за какво иска клиентът

Не е необичайно да получите някаква документация за разглеждания проблем. Понякога това е просто описание на високо ниво, докато друг път е подробен документ със случаи на употреба и бизнес правила. Във всеки случай, колкото и да са ясни записите, единственото нещо, което не можете да направите, е просто да приемете, че всичко написано там е абсолютната истина.

Какво???

Точно. Първо, нещо може да означава едно нещо за някого, в определен контекст, и съвсем различно нещо за хора, които не принадлежат към тази реалност. И ако има нещо, което вие и клиентът нямате общо, това е контекстът!

Второ, не всеки е много опитен писател; те се опитват да кажат A, но в крайна сметка описват B.

И така, след като прочетете всичко, което сте изпратили, как ще бъдете сигурни, че това, което сте прочели, е всъщност това, което са имали предвид? Е, ще смилате всичко, ще си направите бележки, ще анализирате всичко и ... свикайте среща . (Виждате ли? Всичко е свързано с комуникацията!) На срещата ще говорите за проблема и ще опишете това, което сте разбрали със собствените си думи. На този етап вероятно ще можете да установите всяко недоразумение.

„О, но в моя случай не получих никакви документи. Просто седях с клиента и те ми обясниха всичко, докато си правех бележки ”.

Е, все още няма гаранция, че сте разбрали какво означават те и моето предложение все още стои: Отделете малко време с бележките си, помислете за целия проблем, организирайте всичко, за предпочитане в някакъв график на събитията и след това се обадете / срещнете отново с клиентът да представи това, което сте разбрали. Може да ви звучи повтарящо се, но понякога дори клиентът няма пълна визия за всички участващи процеси за изпълнение на определена задача и след това ще види колко сложен трябва да бъде софтуерът.

В крайна сметка трябва да сте сигурни, че няма двусмислие или неразбиране.

Защо не трябва да доставяте всичко, което клиентът иска, без да мислите

Добре, сега, след като знаете, че трябва да изслушате клиента и да потвърдите това, което сте разбрали, можете просто да продължите и да направите всичко, което са ви помолили, нали?

Грешно!

Сега е моментът, в който най-накрая можете да използвате целия опит, който имате, и да се запитате: Това, което клиентът ви помоли, ще решите ли проблема им? Това, което те попитаха, наистина ли е необходимото им?

Ще се изненадате да видите колко пъти отговорът е „не“.

Преди просто да доставим това, което клиентът е поискал, трябва да анализираме проблема и, ако не сте съгласни с това, което е предложил работодателят, тогава вашата работа и професионална отговорност са да изясните това. Разбира се, тогава трябва да обясните защо смятате, че предложението им не е добро и какво ще направи алтернативният ви подход за отстраняване на тези недостатъци. Отново комуникацията е ключът.

Ако вие и клиентът сте разумни, тогава или ще продължите с решението си, или ще проведете мозъчна атака, за да излезете с по-добро (в случай че идеята ви не е била приемлива за клиента по някаква причина).

Прототип - Не пишете обширна документация

Вече казах, че вие ​​и вашият клиент обикновено нямате еднаква перспектива, нали? Следователно, както се отразява на разбирането на тяхната документация, така и на разбирането им за това, което предоставяте в писмена форма. Това също е въпрос на контекст.

Така че, съгласен съм, че по някакъв начин (на по-високо или по-ниско ниво), ние трябва да документираме какво предстои да развием. Но предаването на няколко страници текст без никакви визуални елементи няма да ви помогне много. Клиентът ще се отегчи от четенето му, ще спре да обръща внимание и вероятно няма да може да разбере какво имате предвид под тези сложни бизнес правила - или ще тълкува нещо съвсем различно от това, което сте си представяли.

Имайте предвид, че тези недоразумения могат да бъдат още по-лоши, ако клиентът няма технически опит.

Всички тези фактори могат да доведат до един и същ проблемен резултат: Клиентите ще се оплакват, когато доставяте продукта, защото вероятно няма да е това, което са имали предвид.

Ето какво предлагам: Винаги прототип, дори ако това е само скица, за да нарисувате какъв е вашият план. И каквито и определения да трябва да направите, започнете от там. Направете справки и се опитайте да го направите просто.

Спрете да губите време, убеждавайки клиента, че сте прав

Почти мога да съм сигурен, че всеки разработчик е преживял следната ситуация: В началото на проекта, казва клиентът „Трябва ми цветът на фона на софтуера да е жълт. Вече е договорено от борда. ' След това, когато софтуерът е доставен, те казват „О, но цветът на фона не може да бъде жълт. Казах ти, че трябва да е зелено! ” Сега, как трябва да се справите с това?

Със сигурност при всички случаи няма да е от полза просто да настоявате, че сте били прави и те са грешили. Ако не друго, това просто ще затрудни както вас, така и клиента.

Винаги е добре да имате добър запис на комуникация с клиента, само за да сте сигурни, че сте на една и съща страница и оставите писмена следа. В повечето случаи, ако е нещо просто, можете просто да изпратите имейл на клиента, казвайки, „Както се договорихме на тази среща, фонът на системата ще бъде жълт.“ И ако в бъдеще клиентът промени мнението си, можете да твърдите, че сте го направили поради тази среща, спомената в имейла, но ако тази промяна наистина трябва да бъде направена, можете да я изпълните за допълнителни x часа (а понякога и допълнителни х долара).

Но ако няма нищо, което да докаже, че сте били прави, тогава вероятно ще трябва да вземете решение (както и урок, който да научите): Толкова голяма ли е промяната, която ще изисква промяна в текущата архитектура или ще засегне други функции? Ако не, вероятно е най-добре да продължите, да го направите и да приведете клиента до себе си (но с широко отворени очи, за да не се повтори). Ако го направи, тогава разговорът с клиента ще бъде най-доброто решение; нито един, фокусиращ се върху „Как беше прав“ но нататък „Как можем да решим текущия проблем.“

Във всеки случай най-добрият начин да се предотврати налагането на големи модификации е да се предоставят кратки нови функции за кратки периоди от време. Следователно, ако нещо трябва да се промени, това вероятно няма да бъде значителна трансформация на това, което вече съществува.

Знайте кога да се ангажирате със срокове

И накрая, но не на последно място, една от най-големите грешки, които можете да допуснете, е да дадете на клиента си краен срок, за да завършите проекта. И те ще ви помолят да направите тази грешка!

Разбира се, като клиент искате да знаете кога ще можете да използвате всички онези приятни функции, които обсъждате през последните седмици (месеци?). Но тъй като даден проект не е дефиниран продукт, много неща могат да се случат от момента, в който разработката започне, докато софтуерът е готов за използване.

На първо място, не може да се предскаже непредсказуемото. Много е вероятно да се наложи да се справите с нещо, което не сте очаквали. Това може да е лиценз, обещан от клиента, който не е закупен навреме, или някакъв друг вътрешен софтуер, който трябва да използвате, но не е издаден, когато е трябвало да бъде, или средата е различна от тази, за която се е съгласил в началото, или клиентът промени мнението си за (няколко) функции и трябваше да повторите няколко неща.

Нищо от това всъщност не е вина на разработчика и може да повлияе дълбоко на срока на проекта. Но ако вие, желаещи да угодите на клиента, обещахте, че ще доставите всичко до някаква дата и в крайна сметка, поради всички правилни причини, без да го правите, едно нещо мога да гарантирам, че клиентът ще бъде поне малко , разочарован. Ако сте на свободна практика, трябва да управлявате времето си ефективно, тъй като това В статията на ApeeScape Engineering Blog се обяснява . Не забравяйте, че управлението на взаимоотношенията с клиенти е и вашата работа.

Така че, направете услуга на себе си и на този, който зависи от проекта, и поне им дайте оценка колко време ще отнеме да се развие всичко, но винаги да стане кристално ясно, че това е само оценка, а не краен срок.

Също така настоятелно препоръчвам (особено ако вече сте дали оценка) винаги да казвате на клиента, когато нещо отнема повече време от очакваното, за да може той да ви помогне!

Разбиране на основите

Как да подобря комуникативните умения?

Учете се от грешките си и се фокусирайте върху поддържането на професионална комуникация през цялото време. Попитайте клиенти и колеги за обратна връзка и очевидно продължете да четете статии като тази, в случай че имате нужда от няколко съвета.

Какво е ефективна комуникация?

Просто казано, всяка комуникация, която предава съобщението с възможно най-малко усилия, е ефективна комуникация. Клиентите ценят кратката, точна комуникация, а не пух, който им губи времето.

Какво представлява вътрешната комуникация?

Вътрешната комуникация е комуникация между и вашите колеги, участващи в проекта. Тази статия се фокусира върху комуникацията с клиенти, но комуникацията между екипи по съвместни проекти е също толкова важна за вашия успех.

Как да се справим с трудни клиенти?

Спокойно и професионално. В момента, в който осъзнаете, че клиентът може да бъде труден, направете всичко възможно, за да прекалите комуникацията, да документирате всичко и да предотвратите потенциални спорове. Профилактиката е вашият най-добър начин на действие.