Долгое время я считал авралы/переработки делом обычным - как в IT без этого? Но со временем я стал задумываться и понял, что все не так просто. В целом, понятно, что аврал - производная от планирования. Если мы что-то хотим сделать, но не успеваем, то приходится работать дополнительно по вечерам и/или в выходные. Нюанс в том, почему сложилась такая ситуация. Я выделил для себя три причины авралов со следующими условными названиями: ошибка планирования, тенденция планирования и отсутствие планирования.
Подробнее о каждом из типов.
Ошибка планирования
Это самый безобидный вариант. Сюда я включаю случаи, когда реально сработал какой-то из рисков (пусть даже и не заложенных изначально):
- тестирование фич(и) занимает больше времени, чем планировалось
- нужно срочно выполнить дополнительное тестирование какого-то модуля
- половина команды слегла с гриппом
- и т.п.
Я считаю этот вариант сравнительно безобидным, потому что известно, что надо сделать, чтобы аврал закончился (или даже не начинался, если удастся достичь цели в рамках рабочего времени). Конечно, плохо, что такая ситуация стала возможной, но есть шанс, что в будущем при планировании подобные риски будут учтены. Безусловно, если качество планирования не меняется, если похожие "неожиданные" проблемы возникают регулярно, то стоит задуматься: а способны ли участники проекта адекватно планировать? Или проблема вовсе не в неожиданности проблем?
Тенденция планирования
Порой можно встретить намеренное планирование, изначально включающее в себя авралы. Если руководитель в начале или середине цикла тестирования говорит, что "опять времени на тестирование выделили мало, поэтому каждому сотруднику придется отработать дополнительно 6 рабочих дней, давайте составим расписание, кто когда будет их отрабатывать", то это как раз тот самый случай. Изначально запланировано больше работы, чем отдел может выполнить. Изначально планируется, что люди будут регулярно перерабатывать. Зачастую еще и компенсация этих переработок довольно символическая.
Отсутствие планирования
Ну тут все просто. Мы смутно представляем, какой объем работ должны выполнить ("нужно полностью протестировать продукт"). Мы не оцениваем, сколько времени это займет. Возможно, мы даже не выделяем более или менее приоритетные вещи - просто тестируем "подряд". Не исключено, что мы даже толком не фиксируем, что мы уже протестировали и когда. Это, конечно, пример клинический, но идея, я думаю, понятна. В итоге две трети имеющегося времени мы работаем спокойно, а потом вдруг выясняем, что мы не успеваем протестировать значительную часть продукта. Начинается аврал и продолжается до самомго релиза (если тот наступает). При этом зачастую сам аврал довольно бессмысленнен, поскольку мы по-прежнему не знаем, что нужно делать в первую очередь, а что может подождать.
Какой из этих вариантов хуже? На мой взгляд, самый плохой случай - тенденция планирования: из людей осознанно и последовательно выжимаются все соки. Другие варианты лучше хотя бы тем, что остается шанс на улучшение: люди ответственные за планирование прочтут книги, пройдут тренинги, набьют шишки и станут строить более реалистичные и разумные планы. Неясно, конечно, как скоро это произойдет. Но тут и рядовые сотрудники могут поспособствовать в случае чего.
Другое дело - как отличить один вариант от другого? На мой взгляд, полезно задать руководителю простой вопрос: "Вот у нас на субботу запланирован аврал. Сегодня среда. Какой объем работ должна выполнить команда, чтобы аврал стал не нужен? Чего мы хотим достичь этим авралом?" Если руководитель может дать внятный ответ на этот вопрос, указать достижимую цель, то все не так плохо. Во-первых, он знает (а теперь и мы), к чему мы стремимся. Во-вторых, есть шанс соптимизировать работу и успеть все сделать до конца пятницы. Или - до середины субботы, и сидеть на работе не весь выходной, а только половину. И, кстати, не сидеть в выходной на работе, а работать.
Если же никакого критерия нет, и аврал состоится в любом случае - то речь, похоже не о варианте с ошибкой планирования, а что-то из оставшихся двух. Отличить отсутствие планирования от тенденции можно по времени, когда становится ясно, что авралы необходимы: если это конец цикла тестирования/разработки, то видимо планирование толком и не проводилось. Если же расписание авралов составляется на ранних этапах проекта, то тут явно что-то нечисто.
Авралы не всегда зло, нередко они действтельно необходимы. Зло - не задумываться, почему они стали необходимы и можно ли что-то с этим поделать. Как правило, можно, если сильно захотеть.
Четкого вам планирования и безавральной работы!
Комментариев нет:
Отправить комментарий