Добрый день, коллеги!
Сегодня я расскажу как в очень сжатые сроки спроектировать и запустить высоконагруженный интернет-магазин с нестандартным функционалом… на платформе 1С-Битрикс.
Если подходить к задаче разработки большого интернет-магазина формально, описывая каждый миллиметр будущего проекта, то у вас получится ТЗ на несколько сотен, если не тысяч листов и десятки диаграмм и экранных форм. И писать вы его будете, скорее всего, не менее полугода… впятером, ночуя на работе. Но самое «страшное» впереди — когда вы его наконец торжественно допишите и объявите об этом выпучив воспаленные глаза, с огромной долей вероятности поменяются требования к проекту: рыночные условия за полгода изменились, приходят и уходят люди, ваши начальники и подчиненные, появляются новые идеи и у них и у вас и т.п. И придется срочно нанимать 10 переписчиков и так до бесконечности :-)
С другой стороны, если ТЗ написать маленьким, страниц на 10, за выходные, и все его согласуют… не читая, то вам придется поселиться в команде разработки для конкретизации требований и ответов на поражающие своей точностью мозгоразжижающие вопросы: «А напишите пожалуйста формулу расчета скидки при оплате продукта долларами с учетом погрешности машинного нуля». Скорее всего, больше недели вы не продержитесь и проект так и не появится.
Так что же делать, если на проектирование отведен месяц, на программирование — три, вы не хотите поселяться в команде разработки, а кто-то уже публично объявил дату запуска проекта? :-)
Прежде всего, осознайте, что над платформой 1С-Битрикс много лет трудились не только программисты, но и талантливые системные и бизнес-аналитики и воспользуйтесь их опытом! К счастью для вас, самые сложные и трудные для понимания вопросы электронной торговли — давно разжеваны, адаптированны к российским реалиям и превратились в простые концепции, разбитые для простоты восприятия на модули платформы 1С-Битрикс: «Интернет-магазин», «Торговый каталог» и «Валюты».
Вам остается:
1) Хорошо понять внутреннюю логику и терминологию данных модулей. Это ключевой пункт. Можно потратить на это выходные, дело стоит того.
2) Увидеть, какие небольшие блоки осталось добавить, чтобы получился публично анонсированный интернет-магазин.
3) Написать короткое, но емкое ТЗ в терминологии платформы 1С-Битрикс, содержащее ссылки на стандартную документацию к платформе и детально проработанные блоки с описанием расширенного/нестандартного функционала. Объемом — ну максимум страниц 20-30 и 5-10 диаграмм.
4) Подготовить команду разработки к пониманию ТЗ и быстрой его реализации — для этого коллег нужно оперативно «прокачать» на бесплатных курсах для разработчиков или, если позволяет время, на более сложных коммерческих тренингах.
5) Подготовить команду обслуживания проекта — менеджеры, контент-редакторы, администраторы — также «прокачав» их для эффективной работы.
Да да. Остался важный вопрос — а что если я начну разработку на платформе 1С-Битрикс, а внезапно появится сложный функционал, который окажется невозможно реализовать и придется заново все писать на другой платформе? Поверьте, вы не первый, у кого возникает такое опасение — и подобные задачи решаются, давно и достаточно успешно следующими технологиями:
1) Постоянная борьба за упрощение и модульность архитектуры платформы. Архитектура 1С-Битрикс настолько проста и интуитивно логична, что вашему креативному полету фантазии и спускаемым сверху бизнес-требованиям ничего не будет мешать — вам же воздух не мешает двигаться? Лично я не разу не встречал таких бизнес-требований к интернет-магазинам, которые требовали бы переписывания ядра платформы. Хотите верьте, хотите нет.
2) Стандартный механизм расширения бизнес-логики платформы — переопределяемые обработчики событий и собственные модули. Поверьте это проще, чем делать трехэтажные наследования от множества объектов.
Также вы можете вынести разработку и поддержку проекта в аутсорс, например воспользоваться услугами нашей сертифицированной партнерской сети, что значительно снизит риски самостоятельной организации процесса разработки/сопровождения интернет-проекта. Вам нужно будет только собрать требования и прийти с ними к разработчикам.
Писать ТЗ можно в Microsoft Word и т.п., но рекомендую писать его с использованием эффективного инструмента коллективной работы — wiki. Все могут править текст и видно, кто и когда это сделал. Если вы используете наш корпоративный портал, то можно писать ТЗ в wiki созданной для проекта рабочей группы.
Также, удобная wiki имеется в продуктах redmine, trac, confluence и т.п.
Соберем и опишем ключевые особенности нашего интернет-магазина в ТЗ, оттолкнувшись от расширяемого стандартного функционала.
Вам нужно однозначно определиться — какой у вас каталог. Иногда каталог товаров предоставляет из себя «дерево с яблоками», иногда — это плоский список с возможностью фильтрации по разным параметрам (производитель, новинка, распродажа), а иногда — одни и те же товары-яблоки можно повесить на разные деревья — предоставив Покупателям различные представления информации. Рекомендую вставить в этот раздел ТЗ прототипы интерфейсов всех страниц вашего каталога — черновая отрисовка экранных форм очень помогает разобраться с логикой каталога.
Обычно на платформе 1С-Битрикс каталог размещают либо целиком в одном инфоблоке, либо в одном инфоблоке хранится древовидная структура товаров с общими описаниями, а конкретные ценовые предложения (которые часто идентифицируют по SCU), хранятся в другом(их) инфоблоках.
Если вы или ваши коллеги разбираются в UML, то часто полезно отразить сущности каталога на подходящей диаграмме, проставив логические отношения между ними.
Чтобы максимально снизить риски, связанные с высокой нагрузкой при эксплуатации проекта, рекомендую эксперименты со структурой каталога проводить на прототипе, который может быть быстро создан разработчиками на платформе 1С-Битрикс в черновой верстке (трудозатраты: день-два). А окончательное решение по архитектуре каталога принимайте только после того, как зальете в каталог ожидаемый объем тестовых данных (а лучше его превысить раза в 2) и замерите скорость и характер типичных запросов к ним.
Часто для функционирования каталога требуются дополнительные справочники — Производители, Цвета, Типы транспортных средств и т.п. — все то, что будет связано с товарами в каталоге. Перечисляем их тут.
Итог:
В данном разделе ТЗ вы продумали и описали структуру каталога и свойства товаров вашего проекта, предварительно сделав наброски экранных форм, сделали технологический прототип и испытали архитектуру каталога на объеме тестовых данных, приближенном к реальному. Было бы время — и вы смогли бы собрать и протестировать на прототипе каталог в стиле Яндекс.Маркет — однако до запуска остается 3 месяца.
Самое простое — у товара есть одна цена=циферка. Сложнее, когда цена меняется в зависимости от типа Покупателя — для рядовых цена одна, для партнеров — другая и т.п. Еще интереснее, когда цена может быть задана в каталоге в разных валютах, и должна быть пересчитана в валюту магазина, в зависимости от того, откуда пришел Покупатель. А бывает еще так, что цена товара зависит от и от покупаемого количества. А когда все собирается вместе…
В торговом каталоге платформы 1С-Битрикс вышеперечисленный функционал, к счастью, предусмотрен (и много еще другого полезного функционала). Однако, если вам потребуется более сложная логика ценообразования в каталоге, например, когда цена зависит от числа дней до дня рождения Покупателя*сумма ваших заказов, вы всегда ее можете решить… переопределением обработчиков событий.
В этом разделе ТЗ нередко появляются формулы. Полезно написать данный и следующий раздел ТЗ вместе с бухгалтером.
Итог:
Скорее всего, большая часть нужной вам логики ценообразования и валют, адаптированной к российским реалиям, уже реализована в платформе 1С-Битрикс. Однако, вы всегда можете добавить то, что вам нужно, либо изменить ее поведение — путем стандартных механизмов расширения платформы, хорошо известных разработчикам.
Описываем, как Клиент может купить продукт, отрисовывая экранные формы. Если сомневаетесь, установите стандартный интернет-магазин платформы 1С-Битрикс или поиграйтесь в виртуальной лаборатории и изучите логику его работы. Часто продукт предварительно добавляется в корзину и проводится по мастеру заказа, но можно также иногда организовать «быструю» покупку в один шаг — оплатив заказ, к примеру, с лицевого счета Покупателя и подставив в него данные из профиля Покупателя по умолчанию.
Помним, что покупатели делятся грубо на физических и юридических лиц, но иногда требуется больше типов. Каждый тип покупателя, при оформлении заказа, как правило вводит разные данные — например юридические лица могут ввести ИНН и т.п. Этот раздел ТЗ неплохо проработать совместно с юристом.
Когда заказ оформлен, нужно не только уведомить Клиента об этом, но и сохранить введенные данные в профиль для дальнейшего использования при повторных заказах. Также, клиент должен иметь возможность просматривать сформированные заказы в персональном разделе, повторять и отменять их.
Нередко удобно, когда Покупатели могут оплачивать заказ с персонального лицевого счета, пополняемого, например, со скретч-карты.
Итог:
Вы отрисовали и описали процесс заказа. Полезно использовать для этого диаграммы активности UML. Многое из того, что нужно для реализации этого процесса, уже имеется в платформе 1С-Битрикс. Если вам требуется расширить бизнес-логику процесса заказа, вы всегда сможете это сделать, используя стандартные механизмы расширения платформы.
В платформе имеется стандартный административный интерфейс для работы с каталогом, заказами Клиентов, их лицевыми счетами, скидками, налогами, и т.п. — подходящий подавляющему большинству интернет-проектов. Мы можете не только обрабатывать заказы, но и «пустить» их по адаптированным для вашей компании бизнес-процессам, где каждый сотрудник выполняет по отношению к заказу определенные операции — один дозванивается до Клиента и подтверждает заказ, другой устанавливает статус оплаты заказа и вводит реквизиты платежных документов, третий взаимодействует с курьерскими службами и т.п.
Нередко бизнес-процессы бэк-офиса, связанные с обработкой заказов магазина, отражают на диаграмме состояний. Это позволяет более четко и формально отразить сложные процессы компании и емко передать знания разработчикам.
Итог:
Вы настраиваете бизнес-процессы бэк-офиса интернет-магазина используя возможности технологии «документооборота» заказов — определяя их возможные статусы, права сотрудников и возможности перехода между статусами. Также через стандартные админки вы управляете многими другими сущностями каталогов и магазина.
Как правило, интернет-магазины запускаются с ограниченным набором платежных систем и служб доставки, добавляя затем их по мере необходимости. В 1С-Битрикс имеется множество встроенных объектов данной категории, и вы всегда сможете быстро добавить нестандартные платежные системы и службы доставки.
Иногда бывает так, что встроенные в платформу административные разделы, например админка заказов, не совсем подходят для решения очень специфических задач. В этом случае, правда за счет дополнительных затрат на программирование, можно создать свои собственные административные разделы с любым, нужным вам функционалом. По секрету — если нужно запуститься за 3 месяца, постарайтесь не заниматься созданием кастомных админок — лучше позаботьтесь о юзабилити части сайта, доступной посетителям :-)
Итог:
Админки, специфичные для вашего проекта можно добавлять в любом количестве. Но часто — «с головой» хватает стандартных админок.
В этом разделе ТЗ описываем кто какими правами в магазине обладает и какие операции может выполнять. Например, редактор контента добавляет новости и редактирует страницы, а бухгалтер — проставляет у заказов статус оплаты и т.п. Возможно, в ваш каталог будет автоматически заливаться информация из других систем — создайте для них специальную учетную запись/группу с правами только на эту операцию. Полезно оформить данную информацию в виде диаграммы UseCases.
В этом разделе ТЗ описываете методику проведения нагрузочных испытаний интернет-магазина, если на это есть время, и целевые показатели. Например:
1) В систему заливаются тестовые данные в объеме, приближенном к ожидаемым. Например 1000000 заказов, 200000 позиций в каталоге, 2000000 пользователей.
2) Эмулируется нагрузка на интернет-проект, например с использованием jmeter и т.п.
3) Инструментом нагрузки фиксируется информация по каждому хиту.
Требуется, чтобы система выдержала 1000000 хитов в сутки, со средним временем получения страницы в 0.5 секунды и процентом ошибок (50*), допустим, менее 1% (системный администратор должен стремиться снизить число ошибок до 0).
В результате у вас получилось короткое и эффективное ТЗ, в котором, с одной стороны, будет множество ссылок на подробную он-лайн документацию к платформе 1С-Битрикс, а с другой — детально расписанные специфичные для вашего интернет-проекта задачи. Дополнительно, вы сразу определяете целевые показатели решения, которые должны быть достигнуты в ходе реализации путем выбора и настройки оборудования, оптимизации кода, кэширования. ТЗ содержит лишь специфику вашего проекта, опираясь на огромную техническую документацию к платформе.
Реализация проекта на 1С-Битрикс обычно идет по такому сценарию:
1) Инсталляция платформы — минуты
2) Интеграция шаблонов, настройка многосайтовости — обычно, при наличии верстки, день
3) Интеграция стандартных элементов — новости, карта сайта, меню, поиск по сайту и т.п — обычно делается за день-два
Подготовленное выше ТЗ делится, лучше с привлечением команды разработчиков или экспертов (попробуйте PlanningPoker), на компоненты. Типичный проект — десятки компонентов. Часто быстрее не писать свой компонент для проекта, а доработать стандартный (в дистрибутиве платформы сотни готовых компонентов).
Для работы компонентов требуется настроить информационные блоки — это абстракция платформы 1С-Битрикс над базой данных. Обычно на это уходит около дня.
4) Производится оценка компонентов. Лучше собрать программистов и потратить на оценку и обсуждение день-другой. На этом этапе проверяется, насколько вы понимаете, что хотите получить — либо вы уверенно ответите на все вопросы разработчиков и получите адекватные оценки, которые можно озвучить, либо разработчики, тем более не понимая задач (если вы их сами не понимаете), дадут оценки (возможно под давлением :-)) «от фонаря» и скорее всего вы не запуститесь в срок.
5) Разработка компонентов. Как правило это самая долгая фаза в жизненном цикле первого релиза проекта. Компонент средней сложности делается одним разработчиком грубо день. Компоненты можно, как правило, делать параллельно несколькими разработчиками.
6) Настройка прав. Создаются пользователи и роли, проверяются их права в системе и проекте.
7) Функциональное и приемочное тестирование. Тестировщики и пользователи проверяют функционал, «прокликивая» проект. Баги исправляются. Хотите модульные тесты — пишите, но скорее всего на них не останется времени.
8) Подготовка и проведение нагрузочного тестирования. Если проект высоконагруженный, то рекомендуется настроить веб-кластер. По опыту, лучше разрабатывать и тестировать на максимально слабом железе — на мощном железе вы возможно не сразу оцените низкое качество разработки.
Т.к. на предыдущем этапе были настроены роли и права, контент редакторы могут приступить к наполнению системы информацией. Также импортируются справочники и каталоги. Сотрудников, задействованных в наполнении контентом, лучше предварительно направить на вышеуказанные курсы — иначе засыпят вас вопросами в лучшем случае, а в худшем будут говорить, что платформа глючит, т.к. у них ничего не получается.
Рекомендуется выбирать сертифицированный хостинг с учетом требований, полученных при проведении нагрузочного тестирования в п.8. Для высоконагруженных проектов, созданных на веб-кластере, стоит обратить внимание на набирающих популярность облачных провайдеров. Если у вас есть сильные админы — берите выделенный сервер, если нет — заказывайте внешнее администрирование.
После ввода проекта в эксплуатацию проследите, чтобы ядро системы регулярно обновлялась (иногда во время разработки нарушаются наши требования к качественной интеграции и модифицируется ядро — что приводит к нарушению работы проекта после обновления, поэтому совет — заставляйте обновлять проект каждый день), а сам проект проактивно мониторился и о возможных неполадках системные администраторы узнавали раньше посетителей сайта :-)
Для реализации высоконагруженного интернет-магазина за несколько месяцев вовсе не обязательно писать огромное ТЗ на 1000 страниц с сотней диаграмм. Часто менеджеру проекта достаточно изучить возможности модулей «Интернет-магазин» и «Торговый каталог» платформы 1С-Битрикс и в ТЗ отразить лишь специфические и нестандартные задачи, оформив остальные разделы в духе «смотри стандартную документацию 1С-Битрикс». Как правило, в большинстве случаев для изменения стандартного функционала интернет-магазина платформы достаточно воспользоваться технологией переопределения обработчиков событий и крайне редко — создавать свои модули, хотя делается это просто. Чтобы снизить риски деградации производительности проекта под нагрузкой — рекомендуется заблаговременно провести нагрузочное тестирование на объеме данных, приближенных к «боевым».
Вы не первый, кого мучает вопрос: «А что, если я начну разработку на платформе 1С-Битрикс, а внезапно появится сложный функционал, который окажется невозможно реализовать и придется заново все писать на другой платформе?». Как я постарался показать в статье, задачи подобного класса давно и успешно решаются — опасаться не стоит.
Удачи!
Руководитель направления контроля качества интеграции и внедрений 1С-Битрикс — Александр Сербул
Сегодня я расскажу как в очень сжатые сроки спроектировать и запустить высоконагруженный интернет-магазин с нестандартным функционалом… на платформе 1С-Битрикс.
Проблематика
Если подходить к задаче разработки большого интернет-магазина формально, описывая каждый миллиметр будущего проекта, то у вас получится ТЗ на несколько сотен, если не тысяч листов и десятки диаграмм и экранных форм. И писать вы его будете, скорее всего, не менее полугода… впятером, ночуя на работе. Но самое «страшное» впереди — когда вы его наконец торжественно допишите и объявите об этом выпучив воспаленные глаза, с огромной долей вероятности поменяются требования к проекту: рыночные условия за полгода изменились, приходят и уходят люди, ваши начальники и подчиненные, появляются новые идеи и у них и у вас и т.п. И придется срочно нанимать 10 переписчиков и так до бесконечности :-)
С другой стороны, если ТЗ написать маленьким, страниц на 10, за выходные, и все его согласуют… не читая, то вам придется поселиться в команде разработки для конкретизации требований и ответов на поражающие своей точностью мозгоразжижающие вопросы: «А напишите пожалуйста формулу расчета скидки при оплате продукта долларами с учетом погрешности машинного нуля». Скорее всего, больше недели вы не продержитесь и проект так и не появится.
Так что же делать, если на проектирование отведен месяц, на программирование — три, вы не хотите поселяться в команде разработки, а кто-то уже публично объявил дату запуска проекта? :-)
Пишем техническое задание на макро-языке
Прежде всего, осознайте, что над платформой 1С-Битрикс много лет трудились не только программисты, но и талантливые системные и бизнес-аналитики и воспользуйтесь их опытом! К счастью для вас, самые сложные и трудные для понимания вопросы электронной торговли — давно разжеваны, адаптированны к российским реалиям и превратились в простые концепции, разбитые для простоты восприятия на модули платформы 1С-Битрикс: «Интернет-магазин», «Торговый каталог» и «Валюты».
Вам остается:
1) Хорошо понять внутреннюю логику и терминологию данных модулей. Это ключевой пункт. Можно потратить на это выходные, дело стоит того.
2) Увидеть, какие небольшие блоки осталось добавить, чтобы получился публично анонсированный интернет-магазин.
3) Написать короткое, но емкое ТЗ в терминологии платформы 1С-Битрикс, содержащее ссылки на стандартную документацию к платформе и детально проработанные блоки с описанием расширенного/нестандартного функционала. Объемом — ну максимум страниц 20-30 и 5-10 диаграмм.
4) Подготовить команду разработки к пониманию ТЗ и быстрой его реализации — для этого коллег нужно оперативно «прокачать» на бесплатных курсах для разработчиков или, если позволяет время, на более сложных коммерческих тренингах.
5) Подготовить команду обслуживания проекта — менеджеры, контент-редакторы, администраторы — также «прокачав» их для эффективной работы.
Да да. Остался важный вопрос — а что если я начну разработку на платформе 1С-Битрикс, а внезапно появится сложный функционал, который окажется невозможно реализовать и придется заново все писать на другой платформе? Поверьте, вы не первый, у кого возникает такое опасение — и подобные задачи решаются, давно и достаточно успешно следующими технологиями:
1) Постоянная борьба за упрощение и модульность архитектуры платформы. Архитектура 1С-Битрикс настолько проста и интуитивно логична, что вашему креативному полету фантазии и спускаемым сверху бизнес-требованиям ничего не будет мешать — вам же воздух не мешает двигаться? Лично я не разу не встречал таких бизнес-требований к интернет-магазинам, которые требовали бы переписывания ядра платформы. Хотите верьте, хотите нет.
2) Стандартный механизм расширения бизнес-логики платформы — переопределяемые обработчики событий и собственные модули. Поверьте это проще, чем делать трехэтажные наследования от множества объектов.
Также вы можете вынести разработку и поддержку проекта в аутсорс, например воспользоваться услугами нашей сертифицированной партнерской сети, что значительно снизит риски самостоятельной организации процесса разработки/сопровождения интернет-проекта. Вам нужно будет только собрать требования и прийти с ними к разработчикам.
Инструменты
Писать ТЗ можно в Microsoft Word и т.п., но рекомендую писать его с использованием эффективного инструмента коллективной работы — wiki. Все могут править текст и видно, кто и когда это сделал. Если вы используете наш корпоративный портал, то можно писать ТЗ в wiki созданной для проекта рабочей группы.
Также, удобная wiki имеется в продуктах redmine, trac, confluence и т.п.
Оглавление
Соберем и опишем ключевые особенности нашего интернет-магазина в ТЗ, оттолкнувшись от расширяемого стандартного функционала.
Структура каталога товаров и свойства товаров
Вам нужно однозначно определиться — какой у вас каталог. Иногда каталог товаров предоставляет из себя «дерево с яблоками», иногда — это плоский список с возможностью фильтрации по разным параметрам (производитель, новинка, распродажа), а иногда — одни и те же товары-яблоки можно повесить на разные деревья — предоставив Покупателям различные представления информации. Рекомендую вставить в этот раздел ТЗ прототипы интерфейсов всех страниц вашего каталога — черновая отрисовка экранных форм очень помогает разобраться с логикой каталога.
Обычно на платформе 1С-Битрикс каталог размещают либо целиком в одном инфоблоке, либо в одном инфоблоке хранится древовидная структура товаров с общими описаниями, а конкретные ценовые предложения (которые часто идентифицируют по SCU), хранятся в другом(их) инфоблоках.
Если вы или ваши коллеги разбираются в UML, то часто полезно отразить сущности каталога на подходящей диаграмме, проставив логические отношения между ними.
Чтобы максимально снизить риски, связанные с высокой нагрузкой при эксплуатации проекта, рекомендую эксперименты со структурой каталога проводить на прототипе, который может быть быстро создан разработчиками на платформе 1С-Битрикс в черновой верстке (трудозатраты: день-два). А окончательное решение по архитектуре каталога принимайте только после того, как зальете в каталог ожидаемый объем тестовых данных (а лучше его превысить раза в 2) и замерите скорость и характер типичных запросов к ним.
Часто для функционирования каталога требуются дополнительные справочники — Производители, Цвета, Типы транспортных средств и т.п. — все то, что будет связано с товарами в каталоге. Перечисляем их тут.
Итог:
В данном разделе ТЗ вы продумали и описали структуру каталога и свойства товаров вашего проекта, предварительно сделав наброски экранных форм, сделали технологический прототип и испытали архитектуру каталога на объеме тестовых данных, приближенном к реальному. Было бы время — и вы смогли бы собрать и протестировать на прототипе каталог в стиле Яндекс.Маркет — однако до запуска остается 3 месяца.
Ценообразование товара в каталоге, валюты
Самое простое — у товара есть одна цена=циферка. Сложнее, когда цена меняется в зависимости от типа Покупателя — для рядовых цена одна, для партнеров — другая и т.п. Еще интереснее, когда цена может быть задана в каталоге в разных валютах, и должна быть пересчитана в валюту магазина, в зависимости от того, откуда пришел Покупатель. А бывает еще так, что цена товара зависит от и от покупаемого количества. А когда все собирается вместе…
В торговом каталоге платформы 1С-Битрикс вышеперечисленный функционал, к счастью, предусмотрен (и много еще другого полезного функционала). Однако, если вам потребуется более сложная логика ценообразования в каталоге, например, когда цена зависит от числа дней до дня рождения Покупателя*сумма ваших заказов, вы всегда ее можете решить… переопределением обработчиков событий.
В этом разделе ТЗ нередко появляются формулы. Полезно написать данный и следующий раздел ТЗ вместе с бухгалтером.
Итог:
Скорее всего, большая часть нужной вам логики ценообразования и валют, адаптированной к российским реалиям, уже реализована в платформе 1С-Битрикс. Однако, вы всегда можете добавить то, что вам нужно, либо изменить ее поведение — путем стандартных механизмов расширения платформы, хорошо известных разработчикам.
Процесс заказа для Клиента
Описываем, как Клиент может купить продукт, отрисовывая экранные формы. Если сомневаетесь, установите стандартный интернет-магазин платформы 1С-Битрикс или поиграйтесь в виртуальной лаборатории и изучите логику его работы. Часто продукт предварительно добавляется в корзину и проводится по мастеру заказа, но можно также иногда организовать «быструю» покупку в один шаг — оплатив заказ, к примеру, с лицевого счета Покупателя и подставив в него данные из профиля Покупателя по умолчанию.
Помним, что покупатели делятся грубо на физических и юридических лиц, но иногда требуется больше типов. Каждый тип покупателя, при оформлении заказа, как правило вводит разные данные — например юридические лица могут ввести ИНН и т.п. Этот раздел ТЗ неплохо проработать совместно с юристом.
Когда заказ оформлен, нужно не только уведомить Клиента об этом, но и сохранить введенные данные в профиль для дальнейшего использования при повторных заказах. Также, клиент должен иметь возможность просматривать сформированные заказы в персональном разделе, повторять и отменять их.
Нередко удобно, когда Покупатели могут оплачивать заказ с персонального лицевого счета, пополняемого, например, со скретч-карты.
Итог:
Вы отрисовали и описали процесс заказа. Полезно использовать для этого диаграммы активности UML. Многое из того, что нужно для реализации этого процесса, уже имеется в платформе 1С-Битрикс. Если вам требуется расширить бизнес-логику процесса заказа, вы всегда сможете это сделать, используя стандартные механизмы расширения платформы.
Процесс заказа для Менеджера
В платформе имеется стандартный административный интерфейс для работы с каталогом, заказами Клиентов, их лицевыми счетами, скидками, налогами, и т.п. — подходящий подавляющему большинству интернет-проектов. Мы можете не только обрабатывать заказы, но и «пустить» их по адаптированным для вашей компании бизнес-процессам, где каждый сотрудник выполняет по отношению к заказу определенные операции — один дозванивается до Клиента и подтверждает заказ, другой устанавливает статус оплаты заказа и вводит реквизиты платежных документов, третий взаимодействует с курьерскими службами и т.п.
Нередко бизнес-процессы бэк-офиса, связанные с обработкой заказов магазина, отражают на диаграмме состояний. Это позволяет более четко и формально отразить сложные процессы компании и емко передать знания разработчикам.
Итог:
Вы настраиваете бизнес-процессы бэк-офиса интернет-магазина используя возможности технологии «документооборота» заказов — определяя их возможные статусы, права сотрудников и возможности перехода между статусами. Также через стандартные админки вы управляете многими другими сущностями каталогов и магазина.
Платежные системы и службы доставки
Как правило, интернет-магазины запускаются с ограниченным набором платежных систем и служб доставки, добавляя затем их по мере необходимости. В 1С-Битрикс имеется множество встроенных объектов данной категории, и вы всегда сможете быстро добавить нестандартные платежные системы и службы доставки.
Специализированные административные разделы
Иногда бывает так, что встроенные в платформу административные разделы, например админка заказов, не совсем подходят для решения очень специфических задач. В этом случае, правда за счет дополнительных затрат на программирование, можно создать свои собственные административные разделы с любым, нужным вам функционалом. По секрету — если нужно запуститься за 3 месяца, постарайтесь не заниматься созданием кастомных админок — лучше позаботьтесь о юзабилити части сайта, доступной посетителям :-)
Итог:
Админки, специфичные для вашего проекта можно добавлять в любом количестве. Но часто — «с головой» хватает стандартных админок.
Роли и права
В этом разделе ТЗ описываем кто какими правами в магазине обладает и какие операции может выполнять. Например, редактор контента добавляет новости и редактирует страницы, а бухгалтер — проставляет у заказов статус оплаты и т.п. Возможно, в ваш каталог будет автоматически заливаться информация из других систем — создайте для них специальную учетную запись/группу с правами только на эту операцию. Полезно оформить данную информацию в виде диаграммы UseCases.
Устойчивость системы к нагрузке
В этом разделе ТЗ описываете методику проведения нагрузочных испытаний интернет-магазина, если на это есть время, и целевые показатели. Например:
1) В систему заливаются тестовые данные в объеме, приближенном к ожидаемым. Например 1000000 заказов, 200000 позиций в каталоге, 2000000 пользователей.
2) Эмулируется нагрузка на интернет-проект, например с использованием jmeter и т.п.
3) Инструментом нагрузки фиксируется информация по каждому хиту.
Требуется, чтобы система выдержала 1000000 хитов в сутки, со средним временем получения страницы в 0.5 секунды и процентом ошибок (50*), допустим, менее 1% (системный администратор должен стремиться снизить число ошибок до 0).
В результате у вас получилось короткое и эффективное ТЗ, в котором, с одной стороны, будет множество ссылок на подробную он-лайн документацию к платформе 1С-Битрикс, а с другой — детально расписанные специфичные для вашего интернет-проекта задачи. Дополнительно, вы сразу определяете целевые показатели решения, которые должны быть достигнуты в ходе реализации путем выбора и настройки оборудования, оптимизации кода, кэширования. ТЗ содержит лишь специфику вашего проекта, опираясь на огромную техническую документацию к платформе.
Оценка и разработка
Реализация проекта на 1С-Битрикс обычно идет по такому сценарию:
1) Инсталляция платформы — минуты
2) Интеграция шаблонов, настройка многосайтовости — обычно, при наличии верстки, день
3) Интеграция стандартных элементов — новости, карта сайта, меню, поиск по сайту и т.п — обычно делается за день-два
Подготовленное выше ТЗ делится, лучше с привлечением команды разработчиков или экспертов (попробуйте PlanningPoker), на компоненты. Типичный проект — десятки компонентов. Часто быстрее не писать свой компонент для проекта, а доработать стандартный (в дистрибутиве платформы сотни готовых компонентов).
Для работы компонентов требуется настроить информационные блоки — это абстракция платформы 1С-Битрикс над базой данных. Обычно на это уходит около дня.
4) Производится оценка компонентов. Лучше собрать программистов и потратить на оценку и обсуждение день-другой. На этом этапе проверяется, насколько вы понимаете, что хотите получить — либо вы уверенно ответите на все вопросы разработчиков и получите адекватные оценки, которые можно озвучить, либо разработчики, тем более не понимая задач (если вы их сами не понимаете), дадут оценки (возможно под давлением :-)) «от фонаря» и скорее всего вы не запуститесь в срок.
5) Разработка компонентов. Как правило это самая долгая фаза в жизненном цикле первого релиза проекта. Компонент средней сложности делается одним разработчиком грубо день. Компоненты можно, как правило, делать параллельно несколькими разработчиками.
6) Настройка прав. Создаются пользователи и роли, проверяются их права в системе и проекте.
7) Функциональное и приемочное тестирование. Тестировщики и пользователи проверяют функционал, «прокликивая» проект. Баги исправляются. Хотите модульные тесты — пишите, но скорее всего на них не останется времени.
8) Подготовка и проведение нагрузочного тестирования. Если проект высоконагруженный, то рекомендуется настроить веб-кластер. По опыту, лучше разрабатывать и тестировать на максимально слабом железе — на мощном железе вы возможно не сразу оцените низкое качество разработки.
Заполнение контентом
Т.к. на предыдущем этапе были настроены роли и права, контент редакторы могут приступить к наполнению системы информацией. Также импортируются справочники и каталоги. Сотрудников, задействованных в наполнении контентом, лучше предварительно направить на вышеуказанные курсы — иначе засыпят вас вопросами в лучшем случае, а в худшем будут говорить, что платформа глючит, т.к. у них ничего не получается.
Выбор хостинга, развертывание проекта
Рекомендуется выбирать сертифицированный хостинг с учетом требований, полученных при проведении нагрузочного тестирования в п.8. Для высоконагруженных проектов, созданных на веб-кластере, стоит обратить внимание на набирающих популярность облачных провайдеров. Если у вас есть сильные админы — берите выделенный сервер, если нет — заказывайте внешнее администрирование.
Обслуживание проекта
После ввода проекта в эксплуатацию проследите, чтобы ядро системы регулярно обновлялась (иногда во время разработки нарушаются наши требования к качественной интеграции и модифицируется ядро — что приводит к нарушению работы проекта после обновления, поэтому совет — заставляйте обновлять проект каждый день), а сам проект проактивно мониторился и о возможных неполадках системные администраторы узнавали раньше посетителей сайта :-)
Заключение
Для реализации высоконагруженного интернет-магазина за несколько месяцев вовсе не обязательно писать огромное ТЗ на 1000 страниц с сотней диаграмм. Часто менеджеру проекта достаточно изучить возможности модулей «Интернет-магазин» и «Торговый каталог» платформы 1С-Битрикс и в ТЗ отразить лишь специфические и нестандартные задачи, оформив остальные разделы в духе «смотри стандартную документацию 1С-Битрикс». Как правило, в большинстве случаев для изменения стандартного функционала интернет-магазина платформы достаточно воспользоваться технологией переопределения обработчиков событий и крайне редко — создавать свои модули, хотя делается это просто. Чтобы снизить риски деградации производительности проекта под нагрузкой — рекомендуется заблаговременно провести нагрузочное тестирование на объеме данных, приближенных к «боевым».
Вы не первый, кого мучает вопрос: «А что, если я начну разработку на платформе 1С-Битрикс, а внезапно появится сложный функционал, который окажется невозможно реализовать и придется заново все писать на другой платформе?». Как я постарался показать в статье, задачи подобного класса давно и успешно решаются — опасаться не стоит.
Удачи!
Руководитель направления контроля качества интеграции и внедрений 1С-Битрикс — Александр Сербул
