Оценка проектов для начинающих

Opinions are like assholes. Everybody's has one and everyone thinks everyone else's stinks

Оценка проектов для начинающих

Каждому из нас в жизни приходилось делать оценки времени. Сколько времени нужно на то, чтобы дойти от дома до работы? Или сколько времени понадобится, чтобы сделать домашние дела на выходных? За сколько времени надо приехать в аэропорт, чтобы успеть на рейс? Думаю, ход мыслей понятен. У большинства людей не возникает особых трудностей с определением конкретных цифр. Некоторые оценки оказываются точными, некоторые ошибочными. Мы привыкли всегда оценивать время и делаем это на подсознательном уровне. В веб-проектах (да и в любых других) оценках времени (а на основе нее и стоимости) производится так же, как мы привыкли это делать ежедневно. Разница лишь в стоимости ошибки.

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

Единоличная оценка

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

Оценка по аналогии

Тоже довольно популярный метод у молодых команд. Он предусматривает сравнение нового проекта или отдельных его частей с уже выполненными в прошлом проектами команды или компании. Его популярность обеспечивается тем, что большинство мелких и средних веб-проектов довольно схожи между собой. Интернет-магазины, как правило, имеют аналогичный функционал, поэтому достаточно провести аналогию с ранее выполненным проектом и получить точную оценку. Если же новый проект имеет определенные отличия, можно воспользоваться методом декомпозиции, разбив задачу на более мелкие фрагменты и оценить каждый из них отдельно, а затем объединить результаты в общую оценку.

Параметрическая оценка

Метод является довольно схожим с предыдущим, однако предусматривает формирование оценки на основе отдельного параметра, например — строках кода, страницах дизайна, диалоговых окнах, таблицах базы данных и т.д. Если мы знаем (из предыдущих проектов), что на создание дизайна одной страницы необходимо потратить три рабочих дня, а новый проект предусматривает необходимость создания 20 страниц, из этого можно сделать вывод, что на весь дизайн понадобится 60 дней.

Оценка тремя точками (или PERT)

Очень полезный метод для устранения проблемы "субъективности" оценок. Он предусматривает формирование трех отдельных прогнозов: пессимистического (П), оптимистического (О) и наиболее вероятного (Н). Полученные показатели вычисляются по формуле, в результате которой мы получаем предполагаемую продолжительность: (П + 4Н + O)/6. Например, программист говорит, что на реализацию определенного функционала, ему потребуется: в лучшем случае (если его никто не будет отвлекать) 10 дней, в худшем (если все пойдет "не так как ожидалось") 25 дней, но вероятнее всего (учитывая что отсутствие отвлекания на работе просто невозможно, но и "залетов" также не предвидится), он справится за 15 дней. Проведя простой подсчет мы получаем почти 16 дней.

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

P.S. Если вас интересуют методы оценки времени и стоимости проектов, рекомендую прочитать книгу Стива Макконела "Сколько стоит программный проект".

Расскажите нам о своем проекте!