Пристрелите меня, или опять дедлайн.

Не знаю как у вас, а у меня давно исчезла мысль о том, что в работе может не быть авралов. Причин множество: неправильная оценка сложности и задач и сроков для их реализации, задержки утверждения документов или предоставления информации по проекту со стороны заказчика, человеческий фактор. А в итоге получаем неподъемное количество работы на пару со стрессом. Причем, не всегда проблемы могут быть внутренние. Сколько раз мне приходилось наблюдать и участвовать в проектах, в которых все идет по плану. Спокойно и размеренно. Функциональность проработана, все необходимые тесты имеются и пройдены, документация написана. И вот остается день – два до сдачи, и… От заказчика приходит гневное письмо, что он изучил последнюю версию продукта и понял, что все не так и надо изменить то-то и то-то, причем сделать это необходимо в кратчайшие сроки.

Да, его можно послать. Сослаться на процедуру формирования требований и цикл разработки. Но в таком случае имеется очень большая вероятность, что дальнейших взаимоотношений с этим заказчиком просто не будет. Согласен, клиентов тоже можно и нужно воспитывать, особенно если предполагаются длительные взаимоотношения. А если это первый контакт? Иногда приходится идти на уступки.

Какие имеем симптомы аврала:

• Давление и стресс


• Крайне сжатые сроки


• Не четко поставленные задачи


• Неопределенность

Что с этим всем делать?

1. Успокоиться.
Я думаю не нужно объяснять, что в напряженном состоянии продуктивная работа практически невозможна. Допускается большее количество ошибок, тратиться время на их поиск и устранение. Падает внимательность. В таких случаях нужно не паниковать, а работать над снижением неопределенности в проекте.

2. Определите требования.
Иногда, это совсем нетривиальная задача. У некоторых менеджеров, если прижать им ... сроки в проекте, напрочь отшибается способность внятно излагать свои мысли. “Все не так, нужно все переделать” - это стандартный вариант, к которому, я думаю, все уже привыкли. А вот фраза – “Этот зеленый - не достаточно тяжелый” в свое время вогнала меня в короткий ступор. Так что, поняв что от вас хотят, сформируйте список и проговорите его повторно (с менеджером или заказчиком). Получая на каждый пункт подтверждение. Так вы будете уверены в вашем взаимопонимании.

3. Приоритезируйте задачи.
Если у вас имеется список из 10 задач с трудозатратами по часу на каждую, и всего один вечер в распоряжении,к гадалке не ходи - не успеть. Поэтому все задачи нужно отсортировать по приоритету. Лучший вариант - если это сделает сам заказчик. Потому, что для него, в предверии предстоящей презентации начальству, может оказаться более важным "подвинуть эту зеленую фишку левее, пикселей эдак на 6", чем исправить проблему импорта данных. При том, что в случае успешной демонстрации продукта, появится возможность получить еще неделю-другую времени на "рефакторинг".

4. Повышайте информированность всех заинтересованных в проекте лиц.
Меньше всего ваш заказчик (или менеджер) хочет узнать от вас в день сдачи новой версии продукта, что вы не успеваете. Поверьте, большинство адекватных управленцев готовы смириться со сдвигом сроков на 1-2 дня при итерации, скажем, в две недели. Но вот неопределенность и непредсказуемость никто не любит. Сообщите об изменении сроков и функциональности всем заинтересованным лицам. Успокойте их этим. Заодно получите возможность работать с меньшим давлением. Логично будет предоставлять им отчеты о ходе работ вкупе с описанием возникших проблем и методами их решения.

Кроме того, стоит избегать связи с заказчиком, при которой отсутствует возможность вести лог обращений. То есть по телефону, заказчик может сделать акцент на одних задачах – а к сдаче потребовать совсем другие. Используя для связи электронную почту, этих ситуаций можно избежать, так как всегда будет возможность сослаться на конкретное письмо.

Ну и, конечно же, если вы исполнитель и контактируете напрямую с заказчиком – простая рекомендация: ставьте менеджера проекта (да и всех заинтересованных лиц) в копию. Тогда во время отчета начальству не придется объяснять ‘чем вы все это время занимались’.

Да, подобные ситуации нельзя назвать здоровыми. Все знают, как нужно организовывать работу – но на практике, к сожалению, все бывает иначе.

5. Составьте списки и планы работ.
Помню, когда мне приходилось сидеть над срочным проектом по 16-18 часов к ряду. Мне здорово помогали списки. По себе я знал, что мой мозг перестанет быть способным к интеллектуальной деятельности после 7-9 часов работы. Поэтому я облегчал себе задачу. Первый час - два я тратил на детальную декомпозицию задач и формирование ИСР. В итоге, даже в состоянии абсолютной невменяемости, я мог довольно продуктивно трудиться. Потому что всю сложную с виду работу разложил на простейшие задачи.

Если же в вашем распоряжении есть несколько дней - разумно будет составить диаграмму Ганта.

6. Группируйте задачи
Имеет смысл, по возможности, однотипные задачи решать за один подход, а не раскидывать их на все время работ. За счет этого можно выиграть время – так как сократятся периоды переключения между задачами и будет тратится меньше времени на подготовительные работы, как то: открытие кода, изучение документации, коммуникации и так далее.

Внимательный читатель, я думаю, заметит - а не о базовых ли понятиях управления проектами идет речь. Именно о них. Есть задача, дефицит ресурсов и сроки к которым необходимо получить некоторый результат. Разница, пожалуй, только в стрессе, который сопутствует авралам.

Мне кажется, что при всем негативе, который несут в себе авральный работы, из них можно извлечь и пользу. Вот что я выделил для себя:

• Авралы заставляют мобилизоваться. Работа на пределе позволяет узнать больше о своих возможностях


• Появляется возможность находить новые и действительно эффективные способы решения задач


• В некоторых случаях авралы способствуют сплочению коллектива

Но это все только в том случае, если подобные ситуации являются исключительными. Если весь процесс построен на “экстремальном программировании” - это повод серьезно задуматься о смене работы. (Однажды, на собеседовании кандидат так расшифровал мне этот термин: доработка бизнес - логики и выгрузка проекта на боевые серверы без тестирования, в пятницу вечером).

Ну и последнее – будьте честны с менеджерами, заказчиками и самим собой. Не стоит при получении длинного списка требований и нереальных сроков брать под козырек и говорить ‘будет сделано’. Этим вы конечно всех успокоите, но и возьмете на себя ответственность за чужие ошибки и эти принятые задачи вам же потом придется решать.