Когда в голову приходит очередная бизнес-идея, часто даже самое неглубокое погружение в поиск Яндекса или 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) позволяют изменять систему так гибко и настолько быстро, насколько это возможно. При этом не возникает проблем с эксплуатацией решения пользователями. Но нужно помнить, что на любом этапе развития в первую очередь должны быть решены вопросы логики работы, хранения данных и безопасности.
Путь работы над ошибками и непрерывной доработки проекта ещё более интересный, чем путь разработки. Особенно он интересен, если в ходе исправлений вы обращаетесь к более совершенным инструментам и технологиям. В любом случае, главное — не останавливаться, ведь весьма вероятно, что ваша идея уже зреет в чьей-то голове.
Комментарии (15)
xoma
10.11.2015 13:23+1«базированием» чужих партнёрских и дилерских сетей
как это вообще связано с фреймворком?
Это предъявит проекту беспрецендентные требования по организации хранения данных и безопасности
Как хранение данных и безопасность вообще связаны с фреймворками и тем более их версиями?
понятно же, не?
Неа.
Subrisk
10.11.2015 13:39Да, во-первых, безопасность. Yii2 надёжнее в плане защиты от кражи и имитации cookie, SQL-инъекций и проч. атак. Во-вторых, проще работать с БД. Упрощена работа с формами, на которой походу много тут завязано. Ну и расширений всяких побольше.
А что вы предлагаете, кстати? Чем вас так смутило желание переезда на более мощный фреймворк?xoma
10.11.2015 13:58+5Мне кажется, что безопасность приложенния — это дело не фреймворка, а разработчика.
Или вам не попадались проекты с таким, например, кодом:
Yii::$app->db->createCommand('SELECT * FROM USER WHERE ID = '.$_GET['ID'])->queryAll(); //псевдокод
Про то, что вывод почти везде НЕ «эскейпится» можно даже не говорить (даже в Yii2-проектах).
Синтаксис AR изменился, да. Но это не «хранение информации», это лишь доступ к ней.
Меня смутила мысль, что есть бизнес-задачи, для которых ну никак не подходит Yii1 и очень очень подходит Yii2, хотелось бы аргументов.
Перезд на другую версию только ради переезда на другую версию для большого проекта в 80 % выгоден только девелоперам — прокачивают новый скилл и пишут на новом фреймворке.
summerwind
10.11.2015 20:17+1Чем мне, как программисту, не очень нравятся подобные идеи для IT-стартапов, так это тем, что успех проекта состоит всего лишь процентов на 20 от программирования, а остальные 80% — это беготня с целью договориться с кучей компаний, чтобы они пользовались порталом и реагировали на запросы. В итоге, получается какая-то контора продажников.
Itimora
10.11.2015 22:54Вечная борьба разработки и коммерции, покуда мир стоит :-) Мне удалось побывать по обе стороны. Скажу одно: программисты плохо продают, продажники вообще не пишут код. Нужно уважение, нужен баланс. «Беготня» — это серьёзный труд, требующий знаний, умений, ресурсов. Если не продать и не раскрутить, в компании не будет денег ни для кого. Да и какая разница, какое соотношение служб — гораздо важнее конечный результат, прибыль.
summerwind
11.11.2015 00:35-2Это только мое субъективное мнение. Я очень уважаю труд менеджеров по продажам, и во многих стартапах он незаменим. Но, имхо, мне больше нравится, когда стартап, который считает себя IT-стартапом, сосредоточен на создании продукта, который сам по себе содержит интеллектуальную ценность и является товаром, который можно продавать.
Например, можно написать Платформу 1С, а можно написать магазин для продажи телефонов, который без телефонов и без их поставщиков — 0 без палки. По-моему, разница существенная.Itimora
11.11.2015 06:07Да ладно вам… Ни один продукт сам себя не продаст, особенно сегодня. Хотя бы потому, что придёт компания с отстойным аналогом, но с кучей денег и раскрутится, а стартапная супер-программа сдохнет.
1С никогда не стал бы 1С, если бы не напокупал за гигантские деньги кучу франчайзи в своё время, не понадавал «бонусы» ключевым компаниям и т.д… У них был, есть и гарантированно будет один из самых зверски мощных маркетингов :-) Или возьмём Консультант Плюс — как они сделали рынок! Но теми же методами, сам софт по себе никуда не пошёл…summerwind
11.11.2015 14:51Вы либо не понимаете, что я хочу сказать, либо смотрите на все с какой-то абсолютно другой точки зрения. Где я написал, что 1С-Платформе (или любому полноценному IT-продукту) не нужен маркетинг?
Subrisk
11.11.2015 11:26Платформа 1С никому не нужна без конфигураций, в которых коммерческие организации ведут учёт. И многие конфигурации как раз были созданы уже упомянутыми купленными партнёрами-франчайзи. Равно как же хороший движок для интернет-магазина покупают сам по себе, чтобы потом на его базе вести свой кусок электронной торговли. В любом случае конечная цель практически любого продукта — его коммерческая составляющая.
summerwind
11.11.2015 14:57Написать универсальный движок интернет-магазинов для продажи и написать магазин под свой бизнес (или просто заточить какой-то движок) — это абсолютно разные вещи и по трудозатратам, и по целям. Не нужно их путать.
Конфигурации никому не нужны без платформы 1С. А вот телефоны без интернет-магазина очень даже.
xoma
Почему?
Subrisk
Не знаю, как вам, а мне ответ очевиден из поста и из практики: Yii1 сменился гораздо более продвинутым, если не сказать, что вообще другим Yii2. Для нагруженных проектов лучше выбрать Yii2. Как говорится, лучше день потерять, а потом за пять минут долететь, то есть переползти на новое и развиваться вместе с ним. Хотя дело вкуса.
xoma
Описанные задачи можно решить и на Yii 1.x и на Yii 2.x Мне интересно, что такого есть в Yii2 (и чего нет в Yii1) когда для
«учёт налогов и выплат, управление кадровым резервом для малых компаний, аутсорсинг персонала» выбирается именно вторая ветка, при условии что весь портал написан на первой. Затраты на миграцию кто-то считает? Или лишь бы «программисты радовались»?
Subrisk
Как-то вы кусочками читаете и цитируете. Думаю, переход обусловлен как раз «базированием» чужих партнёрских и дилерских сетей. Это предъявит проекту беспрецендентные требования по организации хранения данных и безопасности, понятно же, не?
xoma
Промахнулся веткой, ответ ниже.