Проект или поток?
Проект — это мысленная абстракция, которую мы используем, чтобы помочь себе понять мир.
Проекты не возникают по каким-то законам природы. Это мысленные конструкции, которые мы создаём, чтобы помочь себе управлять собственной работой.
Я трачу большую часть своего времени на проекты. Я работал над проектами по созданию систем электронной коммерции, проектами по созданию и обновлению сайтов, проектами по созданию новых продуктов, даже над проектами для определения метода, по которому мы делаем проекты внутри организации.
Идея проекта, как основной единицы работы, довольно распространённая в нашей индустрии. Многие организации формируют свою структуру почти полностью вокруг портфеля проектов, ответственность за которые они на себя взяли.
И огромная отрасль, где приходят на ум PRINCE2, PMI и разные другие группы по проектному менеджменту, возникла исключительно для обслуживания интересов проектов и руководителей проектами.
Но насколько реальны эти проекты?
Где-то между делом мы бы сделали выводы, что разбивка материала, с которым мы сталкиваемся в работе, на отдельные, чётко ограниченные блоки, называемые проектами, облегчит нам координирование связанных действий, общение с людьми, которых касаются наши действия, и так далее.
Другими словами, проект — это модель. Это мысленная абстракция, которую мы используем, чтобы помочь себе понять мир. И, как говорится, «все модели неправильные, но некоторые — полезны».
Таким образом, понятие проекта — упрощение, жизнь порой не делится чётко на проекты. Так что я часто сталкиваюсь с проблемами вроде таких:
Проекты создают искусственные границы между действиями
Например, они создают разрыв между построением и работой веб-сайтов и других систем.
В один день мы приделываем элементы сайта, как часть проекта; на следующий день мы делаем такие же изменения, как часть повседневных действий. И механизмы, который мы используем, чтобы установить очерёдность работ, выделить ресурсы, и так далее, полностью меняются за ночь.
Это создаёт конфликты, беспорядок и дополнительные затраты ресурсов: аргументирование того, что составляет «ошибку», в отличие от «улучшения»; изменение руководства проектами, чтобы распределить работу между ними; механизмы разрешения спорных вопросов и так далее.
Некоторые действия не соответствуют чётко проектам
Люди делаю много вещей, которые не имеют никакого отношения к определённым проектам, продуктам и сопровождению пользователей, обслуживанию системы, подготовке кадров и так далее.
Поскольку эта работа не является частью проекта, мы не выделяем на неё время, не устанавливаем механизмы для расстановки спорных приоритетов и, в иных случаях, не в состоянии нею управлять.
Тогда это перетекает в наши проекты. Как часто вам приходилось видеть, что проект не достиг ожидаемых успехов, потому что время людей растрачивалось на другие действия?
Или, наоборот, как часто нужная работа пропускалась, потому что люди были слишком заняты своими задачами по проекту?
Мы определяем проекты, которые становятся свалкой слабо связанных действий
Чтобы избежать проблемы, описанной выше, мы пытаемся поместить все в проект, так образом, мы заканчиваем проектами, которые собирают несвязный набор действий в одну кучу просто для удобства нашей мысленной модели.
И снова это создаёт дополнительные расходы, люди тратят время, слушая отчёты о состоянии действий, которые абсолютно не связаны с их собственной работой, например.
Все это признаки того, что наша модель сбоит.
Интересно взглянуть на некоторые тенденции, происходящие в связи с этим в разработке программного обеспечения. Например, команды быстрых разработок идут на все более напряжённые рабочие циклы.
30-дневные броски были нормой, когда методология Scrum только вошла в моду, но теперь более распространены семь дней. И Kanban-команды окончательно далеко ушли от идеи определённых проектов и циклов, чтобы попытаться поставить на непрерывный поток производство новых свойств.
Это, вместе с давлением на большинство организаций, заставляет последние запускать изменения быстрее, и, в то же время, порождает огромные вопросы по идее проекта как определяющей модели для организации нашей работы.
Я думаю, эта «потоковая» модель станет гораздо более предпочтительной в наступившем году.
Это не означает, что концепция проекта не важна. Некоторые работы действительно чётко попадают в рамки проектов. И концепция проекта хорошо служит многим организациям.
Я могу, конечно, представить себе несколько организаций, где недостаток чётко определённого портфеля проектов и структуры управления проектами создали полнейший беспорядок. Зависящие друг от друга действия выполняются независимо, с возникающими, как следствие, проблемами в интерфейсах
Люди с общими целями действуют с противоположными намерениями. И ни у кого нет чёткого представления ни о том, к чему, в общем, двигаться, ни о том, как время и внимание людей расположить по приоритетам.
Но проекты уже не оптимальный вариант. Будьте готовы подогнать модель под соответствие реальности в вашей ситуации, а не наоборот.
Комментировать