Последнее время мне часто приходится оценивать проекты. Не всегда мне потом их приходится делать. Но отстаивать оценку приходится всегда, как правило, отвечая на вопрос «почему так много»?

Оценки бывают нескольких типов:

• оптимистические – в этом случае команда вместе с тимлидом рвутся в бой, размахивая руками и маленькой табличкой в excel с криком «да это сделаем за месяц, ну максимум за два!», имея на руках описание очередного гениального проекта на 2 страничках;
• пессимистические – в этом случае оценки составляются из принципа «а вдруг потоп?», часто сопровождаются словами «а что, если?», «а мы не знаем...» и т.д.;
• пофигистические – скажем, что сделаем за X месяцев, а там посмотрим;
• реальные – о таких оценках история умалчивает. Если вам говорят, что оценка РЕАЛЬНАЯ – бегите от таких оценщиков. Они врут (с);

Мысль:

Любая методология является процессом минимизации рисков, связанных со сроками сдачи проекта.

Здесь ключевое слово: риски. О них все говорят, но никто не учитывает. Очень кратко остановимся на тех рисках, которые могут возникнуть на проекте:

• инфраструктурные: вам раз в неделю выключают интернет, раз в месяц – свет, а время реагирование IT подразделения – минимум 24 часа; используется svn, потому что корпоративный стандарт, а не потому что его лучше всего знает команда;
• методологические: используется scrum, где нужен waterfall; используется waterfall, где нужен scrum; используется scrum, где нужен здравый смысл и т.д.;
• технологические: нет доступных ресурсов, компания никогда не делала подобных проектов, нужную технологию знают 1.5 разработчиков, половина из которых работают удаленно, низкая квалификация ИТ специалистов;
• экономический – проект разрабатывается в условиях жесткой экономии, на перспективу или на энтузиазме;
• коммуникационные – разработчики – фрилансеры или находятся в разных часовых поясах, старнах, континентах, имеют разный цвет кожи, религию и коэффициент интеллекта;
• интеграционные – используются различные технологии в одном проекте; специфика проекта различается в зависимости от разных платформ или устройств (например, нужно сделать один проект для всех мобильных платформ с единым back-end);
• человеческий фактор (самый распространный и трудно поддающийся контролю) – уволился хороший администратор, тимлид забухал, женился или внезапно пошел на курсы молодых пасторов; разработчик забухал, затупил, уволился и стер все исходники за прошлый месяц работы и т.д.

Другие аспекты:

• нужно понимать, что чем больше людей в команде, тем больше взаимодействий между ними, что увеличивает время на коммуникацию и принятие решений;
• необходимо иметь четкое распределение обязанностей и зоны ответственности;
• оценка не должна быть абстрактной, а должна учитывать конкретное место, ситуацию, а также психологический и технологический портрет тех, кто этот проект будет делать;
• вопросы по проект должны задаваться ДО оценки, а не после;
• никогда (еще раз: никогда) не нужно считать, что изменение бизнес-схемы или методологии кардинально изменит точность оценки.

Все это влияет на финальную оценку. Как проще всего оценивать риски? Можно напротив каждого пункта поставить весовые коэффициенты вероятности возникновения такой ситуации и потом вывести дельту. Я же делаю проще: добавляю +25% от средней оценки (средняя оценка - это компромисс между пессиместической и оптимистической оценками) и получаю финальную оценку.

А как вы оцениваете проекты?