Ми шість тижнів будували не той продукт
Ми шість тижнів будували не те. Клієнт ніколи не скаржився. У цьому і була проблема.
Справа не в інструментах чи лайфхаках для продуктивності. Справа в жорстокій правді.
Клієнт із галузі охорони здоров'я попросив нас створити систему запису пацієнтів. Ми ставили запитання. Ми кивали. Ми почали розробку.
На шостий тиждень ми показали їм демо-версію. Клієнт замовк.
Вони сказали: «Це чудово. Але записи на прийом роблять не медсестри, а координатори страхових компаній. Їхній робочий процес інший».
Ніхто не брехав. Ніхто не помилився в комунікації. Ми просто не запитали, хто саме користуватиметься програмним забезпеченням щодня.
Найдорожчий код — це той, що вирішує не ту проблему. Найгірший код — це не той, що вилітає з помилкою. Це код, який працює ідеально, але нічого не вирішує.
Ось наші найбільші помилки:
- Ігнорування портрета користувача. Ми створювали продукт для того, хто приймає рішення, а не для того, хто ним користується.
- Плутанина між схваленням та правильністю. Те, що клієнт каже «так», не означає, що продукт правильний.
- Використання схвалення як захисту. Якщо б ви не показали свою роботу комусь, кого поважаєте, не використовуйте схвалення клієнта як щит.
- Сприйняття розгортання як фінішної прямої. Успіх приходить після запуску.
Як це виправити:
Будьте чіткими, коли не згодні. Скажіть клієнту: «Ми зробимо це, тому що ви попросили. Але ми вважаємо, що X призведе до Y. Давайте зафіксуємо це письмово».
Ця фраза допоможе уникнути звинувачень у майбутньому.
Перестаньте сприймати розгортання як кінець. Вам потрібні відстеження помилок, сповіщення про uptime та єдиний дашборд для моніторингу рівня помилок і latency. Вам також потрібна документація для себе в майбутньому.
Яку помилку ваша команда припускається знову і знову?