Architecture First: как небольшой командой с ИИ сделать альтернативу Jira — Часть 3.
Предыдущая статья была о прототипе интерфейса. Теперь нужно решить, как пользователь будет создавать задачи на досках прямо из Telegram.
Прототип показывает, как продукт будет выглядеть, но не отвечает на другой вопрос: как человек из Telegram попадёт в этот интерфейс и что будет делать в самом чате. Фиксируем это до проектирования базы данных. Мы уже писали о том, почему начинаем разработку с пути пользователя, как об общем принципе. Здесь тот же принцип на конкретном примере — Laraue Boards.
Коротко о том, что мы решили:
- первая версия однопользовательская: без организаций, команд, общего доступа и прав;
- путь пользователя состоит из двух действий: сохранить сообщение через бота и разобрать задачи в веб-приложении;
- бот нужен потому, что «Сохранённые сообщения» удобны для записи, но не для разбора записанного.
Минимум для первой версии
Мы предпочитаем итеративную разработку: в конце каждой итерации должна появляться работающая версия приложения. Если сразу пытаться сделать полнофункциональный продукт, есть риск так и не довести его до результата. Поэтому первая версия Boards рассчитана на одного человека и его собственные задачи. Никаких организаций, команд и ролей.
Это сознательное решение. Как только появляется общий доступ, сложность быстро растёт: кто что видит, кто что может менять, что происходит, когда двое правят одно и то же. Однопользовательский режим позволяет быстрее выпустить MVP и проверить главное: удобно ли пользоваться тем, что получается.
Базовый сценарий: от сообщения до карточки
Путь пользователя мы представили так:
- Пользователь пишет сообщение боту.
- Бот сохраняет его карточкой в бэклоге и сообщает, что всё получилось.
- Позже пользователь открывает приложение, видит бэклог и работает с канбан-досками.
По сути, это два действия: сохранить и разобрать.
Сохранение. Вместо заметки в «Сохранённых сообщениях», где она теряется в общей ленте, человек отправляет текст боту, и тот превращает его в карточку. Записывать по-прежнему можно там же, где человек уже сидит, — в Telegram.
Разбор. Когда нужно оценить прогресс или подвигать карточки между статусами, человек открывает веб-приложение. Оно даёт то, чего нет в чате: наглядную картину по всем задачам сразу.
Зачем бот, если есть «Сохранённые сообщения»
В Telegram уже есть место для заметок — «Сохранённые сообщения». Многие ведут там неформальный список дел. Зачем тогда бот, который делает то же самое? Затем, что для дел это место не всегда удобно.
Мы спросили нескольких друзей, которые, как и мы, постоянно сидят в Telegram. Вопросов было два: используешь ли ты «Сохранённые сообщения» как блокнот, который всегда под рукой, и сложно ли потом разбираться в накопленном? Все ответили «да» на оба. Telegram открыт и на телефоне, и на компьютере, поэтому быстро записать мысль там проще всего. Но записи не рассчитаны на то, чтобы потом их сортировать и вести по статусам.
Есть эмодзи-теги, которыми можно помечать сохранённое и фильтровать его. Некоторые заводят несколько чатов. Но тегов немного, а записи, разбросанные по разным чатам, трудно искать, так что полностью проблему это не решает.
Бот позволяет сохранить привычный способ записи и добавить к нему настоящее управление задачами. К тому же Telegram популярен в небольших компаниях в странах СНГ, где задачи часто ставят сотрудникам обычным текстом в чате. Поэтому со временем такой продукт может вырасти в инструмент для малого бизнеса. Это пока гипотеза, но она подсказывает направление.
Как путь пользователя определяет модель данных
Когда путь описан до кода, сразу видно, что должна поддерживать модель данных: пользователя, карточку, бэклог, доску с колонками и статус у каждой карточки. Видно и распределение ролей. Бот принимает сообщение и создаёт карточку. Веб-приложение читает карточки, двигает их и меняет статусы.
Схему базы мы будем проектировать не из абстрактного набора сущностей, а из конкретного сценария: в ней появится только то, без чего этот сценарий не заработает.
Что из этого пути пережило первых пользователей
Позже, на реальных пользователях, часть сценария изменилась, и об этом стоит сказать сразу.
Двухшаговая схема «сохранить в боте, разобрать в приложении» осталась. А вот сам бот мы упростили. Сначала мы добавили в чат выбор эпика и статуса сразу при сохранении, чтобы человеку не пришлось открывать приложение. Пользователям это мешало: вместо быстрой записи бот начинал задавать вопросы. Мы убрали эту функцию. Теперь сообщение, отправленное боту, сохраняется, а бот отвечает реакцией 👍, и всё. Подробнее — в статье о том, почему пользователи выбирали «Сохранённые сообщения».
Что дальше
Путь пользователя описан, и можно выбирать технологии. В следующей статье — выбор стека: .NET, PostgreSQL, Nuxt и причины, по которым мы предпочитаем скучные технологии. Схема базы данных и первая версия бэкенда — после неё.