Спринт хорош на поддержке изменений готового продукта (сопровождение с небольшими доработками), когда от заказчика идут потоком хотелки на доработку. Вот тут да, мы говорим в какой спринт мы это готовы сделать, сколько это стоит в трудоёмкости, и заказчик понимает что в какой спринт будет сделано и когда ждать свои пожелания. И до спринта должно быть планирование, может прям с заказчиком).
А когда мы разрабатываем новый продукт или его новую версию, делаем доработки по контракту - там спринты выглядят странновато... Там уместенее водопадный гант + разделение на PI или релизы (мажорные, минорные и т.д.) - так понятнее. Но спринты все равно живы))). Хотя задачи просто перелазят из одного в другое тут они служат для самого разработчика или аналитика - вот мой фронт работ на 2 недели. Неделя - мало, можно не успеть получить информацию, 3 - много, сложно накидывать работы на большие сроки. Хотя можно и на месяц планировать, если люди привыкнут.
Допустим специалист действительно должен все это делать. Для этого ему нужна квалификация и собственные скилы. А если посмотреть на вакансии самих НR, то увидим максимум опыт от 0,5 до 2-3 лет в найме... Все.
Основная масса специалистов даже теоретически не может выполнять описанные задачи, ввиду отсутствия квалификации.
КТЗ штука прикольная, но не решает проблему непонятных контактных требований. Там дедлайн никуда не подвинуть, даже если ничего не понятно, часто надо самому придумать решение, обычно это делают лиды, аналитики и немного архитектор).
Непонятен ваш флоу. У нас одного взгляда не такую задачу достаточно, чтобы разработчик престо перекинул на аналитику. Понятно, что все аналитики на входе проработать и вникнуть не успевают, но если нужна аналитика - не нужно считать ктз, надо отправить задачу БА/СА.
Наверное тоже не очень корректно сравнивать работу конструктора на большом проекте с мобильными приложениями в ИТ. Тогда уже давайте сравнивать крупный инженерный проект с разработкой крупной системы, где зарегулировано все и на каждый чих есть инструкция. Например, банковская система, крупные медицинские системы, федеральные проекты.
А разработку небольшого приложения корректнее сравнивать с гаражом, где инженерная мысль имеет возможность для полёта.
Спринт хорош на поддержке изменений готового продукта (сопровождение с небольшими доработками), когда от заказчика идут потоком хотелки на доработку. Вот тут да, мы говорим в какой спринт мы это готовы сделать, сколько это стоит в трудоёмкости, и заказчик понимает что в какой спринт будет сделано и когда ждать свои пожелания. И до спринта должно быть планирование, может прям с заказчиком).
А когда мы разрабатываем новый продукт или его новую версию, делаем доработки по контракту - там спринты выглядят странновато... Там уместенее водопадный гант + разделение на PI или релизы (мажорные, минорные и т.д.) - так понятнее. Но спринты все равно живы))). Хотя задачи просто перелазят из одного в другое тут они служат для самого разработчика или аналитика - вот мой фронт работ на 2 недели. Неделя - мало, можно не успеть получить информацию, 3 - много, сложно накидывать работы на большие сроки. Хотя можно и на месяц планировать, если люди привыкнут.
Не буду про нейросеть... выше написали).
Допустим специалист действительно должен все это делать. Для этого ему нужна квалификация и собственные скилы. А если посмотреть на вакансии самих НR, то увидим максимум опыт от 0,5 до 2-3 лет в найме... Все.
Основная масса специалистов даже теоретически не может выполнять описанные задачи, ввиду отсутствия квалификации.
КТЗ штука прикольная, но не решает проблему непонятных контактных требований. Там дедлайн никуда не подвинуть, даже если ничего не понятно, часто надо самому придумать решение, обычно это делают лиды, аналитики и немного архитектор).
Непонятен ваш флоу. У нас одного взгляда не такую задачу достаточно, чтобы разработчик престо перекинул на аналитику. Понятно, что все аналитики на входе проработать и вникнуть не успевают, но если нужна аналитика - не нужно считать ктз, надо отправить задачу БА/СА.
Наверное тоже не очень корректно сравнивать работу конструктора на большом проекте с мобильными приложениями в ИТ. Тогда уже давайте сравнивать крупный инженерный проект с разработкой крупной системы, где зарегулировано все и на каждый чих есть инструкция. Например, банковская система, крупные медицинские системы, федеральные проекты.
А разработку небольшого приложения корректнее сравнивать с гаражом, где инженерная мысль имеет возможность для полёта.