Мы с братом вдвоём разрабатываем WorkHub. До этого у нас не было профильного образования и опыта создания цифровых продуктов. Мы не работали внутри IT‑команд и не проходили путь от стажёра до разработчика. Возможность начать появилась во многом благодаря ИИ‑инструментам.

Я, в основном, отвечаю за продуктовую документацию, проработку функций и тексты. Код мы пишем вместе. Брат сильнее влияет на общее видение продукта и занимается аналитикой. Жёсткого разделения ролей у нас нет: небольшие UX‑проблемы, разработку и проверку реализации мы часто разбираем совместно.

Первой нашей идеей была онлайн‑доска. Мы хотели сделать что‑то похожее на Excalidraw, а затем использовать эту основу для проверки других продуктовых идей.

Разработка остановилась примерно через полтора месяца. Одним из моментов, после которых стало понятно, что старый подход больше не работает, была elbow‑стрелка. Это обычная ломаная стрелка, которая соединяет элементы на доске. Мы потратили на неё несколько недель.

Стрелка неправильно прикреплялась к фигурам, иногда не прикреплялась вообще, а её отображение ломалось. Мы исправляли один сценарий, после чего переставал работать другой. Новая реализация накладывалась поверх предыдущей, код становился сложнее, но стабильного результата всё равно не было.

Сначала мы считали, что основная проблема в Codex. Модели тогда действительно были слабее. Но позже стало понятно, что дело было не только в инструменте.

Как мы вошли в разработку через ИИ

Идея нашлась быстро. Онлайн доска по типу excalidraw, должна была заменить ушедшие западные аналоги с рынка и по сути занять их нишу. Мы быстро набросали дорожную карту, примерно распределили обязанности и записали основные задачи.

Посовещавшись с нашим главным разработчиком‑ChatGPT, выбрали технологический стек, создали репозиторий на GitHub и стали превращать идеи в задачи для Codex. Процесс выглядел примерно так:

Идея → задача для Codex → реализация → поиск пропущенных сценариев → исправление багов.

Для человека без опыта такой подход кажется логичным. Пока функция существует только в голове, кажется, что она уже достаточно понятна. Остаётся объяснить её агенту и получить код.

По началу этот метод даже работал. Мы добавляли функции, исправляли ошибки и постепенно собирали продукт. Но новые решения почти всегда появлялись поверх существующей реализации. Мы заранее не описывали сложное поведение, не разделяли функцию на сценарии и не фиксировали ограничения.

Главный файл быстро разрастался. Разные части продукта становились всё сильнее связаны между собой. Изменение одной функции могло сломать то, что до этого работало нормально. Примерно раз в одну‑две недели мы возвращались к рефакторингу. Пытались привести код в порядок, затем исправляли новые ошибки и восстанавливали сломанные сценарии.

Elbow‑стрелка просто сделала эту проблему особенно заметной. Мы пытались решить её на уровне реализации, хотя часть вопросов должна была быть закрыта раньше:

• к каким элементам может прикрепляться стрелка;

• какие точки привязки доступны;

• что происходит при перемещении фигуры;

• как должна перестраиваться линия;

• что происходит при удалении или изменении связанного элемента;

• какие состояния считаются допустимыми.

У нас не было зафиксированной модели поведения. Поэтому продуктовые и технические решения принимались прямо во время генерации и правки кода. И в какой‑то момент стало понятно, что ещё один рефакторинг ничего принципиально не изменит. Архитектура мешала дальнейшему развитию, продукт работал нестабильно, а у самой идеи не было достаточно понятного основания для выхода на рынок. Мы решаем остановить разработку. 

Проблема оказалась шире плохого кода

После остановки и небольшого разочарования, что полтора месяца были потрачены впустую. Мы решаем пересобрать наш подход, виденье нашего продукта. Параллельно выписав ту боль, с которой столкнулись сами.

Информация о проекте находилась в разных местах. Задачи мы вели в YouGile. Код хранился на GitHub. Обсуждения, гипотезы и часть решений оставались в проектах ChatGPT. Файлами мы могли обмениваться через Telegram. Некоторые документы лежали локально у одного из нас. Даже у roadmap было несколько копий. После изменений приходилось вручную отправлять новый файл, и в какой‑то момент уже было сложно понять, оба ли мы смотрим на актуальную версию.

Терялась не только сама информация. Терялись причины решений. Через несколько месяцев брат мог спросить:

Вадим, почему ты сделал именно так?

И мне нужно было сначала самому вспомнить, где мы это обсуждали, какая версия решения была последней и почему в итоге выбрали именно её.

Из этого опыта начала формироваться идея WorkHub: собрать рабочую информацию проекта в одном пространстве. Постепенно внутри продукта появились доски, Kanban, заметки, файлы и структура проектов.

Часть собственной работы мы тоже перенесли туда. Roadmap оказался на доске, текущие задачи в Kanban, концепции и рабочие материалы в заметках. Это помогло с хранением информации, но не решило другую проблему. Даже если все документы лежат в одном месте, остаются вопросы:

• зачем нужна конкретная функция;

• какие пользовательские задачи она закрывает;

• что входит в первую версию;

• какие состояния нужно учесть;

• как проверить, что реализация соответствует замыслу.

Единое рабочее пространство помогает восстановить контекст. Оно не проектирует функцию вместо команды.

Когда старый процесс снова перестал работать

Для небольших изменений схема «описали задачу и отправили в Codex» продолжала работать. Если нужно добавить отдельный тег в один инструмент, изменить подпись или поправить локальное поведение, большой пакет документации действительно не нужен. Достаточно понять сценарий, проверить связанные состояния и внести изменение. Проблемы начинались именно с комплексными функциями.

По мере развития WorkHub новые задачи всё чаще затрагивали сразу несколько частей продукта:

• интерфейс;

• навигацию;

• бизнес‑логику;

• ограничения тарифов;

• хранение данных;

• архитектуру;

• тесты.

При работе с ИИ к этому добавлялась необходимость постоянно передавать контекст. Агенту нужно было объяснять текущую реализацию, существующие ограничения и связи с другими частями системы. Если часть решения не была зафиксирована заранее, она начинала формироваться прямо внутри чата с агентом. В одном сообщении появлялось первое решение, в следующем оно уточнялось, затем частично менялось во время реализации. Код сохранялся, а логика, которая к нему привела, постепенно растворялась между чатами. Мы начали разделять продуктовую, UX‑ и техническую проработку.

В результате появилась схема из 18 этапов, от первоначальной концепции до проверки функции после релиза.

Сейчас она выглядит заметно сложнее нашего первоначального процесса. Но мы не проходим все этапы механически для каждой задачи. Полная проработка нужна, когда изменение затрагивает несколько частей продукта, содержит много связанных сценариев или может дорого обойтись при переделке. Для небольшого локального изменения процесс сокращается.

У нас нет системы, где задача получает семь баллов из десяти и автоматически отправляется в полный цикл. Решение пока принимается по масштабу и количеству неизвестных.

Например: добавление нового тега в отдельный инструмент и разработка мобильной версии всего продукта требуют разной глубины подготовки. Притворяться, что это одинаковые задачи, было бы странно. Сама схема нужна не ради количества документов. Каждый этап должен закрыть определённый вопрос:

• зачем мы вообще делаем функцию;

• что войдёт в текущую версию;

• как человек будет ей пользоваться;

• какое поведение должна обеспечить система;

• как решение встроится в существующий продукт;

• по каким признакам мы примем работу;

• что и как будем проверять после реализации.

Одним из первых крупных направлений, на котором мы решили проверить этот подход почти полностью, стала мобильная версия WorkHub.

Почему мы подняли Mobile Web в дорожной карте

Изначально Mobile Web находилась примерно на втором или третьем месте в дорожной карте. Мы предполагали, что основная работа с WorkHub всё равно будет происходить за компьютером. Поэтому адаптацию под телефон можно было отложить.

После корректировки рабочей гипотезы, WorkHub начал развиваться не просто как набор инструментов, а как внешняя память проекта. В такой модели человек должен иметь возможность не только полноценно работать за компьютером, но и быстро открыть нужную информацию с телефона, восстановить контекст или сохранить что‑то новое. Но окончательно изменить приоритет нас заставили реальные пользователи.

В Яндекс Метрике мы увидели, что люди заходят в WorkHub с телефонов и пытаются пользоваться интерфейсом, который не адаптирован для телефона и работал по правде говоря, криво. 

Они уже создавали мобильные сценарии, хотя продукт их нормально не поддерживал. После этого мы подняли Mobile Web выше в дорожной карте. Перед нами появился практический вопрос:

Сможет ли новый процесс обнаружить пропущенные требования до начала основной разработки?

Сначала мы зафиксировали границы версии

Работа началась с концепции мобильной версии.

Нужно было понять, зачем пользователю мобильный WorkHub, какие задачи он должен решать с телефона и какую роль мобильный интерфейс играет внутри всего продукта.

После этого мы зафиксировали границы первой версии. Отдельно определили, какие мобильные сценарии делаем сейчас, а какие сознательно оставляем за пределами текущей разработки. Это оказалось важным, потому что мобильная версия легко могла разрастись в попытку полностью повторить десктопный интерфейс.

Но первые документы не закрыли все вопросы. И следующий этап как раз показал, зачем одной и той же идее проходить несколько уровней проверки.

Пользовательские сценарии обнаружили пропущенный биллинг

Когда мы начали раскладывать работу мобильного пользователя по отдельным сценариям, обнаружился большой пробел. В первоначальных границах версии почти отсутствовал платёжный слой. Например, пользователь мог создать максимальное количество проектов или дойти до лимита отдельных элементов, таких как доски. Но мы не описали, что именно он увидит после достижения ограничения и как сможет перейти к управлению тарифом.

Это был не один забытый текст или кнопка. В мобильную версию пришлось добавить отдельную часть биллинга:

• экран с текущим тарифом;

• ограничения по проектам и элементам;

• экран доступных тарифов;

• переходы из состояний, в которых пользователь достиг лимита.

• Отдельное окно обязательных чек‑боксов. 

Без этого пользователь мог столкнуться с ограничением на телефоне и не понять, что произошло и что ему делать дальше. Платёжный сценарий вернулся в границы первой версии. Мы обновили связанные пользовательские пути и предусмотрели дополнительные экраны.

На тот момент финальный PRD ещё не был зафиксирован, а основная разработка не началась. Изменить решение было относительно дёшево. Именно это стало первым понятным результатом нового процесса. Мы не доказали, что документация ускоряет всю разработку. Но конкретное крупное требование удалось обнаружить до того, как оно превратилось в переделку готового кода вместе с тестами.

На уровне UX появились другие пропуски

При переходе от пользовательских сценариев к UX‑модели вопросы стали более конкретными. Начали появляться переходы, кнопки и состояния, которые раньше нигде не были описаны. В какой‑то момент выяснилось, что я вообще не предусмотрел переключение между светлой и тёмной темами.

Со стороны это может выглядеть как совсем простая ошибка. Функция уже существует в продукте, почему её нельзя было сразу учесть? Потому что сложный продукт плохо помещается в голове целиком. Когда думаешь о мобильной навигации, структуре экранов, ограничениях, ui, переходах, проектах и разных типах элементов, обычная кнопка смены темы легко выпадает.

Это одна из причин, по которой я не пытаюсь описать всю функцию за один проход. Концепция проверяет её смысл. Пользовательские сценарии показывают путь человека. UX заставляет разобрать конкретные переходы и состояния.

Каждый следующий этап может вернуть нас к предыдущему документу. Для нас это не считается ошибкой процесса. Наоборот, если UX обнаружил пробел в границах версии, документ нужно обновить до начала основной разработки.

Подробные документы не спасли hi‑fi от плохой реализации

После чернового PRD и обновления предыдущих документов мы перешли к hi‑fi. Детализированный мобильный интерфейс мы собираем в отдельной тестовой среде. Сначала там можно проверить навигацию, состояния экранов и соответствие макетам, не подключая сразу всю реальную логику WorkHub.

Сначала мы передали реализацию ИИ агенту. Отдельная dev среда собрана, первый интерфейс начал вырисовываться. И результат показал, что даже подробный контекст не гарантирует правильного переноса интерфейса. Агент не понял общую модель мобильного UI. Проблема была не в одном цвете или отступе. Дорабатывать пришлось практически все страницы.

Кнопки Back находились не там, где должны были. Часть информации дублировалась. Структура экранов не соответствовала задумке. Нижняя панель должна была быть накладной и находиться поверх рабочей области. Агент реализовал её как обычный отдельный блок в нижней части страницы. Формально панель присутствовала, но интерфейс работал и воспринимался иначе. По сути, нам пришлось заново проходить страницы и сравнивать их с макетами.

Документация уменьшает количество неопределённости, но не отменяет проверку реализации. Агент может получить пользовательские сценарии, требования и hi‑fi, а затем всё равно неверно понять композицию интерфейса.

Нельзя передать задачу и считать, что наличие документов автоматически обеспечивает правильный результат. На момент написания статьи Mobile Web находится на этапе доработки hi‑fi. Мы ещё не прошли полный цикл до основной разработки и релиза.

В общей схеме мы дошли примерно от начальной концепции до этапа детализированного интерфейса. Отдельные последующие документы, включая финальный PRD, implementation plan и acceptance criteria, мы уже составляли для других задач, но конкретно мобильная версия пока находится раньше. Поэтому оценивать весь процесс как завершённый рано.

Что новый процесс уже дал

Пока мы можем говорить только о промежуточных результатах. В Mobile Web ещё до основной разработки обнаружились требования, которых не было в первоначальной версии:

• платёжные сценарии;

• экраны тарифов и лимитов;

• отдельные переходы и состояния интерфейса;

• переключение темы;

• расхождения между задуманным и реализованным hi‑fi.

Стало понятнее, что именно мы собираемся разрабатывать и как должен вести себя пользовательский интерфейс. Документы помогают и внутри команды.

Если брат спрашивает, почему решение устроено именно так, теперь ответ не обязательно восстанавливать по памяти или искать среди старых чатов. Можно вернуться к концепции, сценарию или связанному требованию.

Но отсюда пока нельзя сделать вывод, что новый процесс ускорил разработку. На предварительную проработку уходит больше времени. Мы создаём документы, пересматриваем сценарии, возвращаемся к предыдущим этапам и дорабатываем макеты.

Мы также пока не можем утверждать, что новый процесс уменьшил количество багов или общую стоимость разработки. Mobile Web не дошла до релиза. Полный цикл ещё не пройден. На текущем этапе подтверждён только более узкий результат:

Часть пропущенных требований удалось обнаружить до написания основного кода.

Окупятся ли затраты на подготовку меньшим количеством переделок, станет понятно позже.

Где этот подход может не сработать

Большое количество документов само по себе ничего не гарантирует. Можно подробно описать функцию и всё равно получить неправильную реализацию. Наш опыт с hi‑fi это уже показал. Требование можно неверно понять. Сценарий можно пропустить. Макет можно перенести неточно. Поэтому ревью, тестирование и сравнение результата с исходным замыслом остаются отдельной частью работы.

Но есть и более фундаментальное ограничение.

Документация не превращает слабую продуктовую идею в сильную. Можно последовательно подготовить концепцию, пользовательские сценарии, UX, PRD и технический план, а затем качественно реализовать то, что пользователям не нужно.

Новый процесс не доказывает правильность стратегии. Он решает более узкую задачу: помогает лучше описать выбранное решение и раньше обнаружить часть противоречий.

Также мы в голове держим и то, что схема из 18 этапов легко может превратиться в процесс ради процесса. Особенно если применять её к каждому небольшому изменению. Если признаться честно, мы пока не нашли формальную границу, которая точно разделяет простые и сложные задачи. Ориентируемся на количество затрагиваемых частей продукта, число неизвестных и возможную цену переделки.

Для локального изменения можно ограничиться коротким описанием сценария и проверкой реализации. Для мобильной версии, которая затрагивает навигацию, тарифы, редакторы, проекты и разные типы контента, такой подход уже не работает.

Что в итоге

Мы пока не знаем, окупится ли подробная подготовка Mobile Web меньшим количеством багов и переделок. Это станет понятно только после основной разработки и релиза.

Но промежуточный результат уже есть: до начала работы с основным кодом мы обнаружили пропущенные сценарии и целые экраны, которых не было в первоначальных границах версии.

При этом границу между полезной проработкой и бюрократией мы пока определяем скорее на глаз. Поэтому особенно интересно узнать о чужом опыте: сталкивались ли вы с ситуацией, когда документация сначала помогала разработке, а затем становилась избыточной и начинала замедлять команду? По каким признакам вы понимали, что эту границу уже перешли?