company_banner

Стартап глазами разработчика. Какой framework лучше выбрать

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

    Что объединяет эти идеи, и что это значит? Люди стали ценить свое время выше денег, которые они зарабатывают на работе. При этом необязательно иметь какую-то совсем уникальную идею, достаточно уметь делать что-то лучше других или иметь некоторую изюминку.

    В интернете много вдохновляющих историй о том, что вышел очередной перспективный стартап, который уже обрел многомиллионные инвестиции. На конференции «Продвижение», организованной Программой «Единая фронтальная система», много говорили о создании новых продуктов и о стартапах, а в финале конкурса даже выбирали лучшие идеи банковского приложения.



    И сегодня в нашем посте Николай Надоричев, лидер front-end разработки Программы «Единая фронтальная система» Сбербанка, расскажет о своем видении стартапов, о распространенных ошибках и о том, как с помощью технологии React создать приложение за один вечер.

    Подходы к разработке


    Что мы знаем о разработке стартапа? Она состоит из нескольких этапов:

    1. Proof of concept
    2. Получение инвестиций
    3. Сбор команды
    4. Разработка MVP
    5. Презентация инвестору и получение нового раунда финансирования

    Многие стартапы совершают ошибку, пытаясь разработать 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 — минимально жизнеспособный продукт. Он подразумевает то, что есть некоторый минимум приложения, который обеспечивает подтверждение концепции. Его основная цель — в том, чтобы показать, что продукт имеет право на жизнь. Он не требует детальной проработки архитектуры баз данных, работе под высокой нагрузкой и красивого дизайна. Зачастую он показывает некоторую интерактивную картинку, которую можно пощупать.

    И главное — не забывайте всегда думать о будущем проекта. Надо понимать, нужен ли продукт, каковы его дальнейшие перспективы. И если вы честно ответите себе на этот вопрос положительно – тогда стоит рваться в бой и побеждать. А вы пробовали участвовать в стартапе или организовывали свой? Какие успехи? Приглашаем к обсуждению в комментариях. 
    Сбер
    Больше чем банк

    Similar posts

    Comments 18

      +12
      поддержка сообществом
      продвижение гигантами IT-индустрии
      легкость освоения
      зрелость технологии

      А почему не: скорость разработки, сложность поддержки, багоёмкость, отзывчивость работы, наличие стандартной библиотеки, адаптивность?


      мы в Программе «Единая фронтальная система» выбрали основным фреймворком для разработки React.

      Звучит как "в качестве средства передвижения мы выбрали шины мишлен" :-) Говорите уж честно: вы создали свой уникальный фреймворк, в котором скомпоновали несколько известных библиотек, несколько неизвестных, нескольких велосипедов и кучу связующего их между собой кода.


      для React существует огромное количество написанных элементов UI, библиотек для управления состоянием приложения и других модулей.

      К сожалению, количество слабо коррелирует с качеством. Что лучше: 10 разношёрстных библиотек управления состоянием или одна, но идеально стыкующаяся с остальными компонентами фреймворка?


      На мой взгляд, здесь не нужны дополнительные комментарии: зачем разрабатывать на фреймворке, который убьет много времени на освоение?

      А сколько вы убили времени на освоение экосистемы Реакта и подгонку выбранного вами набора библиотек друг ко другу?


      О том, как создать приложение на реакте за один вечер, Николай рассказал на конференции.

      Я там увидел лишь создание мёртвой формы и вывод таблички с рандомными данными. Ни обработчиков действий пользователя, ни сетевых запросов, ни индикаторов загрузки, ни локализации, ни настроек для переиспользования в разных местах, ни дизайна в конце концов. Сколько займёт времени добавление всего этого?


      Зачастую он показывает некоторую интерактивную картинку, которую можно пощупать.

      Это называется "макет". MVP же должен реализовывать как минимум один бизнес процесс от начала и до конца. Иначе его Value = 0.

        0
        его Value = 0.

        Что и является минимально ценным продуктом :D

          0

          Ну, тогда ценность может быть и отрицательной, когда продукт ломает бизнес процессы :-D

            +1

            В таком случае его ценность становится опять положительной, просто уже для конкурентов :)

              0

              Игра с нулевой суммой же :)

        +4
        Чем MVP в вашем определении отличается от Proof of Concept?
          +3
          Ща выберем фреймворк, запилим сайт, а че за стартап потом разберемся.
            +3
            Сначала инвестиции получим!
            +2
            Стартап и Сбертех — это были не совместимые вещи! Лучше просто рассказывайте про Реакт и архитектуру ЕФС. Это будет всем интересно. Но не надо сейчас пугать людей Сбераджайлом. Может лет через пять, когда у вас все утрясется… Больше пишите по техническим вопросам и меньше по управлению проектами. Используйте ваши сильные стороны и не позорьте компанию там, где она слаба!
              0
              Используйте ваши сильные стороны

              Мне, например, было бы интересно узнать о достижениях Сбербанка в применении нейросетей в документообороте.

                0
                Где карту оформляли, туда и идите...
                Что вам Сбертех пишет, то и читайте… :)
              +1

              С помощью практически всех фреймворков/библиотек для фронтэнда, с которыми я когда-либо сталкивался, можно создать "приложение" за один вечер. А можно и совсем без. Аргументы в пользу React в статье — высосаны из пальца и по каждому пункту можно поспорить и посравнивать. Автору я бы посоветовал иногда вытаскивать голову из React экосистемы и оглядываться по сторонам. Хотя да, иногда React-головного-мозга неизлечим, как когда-то было с jQuery.

                0

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

                  0
                  Верно. Cobol — это круто!
                  0
                  А почему не Vue.js. Все тоже что и в рект, angular подобно, + порог вхождения намного ниже.
                    0
                    >>>Если у продукта за плечами стоит огромная корпорация, то велик шанс того, что он внезапно закроется, >>>>превратив ваш мегапроект в кучу legacy-кода.

                    По-моему, здесь опечатка. Как размер корпорации может отрицательно повлиять на жизнеспособность продукта?
                      0
                      Искали фреймворк, взяли реакт

                    Only users with full accounts can post comments. Log in, please.