Kitabı oxu: «Управление проектами»

ТИТУЛЬНЫЙ ЛИСТ

ПРИНЦИП НУЛЕВОЙ ТЕРПИМОСТИ:

УПРАВЛЕНИЕ ПРОЕКТАМИ

Опыт компании HEADS Consulting

Никита Куликов

ВВЕДЕНИЕ

Почему проекты умирают не от катастроф, а от компромиссов

Я хотел бы начать эту книгу с истории, которую я наблюдал лично. Проект запускался с амбициозной целью: за четыре месяца вывести на рынок новый цифровой сервис. Команда собрана сильная, бюджет выделен, руководство вдохновлено. На стартовой встрече все кивали и улыбались. Через полгода проект всё ещё был «на финальной стадии». Через восемь месяцев его тихо закрыли – без громкого скандала, без публичного разбора, просто перестали упоминать на совещаниях.

Что произошло? Не было ни катастрофы, ни увольнения ключевого разработчика, ни пожара в дата-центре. Было другое – сотни маленьких, разумных на вид компромиссов. Цель «сделать удобный сервис для клиентов» постепенно превратилась в «сделать то, что успеем, но чтобы все были довольны». Сроки сдвигались не решением, а привычкой: сначала на неделю, потом на две, потом «давайте не будем фиксировать дату, пока не поймём объём». Совещания множились, согласования удлинялись, а работа, которая должна была занимать день, растягивалась на неделю.

К концу проекта никто уже не помнил, зачем всё это затевалось. Каждый следующий шаг был логичен сам по себе, но вместе они вели в никуда. Проект умер не от удара – он умер от тысячи порезов.

Эта книга – о том, как не допустить такой эвтаназии проекта. О том, как вовремя заметить, что цель размывается, а сроки раздуваются, и как остановить это до того, как проект станет очередной строкой в списке «почти получилось».

Цена мягкости: три цифры, которые должен знать каждый руководитель

Когда я начинаю консультацию с руководителем, я обычно прошу его ответить на три вопроса.

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

Второй: какой процент рабочего времени команда тратит на совещания и согласования? Исследования стабильно показывают цифру в 30–50%. Это значит, что половина дорогостоящего времени уходит не на создание продукта, а на координацию создания. При этом значительная часть этой координации не добавляет ценности – она лишь создаёт иллюзию контроля.

Третий: сколько раз за последний проект цель менялась «незначительно»? Если руководитель не может вспомнить – это уже ответ. Размывание цели почти никогда не фиксируется, потому что каждое отдельное изменение кажется мелким и обоснованным. Но в сумме эти «мелкие уточнения» способны полностью изменить проект и сделать его неузнаваемым.

Эти три цифры – стоимость задержки, доля непродуктивного времени, частота незаметных изменений цели – и есть цена мягкости. Мы платим её не сразу, а частями, поэтому не замечаем, как много теряем.

Кому адресована эта книга

Эта книга написана для трёх категорий читателей, и для каждой у меня есть свой маршрут.

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

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

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

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

Обещание и предупреждение

Я обещаю, что эта книга не будет сборником общих слов о «важности дисциплины» и «эффективности». Каждая глава заканчивается конкретным выводом, а каждая часть – инструментом, который можно применить.

Но я должен предупредить о другом. Принцип нулевой терпимости – это не волшебная таблетка и не способ заставить людей работать больше. Это способ перестать тратить время, силы и деньги на то, что не ведёт к результату. Он требует от руководителя смелости говорить «нет» – и себе, и команде, и заказчику. Он требует готовности признавать ошибки и останавливать то, что не работает. Он требует последовательности, потому что мягкость возвращается при первом же исключении из правил.

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

Оглавление

ВВЕДЕНИЕ

Часть I. Диагноз: как размываются цели и раздуваются сроки

Глава 1. Анатомия «размывания целей»

Глава 2. Механика раздувания сроков

Глава 3. Хроническое откладывание: почему умные люди тянут

Глава 4. Совещания, которые ничего не решают

Глава 5. Согласования как фабрика задержек

Глава 6. Цена компромиссов: ресурсы, деньги, люди

Часть II. Философия нулевой терпимости

Глава 7. Принцип нулевой терпимости: суть и границы

Глава 8. Цель как контракт

Глава 9. Срок как обязательство, а не пожелание

Глава 10. Культура ответственности без поиска виноватых

Часть III. Методы жёсткого контроля ключевых этапов

Глава 11. Карта ключевых этапов проекта

Глава 12. Ворота качества: контроль на входе и выходе этапа

Глава 13. Ежедневный и еженедельный контроль без микроменеджмента

Глава 14. Управление отклонениями: раннее вмешательство

Глава 15. Защита сроков: методы и приёмы

Глава 16. Борьба с хроническим откладыванием: практический арсенал

Глава 17. Совещания, которые работают

Глава 18. Согласования без бюрократии

Часть IV. Внедрение: от принципа к практике

Глава 19. Диагностика текущего состояния

Глава 20. Дорожная карта внедрения нулевой терпимости

Глава 21. Работа с сопротивлением

Глава 22. Инструменты и шаблоны

Глава 23. Метрики эффективности внедрения

Часть V. Особые случаи и сложные ситуации

Глава 24. Нулевая терпимость в Agile и гибких методологиях

Глава 25. Проекты с высокой неопределённостью

Глава 26. Внешние подрядчики и партнёры

Глава 27. Кризисные ситуации и перезапуск проекта

Глава 28. Личный пример: нулевая терпимость к себе

Заключение

Часть I. Диагноз: как размываются цели и раздуваются сроки

Глава 1. Анатомия «размывания целей»

Что такое размывание цели и чем оно отличается от изменения требований

Первое, что нужно разделить, – это два принципиально разных процесса. Изменение требований – нормальная часть работы. Рынок меняется, пользователи узнают новое, конкуренты делают неожиданный ход. Проект, который вообще не меняет требований, скорее всего, мёртв или делает что-то ненужное.

Размывание цели – другое. Это не изменение требований под влиянием новых фактов. Это потеря самой сути проекта, при которой требования меняются не потому, что появились новые знания, а потому, что исходная цель оказалась недостаточно ясной или неудобной. Разница принципиальна: изменение требований происходит осознанно и фиксируется, размывание цели – незаметно и стихийно.

Проверить, что происходит с вашим проектом, можно одним вопросом: «Если мы изменили требование – мы стали ближе к исходной цели или сама цель изменилась?» Если второе – это размывание. И оно опаснее, потому что не оставляет следов: каждое отдельное изменение кажется мелким и обоснованным.

Пять стадий деградации цели

Размывание цели редко происходит за один день. Оно проходит стадии, и на каждой есть шанс остановиться.

Стадия 1. Цель сформулирована абстрактно. «Улучшить пользовательский опыт», «повысить эффективность», «сделать удобный сервис». Такие формулировки звучат хорошо, но не дают ответа на вопрос «что именно мы делаем и как поймём, что сделали». Абстрактная цель – идеальная почва для размывания, потому что под неё можно подвести любое решение.

Стадия 2. Появляются уточнения без фиксации. «Ну, под улучшением мы имеем в виду вот это… и ещё вот это». Уточнения обсуждаются на встречах, но не записываются. Через неделю каждый помнит свою версию. Цель начинает жить в головах, а не в документе.

Стадия 3. Уточнения начинают противоречить друг другу. Одна часть команды считает, что «удобный сервис» – это скорость, другая – что это красивый интерфейс, третья – что это интеграция с другими продуктами. Каждое направление тянет проект к себе.

Стадия 4. Цель заменяется компромиссом. Чтобы никого не обидеть, команда формулирует новую цель, которая устраивает всех и не обязывает никого: «сделать хороший продукт, который понравится пользователям и заказчику». Это уже не цель, а пожелание.

Стадия 5. Цель исчезает. Работа продолжается, задачи выполняются, совещания проводятся, но никто не может внятно ответить, зачем всё это. Проект движется по инерции. Именно на этой стадии чаще всего звучит фраза «мы уже так далеко зашли, что надо закончить».

Остановиться можно на любой стадии, но чем раньше – тем дешевле. На первой стадии достаточно переформулировать цель. На пятой придётся останавливать проект и перезапускать его.

Симптомы: как распознать размывание на ранней стадии

Размывание почти всегда маскируется под разумные рабочие формулировки. Вот маркеры, которые должны насторожить руководителя.

«Мы пока уточняем». Если уточнение длится дольше одной-двух недель, это уже не уточнение, а отсутствие решения. Уточнение – это процесс с конкретным сроком и результатом. «Пока уточняем» – это способ отложить неприятный выбор.

«Давайте сначала обсудим концепцию». Обсуждение концепции полезно, когда есть рамка: что мы решаем, какие варианты рассматриваем, когда заканчиваем. Без рамки обсуждение концепции превращается в бесконечный круг, в котором каждая встреча порождает следующую.

«Нам нужно быть гибкими». Гибкость – это способность реагировать на изменения, а не отсутствие плана. Когда гибкостью оправдывают отсутствие цели, это подмена понятий. Гибкая команда знает, к чему идёт, и меняет маршрут осознанно. Размытая команда просто не знает, куда идёт.

«Это же очевидно». Фраза, которая чаще всего означает, что ничего не очевидно, но обсуждать не хочется. Если цель очевидна, её можно сформулировать в одном предложении и записать. Если не получается – она не очевидна.

«Заказчик сам не знает, чего хочет». Иногда это правда. Но чаще это означает, что команда не задала заказчику правильных вопросов или не помогла ему сформулировать. Перекладывание ответственности на заказчика – удобный способ не фиксировать цель.

Кто и зачем размывает цели

Размывание цели – не злой умысел. У него почти всегда есть рациональная причина для того, кто это делает.

Заказчик размывает цель, потому что боится зафиксировать требование и потом оказаться неправым. Абстрактная цель даёт свободу передумать. Фиксированная – создаёт обязательство.

Руководитель проекта размывает цель, потому что ясная цель означает ясную ответственность. Если цель размыта, то и провал размыт: всегда можно сказать, что мы делали не то, что изначально имелось в виду.

Команда размывает цель, потому что абстрактная задача даёт свободу интерпретации и защищает от критики. Конкретную задачу можно сделать плохо. Абстрактную – невозможно оценить.

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

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

Кейс: как одна формулировка «улучшить пользовательский опыт» съела квартал

Компания среднего размера запускала обновление личного кабинета для клиентов. Цель звучала так: «улучшить пользовательский опыт». Задача казалась понятной всем, поэтому к ней приступили без дополнительных уточнений.

Первый месяц ушёл на исследование: интервью с пользователями, анализ конкурентов, изучение аналитики. Исследование выявило двадцать три проблемы. Команда решила, что нужно исправить всё, иначе «улучшение» будет неполным.

Второй месяц – проектирование. Дизайнеры предложили новую концепцию, которая нравилась команде, но требовала переработки бэкенда. Разработчики возразили. Начались встречи по согласованию. Решили сделать «компромиссный вариант»: половину изменений, но зато быстрее.

Третий месяц – разработка. В процессе выяснилось, что часть изменений противоречит требованиям безопасности. Их отложили «на потом». Другая часть потребовала согласования с юридическим отделом, которое заняло три недели.

К концу квартала команда сделала примерно треть задуманного. Пользователи не заметили изменений: они были точечными и не связанными между собой. Заказчик остался недоволен: «Мы же договаривались улучшить опыт, а стало только хуже – часть функций переехала, часть изменилась непонятно как».

Разбор показал главное: формулировка «улучшить пользовательский опыт» не содержала ответа на вопросы «для кого», «в каких сценариях» и «как мы поймём, что улучшили». Каждый участник вкладывал в неё свой смысл, и все были правы – по-своему.

Если бы цель звучала как «сократить время оформления заказа с пяти минут до двух для клиентов, заходящих с мобильных устройств», проект имел бы границы. Исследование было бы сфокусированным, дизайн – ограниченным одним сценарием, а критерий успеха – измеримым. Квартал не был бы потрачен на «улучшение вообще».

Глава 2. Механика раздувания сроков

Оценка как переговоры, а не как прогноз

В идеальном мире оценка срока – это прогноз: сколько времени займёт работа, если делать её нормально. В реальном мире оценка почти всегда – переговоры. Исполнитель называет цифру, которая, по его мнению, устроит руководителя и при этом оставит запас. Руководитель торгуется, потому что цифра кажется слишком большой. В результате получается не прогноз, а компромисс между страхом и давлением.

Проблема в том, что такой компромисс не имеет отношения к реальности. Он отражает соотношение сил, а не объём работы. И когда реальность оказывается другой – а она почти всегда оказывается другой, – начинается цепочка объяснений, переносов и «непредвиденных обстоятельств».

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

«Буфер на всякий случай»: как он превращается в норму

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

Разработчик закладывает буфер в свою оценку. Тимлид добавляет буфер к оценке команды. Руководитель проекта добавляет буфер к сроку этапа. Заказчик добавляет буфер к дате релиза. Каждый буфер кажется небольшим – 10–20%. Но если буферы умножаются, итоговый срок может вырасти в полтора-два раза.

При этом парадокс: несмотря на все буферы, проекты всё равно опаздывают. Потому что буфер, заложенный заранее, не защищает от неожиданностей – он просто сдвигает дату. А работа, как известно, занимает всё отведённое время (закон Паркинсона). Буфер не резервируется на случай проблем, а растворяется в повседневной работе: появляются «важные» мелочи, «срочные» задачи, «небольшие» улучшения.

Правильный подход: буфер должен быть один, явный и управляемый. Не размазан по оценкам, а выделен отдельно и потрачен осознанно – только на реальные непредвиденные обстоятельства. И лучше, если он находится под контролем руководителя проекта, а не растворяется в оценках исполнителей.

Закон Паркинсона в действии

«Работа занимает всё время, которое на неё отведено». Этот принцип, сформулированный более полувека назад, в проектах работает с пугающей точностью.

Дайте команде неделю на задачу, которая реально делается за два дня, – и она займёт неделю. Не потому, что люди ленивы, а потому что так устроено внимание: когда времени много, работа растягивается, обрастает деталями, обсуждениями, «улучшениями». Когда времени мало, находится способ сделать главное.

Из этого следует контринтуитивный вывод: щедрые сроки не делают работу лучше. Они делают её медленнее. Разумный, слегка напряжённый срок мобилизует; комфортный – расслабляет.

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

Студенческий синдром в корпоративной среде

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

Один разработчик может отложить задачу до последнего дня – и сделает её. Но если пять человек откладывают свои задачи до последнего дня, то в последний день они обнаруживают, что зависят друг от друга. Интеграция, тестирование, согласование – всё это требует времени, которого уже нет.

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

Лечится это не призывами к дисциплине, а структурой: промежуточными контрольными точками, видимостью прогресса, декомпозицией на короткие задачи. Когда задача разбита на части по два-три дня, откладывать её до последнего дня невозможно – последний день наступает каждые три дня.

Ловушка «ещё чуть-чуть доработаем»

Есть особый вид раздувания сроков, который выглядит как добросовестность. Работа готова, но команда хочет «ещё чуть-чуть доработать»: поправить мелочи, добавить пару функций, улучшить то, что и так работает.

Это ловушка, потому что «чуть-чуть» не имеет границы. Всегда найдётся что улучшить. Всегда найдётся мелочь, которая «займёт полчаса» (и займёт три дня). Проект, который «готов на 90%», может провести в этом состоянии месяцы.

«Доработка» – это форма перфекционизма, которая маскируется под профессионализм. И она так же опасна, как откладывание, потому что не имеет естественного завершения. Критерий «сделано» размывается так же, как и цель.

Решение – тот же принцип: критерий готовности должен быть определён до начала работы. «Сделано» – это не «хорошо», а «соответствует заранее определённым критериям». Всё, что сверх этого, – либо отдельная задача, либо следующая версия.

Кейс: проект, который «был готов на 90%» три месяца подряд

В одной IT-компании был проект по миграции внутренней системы. На еженедельных статусах руководитель слышал одно и то же: «Готово на 90%, остались мелочи».

Первый месяц «мелочей» включал доработку интерфейса, которую никто не просил, но которая «улучшала опыт». Второй месяц – «оптимизацию» производительности, которая давала прирост в 3%, но требовала переписывания двух модулей. Третий месяц – «финальную полировку» и «подготовку к запуску», которая включала бесконечные согласования и тестирование.

Проект запустили на четвёртый месяц. Фактически он был функционально готов в конце первого месяца. Три месяца команда работала над тем, что не добавляло ценности, но создавало ощущение занятости. Стоимость этих трёх месяцев – зарплата команды, отложенные задачи и упущенные возможности – была сопоставима с бюджетом самого проекта.

Причина: критерий готовности не был определён. «90%» – это не критерий, это ощущение. Каждый понимал его по-своему, и каждый находил, что «доработать». Когда критерий не определён, работа не заканчивается – она просто останавливается.