Cервисный дизайн: как мы проектируем функционал обслуживания продуктов

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

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

Serviceability и сервисный дизайн в YADRO

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

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

Отдел сервисного дизайна в YADRO сопровождает разработку более 20 продуктов компании, которые относятся к линейкам систем хранения данных TATLIN, серверов VEGMAN, коммутатора KORNFELD и клиентского оборудования KVADRA.

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

Про отдел сервисного дизайна продуктов

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

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

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

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

В команде на текущий момент есть две активных роли: технические менеджеры продукта и проектные менеджеры. Расскажу о каждой чуть подробнее.

Технические менеджеры продукта

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

Каким опытом обычно обладают технические менеджеры: 

• Они обслуживали системы «в полях» — в центрах обработки данных, on premise-инсталляциях и так далее. То есть они были на месте сервисных инженеров, знают об их потребностях не понаслышке. Как правило, они работали с разными вендорами, такими как Dell EMC, CISCO, IBM, HP, и их флагманскими продуктами. Знают плюсы и минусы в обслуживании таких систем, понимают, каким должен быть правильный сервисный опыт и как стратегически развивать продукт в этой плоскости.

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

• Получили опыт работы в качестве пресейл-инженера или инженера по внедрению систем enterprise-класса у клиентов как в России, так и за рубежом

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

Скорее всего, вы подумаете, что на 100% готовых таких специалистов на рынке нет. И будете правы. Базовый минимум — это понимание и знание, как работает система, за которую отвечает технический менеджер, сильные инженерные навыки. Остальные навыки, в том числе экспертиза в продуктах YADRO, бизнес- и системный анализ, постановка требований в продукты, — то, чему мы можем обучить и обучаем на этапе онбординга. Для этого у нас есть база знаний команды, а также менторство — старшие технические менеджеры сопровождают новых сотрудников в первых задачах.

Мы расширяем команду технических менеджеров. Обратите внимание на вакансии, если вы заинтересовались работой в отделе сервисного дизайна: 

• инженер сервисного дизайна для систем хранения данных, 

• инженер сервисного дизайна для пользовательского оборудования. 

Проектные менеджеры

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

Что обычно делают проектные менеджеры: 

• Планируют работы технических менеджеров по новым выпускам продуктов.

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

Отдел сервисного дизайна взаимодействует с большим количеством подразделений в компании

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

Про serviceability-требования к продуктам

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

Сейчас в базовый набор входит порядка 200 требований к продуктам по части их диагностики и обслуживания. Часть требований заимствованы из действующих в РФ стандартов по ремонтопригодности и обслуживанию.

Все они собраны в документ Serviceability Framework, который де-факто является стандартом внутри компании и используется на различных стадиях разработки продукта — от концепта до выпуска релиза.

Несколько примеров требований к serviceability продукта.

С точки зрения конструкции: 

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

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

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

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

• При выдвижении системы из стойки она не должна задевать провода и другие важные для работы устройства элементы.

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

С точки зрения программного обеспечения: 

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

• Логи должны быть компактными, быстро скачиваемыми, читаемыми, чтобы была возможность в кратчайшие сроки разобраться в первопричинах тех или иных событий или неисправностей в системе.

• Необходимо предусмотреть ролевую модель, чтобы доступ к критическим системам бизнеса был у ограниченного числа людей.

Как строится работа по продуктам: от концепта до «заката»

От продукта к продукту состав работ может немного меняться. Почему? Есть флагманские продукты, которые давно представлены на рынке, — например, TATLIN.UNIFIED. Здесь задача — оперативно обрабатывать фидбэк как сервисных инженеров, так и заказчиков, встраиваться в новые релизы с запросами на улучшения. А есть продукты, которые мы только выпускаем на рынок — например, коммутатор KORNFELD. Тут специалисты команды подключаются к работе, начиная с фазы концепта. Под разработку коммутатора — нового для YADRO продуктового направления — мы наняли технического менеджера, который был специалистом в сетевом оборудовании с опытом разработки подобных устройств.

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

Формирование требований к продукту

Итак, у нас есть концепт продукта. Какие основные действия можно выделить на этом этапе: 

• Изучаем концепт.

• Формируем набор требований к продукту с помощью Serviceability Framework.

• Определяем потребность в стендах для SVB (serviceability), на которых будем отрабатывать новый функционал и сервисные процедуры.

• Планируем сроки и ресурсы команды — кто будет вести проект со стороны технических и проектных менеджеров.

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

Планирование работ команды по релизам

Что делаем на этом этапе:

• Формируем набор требований по развитию функциональности к конкретному релизу, опираясь на концепт, Serviceability Framework и бэклог уже существующих требований.

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

• Формируем план работ команды сервисного дизайна.

• Определяем состав сервисных процедур и 

  Было	→ неинформативные записи в логах и их большой вес.
  Стало	→ меньше записей, более долгое хранение логов, удобство в диагностике.