🎸🎸🎸🎸 Управление проектами Вот мы и подошли к теме про управление проектами, которая часто вызывает бурные споры про свою эффективность и необходимость. Хотя суть споров не всегда ясна. Важно понимать, что проекты обычно (всегда) возникают там, где ведутся какие-либо изменения. И не обязательно в ИТ. Строит компания новый магазин - это проект. Открывает новый склад - это проект. Девелопер строит новый объект (пусть даже типовой) - это проект. Внедряет бизнес новую ERP систему (1С ERP, SAP, Oracle) - это проект. Компания, торгующая одеждой, начинает торговать на кассе едой в виде энергетических батончиков - это тоже проект, или группа взаимосвязанных проектов, именуемая портфелем проектов. Поскольку изменения обычно делаются для чего-то, а в бизнесе они обычно делаются для увеличения прибыли, то есть острая необходимость контролировать сроки, бюджеты, окупаемость этих проектов. И если их случайно превысить, то инвестиции могут стать затратами, или никогда не окупиться, и лучше такой проект не делать вообще. Т.е. представьте, вы хотите внедрить новую CRM систему. Вы посчитали, что бизнес-эффект от ее внедрения составит 1 млн. руб. в месяц. Вы согласны на срок окупаемости в 6 месяцев, т.е. готовы потратить на внедрение этой CRM 6 млн руб. После чего вы сходили к интеграторам и после всех тендеров получили стоимость внедрения 5 млн, а срок внедрения - 3 месяца. Теперь представьте, что из-за дискоммуникации в команде, изменения (расширения) условий задачи в процессе ведения работ, не предусмотренных заранее особенностей, нехватки специалистов, компетенций и прочих нюансов, срок внедрения вырос в два раза (и это еще хорошо, что он известен и конечен), и потащил за собой бюджет, который теперь стал составлять не 5, а 12 млн, потому что вскрылись новый затраты.. А для вас это нерентабельно. В какой момент вы бы хотели отказаться от такого нерентабельного проекта? В самом начале? После потраченного 1 млн? 5 млн? Или в конце, когда потрачено уже 12 млн, зная, что они не окупаются? Проектное управление позволяет держать проводимые изменения в рамках рентабельности, или вовремя и с минимальными затратами выйти из заведомо невыгодного пула изменений. Но это про дискретные проекты, конечные в бюджете и времени. Сфера ИТ и в частности цифровизация - это всегда про изменения, преимущественно безостановочные. Т.е. изменения производятся непрерывно, улучшая один или несколько ИТ продуктов одновременно. Я за весь свой опыт ни разу не встречал случая внедрения ИТ продукта, который бы после внедрения не требовал какого-то последующего развития. Даже счастливые обладатели SAP при невероятной стоимости разработчиков SAP лет 5 назад умудрялись выделять бюджеты на изменения в этом крупном, известном, и казалось бы самодостаточном ИТ продукте. Что уж говорить про самописные системы, системы на платформе 1С, сайты и пр., на изменения в которых всегда есть заказчики. В связи с этой особенностью появились отдельные виды проектов, и способы управления ими, когда необходимо контролировать не конечную цель, а динамику изменений. А инвестиции и их капитализация проводятся не разово, а ведутся в постоянном режиме. Кто-то это называет Agile, кто-то продуктовым управлением, кто-то придумывает собственные названия, но суть все равно сохраняется. При этом есть фанаты ломать копья по поводу сравнения Waterfall и Agile. Про особенности и разницу поговорим в следующих публикациях в рамках цикла постов про проектное и продуктовое управление. Ценные идеи, критику, вопросы и несогласия пишите в комментариях. #туториал Главный по цифровизации | Александр Афанасьев | CIOaaS