Spec Projector — сервис по разработке технического задания на программные продукты
О том, как разработать техническое задание для вашего ИТ-продукта, навести порядок в процессах разработки и автоматически создавать описание задач для программистов.
Как я уже писал тут — я очень люблю программировать и вместе со своей командой нахожусь в вечном поиске идеального подхода к разработке, где всем все понятно, комфортно, и клиенты довольны.
Многие скажут, что Agile предоставляет превосходный подход к разработке, и они будут правы. Но Agile идеально подходит, когда одна целая команда работает над 1 проектом с полным погружением и эмпатией, что в конечном итоге получается хорошо, но очень дорого, и в основном это актуально для продуктовых компаний: свой продукт, свои пользователи, один бэклог.
Мы разрабатываем web-приложения на заказ, и в работе одновременно у одной команды на разных стадиях может быть 3-5 проектов (в т.ч. на поддержке). Разработчики могут получать задачи в разных проектах, и у них нет времени погружаться в проект — им нужно четко выполнить, что написано в задании.
Я часто работал одновременно как разработчик и как проджект-менеджер. Мне неоднократно приходилось писать ТЗ и каждый раз я «испытывал боль» — я читал ГОСТы, изучал UML, рисовал диаграммы и схемы в поиске идеальной модели данных и четких юзкейсов и т.д., но всегда сталкивался с несколькими проблемами:
- ГОСТы и UML хорошо, но в реальности мало кто умеет правильно этим пользоваться, понимать и интерпретировать.
- Отсутствие нормальных инструментов для рисования диаграмм и быстрого доступа к ним. Чаще всего редакторы — это обычные «рисовалки» без привязки в методологии и стандартам.
- Можно использовать PlantUML но исходный код диаграмм где-то нужно хранить, и публиковать рендеры. Было время, когда для этого я использовал Git с рендером через CI/DI. И все бы ничего, но как показывает практика, чем больше нужно сделать действий, тем меньше хочется куда-то идти и что-то править/актуализировать.
- В случае каких-либо ошибок, замеченных разработчиками в ТЗ в ходе разбора задач (даже мелких описок), менеджеру приходится идти править диаграммы, потом снова аттачить в задачи и т.д. — синдром перфекциониста.
- Проектная документация рано или поздно устаревает, отстает от исходного кода и это, пожалуй, главная причина, почему после первой итерации на поддержку документации уже забивают, а единственным местом знаний о системе становится код.
Среди всех испробованных вариантов лучшим местом для написания ТЗ оказался Google Docs:
- Все в облаке и по ссылке. В описании задач разработчикам предоставляются ссылки на соответствующие разделы ТЗ.
- Быстрый доступ и правки прямо на месте в случае ошибок или неточностей.
- Комментарии и предложения по правкам.
- Есть вся история изменений. Почти как GIT: -)
- Можно давать права на чтение и редактирование.
Чего не хватает:
- Жестких рамок по созданию ТЗ.
- Дополнительных инструментов типа: проектирование модели данных, описание пользовательских историй и т.д.
- Более удобной навигации.
- Возможности поддерживать ссылочную целостность. Например, переименовали поле в модели данных, а на него есть ссылка в GraphQL API или REST.
- Разделения прав, например, дизайнеру не нужно править API, а программисту — экраны дизайна. Разработчикам не нужно видеть стоимость фичей, по которым мы работаем с клиентом.
Конечно же, есть еще wiki или Confluence, но проблемы были аналогичные — отсутствие рамок и следования конкретному процессу.
Т.к. я люблю программировать и недавно «игрался» с PouchDB, вызов был принят :-)
Так появился
Spec Projector — место для хранения проектной документации для web-приложений.
По сути, это аналог Google Docs для ТЗ, где:
- Можно определить состав фичей приложения по актерам и эпикам.
- Написать пользовательские истории для каждой фичи.
- Определить необходимые ресурсы и стоимость фичи для клиента.
- Согласовать с клиентом стоимость фичей, итераций и всего проекта.
- Передать истории дизайнеру — он загрузит отрисованные экраны.
- Фронтенд-программист, смотря на истории, дизайн и прототип, спроектирует и опишет модель данных и API.
- Бекенд-программист реализует модель данных и API.
- Тестировщик закрепит чек-листы для проверки качества реализации фичей.
Немного скриншотов
Процесс более подробно
Менеджер проекта определяет функциональный состав в виде:
Актер X
- Фича 1 — Эпик A
- Фича 2 — Эпик B
Актер Y
- Фича 3 — Эпик B
- Фича 4 — Эпик C
Далее процесс по созданию каждой фичи:
1. Планирование
- Менеджер проекта пишет пользовательскую историю в режиме интервью с заказчиком в виде: я вижу, я могу.
- Дизайнер, используя историю, рисует дизайн интерфейса и собирает прототип фичи в Figma, закрепляя фреймы.
- Проджект-менеджер согласовывает дизайн и прототип с заказчиком.
- Проджект-менеджер ставит задачу лидеру фронтенд-разработки на проектирование API в GitLab.
- Лидер фронтенд распределяет задачи между своими разработчиками на проектирование API.
- Фронтенд-разработчики определяют данные, которые нужно отправить/получить на соответствующих экранах дизайна для работы фичи. В результате получаем модель данных и вызовы API: REST или GraphQL.
- Лидер команды фронтенд делает ревью спецификации и закрывает задачи.
- Тестировщик закрепляет чек-листы для проверки качества реализации.
2. Реализация
- Лидер команды фронтенд ставит задачи на реализацию фичи на мок-данных (API еще не готов) для своих разработчиков.
- Проджект-менеджер ставит задачу лидеру бекенд на разработку API.
- Лидер бэкенда распределяет задачи между своими разработчиками на реализацию API.
- Разработчики бэкенда реализуют API, пишут тесты.
- Лидер бэкенда делает ревью и принимает код.
- Фронтенд-разработчики переключаются с моков на API.
- Лидер фронта делает ревью и принимает код.
- Код деплоится, фича опубликована.
3. Тестирование
- Тестировщик проверяет фичу по чек-листам.
- Тестировщик находит баги и назначает задачи на лидера фронтенд.
- Лидер распределяет баги между разработчиками и принимает код.
- В случае ошибок в API фронтенд-разработчики создают задачи для бэкенд-разработчиков и ожидают фиксов.
- Тестировщик все еще раз проверяет и закрывает задачу.
4. Презентация
- Проджект-менеджер проводит контроль качества.
- Проджект-менеджер делает презентацию фичи клиенту.
- Клиент выдает замечания.
Планы на будущее
- Единый словарь терминов и синонимов c возможностью вставки в пользовательские истории, ассоциации с моделью данных, API и т.д. Например в ТЗ есть термин «Вакансия». Один разработчик к коде напишет class Vacancy другой class JobOffer. Так быть не должно.
- Валидация ТЗ.
- Экспорт модели данных, например, в Strapi или Django.
- Экспорт REST API в Swagger.
- Маркетплейс спецификаций, где можно взять/купить готовое ТЗ и адаптировать под свой проект.
- Маркетплейс команд, с возможностью получения оценок от разных компаний по реализации Вашего ТЗ.
- Интеграция с таск-трекерами. Все запланированные фичи можно экспортировать одной кнопкой с описанием задач и связями с ТЗ. Далее, отслеживая трек времени в задачах, можно сравнить разницу с оценками, т.е. насколько «вылетели».
- Возможности выставлять счета клиентам и согласовывать стоимость фичей прямо в системе.
Главный вопрос к Вам, друзья, — как думаете — полезный продукт? Хотели бы Вы попробовать этот сервис для ведения своих проектов?
Ну и для тех кто дочитал — как пример, ссылка на документацию одного из наших проектов Team Projector на примере описания одной из фичей (лучше пока открывать в десктопе).
P.S. Есть у кого опыт продаж IT-сервисов? Очень ищем в команду.