Заказная разработка VS Стартап. Часть 2. Про заказные проекты
В прошлой части я рассказал общую концепцию стартапа и поиска инвестора. Давайте поговорим о заказной разработке, как альтернативе стартапа.
Основная концепция заказной разработки в том, что Заказчик все продумал или совместно с Подрядчиком продумывает на этапе Технического задания (это может быть отдельный этап проекта).
Следом они готовят макеты будущего проекта, где видны все поля, элементы управления и прорабатывается поведение пользователей. Итоговые макеты фиксируются как основа для разработки программного кода.
Важно отметить, что макет более не меняется. А если меняется, это может повлечь перетряску всего проекта.
Следом разработка разбивается на этапы, чтобы постепенно реализовать программный код проекта.
Дальше стороны входят в этап тестирования, отловки багов и правки, пока проект не будет эквивалентен согласованному макету и поведению пользователей.
После сдачи работ Заказчик идет к своей аудитории или инвесторам и история может повториться, как и в стартапе, только правки и тестирование гипотез будет уже отдельными этапами разработки и т.п. Дольше, сложнее, потому что продукт уже готов. Это отдельная проблема для стартапа в целом.
И в случае внесения изменений в макет, стороны вполне могут согласовать доп.соглашением оценку новых работ или у них заранее могут быть договоренности о переносе сроков, если такие задачи будут появляться.
В части ведения проекта перекройка проекта не допускается. Вся разработка лежит на команде производства, Заказчик участвует только в консультационных моментах, приемке-сдаче работ, обсуждении наличия/отсутствия/разработки доп.материалов (логотипы, банеры и т.п.).
Как и в любом проекте бывают срывы сроков. Даже так скажу, что срывы сроков происходят с высокой степенью вероятности. На эти случаи стороны обсуждают планы дальше, могут срезать какие-то работы или переносить сроки.
Бывает, что проекты останавливаются из-за срыва сроков, это вопрос переговоров и доверия сторон. В этом случае сроки, конечно, будут нарушены точно, и новому подрядчику будет сложно продолжить проект.
Бывает и некачественная разработка. Но тут тонкости разработки ТЗ, приемки и нюансов. Качество во многом можно контролировать.
——
Как вы уже поняли, ключевое отличие в том, что скорости и гибкости тут практически нет. А у Подрядчика нет никакой мотивации что-то пробовать, они делают проект по плану и решают задачи. Им ничего про гипотезы и тестирование рынка не нужно знать.
Конечно, бывает такая разработка, что каждый этап очень короткий, чтобы на его этапе разобраться в чем-то и в новом этапе сделать что-то другое на базе предыдущего.
Но это всеравно не дух стартапа, тут все с зарплатами, с соц.пакетом, и за деньги беспокоится Заказчик и менеджмент проекта на стороне Подрядчика.
