«70% соответствия ТЗ — это уже хорошо»: три мифа заказной разработки

Привет, Хабр! Меня зовут Александр Сахаров, я директор по работе с партнерами компании «Диасофт».

За двадцать с лишним лет в индустрии никто из нас не видел идеального ТЗ. Ни разу. При этом каждый новый проект начинается с уверенного «у нас всё прописано». Компании теряют сотни миллионов на выборе стека, который считают «деталью». А low-code продолжают высмеивать, не заметив, что инструмент за десять лет стал другим.

Три мифа, за которые индустрия стабильно платит: «у нас всё написано в ТЗ», «архитектура и стек — детали, разработчики разберутся», и «low-code — для тех, кому лень писать настоящий код». Я собрал практиков из заказной разработки, чтобы разобрать каждый из них без лишней дипломатии. Получился один из редких разговоров, где люди активно спорят, защищая свою точку зрения.

Скажу честно, я лицо заинтересованное. В «Диасофт» мы развиваем платформу Digital Q на которой из 15 000 строк кода около 14 500 генерируются автоматически, а разработчик работает с бизнес-логикой, а не с инфраструктурой. Именно поэтому мне было важно услышать тех, кто делает иначе. 

Свои реплики, для удобства чтения, я поставил наравне с остальными участниками.

Полная запись на Youtube. Обсуждение — в Telegram-канале Департамент разработки.

За 22 года идеального ТЗ ни разу не было

Андрей Свинцов, управляющий партнер IT-компании Morizo: «За 22 года работы компании ни одно техническое задание не обошлось без уточнений и детализаций. Качество постановки прямо отражает, есть ли у заказчика внутренняя экспертиза по запуску проектов разработки. Если есть, на стол ложится сбалансированное ТЗ, полностью описывающее объект автоматизации со всеми процессами. Если нет, постановка ограничивается точкой старта и точкой финиша, а маршрут между ними, с ограничениями и важными нюансами, остается за кадром. По сути, это уже не техническое задание, а набор бизнес-требований».

Вадим Гончаров, руководитель разработки Your Next Agency: «Требования к проекту правильнее воспринимать как приглашение к сотрудничеству и стартовый набор вводных. Полностью законченного ТЗ заказчик не отдает практически никогда: он передает рамку, а специалист ее реализует, оформляет и при необходимости углубляет. Бизнес отвечает за свою часть, инженер за свою. Единственное по-настоящему закрытое ТЗ за всю мою практику касалось крошечной фичи, собрать которую можно было почти на коленке. Все остальное это, по сути, развернутое приглашение к разработке деталей».

Тимур Васильев, Tech Lead в Paybis LTD: «Уточнения к технической постановке появляются практически всегда, это нормальный режим работы. Любая фича, маленькая или большая, проходит через несколько итераций, прежде чем доходит до приемлемого состояния. Многое определяет экспертиза команды: при низкой экспертизе вопросы идут к самому каркасу постановки, при высокой — только к узким местам новой функциональности».

Ибрагим Габидуллин, руководитель отдела разработки ICL Services: «Заказчик приходит со своим ТЗ. Команда его принимает, разбирается в задаче, дальше совместно дорабатывает: появляются макеты, детальные описания, согласования. На входе в разработку документ выглядит безупречно. И все равно по ходу проекта что-то приходится менять. Заказчик раньше видел задачу одним образом, теперь иначе. За это время меняется техстек, обновляются требования, появляются новые идеи реализации. Если финальная система соответствует ТЗ примерно на 70%, это уже хороший сценарий. Плохой — когда расхождение заметно больше».

Виталий Янко, управляющий партнер Softwarelead.pro и основатель сообществ SPB Founders и ExportNow: «Для нас важно не совпадение с ТЗ, а соответствие итоговой реализации заявленному набору фич. Чем сложнее продукт, тем больше расхождение, и обычно оно существенно превышает 50%. К точному попаданию никто не приближается, бывают ситуации, когда желаемое расходится с действительным на две трети. Разрыв в треть встречается только у очень маленьких продуктов, закрывающих одну микрофичу. На открытом рынке типичная история такая: планировали один диапазон, попали в другой, и разрыв чаще всего выше 70%».

Бизнес сам не знает, чего хочет

Александр Сахаров, директор по работе с партнерами компании «Диасофт»: «Я прошел весь маршрут изнутри: программист, аналитик, ИТ-директор. Когда я сам писал бизнес-требования, ни один программист не имел права отступить от них ни на йоту: внутри прописаны и алгоритмы, и структуры функций. По сути это был квазикод, который оставалось перевести на текущий стек, будь то IBM или Oracle. Но таких аналитиков на рынке мало. 95% реальных требований выглядят иначе: «сделай то, не знаю что, примерно так и куда-то туда». Дальше начинается классический сценарий. Документ ложится на стол к системным аналитикам, и каждый понимает его по-своему. Команда разработки переводит результат в код тоже по-своему. Времени и бюджета не хватает, программисты увольняются дважды, архитектор меняется дважды, на выходе получается просто какой-то код. Бедному заказчику остается узнать в Википедии, как организовывать приемочное тестирование, и обнаружить, что эта работа полностью его. Тестировщики на стороне заказчика прогоняют сценарии руками по ночам, проект растягивается на годы. Еще 3 года назад такой диагноз можно было поставить любому крупному проекту с бюджетом свыше 150 миллионов рублей. Сейчас условия меняются. Перед отправкой бизнес-требований исполнителю я могу прогнать их хоть через простой DeepSeek, попросить обогатить документ архитектурными и процессными схемами, получить полный набор тестовых сценариев. На все это уходит 15 минут. Дальше остается дождаться, как именно меня попробуют обмануть».

Андрей Свинцов: «Все участники процесса должны действовать как одна команда: бизнес, ИТ, разработка. Каждый заинтересован в конечном результате, и в этом смысле ответственность общая. Серьезный разрыв между требованиями и тем, как их транслируют и понимают дальше, возникает ровно тогда, когда каждая сторона тянет в свою. Бизнес хочет получить факт реализации. Разработчики хотят применить новые технологии и насладиться стройностью кода, хотя красота кода важна только им самим и на конечный результат, как правило, не влияет. Задача собрать всех вокруг общей цели лежит на человеке, отвечающем за продукт: CPO, менеджере проекта, неважно. Это главный фактор успеха. Если развернуть команду в одну сторону не удалось, результат проекта будет непредсказуем ни по бюджету, ни по срокам, ни по качеству».

Тимур Васильев: «Этот тезис работает только в исключительных случаях. В крупных и зрелых компаниях бизнес отлично знает, чего хочет: зарабатывать деньги. Разработка, как обычно, хочет работать на свежих технологиях, чтобы было приятно, и не хочет переписывать большие куски кода или связываться с некрасивыми решениями. Отсюда и растет конфликт. Бизнес говорит, что разработка не выполняет требования, разработка говорит, что бизнес не понимает, чего ему нужно. Технические документы и постановка задачи играют роль моста между двумя разными городами, которые друг друга понимать не хотят. И именно через этот мост чаще всего выходят качественные продукты».

Александр  Сахаров: «Каждый из нас когда-нибудь делал ремонт квартиры или просил у искусственного интеллекта «сделай меня красивым». Картинка приходит, и тут оказывается, что не нравится нос. Просишь поменьше нос. Потом глаз. Это нормальный процесс: есть начальные требования, есть результат, и у заказчика естественно возникает аппетит проект поправить. Занимать позицию «бизнес, ты сам не знаешь, чего хочешь, я тебе сделал как ты просил, а ты тут нос правишь» совершенно некорректно. За 35 лет на рынке мы эту проблему всегда видели и решение для нее нашли. Очень плохо, когда код приходит в виде черного ящика: на любые косметические изменения он отвечает поломками. Поправил нос — поехало ухо. Поправил ухо — утонул хвост. Чтобы такого не происходило, мы всегда использовали платформенный подход. Инструмент проектирования визуален: заходишь в бизнес-процесс, правишь квадратики, добавляешь стрелочки, запускаешь пилот, например, на Пензу. Если отработало — разворачиваешь на всю Россию. То же самое с экранными формами и с архитектурой: открыл карту сервисов, добавил метод, попросил систему проверить обратную совместимость, выкатил на ограниченную группу пользователей. Если же все висит в виде кода в черном ящике, и в этот код руками лезут разные команды, мы получаем ту самую картину, когда голова утонула, а хвост плывет. Дальше начинаются взаимные обвинения: айтишники тупые, бизнес не знает, чего хочет».

Роман Кузнецов, CEO Mobecan: «Техническое задание не нужно воспринимать просто как документ с каким-то текстом. Это инструмент сокращения неопределенности на проекте. Неопределенность есть всегда, и документ должен закрывать ее максимально, подсвечивая нюансы. От проработки деталей реализации, понятной всей команде, напрямую зависит, попадем ли мы в зафиксированный бюджет. Перед подписанием фикс-контракта мы отдельно продвигаем клиенту еще один договор, на проектирование. В его рамках появляется пул артефактов: функциональное описание, пользовательские сценарии, техническое описание, разные ФЛК. Все это снижает неопределенность. А сам фикс-прайс по сути придуман для финансистов: позволяет заранее зашить в бюджет конкретную сумму, прийти на совет директоров и сказать, что за эти деньги бизнес-задача будет решена. Дальше ответственность ложится на менеджера заказчика и команду разработки».

«Не важен стек — получите палатку вместо дома»

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

Ибрагим Габидуллин: «Задача определяет стек технологий. Эксперименты и свежие технологии это прекрасно, но цена ошибки заранее не считается: непонятно, во сколько обойдется откат, если выбранная история не подойдет. Любые технологические решения должны проходить через денежный фильтр и через того, кто отвечает за бюджет. При этом маленький бюджет не означает автоматический выбор популярного и дешевого стека. Иногда наоборот: именно он дает шанс взять что-то новое и перспективное, что вытащит проект в будущее».

Тимур Васильев: «За неоправданные инвестиции в стек отвечает тот, кто принял решение его внедрить. Каждый раз при внедрении новой технологии нужно считать плюсы, минусы, риски и обоснованность. Я многократно слышал истории, когда компании переходили с одного языка программирования на другой — особенно популярно это было после появления Go. Внятно объяснить, почему отказались от прежнего стека и потратили месяцы на переписывание микросервисов, такие команды не могли. Внутри компании всегда должен работать контроль решений. Разработчики обожают тащить в проект все свежее, особенно на фронтенде, где новые фреймворки выходят буквально каждый день. Но нужно трезво оценивать, какой объем денег компания может потерять на внедрении, испытаниях и откате новой технологии».

Андрей Свинцов: «Стек не критичен у проектов с коротким жизненным циклом в части разработки, хотя в части доступности для пользователя такой продукт может жить годами. Лендинг можно собрать за день, дальше он просто висит в интернете. Часто при обсуждении стека исходят из ложного допущения, что он однороден. На больших проектах техстек как раз неоднороден: какие-то участки пишутся на одном языке для удешевления, какие-то на другом, под задачи совсем другого уровня. Выбирать единую технологию на весь проект не обязательно и часто менее эффективно, чем подбирать точные решения под конкретные подзадачи. И главное, особенно на средних и долгосрочных проектах — доступность ресурсов. Редкую технологию можно взять сейчас, но потом не найти специалистов для сопровождения, либо платить им так дорого, что вся выгода от автоматизации исчезнет под стоимостью поддержки. Доступность специалистов на конкретном языке программирования и конкретном продукте для меня один из ключевых параметров выбора».

Александр Сахаров: «Если вам стек не важен, не удивляйтесь, что вместо нормального дома вам подгонят палатку. При строительстве собственного жилья каждый внимательно смотрит на материал, а в ИТ-проекте почему-то нет. Заказчик, для которого стек не имеет значения, обычно неопытный: за свою жизнь он сделал 2-3 проекта и не знает реальных рисков. Можно привести десятки примеров, когда «неважный» стек превращался в дополнительные расходы на сотни миллионов рублей. Сегодня стек критически важен: с неправильным стеком вы просто не пройдете приемку инфобеза, и все вложенные деньги, включая заложенные под проект квартиры, рискуют оказаться потерянными. Если попадается клиент, заявляющий, что стек ему не важен, на его стороне лучше найти другого человека, с которым технологический выбор можно обсудить и зафиксировать, чтобы потом не разбираться по формуле «я не знал, я не я, корова не моя».

Вадим Гончаров: «Если я захочу купить автомобиль, я пойду спросить совета у того, кто в машинах разбирается и сам их не продает. Параллельно посоветуюсь со знакомыми и с людьми с опытом. Нетворкинг работает. По стеку моя позиция такая: пусть его выбирают разработчики и аналитики. Если бизнес не разбирается, на чем лучше делать его задачу, разобраться при желании можно. Но не стоит держать строгое мнение в духе «я хочу веб-сайт на C++, делайте мне так»».

Динозавры с лопатой и трактор рядом

У последнего мифа репутация еще тяжелее: low-code в индустрии принято считать игрушкой для тех, кому лень писать настоящий код. Эту позицию разделяют и часть опытных руководителей разработки.

Роман Кузнецов: «Для большой корпоративной системы low-code я бы точно не использовал. Неизвестно, что дальше будет с конкретным инструментом, будет ли он развиваться. На это надеяться нельзя».

Александр Сахаров: «Low-code старого поколения действительно нужно выбросить на помойку: он монолитен, закрыт, вендорлочен, не масштабируется, инфобез не проходит. От Oracle Forms и Lotus Notes до Microsoft Dynamics, SAP и наших добрых друзей-конкурентов из российского BPM-сегмента, все это прошлый век. На дворе 2026 год. Сегодня low-code это полностью открытый frontend, полностью открытый backend, полностью открытая архитектура, DevOps на том же GitLab. Хочешь править руками — правь, хочешь рисовать картинки — рисуй, все между собой синхронизировано и проконтролировано. Платформа берет на себя всю скучную работу: процедуры логирования, юнит-тесты, управление ролями, горизонтальную масштабируемость, ФЛК. Параллельно с кодом она генерирует документацию по ГОСТ и РБПО, прогоняет специализированные тесты. По сути это экзоскелет, с которым один разработчик выпускает из-под себя полноценную систему. Из 15000 строк кода, которые сегодня выходят из-под программиста, примерно 14500 генерируются автоматически, по шаблону или при помощи модели. Писать руками одно и то же, изобретая каждый раз тот же велосипед, это максимальный бред. Заказчику я сдаю документ в Word и проект в Git с полностью открытым кодом, который проходит DAST, SAST и любые приемочные проверки. Открытый код можно посмотреть в Аэрофлоте, в Дом.РФ, у десятка других клиентов: любой при желании может развивать его без нас. Писать руками то, что современные инструменты делают за тебя, сегодня будут только динозавры. Это как копать 10 гектаров лопатой, когда рядом стоит трактор».

Андрей Свинцов: «В этот мир я во многом верю и во многом согласен. Изначально low-code и no-code как терминология применялись к блочному софту, который позволял быстро что-то сконфигурировать. То, о чем сейчас идет речь, это уже скорее no-code в современном прочтении: формулируешь задачу не кодом, а на естественном языке, дальше пайплайны в GitLab собираются как хочешь. Минус один, но фатальный: без должного контроля код получается неконсистентным. Если кинуть в систему файл с ТЗ и сказать «сделай тут красиво, эта кнопка пока не работает», она сделает, и какое-то время результат даже будет работать. Но чтобы стабильно получать из этого качественный продукт, нужен серьезный навык. Многим его пока не хватает, и слепо доверять автогенерации, не глядя в код, опасно».

Вадим Гончаров: «Признаюсь, наверное, я тоже 50 на 50 динозавр. За меня сейчас работают агенты, это правда. Но ни разу пока не получалось с нуля поставить задачу и получить идеальный результат: с темплейтами, тестами и всем остальным. Все будет зелененькое, все пройдет, все будет красиво. А когда начнешь это менять, выясняется, что во многих местах ИИ оставил скрытые подводные камни. У меня есть кейс в системе здравоохранения: специальные шифрованные файлы, которые передаются по протоколу HL7 с применением FHIR. Парсить их отдельное удовольствие, и здесь ИИ хорошо помогает, по факту работает как современный low-code для конкретной задачи. Один из недавних проектов, сайт для известного армянского музыканта, мы целиком собрали на low-code платформе: там очень мало кастомщины, и продукт прекрасно живет. Это просто сайт, ничего глубокого в нем нет. Но как только в работу заходят сложные интеграции, скрытые кондишены, нелинейные рекурсии, приходится нырять туда с глубокими знаниями технологии, стека и бизнеса».

Дорогу перекопали, маршрут перестраиваем

Андрей Свинцов: «Разница между бизнес-требованиями и техническим заданием хорошо ложится на аналогию с картами. Бизнес-требование это пустая карта с двумя точками: старт и финиш. Техническое задание это уже Яндекс.Карты с проложенным маршрутом и обозначенной топологией. И именно во множестве возможных маршрутов кроется та разница, которая постоянно возникает между бизнесом и разработкой. Любой документ остается живым даже в условиях госконтракта, мы все это прекрасно знаем. Идешь по маршруту, проложенному вчера, а сегодня на нем прорвало трубу и дорогу перекопали. Маршрут надо обходить, у тебя на руках уже новый план. Эта аналогия отлично описывает и изменяемость требований, и столкновение взглядов, которое возникает в каждом проекте».

Идеальное ТЗ не страхует от перекопанных дорог. Правильный стек их тоже не убирает. И ручной код, противопоставленный «несерьезному» low-code, добавляет на маршруте только лишние ямы. Все три обсужденных мифа держатся на одной общей иллюзии: что хаос можно зафиксировать бумагой, контрактом или выбором языка программирования. Фиксируется он другим, живым инструментом, который ходит вместе с проектом и пересобирает маршрут на ходу. 

Дальше каждый решает сам, копать ему лопатой или садиться на трактор.