Управлять людьми сложнее, чем проектами
Пять коротких фраз из книги Майкла Лоппа «Как управлять интеллектуалами. Я, нерды и гики», которые будут полезны проджектам.
В одной из статей рассказывала о «Джедайских техниках» Максима Дорофеева. Книга неплохая, некоторые приёмы применимы в проектной работе. Но если выбирать литературу, которую я бы рекомендовала бы каждому проджекту, «Как управлять интеллектуалами» Майкла Лоппа стояла бы выше в моём списке.
Я читала её в том числе в оригинале — Managing Humans. Лопп пишет о работе с инженерами, руководителях, корпоративных отношениях и управленческих ошибках. И там не надо изображать из себя идеального менеджера, у которого проблема решается правильной методикой. Он понимает, с какими коллегами работает, и честно рассказывает о провалах. Для меня это одна из самых полезных книг по работе с техническими командами. Выделила пять коротких цитат, к которым можно присмотреться независимо от того, управляем мы отделом разработки или просто координируем команду.
1. «Не будь мудаком!»
Гениальное управленческое правило. Но в корпоративной среде регулярно требующее разъяснений. Лопп много внимания уделяет тому, насколько хорошо руководитель понимает команду, с которой работает. Важно помнить, что разработчики, аналитики и тестировщики — специалисты с разными характерами, профессиональными интересами и представлениями о взаимодействии.
У PM далеко не всегда есть административные полномочия, но регулярно возникает необходимость договариваться с людьми, которые ему формально не подчиняются. Уважение, предсказуемость и способность нормально разговаривать полезнее попыток управлять командой исключительно через статусы и дедлайны.
2. «Оставайся гибким!»
Важное наблюдение: управленческий подход, прекрасно работающий с одним сотрудником, может совершенно не подойти другому. Для проджекта это повод осторожнее относиться к рекомендациям. Например, одна команда спокойно работает с минимальным количеством встреч и самостоятельно сообщает о проблемах. Другой необходимо чаще синхронизироваться на сложных этапах разработки. Но навязывать обеим одинаковый процесс потому что он описан в популярной методичке, сомнительно.
Гибкость требует понимания причин. Если специалисты не успевают, не стоит добавлять контрольные встречи. Может проблема вообще в зависимостях, оценке, постановке задач или постоянном изменении приоритетов. Сначала разбираем, что мешает работе, потом выбираем инструмент.
3. «Он хочет что-то узнать»
Так объясняется, зачем руководитель выделяет время на личные встречи с сотрудниками. Их ценность заключается в информации, которую невозможно получить из отчётов. В разработке статус задачи редко отражает происходящее. Специалист может выполнять работу, формально не нарушая никаких договорённостей, но сомневаться в архитектурном решении, конфликтовать с коллегой или считать выбранный подход технически бессмысленным. В трекере подобные обстоятельства никогда не отображаются.
Общение с командой не должно ограничиваться вопросами о сроках и готовности функционала. Важно копнуть, что специалист думает о происходящем, какие проблемы замечает и что предложил бы изменить. Особенно если речь о людях что знают техническую сторону продукта глубже менеджера.
PM не нужно подменять собой руководителя разработки или устраивать личные беседы со всеми подряд. Формат взаимодействия зависит от структуры команды. Но возможность получать честный фидбек должна существовать независимо от организационной схемы.
4. «Прекрати писать код!»
Интересная провокация. Автор сначала рассуждает о необходимости перестать лично выполнять инженерную работу после перехода в руководство, а затем сам же показывает ограничения этого совета. Для PM знакомая параллель. Чем лучше менеджер разбирается в технических вопросах, тем выше соблазн самостоятельно закрывать небольшие задачи или участвовать в решениях, которые команда способна принять без него.
Но нужно понимать архитектурные ограничения, зависимости, причины оценок и последствия изменений. Иначе обсуждение сроков быстро превращается в пересылку сообщений между клиентом и разработкой. Вопрос в том, где заканчивается полезная техническая вовлечённость и начинается вмешательство в чужую профессиональную зону.
5. «Делает ли ваш начальник то, что обещал?»
Лопп описывает руководителя, который обсуждал проблемы, проводил встречи, предлагал решения, но почти ничего не делал для их реализации. Узнаваемый персонаж, должность не принципиальна. В проектах тоже можно бесконечно обсуждать риски, формировать протоколы и назначать встречи. Только если после этого никто не принимает решения, не устраняет блокировки и не выполняет договорённости, управленческой пользы от подобной активности немного.
PM регулярно договаривается с клиентом, руководством и командой, поэтому любое невыполненное обязательство постепенно снижает доверие к его словам. Для команды иногда достаточно нескольких случаев, когда менеджер пообещал разобраться с проблемой и благополучно о ней забыл. Мне нравится, что Лопп оценивает работу руководителя через конкретные действия. Можно владеть терминологией, проводить образцовые встречи и уверенно рассуждать. Но спецы быстро замечают, способен ли менеджер повлиять на ситуацию.
В книге достаточно профессионального сарказма, чтобы не воспринимать управленческую должность как свидетельство непогрешимости. И достаточно опыта, чтобы после прочтения хотелось пересмотреть привычки в работе со своей командой.
Я менеджерка проектов. Пишу о работе с клиентами и командами, делюсь опытом и наблюдениями.