Расти большой: простые советы для создателей новых бизнес-приложений

    Когда в голову приходит очередная бизнес-идея, часто даже самое неглубокое погружение в поиск Яндекса или Google не оставляет от неё камня на камне — как известно, всё придумано до нас.

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

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

    Задавайте себе вопросы


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

    Составить бизнес-требования — совокупность задач пользователей, которые призваны решать ваши сайт, приложение, ПО. Лучше всего, если это будут чётко описанные процессы, указывающие на стороны и механизмы взаимодействия. Например, у нас это упрощённо выглядело так:

    Сторона 1. Заказчик услуги — лицо, оставляющее заявку на сайте через специальную форму с набором заполняемых из справочника и открытых полей.
    Сторона 2. Исполнитель — лицо (компания), реагирующее на полученную заявку и передающее свои условия исполнения заказа: цену, количество, сроки, иные параметры.
    Процесс: выбор заказчиком лучшего предложения из списка исполнителей.

    Установив такую схему, легко понять, что необходимо реализовать в системе. Смотрим на пример:

    • лицо, компания — карточка компании, карточка физического лица, аутентификация, авторизация
    • заявка на сайте, варианты исполнителя, выбор — система внутреннего отслеживания, почтовый клиент
    • услуги, перечень — заполненные справочники
    • создание запроса — формы запроса с различными полями, зависящими от услуги
    • отслеживание запроса, выбора, ответа — личный кабинет, история заявок и ответов.

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

    Собрать требования к интерфейсу пользователя. Зная основной функционал будущей программы, можно предположить, какие блоки должен включать интерфейс, как они будут взаимодействовать с пользователем и между собой. Иногда на этом этапе компании уделяют слишком большое внимание цветам, стилю, шрифту. Это, безусловно важные элементы и над ними должен потрудиться профессиональный дизайнер и проектировщик, но пока важнее другое — юзабилити. Воспроизведите действия пользователей, запроектируйте их последовательность, смоделируйте логику взаимодействия компонентов программы. В принципе, для этого есть масса сервисов, доступных разработчику, можно (а часто и нужно) использовать даже UML-диаграммы. Но помните, что если рядом с вами в проектировании принимают участие люди, не связанные с программированием, но знающие аудиторию и рынок, то лучше всего вам помогут маркерная доска и флипчат. На первом этапе нужно собрать действительно все детали, UML вас дождётся.

    Определиться с архитектурой программы. На этом этапе проектируются бэкенд, фронтенд, прослойка. Исходя из планируемой нагруженности проекта, выбирается фреймворк и СУБД, планируются трудовые ресурсы.

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

    • Наша команда разработчиков владеет многими языками программирования, но для гибкого и постоянно обновляемого приложения мы отдаём предпочтение PHP.

    • В программе планировалось внедрить множество форм заявок. Всё оказалось серьёзнее, чем мы думали: шутка ли, уже сейчас 22 абсолютно разных раздела услуг, от WEB-сайта на заказ до автозапчастей и туризма. И это число ежемесячно растёт.

    • Нам будут нужны сложные пользовательские фильтры.

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

    • Нам нужен почтовый клиент и удобная интеграция с ним. Кстати, мы выбрали Amazon Simple Email Service (SES) — его инфраструктура показалась наиболее удобной с точки зрения рассылки огромного количества писем.

    • Нам нужна возможность постоянной и глубокой доработки системы — она находится в постоянном развитии и на тот момент у нас не было чёткого видения её конечного состояния.

    • Нам абсолютно не подходит ни одна CMS и мы хотим обеспечить максимум управляемости сайта.

    • Мы любим jQuery — за её простоту, лёгкое обращение к элементам DOM и API для работы с AJAX.

    • Интерфейс будет простым и понятным.

    • Нам важна производительность.

    Мы долго изучали возможности различных фреймворков, спорили, слушали доводы адептов того или иного инструмента. В конце концов, выбор пал на…

    ...Yii. Тогда ещё первый.


    Это было взвешенное и обоснованное решение. У нас к фреймворку было много вопросов и только Yii, соответствуя одной из версий происхождения названия, ответил на большинство из них: «Yes, it is». Итак, чем нас привлёк именно этот инструмент разработки?

    • Yii обеспечил скорость разворачивания, стабильность поддержки и постоянно вносимых изменений. К тому же, он очень хорошо документирован и на русском, и на английском языках — вся команда разработчиков могла разобраться в нюансах работы с фреймворком.

    • Наш сервис был задуман как портал, предполагающий авторизацию и хранение пользовательских данных. И в этом Yii нам здорово помог. Строгие алгоритмы безопасности обеспечивают надёжную защиту от хищения cookies и SQL-инъекций (внедрения SQL-кода). Пока нам не понадобилось самостоятельно добавлять средства защиты.

    • Клиентская часть Yii использует jQuery, простую, популярную и любимую нами библиотеку JavaScript.

    • В Yii великолепно реализована и документирована работа с формами, в том числе обеспечивается валидация вводимых данных.

    • Yii незаменим для командной работы. Он имеет хорошую систему контроля доступа для разработчиков и предусматривает совместное использование директории фреймворка.

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

    • Фреймворк значительно расширяет возможности PHP, множество библиотек с компонентами просто созданы для разработки бизнес-приложений. Фактически, каждый компонент можно использовать как расширяемый.

    • Наконец, Yii хорош для тестирования: отлично настраивается тестовое окружение, запускаются unit-тесты, а логирование ошибок делает отладку проще.

    Гибкий, производительный и к тому же open source фреймворк позволил нам в кратчайшие сроки создать и развернуть web-портал Bonjoin. На сегодняшний день мы большее внимание уделяем фронтенду, поскольку пользовательский интерфейс требует постоянных доработок.

    Что дальше?


    Сейчас мы активно изучаем Yii2, не в пример более мощный, чем его предшественник. Перед нами стоят новые вызовы и мы хотим использовать существующий проект ещё в нескольких направлениях.

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

    В итоге мы сформулировали правила, которые, возможно, помогут тем, кто стоит на пороге реализации идеи своей программы.

    • Нельзя заранее предвидеть конечное состояние программы — это обусловлено и технологиями, и потребностями пользователей, и ограничениями.

    • Обязательно будут ограничения — по знаниям, времени, ресурсам. И вы должны научиться вписываться в них, чтобы выйти на рынок и уже в ходе работы вносить изменения.

    • Все инструменты разработки должны соответствовать целям вашего бизнеса. Если вы выберете язык программирования, фреймворк, базу данных, почтовый клиент, CMS исходя из дешевизны, понятности и простоты, вы можете упереться в серьёзные ограничения.

    • Проектирование на начальном этапе даёт значительное ускорение разработки и сильно упрощает взаимодействие дизайнеров и разработчиков.

    • Важно уделять внимание не только фронтенду, но и бэкенду, и дизайну. Мы сделали несколько ошибок и сейчас исправление их стоит нам времени и средств.

    • Попробуйте обратиться к спиральной модели разработки, которая не только предполагает быстрое создание рабочего прототипа, но и преодолевает риски, с которыми на начальном этапе сталкиваются многие небольшие разработчики: риск сроков выхода на рынок, недостаточности бюджета и ограниченных человеческих ресурсов. Более того, спиральная разработка даёт ещё одно важное преимущество: ваш продукт развивается не в лабораторных условиях на основе гипотез, а получает разнонаправленный фидбэк от сотен и тысяч пользователей. Их обращения дают понять, где требуются внести изменения на следующей итерации. Однако, используя спиральную модель разработки, важно не забывать, что инструменты программистов должны позволять вносить изменения максимально быстро и с наименьшими рисками для устойчивости системы в целом. Кстати, это одна из причин выбора фреймворка Yii — компонентная логика, ООП в основе и парадигма MVC (Model-View-Controller) позволяют изменять систему так гибко и настолько быстро, насколько это возможно. При этом не возникает проблем с эксплуатацией решения пользователями. Но нужно помнить, что на любом этапе развития в первую очередь должны быть решены вопросы логики работы, хранения данных и безопасности.

    Путь работы над ошибками и непрерывной доработки проекта ещё более интересный, чем путь разработки. Особенно он интересен, если в ходе исправлений вы обращаетесь к более совершенным инструментам и технологиям. В любом случае, главное — не останавливаться, ведь весьма вероятно, что ваша идея уже зреет в чьей-то голове.
    БонДжойн
    0.00
    Company
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 15

      +2
      «Очевидно, что под эти задачи и бизнес-процессы нужен совершенно другой фреймворк»

      Почему?
        0
        Не знаю, как вам, а мне ответ очевиден из поста и из практики: Yii1 сменился гораздо более продвинутым, если не сказать, что вообще другим Yii2. Для нагруженных проектов лучше выбрать Yii2. Как говорится, лучше день потерять, а потом за пять минут долететь, то есть переползти на новое и развиваться вместе с ним. Хотя дело вкуса.
          0
          Описанные задачи можно решить и на Yii 1.x и на Yii 2.x Мне интересно, что такого есть в Yii2 (и чего нет в Yii1) когда для
          «учёт налогов и выплат, управление кадровым резервом для малых компаний, аутсорсинг персонала» выбирается именно вторая ветка, при условии что весь портал написан на первой. Затраты на миграцию кто-то считает? Или лишь бы «программисты радовались»?
            0
            Как-то вы кусочками читаете и цитируете. Думаю, переход обусловлен как раз «базированием» чужих партнёрских и дилерских сетей. Это предъявит проекту беспрецендентные требования по организации хранения данных и безопасности, понятно же, не?
              –1
              Промахнулся веткой, ответ ниже.
        +1
        «базированием» чужих партнёрских и дилерских сетей

        как это вообще связано с фреймворком?
        Это предъявит проекту беспрецендентные требования по организации хранения данных и безопасности

        Как хранение данных и безопасность вообще связаны с фреймворками и тем более их версиями?
        понятно же, не?

        Неа.
          0
          Да, во-первых, безопасность. Yii2 надёжнее в плане защиты от кражи и имитации cookie, SQL-инъекций и проч. атак. Во-вторых, проще работать с БД. Упрощена работа с формами, на которой походу много тут завязано. Ну и расширений всяких побольше.
          А что вы предлагаете, кстати? Чем вас так смутило желание переезда на более мощный фреймворк?
            +5
            Мне кажется, что безопасность приложенния — это дело не фреймворка, а разработчика.
            Или вам не попадались проекты с таким, например, кодом:
            Yii::$app->db->createCommand('SELECT * FROM USER WHERE ID = '.$_GET['ID'])->queryAll(); //псевдокод
            

            Про то, что вывод почти везде НЕ «эскейпится» можно даже не говорить (даже в Yii2-проектах).
            Синтаксис AR изменился, да. Но это не «хранение информации», это лишь доступ к ней.
            Меня смутила мысль, что есть бизнес-задачи, для которых ну никак не подходит Yii1 и очень очень подходит Yii2, хотелось бы аргументов.
            Перезд на другую версию только ради переезда на другую версию для большого проекта в 80 % выгоден только девелоперам — прокачивают новый скилл и пишут на новом фреймворке.

          +1
          Чем мне, как программисту, не очень нравятся подобные идеи для IT-стартапов, так это тем, что успех проекта состоит всего лишь процентов на 20 от программирования, а остальные 80% — это беготня с целью договориться с кучей компаний, чтобы они пользовались порталом и реагировали на запросы. В итоге, получается какая-то контора продажников.
            0
            Вечная борьба разработки и коммерции, покуда мир стоит :-) Мне удалось побывать по обе стороны. Скажу одно: программисты плохо продают, продажники вообще не пишут код. Нужно уважение, нужен баланс. «Беготня» — это серьёзный труд, требующий знаний, умений, ресурсов. Если не продать и не раскрутить, в компании не будет денег ни для кого. Да и какая разница, какое соотношение служб — гораздо важнее конечный результат, прибыль.
              –2
              Это только мое субъективное мнение. Я очень уважаю труд менеджеров по продажам, и во многих стартапах он незаменим. Но, имхо, мне больше нравится, когда стартап, который считает себя IT-стартапом, сосредоточен на создании продукта, который сам по себе содержит интеллектуальную ценность и является товаром, который можно продавать.
              Например, можно написать Платформу 1С, а можно написать магазин для продажи телефонов, который без телефонов и без их поставщиков — 0 без палки. По-моему, разница существенная.
                0
                Да ладно вам… Ни один продукт сам себя не продаст, особенно сегодня. Хотя бы потому, что придёт компания с отстойным аналогом, но с кучей денег и раскрутится, а стартапная супер-программа сдохнет.
                1С никогда не стал бы 1С, если бы не напокупал за гигантские деньги кучу франчайзи в своё время, не понадавал «бонусы» ключевым компаниям и т.д… У них был, есть и гарантированно будет один из самых зверски мощных маркетингов :-) Или возьмём Консультант Плюс — как они сделали рынок! Но теми же методами, сам софт по себе никуда не пошёл…
                  0
                  Вы либо не понимаете, что я хочу сказать, либо смотрите на все с какой-то абсолютно другой точки зрения. Где я написал, что 1С-Платформе (или любому полноценному IT-продукту) не нужен маркетинг?
                  0
                  Платформа 1С никому не нужна без конфигураций, в которых коммерческие организации ведут учёт. И многие конфигурации как раз были созданы уже упомянутыми купленными партнёрами-франчайзи. Равно как же хороший движок для интернет-магазина покупают сам по себе, чтобы потом на его базе вести свой кусок электронной торговли. В любом случае конечная цель практически любого продукта — его коммерческая составляющая.
                    0
                    Написать универсальный движок интернет-магазинов для продажи и написать магазин под свой бизнес (или просто заточить какой-то движок) — это абсолютно разные вещи и по трудозатратам, и по целям. Не нужно их путать.
                    Конфигурации никому не нужны без платформы 1С. А вот телефоны без интернет-магазина очень даже.

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