Думаю, примерно 90% читающих эту статью уже в курсе, что бюджеты нужно согласовывать, договоренности – документировать, а ретроспективами – не пренебрегать. Поэтому в статье вы не найдете идеальной модели «Делай вот так и завтра станешь менеджером мира».
В первый месяц стажировки ментор мне говорил: «В жизни каждого уважающего себя менеджера должен быть один легендарный факап». А что скажете насчёт пяти?
Меня зовут Алина Дикарева и я — менеджер проектов в Surf. Расскажу о кейсах, с которыми я столкнулась, будучи невероятно амбициозным и не менее невероятно зелёным менеджером. И да, я пишу о СВОИХ ошибках.
Зачем читать про чужие ошибки
Те 10 минут, которые вы потратите на прочтение статьи, могут оказаться полезными, — и вот почему.
Развитие вариативности решений
Пути решений, которые есть в голове, ограничены личным опытом. Я уверена, что даже для менеджера, собравшего все грабли мира, свежая идея скромного джуна может оказаться приятным сюрпризом.
Практика решения кейсов
Все мы когда-то были стажерами и, на радость менторам, игрались с кейсами перед выходом на реальные проекты. Для тех, у кого это в прошлом, такая статья — возможность предаться ностальгии. Тем, кому только предстоит, — welcome на первую практику.
Ошибки — это весело
Давайте будем честными: всем интересны факапы. Особенно когда они не твои.
Время начинать!
Кейс №1. Планирование спринта
Ситуация. Заказчик подготовил бэклог и акцентировал внимание, что самое важное — уложиться в установленный срок. Попросил дать верхнеуровневую оценку и скомандовал отдавать задачи в разработку.
Действие PM. Всё, как советовали старшие коллеги:
декомпозировать задачу с оценками от тимлидов,
составить календарный план,
накинуть время на риски и отладку,
запланировать время на тестирование,
утвердить точки согласований.
Спринт спланирован! Всё успеваем: срок согласован с заказчиком, стартуем работы. Вот только проблема: спринт спланирован В ОДНОГО, и итоговую картину видел только PM.
Вроде бы всё логично: планирование – менеджерская вотчина. Но…
Последствия. В середине спринта выяснилось, что разработчик не может корпеть над задачей 8 часов в день: собрание отдела, дейлики, внутренние коммуникации, грейдирования, перерывы в течение дня. А тестировщиков вообще «обделили временем и на прогон по этим фичам нужно было закладывать больше». Как итог: в оценки разрабов мы попали замечательно, а вот в сроки — нет.
Урок. Драфт календарного плана PM оформляет самостоятельно, но перед нажатием на кнопку «Запустить спринт» этот КП должен увидеть и «окнуть» КАЖДЫЙ член команды. Это не снимает с менеджера ответственность за сроки, но повышает вовлечённость других ролей: на раннем этапе получается наиболее реалистичная картина.
Между строчек. У начинающего менеджера представление о проекте и отдельных итерациях может быть слишком оптимистичным: не хватает опыта и пока недостаточно прокачанного критического мышления. Тем важнее вовлекать команду, которая уже работала на реальных проектах и знает, что ювелирное попадание бывает там, где нигде.
Кейс №2. Сформированный бэклог — это важно
Ситуация. Мы с командой выкатили крупный релиз. Все выдохнули — включая PM, которому наоборот стоило бы напрячься. В запасе оставалась парочка минорных багов и несколько доработок, которые заказчик попросил включить в хотфикс. До вопроса «Чем заняться дальше?» — максимум полторы недели. При этом заказчик не просил урезать состав команды на развитие и уверял, что предстоит разгребать новый огромный бэклог, который он скоро подгонит. Время тикало, а бэклога все не было.
Действие PM. По классике тушить мелкие пожары интуитивно кажется правильным. Можно было дать команде пару дней заняться тем же рефакторингом или привести в порядок проектную документацию, а за это время — сформировать квартальный бэклог с заказчиком. Но я не могла допустить простоя и ежедневно вытаскивала по парочке задач для команды, «лишь бы не встать».
Последствия. Каждый менеджерский день начинался с поиска запылившихся фич, а календарный план протягивался максимум на неделю вперед. Команда не понимала, чем конкретно мы занимаемся в текущем спринте, когда он закончится и какой результат ожидаем получить «на выходе». Да и что уж там, сам PM не понимал тоже. Думаю, не нужно объяснять, что в такой ситуации происходит с общей мотивацией и, как следствие, с качеством работ.
Урок. Одна из ключевых задач PM на этапе развития — получение и поддержание бэклога в актуальном состоянии. Если бэклог — только в голове у заказчика, вам нужна голова заказчика. Если заказчик не может перенести мысли на бумагу, нужно сделать это за него. Правило 20/80 — во всей красе: если потратить несколько дней на планирование и раскидать спринты на квартал, не нужно будет начинать утро с ежедневных реактивных поисков, а чего бы ещё поделать полезного. В качестве бонуса — сохранение парочки нервных клеток:)
Между строчек. Классная практика на этапе развития — формировать внутренний бэклог и согласовывать его с заказчиком. Если команда готова уделять время совместному брейншторму, можно внедрить практику еженедельных продуктовых дейли. Для заказчика это — возможность расширить бэклог, дополнить его свежими идеями. Для команды — суперполезный опыт в продуктовой разработке.
Кейс №3. Вброс доработок в спринт
Ситуация. В проекте готовился большой релиз с редизайном. Три месяца команда трудилась над обновлением, овертаймила и постоянно росла в количестве. В общем, релиз был долгожданным, а дедлайн — жёстко ограниченным со стороны заказчика. Что же мы получили в момент приемки, когда подоспел срок и всё было готово? Правильно, порцию доработок! А потом ещё порцию. И ещё…
Действие PM. Первые доработки принимали без особого скрипа: очень хотелось закончить и поставить жирную точку на релизе. Но ситуация начала повторяться и перестала удовлетворять всем ранее фиксированным договоренностям. Каждый созвон с заказчиком превращался в один большой спор ни о чём: я указывала на первичные договоренности и настаивала на переносе всех доработок в следующий спринт, заказчик говорил, что в таком виде в релиз мы не выйдем.
Последствия. Доработки всё-таки реализовали: мы — аутсорс и выпускать обновление в релиз без «ок» от заказчика не можем. Но отношения были подпорчены плюс команда сильно устала от ощущения незавершенности.
Какие трудности бывают, если релиз никак не выходит, мы писали в статье «Как вести проект без релизов»
Урок. Я считаю всю эту историю ошибкой PM: этап сдачи и приемки работ — важная составляющая итерации. До этого момента мы полгода работали через одно ЛПР — лицо, принимающее решение: он был «узким горлышком» и всегда проводил приемки самостоятельно. Мне следовало заранее узнать, сохранится ли эта модель взаимодействия для такого крупного релиза, как редизайн.
После релиза мы разобрали ситуацию с главным ЛПР: выяснилось, что в команде на его стороне есть несколько подразделений, каждое из которых производило приёмку и возвращало доработки, блокируя нам релиз. Количество возможных доработок растёт с количеством людей, вовлеченных в процесс приемки: учитывать это нужно ещё на этапе планирования спринта.
Между строчек. Вбросы доработок — штука неприятная, но почти неизбежная. «Чётко фиксировать скоуп» — моя любимая короткая грустная сказка. Но работать с этим можно и нужно. Важно понимать, что доработки обычно приходят не потому, что заказчик не хочет следовать договоренностям, а потому, что доработки, как правило, могут принести хорошие показатели бизнесу. Реализовать их — на самом деле в общих интересах.
Кейс №4. Прозрачность на всех этапах проекта
Ситуация. У нас есть нулевой спринт: до старта разработки проводим глубинные интервью с респондентами, готовим концепцию дизайна, составляем таблицу функциональности и упаковываем выводы. Мы красиво инициировали этап: рассказали, чем будем заниматься, продемонстрировали примеры артефактов, план работ и… ушли в туман отправились тихонько работать:)
Действие PM. Я, как сознательный менеджер, проводила статус-встречи, на которых расписывала, что делаем, какие проблемы есть на данном этапе, в каком направлении движемся. Печатала «минутки» — они же «фоллоуап встречи» — докладывала, что «работа работается».
Но никаких общих встреч, промежуточных демонстраций, коммуникаций в чате — ничего подобного не было. Мы с командой просто делали своё дело, общались исключительно «внутри», расходовали бюджеты и по ряду причин сдвигали сроки.
Последствия. В глазах заказчика это выглядело примерно так: нам что-то пообещали, ушли что-то делать, что-то происходит, сроки почему-то едут. Что сделали — не до конца понятно, менеджер на еженедельных встречах рассказывает о каких-то изменениях.
Естественно, сдвиги по срокам заказчик начал воспринимать достаточно остро. И хотя работы сдвигались не по нашей вине, мы начали производить впечатление не самых ответственных и надёжных ребят. Уровень доверия стремительно снижался.
Урок. Промежуточный этап — такой же важный, как и завершающий. Менеджерские встречи и минутки в чат — это, конечно, хорошо. Но это — слова, а заказчику нужны весомые доказательства, что дело движется: демо, статус-апдейты от команды, доступы к артефактам проекта, возможность принимать участие в работах. Это не только про прозрачность и правильно выстроенные процессы, но и про грамотное партнерство. Не «Мы сделаем вам классный продукт!», а «Мы с вами сделаем классный продукт!».
Между строчек. Промежуточные результаты — это «подушка безопасности» для менеджера. Еженедельные презентации итогов — возможность вовремя найти ошибку и гибко сменить курс. В противном случае велика вероятность правок на этапе завершения. И здорово, если вы заложили бюджет на эти правки. А если нет?:)
В общем, всегда лучше получить фидбек в середине спринта и при необходимости что-то доработать, чем в конце отпираться и доказывать, что «мы знаем лучше и всегда так делаем» — лишь бы не пришлось работать бесплатно и снижать KPI.
Кейс №5. Регулярные встречи с командой 1:1
Ситуация. Проект на стадии «вот-вот зарелизимся», я сфокусирована на интересах заказчика: всеми силами старалась закрывать любые потребности со стороны ЛПР. Запросов было много: это исправьте, это возьмите, тут немножко доработок, тут нужно быстрее.
Действие PM. Заказчик был достаточно напористый. Чем ближе релиз, тем сильнее увеличивалась степень давления, а у меня было катастрофически мало опыта.
«Ван-ту-ван» встречи с участниками команды я не проводила: считала это дополнительной и необязательной нагрузкой. Как следствие, я достаточно поздно осознала, что поддерживать интересы заказчика в тот момент означало полностью игнорировать интересы команды.
Последствия. Постфактум я получила фидбек, который показал, как вся эта история выглядела со стороны команды и как мои действия способствовали выгоранию каждого из её участников. Команда начала затухать, у ребят сформировалось впечатление, что их слово и позиция ничего не значат в рамках проекта.
Проект — это всегда общая работа, а не собственность менеджера и заказчика. PM — опорное звено общей конструкции. Нашей же конструкции в тот момент опираться было не на что.
Урок. Регулярно проводить «ван-ту-ваны». Только в таком формате видится возможным получать всю информацию от каждого сотрудника, работающего в проекте. Намного лучше понимать, что ещё можно переиграть, и перестроить проблемные моменты, чем потом думать, что «не предусмотрела, не объяснила, не уделила достаточно внимания».
Все встречи на каждом этапе жизненного цикла проекта предполагают обсуждение рабочих моментов. Обычно это сухие планы, решение проблем, конкретизация задач, формирование выводов итерации. На эмоции времени нет, да и мало кто может поделиться переживаниями перед всей командой. «Ван-ту-ван» — это безопасное пространство, где про это можно и нужно говорить.
Между строчек. «Ван-ту-ван» встречи — это ещё и возможность для PM понять цели и узнать планы развития сотрудника: достаточно часто их можно реализовать в рамках проекта.
Пример. В связке работают лид (опытный сотрудник, на проекте уже около года) и новый разработчик, который пришел на проект пару месяцев назад. Лид разрывается на декомпозицию, планирование спринта с менеджером, ресёрч реализации сложных фич, ревью пулл-реквестов.
При этом лид понимает, что ему еще и покодить хорошо бы, но времени не хватает. На «ван-ту-ван» с новым разработчиком выясняется, что он хотел бы заниматься декомпозицией фич, готов выделять время для обучения этому и прокачивать скилл. На «ван-ту-ван» с лидом выясняется, что он хотел предложить отдать декомпозицию на второго разработчика, но переживал, что для него это новый формат и нагрузка будет слишком большой. Match! Поздравляю нас всех: мы придумали, как разгрузить лида и дать возможность новому разработчику расти в рамках нашего проекта.
Пожалуй, это всё на сегодня. Подводить итоги и раздавать советы не стану. Все кейсы бережно храню в памяти и рассматриваю их только в качестве важных историй для рефлексии и «указателей» в направлении роста.
Напоследок напишу только одну банальную вещь: ошибки — это естественно и очень даже здорово. В конце концов, n-ное количество ошибок стало хорошим поводом для написания этой статьи. Надеюсь, что не я одна так считаю.
А чтобы продолжить тему, предлагаю вам мысленно откатиться в начало профессионального пути, вспомнить самые любимые кейсы с ошибками и рассказать о них в комментариях. Ну и, конечно, если вы уже начали печатать вопрос, — не останавливайтесь, I am open to answer :)
Больше полезного — в наших телеграм-каналах:
В них мы публикуем кейсы, лучшие практики, новости и вакансии Surf, а также проводим прямые эфиры.
Присоединяйтесь!
