Роли и подходы в IT

Что такое клиентоцентричность

Клиентоцентричность (customer centricity) — подход к управлению, при котором компания устроена вокруг задач клиента: от него отсчитываются процессы, метрики, оргструктура и приоритеты, а не наоборот. Решение «делать или не делать» проверяется вопросом «что это даёт клиенту», а не «удобно ли это нам».

Термин часто путают с клиентоориентированностью, хотя это разные уровни:

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

Как это измеряют

• NPS (Net Promoter Score) — готовность рекомендовать по шкале 0–10. Считается как доля «промоутеров» (9–10) минус доля «критиков» (0–6).
• CSAT — удовлетворённость конкретным взаимодействием: оценка после закрытия тикета.
• CES (Customer Effort Score) — сколько усилий клиент потратил, чтобы решить задачу. Часто предсказывает отток лучше, чем NPS.
• Retention и отток (churn) — единственные метрики, которые невозможно нарисовать: клиент либо остался, либо ушёл.

Инструменты подхода

• CJM (Customer Journey Map) — карта пути клиента по всем точкам контакта, от рекламы до отключения услуги. Показывает, где он спотыкается.
• JTBD (Jobs To Be Done) — взгляд на продукт как на инструмент, который «нанимают» для решения задачи. Пользователю не нужен сервер — ему нужно, чтобы сайт работал.
• Customer Development — проверка гипотез разговорами с пользователями до того, как что-то построено.

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

Продуктовый и проектный подход

Два способа организовать работу, которые часто противопоставляют:

Проектный подход уместен там, где результат известен заранее: миграция в другой ЦОД, внедрение системы. Продуктовый — там, где решение неочевидно и проверяется гипотезами. Именно продуктовый подход опирается на Agile и клиентоцентричность.

Роли в IT-команде

• Product Owner / продакт — отвечает за то, что делаем и в каком порядке; владеет бэклогом и метриками продукта.
• Project Manager — отвечает за то, чтобы согласованное было сделано в срок: сроки, ресурсы, риски.
• Аналитик — превращает потребность в требования. Подробнее — в статье про роли аналитиков.
• Разработчик — пишет код и отвечает за его качество, в том числе через code review.
• QA-инженер — отвечает не за «поиск багов», а за информацию о качестве до релиза; см. тестирование.
• DevOps / SRE — доставка кода в production и его надёжность.
• Дизайнер (UX/UI) — проектирует взаимодействие; в клиентоцентричной компании работает с исследованиями, а не только с макетами.
• Тимлид — отвечает за людей и инженерные практики команды.

Две модели того, как эти роли собираются вместе:

• Функциональные отделы — разработчики отдельно, тестировщики отдельно, админы отдельно. Задача идёт по эстафете между отделами и на каждой границе ждёт очереди.
• Кросс-функциональные команды — в одной команде все роли, нужные чтобы довести фичу от идеи до production самостоятельно. Это условие, без которого не работают ни Agile, ни DevOps: если для деплоя нужна заявка в чужой отдел, короткие итерации превращаются в фикцию.

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

Связанные термины

• Agile / процессы разработки — как продуктовые команды организуют итерации
• DevOps — снятие барьера между разработкой и эксплуатацией
• Роли аналитиков — кто переводит потребности в требования
• SLA и отказоустойчивость — где клиентоцентричность превращается в обязательство
• SDLC — жизненный цикл, по которому распределяются роли