Почему проекты ломаются без “смазки”

Введение: Иллюзия мебели

Большинство проблем в заказной IT-разработке начинаются задолго до того, как программист напишет первую строчку кода. Они начинаются в голове у заказчика в момент формирования ожиданий.

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

Вы купили дорогой стул, поставили его в кабинете, и он стоит там 10 лет. Он не просит обновлений, не конфликтует с новым ковролином и не ломается от того, что в здании поменяли провайдера интернета. Стул — это вещь. Заплатил и забыл.

Но цифровой продукт так не живёт.

Мобильное приложение, CRM-система или B2B-платформа — это не вещь. Это сложный механизм. Двигатель внутреннего сгорания. Его нужно правильно запускать, обслуживать, адаптировать под изменения среды и готовить к нагрузкам.

В IT существует фатальное заблуждение, что продукт может работать “сам по себе”. Что после релиза ответственность заканчивается, и наступает “долгая и счастливая жизнь”.

Правда в том, что любой механизм без смазки начинает стираться. В IT роль этой “смазки” играют процессы:

• подготовка,
• описание логики,
• контроль ожиданий,
• проверка перед запуском,
• сопровождение после релиза.

Проекты крайне редко ломаются в день релиза из-за плохого кода. Авария закладывается намного раньше — в тот момент, когда участники коллективно решают, что подготовка, проверка и сопровождение — это “лишняя бюрократия”, на которой можно сэкономить.

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

Сценарий №1. Иллюзия контроля: Отказ от бизнес-анализа

Первый сбой происходит ещё до первой оценки бюджета, когда клиент пытается перепрыгнуть стадию подготовки и купить контроль над ситуацией.

Клиент приходит не с бизнес-задачей, а с названием технологии.

• Нам нужен Python.
• Мы хотим на Laravel.
• Давайте сделаем на WordPress.

Звучит как конкретика. На деле — это сигнал тревоги.

А фраза “мне всё равно на чём, главное — быстрее” звучит как гибкость. На практике она часто означает, что обсуждение архитектурных ограничений объявляется помехой ещё до начала проекта.

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

Но технология — это не решение. Это всего лишь строительный материал.

Представьте, что вы приходите к архитектору и говорите: “Постройте мне дом из титана”.

Профессиональный архитектор не побежит закупать металлопрокат. Он остановится и задаст вопросы:

• Сколько людей там будет жить?
• Какой климат и несущая способность грунта?
• Какой срок службы и бюджет заложен на эксплуатацию?

И только поняв задачу, он подберёт материал.

В IT работает та же физика. Язык программирования сам по себе не решает проблему бизнеса. Запрос “Хочу на Python” никак не отвечает на вопросы: нужен ли вам быстрый API, требуется ли корпоративный контур безопасности или вам просто нужна удобная админка для контент-менеджеров.

Когда клиент произносит название технологии, а IT-команда радостно кивает и идет писать код без перевода этого запроса на язык бизнес-требований — они строят не продукт. Они строят догадку.

Потому что название технологии никогда не заменяет понимания задачи. А код, написанный без понимания задачи, — это просто дорогая форма гадания.

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

Сценарий 2. Иллюзия определённости: Отказ от проектирования (Fixed Price без ТЗ)

Второй способ сломать проект до его начала — попытаться купить финансовую безопасность, отказавшись от её фундамента.

Обычно этот сценарий начинается с одной и той же фразы: “Мне не нужны долгие исследования и прототипы. Просто скажите мне точную цифру за готовый продукт, и давайте работать”.

Желание клиента получить фиксированную смету (Fixed Price) абсолютно рационально. Так бизнес пытается защитить себя от главного финансового риска — неконтролируемого раздувания бюджета.

Клиенту кажется, что жёсткая цифра гарантирует предсказуемость инвестиций. Проблема в том, что управлять рисками невозможно без информации.

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

Недавно к нам пришла кейтеринговая компания. Им нужна была сложная платформа. Мы объяснили процесс: сначала мы делаем кликабельный прототип, прописываем сценарии пользователей, собираем архитектуру и пишем Техническое Задание (ТЗ). Это займет около двух месяцев, и только после этого появится финальная смета на разработку.

Реакция клиента была типичной: “Зачем мне платить за картинки и тексты два месяца? Я просто хочу знать, сколько стоит сама система!”

Именно здесь механизм клинит намертво.

Фиксированная цена возможна только при фиксированном объёме работ.

А зафиксировать объём работ можно только через прототипы, ТЗ и прояснение всех логических тупиков до написания кода.

Требовать смету без детального ТЗ — это всё равно что просить строителя назвать точную цену дома, опираясь только на фразу: “Ну, мне нужен дом для семьи, два этажа, чтобы было красиво”.

Если строитель всё же назовет цену — он либо заложит туда огромный запас на риски, либо стройка превратится в бесконечный конфликт, когда внезапно выяснится, что “красивый дом” подразумевал ещё и бассейн на крыше.

Если IT-команда соглашается назвать Fixed Price без глубокого проектирования — она вас обманывает. Она продает вам не смету, а гадание.

Клиент, который отказывается от подготовки, прототипов и ТЗ, думает, что он экономит время и борется с бюрократией. На самом деле он отказывается от управляемости.

Без подготовки вы покупаете не управляемость проекта, а неуправляемый хаос. А затем — многомесячный конфликт о том, кто, кому и что именно обещал.

Сценарий 3. Иллюзия консервы: Отказ от сопровождения

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

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

После этого клиент ушёл к инвесторам и исчез из процесса разработки. На сопровождения, ни обновлений.

Спустя почти три года он возвращается с претензией: “Я пытаюсь показать систему новым партнёрам, а она не работает!”

В его картине мира всё абсолютно логично. Он купил “вещь”. Почему она сломалась, если её никто не трогал?

Именно здесь бытовая логика намертво разбивается о физику цифрового мира.

Ответ на вопрос клиента звучит парадоксально: система сломалась именно потому, что её никто не трогал.

Заказчик искренне верит, что написанный код можно “заморозить” и убрать в сейф до лучших времен. Но код не живёт в вакууме.

Потому что цифровой продукт — это не консерва. Это горячая еда.

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

В IT код сам по себе не ломается от времени. Меняется среда, в которой он живёт.

Пока вы не трогаете продукт:

• обновляются браузеры и мобильные ОС;
• исчезают старые версии API;
• истекают токены и сертификаты;
• меняются правила облачной инфраструктуры.

Механизм, который бросили под открытым небом без смазки и техобслуживания, неизбежно заржавеет.

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

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

Контроль — это способ не врать себе

Из кейса с остывшим “цифровым борщом” вытекает фундаментальное инженерное правило.

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

Но мы живём не в идеальном мире.

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

Однако проблема даже не в человеческом факторе. Проблема в физике цифровых систем.

В dZENcode есть жёсткий принцип: пока факт работы системы не проверен лично вами, в актуальной среде и прямо перед событием — этого факта не существует.

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

Контроль перед запуском — это не акт недоверия к клиенту. Контроль — это способ не врать себе.

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

В IT всё, что не проверено в актуальной среде прямо перед использованием, считается сломанным по умолчанию.

Баланс ответственности: Три пути, когда клиент не готов

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

У IT-команды всегда есть соблазн выбрать формальную правоту: “Мы свою часть сделали, код написан, ссылку отдали. Дальше его зона ответственности”.

В реальности у команды есть только три пути.

1. Отказать

Сказать: “Сейчас проект нельзя запускать / показывать / оценивать в таком состоянии. Нам нужно остановиться и пройти этап подготовки”.

Иногда это означает потерю денег в краткосрочной перспективе. Но это сохраняет проекту шанс не умереть позже.

Жёстко, но честно. Отказ чётко фиксирует границу ответственности.

2. Полностью сопроводить

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

3. Пройти полпути

Самый популярный и самый разрушительный вариант на IT-рынке.

Выдать кусок результата, сказать “мы свою часть сделали” и оставить клиента один на один с механизмом, который он не умеет обслуживать.

Третий путь — это ловушка. Полумера создаёт иллюзию безопасности. А иллюзия безопасности всегда опаснее честного отказа, потому что она заставляет клиента принимать бизнес-решения (например, идти к инвесторам), опираясь на ложную готовность продукта.

Если клиент не готов играть по правилам, профессиональная команда не должна делать работу “лишь бы сдать”.

Отказ — это тоже форма заботы о проекте, если единственная альтернатива — продать клиенту иллюзию результата.

Сервисная карта IT-проекта: Что клинит без “смазки”

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

Этап	Что кажется “лишним” (Иллюзия клиента)	Что происходит в реальности (Авария)
Discovery / ТЗ	“Давайте без бумажек, надо сразу писать код”	Хаос ожиданий. Спор по объёму работ. Конфликт из-за выросшей в 3 раза сметы.
Прототип	“Это же просто картинки, мы и так всё понимаем”	Команда программирует не тот сценарий. Дорогие переделки уже готового бэкенда.
Технический выбор	“Мне всё равно на чём, главное — быстрее”	Архитектура не выдерживает роста нагрузки, интеграций или требований безопасности.
QA перед демо	“В прошлый раз открывалось, зачем проверять”	Падение продукта прямо во время презентации перед ключевыми инвесторами.
Техподдержка	“Мы уже заплатили за разработку, оно должно работать”	Продукт быстро деградирует. Отваливаются сторонние API, система становится уязвимой.
Мониторинг	“Если сломается — будем решать по факту”	О критическом сбое первой узнаёт не команда, а клиент заказчика.
Синхронизация	“Напишем вам, когда понадобится”	Клиент выпадает из процесса и обнаруживает чужой продукт вместо своего замысла.

Чек-лист: Готовы ли вы к реальному IT-проекту?

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

1. Капкан Fixed Price: Вы требуете назвать точную цену (Fixed Price) до того, как детально описали все требования, экраны и бизнес-логику?
2. Магия технологий: Настаиваете ли вы на конкретной технологии, хотя ещё не обсуждали с командой бизнес-требования?
3. Синдром консервы: Вы считаете, что после успешного релиза проект можно оставить на год без обслуживания, и он сохранит 100% работоспособность и безопасность?
4. Слепая зона: Вы готовы идти на встречу с инвестором, не проверив в день показа, что продукт вообще открывается?
5. Отношение к процессу: Вы воспринимаете написание ТЗ, прототипирование, созвоны и синхронизацию как лишнюю бюрократию, которая “мешает программистам наконец-то начать писать код”?

Если хотя бы два вопроса вызвали у вас внутреннее раздражение — проблема не в сложности IT. Проблема в несовпадении ожиданий с реальностью цифровых систем.

Вы всё ещё пытаетесь купить стул. А вам предстоит управлять двигателем внутреннего сгорания.

Заключение: Смазка не тормозит механизм

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

Как будто приложение можно “поставить”, закрыть задачу и навсегда забыть о его существовании.

Но цифровой продукт — не предмет. Это живой механизм, существующий внутри постоянно меняющейся среды. Меняются браузеры, API, устройства, сценарии использования, люди внутри бизнеса и сам рынок вокруг продукта.

Именно поэтому подготовка, ТЗ, прототипы, тестовые прогоны, сопровождение и контроль — это не бюрократия. Это форма уважения к реальности сложных систем.

Процесс не тормозит проект. Процесс не даёт ему развалиться на скорости.

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

А клиент, который пытается отказаться от подготовки ради скорости, почти никогда не экономит время.

Он просто переносит аварию в будущее.

• Иногда — на презентацию перед инвесторами.
• Иногда — на запуск рекламы.
• Иногда — на момент, когда продукт уже стал критической частью бизнеса.

Но физика систем от этого не меняется.

Мир не работает без смазки. Цифровые продукты — тем более.

И если клиент не готов обслуживать механизм, профессиональная IT-команда не должна продавать ему иллюзию того, что механизм сможет жить сам по себе.

Потому что инженерная честность начинается с умения вовремя сказать: “Без подготовки эта система сломается.”

Дзен-коан:

Ученик пришёл к Мастеру с гневом:
— Меня обманули! Я купил дорогой меч, хранил его в ножнах много лет, но когда достал для великого боя — лезвие покрылось ржавчиной и рассыпалось.

Мастер ответил:
— Кузнец выковал безупречную сталь. Ты просто ни разу не смазал её маслом. Ты купил оружие, но забыл купить уважение к нему.

P.S. Вспомните свой последний проблемный проект. На каком этапе вы (или ваш клиент) решили “сэкономить время” на подготовке, чтобы потом потратить месяцы на исправление последствий?