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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что это даёт:

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

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

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

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

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

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

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

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

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

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

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

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

Кстати, мы активно нанимаем аналитиков-джунов, которые под руководством старших менеджеров будут расти в проджект-менеджеров.

С вас — желание не делать перечисленные ошибки, с нас — помогать вам в этом.

Отправить резюме можно по ссылке: https://ktshiring.huntflow.io/vacancy/sistemnyi-analitik-junior

Читайте также: как менеджеру понять, что на проекте нужен аналитик