Эмпирические выводов по прошествии 5 месяцев профильной работы менеджером проектов в разработке веб-приложений.

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

Предваряю свой рассказ дисклеймером: опытным менеджерам или аналитикам — всем, кто напрямую взаимодействует с заказчиками в бизнесе, — этот материал может показаться крайне бесполезным. А вот начинающим управленцам — сильно наоборот.

Разработка — это не главное

Кипы материалов уже написаны, конечно, по теме «необходимо ли менеджеру разбираться в технических аспектах своей работы» — и у вашего покорного слуги есть такая статья. Безусловно, необходимо — но это не панацея, далеко не главная часть в ведении проектов.

Анекдот. Собеседование кандидата в менеджеры в техническую компанию:
- Что для вас является маркером успешного завершения проекта?
- Подписанный акт о сдаче работ.

Не быть таким менеджером из анекдота — вот что главное. В такой шуточной форме прихожу к единственно верному на мой взгляд выводу: каждый член команды разработки (или конструирования, строительства, маркетинга и далее по списку) должен приносить ценность заказчику. Эта ценность не останавливается на гениальном знании методологий, отладке бизнес-процесса и качестве ведения воркспейса (а в случае с моим путём и личными ошибками — протекционизме команды и излишнем упоре на экологичное общение и повышенную мотивацию) . Эта ценность заключается в том, ЧТО получает заказчик. При этом, всё перечисленное ранее, как будто бы, само собой разумеется и существует в фоновом режиме.

Кстати. Agile работает, если этого сильно захотеть

Люди и взаимодействие важнее процессов и инструментов.

Помните что-то такое? Так вот: «люди и взаимодействие» — это в том числе "вы и заказчик" или "ваша команда и заказчик". Так вот, посмотрим на выводы.

Выводы

Итак, публикую список из 5 собственных выводов на основе завершенных и идущих под моим руководством турбулентных (и не очень) проектов:

1. Погружение в проект менеджера и заказчика

Необходимо понимать, что это — априори разные «сущности». Руководитель проекта и его команда всегда знают внутреннюю кухню: от реализованного функционала вплоть до скрытых от заказчика нюансов ведения проекта. Это значит, что мы должны вставать на сторону заказчика и пытаться увидеть пробелы в собственных демонстрационных материалах и презентациях, видеть уровень неопределенности, формируемый нами, а не самим проектом или несостыковками в техническом задании, коих не избежать.

2. Сценарии превыше функциональностей

Работаете вы в формате "водопада" или в "гибкости" — разницы нет, вы с командой, скорее всего, реализуете функциональность. Не забывайте, что заказчик всегда ожидает увидеть сценарий. Клиент видит свой сервис как совокупность экранных форм или «фичей», решающих бизнес-задачу. Помогите ему решить именно бизнес-задачу. Это далеко не означает, что вам надо думать о статистике и метриках — просто покажите базовое понимание продуктового подхода и ориентированность на бизнес, которому вы помогаете.

3. Epic и user stories

Мы — менеджеры, аналитики, разработчики, — мыслим в контексте декомпозиции. Мы всё пытаемся раздробить, разжевать. Порой мы декомпозируем недостаточно, порой — слишком сильно. Находите этот баланс самостоятельно в процессе обсуждения задачи. Есть известное правило — иногда исполнителю нужно дать свободу действий и возможность проявить креативность, иногда — сильно ограничить. It goes to show you never can tell.

4. Коммуникация с заказчиком в контексте «продажи»

Как сказал руководитель моего проектного офиса: «Продажа проекта не заканчивается при подписании договора» — и с этим я категорически согласен. Демонстрация результатов вашей работы — это ваша ответственность, и вероятность неудачи здесь достаточно высока. Мыслите и себя еще и как sales-менеджеры. Более опытные коллеги советуют: в случае невозможности предоставить результаты работы — увеличивать количество документации и высылаемых артефактов втрое, записывать screencast с вашей демонстрацией, постоянно делать follow-up по прошествии ваших устных разговоров или даже письменных диалогов. Это, на полном серьезе, может вас выручить.

5. Попытки найти справедливость

Заказчики — тоже люди, и правы они далеко не всегда. Зачастую, в общении с трудными заказчиками я выступал за протекционизм себя и своей команды, практиковал защиту от оскорблений, двусмысленных намеков и иногда даже женоненавистнических шуток; обходительно узнавал, почему бизнес-требования снова так сильно изменились, и понять, почему мы делаем всё «настолько неправильно» в понимании стейкхолдера — пытался «найти справедливость». Каждому важно пройти через это, получить необходимый уровень поддержки и эмпатии от коллег и близких в свою сторону. А потом понять, что всё это не имеет смысла. Я не предполагаю от менеджера терпения и стоицизма во всех шероховатостях нашего мира, просто прошу и заклинаю: не представляйте это результатом управленческой деятельности. Вы потеряете больше нервов и вожделенного жизнеутверждающего «ресурса». Впоследствии, попробуйте поумерить свой пыл на эту тему и продолжить работать — может быть, уже на другом проекте, зато с собственным багажом опыта и «набитых шишек». Надо вам это или нет, зависит, кстати, от характера и темперамента — люди смотрят на мир по-разному, не забывайте.

5 выводов о «продающей» коммуникации для менеджеров проектов