Spec Projector — сервис по разработке технического задания на программные продукты
О том, как разработать техническое задание для вашего ИТ-продукта, навести порядок в процессах разработки и автоматически создавать описание задач для программистов.
О том, как разработать техническое задание для вашего ИТ-продукта, навести порядок в процессах разработки и автоматически создавать описание задач для программистов.
Процесс разработки это последовательная формализация требований. От очень высокоуровневых и неформальных, к конечному коду.
Вы предлагаете инструмент, который сдвигает границу ответственности разработчиков и авторов ТЗ (аналитиков). Для аналитиков потребуется писать более формальные требования, чем они привыкли. А для разработчиков на вход будут поступать менее формальные.
По сути мы снижаем когнитивную нагрузку на разрабов путем снижения абстракции для них на вход, но повышаем нагрузку на авторов ТЗ - аналитиков, продактов или кто там их будет делать.
Если посмотреть, что это значит для бизнеса, то это не инструмент улучшения производительности команды, а инструмент для увольнения дорогих разработчиков и замены их на более дешевых :) Которые не справляются на высоких уровнях абстракции, зато справятся на низких. Дальше им можно нарубить задачек, посадить в жесткие рамки и работать. См. микротаскинг имени Бугаенко. https://www.youtube.com/watch?v=VLaGrUsCbYo
Интересный подход, имеет право на жизнь сам по себе. Но если прямо попробовать внедрить в сложившийся коллектив, то неизбежны конфикты, т.к. сдвиг рамки ответственности их вызывает всегда.
PS Если реально получится инструмент для микротаскинга, то будет интересно попробовать.
Прям для совсем микротаскинга не могу не посоветовать свой pet-проект(бесплатный):
https://greentask.in/
Сделал уже лет 5 назад. Удобно быстро набросать ТЗ, и по ссылке дать.
Есть разные плюшки вроде комментов, доступов и тд.
Сорри если не совсем в тему, может кому пригодится
а инструмент для увольнения дорогих разработчиков и замены их на более дешевых
Но это будет работать только с действительно опытными ПМ, аналитиком, дизайнером и техлидом. И то им следовало бы вырабатывать требования совместно, а не последовательно.
PM не пишет API или модель, а только требования, спека создается самими разработчиками на этапе планирования реализации фичей, перед уходом в код - что полезно, например ревью лидером команды (как самому опытному). Ответственность не сдвигается, каждый занимается своим делом и все формализовано и актуально.
По опыту работы над проектами, мы сделали вывод, что достаточно одному сильному разработчику поставить проект на "рельсы", а все остальное успешно могу "реализовать подмастерья" если задачи нормально описаны.