Разработка
06.11.2024
Почему иногда невозможно точно просчитать стоимость и сроки разработки продуктов
Анализ на основе концепции VUCA и ранней фазы планирования проектов
Разработка digital продуктов с нуля зачастую бывает сложным и многогранным процессом, в котором прогнозирование сроков и стоимости почти всегда представляет собой вызов для команды как со стороны заказчика, так и со стороны исполнителя (здесь мы говорим не об одном человеке, а о целой команде дизайнеров, разработчиков и проджектов). Планирование и расчет сроков сопровождается высокой степенью неопределенности именно на ранних этапах.
Под ранними этапами подразумевается множество вариантов действий, идей и направлений, по которым может развиваться проект, пока продукт еще не определен. Этот ранний этап часто называют "размытым фронтом" из-за его неопределенности.
Большинство сложностей, с которыми сталкиваются разработчики на ранней стадии проектирования продуктов, можно объяснить с помощью концепции VUCA, которая объединяет четыре ключевых аспекта: изменчивость (Volatility), неопределенность (Uncertainty), сложность (Complexity) и неоднозначность (Ambiguity). В этой статье мы хотим донести мысль, как каждый из этих аспектов влияет на способность исполнителей точно предсказывать затраты и сроки разработки продуктов. Мы решили расположить эти аспекты в порядке убывания исходя из преобладания одного аспекта среди других.
1. Сложность архитектуры продукта (Complexity)
Начнем пожалуй с самой ключевой причины, из-за которой прогнозирование стоимости и сроков разработки может стать трудной задачей — высокая сложность проекта. В процессе создания продуктов часто задействуются разные модули, платформы и технологии, которые должны работать вместе. Каждая модульная система требует тщательного проектирования и интеграции, а увеличение числа взаимосвязанных компонентов ведет к увеличению сложности процесса разработки. Это увеличивает риски неучтенных проблем, которые могут возникнуть на более поздних стадиях: несовместимость модулей, необходимость внесения корректировок, адаптация продукта или даже полная переработка отдельных его частей.
Когда архитектура продукта включает множество компонентов и степеней свободы для различных конфигураций, точное планирование может стать особенно трудным. Разработка модульных систем предполагает необходимость нахождения компромиссов между стандартизацией и индивидуальными требованиями клиентов. Увеличение числа вариаций продукта увеличивает вероятность того, что на этапе проектирования и сборки возникнут неожиданные проблемы, что приводит к увеличению затрат и времени разработки. Изменения, первоначально запланированные даже как незначительные, часто приводят к необходимости значительных доработок других модулей из-за их взаимозависимости.
Если архитектура продукта не позволяет легко вносить изменения в отдельные модули без затрагивания всей системы, точное планирование на раннем этапе не является возможным.
Во время разработки продуктов в силу ограниченного бюджета также стоит упомянуть проблему, когда приходится балансировать между внутренними и внешними целями.
Пример: исполнитель пытается реализовать все пожелания клиентов (внешняя цель) по лучшей цене, но при этом старается не создавать слишком много индивидуальных решений или вариантов, которые могли бы повлиять на всю архитектуру (внутренняя цель) и тем самым увеличить внутреннюю сложность и затраты как для компании, так и для клиента.
2. Неоднозначность и сложности коммуникации (Ambiguity)
Неоднозначность часто возникает, когда различные члены команды разработки или клиенты по-разному интерпретируют требования и цели проекта. Например, заказчик может предоставить ТЗ, которое воспринимается по-разному различными участниками команды — разработчиками, дизайнерами, менеджерами. Различия в интерпретациях это вполне нормальное явление, которое может возникать внутри команды, и эти различия затем приходится согласовывать, на что конечно же уходит время..Хотя могут быть расхождения в определении требований, они не возникают в основном из-за недостатка информации со стороны клиента, непонимания со стороны разработчика или недопонимания между ними. Скорее, причина кроется в намеренном утаивании или недосказанности информации о приоритетах целей, чтобы оставить пространство для переговоров.
3. Неопределенность на ранней фазе (Uncertainty)
Часто на начальных этапах разработки неясно, какие именно функции или модули будут востребованы у конечных пользователей. В таких условиях компании исполнители вынуждены принимать решения на основе неполной информации, что ведет к риску возникновения ошибок в планировании.
Процесс сбора требований от клиентов на ранней стадии также может быть затруднен из-за неопределенности в ожиданиях клиентов. Клиенты не всегда способны четко сформулировать свои потребности или могут изменить свои запросы в процессе разработки. Это приводит к необходимости частых изменений уже в процессе проектирования, что увеличивает продолжительность разработки и вносит дополнительные расходы.
Часто некоторые требования не выявляются на ранней фазе, а изобретаются в процессе самостоятельно дизайнерами
4. Изменчивость рынка и требований (Volatility)
Этот аспект преобладает намного реже, но все же о нем не стоит забывать. Это касается чаще всего долгосрочных проектов. Рынки и тренды могут быстро меняться, и то, что было актуально в начале проекта, может устареть к моменту выхода продукта на рынок. Эта изменчивость влияет на требования клиентов, что в свою очередь требует изменений в разработке продукта. Например, компания может начать проект с одного набора функций, но в процессе разработки обнаружить, что для успеха на рынке необходимы другие функции или улучшенные характеристики.
Изменения в предпочтениях клиентов, законодательные нововведения или появление новых конкурентов могут кардинально изменить приоритеты разработки. Для исполнителей это означает необходимость внесения изменений в уже продуманный и начатый проект, что приводит к перерасчету сроков и стоимости. Как мы упомянули ранее, степень модульности и возможность внесения изменений в продуктовую архитектуру напрямую влияют на возможность адаптации к изменяющимся условиям. Если архитектура продукта слишком жесткая и не допускает изменений, это может привести к значительным задержкам.
Подытожив вышесказанное, уже не опираясь на аспекты выше, давайте не будем забывать про такую вещь как человеческий фактор. Даже несмотря на компетентность и уровень исполнителя, всегда есть шанс возникновения ошибок: сотрудник упустил маленькую деталь в ТЗ, мотивация команды, разрешение как внешних, так и внутренних конфликтов. Это все может наложиться поверх часто возникающих аспектов, описанных выше.
Как купировать ошибки на проекте, если вы уже вышли за рамки бюджета и сроков?
1. Для начала стоит определиться, что более приоритетно для клиента: сроки или бюджет. Если дедлайны горят, то в любой момент привлечь дополнительных сотрудников, но это конечно ведет за собой дополнительные расходы, так как никто не хочет работать за “спасибо”.
Здесь нужно добавить, что при пожелании заказчика или других обстоятельств может дополнительно привлекаться в качестве исполнителя другая команда.
2. Для расчета дополнительного бюджета выходящего за рамки изначально запланированного мы в Labpics любим использовать концепцию Time & Materials.
Концепция Time and Materials (T&M) — это модель ценообразования и управления проектами, при которой клиент оплачивает фактически затраченное время исполнителей (дизайнеров, разработчиков) по какой-либо фиксированной ставке час вместо фиксированной цены за весь проект.
Эта концепция помогает дать клиенту более прозрачный расчет бюджета и дополнительно выполненных работ выходящих за основной бюджет. Концепция T&M особенно полезна для сложных или неопределённых проектов, где сложно заранее точно предсказать все детали.
Данная модель также подходит для проектов, в которых нужно разрабатывать уникальные и инновационные решения. В особенности для клиентов, которые в начале не до конца знают, чего хотят.
3. Предоставление ежедневных отчетов. Когда проект уже немного зашел не в то русло, то оптимизировать работу можно более частой отчетностью со стороны исполнителя. Клиенту будет проще изменять требования по ходу проекта, корректировать объемы работы и адаптироваться к новым обстоятельствам.
4. Конечно не стоит забывать использовать такой простой и бесплатный инструмент как обычный открытый диалог между двумя сторонами. При возникновении спорных ситуациях всегда проще открыто обсудить проблемы с командой и заказчиком, чтобы согласовать изменения в плане и, при необходимости, пересмотреть бюджет или сроки.
Заключение
Суммируя изложенное выше: предсказание точной стоимости и сроков разработки продуктов зачастую является невозможной задачей из-за множества факторов, которые сложно учесть на ранней фазе проекта. Концепция VUCA помогает лучше понять, почему планирование в условиях разработки иногда бывает затруднено.
Компании, сталкивающиеся с высоким уровнем сложности, неопределенностью в требованиях клиентов и изменениями на рынке, должны быть готовы к тому, что разработка может занять больше времени и потребовать больше ресурсов, чем ожидалось изначально. Важно признать, что управление проектами с нуля требует гибкости, а также умения быстро адаптироваться к меняющимся условиям как исполнителю, так и клиенту. Чем раньше обе стороны признают существование этих проблем и интегрирует механизмы для их смягчения в процесс планирования, тем лучше они смогут справиться с вызовами, возникающими в процессе разработки.
С помощью этой статьи мы хотим донести мысль нашим текущим, будущим или вовсе не нашим клиентам, что существует множество факторов зависящих не только от нас, а от разных обстоятельств. Даже обозначив на раннем этапе более ранние дедлайны и бюджеты — мы не всегда можем гарантировать 100% попадание в них, так как много непредвиденных вещей может возникнуть во время работы над проектами. Мы всегда стараемся сделать больше чем пообещали и у нас всегда в приоритете отдавать качественный и максимально удовлетворяющий клиента продукт.
Если вы хотите более подробно с концепцией VUCA и реальными исследованиями, основанные на ней, то можете ознакомиться с этой статьей.