Спасибо за такой вдумчивый комментарий, очень точные наблюдения.
Про «я, как администратор, хочу сбросить пароль, чтобы сбрасывался пароль» — с такими крайними кейсами, к счастью, не сталкивались :) Но в целом вы правы: сам шаблон не гарантирует качества. У нас это скорее микрофреймворк, чтобы задача была написана по-человечески.
Смысл в другом — определить базовую работу пользователя, которую мы закрываем. Это зона ответственности PM. Дальше важно, чтобы этот контекст доходил до всех по цепочке: не просто сделать кнопку, а понять, зачем она нужна. Если этого нет, никакая структура не поможет.
По статусам — да, они не про причину, а про сигнал. Нам важно было сначала увидеть, где именно в процессе начинаются проблемы, а уже потом разбираться, почему это происходит.
Причины каждый раз разные, поэтому универсального ответа нет. Из практики смотрим на cumulative flow diagram: если где-то зона начинает раздуваться, значит туда и идем копать.
По тестированию: из того, что реально прижилось — раннее подключение QA. Когда задача еще не дошла до разработки, QA уже смотрят требования, понимают, какие части продукта затронуты, пишут тест-кейсы.
Это сильно снижает количество сюрпризов в конце и ситуаций, когда вместо тестирования начинается попытка оживить продукт.
Спасибо за вопросы — видно, что вы глубоко в теме 🙂
1. В понедельник, когда завершается текущий спринт, сразу начинается новый, так как его планирование проходит ближе к концу второй недели. За счет этого нет паузы между спринтами.
2. Охват считаем по продуктовой аналитике - по количеству пользователей, вовлеченных в дорабатываемый или связанный функционал. Импакт - по сути субъективная метрика, оцениваем эмпирически.
3. Часть задач действительно удалили. Много дублей и связанных задач объединили. Остальное распределяем по спринтам при регулярной работе с бэклогом.
4. Всегда есть задачи, которые не требуют глубокой проработки: ошибки, техдолг и подобные вещи.
5. Квартальные цели согласуются со стратегией от стейкхолдеров. Планируем примерно на 2-3 квартала вперед, так как рынок и требования аудитории меняются достаточно быстро.
Спасибо за такой вдумчивый комментарий, очень точные наблюдения.
Про «я, как администратор, хочу сбросить пароль, чтобы сбрасывался пароль» — с такими крайними кейсами, к счастью, не сталкивались :) Но в целом вы правы: сам шаблон не гарантирует качества. У нас это скорее микрофреймворк, чтобы задача была написана по-человечески.
Смысл в другом — определить базовую работу пользователя, которую мы закрываем. Это зона ответственности PM. Дальше важно, чтобы этот контекст доходил до всех по цепочке: не просто сделать кнопку, а понять, зачем она нужна. Если этого нет, никакая структура не поможет.
По статусам — да, они не про причину, а про сигнал. Нам важно было сначала увидеть, где именно в процессе начинаются проблемы, а уже потом разбираться, почему это происходит.
Причины каждый раз разные, поэтому универсального ответа нет. Из практики смотрим на cumulative flow diagram: если где-то зона начинает раздуваться, значит туда и идем копать.
По тестированию: из того, что реально прижилось — раннее подключение QA. Когда задача еще не дошла до разработки, QA уже смотрят требования, понимают, какие части продукта затронуты, пишут тест-кейсы.
Это сильно снижает количество сюрпризов в конце и ситуаций, когда вместо тестирования начинается попытка оживить продукт.
Спасибо за вопросы — видно, что вы глубоко в теме 🙂
Отвечу по пунктам.
1. В понедельник, когда завершается текущий спринт, сразу начинается новый, так как его планирование проходит ближе к концу второй недели. За счет этого нет паузы между спринтами.
2. Охват считаем по продуктовой аналитике - по количеству пользователей, вовлеченных в дорабатываемый или связанный функционал. Импакт - по сути субъективная метрика, оцениваем эмпирически.
3. Часть задач действительно удалили. Много дублей и связанных задач объединили. Остальное распределяем по спринтам при регулярной работе с бэклогом.
4. Всегда есть задачи, которые не требуют глубокой проработки: ошибки, техдолг и подобные вещи.
5. Квартальные цели согласуются со стратегией от стейкхолдеров. Планируем примерно на 2-3 квартала вперед, так как рынок и требования аудитории меняются достаточно быстро.
О, это отличное решение. Спасибо!
Рад, что понравилось!