Бросил программирование и пошёл управлять проектами: что я понял за 7 лет в должности PM

Всем привет! Я — Егор, менеджер проектов в Secreate. Мой стаж в менеджменте — уже 7 лет, поэтому знаний в этой области накопилось на целый лонгрид. Сегодня на реальных кейсах поделюсь, как решать проблемы в проектах по разработке, что должен знать PM и как этому учиться. В конце статьи — ссылка на чек-лист с ключевыми качествами плохого и хорошего PM.

В Secreate я работаю 2 года. У меня техническое образование, я выучился на программиста в РУДН и планировал работать именно в этой сфере. На 1-2 курсе сделал свою первую аркадную игру, где шарик на экране проходит препятствия, даже выпустил её в Google Play. Мне хотелось пройти полный цикл создания приложения: от первой строчки кода до публикации в сторах.

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

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

Однажды мой дальний знакомый пришёл с идеей сделать мобильное приложение и предложил мне взять разработку на себя. Была проблема: выслушав основную концепцию проекта, я понял, что такие сервисы не делает один программист с фриланса — нужна целая команда. Объяснив это, я получил предложение руководить проектом, потому что заказчик оценил мои способности переводить технические моменты на «человеческий» язык в ходе нашей беседы.

Я сразу сообщил, что не являюсь и никогда не выполнял функции менеджера, однако готов учиться этому. Проект шёл три года, мы делали систему лояльности для ресторанов: от фастфуда до премиального сегмента. Подключили более 60 точек по Москве.

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

Я считаю, что первый проект прошёл круто, но были и свои проблемы. Например, я начал предлагать новую функциональность для приложения до того, как прошёл релиз MVP. В большинстве случаев, это неверный путь. В попытках навесить больше «плюшек» размывается основная идея проекта. Плюс, никто не может гарантировать, что те самые «плюшки» понравятся конечному пользователю. В первом релизе всегда стоит фокусироваться на основной функции приложения, а затем, на базе обратной связи, планировать дальнейшие релизы.

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

Не принимайте всё на свой счёт

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

Неважно, что происходит вокруг: множество сообщений, писем, звонков, горят дедлайны и так далее. Разрываясь сразу на всё, вы не достигнете ничего. Возьмите себя в руки, позвольте себе сосредоточиться на одной задаче и просто сделать её, не отвлекаясь на другое.

В качестве небольшого лайфхака: первой в работу можно взять задачу поменьше. Радость от её выполнения и уменьшения общего количества тасков позволят взяться за следующие с большим спокойствием и энтузиазмом.

Кейс

Однажды на моего коллегу-менеджера напали все: и клиенты по текущим проектам, и руководство, и даже коллеги по цеху. Всем что-то требовалось от него «сразу сейчас». Накопились задачи — одновременно шло несколько важных пресейлов, плюс текущие проекты в разработке. Пресейлами он заняться не мог — другие задачи в приоритете. Если он их бросит, с него за них тоже спросят. Но и руководителя я тоже понимаю, потому что пресейлов было много, нужно делать, а оно не делается. С обеих сторон всё легитимно. И я просто написал ему короткое сообщение: «Не обращай внимания, просто делай то, что ты делаешь».

Не бойтесь сказать, что задача не сделана

Кейс: я устроился на проект, где предыдущий менеджер уволился через полтора дня с моего выхода на работу. Я стал выяснять, что случилось. Здесь плохое руководство? Может быть, менеджер неопытен? Или проект слишком «запущен»?

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

В ответ на это он выдавал артефакты, собранные на коленке за полчаса «лишь бы отстали». Я считаю такой подход неверным. Если что-то не сделано, или получен не тот результат — так и скажи. Обоснуй, что ты делаешь и как планируешь работать дальше. Необходимо показать, что подход у тебя все-таки есть, и ты ему следуешь.

Не впадай в панику от количества задач

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

Не нужно обещать всем всё доделать через полчаса-час. Если вы заранее понимаете, что не успеваете — не нужно строить у людей лишние ожидания.

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

Мне нужно:

В момент рассредоточенности иногда достаточно увидеть перед глазами конкретный список задач, чтобы снизить уровень тревоги. Затем взять одну из них и начать делать.

Через день-два вы к этому списку даже не вернётесь. У меня таких заметок штук 50, но они нужны были ситуативно.

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

Стартерпак:

Здесь всё банально до безобразия, но вдруг вы не знали, что менеджер проектов должен уметь говорить словами через рот. Мой личный топ необходимых софтскиллов:

1. Развитые коммуникативные навыки. Они закрывают любые проблемы.

Менеджер находится на стыке всего:

— команды, которой интересно уйти пораньше или просто отдохнуть;

— руководства, которому интересно, укладываемся ли мы в бюджет, на каком уровне маржинальность;

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

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

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

Такая коммуникация помогает сгладить многие углы, в том числе проблемы из-за переноса сроков. Клиент вас начинает слушать и понимать, соглашаться с вашими предложениями по поводу развития его продукта. Не придётся подписывать допсоглашения и платить штрафы. В «официозе» всё строится вокруг бумаг. Этого лучше избегать. Выстраивать отношения так, чтобы и заказчик не боялся вам написать после 18:00 по какому-то важному вопросу.

2. Пунктуальность. Важно не опаздывать на встречи, грамотно их планировать, писать отчёты, быть чётким в своих действиях. Если менеджер где-то факапит, команда очень быстро скопирует модель поведения, и с них будет сложно спрашивать результат в срок. Рыба гниёт с головы.

3. Ответственность. Всё, что вы наобещали, нужно сделать. При этом не скрываться, если что-то не выходит. Не нужно думать, что сейчас никто не заметит, а мы потом наверстаем. Все всё заметят. Если вы опаздываете по задаче на день, нужно об том сразу сказать, чтобы потом не пришлось перед самым демо всех оповещать, что сегодня его не будет… Оно будет завтра… А, может быть, и не завтра…

4. Грамотная устная и письменная речь. Сразу пахнуло вакансией с HH от какого-нибудь ИП, но это правда жизни. Это влияет на отношение к тебе — есть люди, которые очень заостряют внимание на грамматике и пунктуации. Встречают по одёжке.

5. Проактивность. Если вы видите, что вам через месяц или два будут нужны от клиента какие-то документы, доступы, аккаунты или другая информация — спрашивайте сразу, как поняли это. Не за 2 дня до часа X. Потому что потом может быть всё, что угодно. Клиент не возьмёт трубку, уйдёт в отпуск, заболеет. Идеальный сценарий — сразу на старте проекта составлять список вещей, которые вам могут понадобиться, и в том же момент их запрашивать. К слову, направьте этот список сразу на почту заказчику. Так вся информация будет в одном месте и к ней всегда можно будет обратиться.

1. Долгие согласования с клиентом

Чем больше стейкхолдеров — тем хуже. В таких кейсах сложнее управлять циклом двухнедельных спринтов.

Как решать: готовить всё заранее и пушить клиента, чтобы двигать процесс. При этом делать это деликатно и стараться помочь, чем можешь. Например, клиенту нужно зарегистрировать аккаунт в AppStore. Это нельзя делегировать, потому что там много конфиденциальной информации и нужно загружать паспортные данные. Спрашиваете, делал ли клиент это когда-нибудь раньше, нужна ли ему инструкция, когда он собирается приступить. Чтобы быть на связи и содействовать. Если пустить всё на самотёк — клиент сделает через полгода… или через год.

2. Частые переносы встреч со стороны клиентов.

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

Конечно, у вас есть соглашение, которое обязует клиента принимать задачи в оговоренные сроки. Но как только вы начинаете тыкать в клиента этими бумажками, вы снова сваливаетесь в «официоз» и рушите личные отношения. Это нужно делать только в крайнем случае, если клиент сам начал проявлять себя не с лучшей стороны. На самом деле, почти всё всегда можно решить простым диалогом и договориться.

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

3. Клиент решает переделать уже готовую функциональность

Например, заказчик хотел делать поминутную тарификацию оплаты, а потом говорит: «Давайте делать полностью предоплатную систему. Так проще и с законодательством вопрос решается». При этом мы уже начали делать поминутную тарификацию, и она готова на 70%.

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

Если предложение новой функциональности происходит до релиза MVP, нужно обозначить, что это решение может навредить сервису. Ведь ещё непонятно, каким он понравится аудитории.

Если заказчик ставит задачу, которая перечёркивает уже сделанную работу, нужно обозначить возможности и ограничения.

Да, мы возьмём новые задачи, но сроки смещаются, и оплата будет другая. Причём сразу нужно подготовить оценку — насколько она поднимется. Такую проблему можно решить за 1−2 встречи, если заранее подготовить все оценки и прописать возможные варианты.

Немного расскажу о своём опыте работы на реальном кейсе, чтобы вы лучше понимали, с чем приходится сталкиваться менеджеру проектов в работе. Опишу, как вырулил из сложных ситуаций и что мне помогало.

NDA кейс

Проект по разработке приложения для зарядки электромобилей.

Когда я пришёл на проект, у меня было:

— техническое задание и план работ, которые были уже были не актуальны;

— собранная команда, которой уже нужно было ставить задачи;

— согласованный дизайн-макеты, которые сильно отличались от ТЗ.

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

В чём была сложность

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

Я решил построить план разработки с того, что сделать проще и быстрее: заставка на экран, авторизация, карты зарядных станций. Мы смогли буквально через 2 недели показать первую сборку этого приложения. Клиент видел прогресс и нового человека в команде, который действительно занялся проектом.

Потом мы пришли к моменту, когда нужно было подключать зарядные станции и работать с ними. Это нестандартная вещь: не получится просто отправить документацию, чтобы всё заработало. Это интеграция с внешним «железным» сервисом. Да, стандарты прописаны, но у нас нет этой «железки» на руках, чтобы проверить, как она работает. К тому же, оказалось, что документация не соответствовала реальному поведению зарядных станций. Они были от разных производителей, и из-за этого тоже возникали проблемы.

Разработчик писал свой код практически вслепую, потому что нельзя было на деле посмотреть, как приложение будет взаимодействовать с электростанциями. Они находились далеко, клиенту приходилось ездить к ним, чтобы проверить их работу. Все эти действия нужно было заранее согласовывать. Наступает день X, клиент приезжает к станции в своём городе, а она не работает. Отображается какая-то ошибка, и никто не знает, в чём проблема. Всё происходящее ещё нужно как-то объяснить заказчику.

Я спасся тем, что спланировал клиенту в этот день целый план тестирования. Туда входили простые функции: показать, что станция онлайн, что она реагирует на отключения от сети, и сервер это видит. Далее шла проверка статусов коннекторов-розеток и только в конце непосредственно зарядка. В итоге план тестирования состоял из пяти пунктов, из которых не отработал только один. Если бы пункт был только один и он не сработал — это привело бы к негативу, потому что у клиента уже ушло полдня на прибытие к месту тестирования. Но остальные функции работали хорошо. Так что клиент ушёл с ощущением «уже что-то работает и здорово».

Долго не получалось найти проблему, почему зарядка не идёт. Тогда я уже сам сел за сертификацию и протокол и начал разбирать с пристрастием.

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

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

1. Изучайте новые технологии и проектные методологии. Постоянное обучение и развитие помогут вам стать более эффективным сотрудником.

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

3. Создавайте свою базу знаний. Собирайте информацию о проектах, методах управления и технологиях, которые могут быть полезны для вашей работы. Эту же базу можно будет адаптировать для профессионального развития коллег на должности Head of PMO.

4. Участвуйте в проектах с разными командами, клиентами и стеком технологий. Работа с разными людьми и задачами поможет вам лучше понимать потребности клиентов и требования к проектам.

5. Следите за трендами в ИТ-индустрии. Изучайте последние новости и исследования в области управления проектами и технологий.

6. Будьте готовы к изменениям и адаптации — это важные скиллы для PM. Чтобы подготовиться морально к изменениям, вдумчиво повторяйте как мантру: «Стабильность — это иллюзия». Проверено, работает.

7. Не теряйте почву под ногами, даже когда всё горит, а вы — та собачка из мема в огне. Сохраняйте спокойствие в любой ситуации. Сон, смена деятельности, дыхание, хобби, проговаривание проблем, физическая активность, медитации смогут помочь.

Пока я собирал свой опыт в статью, понял, что это только малая часть того, что можно было бы рассказать. В багажнике ещё много материала, как управлять проектами и расти до Head of PMO (к чему я и сам стремлюсь).

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

Пишите в комментариях, что ещё разобрать. Не забывайте ставить «+1», если статья была полезной.

Также подписывайтесь на Телеграм-канал Secreate, там я выложил чек-лист, чем плохой PM отличается от хорошего.