При таком подходе все равно получается "лапша", аналитики-разработка-тестирование-разработка документации. В реальности к моменту, когда закончено тестирование, команда хочет выпустить продукт, документация является блокером. Для техписа продукта такой подход означает периоды простоя и пиковых нагрузок. Мы же стремимся реализовать эти процессы параллельно, избавиться от пиковых нагрузок и по возможности избегать блокеров в виде документации.
Спасибо за комментарий! Как бы вы предложили подойти к решению проблемы по созданию больших объемов документации и поддержания его в актуальном состоянии?
Я навскидку вижу два варианта:
Продолжать опрашивать разработчиков силами технических писателей. При этом экономить время не получится.
Нанять отдельно разработчиков в команду технической документации, чтобы экономить время тех разработчиков, которые заняты созданием продуктов. Выглядит как рекурсия и нерациональное расходование ресурсов компании.
Может есть сценарий, который я не вижу, буду рада вашему ответу.
9:55 AM
При таком подходе все равно получается "лапша", аналитики-разработка-тестирование-разработка документации. В реальности к моменту, когда закончено тестирование, команда хочет выпустить продукт, документация является блокером. Для техписа продукта такой подход означает периоды простоя и пиковых нагрузок. Мы же стремимся реализовать эти процессы параллельно, избавиться от пиковых нагрузок и по возможности избегать блокеров в виде документации.
Спасибо за комментарий! Как бы вы предложили подойти к решению проблемы по созданию больших объемов документации и поддержания его в актуальном состоянии?
Я навскидку вижу два варианта:
Продолжать опрашивать разработчиков силами технических писателей. При этом экономить время не получится.
Нанять отдельно разработчиков в команду технической документации, чтобы экономить время тех разработчиков, которые заняты созданием продуктов. Выглядит как рекурсия и нерациональное расходование ресурсов компании.
Может есть сценарий, который я не вижу, буду рада вашему ответу.