Отделы мертвы, да здравствуют сервисы

В мае 2013 года мы с моим другом-коллегой Вадичкой открыли веб-студию. Я делал сайты, а он их продавал.

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

Через пару лет я оказался в Авентусе и стал тимлидом. С самого начала я почувствовал какую-то искусственность происходящего. Когда мы с Вадичкой и парой веб-мастеров выживали на умирающем рынке, все ощущалось настоящим. Тут же была какая-то симуляция реальности.

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

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

К счастью, в конце 2021 года я попал на тренинг по канбан-методу, благодаря которому я узнал о таком подходе, как...

СЕРВИСНАЯ ПАРАДИГМА

Организация — это не иерархия отделов и департаментов. С точки зрения сервисной парадигмы, организация — это цепочка зависимых сервисов.

Было "отдел бухгалтерии" — стало "сервис бухучета". Было "юристы" — стало "сервис юридических консультаций и услуг по представлению организации в суде". Было "гребаные айтишники" — стало "сервис с гребанными айтишниками".

Сервис должен разработать протокол взаимодействия с собой. Кто и какие запросы может подавать на вход в сервис? В какое время они обрабатываются? Как долго ждать результатов?

Сервис формирует для своих потребителей ожидания о своей пропускной способности и времени исполнения поручений. Все это должно быть задокументировано и представлено на всеобщее обозрение.

Если на сервис увеличивается спрос, ему надо принять меры по удовлетворению этого спроса.

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

Это уже больше похоже на то, как работает рынок. Жестоко, зато свободно от чуши.

Правила сервиса

Попробуем описать правила для сервиса “Разработки и поддержки CRM Шманус 3.0”.

Типы работ (в основном) отличаются друг от друга технологическим процессом. Если для выполнения “Новой функциональности” требуется код-ревью, а для “Системного дефекта” — нет, то это повод их разделить. Если же подход один и тот же, то их можно слить в один тип.

Виды работ должны быть терминами заказчиков. Тип “Таска для фронтендера” — не из мира заказчиков, они такое заказывать не будут.

Итого, у нас 3 типа: Новая функциональность, Системный дефект, Выгрузка статистики.

К примеру:

• на класс "Стандартный" мы реагируем, как только до него дойдет очередь в рабочие часы с 10:00 по 19:00;
• на класс "АСАП" мы реагируем в течение 10 минут в рабочие часы с 10:00 по 19:00;
• на класс "Единичная проблема с клиентом" мы реагируем в течение 10 минут в рабочие часы с 10:00 по 19:00, но, на усмотрение исполнителя, работа может быть отложена до следующего дня, если проблема действительно единичная;
• на класс "Массовая катастрофа" мы реагируем сразу же, как только кто-либо из команды заметил появление запроса, независимо от дня недели и времени суток;
• на класс "Суита" мы реагируем, когда кому-то в сервисе нечего делать, у него есть пара минут, и он не хочет поощрять свою порнозависимость.

Класс обслуживания — не синоним приоритета. Приоритет определяет лишь, что важнее. Класс обслуживания описывает больше нюансов.

Для каждого пересечения типа запроса и класса обслуживания определите, кто может давать такое поручение.

К примеру:

• тип Системный дефект с классом Массовая катастрофа может выставлять кто угодно;
• тип Новая функциональность с приоритетом Стандартный могут выставлять господа А, Б, В;
• тип Новая функциональность с приоритетом АСАП может выставлять только CEO;
• тип Выгрузка статистики с классом Массовая катастрофа не может выставлять никто, потому что это какая-то чушь.

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

Эта доска именно для заказчиков. Если для членов команды нужно больше инструментов координации (подзадачи, релизы, компоненты) — делайте это где-то отдельно. Не стоит нагружать внешних наблюдателей ненужными им подробностями.

Укажите, где на доске точка принятия обязательств и где — точка передачи результатов заказчику. Традиционно принятие обязательств возникает, когда заказ вытягивается на доску, а передача — в предпоследней колонке доски, сразу перед “Принято”. Вы можете определить для себя любые другие точки.

Давать обещания нужно по двум метрикам: пропускной способности и времени реализации.

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

Сделайте это в разрезе всех комбинаций типов работ и классов обслуживания. Так, чтобы можно было ответить на вопрос “За сколько будет сделан заказ на новую функциональность, если повысить класс до АСАП?”.

Эта метрика называется service level agreement или SLA.

Теперь к пропускной способности. Добейтесь того, чтобы взятые в работу заказы не простаивали у вас на доске без внимания. Для этого ограничьте количество заказов, которые могут присутствовать на доске одновременно, с помощью WIP-лимитов.

Меряйте, сколько заказов прошло через сервис за, к примеру, месяц. Так вы сформируете ожидания насчет объема работ, которые ваш сервис может переварить.

Будьте предсказуемы

Не забывайте регулярно обновлять документ с правилами и обещаниями. Прислушивайтесь к потребностям клиентов. Уточняйте свои обещания, если статистика изменилась.

Главное требование к сервису внутри организации — его предсказуемость. Только благодаря предсказуемости все сервисы могут начать работать в одном ритме.