Периодически слышу, что срок сдачи проекта — одна из главных метрик в работе руководителя проектов. И каждый раз это звучит настолько уверено, что твои мышиные сомнения вырастают до капитального такого мамонта, мохнатого, с бивнями и, непременно, с очень толстой кожей.
Да, разумеется, есть более или менее шаблонные проекты. Согласитесь, создание нового ресурса с уроками йоги от Саши Грей - задача простая и вполне детерминированная. Но что делать, когда проект яляется тяжеловесным, а число его участников сильно больше 3 человек.
Я убежден, что попадание в срок — это игра, суть которой может быть выражена в следующих факторах:
- Правильные ожидания. Заказчик, как правило, хочет результат завтра, разработчики говорят - месяц (два месяца в уме). Ну, вы же знаете свою команду, вы же знаете, кто и насколько способен ошибаться в своих оценках. И вот вы с этим знанием получаете срок - 3 месяца. Вы начинаете торговаться и постепенно срок начинает сокращаться, ведь заказчику очень хочется. Вот только реальный срок не изменился, даже при условии, что вы не ошиблись и не возникнет никаких трудностей. В результате ваша метрика будет в красной зоне. Очень уж часто мы идем на поводу заказчика, чтобы удовлетворить его ожидания. Очень уж часто заказчик выходит на путь занудства и просто не выпускает из кабинета, пока не будет назван успокаивающий его срок.
- Помним о людях. Вы можете все спроектировать, посчитать, докопаться до всех мелочей. Но вы НИ-КО-ГДА не узнаете, в какой момент у одного из разработчиков случится запор, другой заболеет, у третьего случится семейная драма, а остальные просто не выспятся. Все, что вам остается - вставить разрыв и..... ну да, сдвинуть срок. Как бы банально это ни звучало, но мы имеем дело с интеллектом, а это очень нестабильная штука.
- Жонглируем отмазками. Да, и это нужно. Степень продуманности отмазок растет одновременно со сроком, на который вы сместили сдачу проекта. Просрочка на неделю - "осталось чуть-чуть, пара дней и все будет готово". Просрочка на месяц - "на самом деле, все готово, но мы специально для вас делаем важные оптимизации, необходимость которых выяснилась внезапно". В общем, принцип довольно прост.
- Первым делом - удовлетворение. Приоритизация для того и дана, чтобы сделать сначала главное, а остальное.... ну, как пойдет. Если отмазки закончились, то всегда можно сделать ту функцию, которая представляет наибольшую важность для заказчика. Если заказчик сам не понимает, что наиболее важно, то ему нужно подсказать. Сделав самое важное, можно всегда попробовать скрыть продоланные сроки за всякими "доводками", "гарантией", ну и прочим сопровождением. И не говорите, что вы так никогда не делали.
И вот если все эти факторы учитывать, то вполне можно сдаться в срок, ну, по крайней мере, выглядеть будет именно так.
Насколько стабильно солнце встает на востоке, настолько же стабильно продалбливаются сроки проектов. Да, разумеется, умные книги говорят, что надо проектировать, что нужно планировать, контролировать, надувать щеки и ковырять в носу обязательно указательным пальцем левой руки. Но, как я говорил выше, если проекты реализуются людьми, то вероятность провала сроков будет далека от изначально приемлемой. Но все это иные истории. Проектирование делается не столько для сроков, сколько для хорошей архитектуры. Планирование - да, речь о сроках, но если мы планируем работу мозга, то, либо познаем его, либо смиряемся - выбор, пожалуй, очевиден. Контроль - это замечательно, но это, скорее, своевременная реакция, что может сократить просрочку, но не гарантирует ее отмену. Вот насчет ковыряния в носу у меня контраргументов нет, может и полезно.
Я это все к чему. На мой скромный взгляд, важна именно деятельность руководителя. Насколько он способен отреагировать на просрочку. Будет ли он просто разводить руками и потеть, либо он будет искать выходы из ситуации: кого-то пнет, с кем-то договорится, от чего-то отмажется, что-то отменит или перенесет, кому-то купит пирожок и погладит по головке, чтобы этот кто-то чувствовал поддержку.