Что такое дискавери фаза

Что делает бизнес-аналитик на discovery-фазе: анализ потребностей клиента

В прошлой статье я рассказал, какие задачи решает бизнес-аналитик. В этот раз поговорим больше о его работе на дискавери-фазе. Я встречал два пути ее инициирования:

Основная цель дискавери-фазы — сделать коммерческое предложение. Задача бизнес-аналитика — собрать максимум информации о потребностях клиента и выразить это в отдельном документе, чтобы потом сделать предложение клиенту, от которого он не сможет отказаться.

На практике дискавери-фаза длится до 1 месяца. Почти никто не инвестирует в этот процесс так, чтобы он длился

Хочу отметить, что не всегда дискавери-фаза проводится до подписания контракта. Бывают случаи, когда тендер уже был проведен, контракт подписан, а требований нет. Вот тут и нужно быстро понять, что нужно сделать.

Задача — помочь клиенту

Есть две команды — заказчика и вендора. Со стороны вендора ее состав обычно такой:

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

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

Я акцентирую на этом внимание, потому что, когда в проекте начинает что-то идти не по плану, многие говорят «клиент не такой», «клиент плохой». Это не так. Это значит, что вы плохой специалист и не смогли организовать работу так, как вы хотели изначально. Все клиенты одинаковые: они хотят результат и качество за определенную сумму.

Важен опыт команды

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

Я приведу пример. В вашем распоряжении есть ровно месяц, чтобы понять, какой scope нужен, и подготовить коммерческое предложение. Если ваш дизайнер junior, то вложиться в 1 месяц будет очень сложно, потому что он будет медленно создавать нужные прототипы. Из-за этого будет затягиваться и последующая работа всей команды и проекта.

Возьмем бизнес-аналитика. Если у него мало опыта, то он будет задавать не те вопросы и решать не те проблемы. Когда у бизнес-аналитика за плечами не одна дискавери-фаза и реализованный проект, он уже четко знает, какие вопросы и когда задавать. Поэтому и качество артефактов, которые выйдут в итоге, будет намного выше.

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

Слаженность команды

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

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

Ваша задача как профессионала — рассказать последовательность ваших действий, объяснить, какая помощь для этого нужна. То есть разложить клиенту все по полочкам. Для этого и нужны kick-off, где вы представляете свою команду, рассказываете, чем вы будете заниматься, какая дальнейшая работа. Конечно же project manager может рассказать глобально, но за то, как будет проходить процесс сбора требований, ответственны именно вы!

Заказчик — это группа людей, работников компании, которые занимались своей рутинной работой каждый день. Они, возможно, никогда не сталкивались с процессом сбора требований. Помогите им, рассказывайте, делайте, не бойтесь. Вы профессионал в этом деле и вы должны драйвить.

Обязанности бизнес-аналитика на дискавери-фазе

После проведенных встреч, обсуждений и наблюдений у вас должен быть целый перечень артефактов для дальнейшей работы над продажей проекта:

Если вы крутой бизнес-аналитик, то вы должны с самого начала создавать и структурировать backlog. Рекомендации:

Обязанности дизайнера

Что касается дизайнеров — это моя личная боль. Запомните: дизайнер занимается только дизайном и все! Он не придумывает требования, не описывает бизнес-процессы, он не должен вникать в какие-то технические вещи. Это отдельная и очень обширная тема, подробнее об этом я рассказываю в своем видео.

Если речь идет о разработке программного обеспечения для внутреннего использования, не придумывайте велосипед. Так и скажите дизайнеру — не нужно изобретать то, что только затруднит работу пользователя внутри организации. Интерфейс должен быть как можно проще, и желательно, чтобы он имел схожие паттерны поведения с глобальными продуктами (MS, SAP, Oracle).

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

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

Задача технического специалиста

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

Результаты дискавери-фазы

Результат работы бизнес-аналитика на дискавери-фазе — всевозможный материал, собранный на стороне клиента: документы, артефакты и понимание, что нужно сделать.

Почему я говорил изначально «думайте через epiс и user story»? Потому что для того, чтобы составить коммерческое предложение, вам нужно создать WBS (work breakdown structure). Каждый кусок информации, который вы получили на дискавери-фазе, поможет sales-команде построить правильное коммерческое предложение.

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

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

Источник

Без ТЗ, быстрая аналитика или глубокая аналитика. Как спасти заказчика веб-разработки от бесполезных трат

Привет! Меня зовут Роман Штых, я директор студии разработки MetaLamp. Я много общаюсь с заказчиками веб-проектов и вижу проблему: они часто не могут описать задачу так, чтобы её можно было сразу оценить. В ответ разработчики предлагают работать без оценки, по часам, либо продают глубокую аналитику — сначала составим ТЗ за счет заказчика, а потом назовем сумму разработки. Это выгодный подход для студии, но он не всегда подходит клиенту.

Работа без ТЗ заказчика не устраивает, потому что непонятно, какой бюджет закладывать. Нужен сильный кредит доверия — вдруг пройдет пару месяцев, придётся платить миллионы, а проекта так и не будет. Глубокая аналитика тоже смущает — тратить сотни тысяч и несколько месяцев на разработку ТЗ, прототипов и оценку стоимости разработки может показаться сомнительной идеей.

Я бы предложил третий вариант, «волшебную таблетку» для таких ситуаций — быстрая аналитика без сильной детализации. Расскажу, как это делаем мы, на примере нескольких заказчиков. В конце поделюсь методичкой: если подход понравится, сможете попробовать провести такое исследование сами, сэкономите деньги и время.

Дисклеймер. Мы в MetaLamp для быстрой аналитики без особой детализации используем термин Discovery phase, или «Дискавери» — процесс превращения идеи заказчика в техническое задание и прототипы, по которым разработчики оценят проект и озвучат клиенту сроки и стоимость работ.

И говорим «Глубокая аналитика», когда речь заходит про аналогичное исследование, только очень подробное и щепетильное. Просто так проще.

В других студиях терминология может отличаться: где-то «Дискавери» могут называть и полугодовые исследования проектов, а где-то это будет недельная проработка фич.

Знакомьтесь, Дима — владелец логистического бизнеса, который он решил перевести в онлайн и расширить, сделать аналог Uber, но в мире грузоперевозок. Дима скачал из интернета шаблон ТЗ, заполнил, получилась какая-то ерунда. Погуглил, понял, что у него совсем нетиповой проект, набирать свой штат разработчиков дорого, долго и сложно, и решил искать подрядчика.

Сначала Дима пришёл в бюро, где ему рассказали про Agile, гибкие методологии и почасовую оплату. Если проще, то предложили работать без подробного ТЗ: он рассказывает идею, ребята начинают разработку, заранее договорившись о стоимости часа программиста, дизайнера и других специалистов.

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

Дима пришёл в другое агентство, озвучил сомнения про гибкие методы работы. Ему сказали: «Не вопрос», и предложили провести глубокий бизнес-анализ проекта. Команда пообещала за 300 000 рублей и три месяца написать подробное ТЗ.

Глубокая аналитика потребует плотного контакта, согласовывать придётся каждую мелочь. Вплоть до поведения приложения при прокрутке экрана: будет ли контент сам погружаться или нужно будет нажимать на номера страниц.

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

Долго и дорого, зато точно будет понятно, сколько денег надо готовить. Хороший вариант, если заказчик хочет до копейки знать бюджет и срок, и готов дорого заплатить за подготовку. Диму это не устроило — для него ждать условные три месяца только ТЗ слишком долго, платить сотни тысяч за это не хочется.

Наконец, Дима добрался до нас. Мы немного расспросили его о проекте и предложили золотую середину — провести быструю и неглубокую аналитику, как мы её называем, фазу «Дискавери».

Это как глубокая аналитика, только не настолько подробная, долгая и дорогая. Например, в «Дискавери» мы определим ключевые бизнес-процессы, решим сложные вопросы вроде логики получения груза или формирования заказа, и определим список сервисов, с которыми нужно проводить интеграции.

Если увидим сервисы, интеграцию с которыми оценить сложно, долго и дорого, то так и скажем. Например, с Димой получилось так: оценили 80% объёма проекта на точную сумму и срок. Интеграции же с сервисами вроде трекинга автомобилей по GPS предложили делать по часам, с ориентировочным прогнозом по срокам и вилкой цены.

В итоге получается смешанный стиль: за пару недель Дима получил ТЗ, в котором основной объём работы оценён, а для остатка проекта есть вилка по стоимости, которую он спокойно закладывает в свои планы.

Я не хочу говорить, что быстрая аналитика с помощью «Дискавери» — самый классный способ подготовить ТЗ. Хотя, судя по опыту, именно он больше подходит нашим клиентам. Если смотреть объективно, то выбирать модель работы нужно в зависимости от объёма проекта и комфорта заказчика. Если кратко, то так:

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

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

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

«Дискавери» — это гибкий метод. Для Димы мы сделали оценку проекта в целом, а интеграции с платежными система решили делать позже, с почасовой оплатой.

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

«Далеко не каждому проекту пригодится глубокая детализация. Нужен заказчику абсолютно точный бюджет — ок, пусть будет долгая и дорогая аналитика, зато потом без изменений. Но в большинстве случаев это необязательно — ведь с помощью «Дискавери» можно довольно точно оценить большую часть проекта и сэкономить на аналитике и скорости запуска»

Расскажу, как мы проводим «Дискавери». Постараюсь описать так, чтобы вы могли попробовать повторить процесс самостоятельно и увидеть пользу от этого метода.

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

Другой заказчик, Лёша, пришел к нам со срочным запросом — решить проблемы с документами. У него брокерский бизнес, в котором менеджеры принимали и отправляли клиентам кучу разных документов по почте, в нескольких письмах. Проблема — это занимало очень много времени, менеджеры иногда путались в бумагах.

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

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

Для этого этапа есть хороший инструмент — BPMN. Проще говоря, это большая цепочка бизнес-процессов, в которой явно видно, кто что делает, как делает и кто за что отвечает.

Здесь задача обрастает «мясом» — мы уже понимаем, откуда в будущем проекте будут появляться данные, как их обрабатывает бизнес, насколько длинный будет путь.

«Если вы работаете со стартапом, придётся рисковать: описывать не текущие бизнес-процессы, а строить гипотезы, как это должно всё работать»

Бывает, что человек начинает рассказывать, как он видит решение своей задачи сразу по процессам. Например, хочет, чтобы документы собирались и обрабатывались вот так, чтобы на конкретных этапах были такие-то результаты.

Другой вариант — заказчик может ничего не фантазировать и сказать, что ждёт от нас решения его задач. Так тоже можно — тогда мы проработаем это сами.

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

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

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

Для каждой роли мы прописываем возможности — ещё их называют функциональными требованиями. Данные берём из бизнес-процессов, расписываем подробно.

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

Если хотите провести «Дискавери» сами, чаще задавайте себе два вопроса: «А что дальше?» и «Что, если нет?».

Например, водитель в экспедиторском проекте может попасть в личный кабинет. А что дальше? Он увидит оповещение о новом заказе. А что дальше? Может предложить свою цену. А что дальше? Возьмёт заказ. А что, если нет, если откажется брать заказ? Сервис предложит новый? А если он возьмет заказ, но не поедет? И так далее.

Итог этого шага — карточки с ролью и перечислением функциональных требований.

Источник

Request response diagram: что такое и зачем это нужно

Мы продолжаем серию публикаций об артефактах, которые клиенты получают на самой первом этапе разработки — дискавери фазы. Мы уже объяснили, что такое MindMap, Пользовательские истории, BPMN-диаграмма, Customer Journey Map и как мы используем эти инструменты в разработке. Сегодня говорим о Request response diagram — этот артефакт необязательный, мы его используем, если в проекте предусмотрены интеграции (например, с Google-переводчиком, сервисом доставки и логистики, онлайн-оплатой и т. д.).

Request response diagram или диаграмма последовательности — разновидность диаграмм взаимодействия. Обычно она содержит объекты, которые взаимодействуют в рамках сценария, сообщения, которыми они обмениваются, и возвращаемые результаты, связанные с сообщениями. Диаграммы последовательностей используются для более детального описания логики сценариев использования.
Request response diagram отражает:

В отличие от BPMN-диаграммы, которая показывает алгоритм работы системы, Request response diagram обращают внимание разработчиков на сообщениях, которыми объекты обмениваются друг с другом.

Разберем на простом примере, как работает Request response diagram, чтобы наглядно представить, как работает этот артефакт. Эта диаграмма отображает обслуживание в ресторане:

Фред (клиент) заказывает еду Бобу (официанту), Боб передает заказ Хэнку (повару). Пока повар готовит еду, официант наливает вино клиенту. Хэнк отдает заказ Бобу, Боб сервирует блюда. Фред ест и потом рассчитывается за ужин через кассира Ренне.

Это простая схема, в веб и мобильной разработке на таких диаграммах отображаются более сложные процессы и интеграции. Но такой инструмент дает понимание логики процесса, так как мы видим как должны работать объекты на протяжении всего временного цикла. Request response diagram — довольно сложная нотация, которая имеет свой язык. Чтобы правильно прочитать ее, необходимо знать значение каждого символа. Останавливаться на расшифровке мы сейчас не будем, так как клиентам студии обычно не приходится разбираться с диаграммой, этот артефакт скорее оптимизирует работу в команде разработчиков.

Request response diagram чаще всего применяются на этапе дискавери фазы, когда у сервиса есть интеграция.

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

Бизнес или системные аналитики в компании с проджект-менеджером разрабатывают бизнес-модель, которая позволит сделать продуктивную и экономичную интеграцию. На примере интеграции с google-переводчиком (на схеме ниже) видно, что эта диаграмма показывает, как сохранить все переведенные ранее тексты в систему, чтобы пользоваться ими в будущем. Тем самым не придется каждый раз обращаться к платному переводчику и тратить деньги клиента.

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

Источник

Что такое BPMN-диаграмма и зачем она нужна в разработке

Схемы по методу моделирования бизнес-процессов (BPMN) используются в разных сферах, например, в продажах и ведении проектов. В разработке этот инструмент важен на этапе бизнес-аналитики: с помощью BPMN описываются все сценарии взаимодействия пользователей и системы.

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

В YuSMP Group мы отдаем BPMN-диаграммы продуктов после окончания дискавери-фазы. Эта нотация входит в список обязательных артефактов, которые получает клиент.

Business Process Model and Notation (нотация моделирования бизнес-процессов) — это система условных обозначений, которая отображает бизнес-процессы с помощью блок-схем. BPMN диаграмма показывает в какой последовательности совершаются рабочие действия и перемещаются потоки информации.

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

Наглядная схема показывает, где в процессах есть узкие места или вовсе тупики, из-за которых клиенты уходят или не заканчивают целевое действие (заявка, покупка, звонок). BPMN подсвечивает места, которые можно улучшить и моделирует способы адаптации под новые условия.

Главное преимущество BPMN-диаграмм — это то, что они понятны и внутри организации, и за ее пределами. Нотация описывает процессы языком, который доступен всем участникам проекта. Его понимает команда разработки (бизнес-аналитики, программисты, продакт-менеджеры) и сторона заказчика (владелец и сотрудники).

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

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

На примере фрагмента схемы, которую мы создавали для платформы онлайн-обучения, покажем основные объекты языка BPMN и как они взаимодействуют друг с другом.

На иллюстрации: «Вход на сайт».

На иллюстрации: «Есть логин и пароль?».

На иллюстрации: «Да/Нет».

На иллюстрации: «Запросить у владельца курса логин и пароль».

BPMN — это схема из блоков и соединительных элементов, которые отображают все действия, происходящие в системе. Эту диаграмму составляют на дискавери-фазе бизнес-аналитики.

С помощью BPMN-диаграмм работа идет динамичнее: бизнес-аналитики быстрее отдают проект разработчикам, которым не нужно тратить время на то, чтобы вникать в систему и разбираться в процессах.

Команда разработки и заказчик лучше понимают друга, BPMN исключает возможность «двойного прочтения», а значит и недопониманий тоже.
Диаграмма улучшает коммуникацию не только внутри компании, но и создает единое информационное поле в общении с заказчиком.
BPMN наглядно показывает слабые места, где потенциальные клиенты могут уйти. А значит, исправить или вовсе предотвратить “утечку” будет намного проще.

А какое его истинное назначение?

Есть более проще нотации типа EPC. Одно из назначений BPMN это написание однозначных инструкций в графическом виде для последующего выполнения в системах типа BPMS. То есть, это более жесткая нотация, как очень высокоуровневый язык программирования.

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

Источник

Discovery фаза: что, почему, зачем

Что такое дискавери фаза

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

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

Основные цели анализа:

Дискавери фаза необходима чтобы:

Игнорирование этого этапа реализации проекта может иметь такие последствия:

Дискавери фаза в проектах разработки программного обеспечения является жизненно важным этапом на пути к созданию продукта. Фактически, это первый шаг, который нужно сделать после принятия решения о воплощении идеи в жизнь, и выполнять его стоит с опытной и надежной компанией. Результатом реализации этого этапа является прототип и вся необходимая для реализации проекта документация. Для реализации идеи важно выбрать компанию, которая строго соблюдает все этапы разработки проекта. О том, какие это этапы, можно узнать подробнее здесь.

ПРЕСС-РЕЛИЗ. Материал публикуется на коммерческих условиях. Сайт progorod43.ru не несет ответственности за содержание материала. Товары и услуги подлежат обязательной сертификации.

Источник