Алексей Александров
генеральный директор компании SEBEKON
Начнём с определений.
Интернет-магазин — сайт для продажи товаров физическим лицам.
B2B-портал — сайт для продажи товаров и услуг профессиональным клиентам.
B2B-портал отличается от интернет-магазина бо́льшим количеством интеграций с внутренними и внешними системами компании-продавца, предоставлением дополнительных услуг: документооборот, сервисное обслуживание продуктов компании, оформление рекламаций, заказ по артикулам, интеграция b2b-портала с внутренними системами учета компаний-покупателей и т.д.
Давайте рассмотрим в качестве примера небольшое производство. Его владелец ходит на профильные выставки и конференции, общается с коллегами по отрасли, читает отраслевые газеты и журналы. И везде слышит, как круто меняется жизнь предприятия с внедрением b2b-портала и интернет-магазина:
- автоматизируются бизнес-процессы;
- растет прибыль;
- сокращаются издержки, в том числе и на персонал;
- цепочки поставок становятся прозрачными и т.д.
И он думает: «Хочу так же!». Он поручает своему заместителю или даже секретарю найти подрядчика по разработке портала. Ему показывают список из нескольких компаний-кандидатов, назначают встречи. На встречах представители этих компаний задают неудобные вопросы:
- Как у вас устроен учет заказов? В какой системе?
- Как вы отгружаете заказы?
- Как ведется учет остатков на складе?
- Как устроен документооборот с клиентами?
- Кто будет заниматься b2b-порталом внутри компании?
А на производстве весь учет ведется в Excel или гугл-таблицах, курировать b2b-портал будет менеджер по продажам, потому что больше некому. Руководитель рассказывает, что хочет, чтобы через портал можно было видеть остатки товаров на складе, оформлять заказы, отслеживать грузы, вести документооборот. Представители фиксируют «хотелки» в требованиях, на основе которых готовят коммерческое предложение. Как правило, заказчик пугается длительной разработки и высокой стоимости проекта и в 90% случаев отказывается от идеи, продолжив вести работу в «табличке».
Возможно, стоит потратиться сначала на автоматизацию бизнес-процессов, а уже потом заниматься «фасадом» ― разработкой IT-проекта. Если же у вас с этим все отлично, то можно переходить к следующим этапам.
1. Выбор руководителя проекта
Наивно полагать, что вы заплатите деньги и получите через месяц готовый IT-проект. С вашей стороны нужен менеджер, знающий нюансы интернет-магазинов или готовый погружаться в эту тему и взаимодействовать с руководителем команды разработчиков.
2. Выбор подрядчика
На тему выбора подрядчика написано много материалов. Мы рекомендуем просмотреть поисковую выдачу по релевантным запросам, рейтинги разработчиков (Тэглайн, Ruward, Рейтинг Рунета и др.). Только имейте ввиду, что лидеры рейтингов обычно называют за работу высокую цену, да и загружены проектами на годы вперед, а в лидерах органической поисковой выдачи могут оказаться компании с хорошо прокачанным SEO, но посредственным опытом в разработке. Хороший способ найти проверенного подрядчика ― сарафанное радио. Расспросите коллег по отрасли, кто им делал интернет-магазины, а лучше поищите примеры IT-проектов, которые вам нравятся, и посмотрите, кто их разрабатывал. Часто внизу страниц, в подвале, есть отметка «Разработка сайта “Название компании”». Составьте список потенциальных подрядчиков, пообщайтесь с ними, запросите коммерческие предложения.
Перед рассылкой запросов на коммерческое предложение составьте перечень бизнес-требований к вашему будущему IT-проекту. Приведем базовый перечень.
- Общее словесное описание проекта. Например: мы хотим сделать интернет-магазин таких-то товаров, в таком-то сегменте. Добавьте сюда цели по продажам и другие значимые метрики.
- Основной перечень объектов. Например: в личном кабинете клиент должен видеть историю заказов, документы по заказам, просрочки по договорам.
- Роли пользователей. Например, самый простой вариант — незарегистрированные пользователи, зарегистрированные клиенты и администратор магазина. Если речь о b2b-портале, то могут быть такие роли: главный бухгалтер клиента, менеджер клиента, директор клиента. Если вы предполагаете разный доступ к функционалу проекта, напишите в этом пункте об этом.
- Сценарии работы. Можно для начала ограничиться минимальными, например: зашел на сайт, нашел по поиску нужный товар, зарегистрировался, положил товар в корзину, купил. В более сложном варианте может быть так: один пользователь положил в корзину, другой оформил заказ, третий оплатил. Если у вас несколько складов в разных городах и вы хотите, чтобы ваш клиент мог видеть товар и информацию о его доставке в зависимости от местоположения товара и клиента, не забудьте написать об этом. Все эти нюансы важны для оценки проекта.
- Список систем для интеграции. Здесь нужно указать все внешние и внутренние системы, которые вы хотите интегрировать с IT-проектом: от эквайринга и сервиса смс-уведомлений до модулей доставки, ERP-систем, 1С, CRM и т.д.
- Показатели назначения. Показатели назначения должны включать в себя все данные о количестве товаров, клиентов. Нужно указать, сколько примерно планируете оформлять заказов в одну единицу времени (день, неделя, месяц, год). Если вы планируете формировать в личном кабинете документы к заказам, то нужно примерно написать их количество и «вес». Все это нужно для того, чтобы подрядчик рассчитал нагрузку на сервера и предложил оптимальное решение. Например, как-то раз к нам пришел клиент с запросом «хочу сайт как у Иванова». Мы изучили сайт, сфокусировавшись на каталоге товаров, фильтрах и т.д. При просмотре сайта не видно, что там размещено одновременно более 5 млн товаров. А это критически важный показатель: например, если попробовать сделать интернет-магазин с таким количеством товаров на базовой лицензии 1С-Битрикс со стандартными настройками, то при первом же запуске сайт ляжет.
После получения коммерческих предложений выберите понравившегося подрядчика. Дальше хочется добавить «и начинайте работать», но до старта работ нужно сделать еще многое.
3. Подготовка технического задания
Это критически важный этап и самое главное здесь: ТЗ должен писать профессионал. Если потенциальный подрядчик предлагает сделать ТЗ (разумеется, за отдельную плату), соглашайтесь: у него явно больше опыта в этом и он сможет учесть все нюансы. Даже если вы в итоге не договоритесь с ним о разработке, ТЗ будет у вас, и с ним вы сможете обратиться к другому исполнителю. К слову, такое сотрудничество — удобный способ проверить потенциального подрядчика: если вам будет некомфортно общаться еще на этапе написания ТЗ, то и дальше этот дискомфорт будет сохраняться и нарастать.
Коротко рассмотрим, почему ТЗ так важно.
А по ТЗ вы будете принимать готовый проект. Например, в нашей компании среднее ТЗ на интернет-магазин занимает 100+ страниц, на которых учтено все:
- пользовательские сценарии;
- реакция системы на клики клиента;
- интерфейсы полей для заполнения;
- функционал личного кабинета;
- сценарии работы с товарным каталогом;
- интеграции с внешними и внутренними системами и многое другое.
Такая детализации пригодится вам и в процессе разработке, и на финише, когда нужно будет принимать проект.
4. Заключение договора
Это финишный этап перед началом разработки. Мы не будем подробно останавливаться на всех разделах договора, обратим внимание на три аспекта:
- гарантия;
- план-график;
- промежуточный контроль.
Стандартная история ― год гарантийного обслуживания с момента передачи проекта заказчику. Обратите внимание, указана ли в договоре ответственность за невыполнение гарантийных обязательств: в небольших студиях веб-разработки пренебрегают этим пунктом. Кроме этого, стоит посмотреть, указана ли скорость реакции исполнителя на гарантийное обращение. Если этого нет, то есть риск получить устранение проблем спустя месяц после заявки ― в этом случае размер ваших материальных потерь подсчитать невозможно.
Еще один важный пункт ― условия оплаты. В нашей компании мы еще в коммерческом предложении всегда предлагаем поэтапную оплату. Это снижает общую напряженность сторон и позволяет расторгнуть договор без серьезных финансовых потерь с обеих сторон, если возникнут серьезные разногласия.
Пару слов о план-графике. Разработка сайта – это услуга, ценность которой создают обе стороны. Заказчик должен участвовать во всех этапах разработки, согласовывать дизайн страниц и структуру сайта, предоставлять контент, вовремя заключать договоры с внешними сервисами и т.д. В нашей практике часто случается срыв сроков сдачи этапа проекта, потому что заказчик вовремя не заключил договор с банком для эквайринга, не выбрал логистический сервис. Мы не уполномочены решать такие вопросы, это ответственность заказчика. План-график позволяет минимизировать риски: в нем должна быть вся информация, на каком этапе что понадобится для разработки. Если исполнитель не предлагает вам план-график, вам стоит насторожиться и подумать о его замене.
Еще одно важное приложение к договору ― промежуточный контроль за ходом проекта. Вы согласовали ТЗ, дизайн. Исполнитель ушел делать IT-проект со словами: «Через три месяца вернемся с готовым». Как вы можете оценить ход работ? Можно, конечно, позвонить менеджеру и услышать от него: «Работа кипит, уже сделали 38%». Как понять, что входит в эти 38%? Четких регламентов по созданию промежуточных точек контроля нет, в каждом случае они будут уникальными. Например, в нашей компании контроль выполнения выстроен по-разному, но мы всегда договариваемся на старте о формате отчетов: кому-то из клиентов нужны еженедельные встречи с презентацией о проделанной работе, кто-то просит только устные отчеты, кому-то достаточно писем. Красный флаг: если исполнитель откажется от приложения договора о промежуточном контроле, вам стоит задуматься, работать ли с ним дальше.
Возможно, некоторые меры, описанные в статье, вам покажутся лишними. Однако мы убеждены: чем больше времени и сил вы потратите на подготовительную работу по IT-проекту, тем меньше проблем у вас будет в ходе разработки и последующей эксплуатации интернет-магазина или b2b-портала.
Как-то текст больше про саму разработку технического приложения...
вот именно! давно мысли запустить свой b2b проект и решил зайти почитать как к этому прийти. а в итоге тут чисто про приложение написано. разочарован