Spec Projector — сервис по разработке технического задания на программные продукты

О том, как разработать техническое задание для вашего ИТ-продукта, навести порядок в процессах разработки и автоматически создавать описание задач для программистов.

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

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

Мы разрабатываем web-приложения на заказ, и в работе одновременно у одной команды на разных стадиях может быть 3-5 проектов (в т.ч. на поддержке). Разработчики могут получать задачи в разных проектах, и у них нет времени погружаться в проект — им нужно четко выполнить, что написано в задании.

Я часто работал одновременно как разработчик и как проджект-менеджер. Мне неоднократно приходилось писать ТЗ и каждый раз я «испытывал боль» — я читал ГОСТы, изучал UML, рисовал диаграммы и схемы в поиске идеальной модели данных и четких юзкейсов и т.д., но всегда сталкивался с несколькими проблемами:

1. ГОСТы и UML хорошо, но в реальности мало кто умеет правильно этим пользоваться, понимать и интерпретировать.
2. Отсутствие нормальных инструментов для рисования диаграмм и быстрого доступа к ним. Чаще всего редакторы — это обычные «рисовалки» без привязки в методологии и стандартам.
   
3. Можно использовать PlantUML но исходный код диаграмм где-то нужно хранить, и публиковать рендеры. Было время, когда для этого я использовал Git с рендером через CI/DI. И все бы ничего, но как показывает практика, чем больше нужно сделать действий, тем меньше хочется куда-то идти и что-то править/актуализировать.
   
4. В случае каких-либо ошибок, замеченных разработчиками в ТЗ в ходе разбора задач (даже мелких описок), менеджеру приходится идти править диаграммы, потом снова аттачить в задачи и т.д. — синдром перфекциониста.
   
5. Проектная документация рано или поздно устаревает, отстает от исходного кода и это, пожалуй, главная причина, почему после первой итерации на поддержку документации уже забивают, а единственным местом знаний о системе становится код.
   

Среди всех испробованных вариантов лучшим местом для написания ТЗ оказался Google Docs:

1. Все в облаке и по ссылке. В описании задач разработчикам предоставляются ссылки на соответствующие разделы ТЗ.
2. Быстрый доступ и правки прямо на месте в случае ошибок или неточностей.
   
3. Комментарии и предложения по правкам.
   
4. Есть вся история изменений. Почти как GIT: -)
   
5. Можно давать права на чтение и редактирование.
   

Чего не хватает:

1. Жестких рамок по созданию ТЗ.
2. Дополнительных инструментов типа: проектирование модели данных, описание пользовательских историй и т.д.
   
3. Более удобной навигации.
4. Возможности поддерживать ссылочную целостность. Например, переименовали поле в модели данных, а на него есть ссылка в GraphQL API или REST.
   
5. Разделения прав, например, дизайнеру не нужно править API, а программисту — экраны дизайна. Разработчикам не нужно видеть стоимость фичей, по которым мы работаем с клиентом.
   

Конечно же, есть еще wiki или Confluence, но проблемы были аналогичные — отсутствие рамок и следования конкретному процессу.

Т.к. я люблю программировать и недавно «игрался» с PouchDB, вызов был принят :-)

Так появился
Spec Projector — место для хранения проектной документации для web-приложений.

По сути, это аналог Google Docs для ТЗ, где:

1. Можно определить состав фичей приложения по актерам и эпикам.
2. Написать пользовательские истории для каждой фичи.
   
3. Определить необходимые ресурсы и стоимость фичи для клиента.
   
4. Согласовать с клиентом стоимость фичей, итераций и всего проекта.
   
5. Передать истории дизайнеру — он загрузит отрисованные экраны.
   
6. Фронтенд-программист, смотря на истории, дизайн и прототип, спроектирует и опишет модель данных и API.
   
7. Бекенд-программист реализует модель данных и API.
   
8. Тестировщик закрепит чек-листы для проверки качества реализации фичей.
   

Менеджер проекта определяет функциональный состав в виде:

Актер X

1. Фича 1 — Эпик A
2. Фича 2 — Эпик B
   

Актер Y

1. Фича 3 — Эпик B
2. Фича 4 — Эпик C
   

Далее процесс по созданию каждой фичи:

1. Менеджер проекта пишет пользовательскую историю в режиме интервью с заказчиком в виде: я вижу, я могу.
2. Дизайнер, используя историю, рисует дизайн интерфейса и собирает прототип фичи в Figma, закрепляя фреймы.
   
3. Проджект-менеджер согласовывает дизайн и прототип с заказчиком.
   
4. Проджект-менеджер ставит задачу лидеру фронтенд-разработки на проектирование API в GitLab.
   
5. Лидер фронтенд распределяет задачи между своими разработчиками на проектирование API.
   
6. Фронтенд-разработчики определяют данные, которые нужно отправить/получить на соответствующих экранах дизайна для работы фичи. В результате получаем модель данных и вызовы API: REST или GraphQL.
   
7. Лидер команды фронтенд делает ревью спецификации и закрывает задачи.
   
8. Тестировщик закрепляет чек-листы для проверки качества реализации.
   

1. Лидер команды фронтенд ставит задачи на реализацию фичи на мок-данных (API еще не готов) для своих разработчиков.
2. Проджект-менеджер ставит задачу лидеру бекенд на разработку API.
   
3. Лидер бэкенда распределяет задачи между своими разработчиками на реализацию API.
   
4. Разработчики бэкенда реализуют API, пишут тесты.
   
5. Лидер бэкенда делает ревью и принимает код.
   
6. Фронтенд-разработчики переключаются с моков на API.
   
7. Лидер фронта делает ревью и принимает код.
   
8. Код деплоится, фича опубликована.
   

1. Тестировщик проверяет фичу по чек-листам.
2. Тестировщик находит баги и назначает задачи на лидера фронтенд.
   
3. Лидер распределяет баги между разработчиками и принимает код.
   
4. В случае ошибок в API фронтенд-разработчики создают задачи для бэкенд-разработчиков и ожидают фиксов.
   
5. Тестировщик все еще раз проверяет и закрывает задачу.
   

1. Проджект-менеджер проводит контроль качества.
2. Проджект-менеджер делает презентацию фичи клиенту.
   
3. Клиент выдает замечания.
   

1. Единый словарь терминов и синонимов c возможностью вставки в пользовательские истории, ассоциации с моделью данных, API и т.д. Например в ТЗ есть термин «Вакансия». Один разработчик к коде напишет class Vacancy другой class JobOffer. Так быть не должно.
2. Валидация ТЗ.
   
3. Экспорт модели данных, например, в Strapi или Django.
   
4. Экспорт REST API в Swagger.
   
5. Маркетплейс спецификаций, где можно взять/купить готовое ТЗ и адаптировать под свой проект.
   
6. Маркетплейс команд, с возможностью получения оценок от разных компаний по реализации Вашего ТЗ.
   
7. Интеграция с таск-трекерами. Все запланированные фичи можно экспортировать одной кнопкой с описанием задач и связями с ТЗ. Далее, отслеживая трек времени в задачах, можно сравнить разницу с оценками, т.е. насколько «вылетели».
   
8. Возможности выставлять счета клиентам и согласовывать стоимость фичей прямо в системе.

Главный вопрос к Вам, друзья, — как думаете — полезный продукт? Хотели бы Вы попробовать этот сервис для ведения своих проектов?

Ну и для тех кто дочитал — как пример, ссылка на документацию одного из наших проектов Team Projector на примере описания одной из фичей (лучше пока открывать в десктопе).

P.S. Есть у кого опыт продаж IT-сервисов? Очень ищем в команду.