Клиент хотел 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.