В идеальном мире каждый менеджер знает, как довести проект до конца и сделать его успешным. Но в реальности часто что-то идет не по плану, дедлайны оказываются под угрозой срыва. В этой статье Дмитрий Макуха, аккаунт-директор диджитал-агентства AIR Production расскажет, что может сделать менеджер, чтобы не довести проект до провала и почему методологии в чистом виде — архаизм.
Менеджер и менеджмент в IT
В проектном менеджменте в IT обычно выделяют две основные методологии разработки проекта:
- Прогнозируемый, он же waterfall. Это поэтапный линейный алгоритм. Содержание проекта зафиксировано, стоимость и срок не могут меняться. Работа идет по изначально сформулированному плану. Этот метод целесообразно применять, когда проект более-менее предсказуем по срокам, бюджету и желаемому результату.
- Agile (и все его артефакты). Цели компании и стратегия развития могут меняться независимо от первоначального плана, а бюджет и срок зафиксированы.
Каждая из них делится на бесконечные варианты и вариации.
Но проблема в том, что чистой методологии не существует. Поясню на примере: у вас есть круг. По факту, этот круг — многоугольник, просто число сторон у него бесконечное. Длина каждой стороны стремится к нулю и за счет этого многоугольник выглядит как круг. Ощущение, будто у него нет сторон, и он гладкий. Но при ближайшем рассмотрении оказывается, что это не так.
То же самое происходит в менеджменте. У вас может быть утвержден Agile, но на более мелких этапах вы будете работать по waterfall или еще по какой-нибудь методологии.
Любая методология управления проектом в чистом виде — архаизм.
Лет 15-20 назад, когда Agile и другие методологии пришли в Россию, считалось, что нужно строго следовать канонам. Собирались специальные команды, их обучали, и они старались не отступать от методологии. С повальной цифровизацией бизнеса концепции «чистоты в методологии» пришел конец. Это раньше мы могли себе позволить жестко следовать заданной траектории, поиграть в скрам-мастеров и т.д. Славное было время. Но сегодня условия работы и тенденции в разработке меняются слишком быстро. Приходится смешивать подходы.
Это не плохо. Просто надо приспособиться.
Как менеджер прогнозирует и выявляет блокеры в работе
Адекватный менеджер понимает, что сложностей в проекте не избежать. В этом случае помогает проработка рисков. В сумме, риски делятся на 2 типа:
- Прогнозируемые (высокий/низкий сезон, отпуска, праздники и т.д.);
- Непрогнозируемые (эпидемии, стихийные бедствия, войны, резкая смена законодательства в определенной сфере и т.п.).
Смысл управления рисками в том, чтобы спланировать реакцию на возможные проволочки в работе и постоянно анализировать ситуацию. Так легче выявлять новые риски и не зацикливаться на устаревших. Менеджер ищет решение, которое снизит уровень рискованности проекта. Это база.
Работа с риском строится по стандартной модели:
- Выявление риска (неправильно посчитали бюджет, не учли реальный объем дополнительных работ);
- Качественная оценка (мы потеряем входящий поток крупных клиентов);
- Количественная оценка (мы потеряем 20% от прибыли с проекта);
- Планирование реагирования на риски (мы подключим дополнительные ресурсы и устроим срочную встречу с клиентом);
- Мониторинг и контроль рисков (с дополнительной работой решили, но не хватает...).
И так по кругу, пока не завершите проект. Планирование работы с рисками — это черта хорошего менеджера.
Но в IT-сфере, где мы работаем, есть особенность: если менеджер со стороны агентства наступит на грабли, «по лбу» достанется клиенту. Все потому что IT-проект часто разрабатывают на аутсорсе, но продукт выводится под именем клиента.
Например, сайт не выдержал нагрузку в первые часы промоакции. Подрядчик в данном случае отделается штрафом и одним потерянным клиентом. А вот заказчик потеряет из-за этого лояльность и заказы тысячи клиентов. И свою репутацию в их глазах. Впустую будет слит и рекламный бюджет, и часы работы маркетологов. Сравните урон.
Распознавать и устранять проблемы помогает умение задавать правильные вопросы. Люди, которые задают их, как правило, реже сталкиваются с неприятностями на проекте.
Например, один из рисков — это сроки согласования. Это особенно важно, так как клиенты разные и часто IT-проект, который им делают аутсорсе, для них не в приоритете. Или у принимающего проект человека мало времени. Или он, вообще, увольняется через 3 недели. Причин может быть миллион, и вам желательно узнавать о них вовремя. Поэтому стоит проговорить сроки согласования еще до старта работ. Причем очно, а не в почте или мессенджерах. В крайнем случае — по телефону. Вот ситуация:
— Алексей, вот тайминг проекта. Мы предлагаем заложить на согласование не больше недели. По нашим расчетам, проект запустится к середине августа, может, на неделю раньше. Но точно не позже 1 сентября. Если есть какие-то обстоятельства, которые могут тормозить проект, то скажите о них сейчас.
— Ну, я ухожу в отпуск на 2 недели в июле, на связь точно не смогу выходить. Плюс на июнь у нас назначено важное ежегодное мероприятие компании. Перед ним вряд ли смогу уделять достаточно времени проекту.
— Хорошо, тогда давайте на время вашего отсутствия назначим человека, который примет проект с вашей стороны.
— Нет, Денис, так не получится. Все согласования лежат на мне, не могу передать это другому человеку. По регламенту так.
— Хорошо, тогда предлагаем поступить так...
Пара простых предложений, и вы уже сэкономили себе нервы и время. Важно не просто «принять к сведению» эти блокеры. Нужно при этом еще и сразу придумать план действий и озвучить его. Не после встречи, а во время. Иначе выйдет так, что все всё знали, но сроки проекта и весь тайминг все равно летят в тартарары: «Человек же в отпуске — что мы можем сделать?» Можем.
Как разработать базовый план проекта и управления рисками
Есть понятие базового плана, который утверждается у заказчика, и текущего, с которым работает руководитель IT-проекта и его команда. Если меняется содержание проекта, это сильно влияет на отклонение текущего плана от базового. Произойти это может по объективным и субъективным причинам. Среди них:
Объективные
- Изменились цели;
- Изменились ожидания заказчика;
- Поменялись требования к продукту;
- Изменилось количество выделяемых на проект ресурсов;
- Есть неучтенные в плане проекта работы.
Субъективные
- Директор компании не хочет погружаться в детали;
- Менеджер ленится работать над проектом;
- Менеджер ушел в отпуск на несколько месяцев.
Невозможно предсказать, какие изменения и когда произойдут на проекте. Менеджер может лишь своевременно реагировать на эти перемены, корректировать план и предлагать решения для сложившейся ситуации.
Например, мы работали с b2b-компанией, изготавливающей краски и лаки для деревянных изделий. Они продавали их, в основном, в магазины. К нам они пришли с запросом помочь развить b2c-направление. Но в ходе предпроектного анализа мы поняли, что это не рабочая идея (риск). Все потому, что клиенты не станут разбираться в типах краски, грунтовки и т.д. Это не стоит того, чтобы идти в интернет и читать статьи или смотреть обучающие видео, когда всего-то нужно выбрать покрытие для новой двери. Поэтому легче попросить условного консультанта в ИКЕА посоветовать марку и тип краски или же купить товар, который уже окрашен.
В итоге мы не стали выдумывать интернет-магазин и проводить всяческие интеграции. Вместо этого оставили мастер подбора, где человек указывает, что ему нужно покрасить, в каком количестве, какого эффекта он хочет добиться и т.д. Исключается возможность того, что клиент выберет в каталоге неподходящую краску или покрытие.
Лучше составить карту рисков, заложить в нее оценку в часах и в рублях. Перегибать не стоит, но это создаст общую картину рисков для команды. Самоуверенность дорого обходится. Однако не стоит идти с этим планом к клиенту. У него может сложиться ощущение, что подрядчик сам не уверен в своих компетенциях.
Базовый план
По части составления плана не будем писать общие рекомендации, вы их и так знаете и применяете каждый день. Можем привести лишь несколько вопросов, которые помогают лучше понять задачи проекта:
- Как будет измеряться успешность проекта и какие есть ресурсы? Выясните у клиента, что для него успех. «Повысить продажи» — это не измеримый успех. А вот «повысить количество регистраций на сайте на 15%» — вполне определенное требование. К тому же, часто у клиента и разработчика разные понятия об успехе. Как часто происходят разговоры в таком духе на нашем IT-рынке:
— Сергей, мы изучили ваш проект, все проанализировали. Вот что можем предложить для увеличения скачиваний приложения…
— Это не самый большой приоритет для нас сейчас. Нам куда важнее повысить число держателей карт лояльности.
— В брифе в первую очередь указано желаемое количество скачиваний, и ваш коллега Максим указывал на это.
— Это не совсем так, в приложении просто карту держать удобнее. Поэтому и хотим повысить скачивания. Но основная цель — расширить наше сообщество.
— Тогда нам нужно будет время, чтобы провести дополнительный анализ и предложить ещё решения для программы лояльности...
И так далее. Избавьте себя от чехарды целей на проекте, проговаривайте даже очевидные моменты, разночтений все равно не избежать.
Каков реальный объем работ. В этом документе определите, какие есть задачи, укажите продолжительность их выполнения в часах, необходимые ресурсы и ответственного исполнителя.
- Как нагляднее оформить календарный план проекта? Один из хороших инструментов — диаграммы Ганта. Это интерактивная временная шкала, которая дает полное представление о ходе выполнения работ, объеме и зависимостях.
- Исполнители в курсе своих обязанностей и сроков? Удостоверьтесь, что все роли определены. Лично проговорите с каждым исполнителем пул его задач. «Забронируйте» разработчиков, дизайнеров, тестировщиков и т.п.
- Отпуска, праздники и другие нерабочие дни команды предусмотрены? Учитывайте это в плане.
Как превратить регламент в подручный инструмент
Выше мы говорили о том, что заранее стоит заготовить карту рисков. Но этого мало. В идеале у сотрудников должен быть под рукой регламент общения с клиентами и ведения проекта.
Обычно он лежит тяжелым грузом, который все вроде читали, а вроде и нет. Проблема в том, что это общий документ, написанный, как правило, официальным языком и со структурой как в дипломной работе. Представьте ситуацию: звонит разъяренный клиент, который нашел баг в безопасности и теперь хочет деньги обратно. И ваш менеджер обдумывает срочный план действий. В регламент он посмотрит в последнюю очередь.
В документе нет быстрых ответов. Он не приспособлен под ситуации, когда надо на ходу предложить решение в кризисной ситуации. Рабочее решение. А клиент хочет увидеть какие-то действия прямо сейчас. Так и выходит, что регламент лежит в глубинах гугл-дисков и корпоративных почт. При этом само качество регламента может быть высоким, а описанные ходы — рабочими.
Например, в нашем регламенте каждый пункт написан кровью. Светофор ставят, только когда в том или ином месте погибло 2+ человек. Вот и мы вырабатывали его по такому же принципу.
По регламенту нужно работать с самого начала. Если же ввести его только на какой-то стадии, то:
- У клиента возникнет вопрос, почему начали по нему работать и почему именно сейчас;
- Клиент к этому времени уже привык работать хаотично или просто по другой системе, поэтому теперь сложно поменять принципы работы;
- Регламент уже не в силах помочь исправить ошибки.
Регламент защищает как интересы клиентов, так и команды разработки. По нему все договоренности должны быть запротоколированы и поставлены в тикетную систему, должны быть согласованы прототипы, на проекте есть несколько обязательных бесплатных итераций правок. В этом случае, менеджер обезопасит себя от ситуации, когда он мог сдать проект за 3 месяца, а ведет его уже в течение года.
Клиента регламент защищает в том случае, когда менеджеры с его стороны не соблюдают интересы собственной компании, затягивают проект по личным причинам и доходит до того, что проект тяжело завершить.