image

Сейчас работать в сфере IT очень популярный тренд по известным причинам. И все больше и больше молодых людей решают посветить себя именно этому делу. Однако писать код не всем по душе и поэтому выбор новичка часто падает на не технические IT специальности, такие как бизнес анализ, тестирование (разумеется мануальное), рекрутинг или менеджер проекта. Причем под новичком я имею в виду как вчерашних студентов, так и людей с опытом работы в других сферах. Как раз на должности менеджера проекта я и хотела бы остановиться поподробнее.

В наше время позиции руководителя или владельца бизнеса настолько притягательны, что боюсь лет через 10 некем будет управлять… Не знаю почему, но бытует мнение, что если есть знание английского языка, да еще и прочитано несколько бестселлеров о лидерстве, мотивации и управлении, то готов идеальный кандидат на место PM. Как часто вам приходилось слышать подобные рассуждения «Да что там управлять проектом – раздал задания, проконтролировал (серьезно и ооочень строго), поболтал с заказчиком вот и вся работа, делов то!»?

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

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

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

Делегирование — это передача задания, власти или ответственности, постановка перед кем-то цели с одновременным предоставлением средств для ее достижения и несение исполнителем ответственности за качество результатов.
В.В. Глухов («Менеджмент». Учебник для вузов, 3-е издание)


Как видно из определения, для правильного делегирования менеджеру необходимо удостовериться, а обладает ли человек всем необходимым для выполнения задачи (пониманием цели, знаниями, полномочиями, доступом к информации и т.д.). Поэтому поручая в следующий раз задачи помните, что прежде чем требовать, вначале нужно объяснить или даже научить.

Действие №2 «А давайте помогу…»
Из самых добрых побуждений некоторые менеджеры считают своим долгом помочь чем только смогут. И сверку верстки с дизайном провести, и требования подправить, и декомпозицию на сабтаски сделать, и потестировать и еще работы найдется всякой… Вместо выполнения своих прямых обязанностей менеджер просто превращается в многорукого Шиву, который героически овертаймит в одиночку, а проблем в проекте почему-то не становится меньше, а скорее наоборот.
Последствия. Утопая в тоннах чужой работы PM теряется фокус и уже не в состоянии справиться с главной своей задачей: вместе с командой успешно реализовать проект.
Отправная точка для размышлений. Данная тема прекрасно раскрыта в книге «Одно-минутный менеджер и обезьяны» Кена Бланшара. Основная идея заключается в том, чтобы не распылять свои усилия на выполнение чужой работы, а стараться максимально освободить время для занятия своими непосредственными обязанностями (производство результатов, администрирование, интеграция, проработка и имплементация новых идей).

Действие №3 «Мы с заказчиком обо всем договорились»
К сожалению, очень распространена практика просто «спускать» задачи команде. PM не считает нужным доводить до всеобщего сведения дополнительную информацию о целях, о приоритетах, о том почему-то что делается так важно для компании или заказчика. Работаем по принципу «нет времени объяснять». А зря!
Последствия. Команда, находясь в неведении, часто идет не в том направлении, не имеет возможности поделиться своими идеями (а поверьте, это очень большая потеря) и в результате получаются провальные спринты или даже проекты.
Отправная точка для размышлений. Постарайтесь всегда доносить до команды не только ЧТО ей необходимо сделать, но еще и ПОЧЕМУ. Во-первых, такой подход поможет построить доверительные отношения, ведь вы не просто раздаете указания, а увлекаете людей и мотивируете их принять максимальное участие в создании проекта. Во-вторых, вы страхуете сами себя от провала перед заказчиком. Чем лучше команда понимает к чему идет, тем быстрее могут быть выявлены ошибки, противоречия, риски.

Действие №4 «С понедельника живем по-новому»
Здесь речь пойдет об опрометчивых изменениях, которые так часто любят внедрять молодые PM. Почти в каждой книге, статье или докладе можно встретить призыв к экспериментированию и опробованию изложенного материала у себя на проекте. Я полностью согласна с таким эмпирическим подходом, но все же он таит в себе опасность. Многие опытные разработчики часто скептически относятся к подобным переменам, потому что на своем опыте им уже доводилось переживать подобное.
Последствия. Обилие новых модных терминов и натягивание разрекламированных способов работы as is на свой проект в лучшем исходе просто не даст никакого результата. В худшем — такие глобальные, необдуманные изменения могут привести к полной остановке работ, к хаосу и неразберихе, если хотите, к параличу проекта.
Отправная точка для размышлений. Удостоверьтесь, что вы достаточно глубоко изучили вопрос и понимаете суть и цели нового подхода. Подумайте, как адаптировать новый подход в вашем проекте с учетом сложившихся особенностей, культуры и политики компании. Проводите внедрение поэтапно. Это позволит не перегрузить команду (ведь их текущие задачи никто не отменял), вовремя заметить, что требуется дополнительная корректировка, суметь измерить результат и сделать объективные выводы. Презентуйте новый подход команде и поинтересуйтесь их мнением. Очень важно чтобы команда стала вашим сторонником – ведь именно им придется каждый день работать с новым процессом.

Действие №5 «Я все сделал правильно»
Частенько наблюдала случаи, когда вина за провал обязательно должна найти своего обладателя среди членов команды. И самое печальное то, что сам этот человек вполне согласен, что проблема именно в нем. Позволю себе заметить, что чуть ли не в 90% случаев косвенно или прямо вина за случившееся лежит на менеджменте. Ведь именно PM отвечает за организацию и соблюдение оптимальных процессов на проекте, которые призваны служить для гладкой работы. И сбой процессов – это зона ответственности менеджера, который просто вовремя не заметил, что что-то пошло не так.
Последствия. Из-за неверной интерпретации случившегося аналогичные проблемы возникнут в будущем, ведь никаких действия кроме «тушения пожара» не будет предпринято.
Отправная точка для размышлений. Анализируйте подобные отклонения с особой тщательностью. Ищите реальные причины проблемы и имейте смелость разделить ответственность за негативный результат со своей командой. Только устранив причину вы можете быть уверенны, что больше вас эта проблема не побеспокоит. Признанием своей ошибки вы также заработаете уважение со стороны команды. А без уважения о лидерстве не может быть и речи.

Действие №6 «Я уже 3 года так делаю и это работает»
Еще один случай, связанный с самоуверенностью менеджера – нежелание учиться. К примеру вы уже имеете некий опыт работы и считаете, что уже владеете всеми необходимыми навыками и знаниями. Но на самом деле нет никакой гарантии, что выработанные в прошлом способы помогут в новом проекте (компании) достигнуть результата. Вам наверняка понадобятся свежие идеи и взгляды.
Последствия. Если упрямо игнорировать достижения IT сообщества, то ваш способ ведения проекта попросту может не устроить новых заказчиков или работодателей. Вы станете похожи на динозавра, внезапно очутившегося посреди мегаполиса.
Отправная точка для размышлений.Всегда будьте открыты к новым знаниям. Следите за новыми тенденциями, читайте литературу, блоги, смотрите видео конференций. Благо в интернете доступно огромное количество различной полезной информации. Нужно только иметь желание.

В заключение хочу отметить, что IMHO времена строгого менеджера-единоличника уже остаются в истории и я вижу PM в роли полноценного игрока команды, основная задача которого — помогать. Именно фасилитация становится ключевым фокусом для PM. Суметь построить дружеские отношения в команде, способствовать росту каждого члена как профессионала, выпускать нужные и полезные для пользователей продукты, построить партнерские отношения с заказчиком – вот все то, к чему стремится современный менеджер проектов. Надеюсь, что здравый смысл все таки одержит верх над тщеславием и вскоре подобных Профессионалов можно будет встретить на любом проекте вне зависимости от величины и имени компании. И если вы твердо решили остановить свой выбор на роли PM, то пойдите правильным путем, минуя давно известные «грабли».

Комментарии (19)


  1. Askofen
    21.12.2015 13:53

    Поправьте грамматическую ошибку — адаптировать, а не адоптировать.


    1. Konffeta77
      21.12.2015 16:42

      Спасибо за внимательность, поправила.


      1. Kemanorel
        21.12.2015 16:45

        Тогда уж и «а что собственно понадобиться» поправьте.


        1. Konffeta77
          21.12.2015 16:47

          Спасибо! Нельзя полагаться на Word и внимательнее перечитывать самостоятельно.


  1. Kemanorel
    21.12.2015 16:22

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


    1. Konffeta77
      21.12.2015 17:00

      Больше речь идет о том, что очень желательно посвящать команду в цели бизнеса. По возможности, подробно рассказать о приоритетах (почему они именно такие), о главном фокусе спринта (на случай «обрезания» функционала, если команда не успевает выполнить полный объем в спринте), особенностях нового функционала (какие именно бизнес задачи он должен решать).
      У себя на проекте практиковали следующее: на груминге (или на планировании) Product Owner (или аналитик) начинал собрание как раз с пояснения описанных выше нюансов и уже после переходили к обсуждению конкретных задач. Таким образом, команду вначале погружали в бизнес контекст, а уже после было намного проще брейнштормить по требованиям, хорошо понимая, какие улучшения/изменения можно предложить для достижения цели (полезный для пользователя функционал).


      1. Kemanorel
        21.12.2015 17:07

        Да, я пункт перепутала, я про второй. С третьим прозрачно.


        1. Konffeta77
          21.12.2015 17:54

          В описанной вами ситуации избежать выполнения дополнительных обязанностей не получится.
          Я, скорее, имела в виду ситуацию с неким недоверием со стороны PM к команде и желанием все контролировать (позиция «хочешь чтобы все было сделано правильно — сделай сам»). Когда, имея все необходимые ресурсы, менеджер, в меру своих возможностей, берется за чужие задачи и считает такой подход правильным. То есть ему проще выполнить задачи самому, чем научить ребят из команды новым техникам.
          Приходилось бывать на вашем месте и закрывать собой некоторые позиции, пока новые люди не были набраны (в частности QA и BA). Старалась для себя расставить приоритеты так, что основным все таки оставались обязанности PM (общий фокус по проекту и синхронизация с другими командами зависимых проектов), а уже вторичными (overtime) дополнительные задачи.
          Но такие периоды все-таки должны быть временными, так как постоянно нести подобную нагрузку будет очень и очень не просто (особенно на крупных проектах). Возможно, стоит попробовать поговорить с руководством о необходимости пополнения команды или привлечения на part time нужных специалистов из соседних команд. Постараться донести мысль о том, что ваша задача — максимально помогать команде двигаться в правильном направлении и решать множество сопутствующих внешних/ внутренних проблем. Могу предложить проверенный мною способ: выписывать все свои выполненные задачи с результатом и предъявить список руководству как подтверждение объема вашей работы в роли PM. Ведь большая часть нашей работы вовсе не оформлена в виде задач и иногда не видна. А так можно обосновать собственную загрузку.


          1. Kemanorel
            22.12.2015 11:14

            Благодарю за ответ.


  1. Askofen
    22.12.2015 13:52

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


  1. valis
    22.12.2015 14:07

    Спасибо за совет номер 3. Частенько этим грешу (хотя сам не занимаю роль PM)
    Добавлю указанную книгу в список для чтения.


    1. Konffeta77
      22.12.2015 15:53

      Рада, что вам было полезно.


  1. potapcho
    22.12.2015 15:12

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

    Вот некоторые из них:
    — Статичность желаний собственника
    — Финансирование
    — Команда
    — Сроки

    Грамотный РМ может собрать все части проекта, сложить из этого рабочий алгоритм и запустить проект.
    Новичку требуется усвоить всего одно правило, никогда ничего не обещать без проработки!
    И будет Вам счастье) Вообще есть множество общемировых практик, но система адаптивного управления должна быть своя!


    1. Konffeta77
      22.12.2015 15:52

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

      Про «Эффективных менеджеров». Приходилось встречать тех, кто имея опыт работы PM никогда не работал простым членом команды («по ту сторону») и в попытках применить общепринятые практики умудрялся адаптировать их в совершенно нерабочие конструкции. Отсюда потом нарекания на менеджеров о бюрократии, странностях, отчетах и прочем. Мне проблема видится в непонимании менеджерами тех самых методологий и нежелании получать действительно полезный опыт путем признания своих ошибок.


  1. uamarshall
    22.12.2015 17:51
    +1

    Очень спорные ошибки, по моему мнению. Особенно утверждение, что пм должен — вместе с командой успешно реализовать проект. У кого то есть инструкция, что бы наверняка?!

    Из самых важных проблем юных ПМ по моему мнению:
    — Недостаточная согласованность (не убеждаются, что стороны имеют одинаковое понимание в аспектах, вопросах, процессах. Как на уровне исполнитель-заказчик, так и на уровне внутри компании. Типичный ответ джун пма при проблемах — «я думал он все понял» или «это же было очевидно»)
    — Недостаточное документирование (мало пишут и много говорят. как следствие, детали размываются либо теряются. постановка задач личная, на пальцах, либо по скайпу в голос. мало пишут в таски, трекер, почту.)
    — Не делегируют (пытаются все делать самостоятельно забирая на себя большие полномочия и возможности. как следствие, перегружены и считают, что другие с обязанностями справятся хуже либо не справятся вообще)

    Это три основных которые ведут к самым популярным ошибкам и проблемам.

    И последняя на закуску — пытаются подружится с клиентом. Это поведение жертвы. Как следствие, не могут клиенту отказать либо оспорить. Потом клиенты катаются на шее и не относятся к исполнителю как к профессионалу.


    1. Konffeta77
      23.12.2015 16:20

      О правильном делегировании было упомянуто. Спасибо за дополнение списка проблем.


  1. FlipWho
    24.12.2015 17:36
    +2

    image


    1. nicelight_nsk
      24.12.2015 21:35

      была бы карма, лайкнул бы!))


      1. FlipWho
        25.12.2015 08:35
        +1

        Оригинал картинки я потерял, но суть та же. Очень нравится способ интерпретации. Сразу становится понятно, к чему нужно стремиться PM.