Эволюция менеджера
Базовые качества
О качествах менеджера много написано и в бизнес-книгах, и в сообществах во «ВКонтакте» а-ля «Стартапы для молодых и амбициозных». Кто-то выделяет пять основных, кто-то — двадцать пять.
вот основные составляющие:
· Честность. На уровне «пацан сказал, пацан сделал». Без этого с человеком, по-моему, вообще нельзя иметь дел.
· Интеллект. Сюда входит системное мышление и то, что выявляется посредством IQ-теста.
· Зрелость. Важно не быть инфантильным маменькиным сыночком и уметь вылезти из скорлупки комфорта, если того требует долг.
· Исполнительность. Главное качество любого сотрудника — готовность выполнить распоряжение. Даже если не согласен с какими-то его параметрами. В этом случае можно аргументировать, почему так делать не надо, но если руководство к аргументам не прислушалось — не устраивать саботаж. Не делать по-своему и не делать точно как сказали (что называется итальянской забастовкой). А действовать разумно, не следовать механически инструкциям, не спорить по пустякам и решать задачу.
· Позитив и энтузиазм. Если менеджер по натуре депрессивен, и у него на лице написано «Господи, когда же это всё закончится» — не стоит ожидать, что команда радостно подхватит знамя и с криками «Эгегей! Это всё! Кончайся!» побежит делать проект.
· Внимание к мелочам. Большие проблемы вырастают из мелочей, которые проглядели на старте работ. Или нашли, но решили, что они никак не повлияют на будущее. Мелочи ничего не прощают большому. Поэтому менеджер проектов должен уметь их находить и устранять ещё в безобидном состоянии.
· Готовность к поступку. В бусидо — кодексе чести самурая, — говорится о том, что каждый самурай должен постоянно думать о смерти и делать все как в последний раз. Если отбросить разговоры про смерть и заменить на «готовность к поступку» — вот это как раз оно.
· Требовательность. Умение пойти на конфликт, если что-то сделано плохо, отстаивать свои интересы и интересы проекта. Без этого менеджер не получится.
Технари и продажники
Профессиональный менеджер проектов должен знать веб-технологии, понимать принципы дизайна, иметь хороший вкус и переговорные навыки, знать бизнес-анализ и психологию. В общем, много всего, что вспоминается образ многорукого бога Шивы. Который, кстати, не был самым добрым парнем на земле, а вполне мог карать и миловать, создавать и разрушать (что менеджеру иногда тоже позволительно).
Все навыки менеджера проектов делятся на две группы: коммуникативные и технические.
Если у PM-а проседают коммуникации, он сможет запороть даже проект, сделанный сильной технической командой. И наоборот: менеджер, который умеет договариваться, вытянет слабый проект и сделает так, что заказчик попросит ещё.
Технологии нужны, чтобы общаться с заказчиками на уровне эксперта. Особенно с крупными, на стороне которых менеджером работает зачастую человек, уже поработавший в агентстве или студии.
Не обязательно при этом самостоятельно трогать технологии и понимать, чем реакт отличается от ангулара. Но чтобы профессионально общаться с заказчиками, менеджер в агентстве должен быть более технически подкован, чем менеджер на стороне клиента.
Отсюда вопрос. Что лучше: выращивать менеджеров из технических специалистов, прокачивая их коммуникативные навыки, или обучать специалистов разговорного жанра ИТ-штукам?
Везде есть свои нюансы!
Если мы берём хорошего программиста (а в менеджеры стараются двигать именно хороших сотрудников) и учим его разговаривать, через полгода рискуем получить плохого менеджера и потерять хорошего разработчика.
· Программист может не научиться или не захотеть быть требовательным к коллегам, с которыми раньше общался на равных.
· Уверенный разработчик рискует потерять запал и смелость, столкнувшись с новыми, незнакомыми задачами.
· Проработав «в потоке» несколько лет, не все смогут перестроиться на дерганный режим менеджера.
· В моменты долгих раздумий, когда нападает вселенская тоска (отпуск или новогодние каникулы), уже оформившийся менеджер может удариться в ностальгию и захочет вернуться к программированию.
На случай, если один из этих неприятных сценариев сработает, а с человеком расставаться не хочется — договаривайтесь на берегу, что через определённый срок он сможет откатиться до программиста, если с менеджментом не склеится.
Второй путь — обучать продажника техническим штукам. Ему нужно подробно рассказывать и показывать диджитал-кухню, давать возможность консультироваться с техлидами. И не оставлять без контроля, чтобы продажник не стал паразитом, сидящим на шее у технарей.
Если до этого дойдёт, то для решения самой мелкой задачи он начнёт собирать консилиумы, а ответственность перекидывать на программистов. В запущенных случаях такие ребята напрямую пересылают письма клиентов разработчикам — и так сойдёт.
Но, несмотря на простыню возможных проблем, оба варианты рабочие.
В следующей статье рассмотрим «Несколько ступеней эволюции менеджера»…
