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. Если задача описана подробно, тогда просто сделай. Лучше сделать нормальное описание, чем потом утонуть в уточнениях и "митинагах".
Дополню сам себя: при это Gherkin выгодно использовать, если вы покрываете весь код автотестами. Но в нем описывается бизнес-логика приложения, у вас же я вижу требования, в том числе, к интерфейсу.
Спасибо! Очень интересный продут!
Думаю, стоит попробовать :)
Спасибо, отпишусь Вам в личку что бы сделать аккаунт.
Очень интересно. Я как проджект попробовал бы со своими командами.
Почему?
Имеется ввиду разработчикам в штате. Компания продала фичу за 5000$ по ставке 40$ за разработчика, а платит разработчикам 20$. Все остальное это менеджмент, прибыль, развитие и т.д. Зачем видеть разработчику финансовые взаимоотношения компании с их клиентами.
https://vk.cc/85tILr
Хорошо, что это не возможно, не к чему стремиться :)
Инвайт плиз
любопытно, если посадить несколько грамотных человек, которые будут по сумбурным рассказам заказчиков писать первоначальное ТЗ для оценки объема, а потом команды разработчиков смогут предложить свою цену по этому ТЗ, то получится специализированная биржа для приложений, это нам надо
Бинго, именно об этом мы и думали :-) Созвонимся? :-)
По идее да. Если Вы сможете написать историю в формате
Я как Клиент хочу Сделать заказ на сайте:
я вижу список товаров,
я могу нажать на кнопку добавить товар в корзину.
То по сути этих данных уже хватит что бы отрисовать дизайн и прототип.
Ничего не понимаю в ИТ. Может проверим на мне как клиенте? Думаю, это очень перспективно!
Я не знаю точно какие плагины (не я конфигурю), но по факту джира превращается в инструмент планирования и управления проектом: - стори, эпики, бэклог и тд. Там же можно завести и баги. Гитлаб настроен на проставление комментов под сторями.. вообщем, там все есть. Другое дело - джира стоит денег, не все потянут на своих проектах
Джира в данном случае это такс-менеджер. SP немного другое. Где Вы в джире планируете фичи (фича не задача, одна фича много задач)? Описываете историю? В каком формате? Как делаете описание для разработчиков?
Пишется junior, а не juniour
Спасибо за замечание, но в этой статье не нашел "juniour"
Комментарий недоступен
Сейчас это бета, забыли написать.
1. Спасибо, исправим.
2. Поправим.
3. В тестовом да, в качестве презентации. А так система прав еще в разработке.
Комментарий недоступен
Написал в личку
Круто! Очень хотелось бы глянуть и потестить на своей команде
Спасибо, отписал в личке.
Это все круто-классно! Но разве самый большой затык в инструменте, а не в том что заказчик хочет быстро и красиво, но не знает что именно?
Это уже вопрос сбора требований. Общение с пользователи и т.д.
В любом случае от чего-то придется отталкиваться. Написать пользовательскую историю, отрисовать дизайн, кликабельный прототип или N, проверить на фокус группе, снова поправить требования. Будет хранится все история работы над фичей.
У меня один вопрос - эта штука пригодна для написания ТЗ клиентом? Поймет ли человек без бэка в ИТ, что куда писать?
Я бы попробовал с своей командой, а то сами уже в Gdocs сидим 4й год
Любопытный продукт. Я для этого же использую jira с соотв. плагинами
А можно если не сложно ссылки какие плагины? Будет очень полезно.
Сложновато, еще учить заказчика пользоваться сервисом?
Зачем просто скинуть прямую ссылку. Он увидит состав функций, описание, дизайн, стоимость, этапы.
Пример у мне нужно уточнить определенные вопросы по определенным этапам.
Например, в части расчетов габариты деталей, их стоимость.
На другом этапе мне нужно утонить методику расчетов.
Такое "общение" с заказчиком предусмотрено?
И насколько просто оно устроено?
Я пока только "заблудился" в интерфейсе.
Хотелось бы видеть компактнее этапы работы и блоки модули.
Сложно ориентироваться, мне кажется...
Мы думали о чатах и комментариях позже. Пока предполагаем, что это конечное место где заполняется самая последняя актуальная информация. Т.е. обсуждается все на стороне любыми способами, сюда заносятся выводы.
Отличная идея, тоже приходила в голову мысль, что не хватает специализированных сервисов для создания ТЗ. Будет интересно посмотреть за развитием вашего продукта. Как можно потестировать его в своей команде?
Отправил доступы в личку.
Привет! Мы ваши "коллеги по ТЗ инструментам", представляем сервис по разработке ТЗ (spexfy.com). Было интересно ознакомиться с вашей презентацией и отзывами. Мы подходим к документу ТЗ немного под другим углом и с большей ориентацией на заказчика. Есть еще ряд отличительных моментов. Единственное, ваше видение "через ТЗ к фриланс площадке", мне кажется потерей времени и денег, хотя бы по той причине, что есть стоимость привлечения клиента и здесь вы будете жестко конкурировать с фриланс биржами.
Интересный продукт, по типу квиза. У нас же задание именно на ПО.
По поводу фриланс площадки не совсем понял.
Интересный продукт!
Однако, сломана авторизация через гитлаб (не заходит). Можно попросить учётку?
https://specprojector.com/
Как заказчик уже год мечтаю о "чёрном ящике" : что-то на вход, а на выходе черновик ТЗ. Возможно ли сейчас в год ChatGPT и К такое? Вы двигаетесь в этом направлении? Хотелось бы пообщаться...
The best projector cine beam
https://getprojectorsnow.blogspot.com/2021/05/lg-pf50ka-portable-full-hd-led-smart.html
https://ilearn.stanford.edu/eportfolios/1492/Home/Most_Useful_LED_Projector_HD_LG_PF50KA_Portable_Full_HD