Желание помочь и цена этой помощи
«Хотели как лучше, а получилось как всегда».
Виктор Черномырдин
В основе работы большинства ИТ-специалистов лежит простая и очень человеческая мотивация — быть полезными. Не просто закрыть задачу в трекере и перейти к следующей, а действительно решить проблему, услышать благодарность, увидеть, что кому-то стало легче работать. Я не раз встречал разработчиков, которым было важно общаться с пользователями, потому что без этой обратной связи работа теряла смысл и превращалась в механическое выполнение инструкций.
Эта мотивация особенно заметна в молодой команде, где ещё нет усталости от операционного потока и каждый запрос воспринимается как возможность доказать ценность ИТ. Руководитель разработки становится точкой входа для боли бизнеса: через него проходят ожидания, дедлайны, срочность и эмоциональное давление. Каждая задача выглядит оправданной, потому что за ней стоит реальный человек и конкретная проблема.
Параллельно существуют задачи, у которых нет лица и нет немедленной благодарности. CI, автотесты, архитектурная стабилизация, устранение скрытых зависимостей, снижение технического долга. Их нельзя продемонстрировать завтра на совещании как «вот результат». Их эффект распределён во времени, а значит — менее заметен.
На уровне ценностей это конфликт добра с добром. С одной стороны — помочь здесь и сейчас. С другой — обеспечить устойчивость системы на горизонте года и больше. Если модель управления не закрепляет второй горизонт формально, руководитель разработки почти всегда выбирает первый. Не потому что он не понимает стратегию, а потому что давление текущих задач всегда громче.
«Проверим руками» и накопление незаметного замедления
«Отличный план! Надёжный, как швейцарские часы»
Гай Ричи, «Snatch»
Сценарий повторяется в разных компаниях почти одинаково. Конец месяца, срочная доработка в расчёте себестоимости, жёсткий срок. Изменяется формула распределения затрат, затрагиваются аналитики, интеграционные выгрузки, управленческие показатели. Руководитель разработки понимает риск регрессии, но времени на автоматизацию нет — релиз уже в работе.
Решение принимается привычное: проверяем руками. Команда проходит основные сценарии, релиз выходит. Через некоторое время обнаруживается редкий случай, который не попал в проверку. Начинается разбор, дополнительные сверки, объяснение бизнесу.
Через несколько недель похожая история происходит в другом контуре — доработка интеграции с CRM, изменение статусов, переработка расчёта KPI. И снова ручной регресс, потому что «сейчас не до автоматизации».
Через полгода становится заметно, что регресс стал отдельной фазой релиза, время подготовки к выпуску увеличилось, оценки сложных задач стали осторожнее, а изменения в расчётных механизмах вызывают напряжение. Формально команда та же, компетенции выросли, но скорость изменений начинает снижаться.
Самое опасное — постепенность. Нет точки перелома. Замедление накапливается через дополнительные проверки, временные решения и осторожность. На горизонте двух–трёх лет это приводит к системному эффекту: команда избегает архитектурно сложных инициатив, бизнес осторожнее инициирует изменения, релизы становятся рискованнее.
Ручная проверка не плоха сама по себе. Она просто плохо масштабируется. И когда бизнес говорит «проверим руками», он прав в масштабе текущей задачи, но ошибается в масштабе траектории.
Операционный и инвестиционный поток как управленческое решение
«Большая сила — это большая ответственность».
Человек-паук
В любой ИТ-системе существуют два типа работы. Операционный поток даёт немедленный эффект и имеет конкретного заказчика. Инвестиционный поток даёт отсроченный эффект и почти никогда не имеет лица.
Когда оба потока конкурируют за один ресурс, операционный почти всегда побеждает, потому что он эмоционально убедительнее и проще объясняется. Руководитель разработки может балансировать внутри команды, но без закреплённого управленческого решения этот баланс нестабилен.
Именно здесь начинается зона ответственности Руководителя корпоративных информационных систем. Его задача — определить траекторию, а не просто распределять задачи. Инвестиционный поток должен быть зафиксирован формально: часть мощности команды направляется на автоматизацию регресса, стандартизацию релизов, устранение скрытых зависимостей и архитектурную стабилизацию. Этот объём не исчезает автоматически при каждом срочном запросе, а перераспределяется только осознанным решением с пониманием последствий.
Важно, чтобы этот поток был измеримым. Не «мы внедряем CI», а «мы удерживаем время релиза в заданном диапазоне», «мы снижаем долю ручного регресса», «мы уменьшаем количество инцидентов после релиза». Разговор должен идти не об инструментах, а об управляемости.
CI — это не технический долг, а механизм ограничения его накопления. Если относиться к нему как к второстепенной задаче, он будет проигрывать всегда. Если рассматривать его как элемент модели развития, он становится частью стратегии.
Экономика замедления и выбор траектории
«Отсель грозить мы будем шведу».
А.С. Пушкин
Замедление редко воспринимается как экономический фактор. Оно ощущается как «немного дольше», «чуть осторожнее», «надо перепроверить». Однако в горизонте года это превращается в измеримые потери.
Если доработка, которая раньше занимала две недели, начинает занимать четыре, это означает более поздний вывод продукта на рынок, более медленную реакцию на изменения спроса, более осторожные управленческие решения. Это означает потерянные возможности.
Ручной регресс — это не только время тестировщика. Это время разработчика, аналитика, пользователя, который подтверждает корректность расчётов. Это переключение контекста, дополнительные встречи, повторные проверки. Эти затраты редко отражаются напрямую в бюджете, но они влияют на общую производительность команды.
Скорость изменений — это фактор конкурентоспособности. Компания, которая меняет систему быстрее и предсказуемее, принимает решения быстрее. Компания, где каждое изменение становится рискованным, начинает избегать изменений.
Отсутствие времени на CI — это не техническая проблема. Это индикатор управленческой модели. Реактивная модель живёт от запроса к запросу и всегда выглядит рационально. Управляемая модель требует закрепления горизонта и публичного принятия компромиссов.
Если инвестиционный поток не закреплён, выбор уже сделан — в пользу реакции, а не траектории. И каждый срочный запрос будет рационально вытеснять стратегический.
Вопрос в конечном счёте звучит иначе: готовы ли мы инвестировать в то, чтобы через три года менять систему быстрее, чем сегодня?
Если это решение не принято, времени на CI действительно не будет никогда.