Работа и управление
Как IT команде успевать в сроки

Как IT команде успевать в сроки

Рецепт, который был мной придуман под команду, чтобы добиться попадания в сроки. Протестирован слабо, но признан успешным :)

Рецепт, который был мной придуман под команду, чтобы добиться попадания в сроки. Протестирован слабо, но признан успешным :). О том, почему в целом эта затея провалена — в другой заметке.

  1. Задачи оценивают только исполнители. Не допускать «ребят, да чё там — возьмите эту ещё — она же лёгкая». При этом должны присутствовать незаинтересованные люди, имеющие компетенции в данной области, чтобы сроки были более-менее реальными.
  2. Морозим список задач на итерацию. Никакого «ещё вот это надо успеть и вот это». Да, мир бизнеса довольно часто меняется. Но давайте на пару недель будем морозить наше представление о том, что нужно — тогда хоть что-то сможем сделать.
  3. Исследовать до того, как брать. Пока непонятно, как решать, не берём в работу, а исследуем. Таким образом — исследование — это тоже задача, она ограничена во времени, у неё есть результат — план того, как мы будем делать с объяснением, почему мы делаем именно так.
  4. Блокируем зависимые “ресурсы” до исполнения. Человек блокируется на исполнение самой приоритетной задачи. Освобождается только после исполнения всей приоритетной задаче, переходя к приоритету ниже. Так реально важные задачи будут делаться (первыми), а неважные — оставаться неважными.
  5. Закладываем 50% времени на интересные задачи, внезапность и поддержку. На планировании исходим из того, что можем потратить на обязательные задачи только половину времени. Всё это — чтобы было время на авралы, болезни, лень и прочие вещи, растягивающие сроки. Мы не боремся с ними, мы их учитываем. А если всё же команда всё успела раньше — есть время улучшить инфраструктуру, порефакторить код, покрыть пробелы в тестировании…
  6. Катим большие задачи только в начале итерации. Иначе это приводит к затяжной разработке, растягиванию сроков — мы ведь вот-вот всё закончим!
  7. Merge делает автор PR, есть необходимые approve-ры (2 штуки от разных членов команды). Таким образом есть личная ответственность за pull-request у автора.

Это без очевидных вещей типа ограниченности итерации, тестирования, ежедневных летучек (стендапов), таск-трекинга и подобного.

Как он получился? На протяжении нескольких итераций я наблюдал за ходом разработки на позиции TeamLead. На протяжении нескольких ретроспектив записывал недовольство. Потом вечером сел и написал решения проблемам. На утро некоторые вещи отполировал, некоторые объединил.

Подходит ли он вам? Не факт — "у каждого офиса запах особый".

Главное — наблюдать, определиться с проблемами, их решениями и действовать (обозначить правила игры и их контролировать).