Они организованны, увлечены и целеустремлённы. Они знают всё о проекте и их стратегическую роль в его успешной реализации. Они учатся и меняются. Более подробно о том, зачем же в компании нужны хорошие менеджеры проектов рассказывает PM Владимир Шлыков.
Я встречал разработчиков, особенно начинающих, которые воспринимают менеджеров как неких надсмотрщиков, нужных для того, чтобы строго следить за тем, как работает разработчик, контролировать его каждый шаг и наказывать, если разработчик что-то делает не так и придумывать поводы, чтобы отказать в отпуске.
Конечно, некоторые менеджеры своим поведением поддерживают такое восприятие, но такие менеджеры в хорошие компании не попадают, либо, если каким-то образом пробрались, надолго не задерживаются.
В этой короткой заметке я попробую показать, что описанное выше восприятие – ошибочное, и в таких компаниях, как EffectiveSoft, перед менеджерами стоят совсем другие задачи.
Давайте представим команду без PM, кратко пройдемся по процессу создания ПО и рассмотрим основные ситуации, с которыми может столкнуться команда. Здесь я хочу отметить, что процесс описан упрощенно и усредненно, т.к. есть разные методологии ведения проектов и процесс разработки может отличаться в зависимости от выбранного подхода.
Пусть у нас будет команда из четырех разработчиков и QA. Перед стартом проекта мы совместно с BA выяснили у заказчика все требования, сделали оценку, и проект стартовал. Сначала нам нужно решить, что мы делаем в первую очередь, что во вторую и так далее, т.е. расставить приоритеты, ведь заказчику нужно получить продукт с наибольшей ценностью за наименьшее время. Без глубокого понимания бизнеса заказчика и его специфики мы сами не в состоянии правильно оценить бизнес-ценность каждой ‘’фичи’’, а, значит, нам ничего не остается, как пообщаться с заказчиком и выснить, что позволит ему заработать на проекте в первую очередь.
Кто-то должен взять это общение на себя, в нашем случае отвлекаясь от разработки. При чем у человека, который будет это делать, должен быть достаточный уровень английского языка, чтобы понять, что говорит заказчик, и быть в состоянии донести до него свои мысли. Так же нужно помнить, что в наше время все развивается не просто быстро, а во всю мощь, и функции разрабатываемой системы, которые были важными месяц назад, сегодня могут быть никому не нужными, а, значит, выяснять приоритеты придется не только один раз при старте, а ритмично, на протяжении всего проекта. Это означает, что кто-то из команды должен регулярно отвлекаться от своего любимого дела.
Но мы не лыком шиты, мы справились: приоритеты расставлены, первые задачи распределены по команде, и мы приступили. Правда, с первой задачей возникают технические сложности: разработчик Игнат не знает, как сделать один из этапов этой задачи. На StackOverflow такой вопрос есть, но он остался без ответа, и никто из членов команды с таким никогда не сталкивался. Значит нам нужно, чтобы кто-то нашел на фирме разработчика, имеющего такой опыт. К счастью, такой человек нашелся, и он помог разрулить ситуацию, хотя поиски отвлекли команду.
Через некоторое время оказывается, что разработчик Василий сделал свою задачу раньше всех и, чтобы не сидеть без дела, взял в разработку следующую по приоритету задачу, забыв об этом предупредить других. Другой разработчик Алина, закончив свою задачу, также взяла следующую по списку задачу, и она оказалась той же, что и у Василия. Через два дня это выяснилось случайно, когда Василий столкнулся с техническими трудностями и обратился к команде за помощью. Значит нам нужен человек, который будет отслеживать, кто и что делает для избежания повторения такой ситуации в будущем.
Итак, у нас закончено несколько задач, и QA Тоня приступает к тестированию. Но вот первая по приоритету задача Тоне не интересна, она выглядит сложной, поэтому Тоня решает оставить ее «на потом» и приступает к проверке остальных готовых задач. В процессе она замечает, что в задачах разработчика Федора очень много ошибок, а каждую из них ей нужно подробно описать. Ей это надоедает, она идет к Федору и красочно описывает степень кривизны его рук и скудные умственные способности.
Федор парирует, объясняя Тоне, что у нее полностью отсутствует трудолюбие, т.к. описать ошибки не так уж и сложно, «это тебе не код написать», она не имеет и малейшего представления о тактичности, и, вообще, больше он с ней общаться не намерен. Вот мы и получили конфликт на ровном месте. Тоня и Федор после сражения сами не помирятся, а состояние войны между членами команды не лучшим образом скажется на моральном духе не только участников конфликта, но и всех остальных. Следовательно, кто-то из других разработчиков, снова отвлекаясь от своих задач, должен взять на себя роль медиатора и объяснить Тоне, что прямолинейность не всегда приводит к положительному результату и попросить Федора тщательнее проверять свой код, прежде чем перевести его на стадию тестирования.
И вот тут на сцену выходит заказчик, который говорит, что на данный момент ему нужна только первая по приоритету задача прямо сейчас, потому что мы ее давно уже начали делать и должны были сдать. Но мы помним, что у сначала у Игната были сложности, потом Тоня ее отложила, затем был конфликт, поэтому как-то вот затянулось и задача не готова. Заказчик высказал все, что думает о команде, чем деморализовал ее полностью еще в начале проекта, и ничего хорошего в итоге не получилось.
Конечно, приведенные выше примеры утрированы, и в реальности многие из слаженных команд могут успешно разрешить все эти ситуации даже без менеджера, но решение подобных вопросов отнимает время и сильно снижает производительность.
Какие же основные задачи, стоящие перед менеджерами?
Я бы разделил их на три основных направления, которые, конечно же тесно переплетаются между собой:
— Общение с заказчиком
— Взаимодействие с командой
— Взаимодействие с руководством компании
Общение с заказчиком
Именно менеджер проектов является тем самым связующим звеном между командой и заказчиком, находясь в постоянном общении с двумя сторонами.
Планирование проекта
Менеджер должен предоставить заказчику информацию о том, что и к какому сроку будет готово независимо от того, какая модель применяется – Fixed price или Time and material. Конечно, при модели Time and material все планы более гибкие, чем при Fixed price, но, тем не менее, цель любого проекта – получение прибыли, и заказчик должен представлять, что и когда он получит. Основа любого плана – это оценка от команды, но также менеджер должен учесть риски, которые могут возникнуть на протяжении проекта. Способность планировать – это один из основных hard skills для менеджера.
Управление требованиями
На небольших проектах обычно не выделяется отдельный бизнес-аналитик (BA), и менеджер берет на себя управление требованиями: необходимо понять, что нужно заказчику, оформить это в User stories, расставить приоритеты и делать это периодически до окончания проекта.
Так же задача менеджера установить личный контакт с заказчиком, поддерживать доброжелательные отношения, несмотря на возможные конфликты и разногласия. Менеджер должен уметь поддержать разговор на любые темы, при этом аккуратно обходить потенциально опасные, например политику либо религию.
Управление ожиданиями
Заказчики, требуя что-то сделать, далеко не всегда осознают, что это повлияет на их предыдущие просьбы и планы. Например, часто добавляя новые «фичи», которые нужно сделать прямо сейчас, заказчики ожидают, что все предыдущие договоренности, в том числе о сроках, будут соблюдены, хотя нам очевидно, что при той же команде это трудно выполнимо.
Взаимодействие с командой
В EffectiveSoft менеджер является такой же частью команды, как и любой разработчик, team lead или QA. Он должен чувствовать настрой команды, помогать ребятам в сложных ситуациях, обеспечивать всем необходимым, мотивировать и поддерживать позитивный настрой.
Менеджер ответственен за два главных вопроса от команды: “Что делать?” и “Когда делать?”.
Так как менеджер общается с заказчиком, он в большей степени, чем другие члены команды, владеет всей картиной проекта, поэтому он должен знать, что и в какой момент нужно сделать для лучшего результата. В этой части работа менеджера немного напоминает работу дирижера оркестра. Каждый музыкант играет свою партию в нужный момент, и в итоге получается красивое произведение , заслушаться можно.
Как я описал выше, в командах случаются и внутренние конфликты. В этом случае менеджер должен выступать в роли медиатора. Нужно найти подход к каждой из конфликтных сторон, понять причины и мотивы каждого и предложить компромиссное решение, убедившить, что оно действительно устраивает всех.
Помощь в решении проблем
В процессе выполенения проекта могут возникнуть разные проблемы, а я приведу лишь пару из них в качестве примера. У разработчика внезапно снижается производительность. Менеджер должен вовремя выявить эту ситуацию и понять причины, чтобы принять правильное решение. У человека может возникнуть выгорание, он мог устать, либо у него проблемы личного храктера или со здоровьем. В этом случае нужно сотруднику предложить отпуск или перевести его на другой проект к другому заказчику. А зачастую бывает достаточно просто выслушать человека и дать ему жизненный совет. Бывает и такое, что разработчик хочет изучать другой язык программирования, сменить платформу разработки. В этом случае мы так же можем предложить человеку перейти в другую команду, где он сможет учиться и развиваться в том, что ему нравится.
Бывает, что у сотрудника возникают проблемы с техникой. В этом случае менеджер через руководство решает вопрос об обновлении или смене оборудования.
Поддержание позитивного настроя
Менеджер должен избегать кислых лиц на митингах. Несмотря на возникающие трудности при выполнении проекта, он должен стараться всегда подбодрить ребят, мотивировать и направить вперед, ведь любые проблемы можно решить, и именно через сложности мы развиваемся!
Взаимодействие с руководством компании
Руководству компании важно знать, как идут дела на проектах, чтобы своевременно выявлять узкие места и проблемы на проектах для принятия управленческих решений на уровне компании, поэтому менеджер должен регулярно взаимодействовать с руководством и уметь кратко, экономя время руководства, рассказать, что происходит на проекте, но сделать это так, чтобы была видна вся картина, ведь на ней не должно остаться “белых пятен”.
Так же ежемесячно нужно подавать отчеты о потраченных командой часах на каждом из проектов для выставления счетов заказчикам. Финансовый результат нашей деятельности имеет не самое последнее значение!
Итак, на мой взгляд, основная роль менеджера в широком смысле – обеспечить команду всем необходимым и своевременно устранить все препятствия для успешного решения стоящих перед ней задач.
Проектный менеджер — это не начальник, а, в первую очередь, помощник и тот самый человек, с которым работа становится более эффективной, процессы структурированными, а команда по-настоящему слаженной.