При разработке и производстве программно-аппаратных комплексов в первую очередь думают о функциональности для конечного потребителя. Сложная система типа сервера или системы хранения данных (СХД) должна работать без сбоев, не отставать в производительности от конкурентов, эффективно решать задачи пользователей. Вопросы комфорта обслуживания и диагностики таких систем сервисными инженерами и заказчиком зачастую имеют более низкий приоритет.
Более трех лет назад в 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 и работы с ними.
В системе хранения данных и серверах:
Было | → неинформативные записи в логах и их большой вес. |
Стало | → меньше записей, более долгое хранение логов, удобство в диагностике. |
В серверах:
Было | → много лишних действий при разборке сервера. |
Стало | → изменили некоторые разъемы в NextGen и общую эргономику сервера, теперь нужно меньше инструментов для сервисного обслуживания. |
В системах хранения данных:
Было | → все сервисные операции могли выполнять только инженеры YADRO. |
Стало | → перевели часть таких операций, как замена модулей охлаждения, блоков питания, кабелей и накопителей, в пользовательские; теперь заказчики могут выполнять их самостоятельно в кратчайшие сроки. |
Есть несколько цитат, которыми вдохновляется наша команда. Одна из них принадлежит специалисту в области когнитивистики, дизайна и пользовательской инженерии Дональду Норману. «Существует восемь способов вставить дискету в компьютер, и только один из них верный», — писал он. Пожалуй, инженеры команды сервисного дизайна заботятся о том, чтобы этот единственно верный способ был логичным, быстрым и комфортным.
Расскажите, есть ли у вас в компании подобные специалисты? Схожи ли задачи и процесс работы? Делитесь в комментариях!
