За свою жизнь я успел поработать в нескольких крупных компаниях. Телеком, ритейл, финансы — неважно. И почти везде встречал одно и то же явление: система, которая должна помогать пользователю (и бизнесу), превращалась во врага.

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

Поздравляю. У вас вырос корпоративный IT-монстр.

Кто такой корпоративный IT-монстр и где он обитает

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

Монстр обладает удивительными свойствами:

• без него работать нельзя (встроен в процессы, ВНД требует);

• с ним работать невозможно (тормозит, глючит, бесит);

• юзеры его ненавидят, но заменить нельзя («мы же столько в него вложили»);

• на его поддержку уходит куча ресурсов (и не только денежных);

• DAU в разы меньше MAU — в систему для ежедневной работы заходят раз в неделю.

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

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

Вендорлок и другие способы выстрелить себе в ногу

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

Проблемы часто начинаются позже: бизнес меняется, процессы эволюционируют, а система — нет. Точнее, она эволюционирует по roadmap вендора, которому ваши специфические потребности не слишком интересны.

И вот тут вылезает вендорлок во всей красе:

• любая доработка — только через вендора (за деньги);

• лицензии считаются каким-то хитрым образом;

• интеграция с другими системами — отдельный квест с неизвестным финалом;

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

Что хуже вендорлока? Когда для собственной разработки создают процессы «как у взрослых». Менеджмент начитался про enterprise-подходы и решил: раз большие компании так делают, значит, и нам надо. Появляются архитектурные комитеты, change advisory board, релизные окна раз в квартал.

«У них так сделано, значит, правильно» — и понеслось. Теперь чтобы добавить поле в форму, нужно пройти семь уровней согласования. Не потому, что это технически сложно, — программист сделает за день. А потому, что «положено», best practices, «а вдруг сломается».

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

Пошаговая инструкция по выращиванию монстра

Шаг 1. Перестаньте слушать пользователей

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

Разработка рассуждает: «Зачем им Excel, если есть наша прекрасная система?» А продажник в это время ищет клиента в Excel 10 за секунду против минуты в системе.

Шаг 2. Создайте иллюзию обратной связи

Проводите опросы удовлетворенности. Собирайте NPS. Стройте красивые дашборды. Главное — правильно интерпретировать.

CSI = 3,2 из 5? Нормально, больше половины! Пользователи заходят в систему только в последний день месяца? Отлично, не перегружают сервера в остальные дни. А еще можно смотреть не на те метрики. Количество операций растет? Супер! Эффективность упала в три раза и половина работы переделывается? Это не наша проблема, это пользователи не умеют работать.

Шаг 3. Растяните time-to-market до бесконечности

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

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

Шаг 4. Игнорируйте производительность

Поиск записи работает 30 секунд? Это нормально, база большая. Сохранение данных — минута? Зато надежно, с тремя бэкапами и логированием.

Пример из жизни: продажник за день должен обработать 50 лидов. В CRM это занимало весь день. Что он делает? Правильно, записывает все в блокнотик, а в систему вносит раз в неделю скопом. 

Шаг 5. Создайте культ карго

«У Amazon так!» — и неважно, что у Amazon другая бизнес-модель, другие процессы и бюджет на IT куда больше. Agile? Конечно, но со всеми старыми регламентами. DevOps? Обязательно, но деплой по-прежнему раз в месяц и на ручном приводе.

Шаг 6. Превратите разработчиков в касту жрецов

Они знают все тайны системы. Без них ничего не работает. Любая критика системы — это критика их профессионализма.

Пользователь жалуется, что неудобно? «Он просто не умеет пользоваться». Предлагают заменить систему? «Они не понимают, насколько все сложно».

И вот уже разработка защищает монстра. Потому что монстр — это их детище, их крепость, их зона комфорта.

Симптомы: как понять, что монстр уже выращен

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

Синдром параллельной реальности

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

Крайняя стадия: в общих папках файлы с названиями типа Актуальные_данные.xlsx.

Синдром постфактума

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

Синдром ложных метрик

Формальные показатели растут, реальная эффективность падает. CSI держится на уровне 4,0? Отлично. Только это потому, что недовольные уже уволились. Количество операций в системе увеличилось? Да, потому что для одной задачи теперь нужно в пять раз больше действий. Руководство смотрит на красивые дашборды и не видит, что бизнес теряет деньги.

Синдром окопной войны

Три лагеря, три позиции, ноль диалога:

• IT: «Пользователи не умеют работать».

• Пользователи: «Система неработоспособна».

• Руководство: «Ну, мы же не зря купили!»

Вместо решения проблем — бесконечный поиск.

Синдром стокгольмский

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

Новая система? Это же учиться заново, терять экспертность, становиться новичком. Лучше уж терпеть знакомого монстра.

Как не вырастить монстра: противоядие

Правило погружения

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

Правило быстрых изменений

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

Правило открытости

Никаких черных ящиков. Пользователь не должен мириться с проблемами, имея лишь возможность сообщить о них. Разработчик должен видеть, как его код используется в бою. Руководство должно видеть реальные метрики использования, а не причесанные отчеты. API документирован, интеграции прозрачны, данные доступны. Любой может посмотреть и сказать: «А почему у нас простой поиск делает 15 запросов к базе?»

Правило пользы

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

Что делать, если монстр уже есть

Вариант 1. Параллельная реальность

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

Вариант 2. Революция снизу

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

Вариант 3. Терапия для монстра

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

Вариант 4. Признать поражение

Иногда монстра проще похоронить, чем лечить. Если на поддержку системы уходит больше денег, чем она приносит пользы, — пора принимать сложное решение. Да, будет больно. Но продолжать кормить монстра — еще дороже.

Главное правило: слушайте пользователей

В чем главная проблема всех монстров? Их создатели в какой-то момент решили, что знают лучше, чем пользователи. Что те «просто не понимают». Что «им надо привыкнуть». Что «это best practices».

А пользователи в это время тихо создают свой теневой IT — Excel, Google Sheets, Notion, тетрадку в клеточку. И работают там, где удобно, а не там, где «правильно». Самый простой способ не вырастить монстра — регулярно спрашивать пользователей: «Вам удобно?» И если ответ «нет» — не объяснять, почему они неправы, а исправлять.

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

P. S. О культуре и стратегии

Помните фразу Питера Друкера Culture eats strategy for breakfast? IT-монстр сначала съедает культуру компании, превращая ее в культуру обходных путей и теневого учета. А потом эта изуродованная культура сжирает любую стратегию цифровой трансформации.

Вы можете сколько угодно рисовать красивые roadmap`ы и говорить про digital-first. Но пока ваши сотрудники ведут записи в блокноте, а в систему заходят только для отчета, — у вас нет цифровой трансформации. У вас есть дорогой электронный журнал учета.