Управление проектами

Оценка длительности: почему ваши прогнозы чаще всего оптимистичны? «Это займёт две недели».  А потом проходит месяц, и вы объясняете заказчику, почему «две недели» превратились в шесть. Почему так происходит снова и снова? Психология планирования: три причины оптимизма 1. Ошибка планирования (planning fallacy). Канеман и Тверски описали это ещё в 1970-х: люди систематически недооценивают сроки и стоимость, даже когда имеют опыт подобных задач. Мы верим, что «в этот раз всё пойдёт по плану», игнорируя статистику прошлых проектов. 2. Effect of optimism (эффект оптимизма). Мы склонны верить, что нам повезёт больше, чем другим. Пробки, болезни, сбои, «внезапные» требования — всё это случается с кем-то другим, но не с нами. В проекте это превращается в оценку «если всё пойдёт хорошо» — а «хорошо» не идёт почти никогда. 3. «Проклятие знания» (curse of knowledge). Чем лучше вы знаете задачу, тем сложнее вам представить, что что-то может пойти не так. Эксперт оценивает работу, которую делал сотню раз, и забывает про все случаи, когда она занимала в два раза дольше. Новичок, наоборот, боится всего и часто даёт более реалистичные оценки. Что делать: практические приёмы 1. Оценка по трем точкам. Вместо одной цифры — три: оптимистичная (O), ожидаемая (M), пессимистичная (P). Расчетная длительность считается по формуле PERT: E = (O + 4M + P) / 6 Это способ учесть неопределённость. Если разброс между O и P огромный — это сигнал: задача плохо понята, нужно декомпозировать. 2. Буферы. Не прячьте резервы внутри задач. Выносите их отдельно. Буфер — это не «увеличение сроков», это страховка. Если буфер не понадобился — вы сдали проект раньше. Если понадобился — вы не нужно объяснять заказчику, почему «две недели» превратились в шесть. 3. Метод Монте-Карло. Полноценное моделирование требует специальных инструментов. Как работает Монте-Карло: - Для задач с большой неопределенностью в плане задайте три оценки (O, M, P). - Внесите риски в план проекта. Оцените их вероятности. - Для каждого риска разработайте последствия – «что произойдет с проектом если риск наступит». И внесите их в план. - Запустите генерацию сценариев: для каждой задачи случайно выбирается длительность в диапазоне O–P с учётом распределения. Риски при каждом сценарии также «происходят» с учетом их вероятностей.   - Рассчитывается длительности проекта для каждого сценария. - Получите распределение: вероятность завершить проект к определённой дате. - Примите решение о том, какая вероятность завершения проекта допустим для вас и заказчика. - Аналогично можно сделать моделирование затрат. Если нет Spider, то метод Монте-Карло возможно сделать с помощью VBA в MS-Project. Excel оставьте в покое – он не для этого. Освоить VBA для MS-Project можно на моих курсах. 4. Оценка по аналогам с поправкой. Возьмите похожий проект из прошлого. Посмотрите, сколько он занял фактически, а не по плану. Добавьте поправку на различия. Это самый честный способ — он основан на реальности, а не на вере в лучшее. 5. Декомпозиция. Чем крупнее задача, тем выше неопределённость. Разбейте работу на мелкие шаги — так вы увидите, где именно скрываются риски, и сможете оценить каждый шаг отдельно. Как перестать обещать «через две недели» Не давайте оценку сразу. «Я вернусь с цифрой завтра» — это профессионально. «Две недели» на встрече — это гадание. Говорите диапазоном. «От двух до четырёх недель, скорее всего — три» — честнее, чем «две недели». Показывайте неопределённость. Если вы используете оценку по трем точкам, покажите заказчику разброс. Это не слабость, это управление ожиданиями. И да, в договоре лучше ни использовать оптимистичную оценку. Отслеживайте ход проекта. Сравнивайте план с фактом. Если ваши оценки систематически занижены на 30% — вносите поправку. Это называется «калибровка». Главное: реалистичные прогнозы — это не пессимизм, а профессионализм. #УправлениеПроектами #ОценкаДлительности #PERT #МонтеКарло #VBA

Про безответственность и мотивацию 29 сентября городская администрация отчиталась о подготовке к отопительному сезону – город «готов» к холодам. В первых числах октября отопительный сезон «стартовал» авариями и ремонтами теплотрасс. Так каждый год. Меняются мэры, подрядчики, места раскопок. Но каждый год сценарий одинаковый: красивый отчет и буквально тут же последующий аварийный ремонт. Почему? Потому что нет ответственности. И нет мотивации делать иначе — «бесконечные» ремонты выгоднее, чем один раз сделать нормально. Знакомая ситуация? А теперь о проектах. Клиент попросил провести тренинг. Задача: чтобы персонал активнее участвовал в проектах. Ладно, говорю, пришлите положение о проектной деятельности. С трудом получил. Читаю. Ни слова об ответственности за невыполнение работ, нарушение сроков. И ни слова о том, что будет, если человек, наоборот, выложится по полной и сделает свою задачу. Вопрос: почему персонал будет активнее участвовать в проектах? Если участие в проекте — это дополнительная нагрузка без признания, без карьерных перспектив и без последствий за отказ, то зачем напрягаться? Безответственность + отсутствие мотивации = отсутствие результата. Это не про «плохих сотрудников». Это про систему, в которой не прописано, кто за что отвечает и что получает. Тренинг не исправит положение, в котором нет ни ответственности, ни мотивации. Иначе получится как с теплотрассой: каждый год отчет, потом авария и ремонт. #УправлениеПроектами #PMO #Мотивация #Ответственность

Карьерный тупик PM: куда расти дальше? Проекты идут один за другим. Задачи похожи. Бюджеты, сроки, риски, отчёты. В какой-то момент ловишь себя на мысли: «А что дальше?» Вроде бы всё умеешь, но роста нет. Знакомая боль. Хорошая новость: тупик — это иллюзия. Плохая: выход есть, но придётся выйти из привычной колеи. Вот несколько направлений, куда может пойти проектный менеджер (список конечно неполный): 1. Senior PM – то, что напрашивается в первую очередь Ты не просто ведёшь проекты — ты берёшься за самые сложные, кризисные, стратегические. Отвечаешь не только за сроки, но и за бизнес-результат. Учишь других. Что меняется: меньше операционки, больше политики и стратегии. Навыки: управление программами, финансовая грамотность, лидерство, наставничество. 2. Продакт-менеджер (Product Manager) Переход из проекта в продукт. Фокус смещается с «сделать в срок и в бюджет» на «сделать то, что нужно рынку». Ты работаешь с гипотезами, метриками, пользователями. Что меняется: больше неопределённости, меньше чётких требований. Навыки: аналитика, юзабилити, маркетинг, принятие решений на основе данных. 3. Менеджер программ (Program Manager) Управляешь не одним проектом, а группой взаимосвязанных проектов. Цель — не просто сдать каждый по отдельности, а получить общую выгоду. Что меняется: больше координации, зависимостей, стейкхолдеров. Навыки: управление портфелем, стратегическое планирование, работа с рисками на уровне программы. 4. Руководитель проектного офиса (PMO Head) Ты отвечаешь за методологию, стандарты, зрелость проектного управления в компании. Что меняется: меньше проектов, больше людей и процессов. Навыки: методология, обучение, политика, бюджетирование, управление изменениями. 5. Менеджер доставки (Delivery Manager) Роль из IT/Agile. Отвечаешь за поток поставки, команды, процессы. Не столько «управляешь проектом», сколько создаёшь условия, чтобы команды работали эффективно. Что меняется: фокус на людях и процессах, а не на задачах. Навыки: Agile, DevOps, управление потоком, метрики, фасилитация. 6. Agile-коуч Помогаешь командам и организациям внедрять Agile, обучаешь, фасилитируешь, менторишь. Что меняется: ты не управляешь проектом — ты учишь других. Навыки: глубокое знание Agile, коучинг, организационные изменения, терпение. 7. Консалтинг Внешний эксперт. Проекты разные, компании разные, задачи разные. Что меняется: больше адаптации, меньше стабильности. Навыки: быстрая обучаемость, методология, продажи, коммуникации. Как не застрять на одном уровне: Постоянно учись. Стандарты, инструменты, технологии — всё меняется. Бери сложные проекты. Если всё получается — значит, ты не растёшь. Развивай soft skills. На senior-уровне решают не знание процессов, а умение договариваться. Строй социум вокруг себя. Карьерные возможности часто приходят через людей из других компаний, направлений и отраслей. Меняй роли. Иногда шаг в сторону (в продукт, в консалтинг) даёт больше, чем вертикальный рост. Главное: тупик — это не отсутствие вариантов. Это отсутствие решения. Выбирай направление, развивай навыки и не бойся выходить за привычные рамки. Рост начинается там, где заканчивается накатанная колея. #УправлениеПроектами #Карьера #PMO #Развитие

Проект и продукт: в чём разница и почему все путают «Мы запустили проект по продукту», «продуктовая команда ведёт проект». Знакомо? Проект и продукт, часто эти два слова используют как синонимы. А потом выясняется, что получили "бесконечный" проект. В чем разница? Проект — временное предприятие, создающее уникальный результат. Есть цель, сроки, бюджет, начало и конец. «Разработать CRM для заказчика», «построить дом», «провести конференцию». Проект заканчивается, когда результат передан заказчику и подписан акт. Продукт — это результат, который живёт долго и развивается. У него есть жизненный цикл: идея, создание, рост, зрелость, упадок. «CRM-система, которую мы продаём», «мобильное приложение», «автомобиль». Продукт не заканчивается — он эволюционирует. Им управляет product manager, а не project manager. Ключевые различия: Цель. Проект направлен на создание уникального результата — конкретного продукта, услуги или иного артефакта, который должен быть получен по завершении. Продукт же нацелен на развитие и принесение ценности на протяжении всего своего существования, он не ограничивается однократным созданием, а постоянно адаптируется и улучшается. Время. Проект всегда временный: у него есть чёткое начало и финиш, после достижения цели он завершается. Продукт, напротив, существует длительно, проходя через жизненный цикл — от идеи и создания до роста, зрелости и eventual снятия с поддержки; он не имеет фиксированной даты окончания. Управление. Проектом управляет Project Manager, который отвечает за достижение целей в рамках ограничений по срокам, бюджету и качеству. Продуктом управляет Product Manager, чья задача — определять, что именно нужно рынку, и обеспечивать долгосрочное развитие продукта. Фокус. В проекте основной фокус — «сделать в срок и в бюджет», то есть эффективное выполнение запланированных работ. В продукте фокус смещён на «делать то, что нужно рынку» — на удовлетворение потребностей и создание ценности, даже если это требует изменения первоначальных планов. Метрики. Успех проекта измеряется сроками, бюджетом и качеством выполнения работ. Успех продукта оценивается рыночными показателями: выручкой, удержанием пользователей, лояльностью потребителей (например, NPS) и другими метриками, отражающими ценность для клиента. Окончание. Проект считается завершённым, когда подписан акт выполненных работ и результат передан заказчику. Продукт же не заканчивается подписанием акта — он живёт до тех пор, пока не будет снят с поддержки, что может произойти через годы или даже десятилетия после его создания.   Почему происходит подмена понятий? Тренд на "product mindset". Все хотят быть «продуктовыми». Даже если делают уникальный проект для одного заказчика. Полагают что считаться «продуктовой командой» престижнее, чем «проектной». Пересечение ролей. В agile-командах product owner часто выполняет административные функции, что сродни project manager. Отсюда путаница. Незнание терминологии. Люди не читали ни стандартов по управлению проектами, ни стандартов по управлению продуктом. Им кажется, что «продукт» на данный момент звучит солиднее. Организационные причины. Нет чёткого разделения ролей и зон ответственности. Один человек может быть и PM, и product manager. Последствия? Product manager пытается управлять проектом, но не умеет строить календарный план. Метрики смешиваются: проект закрыли «в срок», а продукт не взлетел. Ресурсы распределяются неэффективно: продуктовая команда тратит время на проектные задачи. Проект и продукт — разные сущности. Проект создаёт продукт. Продукт живёт дальше. Если вы не уверены — задайте вопрос: «У этого есть финиш?» #УправлениеПроектами #PMO #Продукт #Проект #ProductManagement