Большие проблемы маленьких проектов и их решение

Tweet

Недавно увидел пост на happy-pm «Чего не хватает начинающим менеджерам…» (см. также конспект в блоге Дениса Дудника) и очень порадовался, заметив, что идеи «Случаев из жизни…» (случай #1, случай #2 и случай #3) и выступления на CEE-SECR сильно пересекаются с мнением директоров крупных компаний…

Но потом я задумался, и попытался вспомнить, чего же не хватало мне на первых порах как ПМ-у? Думаю, что результаты этой моей «ретроспекции» возможно будут интересны начинающим менеджерам, особенно менеджерам небольших проектов по разработке ПО…

Итак, мне не хватало…

1. Собственного мнения о своей работе

ПМ является чрезвычайно сложной областью деятельности, четких критериев успеха в которой, к сожалению, нет. Даже, если все идет хорошо, и клиент удовлетворен, ни в одном из проектов не обходится без «косяков».

Причем именно за косяки ПМ-у обычно выговаривают: методично, нравоучительно, в назидание потомкам. Если ПМ делает работу хорошо, то обычно, это проходит незамеченным; потому что это — «твоя работа». Результат понятен – особого удовольствия от подобного процесса ПМ не получает. А так как стресса в нашей работе хватает – то часто подобные «выговоры за косяки» бывают последней каплей.

От команды, особенно если команда новая и собралась в первый раз только для этого проекта, поддержки и объективного отклика ПМ-у обычно тоже ждать не приходится…

Чтобы как-то с этим всем бороться, ПМ-у необходимо уметь самому оценивать свою работу, причем честно, беспристрастно, не обманывая себя самого. А для этого – нужны собственные «критерии качества», которые и будут использовать для такой оценки.

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

даже если Вы посчитаете, что недоработали по каким-то параметрам, осознание того, что всё хорошо по другим – очень помогает в трудную минуту.

2. Хладнокровия

В любом проекте бывают моменты, когда всё идет наперекосяк. В подобных ситуациях команда обычно бежит к менеджеру, чтобы тот научил как жить и объяснил, что делать дальше. Иногда команда даже может начать обвинять менеджера в сложившейся неприятной ситуации…

В такой ситуации у менеджера есть большой соблазн либо поступить как страус (аккуратнее, перекрытия между этажами в современных офисных зданиях, обычно, бетонные), либо начать «рубить с плеча» и принимать «экстренные меры» дабы как можно быстрее удовлетворить команду — ведь они же ждут, и авторитет менеджера поставлен на карту!

К сожалению, оба этих варианта – бесперспективны и даже опасны для успеха проекта. Менеджеру необходимо оставаться спокойным, принимать взвешенные решения, даже если команда требует незамедлительных указаний.

Не делать ничего или отложить принятие решения ненадолго иногда бывает правильной альтернативой.

3. Чувства меры

Как я недавно писал в одной из заметок, что должен делать менеджера в том или ином проекте – определено далеко не до конца. В результате, часто бывает непонятно, как определить, сделал ты уже всё необходимое или нет.

Поначалу, хочется всё сделать наилучшим образом – в итоге можно скатиться к микроменеджменту, и в результате демотивировать команду и поставить проект под угрозу. Либо начать «изображать кипучую деятельность» — и, тем самым, совершить вторую ошибку менеджера.

Отчасти избежать таких проблем помогает список «критериев успеха», о котором говорилось выше. Но что действительно нужно – это чувство меры, понимание реальных необходимостей проекта, так как именно это — залог более-менее спокойной и эффективной работы команды, правильности принимаемых решений.

4. Умения остановиться и «не кодить», не терять перспективу

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

Например, вырастая из «из программистов», часто менеджер очень хорошо знает правильное и корректное техническое решение проблемы. Более того, всем нам нравится придумывать как же всё будет работать…  В результате, в порыве сделать «как лучше», менеджер может не просто поставить задачу участнику команды, но еще и объяснить как ее нужно решать.  В итоге – теряется весь Fun… остается только закодить.

Более того, обладая значительной властью в рамках проекта, у менеджера есть большой соблазн не только объяснить, как он считает нужным решить ту или иную проблему, но еще и настоять на своей точке зрения, считая ее единственно верной…

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

5. Осознания и признания ограниченности собственных возможностей

Начинающему менеджеру часто необходимо доказывать свой авторитет команде. Часто команда «проверяет его на слабо» – спрашивая мнения менеджера по вопросам архитектуры, кодирования, качества… При этом менеджеру, выросшему из программистов, разбирающемуся в предмете, велик соблазн «козырнуть» собственной квалификацией и компетенцией…

Часто, «лихие» решения принимаемые менеджером в таких условиях оказываются недальновидными, или из них получаются «срезанные углы», выливающиеся впоследствии в проблемы качества или сопровождаемости решения… Причем исправить такие проблемы впоследствии и не уронить свой авторитет — гораздо сложнее! Ведь это же Вы, менеджер, приняли эти решения…

Участники команды обычно задают вопросы, которые возникают в результате их длительной работы в проекте, причем работы сконцентрированной на решении в рамках определенной роли… Для ответа на такие вопросы менеджеру, если он не всемогущий superman, объективно требуется время чтобы «въехать», понять есть ли вообще проблема, какие есть альтернативы и ограничения…

Более правильным в указанной ситуации будет сказать: «Я не могу дать ответ прямо сейчас. Давайте разберемся, в связи с чем возник вопрос?» и если проблема реально существует и не лежит в области компетентности участника команды – отложить решение вопроса и дать корректный ответ после детального анализа.

Вторым способом ПМ-у доказать что «я могу всё» является принятие решений, в вопросах, которые объективно лежат за пределами зоны ответственности менеджера проекта:  в компетенции заказчика, либо ресурс-менеджеров компании-разработчика.

Например, о поведении в недоспецифицированных ситуациях, о необходимости изменений в используемых технологиях и серьезных изменениях архитектуры, о подключении дополнительных участников к проекту и т.д.

Единственным результатом таких попыток сделать «как лучше и эффективнее» скорее всего будет конфликт с руководством и проблемы с заказчиком, и … потерянный авторитет.

6. Умения сохранять внешнее спокойствие и чувства юмора

Деятельность организованная попроектно – гораздо более рискованная, чем операционная деятельность – и как следствие гораздо более стрессовая. Если, несмотря на стресс, менеджер выглядит спокойно и расслабленно – это спокойствие передается команде, позволяет ей работать более спокойно – и эффективно. Если же менеджер напряжен  – то это напряжение передастся команде – и тогда менеджеру возможно потребуется решать более серьезные проблемы.

Сохранить рабочий настрой команды можно часто одной лишь простой шуткой. Умение лишний раз пошутить, никого не обидев разрядить обстановку – дорогого стоит.

Умение разрешить конфликт между участниками команды, заставив их рассмеяться, или избежать волны conspiracy, удачно пошутив насчет того или иного заявления заказчика, позволяют повысить morale – и значительно упрощают работу менеджера.

Чувство юмора также очень помогает в трудную минуту при общении с заказчиком – даже простой смайлик в чате упрощает коммуникацию, позволяет разрядить обстановку и вернуться в конструктивное русло.

7. Умения творить миф

Основным инструментом работы менеджера являются коммуникации: от того что и как говорит менеджер – зависит уровень стресса команды, мотивация, ответственность, в какой-то мере качество продукта. Менеджер – лидер проекта, источник его идеологии и морали, протагонист. Часто именно менеджер расставляет точки над i, определяет что такое «хорошо» и «плохо» для проекта, поддерживает мораль, убеждая команду, что текущие трудности временные и «мы их преодолеем», что «все большие молодцы» и «так держать»

Каким бы низким ни был авторитет менеджера у команды, команда будет прислушиваться к оценке менеджером происходящего. Слова менеджера, должны быть хорошо  взвешены и обдуманны. Во власти менеджера создать вокруг проекта ореол «миссии», дать команде ощущение важности происходящего, инновационности, сложности… Но также в его силах – в одночасье этот ореол разрушить и тем самым поставить успех проекта под угрозу.

Вот как-то так… Думаю, что для этой статьи самокритики уже достаточно