Перестаньте слухати клієнта, щоб зробити його щасливішим
Мене звати В’ячеслав Муха, я Software Engineer в MEV. Сьогодні на прикладі одного з кейсів нашої компанії я хочу розказати, як продуктова культура в аутсорсі може покращити процес онбордингу клієнтів, а відмова наосліп втілювати всі вимоги замовника — зробить його щасливішим, та на чому потрібно сфокусуватись, щоб в результаті вирішити бізнес-проблему.
Who is who в цій історії
Одного разу до нас, за рекомендацією свого товариша (нашого замовника), звернувся власник невеликої логістичної компанії у США, яка займається вантажними перевезеннями. З часом керівництво зрозуміло, що недоотримує значну частину прибутку — багато машин повертаються порожніми із кінцевої точки подорожі, а могли б додатково завантажуватися по дорозі назад. Однак для цього диспетчери мають своєчасно знаходили відповідний вантаж.
Тому, виникла ідея розробити платформу, яка б вирішувала ці завдання, а саме:
- активно моніторила доступні замовлення на перевезення вантажів;
- зіставляла ці замовлення з радіусом поточного місцеперебування вантажівки (або з місцем, куди вантажівка має доїхати);
- відправляла пуш-сповіщення диспетчеру або водієві про відповідні замовлення.
За наявних умов, перше, що спадає на думку — розробка мобільного застосунку. Власне, його клієнтові й пропонували інші компанії, до яких він вже встиг звернутись — проєкт на
Але, як казав мудрий дядько Дейв Воша:
«Уважно слухай клієнта, коли мова йде про проблему, проте перестань слухати, як тільки мова йде про реалізацію.»
Тож замість того, щоб швидше починати проєкти, білити клієнтів з першого дня і просто мовчки розробляти те, що нас просять, ми виділили час на детальніший аналіз домену і дослідження вимог.
Перші кроки — перевірка концепції
Традиційно, ми почали з перевірки концепції всього проєкту (PoC) та створення прототипного рішення. Чому це вдалий перший крок при роботі над проєктом?
- Ви перевіряєте, чи здійснена ідея замовника з погляду технології.
- Демонструєте клієнтові, що ви зрозуміли бізнес-проблему і знаєте, як її вирішити.
- Можете побачити загрози в процесі розробки, ще до початку активної стадії робіт.
- Синхронізуєтесь із замовником щодо бачення майбутнього продукту.
В нашому кейсі прототипом став telegram-бот та сервер, який зчитував GPS дані вантажівок і отримував заявки на вантажі. Маючи такий бот, ми отримали доступ до пуш-сповіщень користувача, чого було цілком достатньо для вирішення бізнес-проблеми. Таким чином, прототип змінив першочергову концепцію проєкту у вигляді розробки мобільного застосунку.
Подальша реалізація — фокус на швидкість та зворотний зв’язок
Швидкість — часто ключовий показник для бізнесу. І вона особливо важлива при старті розробки. Вже під кінець першого тижня роботи ми зарелізили першу, готову до використання фічу завдяки тому, що відразу сфокусувалися на важливому — функціоналі.
Для прикладу: навіть базу даних не підключали на ранніх етапах, а використали просто файлову систему. Проте застосували бібліотеку (tingodb), яка пропонувала MongoDB-like інтерфейс, що дало змогу без проблем переїхали на повноцінну MongoDB, коли була нагода.
Це все ілюструє два важливих моменти:
- не забуваємо про принцип KISS (Keep It Simple Stupid), особливо на ранніх стадіях розробки системи;
- тримаємо в голові big picture vision, стимулювати розробників спрямовувати архітектурні рішення в правильному напрямі, аби система завжди була в стані, готовому до змін.
Також значно пришвидшувала роботу над проєктом практика максимально коротких, по декілька разів на тиждень, релізів. Короткий цикл отримання фідбеків від замовника дозволяв оперативно вносити зміни.
Та, напевно, найкориснішими стали фідбеки реальних користувачів. Оскільки вже в перший тиждень систему почали використовувати в продакшені, ми отримали запити на фічі про які ніхто не задумувався на етапі початкового узгодження обсягу робіт. А більша частина узгодженого по SoW функціоналу виявилась непотрібною.
Last but not least — увага до беклогу
Логічно, що чим більше зворотного зв’язку ви отримуєте, тим швидше розростається беклог — під кінець роботи над проєктом кількість фіч, які з’явились на основі такого фідбеку, сягнула 70%. Тобто +70% до початкового скоупа робіт.
За таких умов можна піти різними шляхами. Можна просто робити більше фіч в одиницю часу, певною мірою жертвуючи при цьому якістю розробки. Можна збільшити час роботи над проєктом, оскільки нові таски не були заплановані з самого початку, але вони важливі для замовника. І в умовах аутсорсу, на перший погляд, це може видатись непоганою ідеєю, адже триваліший проєкт = прибутковіший проєкт. Та в контексті продуктової культури найбільш вірним видається шлях постійної пріоритезації беклога.
І коли ми говоримо про пріоритезацію беклога, то беремо до уваги два параметри задач: їх цінність та розмір (час, який буде потрібен на їхню реалізацію). Як співвідносяться ці параметри? Правильно, ніяк. Далеко на завжди фіча, розробка якої тривала умовний місяць, буде важливіша для користувача ніж та, яку запилили на тиждень. Детальніше про це можна подивитись тут.
Взято звідси: Agile Product Ownership in a Nutshell
Отже, знову закликаємо на допомогу наші комунікативні навички — щоб коректно пріоритезувати беклог, нам доведеться постійно спілкуватись із замовником та уточнювати, що саме наразі є необхідним.
Happy End
На початку статті ми говорили про те, що відмова наосліп втілювати всі вимоги замовника може зробити його щасливішим. То чи вдалось цього досягти? Думаю, кращою відповіддю на це питання проілюструє той факт, що ми змогли розв’язати проблему клієнта за 2 місяці, замість
Та й для нас ця історія закінчилась не просто успішним кейсом в портфоліо, але і новим клієнтом — за деякий час за рекомендацією задоволеного власника логістичної компанії до нас звернувся новий замовник.
Висновки
- Розпочинайте з аналізу та проєктування прототипу рішення. Це показує, чи ви зрозуміли завдання бізнесу та зможете його вирішити. А у більшості випадків — це ще й суттєво пришвидшить підписання контракту.
- Рухайтесь швидко, але тримайте в голові big picture vision. Не варто інвестувати купу часу на сетап процесів та інструментів, які хоч і зручні та пришвидшують розробку, та все ж не виправдані на ранніх стадіях, особливо для невеликих проєктів.
- Прагніть до швидкого фідбеку. Не завжди вдається одразу зрозуміти клієнта повною мірою, та й клієнт не завжди досконало розуміє, що йому потрібно. Короткі ітерації в реалізації проєкту дозволять уникнути цих непорозумінь. А в ідеалі, якщо особливості проєкту це дозволяють, варто дати слово реальним користувачам якомога швидше. Саме вони найкраще пояснять, що саме потрібно продукту.
- Не забувайте про принципи Agile. Зокрема в тому, що особистості та їхні взаємодії важливіші, ніж процеси та інструменти, а співпраця із замовником важливіша, ніж контрактні зобов’язання.
- Тримайте в фокусі постійну пріоритезацію беклогу. У форматі швидкого ритму та великої кількості зворотного зв’язку доводиться постійно уточнювати пріоритезацію, комунікуючи з клієнтом, над чим потрібно працювати саме зараз, а що може зачекати, враховуючи цінність задач та вартість їх реалізації.
58 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів