#управлениеПроектами #теория

Всем привет и с наступившим 2021 годом! 🍾🎄🍾🍾🍾🎄

Надеюсь, в новый год у вас не было несварения от всех этих итогов года и успешных успехов других людей ;)

Я тоже решила немного отдохнуть до и после нового года, устроить отдых от соц сетей и немного прийти в себя. А вот до рабочей недели 📆 осталась ровно неделя и я хочу наполнить её для вас ежедневными погружениями в области знаний проектного управления.

Что это такое? 🤷🏼‍♀️

Если не вдаваться в сухие определения PMBok, то область знаний - это любая сфера, которой управляет руководитель проекта, она включает в себя шаблоны, которые использует РП (например, шаблон сметы проекта), инструменты (к примеру, мозговой штурм для определения рисков), входящую информацию (без расписания не составить стоимость) и выходные результаты (например, устав проекта).

📚Всего выделяют 10 областей знаний :

1️⃣ Управление интеграцией
2️⃣ управление содержанием
3️⃣ управление расписанием
4️⃣ управление стоимостью
5️⃣ управление качеством
6️⃣ управление ресурсами
7️⃣Управление коммуникациями
8️⃣Управление рисками
9️⃣Управление закупками
🔟Управление заинтересованными сторонами

С завтрашнего дня мы будем последовательно разбирать ключевые аспекты каждой области

А пока напишите в комментариях, кто в каком городе сейчас находится и делитесь фотками) я вот лечу домой в Питер! Не была там уже больше месяца, очень соскучилась )

#УправлениеПроектами #Теория #Интеграция

Всем привет!

Начинаем серию 10-ти дневных постов о проектных областях знаний. Напомню (из вчерашнего поста), что область знаний - это любая сфера, которой управляет руководитель проекта, она включает в себя шаблоны, которые использует РП (например, шаблон сметы проекта), инструменты (к примеру, мозговой штурм для определения рисков), входящую информацию (без расписания не составить стоимость) и выходные результаты (например, устав проекта). Перечень областей знаний есть в прошлом посте 👆🏻

⛓Управление интеграцией
Сегодня мы с вами начинаем разговор про Управление интеграций - пожалуй, это самая очевидная и, вместе с тем, самая непонятная на первый взгляд область.
Как вы думаете, какая основная задача руководителя проекта?… прервитесь в этом месте и попробуйте ответить про себя на этот вопрос. Если в голову приходят мысли из серии - объединить все части проекта в единое целое, чтобы достичь основной цели проекта - вы абсолютно правы! 🎆

Процессы управления проектами не происходят самостоятельно. Например, для расчета бюджета проекта необходимо составить расписание и оценить риски, а любое новое требование Заказчика может повлиять на качество продукта/ сроки или стоимость проекта. Руководителю проекта необходимо анализировать любое изменение в проекте на предмет влияния на все остальные сферы

Что важно знать и понимать в интеграции:

1️⃣ Разработка Устава проекта - самый первый документ проекта. Документ на 2-3 листа А4
☢️Функции: легитимизировать проект!!!! Определить Заказчика, дать ПОЛНОМОЧИЯ РП, определить цель проекта, связанную со стратегией организации и основную выгоду. Очень важно: любое изменение устава должно ставить под сомнение целесообразность продолжения вашего проекта.
💡Вариативно: подсветить ВЕРХНЕУРОВНЕВЫЕ оценки сроков, бюджета, рисков

2️⃣ Разработка Плана управления проектом - БОЛЬШОЙ документ, в котором должно быть описано: что и как вы будете делать в проекте.
☢️Функции: определить правила игры в вашем проекте и спланировать все и вся
💡что пишем в документе: как будем планировать (читай: как будем планировать планирование проекта😂), что будем планировать, с кем, по каким форматам, какой подход (конфигурацию) проекта будем использовать: waterfall или agile, что будем делать потом, ну и собственно планировать каждую область проекта. Это не формальный документ для Заказчика - это ваша собственная «библия» в проекте, которая описывает, как будет происходить проект, с кем и кто чем будет заниматься.

3️⃣Руководство и управление работами проекта - наконец-то начинаем руководить 😂
☢️На самом деле здесь вы и ваша команда начинаете осуществлять все то, что написано в Плане управления проектом.
Особое место отводится управлению вашей командой: ваша задача как РП - быть ПОЛЕЗНЫМ для команды, помогать им завершать свои задачи, обеспечивать единое понимание задач проекта между всеми заинтересованными сторонами, ограждать от несвязанных с целями проекта задач.
🛠Ваши основные инструменты: план-график проекта, перечень изменений в проекте, проведение статусных и рабочих совещаний, система управления проектами (если есть), журнал проблем или открытых вопросов

4️⃣ Управление знаниями проекта - это очень тонкий момент, которому, к сожалению, редко отводится должное внимание.
Конечно, PMBOK нас учит документировать все и вся: каждую запятую, каждые варианты решения проблемы, каждые изменения, которые происходят в проектах - очень часто на это элементарно не хватает времени (попробуйте ка вести хронометраж проектных активностей хотя бы 2-3 месяца…)
🆘 НО! ключевые решения, в особенности об изменениях содержания, расписания, бюджета, качества должны быть обязательно задокументированы , а иногда еще и утверждены уполномоченными органами в проектах (к примеру, Управляющими комитетами). Не забывайте также фиксировать решения, которые привели к хорошим/ эффективным результатам - это поможет будущим РП или проектам.

ПРОДОЛЖЕНИЕ

🌟 и еще одна ключевая задача РП: обеспечить распространение, обмен информацией и накопленными знаниями на проекте. Это могут быть внутренние порталы, на которых вы выкладываете документы проекта; чаты в соц. сетях с основными изменениям в проектах; общие календари с основными мероприятиями по проекту.
💡ОДнако не забывайте и о законодательных требованиях: защита персональных данных, соблюдение соглашений о конфиденциальности, работа с коммерческой тайной.

5️⃣Контроль и мониторинг работ - сравни план с фактом и сделай выводы!
В это части мы как раз готовим отчеты о статусе проекта, предлагаем различные улучшения к проекту или мероприятия для устранения отклонений.
☢️Если намечается любое изменение в проекте (например, Заказчик захотел реализовать дополнительный функционал в программе). Функции РП - оценить влияние любого изменения в проекте на все области знаний, проверить на предмет соответствия цели проекта, составить итоговое заключение и согласовать с уполномоченными лицами, проинформировать заинтересованные стороны. Пожалуйста, не нарушайте эту последовательность!

6️⃣Завершение проекта - ура! ты совсем близок к своей цели и закрытию проекта, но не торопись: аккуратно закрой все контракты, собери и положи всю документацию по проекту в нужное место, собери итоговое совещание по закрытию проекта с заинтересованными сторонами для приемки всех работ и результатов проекта. Проведите сессию извлеченных уроков. И Если все гуд - Поблагодари команду за проделанную работу и ОБЯЗАТЕЛЬНО отметьте достигнутые результаты вместе с командой🍾)))

на сегодня все, получилось достаточно много, т.к. эта область знаний безгранична и включает конечно в себя очень много лайфхаков, но, думаю, для первого раза более, чем достаточно. Все эти вопросы мы подробно разбираем на курсе Основы управления проектами, узнать , когда будет следующий поток или приобрести записи, можно тут

Если есть вопросы или дополнения пишите в комментариях👇🏻

Перейти к следующей области знаний. Управление содержанием

#УправлениеПроектами #Теория #Содержание

Всем привет!

Продолжаем серию из 10-ти дневных постов о проектных областях знаний. Перечень областей знаний есть в прошлом посте 👆🏻а сегодня собственно о Содержании - будет покороче, чем по интеграцию, чтобы вас сильно не грузить))) наверняка вы сейчас гуляете по городу, пьете глинтвейн или проводите время с семьей))))

Поехали 🚀🚀🚀

Итак, основная задача управления содержанием - определить то, что вы будете делать в проекте, задать границы проекта (это называется scope проекта) и четко соблюдать обозначенные границы.

В традиционных ИТ проектах в эту область могут входить такие активности как обследование бизнес -процессов, разработка методологических документов, подготовка технического задания для проведения тендера и далее создание прототипов.
В digital проектах могут проводиться UX/UI исследования, в agile проектах - составляться user stories и прочее

🆘Очень важный аспект в этой области : собрать верные требования, явные и скрытые. но для этого важно грамотно определить заинтересованы стороны. Очень часто встречается следующая история: ИТ систему внедрили, а она "не летит", потому что конечных пользователей никто не спросил о том, как им будет удобно работать. Или ещё из классики: начать рассказывать пользователям про новую систему перед запуском - люди первый раз об этом слышат и начинают "раздувать" границы проекта дополнительными хотелками.

Вот тут вернемся на шаг назад и поговорим о том, как работать с новыми требованиями, как их ограничивать и как расаознать то, что действительно нужно. Перед тем, как начать собирать требования, определи, какие вообще требования ты будешь собирать, по каким критериям они будут утверждены, а какие - отклонены. Требования Обязательно должны соответствовать цели проекта. Все это можно описать в плане управления проектом (см прошлый пост про интеграцию).

Давай на примере?
если основная цель вашего проекта - повысить продажи в интернет магазине, вряд ли вы должны брать в работу требования менеджеров по продажам по улучшению интерфейса их рабочего стола и скорее всего наиболее полезным будут UX/UI исследования.

Следующая история - это подготовка ИСР - иерархическая структура работ. В agile проектах обычно представляет собой набор пользовательских историй.
🌟 важно : ИСР - это все то, что вы будете делать в проекте - визуализация границ проекта. Может быть в виде канбан-доски, большого ватмана, доски со стикерами.
🗂Группировка работ может быть по этапам проекта / по функциональным характеристикам/ по ключевым заинтересованными. Основная ценность в том, что команда проекта и любые заинтересованные стороны могут подойти к доске и посмотреть, что мы делаем в объёме проекта, а чего не делаем.

И теперь давайте подведем итог в виде последовательности действий:

1️⃣ определяем, какие требования будем собирать - пишем это в плане управления проектом
2️⃣ выбираем способ сбора требований (обследование, анкетирование, интервью, опросы, дизайн -мышление, мозговой штурм, отображение данных, экспертная оценка и др) + выбираем тех, с кем их будем собирать
3️⃣ проводим сбор требований, фиксируем в виде документов + составляем визуальную ИСР, проверяем на соответствие целям и задачам проекта. Обязательно обсуждаем с командой - создаём единое информационное пространство
4️⃣ утверждаем список требований с заказчиком
5️⃣ переходим к составлению расписания, но об этом завтра))

Все эти вопросы мы подробно разбираем на курсе Основы управления проектами, узнать , когда будет следующий поток или приобрести записи, можно тут

Как всегда, если есть вопросы - буду рада ответить 👇

Перейти к описанию следующей области управления проектами. Управление расписанием

Пример ИСР

#УправлениеПроектами #Теория #Расписание

Всем привет!
мы с вами подошли к 3-й области знаний проектного управления - РАСПИСАНИЕ 📆
Напомню, что перечень областей знаний есть в прошлом посте 👆🏻

Поехали 🚀🚀🚀

Управление расписанием - это, пожалуй, одна из самых понятных и, как следствие, самая хорошо-управляемая область проектного управления. Что мы тут делаем?
Все просто: составляем расписание проекта, контролируем его исполнение и мониторим план-факт.

Поэтому сегодня я напишу скорее о том, что иногда забывается руководителями проекта.

1️⃣ Анализ альтернатив. После того, как вы определили, что вы будете в проекте делать и даже назначили ресурсы для выполнения задач подумайте, а действительно ли это самый оптимальный способ выполнения с точки зрения длительности/ стоимости/ объема задействованных ресурсов/ соблюдения требований компании? К примеру, вы собираетесь включить в команду проекта разработчика для интеграции вашей системы с широко-распространенной системой гос. органов. Как вы думаете, у кого компетенции и опыта больше: у вашего программиста или у ИТ-агентства, которое занимается настройкой интеграций системы гос. органов?
Или вот еще: вы хотите с нуля писать систему для ведения бухгалтерского учета на Предприятии? Зачем? если есть уже написанные готовые программы, которые прошли неоднократное внедрение, настройку и апробацию и за счет эффекта масштаба, вам могут предложить адекватную стоимость за эту систему.


2️⃣ Сжатие расписания - в практике проектного управления так называются варианты оптимизации/ сокращения расписания. Представьте, что вас просят сократить длительность проекта на 2 месяца. В принципе, у вас всегда 2 варианта:
🌟либо добавить ресурсы на выполнение последовательных работ и сократить длительность каждой, но при этом вы увеличиваете стоимость проекта
🌟либо запараллелить работы, но при этом вы увеличиваете риски своего проекта
Не забывайте, пожалуйста, про эти ограничения и обязательно оценивайте каждый из этих вариантов при защите расписания у Заказчика.
Хорошее видео на этот счет

3️⃣ после того, как определены работы, назначена длительность и ресурсы, выбрана наилучшая стратегия реализации каждой работы составь итоговое расписание.
Инструмент может быть любым: Excel, Project и др - здесь останавливаться не буду, писала целый пост на этот счет в инсте

🆘но вот что важно: расписание это не всегда «диаграмма Ганта» (например, разработка Технического задания будет проводиться с 1-10 февраля 2020 года), ты вполне можешь составить список контрольных точек проекта с указанием финальной даты (к примеру, Техническое задание должно быть готово не позднее 10 февраля) - это еще называется вехами проекта. Также по набору достигнутых вех проекта можно отлеживать % выполнения Плана-графика и эта форма обычно ОЧЕНЬ нравится Руководителям - ее можно использовать для отчетных совещаний. А вот для планирования подойдет не всегда… В каких случаях ее можно использовать:
🌟у тебя немного работ
🌟большинство работ выполняет один исполнитель и их загрузка не связана между собой
🌟работы по большей части не связаны друг с другом
🌟длительность проекта примерно 3-6 месяцев
Пример диаграммы контрольных точек прикреплю скрином ниже

4️⃣ Следующий пункт навеян недавними консультациями по устройству на работу 😂😂😂. Вне зависимости от того, какую форму составления расписания ты выберешь, есть негласная прописная истина: расписание должно быть структурным, с выделением этапов проекта (группировка работ), с обозначенными ресурсами, с указанными зависимостями между работами, с указанием вех проекта, очень хорошо воспринимаются Заказчиком индикаторы о каждой работе проекта (красно-желто-зеленые), которые формируются автоматически в зависимости от даты. Поверь, визуальная часть может очень многое рассказать о квалификации РП. Именно поэтому при приеме на работу часто просят составить план-график проекта. Удели этому особое внимание. Сомневаешься - обратись к специалисту;)

ПРОДОЛЖЕНИЕ ->>>>>>>>

5️⃣Ну и last but not least. Контролируй план-факт исполнения расписания проекта ежедневно или еженедельно в зависимости от состава проекта.
Твой идеальный статус проекта (например, еженедельный) должен строиться примерно по такой структуре:
🌟обзор выполненных за неделю работ.
🌟разбор причин невыполнения работ и предложений по «наверстыванию» графика с фиксацией итогового решения
🌟план задач на следующую неделю
🌟обзор зафиксированных на прошлом статусе поручений и при необходимости фиксация добавленных задач в план график.

Все эти вопросы мы подробно разбираем на курсе Основы управления проектами, узнать , когда будет следующий поток или приобрести записи, можно тут

Как всегда, если есть вопросы - буду рада ответить 👇

Перейти к описанию следующей области управления проектами. Управление стоиомстью

Пример диаграммы контрольных точек

💰💰💰
#УправлениеПроектами #Теория #Стоимость

Всем привет!
Сегодня 4-я область знаний проектного управления - Управление стоимостью
Напомню, что перечень областей знаний есть в прошлом посте 👆🏻

Многие в этом чате со мной после обучения на GeekBrains, а там я как раз веду курс о Финансовом менеджменте на проекте и вроде бы что еще рассказывать об этой теме 😂😂😂 но, конечно, это одна из самых сложных, объемных областей знаний, которая в зависимости от компании и проекта включает в себя совершенно разные термины, понятия и определения.

И как всегда постараюсь рассказать вам не только об основных процессах управления стоимостью, но и о лайфхаках в этой области
Поехали 🚀🚀🚀

Давай для начала представим, что твой Подрядчик приносит тебе смету на проверку. На что ты обратишь внимание? какие вопросы задашь? какие показатели тебе наиболее важны? Давай на этом примере разберемся детально:

1️⃣Попросите показать детальный план-график выполнения работ (чем детальнее, тем лучше) с указанием объема задействованных ресурсов и их ставок. Основные моменты про расписание проекта и что там важно были в предыдущем посте 👆🏻 График работ - это основной документ, на основании которого рассчитывается смета или бюджет проекта, т.к. он дает понимания о работах проекта, ресурсах (людях, материалах, оборудовании), длительности выполнения проекта.

💡Не поленитесь и детально изучите план график, найдите 1-2 понятных для себя работы, оцените задействованные ресурсы и поговорите об этом с Подрядчиком, ну или попросите ваших экспертов провести подобную работу
🔴 к примеру, если в разработке Плана управления проектом не задействованы ключевые участники от Подрядчика и все делает один РП - явно хорошего результата вы в проекте не получите; Если в ПГ не присутствуют работы по установке ПО или оборудования, на основании чего тогда они включены в смету проекта? ну и т.д….

2️⃣ Оцените структуру проектной сметы - вариаций, конечно, много и, возможно, шаблон у вас в компании установлен, но посмотрите, какие статьи затрат выделены (например, здорово, когда отдельно выделяется стоимость привлечения команды, стоимость оборудования или ПО, командировочные расходы, особо круто выделение стоимости на управление проектом: Руководитель и администратор проекта).
💡под каждую цифру в смете у РП должна быть расшифровка, смело спрашивайте, как получена стоимость ПО, проведен ли сравнительный анализ наиболее оптимальной стоимости
✅ но имейте ввиду, что Подрядчик в праве не раскрывать рентабельность, т.е. сколько он на вас зарабатывает или другие показатели, например, нормы командировочных расходов, тут ваша задача согласовать основные метрики, к примеру, количество дней присутствия консультантов или очных совещаний.
🔴 если смета представляет собой набор несвязанных задач, не прозрачна по структуре, а подрядчик на каждый вопрос отвечает, что оценка получена экспертным путем - шлите лесом переделывать.

3️⃣Попросите Подрядчика рассказать об аналогичных проектах и их стоимости, реализованных для других Заказчиков, или проведите такой анализ самостоятельно Только так вы сможете сделать вывод о «справедливости» цены.
✅ В идеале Подрядчик приведёт хотя бы 2-3 аналогичных проекта, отметит нюансы вашего проекта, расскажет о проблемах, которые были в прошлых проектах, и подсветит особенности вашей сметы
🔴 подрядчик скажет, что ваш проект уникальный, но он все очень детально и точно рассчитал - ну- ну, опять же идет лесом…

4️⃣ Спросите, какой объём в структуре стоимости заложен на управление рисками. Риски, вернее их перекладывание на Подрядчика, зачастую является основной причиной привлечения Подрядчика))) Они всегда присутствуют в бюджете проекта, но самый большой вопрос - в каком объеме и почему именно столько…
✅ Подрядчик приведёт зафиксированные риски, расскажет о стратегии работы с рисками и скажет, что к примеру 10-15 % в стоимости предусмотрено в качестве резерва на риск.

ПРОДОЛЖЕНИЕ->>>>>>>

🔴 Подрядчик сделает удивленные глаза или назовёт цифру в 5-10% от стоимости. В этом случае можете считать, что в вашей цене сидит примерно 40-50% «надбавки» вместо реально проработанных рисков. Как делает часто-встречающийся РП: к примеру, разработчик называет срок разработки - 5 дней, РП закладывает - 10 и так по каждой задаче - это вкорне неверный подход. Стоимостные резервы НЕ должны закладываться в каждую работу. Все риски должны быть зафиксированы и оценены в денежном эквиваленте (но об этом поговорим в 8-м посте)

5️⃣ Если вы уже все согласовали и перешли к реализации проекта, важным этапом управления стоимостью является Мониторинг сметы. Заранее договоритесь с Исполнителем или Заказчиком, какая будет форма мониторинга, какая периодичность и какие показатели являются ключевыми. К примеру, это может быть методы освоенного объема (обычно применяется в строительстве и классических ИТ-проектах) - если кратко суть его в том, что мы не просто смотрим, сколько денег мы потратили, но и то, на сколько это соответствуют плану выполненных работ. Еще одним показателем может быть конверсия (в digital проектах), когда вы запускаете интернет магазины или странички в инстаграмм и смотрите, сколько реальных продаж вы сделали - иногда от этого показателя Исполнитель получает свой %.

ВЫВОД: В целом, если вы являетесь разработчиком сметы, а не согласующим - задайте себе те же самые вопросы, начиная с 1 пункта, и имейте ввиду: вы должны нести ответственность за каждую цифру в вашей смете! Если вы не можете ее обосновать - лучше не отправляйте ее своему руководителю или Заказчику

Делитесь в комментариях, что думаете и какие у вас лайфхаки по снижению стоимости сметы 👇🏻

Более подробно эту область знаний мы разбираем на практикумах по проектному управлению (доступны в записи):
Как составить бюджет/ смету проекта
Как оценить экономические эффекты проекта
Как составить экономическую модель проекта и рассчитать окупаемость

#УправлениеПроектами #Теория #Качество

Даже у меня есть темы, о которых я не очень люблю говорить и сегодня как раз такая тема - управление качеством.

Давайте для начала определим, что такое качество проекта или продукта - в общем случае это соответствие заранее установленным параметрам или требованиям,
🌟для ИТ систем часто применятся такие показатели, как быстродействие, время отклика, объем баз данных и т.д.
🌟Для производственных систем у вас может мониториться % бракованных изделий, соблюдение Гости т.д.
🌟Также под качеством проекта может подразумеваться и качество выстроенных процессов внутри проекта/ организации для своевременного выявления дефектов/ проблем.

Все эти параметры обусловлены либо стандартами качества (например, ГОСТ в строительстве, производстве пищевой продукции) или требованиями Заказчика. Для начала вам нужно их выяснить, зафиксировать и определить критерии приемки результата, чтобы при сдаче проекта не услышать от Заказчика: «это не тот результат, которого мы ждали, мы не можем его использовать», а дальше начинается составление планов достижения этих показателей, реализация планов, мониторинг и контроль и подведение итоговых замеров, насколько ваша система соответствует этим параметрам.

Общая схема управления качеством выглядит так:
1️⃣На этапе инициации Заказчик определяет требования к продукту, РП собирает все стандарты и политики, которым также должен соответствовать продукт
2️⃣На этапе планирования
◦ Команда уточняет эти требования и определяет, что нужно сделать в проекте
◦ РП разрабатывает план управления качеством (кто, что и когда делает, какие процедуры проверки качества будем использовать, с какой периодичностью) и синхронизирует его с остальными планами (сроки, деньги, др)
3️⃣ На этапе реализации
◦ команда проводит контроль качества разработок в соотв. с планом (например, тестирует программный код перед сдачей Заказчику на предмет соответствия требованиям) - чек-лист тестирования ИТ-системы забери тут
◦ отдел качества контролирует соблюдение плана по качеству (например, проектный офис проверяет наличие протоколов внутреннего тестирования, подписанного тестировщиками)
4️⃣ На этапе мониторинга Заказчик проверяет продукт на предмет соответствия заявленным требованиям (тестирует решение) и в случае успеха - принимает работы

🌟ТОП 5 советов:
1. В каждом проекте вы управляете качеством, когда что-то проверяете. перед тем, как что-то проверять, напиши, КАК проверять
2. Лучше предотвращать, чем устранять
3. Не надо делать лучше, если вас об этом не просили - это передайте проектной команде
4. постоянно ищите способы, как повысить эффективность процессов управления проектом/ разработки кода/ проведения совещаний
5. за качество отвечает каждый участник проекта

🆘А теперь Давайте сразу к ключевому и основному, что вам нужно запомнить и на этом мы пожалуй на сегодня закончим, чтобы не мучать и меня и вас 😂

Как вы знаете, в проекта есть треугольник ограничений - стоимость, расписание, содержание. Представьте, что это ваши вершины треугольника (рисунок будет ниже). В проектном управлении есть одна простая аксиома: при изменении любой вершины (к примеру, увеличение содержания или при снижении стоимости) обязательно изменяются и другие вершины, а какая-то из свершил невозможна к изменению (к примеру, проект нужно реализовать к 01.01.22), поэтому вы как Руководитель проекта всегда должны находить компромисс и наиболее важные параметры для проекта.
Что выберет Заказчик: реализацию дополнительного функционала и увеличение сроков проекта на 2 неделю + 500 тыс. руб. или завершит проект в срок, но не выполнит дополнительное требование?

✅ так вот - основной вывод сегодняшней темы в том, что какие бы вы параметры проекта не меняли, вы никогда не должны СНИЖАТЬ утвержденное качество вашего продукта и стараться удержать его наиболее «круглым»!

Все эти вопросы мы подробно разбираем на курсе Основы управления проектами, узнать , когда будет следующий поток или приобрести записи, можно тут

Следующая область управления проектами
Управление коммуникациями

Привет, 102 подписчика!))) 🎉

За сегодняшнюю ночь нас стало немного больше, чем 1️⃣0️⃣0️⃣)

Спасибо вам, что вы со мной, надеюсь, канал для вас полезен. Еси у вас есть ребята, которые интересуются проектами, крутыми мероприятиями и личной эффективностью - приглашайте в чат, буду вам очень признательна.

В чате закрепила 3 поста: о себе, о навигации по хэштегами и о теме блога на январь - области знаний проектного управления.

🌟Проектный менеджер VS менеджер продукта?

#интересныеМероприятия #проекты #продукты

Кто все эти люди и какая в них разница? Судя по опросам примерно 20% не понимают разницы. И это нормально и вполне объяснимо - во многих компаниях эти функции перемешены, либо используются не по назначению.

🗣Я объясню просто на примере
Давайте представим, Вы - менеджер продукта, например в он-лайн школе, вам поставлена задача сделать ПРОДУКТ - сайт для взаимодействия преподавателей и учеников, да еще так, чтобы он он-лайн школе прибыль приносил и имел внешний, удобный, классный интерфейс.

И вот вы хватаетесь за голову и начинаете думать, что же такого можно на этом сайте сделать, изучаете потребности будущих пользователей, выбираете платформу, считаете экономические эффекты и в итоге решаете для запуска привлечь Менеджера проекта (неважно: внутреннего, внешнего) для реализации ПРОЕКТА по созданию сайта.

📆 У менеджера проекта задача понятная и ограниченная определенной целью и во времени: к 1 июня запустить сайт с заявленным функционалом.

И вот 1️⃣ июня вы получаете готовый сайт , но дальше вам, как менеджеру продукта, предстоит поддержка и развитие ПРОДУКТА: внимательно следить за работой сайта, реагировать на внешние и внутренние изменения с целью обновления сайта; контролировать, чтобы заявленные эффекты действительно были достигнуты и, что самое главное, но редко используемое - вовремя принять решение о выводе вашего сайта из эксплуатации или замене его на более крутую версию.

А дальше все по спирали и этому может даже не быть ни конца ни края (ну вот такая доля у менеджера продукта). На этом нашему примеру конец, а кто слушал…т.е. Читал + 500 к карме 🙏

#управлениеПроектами #теория #коммуникации
💜Это Моя самая любимая область управления проектами и, если вы хотите стать хорошим руководителем проекта, полюбите её тоже.

Естественно, речь пойдет не только про общение, разговоры, обсуждения и совещания

Задумайтесь над следующей ситуацией : вы встречаете в коридоре руководителя смежного подразделения, который интересуется, когда вы планируете запускать в продуктив вашу систему. Вы называете дату, а он просит вас направить все документы по проекту

Что бы вы подумали?
⁃ какого художника?
⁃ кто это вообще?
⁃ У меня его вообще в проекте нет
⁃ Блин, придётся тратить время и потом отвечать на вопросы по документам

Бывало у вас такое? Наверняка да! Первое, о чем вы должны подумать : почему он интересуется проектом и соответственно почему он вовремя не получил необходимую - скорее всего вы не идентифициррвали его как заинтересованных сторону, не учли его требования, как следствие, придется проводить доп работы. Оно вам надо?

Итак, Основная задача управления коммуникациями - обеспечить единое информационное пространство для вашего проекта, а всех заинтересрванных лиц - нужной информацией

Самый главный документ здесь - план коммуникаций, который обычно состоит из описания того
🌟какие совещания/встречи /звонки /статусы/ информационные сессии/ публикации вам нужно провести
🌟в каком формате (очно, заочно)/ какая периодичность
🌟кто ответственный
🌟с кем (кто должен быть на совещании или кто должен быть получателем информации )
🌟какая цель каждой коммуникации

А вот еще топ 5 лайфхаков для составления и исполнения классного плана коммуникаций:

1️⃣ Представьте все коммуникации как квадрат: они проходят внутри и снаружи проектной команды, а также в горизонтальном и вертикальном направлении. А теперь постарайтесь описать каждый из этих потоков.
Например, вертикаль вверх: в офис управления проектов РП будет 1 раз в неделю подавать отчет о статусе проекта в установленной форме (word). Горизонталь: команда обменивается статусом задач и открытыми вопросами на ежедневных стендапах и т.д.

2️⃣ коммуникации в проектах не всегда письменные и формальные. Постоять в курилке/ отметить ДР участника команды/ похвалить за крутую работу - это тоже коммуникация. Краткая шпаргалка о подходящих типах коммуникаций будет внизу в виде картинки

3️⃣ используйте правило 5С: любая коммуникация должна быть грамотной, емкой, с указанием цели, с логичным изложением мысли, и под контролем. Вам кажется эта рекомендация слишком очевидной? 😎А вы понаблюдайте за ближайшими своими или чужими коммуникациями и сделайте выводы - соблюдаются ли эти условия или нет.

4️⃣ Вспомним математику: если в проекте у вас 3 участника команды, то у вас 3 канала коммуникации. А если 4? Количество каналов рассчитывается по формуле n*(n-1)/2, т.е. При 4 участниках у вас Уже 6 каналов. А если 10 участников команды? - чтобы коммуникации оставались эффективными, Выделите 2 мини-руководителя групп (к примеру, ведущий программист и ведущий аналитик) и все коммуникации проводите с ними, а они в свою очередь - со своими 2-3 участниками.

5️⃣last but not least не стесняйтесь подтверждать получение информации - это касается и простых писем из серии: подтвердите, пожалуйста, получение письма. Я, к примеру, очень люблю писать письма с фразой kind remind и далее напоминание о том, что я ожидаю получить. Если речь про устную коммуникацию (особенно на удаленке) просите собеседника повторить как он понял вопрос/ поручение или попросите зафиксировать в виде мимо/ протокола

И напоследок: обязательно оценивайте, насколько эффективны ваши коммуникации (как часто вы встречаете таких руководителей смежного подразделения в коридоре или пересылаете статус-отчеты другим людям), оперативно корректируйте свои планы и постоянно ищите новых заинтересованных лиц и их возможные требования к коммуникациям. А про заинтересованные стороны мы с вами поговорим в последнем выпуске этой серии.

Все эти детали, шаблоны и примеры рабочих документов мы разбираем на семинаре «Инструменты проектного управления» (доступна запись)

#посмотреть #видео #управлениеРасписанием

Ежегодно пересматриваю это неимоверно милое видео про сетевое планирование и управление расписанием из Советского союза.

Столько прошло времени, а видео до сих пор актуально
Обязательно посмотрите, как будет время

Enjoy!
https://www.youtube.com/watch?v=xDp6xKOVJYE&t=977s

Еще больше информации про управление расписанием в проектах

#кейсыИзЖизни #проДоговоры

Включать ли Акт выполненных работ в результирующие документы по договору?

Давайте сразу на примере из жизни: у вас проходит опытно-промышленная эксплуатация системы (ОПЭ) и в договоре в качестве результата указан Акт выполненных работ. И вот Подрядчик запустил систему в ОПЭ и через 2 дня приходит к вам с актом выполненных работ на подписание? Можете ли вы его подписать? - очевидно нет, но, с другой стороны, юридически у вас нет необходимости сдавать другие документы.

И 2️⃣ вариант развития событий: в результатах этапа написано:
🌟Протокол проведения ОПЭ в течение 3-х месяцев
🌟Протокол устраненных замечаний по итогам ОПЭ

Чувствуете разницу? Тут уже через 2 дня к вам никто не придет и до тех пор, пока не будут подготовлены и подписаны с вашей стороны оба документа, Акт выполненных работ не может быть подписан.

ИТОГО: Акт выполненных работ - это бухгалтерский документ, который вы в любом случае обязаны подготовить при закрытии этапов работ, а вот конкретные результирующие документы дают вам сразу четкое понимание, что нужно сделать, а также позволяют избежать потенциальных разборок и споров в суде

☝🏻Кстати, имейте ввиду, что достаточно часто Поставщики предлагают договоры, по условиям которых, предоставление акта выполненных работ обязывает вас в течение какого-то срока⏰ (к примеру, 5 дней) его подписать или направить официальный отказ, а если вы вдруг этого не сделали, работы считаются принятыми. Поэтому обязательно внимательно читайте договор и согласовывайте его с юристами.

Подробности разбираем на семинаре «Тендеры и договоры» (доступны записи)

🚘Арендовать или покупать в проектах и в жизни?
#кейсыИзЖизни #бюджетПроекта

Пост как всегда навеян прошедшим обучением на курсе Финансовый менеджмент))
Новым студентам - привет)))

Сегодня немного поговорим о классификации статей затрат на CAPEX и ОРЕХ, которая всегда используется в организациях и при управлении проектами. Знать и понимать эти термины нужно для того, чтобы уметь ответить себе на вопросы

• Арендовать место в облачном хранилище или купить собственные сервера?
• Нанимать работников в штат или привлекать со стороны?
• Арендовать автомобиль или приобрести в собственность?

Объясню на простом примере из жизни:

🚘 Вы хотите водить машину и думаете, ЧТО именно выбрать: каршеринг или купить новенький порш (ну а что… сразу замахнемся на него).

Если у вас сейчас нет достаточной суммы денег 💰(хотя бы для первого взноса по кредиту) вам выгоднее использовать каршеринг (недорого, быстро, можно взять любую машину и вполне вашей цели удовлетворяет) - это будут ваши текущие (ОРЕХовые) затраты. Вы начинаете ездить, ежедневно тратите деньги на каршеринг, пару раз съездили за город и уже понимаете, что денег то уходит не мало, а скоро годовая премия, да еще и скидки на машины прошлого года и вы решаете купить пусть не Порше, но хотя бы хёндай. И вот вы выезжаете из салона на новеньком авто и теперь понимаете, что у вас уже появилась своя собственность, которую вы почти в любой момент и по предсказуемой цене можете продать - это ваш актив или CAPEXовые расходы. Это серьезная покупка, которой вы будете пользоваться больше года (если все-таки не решитесь на порш). Однако у вас появляются новые расходы - текущий ремонт, заправка, покупка ковриков, масла, обывателей, вонючек и т.д. И это опять ваши текущие расходы, т.е. OPEX

☝🏻К чему я все это: с точки зрения краткосрочного планирования всегда выгоднее иметь OPEXовые затраты (дешевле взять машину в аренду на несколько часов), но с т.з. стратегического мышления - выгоднее наращивать свои «активы», т.е. CAPEXовые затраты (когда у вас есть в собственности автомобиль вы понимаете, что у вас есть определенная «денежная подушка».

Чем больше у вас OРEХовых затрат, тем больше расходов приходится нести ежемесячно, плюс возникают непредвиденные/ нерегулируемым проблемы (нет поблизости нужной машины из-за высокого спроса, в карантин каршеринг закрылся и т.д.).
Однако и СAPEXоывые затраты также имеют свои минусы: машину надо заправлять, ремонтировать, и между прочим платить налог.

📌Вывод (вспомним о нашем выборе: каршеринг или покупка): решение принимать конечно вам, важно учесть не только затраты в моменте (покупка автомобиля), но и все сопутствующие затраты во время использования, и еще и не забыть про обесценение машины при продаже. А вот опыт, конечно, полученный после обладания автомобилем, вряд ли измеришь в денежном эквиваленте 😂

📒Ну и немного теории с практическими применениями в проектах:
• Капитальные затраты, или CAPEX (сокращ. от англ. capital expenditure), представляют собой затраты на приобретение активов (срок эксплуатации более 1 года - машина), а также на их модификацию (достройку, дооборудование, реконструкцию - замена Хендай на порш) и модернизацию. Пример из проектов: закупка ПО, оборудования, лицензий, привлечение внешнего консалтинга.

• Операционные затраты, или OPEX (сокращ. от англ. operational expenditure), представляют собой затраты компании, которые возникают в процессе ее текущей деятельности. Примерами операционных затрат являются: зарплата персонала, аренда помещений, представительские расходы, командировочные, затраты на обучение или обследование бизнес-процессов.

А какую модель предпочитаете вы - покупка или аренда квартиры/ машины/ оборудования? Делитесь в комментах к посту)