Когда проект короткий – все в нем собраны и идут к общей цели, и управлять таким проектом относительно просто. А вот при длительности в год и больше удержать фокус команды и стейкхолдеров и сохранить управляемость гораздо сложнее. Цифры приведены для ИТ и, понятное дело, условные, для разных областей они будут разными. Как же сделать так, чтоб и через год и через два проект по-прежнему был интересен команде и стейкхолдерам, нес разумное, доброе и светлое, и не требовал безумных усилий для управления им?
Сразу оговорюсь, что по возможности такие проекты все-таки нужно разбивать на несколько. Это проще как с точки зрения управления, так и с точки зрения мотивации. Когда в проекте, пусть и долгом, успевает смениться почти вся команда, пусть даже в силу естественной текучки кадров, это никого не радует и порождает отрицательное отношение к нему и подозрения о недостаточной квалификации РМа (несправедливо, но факт).
Кстати, умение сделать проект коротким – это отдельный навык, который стоит развивать, потому что управляемость таких проектов в разы выше. Но об этом как-нибудь в другой раз.
Итак, что нужно для того, чтобы сделать долгосрочный проект управляемым?
1. Четкие процессы и непримиримость к их несоблюдению
На этапе планирования грамотный руководитель проекта должен продумать не только процессы работы в настоящий момент, но и то, как они будут меняться в ходе жизненного цикла проекта. Например, если на активной фазе (например, сбор и согласование требований) вы проводите собрание рабочей группы один раз в неделю, то лучше сразу оговорить, что на этапе разработки они будут один раз в три недели или один раз в месяц.
Самое худшее, что можно сделать – это пустить вопрос на самотек, мол, в то время, когда постоянное привлечение группы не требуется, буду собирать встречи при необходимости. Как только из календаря пропадет регулярная встреча – про проект забудут, фокус будет потерян. Однако какой смысл собирать людей, если для них нет конкретных задач, спросите вы?
Именно поэтому важно продумать этот момент еще при планировании работ и сделать так, чтобы поток задач для всех участников был относительно постоянным в течение всего хода проекта или хотя бы не иссякал совсем. Требования собраны, разработка запущена? Самое время вместе с рабочей группой спланировать, как вы будете учить людей, и что для этого нужно сделать.
То же самое и с планированием отпусков – как только вы пропустите 1-2 встречи – народ начнет ходить как удобно ему, а вы потом в самый критический момент обнаружите, что ключевые сотрудники в отпуске именно в то время, на которое вы запланировали на них важные активности.
2. Разбиение проекта на стадии и отмечание завершения этих стадий
Если долгосрочный проект по каким-то причинам (часто финансовым или политическим, кстати) невозможно разбить на несколько, нужно, по крайней мере, четко обозначить его стадии и критерии их завершения. После того, как стадия завершена, необходимо ее официально закрыть – провести презентацию для управляющего комитета, наградить отличившихся, устроить какое-то тимбилдинговое мероприятие и отметить это дело. Это даст людям понимание того, что проект движется, а не стоит на месте, позволит поставить ментальную “галочку””я сделал” и продолжать бежать.
Отличный пример – “Красочный забег” в Москве, на котором каждый километр трассы был отмечен новым цветом, чтобы люди понимали, что они пробежали еще один кусок и могли получить “подзарядку”.
3. Извлеченные уроки по каждому этапу
После завершения стадии хорошо бы проводить сессии по тому, какие уроки (положительные и отрицательные) команды извлекла за время этой стадии, и как они помогут нам дальше.
Опять же, дает чувство завершения предыдущей стадии и позволяет отделить ее от последующих плюс пополнить копилку теми знаниями, которые в конце проекта (через год!) будут уже давно и благополучно забыты.
4. Поэтапный ввод результатов в работу
Скорее всего, это не ваш случай (тогда вы с самого начала делали бы проект по гибкой методологии), но иногда можно как-то это исправить уже в ходе самого проекта. Если non-Agile – это политическое решение, то промежуточную версию всегда можно назвать тестовой или “для получения обратной связи” и делать себе спокойно проект так, как удобно и эффективно.
Ну и какие-то отдельные вещи можно вводить тоже раньше полного запуска – например, если в проекте предусмотрены дашборды на больших экранах, можно повесить их за год до старта и транслировать на них новости проекта и что-то еще. Во-первых, заранее сделаете этот кусок, во-вторых – огни будут ненавязчиво напоминать о проекте, в-третьих – у людей будет понимание, что эта часть проекта завершена.
5. Регулярная переоценка необходимости проекта, требований, стейкхолдеров, рисков
Это печальный факт, но большинство результатов долгосрочных проектов устаревают еще до того, как попасть к конечным пользователям. А иногда и вообще выясняется, что они больше не нужны, стратегия компании поменялась, ключевые заинтересованные лица уехали работать в Лондон и еще сотни причин, почему ваша работа оказалась никому не нужной. Если по каким-то причинам Agile не для вас и сдавать проект по кускам никак нельзя – то нужно с определенной регулярностью возвращаться к целям проектам, убеждаться, что они для компании еще актуальны и утверждать их у новых должностных лиц. То же самое актуально для требований.
И, конечно, если в компании меняется топ-менеджер, имеющий непосредственное отношение к вашему проекту – необходимо убедиться, что он про проект знает и что с тем, что он принесет указанные выгоды и на него будут потрачены указанные деньги и ресурсы, согласен (как максимум – заручиться поддержкой, как минимум – подстраховаться, чтобы потом не оказалось, что он ни при чем, деньги потрачены, а вы крайний).
6. Бриф проекта
Бриф – хорошая штука, позволяющая в растянутом по времени проекте не забыть, а зачем, собственно, это все, и особенно о том, что разумное, доброе и светлое несет проект и для кого он делается. Подробно я писала о брифе тут.
Вот и все, правила простые, но их соблюдение поможет удержать проект на коротком поводке и не дать людям потерять фокус на нем. Иногда, выполняя какие-то из указанных выше пунктов (особенно п.5), можно понять, что проект уже нерелевантен и компании не нужен. Этот тот самый случай, когда несмотря на уже потраченные деньги, лучше поднять вопрос о его закрытии. Упорно догрызть кактус и сделать то, что не нужно никому – это не тот опыт, который вам нужен как руководителю проекта. А умение вовремя понять и признать правду и особенно сказать менеджменту “все, деньги выброшены на ветер, предлагаю дальше их не выбрасывать и проект закрыть и начать новый” – бесценно, и является одним из доказательств вашего профессионализма.
Всем коротких проектов и быстрых побед!
Добавить комментарий
2комментария