Привет, я Вика Строгонова, руководитель проектного офиса в KTS. Я веду проекты с 2017 года и прошла путь от младшего менеджера до руководителя проектного офиса. Сейчас в моем портфеле более 20 проектов и 42 человека, среди них разработчики, аналитики и менеджеры.
Текст написан на собственном опыте, поэтому уверена, что есть и другие ошибки, которые я не учла в статье. Буду рада, если поделитесь ошибками джунов, с которыми вы чаще всего сталкиваетесь, в комментариях.
Все типовые проблемы, о которых пойдет речь ниже, касаются менеджеров-джунов или вчерашних стажеров. Это не тайные знания, которые открываются только тем, кто несколько лет отработал на проектах или прошел специальные курсы: это достаточно базовые вещи, которые начинающие менеджеры почему-то упускают.
У этих проблем есть две причины:
- Отсутствие грамотного менторства у менеджеров-джунов.
- Отсутствие опыта и спорных ситуаций на прошлых проектах.
В основном мы в KTS занимаемся заказной разработкой, поэтому заказчик для нас — внешний стейкхолдер, но все эти пунты абсолютно справедливы и для заказчиков внутри вашей компании.
А теперь — к самим ошибкам. Вот что часто упускают начинающие менеджеры.
#1. Не фиксируют итоги встреч
Фоллоу-апы — одна из основ проектного менеджмента и мое личное требование ко всем ребятам, которые приходят к нам работать. Когда работа по проекту стартует, характер и стиль работы заказчика — всё ещё загадка для менеджера. Иногда в такие моменты менеджеру может показаться, что он на одной волне с заказчиком, поэтому необходимость фоллоу-апа по встречам не очевидна до возникновения первых противоречий.
В отличие от других специалистов, менеджер часто переключает контекст, и может упускать важные нюансы не фиксируя итоги встреч. Фиксация этих итогов позволяет:
- Еще раз обдумать итоги встречи
- Сделать дополнительные выводы и обратить внимание на моменты, которые не успели обсудить
- Зафиксировать следующие шаги
- Убедиться, что все друг друга поняли
- Не забыть о договоренностях
Чеклист: что должно быть в итогах встречи
- Теги, чтобы фоллоу-ап можно было быстро найти
- Ключевые итоги: что обсудили, какие решения приняли
- Следующие шаги: задача, срок, ответственный
- Дата следующей встречи: работа идет эффективнее, если сразу обозначать срок проверки результатов
Дополнительные советы
⏳ Чтобы оставалось время на фиксацию и обдумывание итогов встречи, важно следить за своим графиком и не ставить большие встречи одну за другой.
📩 Итоги важных встреч стоит дублировать в почту, даже если это не основной канал коммуникации.
📝 Идеальный вариант – делать фоллоу-ап по всем встречам, не только с заказчиком: фиксирование итогов даже внутренних планёрок команды по проекту помогает структурировать коммуникации.
#2. Не пользуются календарём
Начинающий менеджер не погружён в большое количество проектов и процессов, и поэтому встреч может быть немного. Из-за этого многие не спешат пользоваться календарем. Но очень сложно поймать момент, когда встреч станет слишком много, и они начнут накладываться друг на друга.
Поэтому каждый менеджер с первого дня работы должен привыкать пользоваться календарем и заводить в него даже одну-две встречи в неделю. Это удобно и для заказчика, и для членов команды, и для самого менеджера.
Вот базовые принципы использования календаря:
- Прикрепляй ссылку на встречу к приглашению
- Повторяющиеся встречи заводи в календарь как периодические
- Включи уведомления от календаря
#3. Не транслируют команде долгосрочные цели проекта
Коммуникация заказчика с командой обычно ведётся через менеджера, поэтому он является главным носителем знания по проекту. Он знает, какую бизнес-ценность несёт продукт, и как он будет запускаться. Начинающим менеджерам интуитивно кажется, что команда — это исполнители, которым достаточно заводить детальные описанные задачи для того, чтобы реализовать ту или иную фичу.
В реальности это не так. Работа идет более эффективно, когда команда знает, какую проблему решает каждая из фичей продукта и какие есть ограничения. Эту информацию нужно постоянно транслировать команде: на ежедневных встречах, в рамках принятия каких-то решений.
О чём команда должна знать:
- Релизы: дедлайны и что должно войти в релиз
- График промежуточных демонстраций, и в каком виде они будут проходить
- Состав MVP и приоритеты фичей, входящих в MVP
- Пользовательский путь в продукте
Что это даёт:
- Команда принимает участие в приоритизации задачи и учитывает приоритеты в работе над каждой задачей. Например, разработчики отодвигают неприоритетные доработки или упрощают реализацию какой-либо фичи
- Исполнители сами принимают взвешенные решения, когда это требуется, не дергая лишний раз менеджера
- Команда не задаёт вопросы, которые идут вразрез с долгосрочными планами. Например, разработчик не попросит отпуск перед релизом
- Уровень мотивации команды повышается, так как всем ясна полная картина проекта и его промежуточных этапов
#4. Не показывают промежуточные результаты заказчику
Чтобы большую работу не пришлось переделывать из-за неоправданных ожиданий, почаще показывайте заказчику то, что получается в проекте. Если клиент каждую неделю видит промежуточные результаты, на каждом этапе работы при желании можно что-то поправить.
Поэтому для лучшей эффективности сразу согласуйте график регулярных промежуточных показов с заказчиком. Важно, чтобы всё время разработки заказчик понимал, что продукт работает так, как нужно.
Это полезно и для команды: её члены видят результаты своей работы и получают фидбек напрямую от заказчика. Такой подход держит команду в тонусе и стимулирует показывать результат, пригодный для демонстрации.
При формировании графика демонстраций лучше опираться на результат, понятный заказчику: сделанный макет, работающий экран, и тд. Если вы показываете результаты раз в две недели, но что-то реально работающее можно создать только за три – лучше уменьшить частоту до трех недель. Показывать заказчику задачи в таск-трекере и написанный код недоделанных фичей не стоит.
#5. Озвучивают сроки, исходя из оценок только по разработке
Любой проект включает много этапов: аналитику, дизайн, разработку, тестирование, период отладки. Часто начинающие менеджеры при согласовании сроков запуска проекта не учитывают именно последний.
Практика KTS показывает, что отладка (исправление ошибок после проверок тестировщика и приёмка работ заказчиком) занимает в среднем 20% времени от разработки функционала. Но есть нюансы, которые могут отсрочить дату релиза ещё больше:
- У заказчика есть несколько уровней тестирования продукта перед запуском, на каждом из которых могут возникнуть проблемы
- Необходимость дополнительного ревью со стороны заказчика — например, от топ-менеджмента. По его результатам могут потребоваться правки перед запуском продукта
- Необходимость подключения сторонних сервисов на стороне заказчика для дополнительного мониторинга
Менеджер должен понимать не только путь продукта перед запуском, но и что именно заказчик считает готовым к запуску продуктом. Это может быть демо-версия какого-то функционала, который будет работать на устройстве заказчика или полноценный релиз для пользователей. Начинающему менеджеру лучше заранее проговорить это с заказчиком.
Чтобы качественно заложить время на подготовку к запуску, нужно узнать у более опытных сотрудников, что может затянуть или отложить релиз.
#6. Не умеют (или не знают когда) говорить «нет»
Умение вежливо отказывать — необходимый софт-скилл, которого нет у многих джунов. Но настоящая магия заключается не просто в отказе, а в поиске компромисса, который решит задачу заказчика.
Как и любому человеку, ни одному заказчику не понравится ответ «нет, мы не успеем это сделать» или «нет, это невозможно». Поэтому если менеджер понимает, что реальные сроки решения задачи больше, чем хотелось бы заказчику, он должен обозначить возможные альтернативы.
Например, можно обсудить частичный запуск проекта с базовым необходимым функционалом (MVP) и упрощение реализации некоторых фич, что позволит сократить сроки разработки. Само собой, чтобы сделать взвешенное предложение заказчику, его необходимо сначала обсудить с разработчиками — они подскажут, какие именно элементы проекта можно упростить на этом этапе.
Если менеджер оказывается в неудобном положении, когда нужно дать ответ по дедлайну, но он не уверен, уложится ли в срок команда, самым правильным будет собрать пожелания заказчика: какую проблему надо решить, почему сроки именно такие. Дальше нужно взять короткую паузу, передать информацию команде и вместе с командой понять, что получится успеть в заданные сроки.
Кстати, мы активно нанимаем аналитиков-джунов, которые под руководством старших менеджеров будут расти в проджект-менеджеров.
С вас — желание не делать перечисленные ошибки, с нас — помогать вам в этом.
Отправить резюме можно по ссылке: https://ktshiring.huntflow.io/vacancy/sistemnyi-analitik-junior
Читайте также: как менеджеру понять, что на проекте нужен аналитик
Вот после таких статей мне кажется, что не зря депутаты придумали закон о запрете иностранных слов, ой не зря.
Согласен. Вы тоже компьютеры называете электронно-вычислительными машинами, а интернет внутренней сетью?
А правильно будет «сообщения по итогам встречи», да?
Научиться говорить "Нет" - это будет полезно, и джунам и всем остальным людям, которые хотят научиться ценить свое время и силы.
Комментарий недоступен
Но, увы, сказать нет могут не все, а именно этим многие и пользуются
Тут просто это умение напрямую влияет на результаты проектов, поэтому выделила отдельным пунктом. А так да, хороший навык для любого человека!
Интересная статья, многим миддлам тоже неплохо бы освежить это в памяти) еще у джунов я замечал часто такую ошибку — они не умеют фокусироваться на важном и делать приоритизацию, пытаясь всем подряд заниматься. Либо фокусы недели (промежуточные вехи) расставляются только на 1-2 недели. Иногда это приводит к тому, что к дедлайну оказывается, что работы еще много предстоит сделать. Но это уже больше про декомпозицию и коммуникацию со стейкхолдерами.
приоритизировать; назначение приоритетов, присвоение приоритетов кому-либо, чему-либо ◆ Мероприятия и проекты описаны в хронологическом порядке с учетом их взаимосвязей, ключевых вех и приоритизации.
Т.е расставлять приоритеты.
Веха (milestone, майлстоун) проекта — контрольная точка, значимый, ключевой момент (например, переход на новую стадию, новый этап в ходе выполнения проекта). Как правило, с этим моментом связано завершение какого-либо ключевого мероприятия, подписание важных документов или любые другие значительные действия, предусмотренные планом проекта. Сдвиг вехи приводит к сдвигу всего проекта.
В дополнение к сигнализации о завершении некого ключевого этапа, веха употребляется в значении принятие важного, ключевого решения, способного изменить весь ход проекта. В этом смысле вехи отмечают не только контрольные точки процесса, но и указывают направление движения.
Частично отразила это в пункте 3 про долгосрочные цели проекта, но да, хорошее дополнение!
грустно, когда менеджеры со всеми этими ошибками НЕ остаются джунами и магическим образом растут. такой бардак в процессах начинается
Комментарий недоступен
для лучшей эффективности сразу согласуйте график регулярных промежуточных показов с заказчиком- вот это действительно верное решение и результат тем самым будет ожидаемым ,без каких- либо сюрпризов и в срок
"Отсутствие грамотного менторства у менеджеров-джунов.
Отсутствие опыта и спорных ситуаций на прошлых проектах"- то есть по сути одна...потому что опыт можно получить,если человеку подскажут как решить спорную ситуацию правильно
Разделила это на 2 пункта, потому что научиться можно либо на своих ошибках, либо на основе советов наставника)
не знаю, то ли пятница сказалась, то ли реально текст скучноват.
что бы не гуглить лишний раз:
KTS разрабатывает цифровые сервисы для бизнеса.
И еще нюанс, вот каждый день практически пользуюсь, приложенькой и так скажем вспоминаю всех, кто это разработал)
невозможно открыть карту, в приложеньки, без интернета. Это просто бред какой то. Кто это разработал, явно не знаком с продуктом
Вы работаете в Пятёрочке?
Мы просто ЛК для сотрудников Пятёрочки делали, а не для покупателей
А Растишка то тут при чем?😂
Ну так это, Растишка — расти на здоровье!
А менеджеры могут так и не вырасти, и даже Растишка не поможет)
Чёт прям покоробило от "в подчинении 42 человека", типа как на заводе получается))
Долго думала над формулировкой, но не смогла придумать что-то более вменяемое))
Есть идеи?
Мне было полезно прочитать, спасибо, что поделились. Еще интересно, про менторство- в каком формате вы его ведете, как долго сопровождает новичков, как оцениваете результаты?
Зависит от уровня менеджера. Если это стажер, то придется взаимодействовать часто, так как идет активный процесс обучения. Можно делать дейлики по утрам и проговаривать задачи на день. Таким образом получится контролировать исполнение задач, давать фидбек по работе. Если уже есть опыт, достаточно 1to1 встреч раз в месяц, где можно разбирать проблемы, ставить долгосрочные цели и планировать шаги для их достижения.
Бей джуна, чтобы сеньоры боялись!