В своей прошлой заметке я немного упомянул проблему перехода с технической карьерной лестницы на менеджерскую. Этот переход не так прост, как кажется многим техническим лидам. Очень часто он воспринимается просто как добавление новых обязанностей по общению с заказчиком, принятию каких-то проектных решений, а также как дополнительная ответственность. В том, что управление проектами - это абсолютно другая область знаний и навыков, которую необходимо изучать, отдают себе отчет не все. Как минимум, до первого заваленного проекта :)
Об общих ошибках управления проектами написано уже очень много, поэтому я не хотел бы повторяться. Об этом можно почитать здесь, здесь, а также в куче других мест - достаточно лишь погуглить по ключевым словам. Я же хотел бы остановиться на некоторых ошибках, которые свойственны именно бывшим техническим лидам, ставшим менеджерами проектов или начинающим выполнять эту роль в дополнение ко своим текущим обязанностям. Причем говорить я буду о бывших программистах, а не о QA, BA или ком-то другом, потому что:
- я на практике сталкивался в основном с PM, которые в прошлом были программистами, а не QA или BA - банально нет подобного опыта, поэтому мало о чем могу сказать
- на мой взгляд, PM из бывших QA и BA не будут совершать часть из перечисленных ниже ошибок, просто по тому что они специфичны для программистов
- я сам - программист, поэтому мне проще основываться еще и на своем личном опыте и своих ошибках :)
Думаю, любой человек, работая под началом разных менеджеров, видел различия в отношении и подходах. У каждого PM свой уровень знания и умений, менталитет, психология, поэтому стили управления отличаются. Но если посмотреть на PM, которые в прошлом были программистами, можно заметить некоторые общие черты и типичные ошибки, которые те совершают. Основная причина этих "типичных" ошибок - менталитет, установленные подходы и шаблоны работы в бывшей роли программиста, а не просто недостаток знаний или понимания процесса управления проектами. Почти любой программист, при условии хороших технических знаний и наличии лидерских качеств, может стать хорошим лидером, но это еще не значит, что он может стать хорошим менеджером. Между "управлением" продуктом, которым, по сути, занимаются DL или TL, и управлением проектом и командой, которым занимается PM есть большая разница.
Ошибка №1. Непонимание целей и задач роли PM
Я уже упоминал, что цели и задачи ролей DL и PM отличаются. Основная задача DL - реализовать продукт технически. Это его сфера ответственности. Основная задача PM - успешно завершить проект в рамках запланированных сроков, бюджета, объема функционала и его качества, таким образом сделав клиента довольным и счастливым. Попутно можно сказать, что основная задача QAL состоит в том, чтобы удостовериться, что полученный в результате выполнения проекта продукт - это именно то, что нужно клиенту и что качество этого продукта соответствует предъявленным требованиям, но QA мы пока что трогать не будем. Таким образом, обязанности PM состоят не только в том, чтобы общаться с клиентом, давать всем подзатыльники, а также писать спецификации и отчеты (изверги, бумажной работы навалили, ужас!), а в том, чтобы создать условия и наладить процесс работы, в рамках которых команда достигнет результата, попутно эффективно управляя требованиями, рисками, различного рода ресурсами (в том числе и человеческими) и т.д. И это все нужно понимать и делать, даже если PM - всего лишь дополнительная роль, которую вам приходится выполнять по долгу службы, а не настоящая должность.
Ошибка №2. Неумение смотреть на проект и продукт с точки зрения клиента (бизнеса)
Менеджер проекта в какой-то степени является промежуточным звеном между командой и клиентом. Поэтому если программист и DL могут позволить себе думать только о реализации и проблемах, связанных с ними, быть "по эту сторону баррикад", то PM уже должен думать не только о команде, но еще и о клиенте, его целях, желаниях и проблемах. Любой продукт, разрабатываемый в рамках проекта, несет для клиента какую-то выгоду (не обязательно финансовую). Если же мы в угоду желания попробовать новую технологию, реализовать эту фичу "по-своему" или даже просто по глупости убиваем эту выгоду - клиент не будет доволен. И PM иногда является единственным носителем полной информации о целях и желаниях клиента. Да, в какой-то степени это еще и обязанность QA, но зачастую они не могут принять решение в момент разработки, а лишь тогда, когда что-то уже сделано. Поэтому лишь PM может вовремя остановить разработку и направить ее в правильное русло. Нужно помнить, что PM является не только адвокатом команды перед клиентом, но и адвокатом клиента перед командой.
Ошибка №3. Считать себя самым умным и самым главным
Достаточно распространненая ошибка, особенно когда менеджером проекта становится очень технически подкованный программист, который был долгое время девлидом или архитектом. Авторитет бывших "лидеров" очень высок, и они с одной стороны не хотят его терять, а с другой - привыкают считать себя последней инстанцией в принятии технических решений, попутно перенося это и на управление проектом, становясь подлинными тиранами. Да, PM - это тот человек, который принимает окончательное решение, а также разрешает споры и конфликты. Но в то же время грамотный PM слушает команду, ее советы, дает оспаривать свои решения, а также старается создать условия для креатива и роста членов команды, попутно лишь поправляя курс по необходимости.
Ошибка №4. Злоупотребление делегированием-исполнением, а не делегированием-руководством (микроменеджментом)
Любой менеджер должен уметь распределять задачи (делегировать их). Существует два основных типа делегирования: делегирование-исполнение и делегирование-руководство. Делегирование-исполнение выглядит следующим образом: "Возьми пилу, пойди в сад, спили все сухие деревья, а когда закончишь - вернись и доложи мне". То есть фокус идет на методах исполнения обязанностей, на том, как что-то сделать. Делегирование-руководство в таком случае может выглядеть следующим образом: "Очисти сад от сухих деревьев". То есть фокус идет на результат, которого нужно достичь, на то, что нужно сделать, а не то, как. Как очистить сад от сухих деревьев - спилить, срубить или спалить - исполнитель может принять решение и сам. Право выбора, равно как и ответственность за результат, возлагается на исполнителя. Чем делегирование-руководство лучше - оно дает возможность человеку проявить свои способности и творчество в полной мере, возможно, быстрее или эффективнее добившись результата. Но в то же время если человек еще не умеет принимать решения (допустим, он еще неопытен), то нужно это делать за него, но только после того, как он хотя бы подумает над своим вариантом решения - чтобы он учился.
Конечно же, у менеджера проекта, которые сам был раньше программистом, всегда есть искушение рассказать кому, что и как делать, залезть в девелопмент и постараться порулить там. Но по сути это как раз и есть тот самый микроменеджмент, а также влезание в чужую сферу ответственности, которые не любит ни один специалист. К тому же это еще и отбирание у человека или команды в целом возможности выбора, права на ошибку и ответственности за свои поступки, ограничение творчества и инициативы.
Ошибка №5. Боязнь показать свое незнание
У программистов это чувство развито очень сильно :) Поэтому довольно часто менеджеру сложно спросить какие-то детали, попросить о помощи - ведь он вроде бы как самый главный в команде (см. ошибку №3), негоже перед подчиненными показывать свою слабость, вдруг перестанут уважать. Достаточно глупо и, к сожалению, иногда весьма критично для проекта. У PM есть куча других обязанностей, поэтому ему часто некогда вникать в детали, новые технологии и подходы разработки. Немудрено, что некоторые люди на проекте, которых вы раньше учили сами, вдруг окажутся осведомлены в чем-то техническом больше вас. Это нормально, не обращайте на это внимания, развивайтесь в свою сторону, и старайтесь наоборот стимулировать профессиональный рост своей команды, ведь чем сильнее команда - тем успешнее будет ваш проект.
Ошибка №6. Поверхностное отношение к команде и ее интересам
Как известно, программисты не всегда являются экстравертами. Менеджер проекта может запросто не интересоваться вопросами мотивации, создания и поддержания эффективных коммуникаций в команде, командного духа, тимбилдинга. Не говоря уже про решение личных проблем членов команды, с которыми сталкивается любой менеджер. Необходимо понимать, что для эффективной работы команды она: а) должна быть (!), б) должна быть единым здоровым организмом, в) должна быть хорошо мотивирована. Каждый член команды должен чувствовать, что он может без страха подойти к вам со своей проблемой и вы ему поможете по мере сил. Это еще один набор активностей и умений, которому нужно учиться практически с нуля, потому что ни программист, ни даже девлид подобными вопросами обычно не занимается.
Ошибка №7. Остановка технического роста
Казалось бы, какое отношение это имеет к управлению проектом? Никакого. Но зато это имеет самое прямое отношение к реалиям жизни. Если бывший программист, став PM, полностью останавливает свой технический рост по принципу "я уже и так достиг всего чего мог в техническом плане, могу забить", то это, по сути, рубание ветки, на которой сидишь. Да, технические навыки не обязательны для того, чтобы быть эффективным менеджером, но тем не менее кто вам даст гарантию, что один из ваших следующих проектов, который будет через год или два, не потребует от вас занятия должности PL, который будет руководить и технической, и организационной частью проекта? Или что на вашем следующем месте работы это не будет обязательным требованием? А будете ли вы тогда достаточно подкованы в новых технологиях или подходах для того, чтобы довести подобный проект до успешного завершения? На мой взгляд, если уж вам так повезло, и вы прошли весь путь от падавана до мастера Йоды в программировании, то не забрасывайте свои технические знания в темный чулан, развивайте их, хотя бы на поверхностном уровне изучайте новые технологии и подходы к разработке ПО, совершенствуйтесь!
Успехов вам и вашим проектам!
