Проект никогда не идет по плану. Вы можете продумать все до мелочей, но придет заказчик, скажет «давайте менять концепцию» — и все полетит коту под хвост.
Что же делать, чтобы зарелизить проект вовремя, в рамках бюджета и остаться психически здоровым человеком — рассказывает Марина Мельник, ex-Program Director в Luxoft.
У Марины более 13 лет опыта в управлении проектами и программами. Она много консультирует в сфере проектного управления, в том числе ПриватБанк, VARUS, АНЦ. А совсем скоро в Laba стартует курс Марины «Проджект-менеджмент».
Вместе мы подготовили гайд, который поможет сдать проект, не срывая дедлайн.
#1. Сформулируйте четкий product vision
Для этого на старте определите, чего вы хотите, с какой целью, почему именно в такие сроки и сколько готовы потратить на проект.
Я согласна с бизнес-спикером Саймоном Синеком, который говорит: «Start with why». Начните с определения, для чего нужен проект, — а потом приступайте к воплощению. Сформулируйте, какую ценность он принесет пользователю, бизнесу и заказчику. Это то, что дает мотивацию команде.
Постоянно синхронизируйте видение проекта по ходу его реализации: что мы продолжаем делать и какие задачи для нас до сих пор актуальны. Условно, можно договориться на берегу, что мы направляемся к конкретному острову, но потом погода изменится и мы поймем, что лучше плыть к другому или вообще встать на якорь.
Это важный момент — постоянно чувствовать видение проекта: что мы делаем и для чего.
Например, заказчик хочет систему управления клиентской базой. На вопрос «Для чего?», он отвечает: «Планируем расширять бизнес и ожидаем получить больше клиентов». Когда речь заходит о том, что даст новая система и какую ценность она принесет, клиент говорит: «Мы понимаем, что все на рынке так делают» или «Мы узнали, что наш конкурент так ведет бизнес». Это явный сигнал, что что-то не так.
Сравнивать себя с соперниками и аналогичными организациями — неправильная мотивация. Правильная — в том, что компании некомфортно. К примеру, она тратит много времени на работу с текущей базой или на сведение клиентов в Excel, поэтому критично важно автоматизировать процессы, чтобы эффективно выстроить работу. То есть новая система нужна для повышения продуктивности.
#2. Определитесь с конкретной датой
Тут можно выделить два типа проектов:
- Scope-driving — проект, который сильно зависит от функционала. Если его нет, выпускать проект нет смысла. Тут есть объем работы, который обязательно должен быть выполнен перед релизом.
- Date-driving — проект с критической датой выхода и, возможно, урезанным скоупом. Вероятно, мы сделаем не все задачи к конкретному сроку, но какую-то часть работы точно выполним, и это позволит нам выстрелить на рынке.
Условно, если у нас проект, в котором дети пишут письмо Деду Морозу, он не имеет смысла после 31 декабря. Здесь критична дата — и мы ориентируемся на нее. Может быть, мы это письмо будем отсылать не со всеми прекрасными фишками, которые изначально запланировали, но точно отправим до дедлайна. А если наш проект касается лазера для коррекции зрения, то без идеально работающего функционала никаких сроков нет.
Поэтому нужно определиться, что важнее: дата или функционал. Я часто сталкиваюсь с клиентами, которые изначально настаивают, что самое главное — дата. А когда мы максимально подгоняем задачи под дедлайн, заказчик говорит, что пока не будем релизиться — хотели бы еще добавить новый функционал.
Когда клиенту важна дата и она действительно «горит», он говорит: «Сделайте продукт хотя бы с элементарным функционалом». И может сформулировать видение минимально жизнеспособного продукта.
Грамотная работа аналитика и проджект-менеджера здесь — задать клиенту правильные вопросы. Если мы поймем друг друга изначально, тогда будет успех.
#3. Контролируйте качество на старте
Если мы будем говорить «ничего, пока так сделаем, а потом починим», в дальнейшем можем столкнуться с эффектом «треснутого стекла». Позволим одну поблажку по качеству — и как снежный ком начнем их допускать дальше. А потом это ударит нас техническим долгом и не позволит зарелизить проект в срок. Мы не имеем права выйти на рынок с плохим продуктом — это как стрелять себе в ногу. Так можно растерять клиентов и обрасти проблемами.
Иногда заказчик начинает «давить», чтобы выпустить не полностью готовый продукт. И тут важно уметь управлять им: если вы не будете этого делать, клиент по незнанию и неопытности начнет сам себе вредить. Поэтому отслеживать качество на старте крайне важно — нужно выстроить контроль и постоянно его вести.
#4. Научитесь управлять изменениями
Клиентское «увидел что-то новое, давайте менять концепцию» точно отразится на датах. Чтобы сделать все вовремя, нужно изначально проговорить: если возьмем изменение в работу, каким бы правильным оно ни было, это повлияет на сроки.
Можно сказать, что мы принимаем корректировки в скоуп, но поскольку у нас есть дедлайн, сначала выпускаем проект без нового функционала в нужную дату, а дальше уже доработаем его. Если же нововведение кардинально перестроит проект и мы не можем его отложить, говорим, что другие задачи сдвинем на более поздние сроки.
Когда мы идем на поводу у клиента и берем все коррективы в работу — 100% не попадем в дедлайн. Поэтому каждое изменение от заказчика оцените с двух позиций:
- можно ли им заняться уже после выпуска первой версии продукта
- если важно реализовать его сейчас — 1) какой объем работы нужно на него потратить; 2) какие аналогичные таски с таким же объемом работы мы можем убрать из текущего списка задач.
Кроме того, можно сказать клиенту, что мы впишемся с нововведениями в дату, но тогда пострадает бюджет. Треугольник проектного менеджмента никто не отменял: у нас есть объем работы, бюджет и время. Когда мы начинаем одну из этих сторон тянуть — растягиваются и другие.
Все эти моменты нужно проговаривать, а решение уже будет за клиентом. Например, если заказчик готов продлить дедлайн и увеличить бюджет, тогда берем в работу все изменения. Если нет, что бывает чаще всего, — делаем, как изначально договорились, а потом смотрим, что добавлять в продукт.
#5. Не забывайте об управлении рисками
Это постоянный контроль себя как проектного менеджера: садимся и думаем, что может пойти не так. Опытный проджект всегда держит в голове источники риска. Он должен понимать, откуда способна прийти проблема, чтобы она не стала для него неожиданностью.
Так мы можем составить риск-матрицу: неприятность может произойти по такой-то причине → если это случится, нам придется потратить Х времени на устранение проблемы → что я могу сделать сейчас, чтобы подобная неприятность не произошла.
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
Поэтому проджект-менеджеру нужно продумать несколько стратегий:
- превентивную — как не допустить проблемы
- стратегию смягчения риска — как сделать так, чтобы он оказал минимальное влияние на проект
- план Б — если риск реализуется, как я буду действовать
Бонус: как расставлять задачи по приоритетам
Есть классическая матрица приоритетов Эйзенхауэра, которую я применяю как в работе, так и в личной жизни. Она делит все задачи на 4 группы:
- важное и срочное
- важное, но не срочное
- не важное, но срочное
- не важное и не срочное
Срочные и важные задачи — те, которые нужно выполнить немедленно. Если у вас таких больше 20%, это уже проблема — значит, когда-то вы не сделали их вовремя.
Не срочные, но важные задачи — те, которые рано или поздно все равно нужно будет выполнить. Иначе они переместятся в первый квадрат — тогда придется заниматься ими в режиме аврала и с испорченным настроением. Это может быть подготовка к новым проектам, выстраивание отношений, изучение иностранных языков.
Срочные, но не важные задачи — те, которые (по чьему-то мнению) вы должны выполнить немедленно, однако они не приносят пользы лично вам. Соглашаться на них — значит саботировать свои интересы, но быть хорошим для всех.
Не срочные и не важные задачи — те, которые не приносят значимого результата, но могут быть интересными. Например, смотреть сериалы или играть в игры.
Каждую новую задачу я сразу же вношу в календарь. И когда приходит время выполнять, еще раз анализирую: если я прямо сейчас ее не сделаю, что-то грандиозное случится и кто-то пострадает? Могу ли я заняться чем-то другим? Если могу, вношу новый таск в календарь, а отложенный — отодвигаю.
Внутренняя приоритизация задач нарабатывается путем проб и ошибок. И важно, чтобы рабочие таски не выходили за пределы рабочего времени. Work-life balance никто не отменял: если проджект-менеджер энергетически не наполнен, успеха у проекта не будет.
Хотите получать дайджест статей?
