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