Comments 4
Вместо облегчения работы разрабов вы наоборот навесили свои обязанности на них. Надеюсь вас разгонят поганой метлой
Спасибо за комментарий! Как бы вы предложили подойти к решению проблемы по созданию больших объемов документации и поддержания его в актуальном состоянии?
Я навскидку вижу два варианта:
Продолжать опрашивать разработчиков силами технических писателей. При этом экономить время не получится.
Нанять отдельно разработчиков в команду технической документации, чтобы экономить время тех разработчиков, которые заняты созданием продуктов. Выглядит как рекурсия и нерациональное расходование ресурсов компании.
Может есть сценарий, который я не вижу, буду рада вашему ответу.
Как Вам такая идея: аналитика формулирует требования/ОПЗ - передает в разработку, разработка разрабатывает и вносит технические комментарии (openapi и проч), передает в тестирование, тестирование, проверяя моответстве разработки требованиям вносит (можно прямо в код - plantuml, например) фактуру для документации и передаёт техписам для оформления доков. На всех стадиях возможна дополнительная автоматизация, разумеется.
При таком подходе все равно получается "лапша", аналитики-разработка-тестирование-разработка документации. В реальности к моменту, когда закончено тестирование, команда хочет выпустить продукт, документация является блокером. Для техписа продукта такой подход означает периоды простоя и пиковых нагрузок. Мы же стремимся реализовать эти процессы параллельно, избавиться от пиковых нагрузок и по возможности избегать блокеров в виде документации.
Документация как сервис: как мы генерируем документы независимо от стека разработки