Мы живем в такое время, когда люди устали делать те или иные операции вручную и готовы платить деньги за то, чтобы за них это делали другие. Причем неважно, идет ли речь о записи к врачу, поиске подрядчика, выгодных авиабилетов, уборке дома или приготовлении вкусного домашнего обеда.
Что объединяет эти идеи, и что это значит? Люди стали ценить свое время выше денег, которые они зарабатывают на работе. При этом необязательно иметь какую-то совсем уникальную идею, достаточно уметь делать что-то лучше других или иметь некоторую изюминку.
В интернете много вдохновляющих историй о том, что вышел очередной перспективный стартап, который уже обрел многомиллионные инвестиции. На конференции «Продвижение», организованной Программой «Единая фронтальная система», много говорили о создании новых продуктов и о стартапах, а в финале конкурса даже выбирали лучшие идеи банковского приложения.
И сегодня в нашем посте Николай Надоричев, лидер front-end разработки Программы «Единая фронтальная система» Сбербанка, расскажет о своем видении стартапов, о распространенных ошибках и о том, как с помощью технологии React создать приложение за один вечер.
Подходы к разработке
Что мы знаем о разработке стартапа? Она состоит из нескольких этапов:
- Proof of concept
- Получение инвестиций
- Сбор команды
- Разработка MVP
- Презентация инвестору и получение нового раунда финансирования
Многие стартапы совершают ошибку, пытаясь разработать MVP до похода к венчурным фондам. Это приводит к тому, что со временем мотивация команды падает, и увеличивается вероятность того, что проект не увидит свет. Чтобы этого не случилось, необходимо четко понимать, когда стоит остановиться и выводить продукт вовне. Если взглянуть на консалтинговые компании, то можно увидеть, что многие их продукты проходят стадию presale, когда время на разработку жестко фиксируют, чтобы не допустить разбазаривания ресурсов компании.
В команде должен быть явный лидер, который будет отстаивать интересы команды при общении с потенциальным заказчиком. Кроме того, у него должно быть четкое видение продукта, способность предвидеть подводные камни и возможные проблемы. Причем не только в техническом плане, но и в плане коммуникаций. В крупных компаниях, как правило, эту роль выполняет владелец продукта, в компаниях поменьше — тимлид.
Причины неудач
Мы придумали стартап, он классный, но не выстрелил. Почему?
Первая причина — попытка объять необъятное. Многие молодые разработчики, уверенные в своих силах, чувствуют себя супергероями. Они пытаются создать идеальное решение, но на это уходит слишком много времени.
Вторая причина — проработка детальной архитектуры приложения. Всегда хочется создать идеальный продукт с идеальной архитектурой. Но это работает только в крупных корпорациях, где есть возможность финансировать даже продукт, в котором не написано ни одной строчки кода. И часто это отсылка к водопадной модели разработки.
Однако затягивание процесса получения обратной связи от инвестора может повлечь колоссальные затраты по переписыванию кода. Если есть в команде человек, который знает гибкие методологии разработки, то полезно будет построить разработку по модели scrum. Если такого человека нет, то можно не использовать методологии разработки вовсе. Достаточно общего командного чата для оперативного решения возникающих проблем и задач.
Стек технологий
Фреймворк
У нас есть идея, теперь нужно создать приложение. С чего начать? Прежде чем перейти к выбору технологий, необходимо определиться с тем, какие технологии нам нужны.
Во-первых, необходимо определиться с фреймворком, который будет использоваться в проекте. Основная цель фреймворка — задать правила игры, по которым будет происходить разработка продукта. В мире фронтенда огромное количество различных технологий, но давайте обозначим критерии выбора:
- поддержка сообществом
- продвижение гигантами IT-индустрии
- легкость освоения
- зрелость технологии.
Начнем по порядку. Поддержка сообществом подразумевает количество npm-пакетов, которые могут расширить функционал приложения, а также количество коммитов в проекте от внешних разработчиков. Далее обратим внимание на продвижение гигантами IT: каким бы хорошим продукт ни был, всегда важна его узнаваемость. Если у продукта за плечами стоит огромная корпорация, то велик шанс того, что он внезапно закроется, превратив ваш мегапроект в кучу legacy-кода. Третий немаловажный факт — легкость освоения. На мой взгляд, здесь не нужны дополнительные комментарии: зачем разрабатывать на фреймворке, который убьет много времени на освоение? И последний по списку, но не по важности параметр — зрелость. Как долго технология существует на рынке? Как активно развивается? Ответив на эти вопросы словами «давно» и «активно», можно говорить о том, что технология вам подходит.
Исходя из этих соображений, мы в Программе «Единая фронтальная система» выбрали основным фреймворком для разработки React. Почему? Давайте пройдемся по всем пунктам: для React существует огромное количество написанных элементов UI, библиотек для управления состоянием приложения и других модулей. Это делает возможным не делать часть своей работы — можно просто взять готовый компонент и встроить его в приложение.
Ко всему прочему, React прост в освоении и разработчиков, знающих его, на рынке довольно много. Это позволит собрать команду и отправить ее сразу в бой.
При всех преимуществах React имеет ложку дегтя в виде сложной настройки проекта. К счастью, Facebook позаботился об этом и выпустил проект Create React App. Он изначально заточен на быстрый старт проекта с переходом от идеи сразу к разработке.
О том, как создать приложение на реакте за один вечер, Николай рассказал на конференции. Смотрите видео-инструкцию.
UIKit
Позволить себе создать свой собственный уникальный набор UI-компонентов могут только компании, у которых уже есть отдельная команда для разработки UIKit'а. Известны истории, когда UIKit разрабатывается всеми продуктовыми командами совместно, но у этого подхода есть ключевой недостаток: чем больше разработчиков, тем больше мнений. И в конечном счете это приведет к тому, что каждая команда будет перетягивать одеяло на себя.
Но наша цель — выпустить MVP в короткие сроки. На просторах сети есть множество готовых решений, как платных, так и open source. Можно назвать несколько популярных:
У каждого из них свой дизайн, остается только выбрать, какой больше нравится.
MVP
Или Minimum Viable Product — минимально жизнеспособный продукт. Он подразумевает то, что есть некоторый минимум приложения, который обеспечивает подтверждение концепции. Его основная цель — в том, чтобы показать, что продукт имеет право на жизнь. Он не требует детальной проработки архитектуры баз данных, работе под высокой нагрузкой и красивого дизайна. Зачастую он показывает некоторую интерактивную картинку, которую можно пощупать.
И главное — не забывайте всегда думать о будущем проекта. Надо понимать, нужен ли продукт, каковы его дальнейшие перспективы. И если вы честно ответите себе на этот вопрос положительно – тогда стоит рваться в бой и побеждать. А вы пробовали участвовать в стартапе или организовывали свой? Какие успехи? Приглашаем к обсуждению в комментариях.
Автор: EFS_programm
