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

Карьерный тупик 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

Управление изменениями: когда заказчик настаивает, а договор с фикс. ценой Ни один проект не выполняется без изменений. Это нормально. Но что делать, когда договор с фиксированной ценой, а заказчик приходит с «маленькой доработкой», которая на деле переворачивает логику системы? 1. Проверьте договор. Прежде чем соглашаться или отказывать, задайте вопрос: этот запрос  соответствует какой-либо задаче в утвержденном перечне работ или нет? Если в договоре или приложения к нему нет четкого перечня задач и критериев приёмки — спор превращается в «я думал, что это включено» против «а я думал, что нет». Вывод 1. Внимательно отнеситесь к составлению договора. Все разночтения будут против вас. 2. Нет запроса = нет изменения. Каждое изменение — через формальный запрос. Даже самое «маленькое». Особенно «маленькое». Недокументированные изменения — самый быстрый путь к неконтролируемому размытию границ проекта. Вывод 2. Запустить на проекте формальный процесс «Управление изменениями» с самого старта. 3. Если бюджет нельзя изменить — измените что-то другое. Классическая ловушка: «Сделайте, но денег на это нет». В контракте с фиксированной стоимостью это означает одно — вы забираете бюджет у другой задачи. Варианты: заменить низкоприоритетную фичу, упростить решение. Вывод 3. Все задачи должны иметь приоритеты. Нужно понимать, чем можно пожертвовать. 4. Зафиксируйте компромисс письменно. Если заказчик настаивает, а бюджет фиксирован — это не «просто сделаем». Это управленческое решение с последствиями. Оформите его как согласованный обмен: «Мы делаем X, но Y отменяем». Без бумаги это останется вашей личной проблемой. Вывод 4. Всё что не задокументировано – будет забыто. 5. Не бойтесь эскалации. Если заказчик требует изменений, не готов платить и не готов жертвовать объёмом — это уже не проектный вопрос. Эскалируйте этот вопрос спонсору. Пусть решают на уровне, где есть полномочия менять контракт. Вывод 5. Возможно наверху договорятся и будет дополнительное соглашение на новый объем работ. Главное: фиксированная цена — это не «всё включено». Это фиксированный объём, срок и стоимость. #УправлениеПроектами #УправлениеИзменениями #FixedPrice #PMO #ChangeControl