#УправлениеПроектами #Теория #Качество
Даже у меня есть темы, о которых я не очень люблю говорить и сегодня как раз такая тема - управление качеством.
Давайте для начала определим, что такое качество проекта или продукта - в общем случае это соответствие заранее установленным параметрам или требованиям,
🌟для ИТ систем часто применятся такие показатели, как быстродействие, время отклика, объем баз данных и т.д.
🌟Для производственных систем у вас может мониториться % бракованных изделий, соблюдение Гости т.д.
🌟Также под качеством проекта может подразумеваться и качество выстроенных процессов внутри проекта/ организации для своевременного выявления дефектов/ проблем.
Все эти параметры обусловлены либо стандартами качества (например, ГОСТ в строительстве, производстве пищевой продукции) или требованиями Заказчика. Для начала вам нужно их выяснить, зафиксировать и определить критерии приемки результата, чтобы при сдаче проекта не услышать от Заказчика: «это не тот результат, которого мы ждали, мы не можем его использовать», а дальше начинается составление планов достижения этих показателей, реализация планов, мониторинг и контроль и подведение итоговых замеров, насколько ваша система соответствует этим параметрам.
Общая схема управления качеством выглядит так:
1️⃣На этапе инициации Заказчик определяет требования к продукту, РП собирает все стандарты и политики, которым также должен соответствовать продукт
2️⃣На этапе планирования
◦ Команда уточняет эти требования и определяет, что нужно сделать в проекте
◦ РП разрабатывает план управления качеством (кто, что и когда делает, какие процедуры проверки качества будем использовать, с какой периодичностью) и синхронизирует его с остальными планами (сроки, деньги, др)
3️⃣ На этапе реализации
◦ команда проводит контроль качества разработок в соотв. с планом (например, тестирует программный код перед сдачей Заказчику на предмет соответствия требованиям) - чек-лист тестирования ИТ-системы забери тут
◦ отдел качества контролирует соблюдение плана по качеству (например, проектный офис проверяет наличие протоколов внутреннего тестирования, подписанного тестировщиками)
4️⃣ На этапе мониторинга Заказчик проверяет продукт на предмет соответствия заявленным требованиям (тестирует решение) и в случае успеха - принимает работы
🌟ТОП 5 советов:
1. В каждом проекте вы управляете качеством, когда что-то проверяете. перед тем, как что-то проверять, напиши, КАК проверять
2. Лучше предотвращать, чем устранять
3. Не надо делать лучше, если вас об этом не просили - это передайте проектной команде
4. постоянно ищите способы, как повысить эффективность процессов управления проектом/ разработки кода/ проведения совещаний
5. за качество отвечает каждый участник проекта
🆘А теперь Давайте сразу к ключевому и основному, что вам нужно запомнить и на этом мы пожалуй на сегодня закончим, чтобы не мучать и меня и вас 😂
Как вы знаете, в проекта есть треугольник ограничений - стоимость, расписание, содержание. Представьте, что это ваши вершины треугольника (рисунок будет ниже). В проектном управлении есть одна простая аксиома: при изменении любой вершины (к примеру, увеличение содержания или при снижении стоимости) обязательно изменяются и другие вершины, а какая-то из свершил невозможна к изменению (к примеру, проект нужно реализовать к 01.01.22), поэтому вы как Руководитель проекта всегда должны находить компромисс и наиболее важные параметры для проекта.
Что выберет Заказчик: реализацию дополнительного функционала и увеличение сроков проекта на 2 неделю + 500 тыс. руб. или завершит проект в срок, но не выполнит дополнительное требование?
✅ так вот - основной вывод сегодняшней темы в том, что какие бы вы параметры проекта не меняли, вы никогда не должны СНИЖАТЬ утвержденное качество вашего продукта и стараться удержать его наиболее «круглым»!
Все эти вопросы мы подробно разбираем на курсе Основы управления проектами, узнать , когда будет следующий поток или приобрести записи, можно тут
Следующая область управления проектами
Управление коммуникациями
Даже у меня есть темы, о которых я не очень люблю говорить и сегодня как раз такая тема - управление качеством.
Давайте для начала определим, что такое качество проекта или продукта - в общем случае это соответствие заранее установленным параметрам или требованиям,
🌟для ИТ систем часто применятся такие показатели, как быстродействие, время отклика, объем баз данных и т.д.
🌟Для производственных систем у вас может мониториться % бракованных изделий, соблюдение Гости т.д.
🌟Также под качеством проекта может подразумеваться и качество выстроенных процессов внутри проекта/ организации для своевременного выявления дефектов/ проблем.
Все эти параметры обусловлены либо стандартами качества (например, ГОСТ в строительстве, производстве пищевой продукции) или требованиями Заказчика. Для начала вам нужно их выяснить, зафиксировать и определить критерии приемки результата, чтобы при сдаче проекта не услышать от Заказчика: «это не тот результат, которого мы ждали, мы не можем его использовать», а дальше начинается составление планов достижения этих показателей, реализация планов, мониторинг и контроль и подведение итоговых замеров, насколько ваша система соответствует этим параметрам.
Общая схема управления качеством выглядит так:
1️⃣На этапе инициации Заказчик определяет требования к продукту, РП собирает все стандарты и политики, которым также должен соответствовать продукт
2️⃣На этапе планирования
◦ Команда уточняет эти требования и определяет, что нужно сделать в проекте
◦ РП разрабатывает план управления качеством (кто, что и когда делает, какие процедуры проверки качества будем использовать, с какой периодичностью) и синхронизирует его с остальными планами (сроки, деньги, др)
3️⃣ На этапе реализации
◦ команда проводит контроль качества разработок в соотв. с планом (например, тестирует программный код перед сдачей Заказчику на предмет соответствия требованиям) - чек-лист тестирования ИТ-системы забери тут
◦ отдел качества контролирует соблюдение плана по качеству (например, проектный офис проверяет наличие протоколов внутреннего тестирования, подписанного тестировщиками)
4️⃣ На этапе мониторинга Заказчик проверяет продукт на предмет соответствия заявленным требованиям (тестирует решение) и в случае успеха - принимает работы
🌟ТОП 5 советов:
1. В каждом проекте вы управляете качеством, когда что-то проверяете. перед тем, как что-то проверять, напиши, КАК проверять
2. Лучше предотвращать, чем устранять
3. Не надо делать лучше, если вас об этом не просили - это передайте проектной команде
4. постоянно ищите способы, как повысить эффективность процессов управления проектом/ разработки кода/ проведения совещаний
5. за качество отвечает каждый участник проекта
🆘А теперь Давайте сразу к ключевому и основному, что вам нужно запомнить и на этом мы пожалуй на сегодня закончим, чтобы не мучать и меня и вас 😂
Как вы знаете, в проекта есть треугольник ограничений - стоимость, расписание, содержание. Представьте, что это ваши вершины треугольника (рисунок будет ниже). В проектном управлении есть одна простая аксиома: при изменении любой вершины (к примеру, увеличение содержания или при снижении стоимости) обязательно изменяются и другие вершины, а какая-то из свершил невозможна к изменению (к примеру, проект нужно реализовать к 01.01.22), поэтому вы как Руководитель проекта всегда должны находить компромисс и наиболее важные параметры для проекта.
Что выберет Заказчик: реализацию дополнительного функционала и увеличение сроков проекта на 2 неделю + 500 тыс. руб. или завершит проект в срок, но не выполнит дополнительное требование?
✅ так вот - основной вывод сегодняшней темы в том, что какие бы вы параметры проекта не меняли, вы никогда не должны СНИЖАТЬ утвержденное качество вашего продукта и стараться удержать его наиболее «круглым»!
Все эти вопросы мы подробно разбираем на курсе Основы управления проектами, узнать , когда будет следующий поток или приобрести записи, можно тут
Следующая область управления проектами
Управление коммуникациями