Architecture First: как в одиночку с ИИ сделать альтернативу Jira — Часть 1.
Это вводная статья цикла о том, как разрабатываются Laraue Boards: решения, компромиссы и ошибки. Разработка ведется итеративно, в каждой статье решается проблема или разрабатывается новая версия приложения. Если интересен сам продукт, а не то, как он сделан, можно открыть проект, страницу с его подробным описанием или документацию.
Первая статья о том, зачем мы решили написать ещё один таск-трекер, каким задуман продукт и где посмотреть его исходники. Инженерная часть описывается в следующих статьях.
Зачем нужен ещё один таск-трекер
Таск-трекеров настолько много, что среди разработчиков существуют шутки в стиле "хочешь бесполезно потратить время — напиши еще один таск-трекер". Ниша предельно заполнена, и новому продукту не получится успешно конкурировать с Jira или Linear по функциям, количеству интеграций или узнаваемости. Но, как правило, в переполненном рынке есть и плюсы — скорее всего в нем есть пользователи и они успешно монетизируются, их можно переманивать при определенных условиях, можно подсматривать идеи у конкурентов. Более подробно о том, как мы решаем, что разрабатывать, и почему выходить на переполненный рынок бывает допустимо, мы писали отдельно.
Мы попробуем сделать таск-трекер, сфокусировавшись на глубокой интеграции с Telegram. Как это может работать: небольшие бизнесы в СНГ часто живут в Telegram — там все чаты, там могут ставиться задачи. Иногда такие компании еще даже не дорастают до CRM: чат для них и является CRM. Если же компания уже имеет продукт для ведения задач, для их заведения сотрудникам приходится переключать внимание: идти в браузер и заводить задачи там. При этом задача не привязывается к контексту (к месту в чате, откуда эта задача появилась).
С помощью продукта Laraue Boards мы хотим закрыть этот пробел: бот будет участником чата, превращающим его сообщения в задачи на Kanban доске. Инструмента для тех, кто пока ведет бизнес только в Telegram, нет — это пространство и попытается занять Laraue Boards.
У продукта может быть и другое направление, помимо малого бизнеса — соло-пользователи. Telegram славится своей лояльностью аудитории, и пользователи часто используют его для сохранения своих заметок. Гибкости чатов не всегда хватает для того, чтобы управлять подобными заметками, и Laraue Boards может быть полезен в этой нише. Если заметки в чате будут становиться карточками на доске — процесс их организации станет намного прозрачнее для пользователя.
Куда будет двигаться продукт
Первая версия продукта будет работать для соло-пользователей. Это проще всего реализовать и позволит получить первый фидбэк. В ней должен появиться бот, с помощью которого пользователь создает issue на досках.
Далее — режим организаций. Пользователи смогут работать над одними досками в рамках своих компаний / чатов. Должна появиться некоторая ролевая модель, возможность приглашения в организацию.
Следующая идея в том, чтобы бот стал полноценным участником любого чата. Участник команды упоминает бота в разговоре, бот создаёт issue из этого сообщения, и в чат приходит ссылка на issue, issue ссылается на исходное сообщение.
После стабилизации основной функциональности — встраивание ИИ в рабочий процесс. Пользователь выбирает набор issues как контекст (например, все issues в спейсе за январь–март) и может задавать вопрос: подведи итог квартала, сформируй отчёт в нужном формате, найди заблокированные задачи. Issues становятся контекстом для разговора.
Где посмотреть актуальную версию
Laraue Boards доступны по адресу msgboard.laraue.com. Актуальная документация описывает реализованный функционал и то, как им пользоваться.
Репозитории
Два репозитория, на которых построен цикл статей:
- Бэкенд — Laraue.Apps.Boards — .NET 10 / C#, PostgreSQL 18
- Фронтенд — laraue-boards — Nuxt 4, Vue 3, TypeScript
Далее в цикле статьи ссылаются на конкретные файлы в этих репозиториях.
Что дальше
Следующая статья — о том, что происходит до написания первой строчки кода: о прототипировании интерфейса. Нет смысла выбирать стек, проектировать схему или определять модель данных, не зная, как продукт выглядит и что пользователь будет с ним делать.