Прогрессивная разработка для успеха проекта

Прогрессивная разработка - шаг за шагом к успеху проекта

Многие люди боятся составить хороший план проекта - они думают, что это займет слишком много времени. Институт управления проектами (PMI) предлагает решение под названием Progressive Elaboration. Это причудливый термин, обозначающий шаг за шагом хороший дизайн, пока мы не добьемся отличных результатов.

Успешное развитие

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

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

• Точность - это не то же самое, что детали.
• Сделать это правильно с первого раза дешевле.
• Нам не нужно проектировать все сразу, заранее.

Читайте дальше, чтобы узнать больше.

Точность - это не то же самое, что детали

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

Чтобы сделать это хорошо, мы должны быть предельно ясными: высокоуровневое описание объема или проекта может быть не детализированным, но все же должно быть точным. Он может быть коротким и простым, но он не должен быть неопределенным.

Пример использования: Улучшения веб-сайта для увеличения коэффициента конверсии

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

Давайте постепенно расширять масштаб этого проекта:

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

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

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

Более подробная информация: погружение в детали маркетинга

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

• Меньше кликов для закрытия. Исследования показывают, что чем больше кликов между переходом на страницу и закрытием сделки, тем больше людей покидает сайт. Таким образом, страницы можно оптимизировать для увеличения коэффициента конверсии.
• Создает ощущение срочности. Если продукт выглядит так, как будто он появится позже, люди часто откладывают покупку и никогда не возвращаются. Группе технического маркетинга, возможно, придется вернуться к руководству, чтобы спросить, являются ли краткосрочные продажи со скидкой приемлемым способом повысить коэффициент закрытия.
• Устраните путаницу. Подробные инструкции и много юридических формулировок снизят скорость закрытия.
• Прямые посадочные страницы. Объявления должны идти прямо на целевые страницы, которые являются страницами продаж рекламируемого товара.
• Приветствуем клиентов снова. Используя файлы cookie, логин клиента или и то, и другое, мы можем направлять постоянных клиентов туда, куда они больше всего хотят попасть. Мы также можем проконсультироваться с руководителем о хранении данных о кредитных картах, чтобы упростить будущие покупки.

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

Художники всегда использовали прогрессивную разработку

Это ранний набросок, где художник в дополнение к изображению полной фигуры добавляет две альтернативные головы и цилиндр. В «Портрете Эдуарда Мане, сидящего в кресле» Дега развивает свои идеи, не беспокоясь о создании финального произведения.

Эдгар Дега, Лувр, Париж (общественное достояние) через Wikimedia Commons

Здесь, в этом наброске черным мелом, концепция проработана более полно как «Этюд к портрету Эдуарда Мане». Разработка продолжается.

Эдгард Дега, Метрополитен-музей Нью-Йорка (общественное достояние) через Wikimedia Commons

Этот полный «Офорт» Портрет Эдуарда Мане, этюд, сидящий, повернутый влево, является богатым и сильным результатом прогрессивной разработки Дега своего предмета.

Эдгар Дега, Бостонская публичная библиотека (общественное достояние), через Wikimedia Commons

Сделать все правильно с первого раза дешевле

В любом проекте есть только три варианта качества и результатов:

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

Итак, в общем, лучше вначале быть ясным и точным. Насколько лучше? Множество исследований за последние 40 лет показали, что существует соотношение между затратами на предотвращение ошибки; стоимость исправления ошибки во время проекта; и стоимость уборки после проекта. И минимальное соотношение - 1: 10: 100. Таким образом, ошибка, которую можно предотвратить за дополнительный час планирования при затратах 100 долларов в час, потребует 10 часов проектного времени и 1000 долларов на исправление во время проекта, а также 100 часов и 10 000 долларов, если нам придется отозвать проект после завершения проекта.. И соотношение намного выше, чем 1: 10: 100, было обнаружено, если мы использовали передовой опыт в области управления качеством для создания бездефектного проектирования с самого начала.

Урок: прогрессивная проработка - разработка большего количества деталей по мере продвижения - всегда имеет смысл. Небрежная работа никогда не имеет смысла.

Нам не нужно делать все сразу

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

• Начнем с общей картины и углубимся в детали.
• Четкость на каждой встрече, запись результатов и их подтверждение.
• Отслеживание того, сколько мы определили, а сколько еще не определено.
• На каждую встречу приглашаем нужных людей. Ранние встречи, скорее всего, будут с руководителями и менеджерами более высокого уровня. А мы, руководители проектов, наверняка будем на всех встречах. По мере того как мы стремимся раскрыть детали процесса, рабочего процесса и интерфейса, мы больше работаем с рабочими. А поскольку встречи становятся все более техническими, нам нужно больше технических специалистов (например, программистов и инженеров), задействованных на стороне проекта.
• Мы продолжаем работать до тех пор, пока не будет определена каждая деталь каждой функции продукта или услуги, которые мы создаем или улучшаем. Однако у нас может быть написано много программы или продукт, поскольку мы продолжаем детализировать другие части.

Прогрессивная проработка проектов, устраняющих проблемы

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

Проблема - это то, что возникло, что мешает компании или производственной линии работать так, как раньше. Итак, цель уже ясна: заставить эту чертову штуку работать! Вовлеченность руководителей минимальна, и менеджерам почти нечего делать, кроме как оказывать поддержку. Фактически, поскольку менеджеры уже знают, что это за «вещь» и как она должна работать, «Пусть эта чертова штука работает!» является полным и точным заявлением о высшем исполнительном уровне.

Пример из практики: задержка запуска космического корабля "Атлантис" в 2006 г.

Хороший пример этого типа проекта произошел в 2006 году, когда возникли проблемы с датчиком уровня топлива 10-летней давности, который измерял количество водорода в топливных баках космического корабля «Атлантис». Датчик стал ненадежным, иногда показывал, что бак пуст, когда он полон, и проблема возникала периодически.

Заявление об объеме работ на уровне высшего руководства будет ясным: почините указатель уровня топлива, чтобы мы могли управлять шаттлом!

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

• Решение руководства: если мы знаем, что датчик неисправен, можем ли мы просто выключить его и полагаться на другие датчики и все равно летать. По этому поводу было много споров. Но в конце концов было решено, что важная функция безопасности - отключение главного двигателя (MECO) - не будет надежной без этого датчика. Таким образом, руководство решило, что датчик необходимо отремонтировать.
• Техническая проблема: проблема возникала периодически. Следовательно, ни одно пройденное испытание не было доказательством того, что датчик работает и что шаттл может безопасно летать. Требовалось найти конкретную проблему, чтобы быть уверенным, что она исправлена.
• Подробная техническая проблема: датчик не был простым устройством. В нем задействовано множество различных компонентов и электрические разъемы между ними. Некоторые из них были закопаны глубоко в проводке шаттла. Просто найти все компоненты и очистить их разъемы было нелегко. Более чем однажды инженеры думали, что они устранили проблему, но прибор не проверял чистоту.
• Очень подробная техническая проблема: проектные планы космического шаттла, возможно, не полностью соответствовали проекту Атлантиды в том виде, в котором он был построен. Детали были модернизированы и заменены. Один инженер сообщил, что обнаружение всех частей датчика было исследовательской миссией, что они все еще выясняют, как работает космический шаттл!

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

Прогрессивная разработка не ограничивается рамками

Хотя в этой статье основное внимание уделяется прогрессивной разработке при разработке определения объема работ и иерархической структуры работ (WBS), концепция постепенной разработки шире. Фактически, его можно применить ко всем девяти областям управления проектом. Вот некоторые примеры:

Постепенная разработка плана коммуникаций проекта

Первая версия коммуникационного плана проекта может быть просто списком контактов членов команды и заказчиков проекта. Мы уточняем это:

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

Разработка управления рисками в проекте

Формальные этапы управления рисками проекта постепенно развивают наше определение риска проекта - что может пойти не так - и наши меры реагирования посредством:

• Идентификация рисков, где мы составляем наш первоначальный список рисков.
• Анализ рисков, при котором мы оцениваем и приоритизируем риски
• Планирование реагирования на риски, где мы решаем, что делать, чтобы предотвратить события риска, и что делать, если они произойдут
• Мониторинг и контроль рисков: мы следим за рисками, выявляем новые риски и обрабатываем их по мере их возникновения.

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

Прогрессивная разработка и жизненные циклы проекта

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

Прогрессивная проработка классического водопада

В классическом водопаде или жизненном цикле разработки системы (SDLC) все планирование предшествует выполнению. Следовательно, все постепенное уточнение объема происходит на этапах планирования.

Прогрессивная разработка с быстрым отслеживанием

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

Параллельное управление проектами

Параллельное управление проектами было разработано Hewlett-Packard и сейчас широко используется в автомобильной промышленности. Объединяя вначале всех специалистов, жизненный цикл проекта (например, вывода на рынок нового концепт-кара) можно сократить с пяти лет до 18 месяцев! В параллельном управлении проектами прогрессивная разработка выполняется быстро и быстро кросс-функциональными командами.

Разработка программного обеспечения без дефектов

Бездефектный метод разработки программного обеспечения ориентирован на точность, чтобы предотвратить попадание ошибок в код. Ранняя разработка дизайна с последующей ранней проработкой самого кода с многочисленными проверками заставляет многих обратить внимание на проблему, создавая программное обеспечение высочайшего качества при минимальных затратах. Если 80% усилий затрачивается на хороший дизайн, затраты на тестирование и отладку резко сокращаются.

Спиральная модель

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

JAD и RAD

JAD (совместная разработка приложений) и RAD (быстрая разработка приложений) не являются реальными альтернативами жизненного цикла. Скорее, это методы выявления требований, влияющих на жизненный цикл. Расположение дизайнеров и программистов в непосредственной близости от их клиентов, пользователей приложения, ускоряет разработку. Частые встречи позволяют быстро и постепенно доработать. И этот подход - ключевой компонент гибкой разработки.

Прогрессивная разработка в гибкой разработке

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

Что вы думаете о прогрессивной разработке?

Прогрессивная проработка способствует развитию проекта

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