Управление hardware-продуктом: путь тяжелых компромиссов
За последние несколько лет в России появилась и оформилась новая профессия — менеджер по продукту. Конечно, 10 лет назад были специалисты, которые выполняли обязанности менеджера по продукту или эти обязанности были распределены между несколькими людьми. Теперь же на рынке есть немало готовых специалистов, спрос на них, а также масса различных курсов по подготовке, статей на эту тему и так далее.
К сожалению, 99.9% всех этих полезных материалов и курсов относятся к управлению программными продуктами. Более того, большая часть из них сосредоточена на онлайн-сервисах и мобильных приложениях. Они обсуждают MAU и прочие метрики, а также инструменты, которые помогают с ними работать. К сожалению, большая часть этих метрик не работает для корпоративных продуктов или для hardware-продуктов.
Информации по управлению hardware-продуктами очень мало, попробую это исправить. Начнем с небольшой статьи об отличиях управления hardware-продуктами от управления программными продуктами.
Сложность
Большинство hardware-продуктов сложнее большинства программных. Нет, я ни в коей мере не хочу принизить сложность больших программных продуктов или веб-сервисов. Просто очень часто веб-сервис, это только веб-сервис. А hardware-продукт — это почти всегда не только сама железная начинка, но и драйверы, прикладной софт и даже дополнительные веб-сервисы для работы с этой железкой. В худшем случае (с точки зрения сложности конечно) вам надо создать Apple iPhone, когда кроме прикладного софта вам надо построить целую экосистему.
Например, наша компания занимается производством электронных идентификаторов для аутентификации и электронно-цифровой подписи. В нашем случае продукт — это не только железка, но и драйверы под Windows, Linux и MacOS + прикладные библиотеки + SDK + прикладной софт + расширение для браузера + приложения для мобильных телефонов (Android и iOS). Необходимо также поддерживать различное open-source ПО, работающее с такими устройствами (openssl, opensc, openct и так далее). Плюс документация и база-знаний.
Это приводит к тому, что при создании такого hardware-продукта приходится работать с множеством различных команд: от мобильных разработчиков до схемотехников. Даже дизайнеров для такого продукта необходимо как минимум два — для ПО и так называемый промышленный дизайнер.
Дизайн
Дизайн и проектирование важны при любой разработке. В современном мире продукты все больше начинают конкурировать между собой не только и не столько функционалом, сколько удобством использования. К счастью, для разработчиков программных продуктов дизайн можно переделать. И в большинстве случаев это не такая сложная задача. С hardware-продуктами все гораздо сложнее — внешний дизайн напрямую связан с тем, что находится внутри, например, печатной платой. И желание немного переделать внешний дизайн может привести к полной переделки продукта внутри. А значит такое изменение требует гораздо больше времени и специалистов. Плюс аппаратный дизайн тесно связан с производством и будущем ремонтопригодностью продукта. Вспомните печальную историю с корпусами Galaxy Note 7, когда решение уменьшить корпус на несколько миллиметров, привело к массовым возгораниям.
Запуск и ритм релизов
Добавление новых функций или релизы продукта при управлении программным продуктом зависят только от людей вашей компании — разработчиков, маркетологов, юристов и так далее. А производство hardware-продукта включает в себя правильную координацию и работу с массой других компаний. Разработка «железа» включает в себя естественные жизненные циклы, это означает, что один раз пересекая определенную веху, вы оказываетесь в точке невозврата, когда изменения могут привести к очень большим задержкам в вашем roadmap — не говоря уже о значительном повышении стоимости.
Например, токены Рутокен имеют ограниченный набор цветов и форм корпуса. Представьте, что в середине разработки менеджер продукта решил сделать устройство нового нестандартного цвета и формы. Такой процесс потребует не только редизайна и прототипирования, но и проверки того, что производство действительно сможет произвести такой продукт, поиск поставщиков пластика нужного цвета с подходящими характеристиками, поставка пластика на производство (в нужные вам сроки и за подходящую цену), производство первой партии, дополнительного тестирования, и возможно добавление чего-то в прошивку. Этот процесс может занять месяцы! Сравните это с добавлением кнопки или сменой цвета в интерфейсе пользователя в программном продукте, где весь процесс до релиза может быть меньше недели.
Выпуск полностью нового продукта может занять больше года от момента идеи до поставки конечным пользователям и это абсолютно типичная история. Многое может случиться на рынке за это время и без хорошего исследования вы можете оказаться с продуктом, который совершенно не нужен рынку. При разработке онлайн-продукта вы сможете выйти на рынок меньше чем через 6 месяцев (но даже за это время может многое поменяться).
Даже итерации по обновлению программного обеспечения для «железа» могут потребовать комбинации сервера, клиента, прошивки, изменений в ОС, а все это может занять очень много времени.
Метрики и проверка гипотез
Проверка гипотез в hardware продуктах значительно усложнена. Очень часто вы можете следить за эффективностью той или иной фичи, только наблюдая за продажами и то косвенно. Представьте, что вы добавили в пылесос или холодильник кнопку для нового режима работы. Как понять ее эффективность?
Даже проведя прямой опрос и выяснив, что пользователи этой кнопкой не пользуются, не так-то просто понять почему — был плохой маркетинг этой функции? Инструкция была плохо написана? Или пользователям вообще не нужна эта функция? Это дополнительно усложняется тем, что между вами и конечным пользователем очень часто стоит ритейл, который может иметь свои интересы. Например, пользователям агрессивно продвигали дополнительную гарантию на устройство, для которого вы только что подняли надежность.
Здесь вообще бывают фантастические ситуации. Представьте, что вы производите фильтры для питьевой воды. Завтра вы разработали новую технологию и выпустили фильтр, который надо менять в полтора раза реже, чем у конкурентов. С одной стороны, это выглядит как достоинство продукта. С другой стороны, ритейлеру выгоднее говорить, что все фильтры одинаковые и менять их надо с одинаковой частотой, так как это позволяет ему продавать больше и соответственно больше зарабатывать. А ваша конкурентная борьба его мало интересует.
Вам сложнее ощутить себя пользователем системы, поэтому необходимо как можно чаще общаться с реальными пользователями. Причем надо общаться не только с B2B-клиентами, но и с конечными пользователями. А техподдержка должна быть вашим лучшим другом. Например, если вы производите средства электронной подписи, то часть тестовых сценариев доступна только для определенных групп юридических лиц. В случае системы ЕГАИС — только для поставщиков или продавцов алкогольной продукции. И никто из участников такой системы не хочет давать вам боевые сертификаты для полномасштабного тестирования и выявления каких-то проблем.
При разработке программного продукта вы с командой можете экспериментировать и в финальный релиз добавлять только подошедшие штуки, при этом легко вырезая ненужные. При разработке hardware-продукта создание прототипа и получение обратной связи может занять много времени, быть очень дорогим. «Железные» продукты почти никогда не получают настоящего бета-периода и не могут быть пропатчены после релиза, если была обнаружена критическая неполадка.
Продукт можно потрогать руками
Аппаратный токен — это осязаемый продукт, который поставляется конечным клиентам. А это значит, что менеджер такого продукта получает дополнительную работу — доставка и гарантийное обслуживание.
Клиенты не могут просто скачать новый токен или войти в систему, нажав кнопку. Не важно, доставляете ли вы своему бизнес-партнеру, или договариваетесь с ритейлом, менеджер продукта получает дополнительную пачку головной боли — предложение и спрос, логистика, упаковка и розничное партнерство.
Упаковка продукта зачастую играет очень важную роль — это первый пользовательский опыт по взаимодействию с вашим продуктом. Как и в продуктовой разработке немалый тренд в этом направлении задает Apple. Ее коробки с iPhone навсегда изменили упаковку смартфона. Хорошая упаковка должна быть привлекательной, функциональной, надежной, стоит также упомянуть хорошие инструкции. А возврат продукции — это логистика наоборот — гарантийный ремонт, диагностика, замена и так далее.
Сертификация
Если вы разрабатываете продукты в области информационной безопасности, то знаете о различных сертификациях и требованиях к тем или иным продуктам. Это касается как программных, так и аппаратных продуктов. ФСТЭК, ФСБ и Минобороны — это только небольшой список сертифицирующих органов в сфере ИБ в России.
Даже если вы не работает в сфере ИБ, а производите продукцию для широкого потребителя вам понадобится соответствовать массе требований. Наверняка вы видели различные значки и наклейки на инструкциях бытовых электроприборов о соответствии различным стандартам и выполнениях условий различной сертификации. Что еще печальнее — эта сертификация обычно привязана к конкретным регионам, а значит при поставке продукта в несколько стран вам необходимо учитывать их требования. А так как эти требования могут противоречить друг другу, вы можете оказаться в ситуации когда вам понадобится выпускать несколько версий одного и того же продукта для разных регионов.
Стандарты — это отличная штука, но иногда они имеют определенный набор требований, который диктует поведение продукта или ограничивает его. Это добавляет вызов продуктовой команде, которая должна сделать продукт, который удовлетворяет всем требованиям и при этом создает хороший пользовательский опыт.
Этот вызов особенно силен при разработке продуктов, связанных с безопасностью в целом и информационной безопасностью в частности, где большая часть требований по безопасности так или иначе снижает пользовательский опыт. К сожалению, большинство отечественных продуктов в этой сфере заставляют пользователей не радоваться новому продукту, а страдать.
Срок жизни продукта
Если вы разрабатываете онлайн-сервис, то все ваши пользователи используют его последнюю версию. И вам надо поддерживать только ее. В случае с тяжелым программным обеспечением поддержка может растянуться на годы. Но в случае «железных» продуктов она почти всегда составляет годы или даже десятки лет. И устройство должно не только работать физически, но и в большинстве случаев поддерживаться вашим новым программным обеспечением. Возрастает нагрузка не только на разработчиков, но и на сотрудников технической поддержки. Все это вам необходимо учитывать при выпуске новой версии.
Вам заранее нужна стратегия по завершению жизненного цикла и завершению поддержки продукта. Причем вам заранее необходимо подготовить максимально плавную возможность для перехода.
Надежность
Даже первая версия вашего продукта должна быть на 100% рабочей. Когда вы пишете программное обеспечение, особенно если мы говорим о различный онлайн-сервисах, у вас нет никаких проблем с временно неработающими компонентами или допущенными ошибками. Вы сможете их поправить и быстро выкатить. Когда вы покупаете железный продукт, внесение исправлений практически невозможно. Плюс сами пользователи при покупке чего-то материального крайне рассчитывают на то, что при работе не будет никаких проблем.
Если онлайн-сервис упадет на 5 минут, то максимум что случится, это пара плохих новостей в Интернете. Если на 5 минут откажет железка в критической инфраструктуре — у вас будут большие проблемы.
Экономика и стоимость
Обычно разработка hardware-продуктов требует гораздо больше денег. Кроме стоимости разработки — это также стоимость компонентов, производственные мощности, производственный персонал, стоимость складирования (как компонентов, так и готовой продукции).
Как менеджер продукта, вы должны думать о сокращении затрат на производство. Проектировать новые продукты необходимо с применением готовых решений или стандартных компонентов. Это важно не только для снижения стоимости вашего продукта, но и позволит вам стандартизировать производство. Что в свою очередь еще сильнее снизит стоимость производства и, что еще более важно, увеличит скорость выхода на рынок нового продукта.
Прогнозирование продаж
Очень важным становится прогнозирование продаж не только для оценки выручки, но и для цепочки поставок и загрузки производства. Правильные коммуникации с вашими менеджерами по продажам, и их правильные коммуникации с клиентами необходимы для анализа эффективности и оценки будущих инвестиций.
Прогнозирование объемов позволяет группам цепочки поставок и производства создать производственный план и поддерживать оптимальный уровень запасов компонентов и готовой продукции для экономии. Цепочка поставок дополнительно использует прогнозирование для оптимизации затрат на компоненты, необходимые для производства вашего продукта.
Логистика и производство
Наблюдайте за производством, поставщиками и логистикой. Как менеджеру продуктов вам совершенно не хочется этим заниматься, но это определенно жизненно важно для понимания текущих операционных расходов, помогающих избежать таких неожиданных трат, как отзыв продукта или его отсутствие на складе.
Например, автоматизирован или нет процесс логистики? Есть ли у них свои точки проверки работоспособности на каждой стадии? Как завод принимает решения по жизненно важным компонентам? Это только несколько примеров, но не бойтесь погрузиться глубже и задавать вопросы. Даже задавая вопросы команда будет вовлечена и если случится какая-то проблема, вы будете знать нужных людей, с которыми вы сможете ее решить.
Краткий итог
Надеюсь, описанные мною трудности и проблемы, с которыми сталкивается менеджер hardware-продуктов, не отпугнут тех, кто решил встать на этот путь, а только подстегнут их. Ведь создавать продукты, которые можно потрогать руками, это действительно здорово!
Да, на этом пути будет немало сложных задач, трудных решений и непростых компромиссов. Но без этого не получится хорошего продукта, какой бы он не был — hardware, software или service. Главное, быть как можно ближе к своим конечным пользователям, чтобы создавать действительно полезный продукт. И быть как можно ближе к процессу производства, чтобы создание Вашего продукта было экономически выгодным.
