Когда человеку говорят:
“Сделайте кнопку”
он представляет себе:
обработчик клика
форму
пару строчек кода
Когда это слышит программист — он напрягается.
Потому что за словом “кнопка” часто скрывается:
изменение бизнес-процесса
отчёты
согласования
десятилетнее легаси
и фраза “раньше в DOS было удобнее”
Со временем начинаешь понимать:
Программирование — это не написание кода.
Это перевод человеческого хаоса на язык, который понимает компьютер.
И вот именно от этого иногда хочется выйти в лес и кричать.
“Сделайте что-нибудь. Мы сами пока не знаем что”
Есть один тип задач, после которого программисты начинают смотреть в стену чуть дольше обычного.
Звучит он примерно так:
“Сделайте нам систему.”
“Какую?”
“Ну… хорошую.”
Или:
“У нас биг дата. Разберитесь там как-нибудь.”
Я работал в фирмах, где постановка задачи выглядела именно так.
Без ТЗ.
Без описания процессов.
Без понимания, что вообще нужно получить на выходе.
А дальше начинается классика:
сделал
показал
“ой, мы имели в виду другое”
переделал
“ну почти”
ещё переделал
И так до бесконечности.
Что происходит на самом деле
Когда требований нет — программист начинает работать:
аналитиком
архитектором
разработчиком
тестировщиком
и иногда психотерапевтом для заказчика
Бесплатно.
Вывод, который приходит с опытом
Если на вопрос:
“Что именно нужно сделать?”
вам отвечают:
“Ну вы же специалист”
— это уже не разработка.
Это попытка угадать чужие мысли за свои деньги и своё время.
“Да что там делать? Просто перенесите”
Это вообще отдельный жанр.
Однажды пришлось переносить несколько старых отчётных систем:
сметы
бухгалтерию
проходческие отчёты
Документации — нет.
API — нет.
Описание логики — отсутствует.
Фактически вся работа превратилась в археологию.
Сидишь и пытаешься понять:
откуда берутся данные
почему цифры не сходятся
зачем тут вообще этот кусок кода
и кто решил хранить бизнес-логику внутри SQL-процедур размером с роман
Причём часть системы вообще работала по принципу:
“Не трогай. Оно как-то живёт.”
А со стороны это выглядело так:
“Ну вы же просто переносите данные.”
Нет.
“Просто перенос” в enterprise-разработке обычно означает:
реверс-инжиниринг
восстановление логики
переписывание поведения системы
и попытку не сломать то, о чём уже никто не помнит
Руководство — не пользователь
Это одна из самых дорогих ошибок в разработке.
Руководство почти всегда говорит одно.
Пользователь — совершенно другое.
История с почтамптом
Когда-то нужно было сделать систему приёма коммунальных платежей:
свет
газ
вода
Начальство рассказывало про:
отчёты
контроль
статистику
Я даже не стал долго их слушать.
Пошёл к операторам.
Девочки сидели и вручную перебивали квитанции в Excel.
Сотнями. Каждый день.
Я сел рядом и просто начал смотреть.
И внезапно выяснилось:
стандартная навигация через Tab им неудобна.
Почему?
Потому что правая рука всё время лежит на цифровом блоке клавиатуры.
Им удобнее Enter.
Казалось бы — мелочь.
Но после изменения навигации скорость работы выросла в разы.
Те же люди начали обрабатывать:
200
300
иногда ещё больше квитанций в день
Без истерик и переработок.
Вот это и есть реальная аналитика.
Не UML-диаграммы.
Не “бизнес-требования”.
А наблюдение за человеком, который работает с системой 8 часов в день.
Пользователь не хочет жить в вашей идеальной архитектуре
Программисты любят порядок.
Справочники.
Категории.
Структуры.
Идеальные модели данных.
А потом приходит продавец в компьютерном магазине.
У него очередь.
Покупатель стоит над душой.
И ему абсолютно всё равно, насколько красива ваша архитектура.
Реальная проблема
Разработчик думает:
“Сначала создадим справочник устройств.”
Продавец думает:
“Мне надо быстро продать товар.”
Если нужной марки нет — он не пойдёт в админку.
Он просто:
введёт текст руками
сломает формат
обойдёт систему
Потому что его задача — работать.
А не поддерживать чистоту вашей БД.
После одного такого наблюдения я вообще переделал логику:
если категории нет — она создаётся прямо во время ввода.
И внезапно оказалось:
пользователи начинают работать с системой нормально, когда система не мешает им жить.
“Сделайте как в DOS”
Есть особый вид инженерного ужаса.
Это когда старый интерфейс живёт в памяти человека лучше, чем современный UI.
Однажды я делал систему для бюро переводов.
Сначала:
расчёт стоимости
потом сайт
потом кабинеты
потом автоматизация процессов
Всё нормально.
А потом руководство сказало:
“Теперь сделайте отчёты.”
Сделал.
И тут началось.
Директор привык к DOS-программам.
Ему хотелось:
плюс — перейти глубже
минус — выйти назад
стрелками листать периоды
и чтобы всё было “как раньше”
Только это уже веб.
HTML.
Браузер.
Совсем другая модель интерфейса.
Но объяснить это невозможно.
Следующие месяцы превратились в бесконечное:
“сдвиньте колонку”
“верните как было”
“кнопочку чуть левее”
“а в DOS было удобнее”
И вот в такие моменты начинаешь понимать:
иногда ты переносишь не систему.
Ты переносишь привычки.
Самый тихий вид провала
Это когда система работает идеально…
но оказывается никому не нужна.
Однажды меня взяли тимлидом на проект биржевой системы.
Полгода работы:
личные кабинеты
торги
распределённая архитектура
защита
репликации
резервирование
Система реально получилась хорошей.
А потом ушёл менеджер проекта.
И сверху прилетело:
“Ну… пока замораживаем.”
Всё.
И это очень важный момент, который редко понимают молодые разработчики:
В разработке бывает не только:
“плохо сделали”
Бывает ещё:
“хорошо сделали, но бизнесу это сейчас не нужно”
Почему программисты всё-таки не сходят с ума
Хотя… иногда сходят.
Но со временем появляются простые правила выживания.
1. Идите к пользователю
Не к начальству.
Не к презентациям.
А к человеку, который реально работает в системе.
2. Наблюдайте до того, как писать код
Иногда один день рядом с пользователем экономит месяц разработки.
3. Задавайте глупые вопросы
Почему Enter?
Почему Excel?
Почему они делают именно так?
Очень часто настоящая логика процесса скрыта именно там.
4. Делайте итерациями
Первая версия почти всегда неправильная.
И это нормально.
5. Если проект мёртв — уходите
Не тратьте годы жизни на систему, которую:
никто не внедрит
никто не поддержит
и которая нужна только в презентации для начальства
Итог
Программирование — это не код.
Это попытка превратить:
хаос
привычки
страхи
бизнес-процессы
и человеческие ожидания
в систему, которая должна работать стабильно.
И чем дольше работаешь — тем сильнее понимаешь:
Хороший инженер отличается не количеством фреймворков в резюме.
А способностью не потерять здравый смысл посреди всего этого хаоса.