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-сервисов? Очень ищем в команду.
Процесс разработки это последовательная формализация требований. От очень высокоуровневых и неформальных, к конечному коду.
Вы предлагаете инструмент, который сдвигает границу ответственности разработчиков и авторов ТЗ (аналитиков). Для аналитиков потребуется писать более формальные требования, чем они привыкли. А для разработчиков на вход будут поступать менее формальные.
По сути мы снижаем когнитивную нагрузку на разрабов путем снижения абстракции для них на вход, но повышаем нагрузку на авторов ТЗ - аналитиков, продактов или кто там их будет делать.
Если посмотреть, что это значит для бизнеса, то это не инструмент улучшения производительности команды, а инструмент для увольнения дорогих разработчиков и замены их на более дешевых :) Которые не справляются на высоких уровнях абстракции, зато справятся на низких. Дальше им можно нарубить задачек, посадить в жесткие рамки и работать. См. микротаскинг имени Бугаенко. https://www.youtube.com/watch?v=VLaGrUsCbYo
Интересный подход, имеет право на жизнь сам по себе. Но если прямо попробовать внедрить в сложившийся коллектив, то неизбежны конфикты, т.к. сдвиг рамки ответственности их вызывает всегда.
PS Если реально получится инструмент для микротаскинга, то будет интересно попробовать.
Прям для совсем микротаскинга не могу не посоветовать свой pet-проект(бесплатный):
https://greentask.in/
Сделал уже лет 5 назад. Удобно быстро набросать ТЗ, и по ссылке дать.
Есть разные плюшки вроде комментов, доступов и тд.
Сорри если не совсем в тему, может кому пригодится
а инструмент для увольнения дорогих разработчиков и замены их на более дешевых
Но это будет работать только с действительно опытными ПМ, аналитиком, дизайнером и техлидом. И то им следовало бы вырабатывать требования совместно, а не последовательно.
PM не пишет API или модель, а только требования, спека создается самими разработчиками на этапе планирования реализации фичей, перед уходом в код - что полезно, например ревью лидером команды (как самому опытному). Ответственность не сдвигается, каждый занимается своим делом и все формализовано и актуально.
По опыту работы над проектами, мы сделали вывод, что достаточно одному сильному разработчику поставить проект на "рельсы", а все остальное успешно могу "реализовать подмастерья" если задачи нормально описаны.
Вы для чего-то перепридумали Gherkin и BDD. Но такие спеки это всегда overhead и описание функциональности можно донести в гораздо более в удобном и понятном виде.
По поводу схем, их главное назначение - это дополнительный контекст или новое представление требований для разработчика. Не нужно тупо следовать всем стандартам UML (для описания бизнес-процессов лучше смотрите в BPMN) просто чтобы было.
Ну а по поводу "разработчик не хочет погружаться в контекст" - жаль ваших разработчиков. Это же просто конвеер получается, менеджеру тогда можно сразу условный UML2Code использовать.
Плюсую
Разработчики могут получать задачи в разных проектах, и у них нет времени погружаться в проект — им нужно четко выполнить, что написано в задании
Техническое решение без понимания контекста, и сделанное строго по заданию, вероятнее всего будет более низкого качества, так как оно может не учитывать интересы бизнеса и продукта, или вовсе оказаться неправильным.
Спасибо за развернутый отзыв. Как раз таки следующим этапом мы хотели внедрить описание сценариев на Gherkin для фичей с последующим экспортом их в GIT проекта.
Менеджеру не нужно ничего комиттить, он просто работает в сервисе. И в нем же видит результаты прохода тестов и покрытия его бизнес требований в коде.
По поводу "разработчик не хочет погружаться в контекст" не вижу тут ничего плохого например для бекенд программиста, которому нужно просто реализовать API. Если задача описана подробно, тогда просто сделай. Лучше сделать нормальное описание, чем потом утонуть в уточнениях и "митинагах".