Як пояснити клієнтові, що він неправий, rusbase

Роман Артюх, виконавчий директор компанії «Латера» (розробник білінгу «Гідра») - про те, як знайти спільну мову, якщо ви розробляєте складний ІТ-продукт, а клієнт впевнений, що і сам все знає куди краще.

Щоб домогтися успіху, необхідно створювати продукти, які будуть вирішувати завдання клієнтів. Однак цього мало, потрібно ще й організувати процес спілкування з клієнтами таким чином, щоб збирати їх побажання і враховувати їх. Це не так просто в разі складних продуктів, які використовують середні і великі компанії - наприклад, це біллінгові системи або інструменти управління бізнес-процесами підприємства. Побажання замовника можуть бути дуже складними в реалізації, а віддача від них -неочевідной.

Сьогодні ми поговоримо про те, як слід взаємодіяти з користувачами таким чином, щоб не довелося робити свідомо непотрібні «фічі», при цьому не жертвуючи відносинами із замовником.

«Я б дещо змінив»

Клієнт завжди переконаний, що його ідея дійсно хороша - це цілком зрозумілу поведінку людини. Особливо часто таке зустрічається у невеликих замовників.

Наприклад, в ситуації, коли клієнт впевнений, що потрібно доопрацювати продукт, а розробники розуміють, що це помилка, є два виходи. Піти на поводу у клієнта або переконати його. У нашому досвіді мали місце обидва варіанти - ось, що з цього виходило.

Клієнт завжди правий (с)

Технічним фахівцям, провідним проект, частіше за все не хочеться сперечатися з клієнтом. Дійсно, чому б і не погодитися на доопрацювання, аби замовник залишився задоволений, а компанія отримала гроші без зайвих проблем? Основна причина, чому не варто так робити - позбавлення від невеликої головного болю сьогодні може призвести до великих проблем завтра.

Приклад з нашої практики розробників білінгових систем. У одного фізичного абонента будь-якого оператора зв'язку може бути кілька договорів, наприклад, для різних квартир або послуг.

В результаті замовник був незадоволений і постійно просив все нові і нові доробки, які, по суті, були «милицями» для підтримки спочатку нефункціонального рішення.

Цього вдалося б уникнути, якби ми на самому початку проявили твердість і зуміли пояснити клієнтові, до чого призведе його бажання.

Як пояснити клієнтові, що він неправий ...

Як правило, великі замовники завжди хочуть приблизно одного і той же, тоді як спектр побажань невеликих клієнтів може бути вкрай широким - і самі трудомісткі і неефективні доопрацювання вимагають саме вони. Вплутуватися в цей процес для розробників вкрай ризиковано.

Невеликі компанії часто не надто стійкі, тому велика ймовірність, що проект, наповнений «космічними» побажаннями, взагалі не буде завершений, тому що його замовник на середині шляху просто розориться - в нашій практиці траплялося і таке інше.

Тому тепер в ситуаціях з вимогами нестандартних доробок ми пропонуємо спочатку впровадити продукт з мінімальною необхідною функціональністю, а після додати необхідні функції. Як правило, після закінчення вступного періоду ніхто не просить фантастичних доробок - стає зрозуміло, що система і в поточному вигляді може вирішувати потрібні завдання.

Тут є ще один важливий момент - незважаючи на те, що розробники продукту знають його досконально, клієнт завжди розуміє свій бізнес краще. І якщо одну і ту ж доопрацювання просять здійснити кілька різних замовників, то, можливо, в цьому є сенс.

Роздуми на цю тему стали однією з причин організації відкритого форуму користувачів нашого білінгу. Так нам вдалося вбити відразу декількох зайців. На форумі користувачі можуть отримати відповідь на типовий питання по роботі з системою від інших її пользовтелей без необхідності звернення в техпідтримку.

Другий важливий момент - на цьому майданчику користувачі продукту обговорюють свої ідеї щодо його доопрацювання. Якщо ідея виявиться стоїть - це відразу стане ясно в ході обговорення. Якщо ж пропозиція явно невдало, то його мінуси користувачеві пояснити не розробники, які «просто не хочуть слухати», а такі ж клієнти, як і він сам.

Не давайте сумніватися в своїй експертизі

На те, щоб зрозуміти, як саме слід будувати взаємодію з користувачами такого складного продукту, як білінг, у нас пішов не один рік. На цьому шляху ми зробили багато помилок. І ось що зрозуміли.

Замість того, щоб йти на поводу у «хотелок» замовників або, навпаки, намагатися їх переконати, простіше створити інструмент для збору та оцінки побажань самим співтовариством користувачів.

Це дозволяє відібрати справді вартісні ідеї і уникнути негативу, що виникає при відмові від реалізації запитуваних доробок.

Крім того, щоб довіри думку розробників було більше, їх продукт повинен бути по-справжньому якісним і працювати без збоїв. Додають позитивних емоцій і більш вигідні, порівняно з конкурентами, пропозиції по роботі з системою.

Наприклад, так як багато розробників біллінгів продають ліцензії на поновлення за окремі гроші, ми вирішили надавати їх безкоштовно.

Також дуже важлива відкритість - каналів для спілкування з користувачами і збору зворотного зв'язку повинно бути якомога більше.

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

Потрібно знижувати «тертя»

Зрозуміти, чи підходить компанії складний ІТ-продукт, можна тільки попрацювавши з ним якийсь час. Однак навіть його розгортання в тестовому режимі - складний технічний процес, що вимагає роботи інженерів. Тому провести таке впровадження безкоштовно розробники часто просто не можуть собі дозволити.

Клієнтів лякає перспектива заплатити за впровадження системи, яка їм може не підійти. В результаті вони наполягають на тому, щоб безкоштовно провести таке впровадження. Зняти цю стурбованість можна, запропонувавши їм, в разі позитивного рішення, після завершення тестування врахувати виплачену суму в рахунок майбутніх послуг - наприклад, надання платної техпідтримки.

Крім того, при впровадженні складного продукту попрацювати доводиться як його розробнику, так і замовнику. Фахівці замовника повинні надавати доступи до систем і допомагати, наприклад, з потрібними для роботи даними.

Те, що потрібно не тільки заплатити за впровадження, але ще і активно в ньому брати участь, також не всім подобається - це може призводити до виникнення суперечок про вартість роботи.

«Знешкодити» ситуацію можна ще одним способом. Часто в таких ситуаціях ми говоримо, що проведемо роботу безкоштовно, якщо з боку замовника не буде типових помилок, які подовжують і ускладнюють весь процес. Ще жодного разу працювати безкоштовно не довелося: типові помилки роблять абсолютно всі замовники.

Головне: не треба сперечатися

Одне з головних правил спілкування з клієнтом, яке ми виробили за багато років - клієнт не завжди правий, але сперечатися з ним не варто. Якщо замовник щось хоче, і це може бути реалізовано - питання в ціні. Кінцева цифра змушує задуматися, а чи потрібно побажання виконувати.

Деякі замовники після початку роботи зі службою підтримки починають вимагати, щоб на їх дзвінки і листи відповідав певний інженер, з яким вони вже вирішували робочі питання. Приставити виділеного інженера до кожного клієнта ми не можемо фізично, але якщо комусь це просто необхідно, то чому б і ні - однак за це потрібно буде заплатити. У підсумку ми ввели нову тарифну опцію - «персональний інженер».

Коли клієнт бачить, що в принципі може отримати те, що хоче, це знімає негатив. Інша справа, що в кінцевому підсумку платити за не самі критичні речі готові далеко не всі.