"Идея — это товар. Реализация — нет"
Майкл Делл, Dell
Приветствую! Сейчас немного тренером-мотиватором поработаю и задам вопрос: задумывался ли ты когда-то об открытии своего стартапа в сфере IT?
Я не собираюсь кого-то на что-то наталкивать, говорить "встань и иди к своей цели!", мы тут не для этого. Меньше слов, больше практической составляющей, которая поможет твоему замыслу стать явью.
Сколько же денег достать из-под матраса чтобы, заплатить команде разработчиков?
Небольшая вставка. Чтобы эта статья не выглядела как куча информации, которая ничем не обусловлена, я втисну пару слов о себе.
Я основатель вебстудии BlueberryWebStudio. Мы занимаемся разработкой сайтов и приложений любой сложности (предпочтительно повышенной). За несколько лет работы компании мы изменили множество методов оценки стоимости проектов, и сегодня я расскажу о каждом из них чтобы сложить базовое понятие от чего отталкиваться.
Начнем.
Во-первых, важно понимать, что IT-проект это не просто разработка, а как минимум три ключевые стадии:
- Анализ требований, написание Технического Задания
- Разработка
- Тестирование проекта
Как пишут в книжках, все эти три стадии примерно равны по времени, но на практике сравнивать можно разве что второй и третий пункты и то от силы. Например, я не могу себе представить проект в котором написание ТЗ, разработка и тестирование длятся одинаковое количество времени, а ты?
Классическая, правильно составленная команда должна включать в себя:
- Руководителя проекта (соблюдение качества и сроков висят на нем)
- Тимлид (как правило, самый опытный программист отвечающий за выбор технологии разработки, помощь разработчикам и пр.)
- Разработчики
- Тестировщики
- Бизнес-аналитик (в случае, если клиент хочет только заплатить деньги и получить готовый, продающий себя стартап, нанимается бизнес-аналитик, который отвечает за продажу и продвижение продукта. Конкретно у меня таких людей в команде нету, поскольку все наши клиенты самостоятельно продают свои проекты)
Если проект включает в себя пользовательский интерфейс, тогда добавляем дизайнера и UI / UX специалиста (если дизайнер не включает в себя 2 в 1)
Поэтому, если приходит клиент со словами: "вот этот проект нужно разработать. Просто разработать. Это же просто? Больше ничего не нужно", сразу же срабатывает сигнал СТОП. Человека нужно привести в чувства и рассказать то что я писал выше.
Во время разработки нужно также не забывать о Технической Документации проекта, которая поможет другой команде, в случае необходимости, подключиться к разработке.
Если очень кратко, то в ТД мы пишем общее положение проекта, что он из себя представляет, для чего создан и какие технологии использовались для разработки.
Пользовательская документация также присутствует, куда без неё.
Само собой, если твой проект - это сайт по продаже надувных шариков, тут я думаю все и так ясно. Но если проект сложный, к примеру, связанный с администрированием или включает в себя сложную систему создания предложений, тогда после себя, для предков, стоит оставить пользовательскую документацию.
С теорией разобрались, много, зато полезно. Теперь практика,
Итак, ниже перечислю 4 метода оценки сроков и бюджета, сочетание которых позволит быстро взвесить твой проект:
. 1. Экспертная оценка (Expert Judgement):
Собственно самый просто и популярный метод, который заключается в сборе команды разработчиков (или одного гуру) и анализе стартапа. Идея расщепляется на атомы и собирается снова в виде мелких этапов и подзадач. Такие маленькие процессы понимаются легче, и оценить соответственно тоже легче. Цены всех подзадач суммируются и затем выводятся итоговую смету
2. Метод оценки по 3 точкам (Three Point Estimation):
В рамках этого способа сначала определяются оптимистичная (O = Optimistic), пессимистичная (P = Pessimistic) и реалистичная\средняя (M = Middle) оценки.
Все значения определяются экспертно, в часах, днях и $.
Для этого задаются вопросы такого типа: «сколько времени займет проект, если все пойдет хорошо, не будет никаких рисков и проблем?», «каким может быть самый негативный сценарий и сколько на него потребуется времени\усилий?» и т.п.
Далее мы подставляем все данные в существующую формулу: (O + 4 M + P) / 6
Результат расчета дает усредненную оценку. Такая формула позволяет учесть возможные позитивные и негативные сценарии, а с другой стороны – «сгладить» их влияние и получить более реальное значение оценки.
3. Стоимость качества (Cost of Quality):
Интересная техника, в рамках которой сначала оценивается время или бюджет только на разработку функционала, без учета ошибок и проблем, как если бы у нас сразу получалось идеальное ПО без дефектов.
А далее оценивается, сколько дополнительного времени и бюджета потребуется на работу с ошибками и проблемами в реальности, чтобы приблизить ПО к тому самому «идеальному» состоянию.
При оценке затрат на обеспечение качества ПО можно проанализировать и учесть такие области:
- Расходы на активности по предотвращению дефектов
- Стоимость тестирования
- Исправление внутренних ошибок
- Исправление внешних проблем по интеграции
- Затраты на установку и настройку ПО с учетом реальной среды и данных
4. Оценка по аналогиям (Analogous Estimation):
Не универсальный метод который могут позволить себе только очень опытные ребята. Оценивать бюджет и сроки проекта исходя из опыта разработки прошлых, похожих на текущий.
Как на меня, самый шаткий, зато очень быстрый способ.
В условиях когда времени в обрез, а опыта разработки хоть отбавляй - идеально.
На этом всё! Спасибо за то что добил/-а статью до конца. Материала было много, но мы справились.
Подписывайся чтобы не пропустить новые: *клик*
Предыдущие статьи: