Руслан Раянов - Управление проектом разработки сайта или веб-приложения. От идеи до внедрения

Начнем с оценки. Самый важный момент, надо различать оценку, обязательство и фактический показатель. Оценка – это прогноз по метрике. Обязательство – это обещание сделать в рамках определенных метрик. И фактическая метрика – это то, что по факту получилось.

Очень часто просят назвать очень точную оценку по краткому содержанию проекта. Тем самым заказчик уже закладывает гигантские риски в проект. Невозможно дать точную оценку на начальном этапе. Она в принципе не может быть точной. Есть такое понятие как “Конус неопределенности”. На начальном этапе оценка очень широкая, затем по мере движения проекта вилка оценки уменьшается (т.к. уменьшается неопределенность в проекте). Таким образом, не пытайтесь очень точно оценить проект на самом раннем этапе. Лучше сосредоточьтесь на следующем – сделайте так, чтобы в 90% случаев фактическая метрика вошла в ваша начальный диапазон оценки.

Какие бывают виды оценки?

Быстрая оценка. Делается по одному взгляду на проект. Мы ее очень часто используем для первичной оценки проекта. Как она делается:

Делаем градацию по проектам. Например, 3 градации, у каждой своя вилка и критерии попадания под нее.

При оценке проекта соотносим ее с одной из градаций.

Получаем оценку (оценка этой градации, которая сделана заранее).

Плюс этого подхода в скорости и малых затратах. Минус – это очень приблизительный способ. Но для первого ознакомления с проектом этого бывает вполне достаточно. Еще момент – этот способ практически не требует технической квалификации от оценщика. Его задача – просто корректно соотнести проект с нужной градацией.

Модульная оценка. Вы разбиваете конкретный проект на крупные блоки, модули и отдельно оцениваете каждый модуль. Обычно это делает уже технический специалист, либо менеджер. Здесь, как минимум, нужно детально ознакомиться с концепцией или ТЗ проекта. Модулями могут быть крупные функциональные блоки, которые являются более-менее типовыми. Для таких блоков можно сделать типовые оценки. Например, сделать форум – это N часов (или X рублей). Это немного упрощает оценку.

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

Детальная оценка. Вы разбиваете весь проект на мелкие кусочки – функции и компоненты и детально оцениваете каждый из них. Будет очень хорошо если это будут делать разработчики, и их будет несколько. Это сделает оценку существенно точнее. Параллельно вы можете проработать проект – выявить недостающие нюансы.

Для этой оценки очень важно, чтобы ТЗ было уже написано и оно было достаточно детальным. Если этого не будет, то разработчики завалят вас кучей вопросов по деталям проекта.

Оценку лучше вести в часах и определить нормированную стоимость этого часа. У каждого компонента (или страницы) будет 2 оценки – минимальная и максимальная. Чем точнее написано задание, тем ближе они будут друг к другу.

В итоге, суммируя эти оценки, вы получите довольно точное представление о бюджете и сроках проекта.

Очень важно при этой оценке учесть все дополнительные работы (о которых могут забыть разработчики), а именно:

● подготовка проекта

● совещания

● тестирование

● первичная поисковая оптимизация

● вынесение настроек в админку

● дизайн для админки

● уведомления

● типовой функционал, не учтенный в ТЗ (смена пароля, восстановление пароля, выход и т.д.)

● создание системы бекапов

● настройка мониторинга доступности

● регистрация в поисковых системах

● обработка новых запросов клиента

● ведение проекта

● составление отчетности по проекту.

Еще важный момент, учитывайте, что в любом случае будут неучтенные доработки. Их размер зависит, в основном, от клиента – именно он в конечном счете определяет какие функции надо изменить. Здесь важно помнить, что чем позже вы внедряете изменения, тем дороже они будут стоить. Поэтому желательно сразу правильно определять состав функциональности в проекте.

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

Еще момент, выберите уровень технических решений и качества. Здесь имеет смысл брать ориентир на другие сайты, т.е. этот блок сделать примерно как на site.ru. Конечно, это очень субъективно, но позволит команде разработке сделать свое представление о выбранном уровне качества.

После того как мы сделали оценку по срокам и бюджету, хорошо бы собрать всю информацию воедино в так называемую концепцию проекта.

Что в нее входит:

1. Основные параметры проекта:

a. Цель проекта и результат. Что в итоге вы должны получить? Зачем вам нужен этот проект? Входными данными для какого следующего проекта будет результат текущего проекта? Четко определите критерии завершения проекта.

b. Сроки. Сколько в целом месяцев/недель займет проект?

c. Бюджет. Сколько вы запланировали заложить средств на реализацию проекта?

d. Объем. Что нужно реализовать в рамках проекта? Что мы оставим за бортом? Определите границы проекта.

e. Команда. Кто будет реализовывать этот проект? Кто за что будет отвечать на проекте?

f. Ресурсы. Какие дополнительные ресурсы вам потребуются для реализации проекта? Это могут быть знания, технические средства, место для работы и т.д.

g. Приоритеты внутри проекта. Что в проекте важнее всего из параметров? Сроки, бюджет, качество, объем? Возьмем, например, самолет. В нем важны, в первую очередь, качество и объем. Объем нельзя урезать, да и качество должно быть максимальным. Теперь возьмем социальную сеть. В ней могут быть важны бюджет (т.к. это деньги инвестора) и качество. Объем здесь не так важен – его можно развивать по ходу запуска проекта. Понимание приоритетов даст вам в будущем возможность варьировать параметры проекта. Например, вы не успеваете сделать в срок, а сроки являются приоритетом. Что делать? Либо уменьшайте объем, либо увеличивайте бюджет, либо внедряйте более простые и быстрые решения. При этом, разумеется, вы исходите из прописанных приоритетов проекта.