Управлять командой — хорошо. А хорошо управлять командой — ещё лучше.
Правда, есть один нюанс: делать это бывает неимоверно сложно. Ведь нужно не просто найти правильный подход к разработчикам и четко объяснить им поставленную клиентом задачу, но и вести дальнейшую коммуникацию и контролировать ход выполнения, чтобы сдать проект вовремя.
Как это все сделать эффективно, и при этом не сгореть на работе, мы узнавали у опытного Project Manager’а — Юрия Храмова.
Много лет я работал в ресторанном бизнесе. Открывал рестораны, долгое время проработал бар-менеджером в крупных сетях. Это дало мне большой багаж знаний в менеджменте с уклоном на ресторанный бизнес.
Но с началом карантина пришло понимание, что в данной сфере у меня не будет роста и прогресса. Это дало мне толчок двигаться дальше.
Прежде чем найти направления деятельности, которым я бы хотел заняться после ресторанов, прошла не одна неделя. Нужно было точно понять, чем я хочу заниматься дальше и как я смогу развиваться в новой сфере.
Прочитав немало информации о разных сферах, я точно понял, что менеджмент — это моё. В последствии я выбрал направление IT: последние несколько лет я управлял рестораном в крупной IT-компании, и, возможно, это сыграло ключевую роль в выборе направления для перепрофилирования.
С поиском курсов помогли друзья, и я прошел курс Project Management в ITEA. Впоследствии прошел еще курс Agile/Scrum — на мой взгляд, один из самых интересных и запоминающихся экспириенсов у меня.
Так как это был осознанный шаг, я довольно серьезно подошел к обучению и закончил курс с красным дипломом. Ну а дальше все как в кино: новая работа, коллектив, проекты, и в добрый путь!
Из моего опыта, многие компании с матричной структурой управления — то есть, крупные компании — запрашивают у возможных кандидатов подобного рода сертификаты. Но это не означает, что без него вас туда не возьмут. Если вы уверенны в себе и обладаете достаточным багажом знаний — можно обойтись и без сертификата.
На самом деле тут все просто. Любой из этих специалистов тоже когда-то был джуном и не разбирался в своей отрасли так же хорошо, как сейчас.
Хороший менеджер сразу донесет коллегам, что его опыт меньше, и он не претендует ломать их авторитет. Нужно договориться, что ты будешь задавать много вопросов, чтобы вникнуть в суть задач. Также необходимо предоставить сотрудникам возможности для работы и не ограничивать их, а направлять.
Хороший вопрос. На мой взгляд, важнее всего soft skills.
Тут можно сослаться на PMBOK, потому что основа в теориях PM’а — это управление людьми, процессами и координация действий. Из личного опыта могу сказать, что нужно иметь определенные организационные способности, знания характеров людей, понимание их действий.
Если мы говорим про PM непосредственно в IT, то, конечно, надо понимать стандарты разработки любых приложений, сайтов, программ, по которым работает компания или знать нюансы направлений, в которых ты планируешь работать в дальнейшем: геймдев, веб-разработка и т.д. Нужно четко знать на какие этапы делится разработка.
Да, продал 🙂
На самом деле, весь секрет в самоорганизации и дополнительных утилитах, которые помогают это все организовывать: разные практики тайм-менеджмента, планирования, грамотная речь.
Весь объем информации держать в уме, конечно, невозможно. Если тебе удобно делать заметки карандашом в блокноте — делай заметки карандашом, если удобно ставить таски в Jira и отслеживать их выполнение — ставь таски. Важно понимать для себя, сколько будет выполняться та или иная задача. Например, на дизайн-верстку может быть 50 часов, на какую-то задачу по бэкенду — 10 часов и т.д. Это понимание приходит с опытом.
PM должен отслеживать количество рабочих часов в неделю и ориентироваться на это. Ты разбиваешь ряд задач на количество часов в неделю. Ты понимаешь, за сколько они выполнятся и когда тебе нужно поставить напоминалку, что вот эта задача должна быть реализована. Помогают планерки, на которых можно узнать статус по всем задачам и понимать, на какой стадии все находится. Так ты можешь выяснить когда задача будет выполнена.
Ну я бы не был так категоричен, но эта черта очень может помочь в работе PM.
Как сказал Мандалорец: «This is the way». Не ошибается тот, кто ничего не делает. Нужно это принять и с каждым разом становиться лучше, чтобы не повторять ошибок прошлого.
На самом деле за день происходит много интересных моментов.
Но все зависит от того, на какой стадии находится проект или проекты, которые ты ведешь в данный момент.
Обычно на первую половину дня запланированы митинги с ребятами. Необходимо к ним готовиться — быть в курсе дел всех проектов, так как за вчера может много чего произойти. После митингов идет процесс анализа работы — мониторинг и контроль, а также коммуникация со стейкхолдерами проекта, постановка задач для разработчиков, контроль выполнения, анализ эстимейтов. Много чего.
В конце дня, можно подвести итоги дня и составить планы на следующий день.
Например, на подготовительной стадии проекта ты занимаешься планированием и всем, что с этим связано.
Плюсы:
Минусы:
Тут много ветвей развития. Новые проекты — их может быть больше, или сам проект будет крупнее. Специфика работы: аутсорс или продакт-компания. Может быть сфера деятельности компании, в которой есть IT-отдел — например, банковская сфера. Еще можно стать руководителем PMO.
Если копнуть глубже, можно выделить 3 условных уровня развития PM’а.
Первый — это тот, кто работает на стороне заказчика. Ты стараешься выполнить все его хотелки, пожелания, но не берешь в расчет команду. А ведь при этом не всегда задачи заказчика могут быть нужными или выполнимыми.
Следующая стадия — когда ты полностью становишься на сторону команды. Что бы не говорил тебе заказчик, ты начинаешь воспринимать это все в штыки, критиковать, искать ключи, чтобы переубедить его и переманить на сторону идей команды.
Третья стадия — когда ты уже находишь золотую середину и прислушиваешься и к заказчику, и к команде. Тут ты уже понимаешь, что на этом этапе действительно можно сделать так, как говорит заказчик, а вот здесь — так, как говорят разработчики. И ты это должен донести до обеих сторон. Нельзя просто сказать «Это плохая идея» — важно научиться давать встречные предложения.
Необходимо задавать много вопросов и не боятся признаться себе, что ты не можешь знать всего.
Например, я — свитчер. По опыту могу сказать, что надо попасть в IT-тусовку, начать общаться с ребятами, которые работают в IT, чтобы понять, как устроен рынок. Для этого проводится масса вебинаров, конференций, надо в них участвовать и интересоваться, что происходит на рынке. Нужно поглощать много всевозможной информации.
Также не нужно бояться отправлять свои резюме и проходить собеседования, даже если ты не уверен в своих силах. Это всегда дополнительный опыт. Неважно, провалишь ты их или пройдешь хорошо — с каждым разом ты будешь чувствовать себя все увереннее. Обязательно нужно готовиться к собеседованиям: понимать свои обязанности, какой проект будет в компании, что ты знаешь об этом проекте и технологиях. Если чего-то не знаешь — почитай об этом. По-хорошему, нужно иметь общее понимание базовых языков программирования. Необязательно уметь писать код, но смотреть и понимать, что в нем происходит, важно. Полно информации в сети — статей, видео, много школ проводит бесплатные марафоны. Когда вникаешь в базовые принципы разработки, ты начинаешь говорить с людьми в команде на одном языке. А это важно.
В целом для первой работы советую уйти в аутсорс-компании. Здесь ты получишь много опыта: за год у тебя может быть куча проектов и все ведутся по-разному, т.е. ты прокачиваешь себя в разных направлениях сразу.
Уверенное владение компьютером, умение чувствовать людей и вникать в детали. Нужно понимать основы программирования, этапы разработки программного продукта и устройства серверов и хостинга сайтов.
Читать советую следующее.
Стивен Деннинг «Эпоха Agile» — рассказывает о том, как современные популярные компании из обычного менеджмента переросли в Agile, как они выстраивали свою работу. Можно увидеть, как благодаря этой методологии продуктивность и креативность компаний выросла.
Ричард Румельт «Хорошая стратегия, плохая стратегия» — более специфическая бизнес-книга. Она помогает выстроить определенную линию понятий в рамках компании и объясняет, что такое стратегия внутри компании.
Еще можно почитать «Сервис который продает» Джима Салливана. Не профильная тема, но полезная. Она подойдет людям, у которых проблема с soft skills, а именно — с коммуникабельностью. Книга рассказывает о коммуникации, обратной связи, манере людей отвечать на вопросы, показывает, как доносить до человека информацию. Начинающий PM может увидеть, как договариваться со всеми: с упрямыми разработчиками, которые иногда не хотят делать задачи, с жесткими стейкхолдерами, которые требуют невыполнимого. Новичкам эта книга покажет, как находить компромиссы между объективной задачей от заказчика и нежеланием разработчика ее выполнить и наоборот.
«Учиться никогда не поздно».
Но жалею, что не сделал это раньше — дольше бы занимался тем, что мне нравится и приносит доход.
