Debitoor is hiring. No bureaucracy, no legacy code, no bullshit, fury continuous deployment, trips #js #node #react #mongo
×Закрыть

Карьера в IT: должность Project Manager

Multitask image via Shutterstock.

Представляем вашему вниманию третий материал из серии «Карьера в IT», в каждом выпуске которой мы рассматриваем одну из должностей в сфере разработки ПО. Данная часть цикла посвящена позиции Project Manager.

Project Manager — это специалист, чьей главной задачей является управление проектом в целом: проектирование и расстановка приоритетов, планирование выполнения задач, контроль, коммуникации, а также оперативное решение проблем.

PM — нетехническая должность, но большинство украинских PM’ов в IT — это бывшие разработчики или тестировщики. Так, по поисковому запросу «Project Manager» (в отраслях «информационные технологии», «разработка ПО» и «Интернет-технологии») поисковая база LinkedIn находит 2905 человек, из них 1467 (51%) — бывшие технические специалисты: 1182 в прошлом работали «software engineer» или «developer» и 285 — «tester» или «QA».

Согласно статистике ДОУ, среднему украинскому PM’у 28 лет, он имеет зарплату $2000 и опыт работы 3,8 года.

Задачи и обязанности

Основная обязанность и ответственность PM — довести идею заказчика до реализации в установленный срок, используя существующие ресурсы. В рамках этой задачи PM’у необходимо построить план разработки, организовать команду, настроить процесс работы над проектом, обеспечить обратную связь между командами и заказчиком, устранять помехи для команд, контролировать качество и поставку продукта в срок.

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

С другой стороны, задачи PM’а можно объединить в 3 группы:
— достижение целей проекта и клиента (эффективное выполнение задачи, обеспечение высокого уровня удовлетворенности клиента);
— достижение целей начальства и компании (финансовые показатели);
— достижение целей членов команды (мотивация, помощь в реализации карьерных целей, предотвращение конфликтов).

«Главная постановка задачи для PM’а: „Нам нужно, чтобы это работало“, что подразумевает, что команда предоставит результат в разумные сроки с разумным уровнем качества».

Обязанности PM’а:
— проектная документация;
— составление плана проекта;
— согласование сроков;
— анализ возможных рисков;
— участие в подборе и утверждении проектной команды;
— разбивка продукта на компоненты и раздача их исполнителям;
— определение требуемых ресурсов и рабочей среды, их распределение внутри команды;
— постановка рабочего процесса в команде (разработка, тестирование, работа с требованиями);
— определение приоритетности задач;
— организация работы команды вокруг требуемой задачи;
— отслеживание состояния проекта, хода выполнения задач;
— отслеживание должной приоритетности выполнения задач;
— отслеживание нагрузки задачами и прогресса по задачам каждого разработчика;
— отслеживание сроков выполнения задач;
— удерживание команды в рабочем состоянии, мотивация команды;
— создание прозрачной среды общения между всеми участниками процесса;
— отслеживание удовлетворенности проектом со стороны команды;
— решение всевозможных конфликтных ситуаций внутри команды и в связке заказчик-команда;
— общение с заказчиком, управление его ожиданиями;
— предоставление заказчику отчетности о ходе выполнения задач и проекта в целом;
— презентация заказчику готовых решений, демо-версий, прототипов;
— интервьюирование новых членов команды.

«Также надо разруливать всякие головняки, связанные с явными и неявными конфликтами. Неявные конфликты такие: заказчик хочет весь свой тухляк на вчера и недорого, начальство хочет как можно дольше и больше зарабатывать, а программисты просто хотят, чтобы было интересно, и крутую з/п».

В маленьких компаниях PM’ам иногда приходиться включать в свои обязанности работу других специалистов: управление требованиями (работа аналитика), управление персоналом, найм и рекрутинг (работа отдела HR), решение офисных нужд.

«У нас PM — это такой себе god object: принимает проект, пишет документацию, проектирует UI и API, планирует, выступает скрам мастером у команды, ведет всю отчетность по проекту, выставляет инвойсы клиенту. Если надо, может и тесты написать для API, мануально потестить, отрисовать кнопочки в фотошопе, иногда даже и закодить. Такой себе прекрасный дилетант — всё, но ничего углублённо».

Работу PM’а можно разделить на 5 режимов:

  1. Проектирование нового продукта или какого-либо нового функционала. На этом этапе PM организовывает митинг с техническим архитектором и разработчиками, оглашает задачи, которые им предстоит решить. В результате команда определяет путь, по которому пойдёт разработка.
  2. Планирование. На этом этапе важно учесть все факторы, влияющие на ход разработки, в том числе квалификацию сотрудников и связанные с ними риски, зависимость от сторонних сервисов, багфиксинг.
  3. Контроль. «Ежедневное многократное действие, которое необходимо PM’у для понимания, что происходит в проекте. Нужно всегда держать руку на пульсе».
  4. Оперативное решение возникающих проблем.
  5. Коммуникация с заказчиком, командой, сопутствующими сотрудниками на всех этапах развития проекта.

«В нашей стране должность PM’а часто эволюционирует из должности старшего разработчика, техлида или QA-лида. Таким образом, у новоиспеченного PM’а может начисто отсутствовать управленческий опыт. И, как часто случается (эффект нимба), организация теряет хорошего технаря и приобретает плохого PM’а».

Типичный рабочий день PM’а предполагает:
— Планирование очереди задач на текущий день;
— Проверка выполненной работы команд за прошедший день;
— Проведение стендапа с командой;
— Коммуникации с заказчиком по эмейлу, скайпу, телефону, митинги;
— Работа с документацией, отчетность;
— Мониторинг выполнения задач;
— Решение разнообразных текущих проблем;

«Открыть глаза, взять телефон — проверка почты, если нет заголовков URGENT — пойти чистить зубы. Во время завтрака проверить почту, рассортировать. Ответить только на URGENT. Приехать на работу, разбросать почту, ответить, добавить в свой лист задачи, расставить приоритеты».

«Узнать в офисе, что у нас сломалось сегодня. Понять, кто будет это чинить, и адресовать. Попытаться заняться беклогом. Попробовать выяснить, кто будет чинить то, что сломалось только что. Адресовать. Попытаться заняться беклогом».

В качестве Библии по классическим обязанностям PM’а рассматривается книга PMBOK — свод знаний по управлению проектами.

«Хоть чучелом, хоть тушкой, но проект надо выпустить».

Достоинства и недостатки

Должность PM’а привлекает соискателей возможностью вплотную заниматься управлением: принимать решения, организовывать быстрое и качественное создание продукта, обеспечивать рабочую атмосферу в команде, координировать и контролировать действия разработчиков.

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

«Привлекает возможность решать проблемы, это как адреналин».

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

Среди недостатков этой должности PM’ы отмечают работу в стиле нон-стоп: ненормированный рабочий график, постоянную перспективу овертаймов, необходимость реагирования и решения срочных задач в нерабочее время, а также стрессовость работы. Еще один минус — высокая ответственность даже в случаях недостаточного уровня влияния на результат.

«Начальство часто считает, что РМ должен делать всё и всегда виноват только он. Какая-либо оплошность команды в целом (низкое качество, несоответствие требованиям, затягивание сроков и т.д.) ложится полностью на плечи РМ’а, в то время как члены команды не несут никакой ответственности. Если проект успешный — команда молодец, сделала проект. Если провал — РМ виноват. Это демотивирует и добавляет седин».

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

«Из-за специфики профессии приходится много работать с разными людьми — это морально утомляет, из-за чего вне работы общение вообще хочется свести к минимуму».

«Слишком много энергии тратить на „зажигать“ — вечером приходишь выжатый как лимон».

«Часто операционная работа отнимает большую часть времени, и пропадает чувство удовлетворения от завершения какой-то большой и важной задачи».

Как стать PM’ом и куда идти дальше?

Главные качества PM’а — это хорошее знание предметной области бизнеса, лидерские качества, опыт работы с людьми, навыки презентаций и убеждения, умение договариваться и учитывать интересы разных групп людей, способность вежливо и понятно излагать мысли на многих языках, а также умение собирать общую картину по разрозненным фактам. Также необходимы опыт планирования, оценки и устранения рисков, знание гибких и классических процессов разработки и умение выполнять административные задачи и создавать команду. Будет плюсом опыт в разработке или тестировании.

«Хороший PM ценит время, является хорошим аналитиком, психологом, лидером; энергичен, позитивен, не паникует, вместо отговорок ищет пути решения проблем, политкорректен, понимает стратегию и тактику».

«Важно уметь быть ведущим, а не ведомым, а также находить баланс между диктатурой и бесконтрольностью».

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

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

Карьерный путь к должности PM у специалиста, который ранее уже работал в IT, выглядит примерно следующем образом: Разработчик (тестировщик) —> Ведущий разработчик (тестировщик) —> PM.

«Изначально я выбрал профессию программиста. За несколько лет работы понял, что мне больше нравится и лучше получается общаться с людьми, а не с дебаггерами, поэтому решил изменить свою должность в ИТ».

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

«Если хочешь стать PM’ом, твои навыки должны подходить под стиль управления в компании, ты должен иметь нормальные или хорошие отношения с руководителем. В идеале твоя кандидатура должна приходить твоему менеджеру в голову первая, если он думает о своей замене».

А вот пример карьеры не-ITшного PM’а:
«В ИТ я попала случайно. По образованию лингвист. Одна компания расширяла штат менеджеров проектов и была готова обучать персонал. Меня взяли на позицию Junior project manager, где я проработала полгода. Потом я прошла evaluation, и мне стали давать отдельные проекты. Честно говоря, все знакомые мне PM’ы пришли в профессию точно так же — с ин.яза, без опыта, но с каким-то интуитивным пониманием диджитал процессов. Важно, чтоб тебе было легко разобраться в работе, иначе не получится. Если для тебя нет разницы между форматами .gif и .swf, если ты не понимаешь, как сервер общается с клиентом, даже если тебе эту схему нарисовали на бумажке, вряд ли получится стать менеджером ИТ-проектов».

Закономерным продолжением карьеры менеджера проектов является рост «по горизонтали», то есть расширение полномочий, степени ответственности и глобальности задач, и в дальнейшем занятие должности Program Manager. Если интересно развиваться в других, нетехнических, направлениях менеджмента, то можно перейти в отдел продаж или в отдел по работе с клиентами. Вообще говоря, перспективы не ограничены, включая топ-менеджмент: CTO, CEO, CIO, COO.


P.S. Спасибо за помощь в написании статьи 18 украинским PM’ам, которые поделились с DOU таинствами своей профессии. Приведенные в статье цитаты взяты из их рассказов.



Остальные статьи цикла:
Карьера в IT: должность Team Lead
Карьера в IT: должность Software Architect
Карьера в IT: должность CTO
Карьера в IT: должность QA engineer
Карьера в IT: должность QA Automation engineer
Карьера в IT: должность Бизнес-аналитик
Карьера в IT: должность Системный администратор
Карьера в IT: должность Data Scientist / Machine Learning Engineer
Карьера в IT: должность Technical Writer
Карьера в IT: должность Delivery Manager
Карьера в IT: должность Software Product Manager

  • Популярное

49 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
А вот пример карьеры не-ITшного PM’а:
«В ИТ я попала случайно. По образованию лингвист. Одна компания расширяла штат менеджеров проектов и была готова обучать персонал. Меня взяли на позицию Junior project manager, где я проработала полгода. Потом я прошла evaluation, и мне стали давать отдельные проекты. Честно говоря, все знакомые мне PM’ы пришли в профессию точно так же — с ин.яза, без опыта, но с каким-то интуитивным пониманием диджитал процессов. Важно, чтоб тебе было легко разобраться в работе, иначе не получится. Если для тебя нет разницы между форматами .gif и .swf, если ты не понимаешь, как сервер общается с клиентом, даже если тебе эту схему нарисовали на бумажке, вряд ли получится стать менеджером ИТ-проектов».
Уважаемое сообщество, подскажите, пожалуйста — какие компании имеют подобную практику?

«Узнать в офисе, что у нас сломалось сегодня. Понять, кто будет это чинить, и адресовать. Попытаться заняться беклогом. Попробовать выяснить, кто будет чинить то, что сломалось только что. Адресовать. Попытаться заняться беклогом».

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

А вообще не представляю программиста на этой должности, стрессоустойчивого такого общающегося с недалеким заказчиком, который доказывает что он может его научить как правильно тексты форматировать, а дизайн вообще рисуется в 2 клика...
Но вы ведь легко представляете программиста, «стрессоустойчивого» общающегося с таким же менеджером?

Каким таким же? PM не может быть таким же как клиент, или может но не долго, поскольку толку с него никакого. Таких менеджеров можно ставить для общения с клиентом, но не с командой. Хотя даже в этом случае могут быть проблемы начиная со сроков нереальных, заканчивая странными требованиями

Всем привет!
Интересная статья, много отзывов о том что не все PM’ы с техническим бекграундом, но есть ли такое в реальности?
Я например PM но совсем в другой степи (маркет. исследования).

Есть ли возможность когда-то податься в IT?

Спасибо

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

Спасибо за статью. Как раз целюсь в ПМство.

Хорошая и толковая статья.

В целом статья все правдиво описывает. Плюс-минус во многих проектах на 5+ человек в команде разработки так и есть
Пару замечаний с моей колокольни:
1.

проектирование
Это задача всей проектной команды, а не PM-a. Области PM-a в данной деятельности — определение рисков, определение и распределение ресурсов, администрирование процесса проектирования (митинги-шмитинги, документы-мокументы...)
Собственно ниже так и написано:
1. Проектирование нового продукта или какого-либо нового функционала. На этом этапе PM организовывает митинг с техническим архитектором и разработчиками, оглашает задачи, которые им предстоит решить. В результате команда определяет путь, по которому пойдёт разработка.

2.

контролировать качество
Это задача QA. Задача PM-a — организовать этот контроль, создать и результативно применить роль QA, но не выполнять ее.

3.

Обязанности PM’а:
...
— (1) разбивка продукта на компоненты и (2) раздача их исполнителям;
(1) — это обязанность команды разработки. Обязанность PM-а — обеспечить процесс/процедуру для этого, и контролировать результат.
(2) — зависит от подхода к работе над оперативным списком задач (backlog, iteration, queue). При push подходе — обязанность PM-а, при pull подходе — обязанность команды разработки.

4.

...
— (3) определение приоритетности задач;
— (4) общение с заказчиком, управление его ожиданиями;
— (5) предоставление заказчику отчетности о ходе выполнения задач и проекта в целом;
— (6) презентация заказчику готовых решений, демо-версий, прототипов;
...
Обязанности из этого набора сильно зависят от специфики проекта (предметная область, масштаб, зрелость продукта,...). Чаще всего в моих проектах эти обязанности выполняет Product Manager/Product Owner. По (3) и (4) — самостоятельно, по (5) — с участием PM-а, а по (6) c участием команды разработки.

5. Если "типичный рабочий день"=="день посреди sprint-а" (процесс разработки == Scrum), то следующее — верно:

— Планирование очереди задач на текущий день;
— Проверка выполненной работы команд за прошедший день;
— Проведение стендапа с командой;

Иначе — скорее исключение, чем типичный случай. Для конкретики приведу факты из моего текущего проекта:
— задачи запланированы и распределены заранее;
— проверку выполняют: QA (на Testing environment) + разработчики (per-review, unit testing) + Release Manager (перед релизом и hotfix-ом) + Product Manager/Reporter (на Staging environment)
— нет никаких ежедневных совещаний (stand-up, daily scrum, «летучка» etc.), а есть JIRA, где все видно и без совещаний.
В «типичный» день PM-а я бы добавил «выполнение контроля рисков», поскольку именно за это PM (с технической экспертизой) отвечает всегда.

6.

пришли в профессию точно так же — с ин.яза, без опыта, но с каким-то интуитивным пониманием диджитал процессов.
Это точно было интервью с PM-ом из разработки ПО? «Digital» — это термин из немного другой области — издательской, рекламной, медийной.

7.

включая топ-менеджмент: CTO, CEO, CIO, COO.
CIO я бы из этого списка исключил, если мы говорим о PM-е в проектах разработки ПО. Chief Information Officer — это цель вертикального развития для системных администраторов и консультантов по внедрению систем автоматизации.

Спасибо автору за статью, а DOU за обсуждение. Будет на что сослаться :-)

Это точно было интервью с PM-ом из разработки ПО?
Точно. :)

Спасибо, особенно с учетом п.5 — любых не-технических можно было бы набирать в АйТи, если б не Скрам... Имхо JIRA все-таки решает вопросы проверки и очереди, но не стэнд-апа.

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

habrahabr.ru/...ep/blog/205832

В национальных реалиях — это в больших случаях «который бегает во все стороны и спрашивает у всех что происходит.» (к)

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

Содержательная статья, спасибо.
Один момент: "

— достижение целей членов команды (мотивация, помощь в реализации карьерных целей, предотвращение конфликтов).
" аж 3-й в списке задач. Если эта задача решается, то возрастает вероятность отсутствия проблем с 2-я другими. Я бы поменяла.

Еще раз спасибо

ПМ чето рисует бернаут чарты для visibility руководству, задрачивает по поводу багов трехгодичной давности про которые уже все согласились что это не баг но никто не берет ответственность его убрать из беклога, создает кучу корреспонденции и обеспечивает «коммуникации» которые на самом деле только отвлекают народ от дела. То есть видимость деятельности есть но качество от этого не улучшается, и народ расхолаживается, можно опять же поспать на митинге.
Когда начинается жопа, ПМ начинает все формализировать и бюрократизировать, чтоб можно было на кого то свалить если что потому что имярек де не выполнил написанное в параграфе 2 части 3 и два раза пропустил скрам утром, ах как плохо!
Хороший инженер в ПМы не пойдет, а малошарящий ПМ нужен как собаке пятая нога.

Burndown charts рисует плагин Jira Agile, например. Необязательно на это тратить время. Баги трехгодичной давности, про которые все согласились, что это не баг — нужно просто закрыть со статусом ~won’t fix и забыть.
В общем, вас явно разочаровал какой-то конкретный PM и вы обозлены на всю профессию в целом. Это не совсем правильно.

Всё-таки я придерживаюсь мысли, что должность PM в чистом виде — это стратегическая ошибка и гораздо полезнее иметь роль, которая в этой серии статей обозначена как Team Lead. Работать с PM-ами, которые не имеют технического опыта и не участвуют в разработке меня всегда раздражает. Они, когда становится горячо, начинают бюрократизировать процессы, прикрывая собственную некомпетентность попытками тотального контроля и перекладывания ответственности на плечи кого-либо вне команды, а если не получилось — то и в самой команде. Это редко приносит пользу и сильно демотивирует. Конечно, при конвеерном производстве сайтов это может быть уместно, но если работа идёт над несколькими продуктами или сервисами — лучше иметь нормального лидера команды. Он не обязан быть лучшим технарём, но обязан разбираться во всем, что происходит в проекте, и уметь находить решения нетривиальных проблем.

Ах если бы все проблемы были в плоскости разработки...
Вот и получается, что PM-у нужно быть немножко тимлидом, немножко психологом, немножко продавцом, немножко ...

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

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

То есть, другими словами — тимлид больше ориентирован на производственный процесс, а ПМ — на отношения с заказчиком, бизнес-показатели проекта и психологический климат в коллективе (хотя, последним, в идеале, тоже лучше бы заниматься тим лиду)

Есть задачи, с которыми, как правило, плохо справляется выросший из технаря Тим Лид — в первую очередь, продажно-переговорно-мотивационного свойства.
Продажи — это вообще совсем отдельная задача. Тут без специализированного продажника — никак. Тех.Лид. — может выступать дополнением к нему в качестве технической поддержки и быстрой ответной реакции, обратно таки технической. По продажам тех. — даже не ноль, скорее минус.

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

Не знаю насчет обычных, меня не напрягает, а даже развлекает заниматься этой вашей бухгалтерией. :) А уж всякие составления договоров и т.п. так и вовсе напоминают программирование на языке а-ля “ділове українське мовлення”. Те же объявления переменных, ссылки и условия. Я думаю, это вопрос личных качеств.

Спасибо. Будет ли статья про Account Manager’a? А то со всем всё понятно, а вот о AM мало знаю =)

В ближайших планах СТО, QA и, собственно, dev junior—>middle—>senior, а там посмотрим. )

«интуитивное понимание диджитал процессов», надеюсь, не ограничивается пониманием «разницы между форматами .gif и .swf»

Спасибо! Отличная статья!

Еще надо сказать, что требования к ПМ-ами и их обязанности очень сильно отличаются в зависимости от того, какая компания и какие проекты.

Основную задачу PM можно сформулировать очень просто: сделать все зависящее, чтобы команда сделала проект в нужном объеме в указанный срок и бюджет с необходимым уровнем качества.

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

еще можно прийти в PM через UX, например.

imho
PM skillset = ( mid/high technical + mid managing + low/mid organization + high communication )

Спасибо, статья что надо!

Изначально я выбрал профессию программиста. За несколько лет работы понял, что мне больше нравится и лучше получается общаться с людьми, а не с дебаггерами, поэтому решил изменить свою должность в ИТ

Как-то неоднозначно звучит, не правда ли? Хотя, признаюсь, стоит радоваться — одним амнакодером меньше.

Хорошая статья! Спасибо автору!
Мы как раз недавно открыли школу в Харькове для менеджеров проектов (www.PMsSchool.com).
Уже успели выпустить первый поток студентов.
По моим наблюдениям в PMы с нуля идут учиться и работать в основном те люди, которые уже работают в IT (QA, разработчики, sales-менеджеры, HR-менеджеры) или «около IT» (Интернет-маркетологи, хозяева бизнеса в Интернет, стартаперы).
Хорошие «нетехнические PMы» — менеджеры ВЭД, которые хорошо владеют английским языком и знают принципы управления.
Есть еще достаточно интересный сегмент — жены программистов, которых отправили сами программисты во имя айтизации семьи))))

Я дико извиняюсь, но при всем уважении к образовательным проектам в целом и вашей школе в частности, можно я тут тихонько поржу над доменным именем школы?
По-моему, его можно отправлять в один зал славы с www.PenIsland.com

а что, название сайта и картинка на главной,
3.bp.blogspot.com/...cc/s1600/1b.png
очене даже соответсвуют названию
lurkmore.to/ПМС

Это выгдялить как диагноз всему укр. аутсорсингу:

Согласно статистике ДОУ, среднему украинскому PM’у 28 лет, он имеет зарплату $2000 и опыт работы 3,8 года.

блондинкоПМ, особо радуе «интуитивное понимание процесов»

Меня взяли на позицию Junior project manager, где я проработала полгода. Потом я прошла evaluation, и мне стали давать отдельные проекты. Честно говоря, все знакомые мне PM’ы пришли в профессию точно так же — с ин.яза, без опыта, но с каким-то интуитивным пониманием диджитал процессов.

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

с каким-то интуитивным пониманием диджитал процессов
Facepalm! Занавес!

Исходя из моей практики, есть два принципиально разных PM — технически и не технический.

Технический PM — это тимлид, на которого нагрузили больше бизнес и организационных вопросов. Такое может работать только в небольших проектах (максимум 3-4 человека в команде), иначе нагрузка будет слишком большая на одного человека. В наших мобильных проектах это работало.

Нетехнический PM занимается только организационной работой, общением с заказчиком и мониторингом проекта. Может быть еще и официально account manager, полностью забирая на себе все коммуникации с клиентом, в том числе и по финансам. Соотвественно, либо команда должна быть по настоящему технически зрелой, либо иметь еще и тим/тех лида.

По большому счету PM и должен заниматься «организационной работой, общением с заказчиком и мониторингом проекта». И здесь не сильно важно, есть у него технический бекграунд или нет. Если PM занимается техническими вопросами, то он уже не PM, а какой-нибудь Team Lead / Tech Lead / whatever. И в таком случае ему действительно приходится сидеть на двух стульях.

Просто у нас в аутсорсинге все с ног на голову немножко.

Я вот сидел на двух стульях. Там в принципе больше можно насчитать, стульев этих. Вы считаете что это однозначно плохо?

И кстати — в стартпах количество стульев под одной попой — уверен еще больше.

Я этого не говорил :) Мой поинт в том, что PM — это роль с определенным и довольно большим набором навыков и знаний. Ее может выполнять главный разработчик, Scrum master (да, я знаю, что это плохо, но я видел и такое), сам клиент (часто клинические случаи) или выделенный PM-специалист (возможно, парт-тайм, если проект небольшой). Я видел много случаев, когда на эту роль ставили неопытных в PM технарей, потому что «больше некому», и они фейлили проекты. Те, кто учились на своих ошибках, изучали матчасть, улучшали софт-навыки, со временем становились отличными PM-ами.

Поэтому я и сказал про специфику аутсорсинга, что по-другому этих самых PM-в получить нельзя — только переучивать технарей или брать нетехнарей и учить их с нуля. В наших вузах вроде бы учат менеджменту, но 1) не уверен, что проектному, 2) точно не в сфере IT. Появляются частные курсы, но мне сложно сказать, насколько они эффективны — надо смотреть на выпускников и их достижения.

А еще сейчас набежит куча людей, которые скажут, что PM не нужны, технические команды самоорганизовываются и могут сдавать проекты успешно по Scrum’у :) И тоже будут правы, но лишь отчасти и далеко не всегда :)

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

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

Вот только найти таких универсалов тяжело, поэтому приходится делать специализацию. Да и успевать универсалу за всеми направлениями сложнее, чем человеку с узкой специализацией.

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

Project Lead / Software Architect
Project management, technical leadership

Вижу и вы используете технический бэкргаунд, коллега ;)

Конечно, использую :) Я же тоже продукт этой самой школы «выбираем того, кто скорее всего не зафейлит, и бросаем в воду — авось выплывет». Важно понимать, в чем заключается твоя задача и где заканчивается твоя роль на проекте и начинается чужая :)

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

Подписаться на комментарии