Индиана Джонс и команда: Как преодолеть препятствия в проекте?

Когда мы слышим фразу «план проекта», в нашем воображении возникает образ идеальной прямой, соединяющей две точки: точку А, где мы находимся сейчас, и точку Б, куда придем в конце проекта.
Однако это не всегда так. Проект — это невероятное путешествие из точки А в точку Б, полное неожиданностей и приключений. Вспомните фильмы об Индиане Джонсе — они точно передают дух этого пути.
Как только проект запущен и мы начинаем двигаться в точку Б, то мы неизбежно столкнемся с препятствиями: внесение правок, болезнь сотрудника, потеря флешки, проблемы с карандашом, а также неожиданные обновления операционной системы за минуту до конференции. И это лишь некоторые из них.
Можно перечислять бесконечно, ведь каждый проект уникален и полон своих подводных камней. Но суть уже ясна: проект может прийти к совершенно другой точке Б, отличной от первоначальной.
К сожалению, глобальную идею невозможно реализовать на 100%. Пострадают либо время, либо бюджет, либо качество. Нам придётся чем-то жертвовать. Каждый сам решает, чем именно, но давайте мы немного подстелем соломки и подскажем наименее путь.
Я руководствуюсь правилом, которое подсмотрел у одной дизайн-студии и адаптировал под свои проекты. Правило звучит очень просто: fix time, fix budget, flex scope.

Фиксируем время

Существует так называемый «закон о потерях», который гласит, что в любом проекте всегда будут присутствовать определённые издержки. Это не имеет отношения к физическому закону сохранения энергии, а скорее является специфическим принципом управления проектами.
Задуманный проект невозможно осуществить за 100% времени, на 100% денег, со 100% функциональностью и без потери качества. Всем известно, что репутация зарабатывается годами, а теряется за один день. Поэтому жертвовать качеством — это не вариант. Согласны?
Первое, что мы делаем, — это фиксируем срок. Кажется, обычное дело — перенести срок, когда команда не успевает вовремя, особенно в наше непростое время. Но это нехорошо. Все знают, что время — невосполнимый ресурс. Попробуйте разложить слово «deadline» на составляющие и все станет очевидно.

В общем, сроками жертвовать нельзя ни при каких обстоятельствах. Как оценивать и фиксировать сроки — это тоже целая наука, но попробуем ограничиться простыми принципами.

1. Чтобы эффективно оценить сроки проекта, начните с разделения его на небольшие задачи. Это поможет вам четко понимать объем работы на каждом этапе.

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

3. Учитывайте прошлые данные о выполнении подобных задач или соберите оценки на основе предыдущего опыта.

4. Не забудьте добавить дополнительное время на возможные риски и непредвиденные обстоятельства.

5. Регулярно проверяйте и корректируйте график, сравнивая запланированное время с фактическим выполнением задач, чтобы своевременно вносить необходимые изменения.

Только после того, как мы определились со сроками, можно двигаться дальше.

Фиксируем деньги

Существует два глобальных подхода: «Time and Materials» и «Fixed Price» («Время и ресурсы» и «Фиксированная стоимость»). Я уверен, что подходов больше, но мы рассмотрим только эти два. Как говорится, «Есть два стула...».

Подход «Time and Materials» (T&M):
Этот метод предполагает оплату по факту выполнения работ. Проект разбивается на задачи, каждая из которых оценивается отдельно. Оплата производится на основе затраченного времени и материалов.

Подход «Fixed Price» (FP):
При этом подходе бюджет и сроки проекта фиксируются заранее. Исполнитель обязуется выполнить работу в оговоренные сроки и за фиксированную стоимость, независимо от реальных затрат времени и ресурсов.

Деньги могут решить практически всё. В случае с проектами это чаще всего означает, что заказчик либо оплачивает дополнительное время на решение задач, либо расширяет команду проекта, чтобы успеть к сроку. Увеличение команды, скорее всего, приведет к прогрессии имеющихся проблем и хаоса, а мы уже договорились так не делать и даже зафиксировали договоренности по срокам.

Ну окей давайте сравним эти подходы по трем параметрам.

1. Сроки:

● T&M: Сроки могут варьироваться в зависимости от объема задач и их сложности.

● FP: Фиксированные сроки, исполнитель несет ответственность за соблюдение дедлайнов.

2. Бюджет:

● T&M: Гибкий, зависит от фактически затраченного времени и ресурсов.

● FP: Фиксированный, известен заранее, но может включать дополнительные расходы на непредвиденные ситуации.

3. Функциональность

● T&M: Легко вносить изменения и дополнения в ходе проекта.

● FP: Ограничения на изменения после подписания контракта, что может привести к дополнительным сложностям при внесении корректировок.

Таким образом, «Time and Materials» подходит больше для проектов, где важна гибкость и возможность внесения изменений, а финальный итог проекта хоть немного находится в зоне неопределенности.

В то же время «Fixed Price» идеален для небольших проектов со строго ограниченным функционалом, в который точно не будут вноситься изменения и дополнения во время разработки и реализации. Если вы знаете о таких проектах — расскажите в комментариях, я, по крайней мере, не сталкивался ни с одним. На листе бумаги (например, в ТЗ) или в системе управления проектами все выглядит очень здорово, но когда доходит до практики, приходится «выбирать стул».

Вспоминаем: мы не готовы жертвовать сроком реализации, ограниченным бюджетом и качеством конечного продукта. Методом исключения приходим к решению: жертвуем функциями. Безжалостно режем то, что не успеваем сделать или то, что не несет реальной очевидной пользы. Да, делаем выбор в сторону "ехать" а не "шашечек". Здесь есть много плюсов и минусов, но на практике все только выиграют.

Оперируем функциональностью

Давайте начнем с явных преимуществ, которые играют ключевую роль в нашем подходе:

● Выход продукта в срок. Проект запускается с целью создания продукта, который будет решать какую-то определенную задачу. Приносить доход, расширять аудиторию, помогать помнить клиентов, хранить данные о паролях или своевременно согласовывать новые договоры. Ну или решать другие задачи, для которых все затевалось…

Я не сразу осознал этот важный аспект, но теперь он стал для меня очевиден.

«Чем больше колен в системе, тем больше вероятность, что одно из них выйдет из строя». В нашем контексте это означает, что чем больше функций у продукта, тем больше ответственности. Чем больше пересечений функционала, тем выше риск ошибки. Отказ от некоторых функций на начальном этапе поможет сократить количество узких мест и улучшить качество первой версии.

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

● Новый продукт легче объяснить пользователям. Новый продукт с небольшим количеством функций проще понять, особенно тем, кто не знаком с особенностями задуманного функционала. “Эта штука позволит вам не записывать итоги разговора с клиентом” намного проще и понятнее, чем “Система транскрибации и оценки телефонных звонков менеджеров по 15 критериям с уведомлением руководства”. Возможно, некоторые детали только усложнили бы понимание.

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

Кто-то согласен с этим подходом, кто-то — нет. Это понятно. Но даже если заказчик согласен, это не значит, что проблем не возникнет. Я всегда предупреждаю о возможных трудностях на самом старте проекта.

Давайте перейдем к минусам:

● В основном - это страх. Отказ от какой-либо функции — это всегда страшно и болезненно. Представьте, что вы заказываете ящик апельсинов, а курьер точно в срок по той цене, что и на ценнике, доставляет вам отличные апельсины, но только половину ящика. Каково это?

Однако доставка апельсинов — это стандартизированная процедура с отлаженной логистикой. Риски предсказуемы и заранее заложены в цену.

Проекты — это другое. Во время экспедиции Колумба были бунты, болезни, поломки и штормы. В результате он открыл совсем другую страну, не ту, на путешествие в которую собирал деньги. Как вам такой проект?

● Приоритеты. Часто мы не знаем, какие функции нашего продукта следует реализовать в первой итерации, а какие лучше отложить. В таких случаях важно сосредоточиться на основной задаче продукта.

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

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

И как теперь быть?

В современном мире проектного менеджмента все чаще возникает необходимость в ориентации на Time and Materials (T&M), который подразумевает постепенное планирование и запуск функциональности. Это связано с тем, что традиционные методы фиксированных контрактов (Fixed Price) не всегда могут обеспечить гибкость и адаптивность, необходимые для успешного завершения проектов в условиях быстро меняющегося рынка и требований заказчиков.

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

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

Подход Time and Materials (T&M) помогает команде быстро адаптироваться к новым условиям и минимизировать риски, что обеспечивает своевременное завершение проекта с гарантированным качеством выполнения задачи. В условиях неопределённости и быстро меняющихся требований ориентация на T&M становится не просто желательной, а необходимой стратегией в проектном менеджменте.

Статья написана для канала СБПроБизнес. Благодарим автора - Максима Зубеева! У Максима есть ТГ Канал https://t.me/M3ybeev там тоже интересно😉