Как успеть до дедлайна проекта, если объем работ превышает его

Прежде всего, давайте разберёмся, что же такое дедлайн. Википедия дает довольно четкое и простое определение этого термина: «Крайний срок (дата и/или время), к которому должна быть выполнена задача».

Дедлайн может быть обусловлен банальными «хотелками» заказчика (зачастую безосновательными), маркетинговой кампанией заказчика, обещаниями перед топ-менеджерами компании и другими возможными обстоятельствами. Причина дедлайна играет немаловажную роль в переговорах с клиентом. Этому уделяется внимание на курсах Проджект-менеджеров.

В нашем случае у нас очень ограничены ресурсы, но как же мы попали в такую неприятную ситуацию? Тут могут быть такие причины:

1. Неправильная оценка объема работ. Но нельзя обвинять тех, кто оценивал. Оценку всегда просят дать до начала работ, а дать оценку тому, чего ты никогда или частично делал, очень сложно.
2. Было принято решение любым способом заполучить заказчика для портфолио компании. Тут даже сложно представить, насколько могут расходиться реальный объем и оценка. Потери компании могут достигать миллионов долларов.
3. Проджект-менеджер или его начальство приняло решение «Ну и что, что оценка больше срока дедлайна, как-­то вырулим, еще и с прибылью». Это один из самых непрофессиональных подходов, ведущих за собой печальные последствия для команд(ы) разработчиков.
4. Объем работ постоянно увеличивается, каждый раз заказчик нам что­-то приносит: «А вот тут еще эту мелочь добавить», «Тут нужно, чтобы оно по-другому открывалось»... При таком подходе вы никогда не закончите, и правильный проджект-менеджер все такие изменения проводит как Change Request к оригинальному объему. И за каждый такой CR клиент платит дополнительно. Но если клиент требует, чтобы вы уложились при этом в срок, то это тяжелый клиент, и с ним нужно уметь разговаривать.

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

1. Урезание скоупа проекта. Это один из самых лучших и распространенных способов попасть в сроки без увеличения затрат. Тут можно вспомнить и принцип Парето, и отрезание «хвоста» скоупа, когда наименее полезный функционал идет в конце проекта и его можно не делать без ущерба для продукта.
2. Перенос даты окончания проекта. Если вам удастся договориться об этом с заказчиком, ­вы молодец. В начале мы говорили, что причина установленной даты окончания проекта очень важна. И если можно ее сдвинуть без непоправимого ущерба для заказчика и вас, ­это очень хороший вариант, так как не стоит прибегать в таком случае к остальным вариантам ниже.
3. Увеличение количества сотрудников на проекте. Это помогает до какой-­то критической точки, когда эффективность взаимодействия людей нивелируется количеством связей между ними. Другими словами, у вас на проекте будет столько людей, что вам будет трудно ими управлять и координировать их взаимодействие. Но увеличение количества людей хорошо работает, если части проекта не связаны или слабо связаны между собой.
4. Овертаймы на проекте. Вам придется выжимать из команды последние соки, работать по субботам, вечерами, а, может, и ранними утрами, в праздники и т.д. Это выжигает в команде мораль, снижает качество продукта, и сотрудникам нужно платить по повышенным рейтам.
5. Увеличение seniority-пирамиды на проекте, то есть привлечение более квалифицированных людей, чем имеются на данный момент. Но учтите, что время входа\адаптации на проекте варьируется от одного до трёх месяцев. Если проект заканчивается через месяц, то такой подход является бессмысленным.
6. Остановить проект. Это, наверное, самый плохой вариант для обеих сторон: заказчик не получит продукт, а подрядчик — оставшейся суммы по контракту. Но этот вариант подходит, если выгода при закрытии проекта для одной из сторон превышает затраты на его продолжение. Например, если у заказчика не осталось денег на вас, тогда выход очевиден. Если вы работаете по фиксед прайс проекту и сильно ошиблись с оценкой объема работ, то лучше уж запятнать репутацию, чем пойти в убыток. Особенно такой вариант подходит для маленьких заказчиков.

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