Проект может идти по плану на бумаге и разваливаться в реальности. Люди заняты, задачи закрываются, отчёты отправляются, при этом сроки удлиняются, качество плавает, деньги в конце месяца сходятся через ручные сверки.
Чаще всего причина простая: в управлении нет повторяемого ритма «задумал → сделал → проверил → закрепил». Есть разовые усилия: собрались, договорились, через две недели всё снова в переписках и уточнениях.
PDCA (Plan–Do–Check–Act), он же цикл Деминга, помогает перевести улучшения из режима редких реформ в привычку. Он одинаково полезен в стройке, ремонтах, производстве, услугах: везде, где есть повторяющиеся операции и проекты с похожими рисками.
- Что такое PDCA и зачем он в проектах?
- Plan: как планировать улучшение без перегруза?
- Do: как внедрять изменения на объекте и в офисе?
- Check: как проверять результат и находить причины?
- Act: как закреплять и масштабировать то, что сработало?
- PDCA как ритм управления проектом
- Типовые ошибки при внедрении PDCA
- Как встроено PDCA в Приложение 101?
Что такое PDCA и зачем он в проектах?
PDCA — это управленческая петля из четырёх действий: спланировать изменения, сделать, проверить, закрепить. В проектном управлении он нужен для двух задач: держать проект в управляемости и постоянно повышать качество процесса.
Классический сценарий без PDCA выглядит так: договорились о правилах, начали работать, через месяц правила размылись, обсуждение вернулось в чаты, руководитель снова тушит срочное. С PDCA правила становятся частью процесса: ты заранее задаёшь, что проверить, где лежат факты, кто принимает решение по итогам проверки.
Важно: PDCA не отменяет базовые принципы управления проектом (цель, сроки, бюджет, роли, риск-лог). Он добавляет управляемую привычку улучшать. Если нужна опора по базовой «рамке проекта», держи под рукой статью «Основы управления проектами для предпринимателя».
Plan: как планировать улучшение без перегруза?
На этапе Plan многие ломаются: пытаются переписать всё сразу. PDCA так не работает. План — это выбор одной узкой точки, понятной метрики и простого способа собрать факты.
История из практики: прораб жалуется на «постоянные переделки», руководитель в ответ усиливает контроль. Через неделю выясняется, что переделки возникают в одном месте: узлы примыкания, где разные мастера читают чертёж по-разному. Здесь нужен план улучшения на один узел, не на весь объект.
План можно собрать за 30–60 минут, если идти по короткому алгоритму:
- Шаг 1. Сформулируйте проблему как наблюдаемое событие: что именно происходит и где это видно (акт, фото, замечание заказчика, перерасход по позиции).
- Шаг 2. Определите границу: один участок, один этап, один тип работ, один тип заявки.
- Шаг 3. Выберите метрику: срок (дни на этап), качество (количество замечаний), деньги (перерасход по статье), коммуникации (время ответа/количество согласований).
- Шаг 4. Зафиксируйте гипотезу: что именно приводит к проблеме.
- Шаг 5. Опишите изменение в одном абзаце: новое правило, шаблон, чек-лист, формат отчёта, порог согласования.
- Шаг 6. Назначьте ответственного и дату проверки результата.
Если план связан со сроками и организацией работ, полезно мыслить в логике «цель → методы → план внедрения → мониторинг». Такой подход хорошо раскрыт в материале про оптимизацию сроков: там упор на реальную постановку цели, выбор методов и систему контроля.
Do: как внедрять изменения на объекте и в офисе?
Do — это внедрение. Тут важно не героическое «внедрить за выходные», а аккуратный запуск с понятной поддержкой: где лежит инструкция, кто отвечает на вопросы, какой формат отчёта считается нормой.
Хорошая практика — дробить внедрение по неделям: сначала договориться о статусах и объектах учёта, потом собрать шаблоны (расчёт, комплектовка, чек-лист контроля), потом навести порядок в деньгах, потом закрепить регулярный разбор. Такой темп помогает встроить систему без остановки работы.
Ещё один рабочий приём: заранее решить, что делать с отклонениями. К примеру, новое правило ввели, мастер его нарушил. На Do не надо устраивать разбор полётов на весь отдел. Лучше вернуть к правилу, собрать причину (почему нарушил) и донести до этапа Check.
Check: как проверять результат и находить причины?
Check — это не «спросить, как дела». Это сравнение факта с планом, затем поиск причины отклонения. Тут пригодятся три слоя фактов: сроки (что сделали и когда), качество (какие замечания и где), деньги (какие траты и по какой статье).
Ситуация: на ремонте в конце недели снова минус по материалам. Руководитель видит перерасход и просит «экономить». В Check картина другая: перерасход появляется после замены одного поставщика, плюс часть позиций не привязывают к этапу работ. Значит, проверка должна включать источник закупки и правило привязки расходов.
| Этап PDCA | Что фиксировать? | Как понять, что все ок? |
|---|---|---|
| Plan | Проблема, метрика, гипотеза, новое правило, дата проверки | Есть ответственный и понятный критерий успеха |
| Do | Кому донесли, какие шаблоны/чек-листы выдали, что поменяли в процессе | Команда знает, где лежит актуальная версия |
| Check | Факт по метрике, отклонения, причины, что мешало соблюдать правило | Причина описана действиями, не эмоциями |
| Act | Решение: закрепить, доработать, отменить; новый стандарт; обучение | Правило становится частью рутины |
В проектном управлении проверка часто упирается в коммуникации: кто согласовал, кто не ответил, где потерялось решение. Тут полезна отдельная дисциплина управления коммуникациями и правилами согласований. Можно свериться со статьёй «Управление коммуникациями проекта».
Act: как закреплять и масштабировать то, что сработало?
Act — момент, когда улучшение перестаёт быть экспериментом и становится стандартом. Здесь есть три варианта решения: закрепить, доработать, отменить. Любой вариант нормальный, если он опирается на факты из Check.
Закрепление — это не «рассказать всем». Это обновить шаблон, описать правило одним абзацем, назначить владельца правила и встроить контроль в регулярный разбор. Если улучшение связано с ролями и порогами решений (кто согласует допработы, кто отвечает за качество, кто подписывает акты), пригодится структура управления проектом. Её удобно собирать по принципу «роли → зоны ответственности → пороги → отчётность». Подробная логика есть в статье «Структура управления проектом: виды и построение».
Масштабирование делай через копирование стандарта. Сработал чек-лист по одному типу работ — перенеси на остальные, затем вернись в PDCA и проверь снова. Важно, чтобы стандарт не превращался в толстую папку регламентов. Достаточно короткого документа и регулярного контроля.
PDCA как ритм управления проектом
PDCA легко встроить в проект как календарь повторяющихся действий. Это делает управление предсказуемым для команды: когда планируем, когда сдаём факты, когда обсуждаем отклонения, когда фиксируем решения.
Рабочий ритм для большинства проектных команд выглядит так: в начале недели Plan по ключевым рискам и узким местам, в середине недели Do (внедрение и поддержка), в конце недели Check по фактам, затем Act как короткое решение и обновление стандарта. Если в проекте много неопределённости, пригодятся гибкие практики управления. Они хорошо объяснены в материале «Agile в строительстве»: там как раз про адаптацию принципов под реальную работу на объекте.
Ещё одна привычка, которая поддерживает цикл: «прочитал → проверил у себя → внедрил → вернулся через месяц и сравнил». В блоге 101 этот подход прямо описан как рабочий способ внедрять изменения без перегруза.
Типовые ошибки при внедрении PDCA
Ошибки тут повторяются во многих командах, и это хорошо: их можно предусмотреть заранее.
- PDCA делают разовым мероприятием: собрались один раз, написали правила, разошлись. Цикл живёт, когда у него есть расписание и владелец.
- На Plan выбирают слишком широкую тему: «наладить качество», «ускорить сроки». Нужна узкая точка: один этап, один узел, одна причина.
- В Check смотрят только на итог: «сдали в срок/не сдали». Нужны промежуточные факты, иначе причина ускользает.
- В Act закрепляют стандарт без обучения: новый сотрудник приходит и делает по старому. Стандарт должен жить в шаблонах и в рутине контроля.
Отдельная ошибка — пытаться решить выбором инструмента. Инструмент важен, при этом сначала нужен процесс: что фиксируем, кто отвечает, какие решения принимаем по отклонениям. Если как раз выбираешь систему под проекты, можно свериться со статьёй «Система управления проектами: как выбрать инструмент, который выдержит реальную работу».
Как встроено PDCA в Приложение 101?
PDCA требует одной вещи: факты должны быть в одном месте и в едином формате. Тогда Plan опирается на прошлые данные, Check занимает минуты, Act превращается в обновление шаблона и правила.
В Приложении 101 удобно держать вместе проект, деньги, документы, участников и отчёты. Это помогает закрывать «петлю» PDCA без ручных сверок: руководитель видит аналитику, руководитель проекта собирает отчётность, мастер отчитывается по расходам и выполненным работам, заказчик получает прозрачность по балансу и тратам.
Если улучшения упираются в контроль показателей (маржа, кассовые разрывы, резервы, управленческие отчёты), пригодится PRO+. Подписка помогает держать важные метрики перед глазами и быстрее замечать отклонения, которые стоит брать в PDCA-цикл.
Хочется разобрать PDCA под твой формат проектов и понять, какие факты фиксировать каждый день, а какие раз в неделю? Это проще сделать на короткой презентации: покажем, как собрать ритм Plan–Do–Check–Act в Приложении 101 и где обычно теряется управляемость.