Клієнт хотів real-time спільне редагування в інструменті управління проєктами. Типу Google Docs, але для проєктних брифів. Кілька користувачів редагують один документ одночасно, з курсорами, вирішенням конфліктів та індикаторами присутності.
Ми сказали ні. Не тому що неможливо — а тому що це було неправильно для їхнього MVP.
Запит
Продукт — інструмент управління проєктами для маленьких креативних агентств (5–15 людей). Основні фічі: дошки задач, трекінг часу, клієнтські портали та зберігання документів. У клієнта було чітке бачення та бюджет €14K.
На етапі скоупінгу ми розподілили 4 тижні розробки по основних фічах. Потім клієнт запитав: «А що щодо real-time редагування? Моя команда зараз використовує Google Docs для брифів, але я хочу вбудувати це в застосунок.»
Чому ми відмовили
Математика не сходилася
Real-time спільне редагування (CRDT або operational transforms) — це фіча на 3–6 тижнів. Для бюджету в €14K це 25–40% усього проєкту — на одну фічу, яку ще жоден користувач не просив.
Існуюче рішення працювало нормально
Команда вже використовувала Google Docs. Безкоштовно, надійно, перевірено для спільної роботи. Заміна на гіршу версію всередині застосунку була б даунгрейдом з першого дня.
Що команді реально було потрібно — не real-time редагування, а зв'язок між документом і проєктом. «Цей бриф належить цьому проєкту, і ось посилання на Google Doc.»
Складність була прихованою
Real-time редагування звучить як одна фіча. На практиці це: вирішення конфліктів, індикатори присутності, історія версій, права доступу, офлайн-обробка, продуктивність для великих документів. Кожен пункт — тиждень роботи.
Що ми побудували замість
Розділ документів у кожному проєкті з:
- Завантаженням файлів (drag and drop, до 50МБ)
- Вбудовуванням посилань Google Docs/Notion/Figma
- Простими rich-text нотатками (не спільне — один автор на нотатку)
- @згадуваннями, що повідомляють учасників
Час розробки: 1 тиждень (vs. 3–6 тижнів для real-time редагування).
Шість місяців потому
Клієнт запустився. 40 акаунтів агентств за перші 3 місяці. На созвоні на 6-му місяці я запитав про фічу real-time редагування.
Їхня відповідь: «Ми жодного разу не чули, щоб хоч один користувач попросив це. Усі вже використовують Google Docs або Notion. Що їм було потрібно — кращий зв'язок задач з документами, а це в нас є.»
Вони додали: «Якби ми витратили 4 тижні на real-time редагування, у нас би не вистачило часу на клієнтський портал — а це фіча, яку більшість агентств назвали причиною реєстрації.»
Фреймворк прийняття рішень
Коли клієнт просить складну фічу в MVP, я проганяю три питання:
-
Чи вирішує користувач цю проблему зараз? Якщо так — і адекватно — не потрібно замінювати інструмент. Потрібно інтегруватися.
-
Яка альтернативна вартість? Кожен тиждень на фічу X — це тиждень без фічі Y.
-
Це буде причиною, з якої хтось зареєструється? Real-time редагування не було ні must-have, ні delighter — це була заміна того, що вже працювало.
Незручна правда
Відмовити клієнта від фічі здається ризикованим. Він платить. У нього бачення.
Але розробник, що каже «так» на все — це розробник, що шипить із запізненням, з перевитратою бюджету або з недоробленими фічами. Я бачив цей патерн у rescue-проєктах — оригінальний розробник погоджувався на все, доробив 60% роздутого скоупу, і фаундеру довелося починати заново.
Клієнт подякував, бо ми порахували вголос: «Ось вартість цієї фічі в тижнях та євро. Ось що ми виріжемо, щоб вона влізла. Ось що вашим користувачам реально потрібно в перший день. Ваш вибір — але наша рекомендація: ні.»
Прозорість дає клієнту інформацію для гарного рішення. Мовчазна згода — ні.
Будуєте MVP і не впевнені, які фічі включити? Напишіть — я допомагаю скоупити MVP, щоб ви шипили правильне за 12 тижнів, а не все за 20.