#Обучение

Всем привет!
Вдогонку к вчерашнему списку - вы уже видели новое обучение от GoogleНавыки - если нет - быстрее регистрируйтесь - это бесплатное обучение digital инструментам (основы интернет-маркетинга, перевод бизнеса в он-лайн, способы продвижения и др). Если кто-то уже начала, делитесь первыми впечатлениями? как по мне, темы очень актуальные, обучение удобно разбито на небольшие модули, есть доп. материалы, правда сама платформа пока «сыровата». Ссылка тут: https://learndigital.withgoogle.com/skills-ru/courses

#ценности
Всем привет. Очень крутой пост от человека, которого вы вряд ли читаете в инсте - хочу с вами поделиться и спросить - а какой у вас рассол?

#цели
Всем привет! Собрала для вас мини конспект по классному методу постановки цели. Надо же чем-то на НГ заняться 🎄🎄🎄
Метод называется:

Grow

Вот в чем его основная суть (сразу скажу методика дополнена моими лайфхаками) - последовательно отвечайте на вопросы, при необходимости, возврпщайтесь к вопросом и к корректируйте ответы.
В качестве цели вы можете выбрать абсолютно все, для примера возьмём цель о получении желанной должности (очень важно, чтобы она была конкретной: например, руководитель проектно но офиса в Яндекс)
Очень советую в день выполнять по 1 шагу, каждый шаг смотри на отдельной картинке. Картинки естественно собственного сочинения 😂😂😂

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

Всем привет и с наступившим 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 тыс. руб. или завершит проект в срок, но не выполнит дополнительное требование?

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

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

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