Когда человеку говорят:
“Сделайте кнопку”
он представляет себе:
обработчик клика
форму
пару строчек кода
Когда это слышит программист — он напрягается.
Потому что за словом “кнопка” часто скрывается:
изменение бизнес-процесса
отчёты
согласования
десятилетнее легаси
и фраза “раньше в DOS было удобнее”
Со временем начинаешь понимать:
Программирование — это не написание кода.
Это перевод человеческого хаоса на язык, который понимает компьютер.
И вот именно от этого иногда хочется выйти в лес и кричать.
“Сделайте что-нибудь. Мы сами пока не знаем что”
Есть один тип задач, после которого программисты начинают смотреть в стену чуть дольше обычного.
Звучит он примерно так:
“Сделайте нам систему.”
“Какую?”
“Ну… хорошую.”
Или:
“У нас биг дата. Разберитесь там как-нибудь.”
Я работал в фирмах, где постановка задачи выглядела именно так.
Без ТЗ.
Без описания процессов.
Без понимания, что вообще нужно получить на выходе.
А дальше начинается классика:
сделал
показал
“ой, мы имели в виду другое”
переделал
“ну почти”
ещё переделал
И так до бесконечности.
Что происходит на самом деле
Когда требований нет — программист начинает работать:
аналитиком
архитектором
разработчиком
тестировщиком
и иногда психотерапевтом для заказчика
Бесплатно.
Вывод, который приходит с опытом
Если на вопрос:
“Что именно нужно сделать?”
вам отвечают:
“Ну вы же специалист”
— это уже не разработка.
Это попытка угадать чужие мысли за свои деньги и своё время.
“Да что там делать? Просто перенесите”
Это вообще отдельный жанр.
Однажды пришлось переносить несколько старых отчётных систем:
сметы
бухгалтерию
проходческие отчёты
Документации — нет.
API — нет.
Описание логики — отсутствует.
Фактически вся работа превратилась в археологию.
Сидишь и пытаешься понять:
откуда берутся данные
почему цифры не сходятся
зачем тут вообще этот кусок кода
и кто решил хранить бизнес-логику внутри SQL-процедур размером с роман
Причём часть системы вообще работала по принципу:
“Не трогай. Оно как-то живёт.”
А со стороны это выглядело так:
“Ну вы же просто переносите данные.”
Нет.
“Просто перенос” в enterprise-разработке обычно означает:
реверс-инжиниринг
восстановление логики
переписывание поведения системы
и попытку не сломать то, о чём уже никто не помнит
Руководство — не пользователь
Это одна из самых дорогих ошибок в разработке.
Руководство почти всегда говорит одно.
Пользователь — совершенно другое.
История с почтамптом
Когда-то нужно было сделать систему приёма коммунальных платежей:
свет
газ
вода
Начальство рассказывало про:
отчёты
контроль
статистику
Я даже не стал долго их слушать.
Пошёл к операторам.
Девочки сидели и вручную перебивали квитанции в Excel.
Сотнями. Каждый день.
Я сел рядом и просто начал смотреть.
И внезапно выяснилось:
стандартная навигация через Tab им неудобна.
Почему?
Потому что правая рука всё время лежит на цифровом блоке клавиатуры.
Им удобнее Enter.
Казалось бы — мелочь.
Но после изменения навигации скорость работы выросла в разы.
Те же люди начали обрабатывать:
200
300
иногда ещё больше квитанций в день
Без истерик и переработок.
Вот это и есть реальная аналитика.
Не UML-диаграммы.
Не “бизнес-требования”.
А наблюдение за человеком, который работает с системой 8 часов в день.
Пользователь не хочет жить в вашей идеальной архитектуре
Программисты любят порядок.
Справочники.
Категории.
Структуры.
Идеальные модели данных.
А потом приходит продавец в компьютерном магазине.
У него очередь.
Покупатель стоит над душой.
И ему абсолютно всё равно, насколько красива ваша архитектура.
Реальная проблема
Разработчик думает:
“Сначала создадим справочник устройств.”
Продавец думает:
“Мне надо быстро продать товар.”
Если нужной марки нет — он не пойдёт в админку.
Он просто:
введёт текст руками
сломает формат
обойдёт систему
Потому что его задача — работать.
А не поддерживать чистоту вашей БД.
После одного такого наблюдения я вообще переделал логику:
если категории нет — она создаётся прямо во время ввода.
И внезапно оказалось:
пользователи начинают работать с системой нормально, когда система не мешает им жить.
“Сделайте как в DOS”
Есть особый вид инженерного ужаса.
Это когда старый интерфейс живёт в памяти человека лучше, чем современный UI.
Однажды я делал систему для бюро переводов.
Сначала:
расчёт стоимости
потом сайт
потом кабинеты
потом автоматизация процессов
Всё нормально.
А потом руководство сказало:
“Теперь сделайте отчёты.”
Сделал.
И тут началось.
Директор привык к DOS-программам.
Ему хотелось:
плюс — перейти глубже
минус — выйти назад
стрелками листать периоды
и чтобы всё было “как раньше”
Только это уже веб.
HTML.
Браузер.
Совсем другая модель интерфейса.
Но объяснить это невозможно.
Следующие месяцы превратились в бесконечное:
“сдвиньте колонку”
“верните как было”
“кнопочку чуть левее”
“а в DOS было удобнее”
И вот в такие моменты начинаешь понимать:
иногда ты переносишь не систему.
Ты переносишь привычки.
Самый тихий вид провала
Это когда система работает идеально…
но оказывается никому не нужна.
Однажды меня взяли тимлидом на проект биржевой системы.
Полгода работы:
личные кабинеты
торги
распределённая архитектура
защита
репликации
резервирование
Система реально получилась хорошей.
А потом ушёл менеджер проекта.
И сверху прилетело:
“Ну… пока замораживаем.”
Всё.
И это очень важный момент, который редко понимают молодые разработчики:
В разработке бывает не только:
“плохо сделали”
Бывает ещё:
“хорошо сделали, но бизнесу это сейчас не нужно”
Почему программисты всё-таки не сходят с ума
Хотя… иногда сходят.
Но со временем появляются простые правила выживания.
1. Идите к пользователю
Не к начальству.
Не к презентациям.
А к человеку, который реально работает в системе.
2. Наблюдайте до того, как писать код
Иногда один день рядом с пользователем экономит месяц разработки.
3. Задавайте глупые вопросы
Почему Enter?
Почему Excel?
Почему они делают именно так?
Очень часто настоящая логика процесса скрыта именно там.
4. Делайте итерациями
Первая версия почти всегда неправильная.
И это нормально.
5. Если проект мёртв — уходите
Не тратьте годы жизни на систему, которую:
никто не внедрит
никто не поддержит
и которая нужна только в презентации для начальства
Итог
Программирование — это не код.
Это попытка превратить:
хаос
привычки
страхи
бизнес-процессы
и человеческие ожидания
в систему, которая должна работать стабильно.
И чем дольше работаешь — тем сильнее понимаешь:
Хороший инженер отличается не количеством фреймворков в резюме.
А способностью не потерять здравый смысл посреди всего этого хаоса.
Комментарии (32)
gorchaqw
15.05.2026 20:09Не помню точно но кто-то сказал - " Глобальная задача человечества заключается в борьбе с энтропией" вот мы и боремся)) В конечном итоге, на продукт может повлиять только программист, который пишет его и ему приходится делать поправку на факапы , уровень интеллекта вышестоящего руководства и экономическую ситуацию. Это уже давно норма.
AlexM2001
15.05.2026 20:09"Глобальная задача человечества заключается в борьбе с энтропией"
Насколько помню: "В любой системе, без приложения внешних усилий, энтропия повышается "
AndreyDmitriev
15.05.2026 20:09Абсолютно верно, мы всегда в физтехе, когда выпивали, то за энтропию тосты непременно поднимали.
Вообще это применимо и к разработке ПО, вот Джонатан Эдвардс (Jonathan Edwards) как-то замечательно написал "…programming is a desperate losing battle against the unconquerable complexity of code, and the treachery of requirements", и в том что «программирование — это отчаянная, заведомо проигрышная битва с непобедимой сложностью кода и коварством требований» — в общем вся суть, квинтэсенция, так сказать, программирования.
gerbert_MX
15.05.2026 20:09как по мне доступные способы звуко и видеофиксации сделали для ментального здоровья системных инженеров больше чем все психологи мира
не перечесть сколько нервов сберегла фраза "у нас есть запись согласования, делали строго по согласованному"
3aky
15.05.2026 20:09Мне как-то на аргумент - ваша жалоба это запрос на новую разработку, "мы делали по коментарию номер 123 с 45 страницы согласованного вами ТЗ". Ответили - "Ну это же одна строчка". И зачем-то ожидали сочуствия.
gerbert_MX
15.05.2026 20:09бумажки это все от лукавого
а вот когда голосом все проговаривается и вы явно задалбываете вопросами так ли это, вы уверены что больше ничего и тд - вот тогда настояший дзен
сейчас еше AI появился который может вежливо сформулировать ответ на такие претензии никого не оскорбив
3aky
15.05.2026 20:09Я давно зарёкся без бумажек обходиться. Последний раз меня благодарили за отбитую - благодаря бумажке - претензию на довольно много миллионов - хоть чего.
gerbert_MX
15.05.2026 20:09бумажки это базис. но всякие великие руководители на них плевать хотели зачастую не читая даже
а вот видеофиксация или хотя бы аудио, всех обсуждений и согласований снимает головняк когда пытаются продавить на характере так сказать, пытаясь решить здесь и сейчас
Dhwtj
15.05.2026 20:09у нас есть запись согласования, делали строго по согласованному
Переносить все риски на заказчика не профессионально. Всё верно, но если вы станете в позу и не сделаете как надо, то Вам больше ничего не закажут при таком подходе.
gerbert_MX
15.05.2026 20:09если заказчик идиот то это не лечится
потому и существует согласование ТЗ что бы перед всеми работами получить полную картину и убедится что мы с клинтом на одной волне. если человеку сначала пофиг "ведь вы же специалисты, сделайте как правильно" то все правки уже потом по отдельному ТЗ с согласованием.
самое печальное что действительно есть клиенты которы пришили за "ведь вы же специалисты" но такие звери очень редкие и они всегда принимают мелкими кусками так как всегда в процессе приема появляются новые идеи/виденье для ТЗ следуюшего
Dhwtj
15.05.2026 20:09Как вы выжили вообще?
Вы же так со всеми заказчиками разругаетесь
Не по отдельному ТЗ, а в рамках того же контракта в рамках буфера на адаптацию, опытную эксплуатацию или как угодно, хотите назовите его ЧТЗ, ДТЗ, но бюджет превышать нельзя. Если вам нужны дополнительно деньги, а заказчик умеет только в годовой бюджет, то вы в тупике
gerbert_MX
15.05.2026 20:09вы говорите что-то из мира попила и госконтрактов
обычно есть задача которую нужно решить, а не бюджет который нужно освоить в рамках задачи
уже как раз таки из чернового ТЗ можно обсуждать бюджеты, сроки и на базе этой информации финализировать и вылизывать ТЗ.
feyd12
15.05.2026 20:09Как говаривал мой босс, потребитель этот такой, сам ТЗ не сможет составить, не технари. Придется вам помочь :)
3aky
15.05.2026 20:09Никто и не возражает - "сделать как надо", но если "надо" задним числом на 180 градусов разворачивается - за это заказчик должен платить, а не те, кто делает, логично?
Dhwtj
15.05.2026 20:09Должен платить.
Но это условно нормальное событие. И это должно быть предусмотрено заранее и желательно забюджетировано.
И исполнитель не должен бросить заказчика в таком состоянии, когда система по ТЗ сделана, но заказчик пользоваться ей не может потому что что-то на старте не предусмотрено.
Такой фигнёй (всё по ТЗ без гибкости) занимались ERP внедренцы, особенно sap. Рынок негативно отнёсся к таким внедрениям.
3aky
15.05.2026 20:09Я играл в бюджетированные задачи, и да - лучше всего они решаются через рамочные контракты, когда где-то перебор, где-то недобор, и разница по году учитывается предоплатой за следующий год - чтобы неосвоенного не оставалось, или уходит в допсоглашение с оплатой в следующем году - если перебор случился (это больно, но не так, как работа за бесплатно)
Dhwtj
15.05.2026 20:09В госах хуже всего:
44-ФЗ/223-ФЗ требуют фиксированного ТЗ и цены на старте, изменения почти невозможны
Годовой бюджет жёсткий, неосвоенное сгорает, перенос между статьями сложный
Конкурс выигрывает минимальная цена, потом подрядчик добирает через допсоглашения (обычно, джин уточнение ТЗ без изменения цены) и низкое качество
Обходы которые видел:
Дробление на мелкие контракты по этапам (формально разные закупки, но тут риск что контракт на второй этап ты не получишь)
НИР/ОКР как discovery (там допустима неопределённость результата)
Госкорпорации и ФГУПы как прослойка: они по 223-ФЗ гибче и могут создать субподряд
В целом гибкая разработка в госах работает либо через серые схемы, либо в структурах типа Минцифры/ДИТ Москвы, где (говорят) научились управлять рамочными контрактами. Системно проблема в госах не решена нигде.
atues
15.05.2026 20:09Нормальный текст. И по делу и со знанием дела. Плюсую.
Но вот что интересно: откуда столько минусов? Не похоже, чтобы их ставили те, кто оставил комментарии: последние вполне доброжелательны. Кому автор прищемил хвост?)))
AlexM2001
15.05.2026 20:09Не могу поставить плюс публикации.
Заблокирована возможность оценить эту статью.
Почему?
AndreyDmitriev
15.05.2026 20:09Может, вы израсходовали плюсомёт? Вроде там ничего не заблокировано. Попробуйте сейчас ещё раз, я вам патрон добавил...
AndreyDmitriev
Мне иногда приходится работать системным инженером, и в общем это основная задача - именно угадать мысли. Дело в том, что зачастую у заказчика есть лишь, скажем так, "ощущение" того, как должна работать программа, точнее программно-аппаратный комплекс. Он не профессионал в том, чтобы сформулировать, хотя очень старается, даже пытается интерфейсы и кнопочки изобразить. Задача профессионального системного инженера - облечь эти "ощущения" в форму строгих технических требований, причём реализуемых за разумное время (некоторые считают, что ИИ может всё, но нет). Это очень интересно на самом деле и большое искусство довести проект до финала, в котором выглядеть он будет совсем не так, как дилетантски представлял себе заказчик, но который скажет "да, это именно то, что мне нужно, ни больше не меньше", да ещё и уложившись в сроки. Я поначалу пытался всё переусложнять, но по итогу пришёл к "чем проще тем лучше", хотя бывает непросто облечь сложные вещи в простую форму. Ну и итеративность важна, начиная от грубого MVP надо двигаться к детальному конечному продукту, попутно борясь с менеджерами, которые хотят на стадии MVP остановиться.
А так программисты сходят с ума, конечно, можно Терри Дэвиса вспомнить или грустный эпилог в одной из книг, Макконнелла, кажется.
mate26
Это как раз не задача системного инженера и даже не системного аналитика, задача бизнес-аналитика.
У меня был случай, мы сделали приложение (десктопный клиент), которое большую часть вычислений делало на сервере, заказчик сказал что видел это "немного по другому". Переписали на вычисления на стороне клиента и откидывание метрик в бэк. Снова не то... Привлекли бизнес-аналитика и после его вопроса "мы делаем приложение, что бы что?" разработка остановилась, потому что заказчик так и не смог дать внятный ответ
AndreyDmitriev
В принципе да, но это немножко от индустрии зависит, у нас софт — это лишь часть сложной промышленной системы, и они бывают "универсальные" под многих заказчиков, либо "кастомизированные" под конкретного. В основном бизнес-аналитик составляет маркетинговую функциональную спецификацию под "универсальные" продуктовые линии, которой потом следует системный инженер, а вот если это система заточена под конкретного заказчика, то тут как раз системный включается почти сразу, а бизнес аналитик лишь "посматривает через плечо", как некоторые части сделать по возможности "универсальными", этакий "задел на будущее", ну и очень часто такие системы обкладываются NDA (на какой-то срок) и патентами, потому что заказчик не хочет, чтобы конкуренты получили что-то похожее, так что их выкатывать на общий рынок какое-то время не получится (либо вообще никогда). Но кастомизированные, созданные в нескольких экземплярах, системы сильно интереснее универсальных, потому что бизнес практически не ограничивает инженерный полёт мысли, причём со стороны заказчика тоже, так что у него куча "хотелок", и он в общем имеет на них право, потому что за такую разработку он платит охрененные деньги (речь о семизначных суммах, и отнюдь не рублей).