В мире управления проектами, особенно в сфере разработки, нет вопроса болезненнее и субъективнее, чем оценка сроков. Руководители и команды постоянно балансируют на тонкой грани между двумя крайностями: желанием дать реалистичный, обоснованный план и давлением со стороны бизнеса, рынка и конкурентов, требующих “сделать вчера”. Этот конфликт порождает две фундаментальные и сознательные стратегии: недооценку (сознательное занижение сроков) и переоценку (завышение трудозатрат “на всякий случай”).

Что такое недооценка и переоценка проекта?

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

Такой подход на первый взгляд кажется странным и деструктивным. Иногда он видится как проявление некого “самодурства” со стороны руководства. Однако для его существования есть много объективных причин. 

1. Закон Паркинсона, который звучит так: “Работа занимает все отведенное ей время”. 

2. Синдром студента. Как правило, на длинных этапах или проекта, работа начинается “спустя рукава”, постепенно разгоняясь ближе к завершению. 

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

4. Внешние факторы. Зачастую компания становится заложником своих договоренностей с заказчиком. Например, чтобы победить в тендере, называются заведомо невыполнимые сроки. Сюда же относится конкурентная борьба, например, за место на рынке. 

5. Меньшие затраты на управление проектом- команда, работающая в режиме дедлайна требует меньше контроля.

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

Плюсы сознательной недооценки проекта

Плюсы такого подхода весьма очевидны и перечислены ниже. 

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

2. Снижение затрат на управление
Существенно снижаются затраты на контроль и управление. Скорее всего, у команды не будет простоев а значит можно сократить и количество руководителей проекта (либо их участие) как и количество отчетов. 

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

4. Специальные условия для команды
Команда, работающая в режиме дедлайна, может запросить для себя определенные свободы. Если перед командой ставится некий вызов- успеть к заданному сроку, команда в обмен может требовать для себя специальные условия, например, не следовать некоторым корпоративным стандартам или работать из дома.

Минусы недооценки

Давайте теперь перечислим минусы подхода.

1. Снижение эффективности планирования
Для того, чтобы наши оценки становились все более точными, необходимо проводить ее анализ после окончания проекта. Если оценка и реальная трудоемкость отличаются более, чем на 20%, следует идентифицировать причины такого расхождения, провести анализ и выработать меры для того, чтобы в дальнейшая оценка была более точной.

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

2. Снижение вероятности завершить проекта в срок
Если взглянуть на отчет The Chaos Report по состоянию на 2015, то окажется, что только 36% проектов завершаются в заданные сроки. Таким образом, ваша оценка с вероятностью 64% окажется заниженной. Дополнительное существенное уменьшение времени и ресурсов на проект почти со 100% вероятностью приведет к тому, что мы не завершим работы к заданному сроку

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

4. Рост затрат в связи с вынужденной декомпозицией проекта
К эффекту непропорционального роста расходов добавляются затраты, связанные с вынужденной декомпозицией проекта. Как правило к такому решению прибегают, когда хотят сдать хоть какую-то часть проекта к заданному сроку. Хорошо, если “линия разрыва” проходит по разрабатываемому продукту логично- чаще всего так разделить проект на части не удается, в результате чего на свет появляются франкенштейны, жизненная форма которых выполнена так сложно, что ей еще долго пугают новичков. 

5. Плохая техническая база (архитектура)
Как правило, в жертву ограниченным срокам проектов приносится архитектура. Например, давно пора переходить на микросервисы в то время как из-за постоянной нехватки времени компания до сих пор делает монолитные приложения.  

6. Плохой код
Очевидно, что программисты в условиях постоянного дедлайна генерируют код, которым они не гордятся. “Лишь бы работало, а там разберемся”,- но все это становится легаси кодом, который компания будет тащить годами, тратя на него человеко-месяцы усилий и не получая ничего взамен. 

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

7. Кратный рост количества ошибок
Исследований, на которое ссылается Стив Макконел в книге “Сколько стоит программный продукт” показывает, что программисты при работе в режиме дедлайна допускают в 4 раза больше ошибок, чем при создании кода в нормальном темпе. Логично предположить, что так как тестирование проводится в таком же спешном порядке, мы закладываем мину замедленного действия под свой продукт. Если он выживет, то в дальнейшем все эти ошибки причинят страдания множеству людей. 

8. Частичная или полная потеря команды проекта
Еще один из видов непропорциональных затрат по проекту, которые очень сложно оценить. Выпадение одного или нескольких разработчиков из команды проекта может привести не только к непредвиденным затратам на поиск, обучение и подключение к проекту новых специалистов, но и привести к краху проекта - можно предположить, что документирование, обмен знаниями и обучение в условиях ограниченного проектного времени ведутся плохо и увольнение практически равнозначно безвозвратной потере компетенций по той или иной области знаний.

9. Повышение частоты срабатывания рисков
Причины:

1. Проблемы не эскалируются (времени нет, “никому до этого нет дела”);

2. Решения принимаются поспешно, гипотезы не проверяются;

3. Накладывается эффект “каскадирования”;

4. Повышенная нагрузка на людей;

5. Разработчики склонны сокращать объем работы, ухудшая качество кода;

6. Нет времени на раннюю диагностику рисков (например, проверить какие проблемы могут быть с API еще на старте проекта);

7. Нет буфера на неучтенные факторы;

8. Плохая архитектура, легаси проблемы.

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

Плюсы и минусы переоценки 

Плюсы переоценки довольно очевидны, они перечислены ниже.

1. Повышение вероятности уложиться в срок
Если сроки и трудозатраты завышены, у команды появляется буфер, и риск срыва дедлайна минимизируется.

2. Более качественный результат
При наличии времени на тестирование и рефакторинг продукт обычно получается стабильнее и с меньшим количеством дефектов.

3. Снижение стресса у команды
Запас времени позволяет разработчикам работать в более комфортном режиме, что уменьшает эмоциональное выгорание.

4. Возможность учесть непредвиденные факторы
Дополнительные часы помогают покрыть риски, которые сложно предусмотреть на старте (задержки со стороны подрядчиков, изменение требований, проблемы с интеграциями).

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

Минусы.

1. Растягивание работ (эффект Паркинсона)
Если времени много, команда бессознательно тратит его неэффективно: работа "размазывается" по доступному сроку.

2. Избыточные расходы
Заказчик оплачивает больше человеко-часов, чем реально нужно. Это снижает конкурентоспособность компании.

3. Потеря доверия со стороны бизнеса
Если заказчик понимает, что команда "перестраховывается" и завышает сроки, это может подорвать доверие и привести к конфликтам.

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

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

Что делать, если мы считаем, что отдельные сотрудники сознательно завышают оценку трудоемкости по задачам? 

Существует несколько подходов к решению этой проблемы

1. Культура доверия
Часто трудоемкость задач завышают, если боятся наказания за недооценку. Если культура допускает ошибку в оценке и корректировку плана, у сотрудников отпадает стимул «перестраховываться».

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

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

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

4. Применение балльной оценки задач
Для объективной оценки трудоемкости задачи можно использовать оценку в баллах, например Functional Point Analysis, COSMIC, Story Points и т.п. Когда оценка основана на относительной сложности, а не на “чистых часах”- манипулировать сложнее. 

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

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

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

TribalScale, ИТ-компания, при работе с McCain (производитель продуктов питания) внедрила XP-практики: TDD и парное программирование. Результат: проект сдан на 2 недели раньше срока, существенно улучшилось качество, документация стала полнее, а носители знания перестали быть чем-то уникальным. 

https://medium.com/tribalscale/the-power-of-pair-programming-a-case-study-e5e07e88bce5

Выводы

В ходе написания этой статьи, был прочитан целый ряд исследований, которые ставили целью ответить на вопрос: “Как сознательная недооценка влияет на результаты проекта?”. В целом все авторы приходят к следующим выводам:

1. При недооценке проекта качество кода снижается, а количество ошибок возрастает. При этом рост может носить кратный характер (в некоторых случаях, число ошибок может вырасти в 4 раза). Однако, рост числа ошибок очень сильно зависит от коэффициента, применяемого для уменьшения трудоемкости. Например, коэффициент 0.5 вызовет лавину ошибок, а при использовании 0.9 количество ошибок будет вполне удовлетворительным.

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

Универсальной и идеальной стратегии оценки проектов не существует. И недооценка, и переоценка могут быть полезными инструментами управления, но их применение всегда связано с серьезными компромиссами.

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

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