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