Как всегда, идея для очередной заметки появляется после прочтения чужого материала. Вот и в этот раз статья про управление приоритетами подтолкнула к написанию данного материала.
Сразу оговорюсь, в материале ниже речь пойдёт только об изменениях, связанных с разработкой или доработкой ПО и не относится к изменениям, проводимым над оборудованием или серверным ПО.
Итак, условия задачи следующие. Есть самое обычное подразделение с n разработчиками, известной скоростью выполнения задач и средняя скорость появления новых задач. При этом новые появляются быстрее, чем обрабатываются накопленные ранее.
Введём дополнительное условие. Очередной пользователь\руководитель среднего звена получил по шее от вышестоящего руководителя за сорванную автоматизацию (не проконтролировал, не согласовал ТЗ, не принял работу и т.д.). Что имеем в итоге? Правильно, прибегает весь взмыленный заказчик с криками «а ну-ка быстро всё сделайте, надо было ещё вчера, это очень важно! Этим вопросом уже интересуется <здесь имя очень главного очень авторитетного руководителя>».
Для начала приведу наверняка известный всем квадрат выбора приоритетов. Она нам пригодится при дальнейшем рассмотрении вопроса. Итак, разберём фразу подробнее. «Нужно было ещё вчера» — пользователь пытается охарактеризовать свою задачу как очень срочную. «Это очень важно» — пытается перевести в разряд «Важное». То есть вписать свою задачу в квадрант 1. А теперь постараемся адекватно оценить, действительно ли задача стоит именно так?
Что заказчик делал предыдущие несколько дней\недель\месяцев? Правильно, чаще всего ничего. Срочная задача? Теперь уж вряд ли. Уже легче, свели задачу к квадрату 2. Теперь вопрос приоритетов. Здесь уже привожу локальный опыт, как говорится. В начале года руководитель подразделения составляет план проектов на год. Для этого опрашиваются топ-менеджеры компании и (иногда) руководители подразделений. В план проектов попадают по-настоящему первоочередные задачи. Чаще всего, их не больше 7 (+\- 2). Задача нашего пользователя относится к этим проектам? Если нет — спускаем на уровень 4, иначе оставляем на уровне 2.
Но это частный случай.
Рассмотрим приоритезацию задач на общих случаях.
В квадрат 1:
- Ошибки стабильного релиза после обновления
- Доработка \ разработка задач из плана проектов на год
- Задачи от топ-менеджеров
В квадрат 2:
- Важные задачи не из плана проектов на год
- Ошибки в стабильном релизе после обновления, не нарушающие основной бизнес-процесс (например, перестал открываться отчёт, слетели права доступа…)
- Задачи на развитие систем (генерируются внутри IT отдела: рефакторинг кода, оптимизация интерфейса, административные инструменты…)
- Ошибки обменов данными между системами
- Доработка\разработка участков автоматизации, которая может быть заменена ручным трудом либо иными средствами (например, Excel. Сюда же попадают особые печатные формы, которые можно получить ручным редактированием существующих).
В квадрат 3:
- Ошибки в тестовой среде, обнаруженные пользователем
- Задачи с чётко обозначенным сроком не из плана проектов на год
В квадрат 4:
- Всё остальное
В какой момент расставлять приоритеты? Ну, тут Scrum Guide нам в помощь. Еженедельный грум бэклога позволяет достаточно оперативно включать задачи в план спринта или перепланировать текущий. При этом, если задача на самом деле срочная и важная, об этом наверняка сообщат заинтересованные лица в виде письма или телефонного звонка.
Кто должен управлять приоритетами? Вопрос сложный. У нас введена потрясающая по своей универсальности должность под названием «ведущий специалист по разработке» на стыке должностей team Lead’а и бизнес-аналитика а так же немного QA и менеджера по изменениями. Чем занимается этот человек? Грумит бэклог, планирует спринты, расставляет приоритеты, собирает требования, пишет ТЗ, немного пишет код дабы не потерять квалификацию окончательно, как истинный тимлид помогает остальным разработчикам в написании кода, составляет Code Guide и следит за его соблюдением. А ещё немного управляет изменениями: составляет план релизов, план изменений, план откатов и т.д.
Работает такая схема? Да, работает. Достаточно успешно. Причём настолько, что за последние несколько месяцев мы получили стабильное «сгорание» бэклога (т.е. задачи обрабатываются быстрее, чем появляются новые). Такими темпами скоро задачи на развитие вытеснят пользовательские требования. Но это уже отдельная история.
И помните, любая задача, как хорошее мясо, должна немного полежать…
Добавить комментарий