В отличие от процессной деятельности, где все операции отработаны и регламентированы, проектная требует от исполнителей значительной самостоятельности. Разработчики набраны в проект, чтобы делать новый продукт, а не просто отбывать в офисе положенное время. Делать новый продукт – значит преодолевать возникающие сложности путем самостоятельного поиска решений, а не ждать руководящих указаний. Искать решения трудно – как по объему работы, так и психологически, ведь никто не знает, сколько времени займет поиск и приведет ли к желаемому результату. Чтобы не опускать руки, разработчикам требуется дополнительная мотивация, созданию которой были посвящены предыдущие разделы. Однако созданную мотивацию нужно еще и сохранять.
Мотивация разрушается, когда исполнитель не получает положительной обратной связи по итогу хорошо сделанной работы. Наиболее распространенным случаем неправильной обратной связи является изменение заданий в ходе спринта: «Задача А, которую вы делали, пока не нужна, делайте сейчас Б». Казалось бы, ничего особенного – но ради задачи, которая не так уж и нужна, никто не захочет напрягаться. Даже единичный случай изменения заданий может подорвать доверие к проекту, а если такие изменения возникают регулярно – команда гарантированно перейдет в режим «не торопись выполнять указание, все равно отменят».
Поэтому поддержание мотивации в команде требует защиты исполнителей от несвоевременных требований.
Защита исполнителя заключается в том, что все новые идеи и требования стейкхолдеров включаются в расписание проекта, а не принимаются к немедленному исполнению. Звучит просто, но при выполнении чревато серьезными конфликтами («Я вам плачу деньги, делайте, что я сказал»). Поэтому ПМ должен придерживаться специального метода.
1. Короткие спринты. Ближайший момент, в который возникшие требования стейкхолдеров могут быть взяты в работу, – это планирование следующего спринта. В случае коротких спринтов (одна неделя) срок ожидания будет приемлем для большинства стейкхолдеров, и риск конфликта сведен к минимуму. Однако короткие спринты требуют более детальной декомпозиции задач и создают большую нагрузку на разработчиков (меньше внутренних буферов на устранение возникающих проблем). Поэтому ПМ определяет оптимальную продолжительность спринтов – короткую в случае активных стейкхолдеров и относительно простых задач, и более длительную – для спокойных стейкхолдеров и сложных задач.
2. Объяснение рисков. Грозить увольнением каждый раз, когда у стейкхолдеров возникают новые требования к проекту, – не лучшая линия поведения. ПМ защищает исполнителей путем убеждения, объясняя, какие риски возникают в проекте в случае изменения заданий.
Новая задача поставлена «сверху» в пожарном порядке; что дальше? Команда проекта деморализована; доверие разработчиков к ПМ утрачено; условия работы, согласованные в начале проекта, изменены в одностороннем порядке; выстроенные «образы будущего» повисают в воздухе, поскольку выполнение текущей задачи может оказаться ненужным, а следовательно, не приведет к достижению каких-либо личных целей. Фактически после такого события команду проекта нужно распускать и набирать новую, под новые условия – «в любой момент все может поменяться». Та ли это цена, которую стейкхолдеры готовы платить за выполнение «срочной» задачи на один спринт раньше? ПМ доносит до стейкхолдеров логику управления проектами («выращивать сад», а не «крутить гайку») и убеждает их откладывать вмешательство на планирование очередного спринта.
Результат. Исполнители уверены в том, что качественное выполнение задач спринта гарантированно приблизит их к «лучшему будущему» (выполнению личных целей).