В начале 1960-х гг. компании стали применять к деловым операциям принципы общих теорий систем. Системный подход, который развивался параллельно с сетевыми методами управления в 1950-е годы, акцентировался на менеджменте по стадиям жизненного цикла проекта. В рамках этого подхода особое внимание уделено предпроектному анализу. Метод был впервые реализован в рамках проектов NASA.
Для системного подхода характерны такие методологические принципы, как целостность, системность, иерархичность, структурность. Все эти принципы стали фундаментом для дальнейших практических применений.
Область управления проектами стала оформляться в самостоятельную дисциплину. К тому моменту накопилось большое количество методологических подходов и практических методов. В 1970-е появились профессиональные организации управления проектами, например PMI. Они обобщали и систематизировали опыт.
Далее были сформулированы новые методы управления, такие как итеративные, инкрементальные, появились гибкие методологии, бережливый подход.
Периодизация ключевых подходов:
– 1930—1960: зарождение управления проектами;
– 1960—1970: развитие методов сетевого планирования;
– 1970—1980: системный подход к управлению;
– 1980—1990: управление стало отдельной профессией, появление новых методов.
У перечисленных методов есть недостатки. Первый состоит в том, что вся функциональность разделяется на отдельные задачи, и каждый разработчик отвечает исключительно за реализацию своей задачи, но никто в итоге не несёт ответственность за всю функциональность в целом. Это ведёт к тому, что отдельные модули являются работоспособными, но все вместе – не представляют требуемой для заказчика ценности.
Вторая существенная причина проблем – указанные методики не подразумевают работу кроссфункциональной команды. В рамках поставки ценности нет активного взаимодействия проектировщиков, разработчиков, дизайнеров, тестировщиков, специалистов по маркетингу и внедрению. Это приводит к тому, что каждая часть команды выполняет только свою часть работы без оглядки на работу других команд.
И последняя в списке, но не по значимости, причина проблем заключается в том, что разработчики тянут время как бесконечный ресурс. Однако для заказчиков время – один из важнейших ресурсов, а значит для команды разработки проекта время должно быть в приоритете.
В конечном итоге управленцы пришли к мнению о том, что управление на уровне проекта – неэффективно. Так стал зарождаться и развиваться продуктовый подход.
Начнём с базового определения
Продуктовый подход – это метод организации работы
Вспомним определение метода организации работы.
Метод организации работы – это способы организации процесса труда, определения последовательности и состава операций и приемов, рационального размещения элементов труда и формы кооперации людей и техники в процессе труда с целью достижения полезного эффекта трудовой деятельности.
Для продуктового подхода характерны несколько ключевых особенностей:
– Сфокусированность;
– Полезность;
– Простота;
– Измеримость прогресса;
– Итеративное построении процесса;
– Целостность;
– Комплексная командная работа.
Сфокусированность
Работаем над одной целью.
Для достижения результата важно выбрать, над чем работать и, что не менее важно, над чем не работать. Сфокусированность помогает направить все силы, ресурсы, энергию на что-то одно важное, и не расходовать на то, что не принесёт пользы и выгоды.
Для достижения результата важно выбрать, над чем работать и, что не менее важно, над чем не работать. Сфокусированность помогает направить все силы, ресурсы, энергию на что-то одно.
Полезность
Делаем то, что важно.
Продуктовые команды должны держать фокус не на работе над задачами и проектами. Их внимание должно быть сконцентрировано на создании ценности продукта для пользователей и для бизнеса.
Простота
Не усложняем.
Для достижения первых результатов достаточно простой и понятной системы. Не нужно создавать громоздкого монстра. Возможно, его будет сложно поддерживать, а возможно, он окажется не нужен.
Измеримость прогресса
Используем метрики.
Метрики помогают объективно измерить результат работы и принимать решения. В идеале решения обосновываются не пожеланиями, а контролируемыми и верифицируемыми измерениями.
Читать дальше