Управление 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. Главное, быть как можно ближе к своим конечным пользователям, чтобы создавать действительно полезный продукт. И быть как можно ближе к процессу производства, чтобы создание Вашего продукта было экономически выгодным.

    «Актив»

    47,00

    Компания

    Поделиться публикацией
    Комментарии 15
      –1
      Какой программой пользуется менеджер по продукту для сопровождения изделия в течении всего жизненного цикла изделия?
        –1
        А какой программой пользуется менеджер для сопровождения программного продукта?
          0
          Странно, что Вы у меня спрашиваете ответ на этот вопрос, а не у автора статьи, хотя у меня есть мнение на этот счёт.
          Принятие решения об использовании того или иного программного продукта для сопровождения изделия в течении всего жизненного цикла зависит на каком уровне развития находится организация, производящий продукт. Кому то достаточно таблицы Excel, а кто то использует PLM, например, класса Teamcenter.
          После такой большой обзорной статьи хотелось бы узнать как обстоят дела в конкретной компании.
            0
            Я как-то участвовал в разработке контроллера для, скажем, газового котла.
            Так заказчик сразу сказал, что мы делаем контроллер, они его два дня тестируют и принимают.
            Все — никаких позже доделок-переделок, апдейта фирмваре более не предусматривается.
            Заказчик рассматривает сложное микроконтроллерное устройство, как деталь, выточенную на станке — садится на посадочные места — значит все ОК.
            Пытался рассказать им про жизненные циклы, про возможные баги в микропрограмме, про систему контроля версий исходных кодов микропрограммы- смотрят на меня непонимающим взглядом.
            Думаю у них даже и эксель таблицы не было.
            Но так дело и не пошло, хоть и контроллер сделали и даже приняли его.
            Заказчик в итоге решил, что проще покупать импортные контроллеры — дешевле и морок меньше.
              0
              Проблему отсрочили, но не решили.
              Рано или поздно вопрос обновления прошивок в покупных контроллерах всё равно встанет. Всё таки котёл покупается не на один год.
        0
        Менеджер по продукту — тот, кто раньше назывался главным конструктором изделия?
          0
          Не совсем. Главный конструктор, например, не изучает потребность пользователей. Да и сколько денег можно заработать при добавлении определенного функционала в продукт тоже не его головная боль
            0
            «Потребность пользователей» — это вообще довольно абстрактное понятние.
            Зачастую «потребность» приходится насаждать рекламой (или введением новых законов), прежде чем она действительно станет «потребностью».

          +1
          Про сертификацию электронных устройств было бы интересно узнать подробнее.
            0
            Тут в двух словах не ответишь. Постараюсь сделать отдельную статью на эту тему
            0
            И всё это — всего лишь про USB свистки!)))
              0
              Токены это все-таки не самые простые «USB-свистки». Для больших и серьезных железок все очень похоже. Только вопросов и нюансов на каждом этапе в десятки раз больше
                0
                Просто мне приходится смотреть на ситуацию с точки зрения эксплуатанта куда более сложных систем, включающих, помимо софта и электроники, весьма непростую механику. Откуда, если наблюдать достаточно долго, можно весьма выпукло увидеть, как вендоры справляются (или не справляются) с комплексом проблем, возникающих в ходе жизненного цикла их оборудования. Один из них — крупная англо-американская компания с вековой историей, другой — корейская, вышедшая на рынок в конце 90-х. Честно говоря, не могу себе представить российскую компанию на их месте, в первую очередь потому, что там нужен не менее чем 20-летний горизонт планирования по каждому семейству продуктов.
              0
              Мне как пользователю лучше пользоваться E-token, из преимуществ отмечу:
              удобное программное обеспечение, у корпуса носителя удобная форма
              и прочные материалы.
              У RU-token при частом использовании (бухгалтерия, закупки) корпус трескается
              у USB-разъема, статикой пробито 4 штуки (e-token ни одного) и это при соотношении 1:10.

              Покупать e-token уже нельзя из-за импортозамещения.
                0
                Про проблему с корпусом знаем. Именно поэтому в этом году будет новый корпус, еще более прочный.
                А чем наше ПО не удобное сможете конкретизировать? Обратная связь мне всегда интересна.

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

              Самое читаемое