Есть две расхожие точки зрения. Первая заключается в том, что менеджер-технарь горе в семье не к добру, потому что когда дедлайн подступает ближе, он начинает лезть руками куда его не просят, править код, выискивать, а главное находить баги, журить разработчиков и накалять обстановку. При этом, неоспоримый его плюс в том, что он никогда не скажет заказчику, что проект можно сверстать за три дня на коленке потому, что понимает, сколько нужно времени и людей на ту или иную задачу. Часть команды его недолюбливает, часть уважает, в основном, и те и другие по одной причине: он — бывший разработчик.
Напротив, менеджер, который ничего не понимает в разработке, как пить дать будет кормить заказчиков обещаниями, неправильно записывать требования и правки, потому что ничего в них не понимает, на каждую встречу с клиентом будет водить за ручку бедных разработчиков и с умным видом кивать. В целом: существо доброе, безобидное и бесполезное. Авторитет завоевывает долго, постепенно повышая уровень знаний, но сначала его легко водить за нос.
В последние годы все больше свитчеров переходят из других сфер в IT. Что обусловлено быстрым развитием отрасли. И получается следующая ситуация: те, кто работали в банках, логистике, и других сферах, начинают управлять процессом разработки. Программистам не нравится, когда ими командуют «чужаки» (им в принципе не нравится, когда ими командуют, но мы этого не говорили), а PM-ам сложно влиться в работу и начать вести проект. Ведь нужно разобраться в технической стороне вопроса, понять кто из команды чем занимается. Хочется просто нажать волшебную кнопку или выпить магическую таблетку, чтобы быстро прокачать матчасть. К сожалению, таблетки нет и этап адаптации неизбежен для менеджеров, которые ранее не работали в IT.
Мы попросили специалистов из разных компаний и проектов поделиться с нами своим мнением о том, что должен знать проектный менеджер в IT, и должен ли РМ, в случае неполадок в проекте, нырять в омут с головой лезть в код.
Анна Лаврова
Вопрос, по сути, схож на “а должен ли управляющий рестораном уметь готовить?” — думаю, вы вряд ли найдете много управляющих (именно управленцев, не шефов, не хозяев или инвесторов), которые, действительно, умеют готовить на уровне с поварами на кухне. Должен ли?
Я считаю, что каждый человек в бизнес-процессе, должен обладать навыками и знаниями именно своего процесса (так называемые, T-shaped specialists), если так сложилось, что человек пришел в профессию из смежной области, он может быть и E-shaped — только вот длина “щупалец” будет отличаться.
Понимать процесс разработки (приготовления еды, обслуживания клиентов, продаж) — НЕ значит “уметь кодить“.
На каком-то уровне я умею кодить, даже на первом курсе делала лабораторки на паскале и бейсике за весь поток, написала несколько программ на Delphi и даже делала сайты и приложения-игры на Flash. Делает ли это меня “техничным PM-ом“? Абсолютно, нет. Могу ли я посмотреть код? Нет. Другой вопрос — должна ли я смотреть код?
Я лично знаю несколько PM-ов, которые пришли в менеджмент из разработки, и каждый из них говорит, что потратил несколько лет на то, “чтобы научиться не лезть в код, в разработку и в технологии” — ибо старый опыт не забывается легко, и часто хочется решить проблемы и задачи за команду, или же повлиять на их решение. Когда перед моей командой стоит вопрос выбора технологий, я жду аргументов за и против, сравнений, данных, мирового опыта и лучших и худших кейсов — а не принимаю решение “о да, я сама использовала эту технологию“.
Сказать, что PM-технарь будет руководить продуктивней я не могу. Он будет руководить иначе, чем “не технарь“. Однако, действительно важно понимать как процесс разработки, так и тех, кто в него вовлечен и разговаривать с командой без когнитивных убеждений и испорченного телефона.
Я знаю, что такое гит, как и зачем мержить ветки, что такое пул реквест, фиче бранчинг и другие “умные слова”, но при этом, я не знаю, как писать код лучше тех, кто занимается этим профессионально.
Я бы хотел выделить два классических типа: гуманитарий и инженер.
Гуманитарии — это люди, которые по определенным обстоятельствам оказались в ИТ. Соответственно, они стараются обзавестись каким-то инструментарием, с помощью которого они будут доказывать свою профессиональную ценность.
Обычно таким инструментарием выступает комбинация навыков общения, харизма и личная привлекательность + арсенал рамочных фреймворков в организации работы, куда входят как классические методы, так и вещи из мира Agile. Такие люди, как правило, не могут погрузиться в проект, ограничиваясь тем, что задают рамки работы и в стиле немецких гестапо жестоко подавляют любой отход от буквы неписаных законов успешной организации труда.
Инженеры считают, что, чтобы управлять, нужно лучше всех понимать, что там происходит в проекте/в коде.
Это люди, которые выращивают команды сами, лезут в код, смотрят структуру баз данных и сами проектируют наиболее сложные части системы. Если их команды разрастаются, то тогда инженеры начинают прибегать к методам работы гуманитариев, только правилами хорошего тона начинают выступать не только процессные догмы, но и формальные правила создания ИС, которые берут свое начало из системной инженерии: стандарты написания кода, единообразие интерфейсов, модульность проектируемой системы и т.п. Гуманитарии не опираются на все эти правильные штуки не потому, что не хотят. Просто у них нет этих знаний с самого начала.
Евгений Плохой
Если коротко, кодить РМ-у не нужно, но понимать программный код на уровне абстракций – обязательно. Если умеет кодить – круто, главное чтобы не лез в код руками и не давал ценных указаний, как реализовывать тот или иной функционал. А еще PM должен знать о возможностях платформы или языка программирования, на которых строится проект.
Александр Демура
Глубокое понимание технической части, конечно, помогает разговаривать с разработчиками на одном языке, но таит множество потенциальных рисков и проблем. Страсть к микро-менеджменту и убежденность, что знаешь как лучше — одна из них. Другая проблема — без постоянной практики знания начинают безнадежно устаревать, РМ со временем перестает ловить мышей и начинает продавливать давно уже устаревшие подходы времен своей молодости.
Весь накопленный разработчиком опыт ему практически никак не помогает в роли РМ-а — РМ работает не с кодом, а с людьми.
Вообще, РМ — скорее роль, нежели титул, и, в принципе, эту роль может при желании играть любой член команды.
Вот и сказочке конец. А если серьезно, то вывод напрашивается сам собой — будь ты продактом или проектным менеджером, никуда от изучения области, в которой работаешь, не деться. Только задача — не научиться кодить, а разобраться в процессе. Если вы учили или учите программирование, то вряд ли удержитесь от соблазна «дать ценный совет по технологиям». А это делать, как мы уже выяснили, категорически нельзя. Зато можно и нужно понимать, о чем идет речь в проекте в техническом плане.
Кто-то из опрошенных специалистов настаивает на том, что лучший способ стать крутым PM-ом — быть разработчиком, запретившим себе кодить. Кто-то говорит, что гуманитарий с опытом и желанием учиться справится ничуть не хуже. В любом случае, знание проектного менеджмента — не «золотой микроскоп», которым можно «забивать гвозди» что в строительстве, что в IT. Вникать в индустрию придется. Именно поэтому мы рекомендуем всем гуманитариям и выходцам из других сфер пройти курс TechMind, чтобы меньше времени потратить на набивание шишек и получить необходимый базис, сразу, а не в процессе. Это позволит молодому проектному менеджеру задавать меньше глупых вопросов разработчикам, избежать косых взглядов и, главное, заслужить уважение. Ведь в IT-сообществе тяга к знаниям и желание развиваться считается хорошим тоном.