дефект рейт что это
Серьезность и приоритет дефекта: в чем различие?
У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.
На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:
Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.
Серьезность (Severity) – это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется тестировщиком или техническим специалистом, который может оценить степень влияния дефекта на работу системы.
Но зачем нужно это деление, разве нельзя обойтись только одним атрибутом, например, серьезностью? Предположим, в некой системе не работает модуль отчетности. Это –дефект с уровнем серьезности «Блокирующий». Однако этот модуль потребуется только в конце отчетного периода (перед Новым Годом). Если сейчас лето, то данная функциональность не будет использоваться еще несколько месяцев. Как следствие, руководитель проекта или лицо, принимающее решение, может проставить низкий приоритет исправления.
Обратная ситуация: на лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании). Данный дефект способен сильно ударить по доверию пользователей к продукции, которую им предлагают: потенциальные клиенты могут подумать, что качество услуг весьма сомнительно, раз даже в названии компании присутствует дефект – и отказаться от использования продукта. С точки зрения подхода к качеству, даже нефункциональные дефекты с уровнем серьезности «Тривиальный» способны отрицательно повлиять на репутацию Компании. Поэтому такому дефекту может быть проставлен высокий приоритет исправления.
Подводя итог, нужно помнить, что проставление описанных выше атрибутов является важной частью процесса разработки и тестирования программных продуктов, поскольку атрибуты однозначно классифицируют все дефекты по типу: степень влияния на систему и последовательность их исправления. Как следствие, это позволяет проводить быстрый поиск или делать сортировку, формировать наглядные отчеты и не тратить время на излишние коммуникации. Проставляйте атрибуты правильно и да пребудут ваши системы в добром здравии!
defect rate
Тематики
Смотреть что такое «defect rate» в других словарях:
defect — ▪ I. defect de‧fect 1 [dɪˈfekt,ˈdiːfekt] noun [countable] MANUFACTURING a fault in something that means it is not perfect: • They recalled the vehicles because of brake defects. • an effort to improve customer satisfaction and reduce product… … Financial and business terms
Ventricular septal defect — Infobox Disease Name = PAGENAME Caption = Echocardiographic image of a moderate ventricular septal defect in the mid muscular part of the septum. The trace in the lower left shows the flow during one complete cardiac cycle and the red mark the… … Wikipedia
Casting defect — A casting defect is an irregularity in the metal casting process that is undesired. Some defects can be tolerated while others can be repaired otherwise they must be eliminated. They are broken down into five main categories: gas porosity,… … Wikipedia
Abdominal wall defect — Classification and external resources ICD 10 Q79 ICD 9 756.7 An infant … Wikipedia
Gulf War syndrome — (GWS) or Gulf War illness (GWI) is an illness reported by combat veterans of the 1991 Persian Gulf War typified by symptoms including immune system disorders and birth defects. It has not always been clear whether these symptoms were related to… … Wikipedia
Depleted uranium — The DU penetrator of a 30 mm round[1] Depleted uranium (DU; also referred to in the past as Q metal, depletalloy, or D 38) is uranium with a lower content of the fissile isotope U 235 than natural uranium (natural uranium is about 99.27% uranium… … Wikipedia
Kia Carnival — Class Minivan Manufacturer Kia Motors Also called Kia Sedona … Wikipedia
Sperm donation — is the provision (or ‘donation’) by a man, (known as a ‘sperm donor’), of his sperm, with the intention that it be used to impregnate a woman who is not usually the man s sexual partner, in order to produce a child. A sperm donor is the natural… … Wikipedia
Minato Ward 2006 elevator accident — The Minato Ward 2006 elevator accident was an incident in June 2006 which shook Japanese public confidence in the safety of elevators around the country. In June 2006, in Minato, Tokyo, a 16 year old high school student was killed by an elevator… … Wikipedia
Давайте поговорим о метриках как способе оценки труда программиста
Метрики — они как фломастеры, каждому по вкусу свои. Без метрик существование прибыльного бизнеса как такового невозможно, они окружают нас постоянно, это неприятная, но аксиома. Для кого-то метрика — план продаж на месяц, кому-то — выполнение заказа до оговоренного дедлайна, а другим — количество отработанных часов.
Подходящей «Картинки Для Привлечения Внимания» на эту тему нет, так что держите котика
Почему-то слово «метрики» в IT-сфере плотно ассоциируются с такими «превосходными» по своей тупости практиками, как подсчет написанных строчек кода или закрытых тасков. С уверенностью можно сказать, что это — самые бесполезные и беззубые в управленческом плане «инструменты» контроля. По сути же, адекватные метрики бывают, весьма условно, но все же, только двух типов: метрики для проекта и/или работ, результат и время исполнения которых ясен и прогнозируем во времени, и напротив, метрики для проекта и/или работ, результат и время исполнения которых спрогнозировать физически невозможно. Для первого типа выставляются метрики результата, а для вторых — дистанции, сиречь отработанного времени.
Первый тип метрик «по результату»
Универсального рецепта для выставления метрик любому работнику нет — это всегда ситуационное явление. Метрика работника всегда формируется из одного простого ответа на следующий вопрос: можем ли мы четко предсказать конечный результат и, как следствие, время работ на малой или средней дистанции?
Давайте рассмотрим ситуацию на фрилансе. Чаще всего заказчики выстраивают взаимоотношения с исполнителями по принципу оплаты за выполненный объем работы. То есть существует бюджет на проект, и под этот бюджет уже в ходе переговоров согласуется редлайн и дедлайн его сдачи. Так работают дизайнеры, верстальщики, ряд разработчиков. Чаще всего бюджет не двигается с места, то есть подвижной частью является «время выполнения».
Но оно всегда плюс/минус прогнозируемо, то есть заказчик четко понимает, сколько «примерно» времени уйдет на исполнение его заказа. Отталкиваясь от этой цифры выделяется бюджет, после чего ищется подходящий по стоимости исполнитель.
Вообще во фриланс-среде четко проповедуется принцип «нам все равно, сколько времени вы потратите на выполнение заказа, просто сделайте хорошо и в сроки, которые для нас приемлемы». Таким образом снимается масса вопросов по контролю за работой наемного фрилансера или временного сотрудника, снимается необходимость платить ему три, четыре, десять раз «зарплату» и так далее. Есть транш предоплаты, есть закрытие итогового, заранее оговоренного счета.
Подобный подход просочился и в малый и средний бизнес, где люди работают вроде бы, и на фуллтайм, но компания живет в состоянии жесткой конкуренции и коротких дистанций, когда результат нужен в конкретные сроки. Приложив «безумные усилия» можно нарисовать вот такую грубую-грубую блок-схему, которой руководствуются при принятии решения:
А что насчет почасовых рейтов UpWork и прочих моделей фриланса по времени?
Возможно, этот вопрос родился у тебя, читатель, еще в начале статьи, но пришли к ответу на него мы только сейчас. Точнее, к ответам, потому что их несколько.
Первый: нанимающая компания привыкла к контролю, потому что почасовая ставка в 50% случаев подразумевает трекер, а в 100% — периодические отчеты с проведением ревизии выполненных работ. То есть заказчик перекладывает часть менеджерских функций на самого исполнителя, который отчитывается сам за себя.
Второй: компании нужен контроль за ходом разработки, потому что у нее есть только одна попытка. Если проект растягивается более, чем на несколько недель, заказчику нужно понимать, «на каком свете» находится работа. Чаще всего на такие массивные заказы бюджет выделяется один раз и попытка есть только одна. На самом деле на рынке когда-то были и компании, которые не требовали такой периодичной и временами жесткой отчетности от исполнителей на крупных проектах, но с ними случилось тоже самое, что и со слонами с маленькими ушами — они вымерли (слоны от перегрева, а компании — из-за сорванных сроков).
Второй тип метрик «по времени»
Но все становится намного, намного сложнее, если мы начинаем говорить о крупном проекте, сроки сдачи которого колеблются в диапазоне «от года до трех» и до «это вечная разработка».В случае «вечной разработки» спрогнозировать время получения конечного результата практически невозможно по следующим причинам:
Самый простой и логичный пример работы «по времени» — это обычный офисный фулл-тайм в компаниях от 30-50 человек в отделе разработки. В этих условиях бизнес «на берегу» договаривается с потенциальным работником, то есть еще на этапе собеседования, не о моменте сдачи проекта, а о стоимости часа работы исходя из 40-часовой рабочей недели согласно ТК. Для нас это выглядит просто как размер заработной платы.
При этом надо четко понимать, что бизнес — не дураки. В размер ЗП (точнее в ее сокращение) закладываются личностные кризисы, шатания по офису, перекуры, лишние 20-30 минут на обед (то есть полтора часа, вместо часа) и просто прокрастинация на YouTube. Какие-то компании могут позволить себе эти издержки, так как из бизнес является в данный момент прибыльным и он может позволить себе «легкую» версию контроля через простое выставление краткосрочных задач с размытыми дедлайнами, которыми занимается менеджмент младшего и среднего звена.
Но если бизнес низкомаржинальный или существует в конкурентной легаси-среде, то все становится еще хуже. И вот тут начинается форменный ад, за который разработчики так не любят слово «метрики».
Реальная жесткая привязка к отработанному времени не является самостоятельной метрикой эффективности, тут нужны костыли
Если человеку платят не за результат, а за количество отработанного времени, то как оценить его эффективность? Этим вопросом постоянно задается бизнес. Тут есть несколько переменных:
Чаще всего происходит так, что менеджмент не способен четко проследить потребности бизнеса и работников одновременно, то есть выстроить систему и политику применения метрик, при которой обе стороны были бы довольны происходящим. Что имеется в виду: метрики должны одновременно выполнять интересы бизнеса и быть понятны и выполнимы работниками.
Тут мы сталкиваемся с другой проблемой: если при работе «на заказ» на коротких дистанциях задача, чаще всего, ясна и понятна всем сторонам, то при разработке крупного продукта вся структура находится в постоянном движении. Банально: конкуренты выпустили новый продукт или появился новый инструментарий и все планы, которые были любовно созданы менеджментом, пошли прахом.
В этот момент очень много зависит от менеджмента. Тут можно просто описать неадекватный и адекватный подходы к выставлению метрик.
Кроме того, жесткая привязка к соблюдению метрик контр-продуктивна: если девелопер знает, что у него начнутся «проблемы» из-за того, что он закрыл 19 тасков за неделю вместо 20, то качество выполнения задачи уходит на задний план. И минимум последний, 20 таск, будет сделан на «отвали», с костылями и велосипедами вместо того, чтобы по-настоящему раз и навсегда решить поставленную задачу.
Обратная связь как неотъемлемая часть модели «покупки времени»
Фактически, качественно построенная модель разработки, привязанная ко времени работы, намного сложнее, чем может показаться на первый взгляд. Для эффективной работы по этой модели должна быть организована качественная обратная связь между исполнителями и руководителями, которые должны постоянно корректировать «политику партии» на всех уровнях. Ведь неадекватно поставленная задача, то есть сформулированная метрика — это проблема далеко не разработчиков, хотя эту проблему у нас принято спихивать именно на исполнителей. Неадекватно сформулированная метрика — это проблема, как раз менеджмента, который эту задачу поставил перед исполнителями при условии прозрачности работы обоих сторон.
Именно менеджмент должен организовывать работу так, чтобы время работы расходовалось эффективно, то есть бюджеты не «сжигались», но при этом и разработчики могли бы справиться с поставленными перед ними задачами без тотального выгорания через несколько недель. Потому что людской ресурс хоть и обширен, но не бесконечен, особенно, если речь идет о квалифицированных кадрах.
Именно наличием обратной связи и ответственностью за принятые решения со стороны менеджмента отличается от компания, которая ведет детальный учет отработанного времени, от явной «галеры», где разработчики попадают в бессмысленную мясорубку.
Именно обратная связь позволяет бизнесу найти «узкие места» в разработке. Как часто вы сталкивались с ситуацией, когда сотрудники какого-либо отдела задыхались, работая на износ, но так и не получали «подкрепления» в виде пары новых специалистов, которые бы подставили плечо и забрали на себя часть нагрузки? Такие ситуации возникают сплошь и рядом именно из-за отсутствия качественной обратной связи между разработкой и менеджментом. Вместо четкого отслеживания эффективности команды и ее нагрузки, менеджер ковыряется в носу пальцем, а когда кто-то «ломается», не выдерживая такого ритма, все спихивает на оставшихся девелоперов. Не надо так.
Вместо вывода
Самое худшее, что может случиться в процессе организации рабочего процесса — «передергивание» механизмов, присущих одной модели в другую. Например, когда для долгосрочных проектов выставляются жесткие дедлайны без здравой оценки сложности и возможностей команды. Или когда на краткосрочные самодостаточные проекты и задачи надстраиваются такие формы контроля, которые впору применять в области ракетостроения, а речь идет всего-то о заказе на фрилансе.
Четкое понимание уместности тех или иных методов работы в различных по структуре и размеру компаниях поможет уберечь огромный кусок здоровья и нервной системы при поиске работы. И чем больше разработчиков, менеджеров и владельцев бизнеса будут понимать эти механизмы — тем лучше будет для всех участников IT-сегмента.
Куй железо: горячий жаргон hardware-стартапов
Борис Каганович, технический директор CINEMOOD, открывает цикл статей, посвященных hardware-стартапам, разработке, производству и развитию продуктов. В первой статье цикла — словарь специфических терминов, которые помогут разработчикам и основателям компаний быстрее интегрироваться в hardware среду.
Привет, Хабр! Для начала представимся. Нам уже 4 года, мы быстро развиваемся и… мы не хардверный стартап. Мы разработали и выпустили портативный кинотеатр, увлеченно занимаемся разработкой новых устройств, болеем за их качество, дизайн и инновационность, но девайсы — это те лабутены хрустальные туфельки, в которых наш основной продукт грациозно бежит к сердцам своих пользователей.
Компания Google уже много лет приучает нас к термину «референсное устройство», выпуская серии продуктов под брендами Nexus, Pixel, Home и всевозможными Chrome-чего-то-там. Пользователи хорошо усвоили ценность этих продуктов. Она в высоком качестве сборки, сбалансированной спецификации, всегда свежем дизайне, и, конечно, в безупречно оптимизированном программном обеспечении с регулярными обновлениями и долгосрочной поддержкой.
Мы разделяем принципы, заложенные компанией из Маунтин-Вью. CINEMOOD OS — это контентная платформа, для которой мы придумали и выпустили референсное устройство CINEMOOD Storyteller.
В цикле статей, посвященных разработке и производству «железа», мы обращаемся и к внешним источникам — в том числе, решили дополнить свой опыт работы над продуктом знаниями профессионалов из Bolt.io, чтобы помочь молодым хардверным стартапам не сойти с дистанции на пути к успеху.
Краткий курс железного языка
Первая статья цикла посвящена специфической терминологии, используемой в коммуникациях внутри хардверных стартапов, а также с партнерами по разработке, производству, логистике и дистрибуции. Must have. С вашей помощью этот список может быть дополнен важными акронимами и аббревиатурами. Заранее оговоримся, что некоторые термины в профессиональной среде имеют разные трактовки, все нижеперечисленные — отражение нашего опыта.
Этот список хардверных жаргонизмов составил Ben Einstein, управляющий партнер венчурного фонда Bolt и один из постоянных авторов блога blog.bolt.io. Публикуем адаптированный перевод выжимки из нескольких статей с нашими дополнениями.
Одним из самых обескураживающих элементов любой профессиональной области является бесконечный список сокращений и жаргонизмов. Акронимов порой бывает трудно избежать, но у жаргона есть болезненный побочный эффект: люди «не от сохи» чувствуют себя неполноценными и нежелательными собеседниками, пытаясь узнать о новой области от профи, свободно владеющего «птичьим языком».
Фаундеры, их сотрудники, инвесторы и дистрибьюторы время от времени сталкиваются с профессиональным жаргоном. Мы решили помочь людям быстрее интегрироваться с растущим сообществом инженеров, поэтому собрали в этом посте наиболее часто используемые термины в мире хардверных компаний.
Разработка продукта
PRS / PRD / Spec (спецификация продукта / документ, описывающий требования к продукту) — есть множество названий и сокращений для спецификационных документов, но все они сводятся к одному: документ, который описывает продукт в деталях. Что и как он должен делать, как выглядит, кому нужен, для чего предназначен и т.д. Компании, в которых не пренебрегают написанием подробного плана требований к продукту, сталкиваются с меньшим количеством проблем в дизайне и производстве. Хорошая спецификация включает в себя детали, по крайней мере, в семи функциональных областях:
COGS (Cost Of Goods Sold / стоимость реализованных товаров или себестоимость реализованной продукции) — на языке финансов это общая сумма затрат на производство продукции, поделенная на количество произведенных единиц. Чтобы упростить, рекомендуется рассматривать COGS как «BOM plus». В COGS входят производственные затраты, логистика, таможня, пошлины и другие затраты, которыми обрастает BOM на пути продукта к полке в магазине.
NPS (Net Promoter Score) — широко применяемая система оценки интереса клиентов к вашему продукту. Спрашивая клиентов, «насколько вы можете рекомендовать наш продукт другу?» по шкале от 0 до 10, стартапы могут более-менее точно определять соответствие продукта рынку. NPS может быть статистически релевантным и с небольшими размерами выборки (около 30 человек), что делает его отличным инструментом для проверки гипотез и customer development. Термин используется не только в среде hardware-стартапов.
DFM (Design for Manufacturability / Manufacturing) — набор распространенных инженерных практик подготовки продукта к производству, направленный на упрощение производственного процесса, оптимизацию затрат и устранение потенциальных проблем на этапе проектирования. Фактически, DFM — это проектная документация, где в понятных для производителя форматах и терминах описаны процессы подготовки всех компонентов и частей продукта к сборке, а также указаны подробные характеристики материалов и частей, которые производятся специально для конкретного продукта. Как и BOM, DFM требует постоянной актуализации на протяжении всего жизненного цикла продукта.
POC (Proof of Concept) — как правило, первый и сделанный из говна и палок того-что-было прототип для проверки того, что ваш продукт действительно решает насущную проблему и поэтому будет востребован. Такой прототип не должен хорошо выглядеть или работать надежно, но взгляд на него создаст больше понимания у респондентов, чем ваши попытки объяснить свое еще не сформировавшееся видение продукта.
Looks-like (Mockup) / Works-like — комплементарные друг другу прототипы, которые демонстрируют итоги customer development — исследования вашей ЦА — и ее мнения (looks-like) и ваш прогресс в процессе разработки (works-like). Мокапы или looks-like прототипы могут выглядеть как настоящие, но в большинстве случаев не работают. Это может быть как модель корпуса, сделанная на станке с ЧПУ, так и т.н. «весовой мокап», заполненный песком с клеем и имеющий вес, как у готового продукта. В отличие от мокапов, работающие прототипы (works-like) демонстрируют функциональный дизайн с учетом требований спецификации (то, как будет работать продукт), но редко отражают форм-фактор продукта.
EP (Engineering Prototype) — это когда сошлись волна и камень мокап и функциональный прототип. Как правило, наиболее точно отражающий идею конечного продукта прототип, сделанный до начала работы с серийным производством. EP часто являются самыми сложными, трудоемкими и дорогостоящими прототипами для проектирования и сборки, но вызывают восторженное «вау!» у девушек и инвесторов на профильных мероприятиях.
EVT (Engineering Validation Test) — первый из обязательных этапов в процессе подготовки продукта к массовому производству. EVT прототипы предназначены для проверки функциональных аспектов вашего продукта на соответствие требованиям, указанным в спецификации. Корпуса для EVT samples (образцов) обычно изготавливаются промышленным способом, с использованием тулинга (пресс-форм), но в ограниченных объемах (обычно не более 20 шт.).
DVT (Design Validation Test) — второй этап проверки продукта в ходе подготовки к массовому производству. Прототипы DVT предназначены для проверки необходимого для старта процесса производства качества продукта — и для этого проходят расширенный набор тестов (визуальных, функциональных, нагрузочных). Образцы DVT изготавливаются в несколько больших объемах (2-5x EVT) и с учетом всех планируемых SKU (Stock Keeping Units — разные конфигурации одного продукта, модели для разных рынков, в разном цвете или комплектации).
PVT (Production Validation Test) — в идеале, заключительный этап проверки продукта перед запуском в массовое производство. Цель этого этапа — тестирование на соответствие производственным метрикам: процент брака, время сборки, эффективность зажимов/креплений, скорость упаковки и т.д. Объем PVT обычно составляет порядка 10% от объема первой партии и нередко поступает в продажу конечным потребителям (думаете, им повезло?).
MP (массовое производство) — важный этап разработки, когда продукт на выходе с конвейера имеет достаточно высокое качество для поставки в каналы продаж. Массовое производство косвенно зависит от пропускной способности сборочной линии. Например, популярная модель пассажирского авиалайнера находится в массовом производстве, но в месяц производится всего пара десятков единиц.
Batch / Cell Production / Production Lots (серийное производство) — характерный для стартапов подход к массовому производству, при котором производственный процесс делится на так называемые партии или лоты, обычно от 1 до 10 тысяч единиц продукции, и заказ новой партии следует за отгрузкой предыдущей. Большинство контрактных производителей практикует такой подход при работе с молодыми компаниями, так как не уверены, что спрос на продукцию стартапа достаточный, чтобы запустить непрерывную конвейерную сборку.
NRE (Non-recurring Engineering) — единовременный авансовый платеж за разработку. Как правило, NRE открывает сотрудничество с вашим контрактным производителем. Этот платеж включает в себя наиболее значимые затраты на этапе подготовки продукта к массовому производству: изготовление пресс-форм, производство инженерных образцов и т.д. Реже NRE — требование дизайн-хаусов, которые берут на себя доработку вашего продукта.
MCU / SOC / SOM (Microcontroller Unit / System On Chip / System On Module) — один компонент (чип или модуль) на печатной плате, в котором размещены микроконтроллер или микропроцессор, в некоторых случаях, беспроводные интерфейсы, а в SoM еще и память, управление вводом/выводом, управление питанием, вплоть до физических интерфейсов для подключения периферии. При определенных требованиях, SOM или SOC могут ускорить разработку продукта.
FCC (Federal Communications Commission / Федеральная комиссия по связи) — федеральный регулирующий орган в США, который контролирует использование беспроводной связи в товарах, выпускаемых или импортируемых в США. Если вам предстоит получение сертификата FCC, запланируйте 2 DVT сэмпла для прохождения обязательных тестов.
CE (Conformité Européenne) — упрощенно, маркировка CE указывает на то, что изделие не является вредным для здоровья его потребителей, а также безвредно для окружающей среды. Обязательный сертификат для товаров, распространяемых на территории EEA (European Economic Area / Европейской экономической зоны).
SKU (Stock Keeping Unit) — код, применяемый к уникальному продукту. Каждая ревизия, модификация, цвет корпуса, размер памяти и другие отличия моделей в вашей линейке продуктов должны иметь уникальный SKU. Без этого продукт просто не дойдет до полки в магазине. Помните, что слишком много SKU сведут ваш стартап в могилу поставят ваш бизнес под угрозу.
Производство
CM (Contract Manufacturer, контрактный производитель) — компания, которая производит продукцию или компоненты для другой компании. Стартапы, нанимающие CM, предоставляют всю необходимую документацию (DFM), чтобы начать производство своего продукта. Большую часть прибыли CM получает от использования ручных операций и за счет наценки на компоненты от других поставщиков.
OEM (Original Equipment Manufacturer, оригинальный производитель оборудования или компонента) — компания, которая самостоятельно занимается дизайном, разработкой и производством продукции, и имеет право распространять ее под собственным брендом или продавать сторонним компаниям для распространения под чужим брендом.
ODM (Original Design Manufacturer, оригинальный изготовитель дизайна) — компания, которая, получив от заказчика проектную документацию, берет на себя не только изготовление, но и разработку изделия. Обычно в этой компании есть отдел R&D, который помогает стартапу довести дизайн продукта до фактической готовности к массовому производству.
EMS (Electronic Manufacturing Services, услуги по производству электроники) — компании, которые проектируют, тестируют, производят и поставляют электронную продукцию, а также предоставляют услуги по ее ремонту и восстановлению. Крупные EMS — это компании с многомиллиардным оборотом и штатом специалистов высокого уровня. Компании меньшего масштаба в основном практикуют смешанную бизнес-модель EMS/ODM, причем часто компенсируют отсутствие собственных производственных мощностей обширным пулом партнеров и подрядчиков.
Tier 1/2/3 Contract Manufacturer — уровень контрактного производителя согласно его годовому доходу:
Tier 1/2/3 Supplier (поставщик 1/2/3 уровня) — типы поставщиков по положению в цепочке поставок. Когда Ford собирает автомобиль, то покупает готовые решения (например, сиденья в сборе) у поставщика уровня 1, который, в свою очередь, покупает дополнительные элементы (электроприводы и подголовники) у поставщика уровня 2, который покупает детали и материалы отделки (пластиковые кнопки и кожу) у поставщиков третьего уровня.
MOQ (Minimum Order Quantity / минимальный объем заказа) — минимальное количество единиц продукции, которое производитель считает достаточным, чтобы принять заказ в работу. Большинство CM в действительности заботит общая стоимость заказа, а не количество произведенных устройств.
RFQ (Request For Quote) — формальный процесс, используемый при выборе поставщика или контрактного производителя. Стартапы часто неправильно интерпретируют процесс RFQ и просто отправляют по электронной почте чертеж CAD, рассчитывая на ответ с ценой. Выстраивание хороших отношений с CM — это куда более сложный и тонкий процесс, сродни пути от первого свидания до создания семьи и производства детей.
MSA / PA (Manufacturing Service Agreement / Purchase Agreement) — соглашение между стартапом и производителем. MSA охватывает наиболее критичные параметры сотрудничества: сроки, штрафы, ответственность за брак, условия оплаты, прогнозы и т.д. Для обеих сторон рекомендуется включать в договор и согласовывать перед началом производства все параметры сотрудничества, однако на практике это случается редко.
Tooling (технологическая оснастка) — чаще всего, это металлические пресс-формы для производства частей корпуса литьем из пластика или штамповкой из металла.
PCBA (Printed Circuit Board Assembly, печатная плата в сборе) — печатная плата (PCB) с припаянными к ней компонентами. PCBA — один из наиболее значимых узлов в электронных продуктах. Обычно PCBA производятся вашим CM, сторонним EMS или фабрикой по производству печатных плат.
SMT (Surface Mount Technology, технология поверхностного монтажа) — это способ, которым большинство современных электронных компонентов напаивается на печатную плату.
Ramp up («наращивание») — термин для описания темпов роста объемов производства. Часто выглядит как серия S-образных кривых во времени, показывающих медленный рост в начале, максимальное ускорение посередине и стабилизацию перед началом следующего производственного цикла.
Yield (выход) — процент произведенных устройств, которые соответствуют требованиям к качеству и могут быть проданы клиентам. Хорошая фабрика выдает не менее 98% продукции, пригодной для поступления в продажу. В yield могут попадать продукты, которые нуждаются в доработке перед продажей.
Scrap or Defect Rate (уровень брака) — процент произведенных устройств, которые следует утилизировать по причине найденных дефектов. Этот коэффициент — обратная величина Yield, но часто ошибочно используется для обозначения продуктов, нуждающихся в доработке перед поступлением в продажу.
Payment Terms — условия оплаты, которые выдвигает производитель. Обычно это количество дней до полной оплаты за произведенный объем продукции, которая передается стартапу. Большинству новичков не стоит рассчитывать на гибкость производителя в этом месте; 50% партии оплачивается при размещении заказа и еще 50% — перед отгрузкой. Опытные стартапы, сумевшие выстроить доверительные отношения со своим CM, могут претендовать на отсрочку 30 или 90 дней после выхода груза с фабрики.
Цепи поставок и логистика
Gift box («подарочная коробка») — упаковка, в которой пользователь получает продукт. Чаще всего это основная коробка, разработанная создателями продукта, но термин подходит и для дополнительной защитной упаковки, в которой Amazon и некоторые другие ритейлеры доставляют товары из своих магазинов.
Case / Master Carton — большая картонная коробка для перевозки партии продукта на дальние расстояния. В зависимости от форм-фактора и размера упаковки продукта в Master Carton помещается от 5 до 50 единиц продукции, после чего большая картонная коробка погружается на поддоны (Palletes) для последующей перевозки.
FOB (Free / Freight On Board) — момент передачи права собственности на продукцию от производителя к заказчику. Если вы производите продукт в другой стране, этот момент в большинстве случаев наступает в порту экспорта, когда перевозчик (Forwarder) контрактного производителя (CM) выгружает товар (Goods) для последующей погрузки на судно или самолет. FOB — лишь один из множества вариантов перехода прав собственности на товар от производителя к заказчику. Свод таких правил называется Incoterms, и достаточно подробную информацию о них можно найти в Википедии.
Duties / Customs (сборы и пошлины) — сборы, уплачиваемые за вывоз груза в страну и вывоз из нее. Составляют до 10% стоимости, в зависимости от продукта. Неуплаченные вовремя таможенные пошлины могут стать источником значительных задержек доставки груза.
Freight Forwarder (перевозчик / экспедитор) — компания, которая помогает перемещать товары между фабрикой и складом дистрибьютора. Экспедитор бронирует места на грузовом транспорте (грузовые автомобили, поезда, корабли, самолеты). Заработок перевозчика зависит от объемных и весовых параметров груза, поэтому молодым стартапам трудно обеспечивать хорошие цены на небольшие партии.
Landed Cost (себестоимость) — общая стоимость производства и доставки одной единицы. Включает в себя COGS плюс затраты на перевозку, хранение, фулфилмент, страхование, конвертацию валюты и комиссию за банковские операции.
ERP (Enterprise Resource Planning, планирование ресурсов компании) — программное обеспечение, используемое для управления бизнес-операциями. Для аппаратных стартапов наиболее важным аспектом системы ERP является планирование и управление цепочками поставок и учет запасов. С ростом компании ERP начинает покрывать бухгалтерский учет, продажи, закупки, управление производством, человеческие ресурсы и т.д.
Маркетинг и дистрибуция
Crowdfunding — способ привлечения финансирования через онлайн-платформы, используемые для предварительных продаж продукта (часто до их полного проектирования и производства), валидации спроса, сбора и анализа пользовательских предпочтений перед официальным стартом продаж. Crowdfunding — прекрасный способ запуска для определенных категорий потребительских товаров.
PO (Purchase Order, заказ на поставку) — официальное соглашение между клиентом и поставщиком о покупке партии продукта. Ключевые условия включают в себя количество, стоимость, время от оплаты до отгрузки и даты оплаты. PO используется для заказа продукта у CM или компонентов для производства продукта.
Distributor — компания в цепочке поставок, которая покупает продукцию у производителей и перепродает их с существенной (да-да, мы знаем) наценкой другому бизнесу в цепочке поставок, который уже продает ее конечным пользователям (обычно, это розница). Дистрибьюторы хранят продукт на своем складе и берут на себя продажу вашего продукта крупным розничным сетям. Ритейлеры часто доверяют дистрибьюторам больше, чем молодому стартапу «с улицы».
CAC (Customer Acquisition Cost, стоимость привлечения клиента) — стоимость привлечения одного пользователя вашего продукта. Рассчитывается путем деления маркетингового бюджета на количество проданных единиц продукции.
Channel (это канал, как ни странно) — путь, по которому приходит конечный пользователь, купивший продукт. Это могут быть прямые продажи на вашем сайте, e-tail (интернет-магазины), специализированные магазины (электронные розничные сети, операторский ритейл, и т.д.), или гипермаркеты с широкой ассортиментной матрицей. Стартапам следует выбирать каналы продаж в зависимости от предпочтений целевой аудитории и позиционирования продукта.
MSRP / Прейскурантная цена (рекомендуемая производителем розничная цена) — наиболее высокая цена, которую, по вашему мнению, конечный клиент готов платить за ваш продукт. Розница будет пытаться продавать ваш продукт дешевле MSRP, чтобы использовать цену как конкурентное преимущество и увеличивать оборачиваемость. Ваша задача — поддерживать MSRP во всех каналах.
Sell-in (продажи ритейлеру) — количество единиц продукции, которые ритейлер соглашается приобрести у стартапа или дистрибьютора. В большинстве случаев ритейлер оплачивает приобретенные товары после их продажи конечному потребителю, что указывает на очевидную выгоду работы с розницей через дистрибьютора.
Sell-through and Sell-out (продажи конечному пользователю) — момент, когда продавец продает единицу конечному потребителю, а также — объем проданных единиц продукции. Стартапы считают товар проданным только в этот момент, и исходя из этого рассчитывают выручку. В отчетности, как правило, указывается в виде процента от Sell-in.
Lift (рост) — увеличение продаж продукта в результате маркетинговой акции. Чаще всего указывается в процентном выражении.
Backstock (товарный запас) — количество единиц, необходимых ритейлеру для поддержания складского запаса. Большинство ритейлеров включает в заказ 20-50% от объема заказа в качестве backstock.
EOL (End Of Life, конец жизненного цикла) — момент окончания производства продукта или модели. Большинство потребительской электроники имеет жизненный цикл от 12 до 18 месяцев.
MRR / ARR (Monthly/Annual Recurring Revenue) — регулярная выручка от услуг, которые получает пользователь продукта после его покупки. В глазах инвесторов регулярный доход увеличивает оценку компании в 5-10 раз по сравнению с бизнес-моделью продажи «железа».
Attach Rate — процент пользователей, которые подписываются на дополнительные услуги после покупки продукта. Успешные «хардверные» компании зарабатывают 30-35% дохода за счет предоставления дополнительных услуг.
LTV / CLV (Lifetime Value of a Customer) — общий доход с клиента за весь период «жизни» или пользования продуктом. Этот показатель включает в себя доходы от продажи оборудования, подписки на сервисы, продажи аксессуаров и т.д. Расчет LTV требует знания % оттока (churn), изменения маржинальности продукта в динамике и затрат на удержание пользователей.
В следующей статье расскажем о нюансах разработки и производства в больших и маленьких hardware-компаниях: в чем ключевые отличия, и на что обратить внимание hardware-стартапу.
Чтобы не пропустить следующие статьи из цикла, а также другой полезный контент для IT- и hardware-стартапов и анонсы мероприятий о развитии бизнеса и технологиях — подписывайтесь на пятничную рассылку ФРИИ!