Як робити якісно і виправдовувати сподівання замовника | robot_dreams
Для відстеження статусу замовлення - авторизуйтесь
Введіть код, який був надісланий на пошту Введіть код із SMS, який був надісланий на номер
 
Код дійсний протягом 2 хвилин Код з SMS дійсний протягом 2 хвилин
Ви впевнені, що хочете вийти?
Сеанс завершено
На головну
Очікування клієнта vs реальність. Як робити якісно і виправдовувати сподівання замовника

Очікування клієнта vs реальність. Як робити якісно і виправдовувати сподівання замовника

Колонка Олександра Дьяченка, Senior Project Manager в ІТ-команді NIX

Усе частіше клієнти хочуть отримувати від співпраці не тільки якісний продукт чи послугу, але й приємні враження. Дослідження клієнтського досвіду доводить: проєктному менеджеру та всій команді потрібно намагатись постійно відповідати очікуванням замовника.

Гарна новина: для цього не треба читати думки — достатньо дотримуватися простих порад. Яких саме — читайте далі.

Запропонувати краще рішення ще не означає виконати очікування клієнта

Невиправдані очікування — це завжди розчарування. Неважливо, яких ситуацій вони стосуються: чи то ви прийшли в ресторан за рекомендацією, але сервіс виявився жахливим, чи то побачили вживу те, чим захоплювались на фото, але воно «не таке». Так трапляється і в ІТ. Якщо клієнт дав розробникам завдання, але не отримав бажаного, які б круті професіонали це не зробили, результат його не порадує.

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

Якщо замовнику не повідомити про всі ці нюанси та не сформувати правильні очікування, результат його не задовольнить. Причин може бути декілька:

  • клієнт не розраховував витрачати на це багато коштів;
  • або не хотів довго чекати на реліз;
  • або йому потрібна суто аналітика, щоби презентувати більш ефективне рішення в новій версії платформи та додатково заробити на цьому.

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

Це розчарує: помилки в управлінні очікуваннями

Непосильні обіцянки

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

Ігнорування можливих змін та ризиків

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

Недостатнє взаєморозуміння

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

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

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

Wow-ефект в очікуваннях

Коли він потрібен

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

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

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

Ситуація 2: Наша команда отримала запит від клієнта розробити мобільний застосунок для бігу, щоб користувачі слідкували в ньому за своїм самопочуттям та спортивним прогресом.

Рішення: Я почав займатись бігом, відстежуючи свої показники в цьому застосунку. Завдяки такому підходу ми отримали «‎польового тестувальника» всередині команди. У результаті краще почали розуміти замовника та змогли пропонувати більше покращень. Клієнт побачив, що до його проєкту ми ставимось як до власного. Це його приємно вразило, він високо оцінив нашу роботу та рекомендував нас своїм колегам.

Коли wow-ефект не потрібен

Якщо ваша основна ціль — перевищити очікування клієнта, ви ризикуєте не дати йому те, що дійсно потрібно. Замість якісного виконання завдання та намагання виправдати очікування ви будете думати, як здивувати замовника. Діяти треба послідовно. Першочергово клієнт має отримати бажаний результат.

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

Інструменти для управління очікуваннями. Ви їх точно знаєте і вже користуєтеся ними

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

Інструментів багато, тож можна підібрати зручний і зрозумілий клієнту навіть не з IT. Ми в NIX використовуємо Jira, але комусь із замовників програма може здатись занадто складною. Як варіант, пропоную ще Trello. Розглянемо ці та інші інструменти детальніше.

Jira

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

Переваги:

  • адаптація до проєктів майже будь-якої складності;
  • можливість роботи за методологіями Scrum або Kanban;
  • інтеграції з Gmail, GitHub, Outlook, Slack, Salesforce, Teams тощо;
  • розширений функціонал завдяки підтримці плагінів ProScheduler, Foxly Priorities, Issue Checklist та ін.

Недоліки:

  • складний інтерфейс;
  • тривалий процес налаштування під конкретні завдання.

Trello

Дозволяє створювати дошки для різних проєктів або завдань. Кожна дошка містить списки, які показують статус роботи. Теж продукт від компанії Atlassian.

Переваги:

  • просто створювати таски;
  • є мобільний застосунок;
  • широкий вибір мов, зокрема українська;
  • інтеграції з різними сервісами: Slack, Outlook, Gmail, Salesforce, InVision та ін.

Недоліки:

  • обмежене хмарне сховище;
  • незручно створювати рівні доступу до завдань всередині однієї команди.

Asana

Дозволяє впорядковувати завдання за списками, статусами, дедлайнами тощо. Ви можете ставити таски іншим членам команди, залишати коментарі та бачити прогрес кожної задачі.

Переваги:

  • простий інтерфейс;
  • інтеграції з Google Docs, Jira, Slack, GitHub, Evernote;
  • є дошка для візуалізації методології Kanban;
  • є мобільний застосунок, щоб зручно управляти тасками зі смартфона.

Недоліки:

  • обмеження у виборі типів файлів для експорту (JSON або CSV).

Notion

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

Переваги:

  • просто створювати таски та стежити за їхнім виконанням;
  • швидкий імпорт файлів;
  • є мобільний застосунок;
  • інтеграції з GitHub, Google Drive, Figma, Miro, InVision.

Недоліки:

  • командна робота доступна тільки в платній версії.

Не таск-менеджером єдиним

Є люди, котрі не мають часу або бажання слідкувати за всім, що відбувається в таск-менеджерах. Одним клієнтам зручніше зустрічатись у Zoom (наприклад, раз на 1–2 тижні) та отримувати звіт у форматі Excel. Для інших ознакою прогресу є демонстрація готового функціонала.

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

Насправді наше життя — гарний «тренажер», щоб навчитися розуміти очікування оточуючих. Щодня ми стикаємось із тим, що від нас щось хочуть різні люди: сім’я, друзі, колеги або випадкові знайомі. Чи завжди те, про що ви домовляєтесь у спілкуванні, збігається з кінцевим результатом? Ймовірно, ні. Тому моя вам порада: пробуйте різні підходи, аналізуйте та знову пробуйте. Краще розуміння того, що на думці в інших, приходить із досвідом. Так і в роботі з клієнтами. Детальніше вивчайте фідбеки, більше спілкуйтесь — і врешті зможете краще порозумітися та давати той результат, на який очікував замовник.

Ще статті
У два рази більше натхнення та інформації на другій онлайн-конференції від robot_dreams
Експертки про те, як оцінюють кандидатів на нетехнічних інтерв’ю