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

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

Глава 4. Предпроектная деятельность

Что мы должны сделать до начала проекта?

Во-первых, это общая оценка проекта.

Во-вторых, определить основные параметры проекта.

И, в-третьих, формализовать все моменты по проекту в виде концепции проекта (это письменный документ, а не что-то, что у вас в голове).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

● совещания

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

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

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

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

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

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

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

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

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

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

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

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

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

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