Управление проектом разработки сайта или веб-приложения. От идеи до внедрения | страница 14
Делаем градацию по проектам. Например, 3 градации, у каждой своя вилка и критерии попадания под нее.
При оценке проекта соотносим ее с одной из градаций.
Получаем оценку (оценка этой градации, которая сделана заранее).
Плюс этого подхода в скорости и малых затратах. Минус – это очень приблизительный способ. Но для первого ознакомления с проектом этого бывает вполне достаточно. Еще момент – этот способ практически не требует технической квалификации от оценщика. Его задача – просто корректно соотнести проект с нужной градацией.
Модульная оценка. Вы разбиваете конкретный проект на крупные блоки, модули и отдельно оцениваете каждый модуль. Обычно это делает уже технический специалист, либо менеджер. Здесь, как минимум, нужно детально ознакомиться с концепцией или ТЗ проекта. Модулями могут быть крупные функциональные блоки, которые являются более-менее типовыми. Для таких блоков можно сделать типовые оценки. Например, сделать форум – это N часов (или X рублей). Это немного упрощает оценку.
Эта оценка существенно точнее предыдущего способа и, если у вас одиночный проект, то именно ее лучше всего использовать на начальном этапе. Вы также можете попросить дать оценку у других людей, не всего проекта, а отдельного модуля. Это также позволит вам получить более объективное представление о каждом модуле.
Детальная оценка. Вы разбиваете весь проект на мелкие кусочки – функции и компоненты и детально оцениваете каждый из них. Будет очень хорошо если это будут делать разработчики, и их будет несколько. Это сделает оценку существенно точнее. Параллельно вы можете проработать проект – выявить недостающие нюансы.
Для этой оценки очень важно, чтобы ТЗ было уже написано и оно было достаточно детальным. Если этого не будет, то разработчики завалят вас кучей вопросов по деталям проекта.
Оценку лучше вести в часах и определить нормированную стоимость этого часа. У каждого компонента (или страницы) будет 2 оценки – минимальная и максимальная. Чем точнее написано задание, тем ближе они будут друг к другу.
В итоге, суммируя эти оценки, вы получите довольно точное представление о бюджете и сроках проекта.
Очень важно при этой оценке учесть все дополнительные работы (о которых могут забыть разработчики), а именно:
● подготовка проекта
● совещания
● тестирование
● первичная поисковая оптимизация
● вынесение настроек в админку
● дизайн для админки
● уведомления
● типовой функционал, не учтенный в ТЗ (смена пароля, восстановление пароля, выход и т.д.)