Как управлять изменениями в проекте с выгодой для всех участников

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

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

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

Как правильно менеджеру проектов работать с изменениями?

Все проекты разные, и от некоторых характеристик зависит то, как организовать управление изменениями.

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

Также проекты можно поделить по стадии реализации. Какой-то проект уже идет полным ходом, вы демонстрируете заказчику первые прототипы и получаете уйму пожеланий к изменению. А какой-то только в перспективе, и вы, уже набив не одну шишку, решаете, что надо работать по-новому.

В такой матрице важно понимать, как разные типы проектов связаны между собой. Давайте рассмотрим каждый в отдельности.

Незапущенный проект для зрелого бизнеса

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

Незапущенный проект для стартапа

Это сложнее, так как нет четкого технического задания (ТЗ), требования со стороны бизнеса постоянно меняются. Часто заказчики считают, что это в норме вещей, когда проект претерпевает изменения на ходу. Для таких проектов норма, что они не сдаются годами, а команда владельцев бизнеса и разработчиков очень тесно интегрируется между собой, чтобы реализовать задумку стартапа.

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

Кроме того, для незапущенных проектов-стартапов, как правило, характерны существенные ограничения по бюджету. Поэтому важно вместе с заказчиком договориться, что стоит в приоритете: сделать минимальную рабочую версию мобильного продукта в рамках бюджета (minimum viable product) или внедрять одну за другой новые фичи по мере генерации идей и не ограничивать себя бюджетом.

Запущенный проект для зрелого бизнеса

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

Объясните заказчику, как вы работаете.

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

Соберите все пожелания в одну кучку.

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

Не реализовывайте изменения вперед основного плана разработки.

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

Рассмотрим простой пример. Предположим, у вас есть 3 итерации по 1 неделе каждая. После реализации первой итерации вы показываете заказчику проект, и он просит вас о незначительных изменениях, которые составляют всего 4 часа. Команда разработчиков тратит на это полдня следующего понедельника. После демонстрации второй и третьей итерации происходит то же самое, и вы вновь идете навстречу заказчику. В итоге мы имеем опоздание в 1.5 дня от общего срока проекта, хотя казалось бы, изменения незначительны, и их было несложно добавить в общий план работ!

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

Обработайте накопленный список пожеланий

Не стремитесь угодить заказчику во всем. Желания клиента — хоть и закон, но их надо фильтровать. Ведь специалисты вы, и заказчик не обязан разбираться в вашей предметной области и понимать, почему квадратные колеса — плохо, а четыре колеса — это хорошо. Надо вовремя уметь останавливать клиента и объяснять, почему "нет", почему та или иная фича не выстрелит. Конечно, для этого хорошо бы знать общие цели проекта: для чего он создается, каких показателей необходимо достичь. К этому можно и нужно апеллировать, объяснить клиенту, что, например, маленькая фотография внизу экрана не приведет к достижению верхнеуровневых целей проекта, таких как увеличение продаж товара.

Не потрудитесь подумать, развить идею. Понять, чего же клиент хотел этим достичь, какую задачу решал? Разработчики думают как разработчики, поэтому привлекайте аналитиков, выходите на диалог с заказчиком, ищите ответы. Никто кроме него не знает, что нужно его проекту. Очень важно на этом этапе просить его думать, как будущего пользователя, чтобы разработать решение для всех, а не только для себя. В примере с маленькой фотографией, возможно, он хотел освободить пространство для описания товара. Тогда это можно сделать миллионами других способов не в ущерб красивым фотографиям товара.

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

Александр Чернышев,
iOS-разработчик:

"Работая над несколькими проектами с командой Intelligent Social Systems, мы часто сталкиваемся с пожеланиями к изменению функционала на ходу. После любой демонстрации поступает шквал идей, и это нормально, так как ребята работают в живом и развивающемся стартапе. Мы с ними пришли к работе по такому сценарию, когда все изменения оформляются отдельной итерацией после основного релиза и публикуются отдельно, что дает дополнительный профит мобильному приложению. Это позволяет нам внедрять изменения куда более эффективно, чем это было в самом начале проекта. Мне как разработчику такой порядок работы нравится, потому что нет никакого хаоса и стресса, я всегда понимаю, что я сработал хорошо — просто у клиента появилось новое видение."

Запущенный проект для стартапа

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

Выгода для всех

Как видите, есть способ как предупредить риск, так и работать с ним в процессе проекта. Не стоит переживать и нервничать, что заказчик не принимает ваш проект с первого раза. Все мы сталкиваемся с этим, и это нормально. Надо просто учиться грамотно работать с изменениями!

В проекте, где управление изменениями организовано, лучше становится всем:

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

Надеюсь, что эти советы помогут вам в будущем!

Автор статьи: Дарья Ахмерова,
Менеджер мобильных проектов
в Improve Digital

Понравилась статья? Поделитесь с коллегами и друзьями: