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

Здесь я обозначу основные моменты, чтобы я делал бы на месте человека, который начинает веб-проект

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

Первым делом я бы уменьшил до минимума функциональность. Можно выделить ядро продукта и сделать на нем акцент. А все остальное просто пока отложить до лучших времен. Это позволит прописать ключевую часть более подробно и сделать ее более качественно.

Также косвенным образом это влияет на сроки и бюджет. Дешевле, проще и быстрее внедрить нечто небольшое, нежели долго и упорно делать продукт-фарш. Поэтому первый этап - выделение ядра проекта.

Предположим, что я не особо понимаю в разработке сайтов, и моя сфера никак не пересекается с IT.

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

Я не буду слепо доверять их мнению, и мне будут нужны обоснования.

Допустим, я нашел пару человек для подобных консультаций (в идеале они не должны быть заинтересованными лицами). Я ни в коем случае не буду злоупотреблять их вниманием и временем, формулируя все максимально просто, четко и понятно, а не сидеть у них на ушах с банальными вопросами. Банальные вопросы по веб-разработке можно проработать здесь.

Далее, подбор команды я буду делать в соответствии с принципами, описанными в другой статье.

Параллельно с проектом я буду изучать теорию стартапов, основы веб-разработки и продвижения в сети для базового понимания что к чему, и где могут возникнуть проблемы на пути моего решения. Большая статья про создание своего IT продукта

Обязательно я уделю время финансовому планированию. Даже при всех неопределенностях, которые есть в проекте, необходимо построить свои ожидания относительно затрат, плюс буду сверять свои расходы с начальным финансовым планом. Какие-то траты будут адекватны сложившейся ситуации, какие-то траты будут просто актом веры, что это пока не работает, но потом будет работать.

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

Так проще контролировать процесс, это позволит мне вовремя понять, что с подрядчиком что-то не так. От подрядчиков я буду требовать твердых артефактов, а не просто уверения, что все будет хорошо.

На проекте будут промежуточные контрольные точки (например, сдача этапа), которые помогут мне держать руку на пульсе.

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

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

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

P.S. О рисках проекта есть отдельная статья - Риски веб-проекта. Также посмотрите - Как можно выбрать подрядчика, не понимая деталей процесса разработки?

Уделите особое внимание причинам провала веб-проектов.

Источник: