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