Аккаунт, менеджер проекта и аналитик в одном лице? Конец мифа для ИТ-проектов
Эта статья о легенде о менеджере проектов factotum. За свою карьеру я общался со многими клиентами и компаниями из этого предложения. От малых до крупных проектов, менеджер проекта играет решающую роль в достижении хороших результатов.
Дело в том, что слишком часто он играет более одной позиции, беря на себя также обязанности бухгалтера и аналитика.
Я назвал это совпадение обязанностей «троицей менеджера проекта», потому что он обычно играет роли аккаунта, менеджера проекта и аналитика.
В следующих разделах я объясню, откуда взялась эта ситуация и какие проблемы могут возникнуть. Затем я предложу правильный образец для использования при росте компании.
Менеджер проекта троица
Легко начать с теоретической точки зрения и сказать, что каждый человек должен играть только одну роль в компании. Это немного сложно применить на практике в реальном мире. Даже если сложность растущего ИТ-проекта требует очень целенаправленного профессионализма для получения качественных результатов, у многих проектов не хватает бюджета, чтобы включить такое количество профессионалов.
Просто подумайте о простом веб-приложении. Не могли бы вы добавить в эту команду учетную запись, менеджера проекта, специалиста по облачным технологиям, DevOps, нескольких разработчиков (может быть, один интерфейс и один серверный интерфейс), дизайнера и тестировщика? Наверное, да.
Это также показывает, что в простых сценариях нам потребуется много разных профессионалов для реализации проекта.
Для многих проектов дополнительные затраты на управление таким большим количеством людей не соответствуют преимуществам использования супер-специалистов.
Проще говоря, для простого проекта лучше иметь немного людей, менее специализированных, но сосредоточенных и преданных проекту.
Более того, во многих компаниях невозможно иметь такое количество вертикальных профессионалов (многие веб-агентства вообще состоят из 3–4 человек). Они все равно реализуют проекты, нанимают гибридных профессионалов. Это не ошибка, просто они реагируют на рыночный запрос. Нам нужно принимать неоптимальные ситуации, засучивать рукава и заставлять все работать. Итак, это нормально - для небольших компаний или команд, которые управляют небольшими проектами, - когда кто-то играет более одной роли. У нас может быть full-stack разработчик, который охватывает фронтенд и бэкэнд, но чаще у нас есть менеджер проекта, который призван решать все нетехнические проблемы.
Это то, что я называю Тринити менеджера проекта, потому что у этого героя есть:
- Ответственность за учетную запись: управление выставлением счетов, запрос платежа, обеспечение удовлетворенности клиентов и увеличение доходов от клиентов.
- Ответственность менеджера проекта: да, его основная роль! Руководитель проекта не может забыть завершить проект в срок и в рамках бюджета.
- Ответственность аналитика и специалиста: для многих проектов клиенту требуется быстрый ответ, и вместе с менеджером проекта, который знает технологии, и клиента, он помогает определить, что делать.
Эта ситуация не оптимальна, потому что она создает узкое место, а результат зависит от человека (у кого-то могут быть правильные характеристики, чтобы хорошо играть все роли, но обычно это химера). Более того, любая часть работы может быть конфликтной. Кто гарантирует, что менеджер по работе с клиентами пишет правильный анализ, а не тот, который сводит к минимуму работу, чтобы уложиться в сроки? Или что, если в качестве учетной записи вы бы разместили дополнительную функцию, не указанную в котировках, но как руководитель проекта у вас нет на это бюджета или времени?
Ограничения мультидисциплинарного менеджера проекта
Как объяснялось, лучшим решением было бы иметь разных людей для разных ролей, но это невозможно.
Наличие многопрофильного PM - не ошибка. Это правильный ответ на потребности рынка в небольших проектах.
Но что, если компания вырастет? Или если размер проекта внутри вашей компании будет расти?
Функциональный анализ стал трудным для выполнения в качестве аналитика, работающего неполный рабочий день, особенно когда их сложность требует специалиста. Таким образом, вы можете ожидать, что функция анализа станет более приблизительной, что приведет к переделкам, ошибкам и потере прибыли.
Конфликт между менеджером проекта и аккаунтом будет более частым, и даже при полном доверии к руководителю проекта у нас не было уверенности в том, что он выполняет волю компании.
С ростом сложности проекта то, что изначально было узким местом, может превратиться в еще более серьезную проблему. Вы можете попасть в небольшую монополию, компанию в компании, где все, по-видимому, работает этот человек, и вы потеряете контроль над этим сегментом бизнеса.
Правильный узор
Если вы дойдете до этого момента в этой статье, вы, вероятно, согласитесь со мной в отношении троичного риска менеджера проекта и ждете решений.
Прежде всего следует отметить, что в большинстве случаев правильным решением является принятие несовершенного мира.
Сила многих небольших компаний заключается в том, чтобы идти к клиенту с компактной командой, очень преданной компании и решающей проблему. При добавлении большего количества людей в команду затраты неизбежно растут (и проблемы с коммуникацией тоже).
Кстати, когда бизнес растет, риск потерять клиента или проблемы, связанные с персональным менеджером проекта, обходятся дороже.
Итак, если вы все еще чувствуете, что в вашей модели что-то сломается, давайте вернемся к основам. Какие еще основные сведения содержатся в описании академической должности?
Что делает учетная запись, а что нет
Аккаунт отвечает за:
- поддерживать доход от клиента (по выручке и прибыли)
- держать клиента довольным (верность клиента)
- увеличить выручку \ прибыль исходя из планов компании
- найти решение для потребностей клиента, предлагая то, что ему нужно (не все, что он может продать).
Проще говоря, первая цель аккаунта - подтолкнуть клиента к росту, предлагая правильные консультации.
Аккаунт всегда ищет беспроигрышную стратегию, в которой цели заинтересованных сторон соответствуют целям компании клиента и целям поставщика. Это требует глубоких знаний об отрасли, клиентах и ассортименте продукции. Этот способ, без давления, медленнее, чем другой, но ведет к долгосрочному сотрудничеству с заинтересованными сторонами, которые делают карьеру и спонсируют поставщика внутри организации клиента.
Чего не делает аккаунт (читай: не может):
- Управление проектом
- Самостоятельно определяйте срок или бюджет
- продать вещь, не полезную для покупателя
- не заботятся о прибыли клиента
Что делает и что не делает руководитель проекта
Первое, на что нужно обратить внимание, чтобы определить объем руководителя проекта, - это этимология имени «менеджер проекта». Он состоит из двух слов: проект и менеджер.
Итак, он руководитель проекта, и его сфера деятельности не может быть ничем иным, кроме проекта.
Внутри проекта он отвечает за результат, поэтому его обязанности:
- управлять бюджетом и следить за тем, чтобы расходы не превышали бюджет
- соблюдать сроки
- заставить вещи работать внутри проекта
- позволить адекватное общение внутри команды (с участием заказчика)
- крайний срок торговли, релизы и результаты с заказчиком
- фильтровать и отправлять информацию
Чего не делает руководитель проекта (опять же, читайте: не может):
- продвигать товар или продавать вещи покупателю
- стал важным
- принять техническое решение
- заменить стратега
- пересылать информацию без фильтрации
Что взять домой
Триединство в управлении проектами - полезный ярлык во многих простых сценариях, поскольку он снижает сложность и сохраняет компактность команды.
Дело в том, что растет; такой подход может привести к сложной ситуации, когда что-то происходит из-за человека, а не из-за процесса.
Риски подхода одного человека - снижение качества, ошибок, непрозрачности, зависимости и неудач.
Переход к нормальной ситуации, когда у каждого человека разные обязанности, непросто, но к нему нужно подходить, назначая каждому уникальную роль, а затем уважая соответствие между функциями и обязанностями.
Получите доступ к экспертному обзору - Подпишитесь на DDI Intel
