Как оценивать проекты и управлять расползанием масштабов

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

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

Я преувеличиваю? Возможно, но давайте посмотрим, где так часто что-то идет не так с цифровыми проектами.

Проблемы с нашим проектным процессом

По моему опыту, большинство организаций в любой отрасли ведут проекты примерно одинаково:

1. Кто-то из руководства просит завершить проект. К сожалению, в этом запросе часто не хватает подробностей с точки зрения результатов и, как правило, есть только расплывчатые цели.
2. Комитет заинтересованных сторон собирается для детального определения проекта и принятия решения об объеме.
3. Затем детальный объем передается команде, которая будет его строить, и их просят оценить, сколько времени это займет и сколько это будет стоить.
4. Проект доставляется в соответствии со спецификацией, подчеркивая доставку в срок и в рамках бюджета. В результате крип прицела становится врагом.
5. Проект выполнен, и все переходят к следующему проекту в своем списке задач.

Такой подход далек от идеала, особенно для цифровых проектов. Цифровые технологии дают нам беспрецедентную обратную связь о поведении пользователей и позволяют относительно легко вносить изменения (по сравнению с физическими продуктами). Тем не менее, как только объем определен и предоставлена ​​смета, проект становится заблокированным, и все не хотят вносить изменения по ходу проекта.

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

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

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

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

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

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

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

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

Разбейте проекты на серию более мелких задач

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

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

1. Открытие,
2. Альфа,
3. Минимально жизнеспособный продукт,
4. Постоянная итерация и оптимизация.

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

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

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

Каждый этап помогает определить и оценить следующий этап, начиная с открытия.

1. Открытие

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

Как правило, он включает такие элементы, как:

• проведение исследований пользователей;
• анализ конкуренции;
• определение ключевых показателей эффективности;
• определение того, как выглядит успех;
• понимание ограничений;
• сопоставление мнений заинтересованных сторон.

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

Самое главное, это подтвердит, что проект принесет требуемую ценность.

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

2. Альфа

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

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

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

Мы делаем это по трем причинам.

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

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

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

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

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

3. Минимально жизнеспособный продукт

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

Чтобы избежать этой проблемы, я стал называть этот этап минимально жизнеспособным продуктом (MVP). На этом этапе мы создаем и запускаем начальную версию цифрового сервиса.

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

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

4. Текущая итерация и оптимизация

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

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

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

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

Почему разбивка проектов работает

Разбивка проектов таким образом дает четыре существенных преимущества:

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

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

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

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

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