Робота з клієнтами: чому ваші ІТ-рішення не задовольняють замовника

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

Чому так відбувається?

Реальність така, що зараз як соло-підприємці ми маємо бути одночасно маркетологами, психологами, бізнес-аналітиками та проєктними менеджерами. Технічна майстерність — це лише один інструмент у наборі, який потрібен для створення продукту, що реально вирішує проблеми бізнесу.
Уявіть собі лікаря, який одразу призначає ліки, не запитавши, що у вас болить. Абсурд, правда? А в ІТ саме так часто і відбувається. Клієнт каже «мені потрібен сайт», а ми замість з’ясування реальної проблеми починаємо обговорювати React чи Vue.

Що дає досвід роботи з людьми програмісту
Як мені допоміг мій бекграунд у продажах? Перше і головне, що я засвоїла, працюючи в туризмі, а потім у логістиці — це вірно виявити потреби клієнта і запропонувати йому оптимальне рішення наявної проблеми.
Без глибокого розуміння процесів у компанії клієнта на жаль вийде не корисний продукт, а третя нога, яка замість розвантаження буде додавати ще більше роботи. Я бачила це незліченну кількість разів: красива система, яку ніхто не використовує, бо вона не вписується в реальні робочі процеси.
Найгірше, що може статися — це коли ви створюєте “технічно правильне” рішення, яке ніхто не використовує. Клієнт платить гроші, ви витрачаєте час, а в результаті всі незадоволені. І справа не в тому, що код поганий. Справа в тому, що ви вирішували не ту проблему.
Аналіз бізнесу клієнта: з чого почати
Так з чого почати роботу з новим клієнтом? Ось кілька важливих моментів, які я виділяю для себе при першому спілкуванні:
    1.    Загальна структура бізнесу клієнта.
Скільки людей працює, які відділи є, хто за що відповідає. Це дає розуміння масштабу і складності майбутньої системи.
    2.    Кінцевий результат — що має клієнт на виході.
Чи це готова продукція, чи послуга, чи звіти для регуляторів. Розуміння кінцевої мети допомагає побудувати логіку системи від результату до процесу, а не навпаки.
    3.    Які вихідні дані є у клієнта.
Excel-таблиці, паперові журнали, дані з інших систем, API зовнішніх сервісів. Це визначає, звідки ми братимемо інформацію і як її інтегрувати.
    4.    Виділення основних процесів у фірмі та їх взаємозв’язків.
Тут часто криється підступ — процеси, які здаються окремими, насправді тісно пов’язані між собою. Ігнорування цих зв’язків призводить до того, що система працює, але не так, як потрібно.
    5.    Процеси, які потребують найбільше мануальної праці.
Це ваші точки максимального впливу. Автоматизація процесу, на який витрачається 20 годин на тиждень, дасть набагато більший ефект, ніж оптимізація того, що займає годину на місяць.
    6.    Часто повторювані процеси.
Якщо щось робиться кожен день по 50 разів — це ідеальний кандидат для автоматизації. Навіть економія 30 секунд на операції дасть годину економії на день.
    7.    Наявність паттернів і шаблонних дій.
Люди часто не усвідомлюють, що їхня робота складається з повторюваних шаблонів. Ваше завдання — їх побачити і автоматизувати.
    8.    Бажаний результат — що клієнт хоче отримати на виході.
Увага: це не завжди збігається з тим, що йому насправді потрібно. Клієнт може казати “мені потрібна CRM”, а насправді йому потрібен спосіб не втрачати заявки від клієнтів.
    9.    Аналіз процесів і оптимальне налаштування з максимальною редукцією ручної роботи.
Тут ви вже синтезуєте всю зібрану інформацію і пропонуєте рішення, яке реально вирішує проблему, а не просто виконує технічне завдання.
Звісно, цей чеклист є дуже приблизним, але саме розуміння того, як побудовані процеси, дає можливість створити клієнту продукт, який дійсно буде корисним.
Чому комунікація важливіша за код?
Тому що комунікація — це база, яка часто визначає якість продукту, який ви створюєте. Не ваші знання фреймворків, не вміння писати чистий код, не досвід роботи з хмарними сервісами. Все це важливо, але вторинно.
Ви можете бути генієм програмування, але якщо створюєте не те, що потрібно клієнту, ваш геній марний. І навпаки — навіть посередній код, який вирішує реальну проблему, принесе більше користі та задоволення.
Більшість конфліктів з клієнтами виникає не через технічні помилки, а через різне розуміння завдання. Клієнт очікував одне, ви зробили інше, і обидві сторони праві зі свого погляду. Єдиний спосіб уникнути цього — детально обговорити та зафіксувати всі очікування на початку.
Інвестуйте час у спілкування з клієнтом до початку розробки. Задавайте дурні питання. Перепитуйте очевидні речі. Малюйте схеми процесів. Показуйте прототипи та мокапи. Витрачайте час на те, щоб переконатися, що ви розумієте завдання однаково.
Показуйте проміжні результати якомога частіше. Не чекайте, поки все буде ідеально. Покажіть навіть напівготовий прототип — це допоможе переконатися, що ви рухаєтесь у правильному напрямку.
Висновок
Технічні навички — це необхідна, але недостатня умова успіху в ІТ. Вміння розмовляти з клієнтами, розуміти їхній бізнес, виявляти реальні потреби та пропонувати оптимальні рішення — це те, що відрізняє хорошого спеціаліста від посереднього.