2021-08-04 09:30:43
С чего начинать разработку?Когда у меня еще не было коммерческого опыта разработки, при старте нового проекта я сразу бросался с головой в написание кода. Получалось так себе, но поскольку это были pet-проекты - и так сойдет.
Получив опыт в нескольких компаниях, я улучшил свой подход. Перед началом разработки я начинал с выяснения функциональных требований, после чего набрасывал примерную архитектуру и только после этого кодил.
Пару лет назад я взял заказной проект параллельно к основной работе. Нужно было сделать кастомную CRM для небольшого бизнеса. По неопытности я не вник в специфику бизнеса, не задавал правильных вопросов, слишком быстро приступил к разработке и озвучил низкую цену, не понимая объема продукта.
Повезло что у бизнеса поменялись приоритеты и мы быстро закрыли проект. Сейчас я понимаю что не затащил бы этот заказ на нужном уровне. Получилось бы говно, которое делалось долго, стоило дешево и нуждалось в постоянной поддержке.
По мере нашего развития, также эволюционируют наши методы и подходы. Учитывая весь предыдущий опыт на данный момент я выработал для себя следующий алгоритм, который помогает учесть большинство деталей на старте, заложить правильный фундамент и эффективно разрабатывать продукт.
При старте работы над Creatly я начал с проработки концепции. Продуктовая разработка отличается от заказной, поэтому важным этапом является изучение рынка, конкурентов, описание проблематики, целевой аудитории и тд. Грубо говоря все то, чем занимаются продакт менеджеры.
Когда сформировалось первичное видение продукта, я начал с брейншторминга в Whimsical и высокоуровневого описания продукта в Google Docs. Оно описывает всю продуктовую часть, а также функциональные требования, то есть всю логику приложения. Этот документ послужил отличным ТЗ для дизайнера. Ознакомившись с документов и обсудив со мной ряд вопросов, он смог приступить к UI/UX прототипированию.
Для меня же этого уже было достаточно чтобы спроектировать первичную модель данных. Данные - центральная часть любого приложения, поэтому моделирование БД - один из первых этапов в дизайне архитектуры. От принятых решений на этом этапе может зависеть качество и успех продукта в долгосрочной перспективе.
Сначала я все проектировал под Postgres, но потом решил взять MongoDB. Учитывая то, что это стартап, модель данных будет постоянно видоизменяться и расширяться. Поэтому NoSQL показался мне более разумным выбором.
После этого я приступил к высокоуровневому проектированию архитектуры на бекенде: описывал API эндпоинты в Swagger, а также набор сущностей, сервисов, репозиториев и их методов в коде.
Дальше я уже думал о выборе инфраструктуры, хостинге базы, фронтенд & бекенд приложений.
Всей фронтенд частью продукта заведует мой партнер (Женя здарова ), поэтому моя задача по фронту свелась к деплойменту бекенда на staging окружения для удобной работы с API, деплойменту самого фронтенд приложения, а также составлению ТЗ и списка задач.
На старте проекта я потратил много времени на описание продукта и прототипирование архитектуры. Первую строчку кода я написал только через 3 недели или месяц.
Разработка успешных продуктов - это долгосрочная игра. Когда софт пишут по 10-15 лет, то неправильные решения на начале могут очень дорого стоит в последствии.
Поэтому важно заложить фундамент. Не бойтесь потратить больше времени на дискуссии, составления или выяснения функциональных требований, специфики бизнеса, бюджета на инфраструктуру и тд. Правильные решения на старте помогут быстро и эффективно двигаться дальше.
Намного более подробно о том, как стартовать, валидировать и проектировать продукты я рассказал в одном из видео у себя на канале, если вам интересна данная тема - рекомендую глянуть.
770 views06:30