Роль ПМ-а — она есть всегда, и если не поручена отдельному человеку с нужной подготовкой, то перераспределяется.
Кому?
- Всем членам команды в равной степени.
- Одному члену команды готовому совмещать это со своей первичной ролью.
- Человеку извне, который в процессе толком не участвует, но как-бы управляет.
Все эти варианты вполне реальны, и встречаются на практике, в особенности в молодых компаниях, в которых еще нет структуры и процессов.
Держим сразу в уме вопросы:
- Кто общается с клиентом?
- Кто держит в уме всю картину проекта? А лучше документирует её.
- Кто организовывает процесс?
1. Роль менеджера распределяется всем — и при этом команда средняя по опыту — будет тяжело. Люди не будут знать что делать, и придется много времени митинговать. Совокупная стоимость их часов на обсуждение быстро уйдет в небеса. И не факт что будет достигнут компромисс.
Также общаться с клиентом надо уметь — даже с адекватным, с неадекватным это сложнее в разы. Кто-то не терпелив к вопросам и утверждениям несведущего заказчика, кто-то не понимает совсем его бизнес и зачем ему нужен продукт. Селфтаскинг и прочие радости тоже чреваты проблемами, да и просто не любят разработчики этим заниматься — а значит делают это посредственно. Не забываем что кто-то должен контролировать всё.
Такая схема работает только с очень скилловыми специалистами которые больше участвуют во всем процессе, и способны понять бизнес, цели проекта, свои задачи в его рамках, и им не нужен контроль, так как они сами себе цензура. Думаю все согласятся что таких разработчиков мало и они при деле.
2. Один из программистов — сходу, он сможет адекватно понять бизнес-требования и перевести на понятный язык своим бойцам? Ведь согласитесь, человек то что не понимает, то пропускает мимо ушей — а не понимает в бизнесе средний разработчик много вещей, так как не его сфера совсем, и часто просто неинтересно. Дальше своим ребятам он объяснит коротко — что надо, каждый опять понимает по-своему и результат — полный провал. Потому что, опрашивать клиента надо уметь, объяснять другим тоже надо уметь, и с людьми притираться и склеивать команду тоже необходимо.
Совмещать роли Тимлида и ПМ-а может только очень классный специалист, умеющий понимать клиента, управлять, общаться и разумеется программировать. Серьезный набор, мало таких людей — это исключения.
3. Человек глубоко не погружающийся в проект — наихудший вариант имхо. Часто у него просто нет времени на это, он подхватил заказ по случаю через связи, деньги хорошие, нашел команду технарей — и дело пошло. Параллельно у него еще, как правило, есть занятие поважнее.
В итоге технари без понятия что надо делать, и не переспрашивают — что-то пилят. Он сам понятия не имеет что они разрабатывают, изредка проверяет, но в основном на тест ничего не выходит. Про заказчика вообще молчу. Так происходит потому, что на такие проекты в 80% случаев попадают фрилансеры-одиночки, которые не умеют и/или не хотят работать совместно с кем-то, и не особо умеют делать что-то сложное, где в одиночку не справиться, потому что на биржах таких проектов практически нет. Соответственно никакой самоорганизованной команды крутых ребят не будет. Будет группа ничего не понимающих одиночек. Повезло если к ним попадет лидер, который сможет их сплотить. И то это не сразу и без гарантий.
Так зачем ПМ?
Первое — держать в уме всю картину, и документировать её вовремя с проектной точки зрения. Членам команды нужно прорабатывать детали, и проект как единое целое от них часто ускользает. Сложно постоянно двигаться от частного к общему и обратно. А вот менеджер обязан это делать, и отвечать в меру своей компетенции на все вопросы.
Второе — быть единым контактным лицом для всех. Вся информация должна проходить через него, иначе сразу начнется бардак. Заказчик договорится с отдельным разработчиком, или предъявит ему баги, тот никому не скажет, баги касаются и других и пошло-поехало.
Плюс претензии — менеджер он еще и громоотвод, он выслушивает, принимает все претензии, и в конструктивной форме передает их команде, зная на кого и как воздействовать. Нередки случаи, когда камни летят в конкретного программиста, а тот от первичного шока начинает делать глупости: говорить лишнее, валить на других, нападать в ответ, убегать.
Третье — решать вопросы. И это не если они появятся, а когда они появятся. Потому что появятся они точно. Ведь нужно четко всё распланировать, мониторить, потом протестировать, пофиксить, показать клиенту, получить денежки, посчитать часы каждого, в идеале еще и провести разбор полётов. Во всех этих вещах возникают коллизии которые надо, либо предупреждать, либо решать по ходу. То есть, выстроить изначально процесс и определить правила игры, и дальше решать текущие проблемы и вносить при необходимости новые правила.
Кстати без профильных знаний в управлении это делать достаточно сложно.
Глобально ты либо прошел подготовку в этой сфере предварительно, либо все грабли протестировал на себе и вышел битым управленцем в шишках. Конечно профильное образование всех граблей не уберет, но часть точно, и скорость усвоения опыта будет значительно выше.
Автор: Виталий Степовенко
