«Растишка» не поможет: 6 ошибок, из-за которых менеджеры-джуны остаются джунами

Привет, я Вика Строгонова, руководитель проектного офиса в KTS. Я веду проекты с 2017 года и прошла путь от младшего менеджера до руководителя проектного офиса. Сейчас в моем портфеле более 20 проектов и 42 человека, среди них разработчики, аналитики и менеджеры.

Текст написан на собственном опыте, поэтому уверена, что есть и другие ошибки, которые я не учла в статье. Буду рада, если поделитесь ошибками джунов, с которыми вы чаще всего сталкиваетесь, в комментариях. 

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

У этих проблем есть две причины: 

1. Отсутствие грамотного менторства у менеджеров-джунов.
2. Отсутствие опыта и спорных ситуаций на прошлых проектах.

В основном мы в KTS занимаемся заказной разработкой, поэтому заказчик для нас — внешний стейкхолдер, но все эти пунты абсолютно справедливы и для заказчиков внутри вашей компании. 

А теперь — к самим ошибкам. Вот что часто упускают начинающие менеджеры. 

#1. Не фиксируют итоги встреч 

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

В отличие от других специалистов, менеджер часто переключает контекст, и может упускать важные нюансы не фиксируя итоги встреч. Фиксация этих итогов позволяет: 

1. Еще раз обдумать итоги встречи
2. Сделать дополнительные выводы и обратить внимание на моменты, которые не успели обсудить
3. Зафиксировать следующие шаги
4. Убедиться, что все друг друга поняли

1. Не забыть о договоренностях

Чеклист: что должно быть в итогах встречи 

1. Теги, чтобы фоллоу-ап можно было быстро найти
2. Ключевые итоги: что обсудили, какие решения приняли
3. Следующие шаги: задача, срок, ответственный
4. Дата следующей встречи: работа идет эффективнее, если сразу обозначать срок проверки результатов

Дополнительные советы 

⏳ Чтобы оставалось время на фиксацию и обдумывание итогов встречи, важно следить за своим графиком и не ставить большие встречи одну за другой.

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

📝 Идеальный вариант – делать фоллоу-ап по всем встречам, не только с заказчиком: фиксирование итогов даже внутренних планёрок команды по проекту помогает структурировать коммуникации. 

#2. Не пользуются календарём 

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

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

Вот базовые принципы использования календаря: 

1. Прикрепляй ссылку на встречу к приглашению
2. Повторяющиеся встречи заводи в календарь как периодические
3. Включи уведомления от календаря

#3. Не транслируют команде долгосрочные цели проекта 

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

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

О чём команда должна знать: 

1. Релизы: дедлайны и что должно войти в релиз
2. График промежуточных демонстраций, и в каком виде они будут проходить
3. Состав MVP и приоритеты фичей, входящих в MVP
4. Пользовательский путь в продукте

Что это даёт: 

1. Команда принимает участие в приоритизации задачи и учитывает приоритеты в работе над каждой задачей. Например, разработчики отодвигают неприоритетные доработки или упрощают реализацию какой-либо фичи
2. Исполнители сами принимают взвешенные решения, когда это требуется, не дергая лишний раз менеджера
3. Команда не задаёт вопросы, которые идут вразрез с долгосрочными планами. Например, разработчик не попросит отпуск перед релизом
4. Уровень мотивации команды повышается, так как всем ясна полная картина проекта и его промежуточных этапов

#4. Не показывают промежуточные результаты заказчику 

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

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

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

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

#5. Озвучивают сроки, исходя из оценок только по разработке 

Любой проект включает много этапов: аналитику, дизайн, разработку, тестирование, период отладки. Часто начинающие менеджеры при согласовании сроков запуска проекта не учитывают именно последний. 

Практика KTS показывает, что отладка (исправление ошибок после проверок тестировщика и приёмка работ заказчиком) занимает в среднем 20% времени от разработки функционала. Но есть нюансы, которые могут отсрочить дату релиза ещё больше: 

1. У заказчика есть несколько уровней тестирования продукта перед запуском, на каждом из которых могут возникнуть проблемы
2. Необходимость дополнительного ревью со стороны заказчика — например, от топ-менеджмента. По его результатам могут потребоваться правки перед запуском продукта
3. Необходимость подключения сторонних сервисов на стороне заказчика для дополнительного мониторинга

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

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

#6. Не умеют (или не знают когда) говорить «нет» 

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

Как и любому человеку, ни одному заказчику не понравится ответ «нет, мы не успеем это сделать» или «нет, это невозможно». Поэтому если менеджер понимает, что реальные сроки решения задачи больше, чем хотелось бы заказчику, он должен обозначить возможные альтернативы. 

Например, можно обсудить частичный запуск проекта с базовым необходимым функционалом (MVP) и упрощение реализации некоторых фич, что позволит сократить сроки разработки. Само собой, чтобы сделать взвешенное предложение заказчику, его необходимо сначала обсудить с разработчиками — они подскажут, какие именно элементы проекта можно упростить на этом этапе. 

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