Как запланировать на 90% меньше задач в спринте
Наконец-то появилось время написать пост. Представим ситуацию: продукт стремительно растет, развиваются новые направления, соответственно, появляется и много стейкхолдеров, которым потенциально интересно решение разного рода задач.
Предположим есть 10-20 стейкхолдеров и 5 сотрудников, которым нужно закрывать задачи. Но все было бы просто, если бы не существовало рутины + дополнительных исследований, инициированных самим отделом (допустим, аналитики).
Каждому из заказчиков всегда важно решить задачу вчера как можно раньше. У всех высокий приоритет перманентно.
Планирование косвенно решает эту проблему, но никто не защищен от так называемых влетов: посчитать метрики, принести выводы к презентации C-level и так далее, спринт может изменяться динамично (но не всегда это хорошо).
1. Начинаем с простого: оцениваем цель задачи. Задаем вопрос: "Для чего нам это нужно?". Обычно ответ на этот вопрос есть всегда, но далеко не всегда задача после этого остается в первом приоритете. Часть задач по доработкам имеющихся инструментов может быть просто не нужна, так как на основной вопрос собранный инструмент отвечает.
2. Оцениваем масштаб задачи. Можно вот тут прочитать про различные методы оценки задач. Если понимаем, что задача комплексная и требует большого количества усилий, декомпозируем и отдаем кусками, чтобы с заказчиком быть в коннекте.
3. Заказчики между собой могут не общаться, поэтому важно на планировании подсветить конкретный капаситет на решение задач. На эти обсуждения особенно интересно наблюдать. Если не раскидывается, уводить в другой спринт или деприоритизировать.
4. Автоматизируем всё, что начинает повторяться. Если один и тот же запрос прилетает второй-третий раз, скорее всего, это уже не разовая задача, а кандидат на инструмент. Некоторые люди не хотят брать на себя ответственность за автоматизацию, но тут задача донести до стейкхолдера, что теперь вместо разовых "выгрузок" он будет смотреть в инструмент и отслеживать всё, что ему нужно. А еще лучше на все поставить алерты ⚠️
5. Если изначально понимаем, что планируются встречи / обсуждения, где потенциально потребуется ресурс аналитики (задача лида донести это), заранее броним несколько сторипоинтов для того, чтобы сотрудник мог подключиться.
6. Часть задач может перейти в другой спринт из-за отсутствия импакта на бизнес. А что тогда делать с новыми стратегическими направлениями? Тут задача лида донести то, что считается важным и какая общая стратегия с новыми вводными.
7. Учимся говорить нет, а не потом. Беклог из 200 задач может разрастаться бесконечно, есть желание всё взять и закрыть. Если задача потеряла актуальность, не влияет на решение или не соответствует текущей стратегии, то её лучше закрыть, а не бесконечно переносить между спринтами.
Иногда лучший способ быстрее закрывать задачи — перестать их брать и вас за это не уволят
😮 А что думаете вы? Может просто перестать брать задачи в принципе и наконец-то начать жить?
100 🔥 и выпускаю актуальный пост для подготовки к собесам в компании на разные позиции. Покажу интересные кейсы и ходы решения задач
zasqlpython.ru
Наконец-то появилось время написать пост. Представим ситуацию: продукт стремительно растет, развиваются новые направления, соответственно, появляется и много стейкхолдеров, которым потенциально интересно решение разного рода задач.
Предположим есть 10-20 стейкхолдеров и 5 сотрудников, которым нужно закрывать задачи. Но все было бы просто, если бы не существовало рутины + дополнительных исследований, инициированных самим отделом (допустим, аналитики).
Каждому из заказчиков всегда важно решить задачу вчера как можно раньше. У всех высокий приоритет перманентно.
Планирование косвенно решает эту проблему, но никто не защищен от так называемых влетов: посчитать метрики, принести выводы к презентации C-level и так далее, спринт может изменяться динамично (но не всегда это хорошо).
1. Начинаем с простого: оцениваем цель задачи. Задаем вопрос: "Для чего нам это нужно?". Обычно ответ на этот вопрос есть всегда, но далеко не всегда задача после этого остается в первом приоритете. Часть задач по доработкам имеющихся инструментов может быть просто не нужна, так как на основной вопрос собранный инструмент отвечает.
2. Оцениваем масштаб задачи. Можно вот тут прочитать про различные методы оценки задач. Если понимаем, что задача комплексная и требует большого количества усилий, декомпозируем и отдаем кусками, чтобы с заказчиком быть в коннекте.
3. Заказчики между собой могут не общаться, поэтому важно на планировании подсветить конкретный капаситет на решение задач. На эти обсуждения особенно интересно наблюдать. Если не раскидывается, уводить в другой спринт или деприоритизировать.
4. Автоматизируем всё, что начинает повторяться. Если один и тот же запрос прилетает второй-третий раз, скорее всего, это уже не разовая задача, а кандидат на инструмент. Некоторые люди не хотят брать на себя ответственность за автоматизацию, но тут задача донести до стейкхолдера, что теперь вместо разовых "выгрузок" он будет смотреть в инструмент и отслеживать всё, что ему нужно. А еще лучше на все поставить алерты ⚠️
5. Если изначально понимаем, что планируются встречи / обсуждения, где потенциально потребуется ресурс аналитики (задача лида донести это), заранее броним несколько сторипоинтов для того, чтобы сотрудник мог подключиться.
6. Часть задач может перейти в другой спринт из-за отсутствия импакта на бизнес. А что тогда делать с новыми стратегическими направлениями? Тут задача лида донести то, что считается важным и какая общая стратегия с новыми вводными.
7. Учимся говорить нет, а не потом. Беклог из 200 задач может разрастаться бесконечно, есть желание всё взять и закрыть. Если задача потеряла актуальность, не влияет на решение или не соответствует текущей стратегии, то её лучше закрыть, а не бесконечно переносить между спринтами.
В итоге хорошее планирование для меня — это не когда мы идеально распределили 30 задач между пятью людьми. Это когда из 50 входящих задач в спринт зашли 5. Остальные либо оказались не нужны, либо были объединены, автоматизированы, уменьшены до MVP-исследования или сознательно деприоритизированы. А про то, что качество выполнения задач может падать при увеличении их количества — отдельная история. Могу про это тоже написать.
Иногда лучший способ быстрее закрывать задачи — перестать их брать и вас за это не уволят
😮 А что думаете вы? Может просто перестать брать задачи в принципе и наконец-то начать жить?
100 🔥 и выпускаю актуальный пост для подготовки к собесам в компании на разные позиции. Покажу интересные кейсы и ходы решения задач
zasqlpython.ru