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

Более трех лет назад в 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 и бэклог уже существующих требований.

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

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

• Определяем состав сервисных процедур и CRU/FRU-концепцию.

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

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

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

Итог этапа: сформировали требования для команды разработки по обеспечению serviceability продукта в конкретном релизе. 

Разработка

Переходим к важному и длительному этапу работы. Каждый пункт здесь — недели работы и обсуждений с проектной командой:

• Согласуем реализацию функционала и тест-планы.

• Создаем новые и актуализируем существующие сервисные процедуры.

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

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

Итог этапа: описали сервисные процедуры . 

Запуск продукта

Еще один комплексный этап, который включает следующие действия: 

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

• Участвуем в поставке продукта на производство: утверждаем со своей стороны процесс производства продукта и заменяемых компонентов

• Участвуем в подготовке обучающих и сертификационных материалов по продукту.

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

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

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

Работа с обратной связью

Мы добрались до финального этапа, который завершает «конвейер» работ отдела сервисного дизайна. Задачи здесь во многом — про сбор и анализ фидбэка.

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

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

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

Итог этапа: сформировали требования для будущих релизов. 

Несколько примеров изменений

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

В системе хранения данных и серверах: 

В серверах:

В системах хранения данных:

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

Расскажите, есть ли у вас в компании подобные специалисты? Схожи ли задачи и процесс работы? Делитесь в комментариях!