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

6cb68d474d704a019aad2619a1b3b701.pngКогда в голову приходит очередная бизнес-идея, часто даже самое неглубокое погружение в поиск Яндекса или 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) позволяют изменять систему так гибко и настолько быстро, насколько это возможно. При этом не возникает проблем с эксплуатацией решения пользователями. Но нужно помнить, что на любом этапе развития в первую очередь должны быть решены вопросы логики работы, хранения данных и безопасности.


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

© Habrahabr.ru