📄 Статьи

Боль разработчиков: почему они ненавидят ваше ТЗ

Мы много говорили о боли бизнеса. О том, как тяжело заказывать разработку, как страшно трогать легаси, как дорого нанимать архитектора.

Но есть и другая сторона. Есть люди, которые пишут код. И у них тоже есть боль.

Давайте посмотрим на разработку глазами разработчиков.

1. «Сделайте красиво, чтобы работало»

Это самое страшное, что может услышать разработчик.

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

Итог: он делает «как-то». Вы говорите «не то». Он переделывает. Вы говорите «не то». Он переделывает снова.

Разработчик ненавидит такие задачи. Потому что он не может сделать хорошо. Он может только угадывать.

Был у меня случай, который я запомнил надолго.

Заказчик попросил сделать сайт для элитного алкоголя. Я задаю самый простой вопрос: «Какой ты хочешь сайт?». В ответ слышу: «Хороший».

Я пытаюсь уточнить: стиль, цвета, настроение. Бесполезно. «Хороший» — и точка. Фото он обещал подобрать сам, потому что «у него есть человек, который понимает».

Через неделю он присылает фотографии. И там, на главном баннере, в разделе «Обязательно попробуйте», лежит девушка. На барной стойке. В весьма откровенном виде, учитывая не очень скромный разрез на платье.

Сайт про элитный алкоголь. Баннер с девушкой, которая явно не модель из каталога. Красиво ли это? Для него — да. Для меня это не понятное и не логичное решение — хозяин-барин, как говорится, но...

Я ничего не мог сделать. Потому что «красиво» — это субъективно. И когда заказчик выбирает фото сам, без чёткого ТЗ, границы «красиво» размываются до полной потери смысла.

Итог: я переделывал макет три раза. Каждый раз — «не то». Каждый раз — «сделайте лучше». А «лучше» — это угадай, что у него в голове.

Я больше так не работаю. Теперь я говорю: «Красиво — это не критерий. Давайте опишем, что должно быть на странице».

2. «Ну, вы же понимаете, что я имею в виду»

Нет, не понимает.

Разработчик не знает ваш бизнес. Он не знает, как устроены ваши процессы. Он не знает, что вы подразумеваете под «обычная форма».

Когда вы говорите «ну вы же понимаете» — вы перекладываете на него ответственность за то, чего вы не сказали.

Он начинает додумывать. Он ошибается. Вы недовольны. Он переделывает.

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

А теперь самый опасный аргумент, который я слышу от заказчиков: «Он работает у нас уже год и всё прекрасно понимает».

Это иллюзия.

Разработчик видит ваш бизнес не так, как вы думаете. Он живёт в другой реальности. Звучит глупо, но это именно так.

Вы видите процесс: «Мы выставили счёт контрагенту, он оплатил, всё отлично».

А разработчик видит строку в таблице «счета», связанную по индексу со строкой в таблице «контрагенты». Оплата для него — это заполненное поле «дата_оплаты» в этой строке.

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

Назовите это профессиональной деформацией — видеть мир не как физический процесс, а как связи в цифровом мире.

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

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

Он не понимает, что «красиво» для вас — это не «быстро и правильно». Он живёт в мире, где «красиво» — это когда запрос выполняется за 50 миллисекунд, а не за 500.

Вы просите его «понять» ваш бизнес. А он вас — понять, что его мир — это не ваш мир.

Вы говорите «контрагент» — он видит foreign_key.

Вы говорите «оплата» — он видит payment_date и payment_status.

Вы говорите «отчёт по продажам» — он видит SELECT SUM(amount) FROM orders WHERE status = 'paid' GROUP BY manager_id.

Он не делает это назло. Просто его мозг устроен иначе. И если вы не опишете ему задачу его языком, он будет делать так, как понял. А вы будете злиться, что «он же должен понимать».

Не должен. Он не экстрасенс. И у него нет доступа к вашей картине мира.

Я больше не говорю разработчикам «ну вы же понимаете». Я описываю задачи так, чтобы у него не было шанса что-то не понять.

3. «Это же маленькая правка, сделайте за час»

О, это классика.

Маленькая правка на словах — это всегда 2–3 дня работы. Потому что «добавить одно поле» — это:

Изменить структуру БД.
Переписать запросы.
Обновить формы.
Исправить отчёты.
Проверить, ничего не сломалось.

А если там ещё и интеграция с 1С, то «маленькая правка» превращается в неделю ада.

Итог: разработчик чувствует, что его время обесценивают. И злится.

Самая большая проблема заказчика, который без ТЗ напрямую говорит разработчику «добавь кнопку — это не долго», — это естественное непонимание того, что такое сайт.

Сравнить это можно с айсбергом.

То, что вы называете сайтом, — это крошечная вершина, видимая над водой. А на самом деле сайт — это как раз та глыба, которая находится под поверхностью. И её вы не видите.

Приведу наглядный пример.

Обычный сайт на 6 страниц, включающий каталог товаров и формирующий заказ на почту. Никаких сложных интеграций, никаких личных кабинетов, никаких «умных» фич. Просто: нажали на «Заказать» → заполнили форму → заказ ушёл на email пользователя.

Сколько файлов в этом проекте?

6? 12? 18?

Не угадали.

Если написано правильно, с архитектурой, с разделением логики, с продуманной структурой — это 30–50+ файлов.

А если программист написал всё в одном файле (так, к слову, тоже реально — я лично видел такой проект, где файл был более 60 тысяч строк!), стоит задуматься, кто он и каков его опыт.

Контроллеры. Модели. Виды. Маршруты. Миграции. Конфиги. Хелперы. Сервисы. А если ещё и тесты — смело добавляйте ещё 20.

А теперь представьте, что разработчик слышит: «Добавь кнопку — это же просто».

Он знает, что эта кнопка — не просто кнопка. Это:

Создание новой записи в БД.
Привязка к конкретному товару.
Проверка прав доступа.
Отправка уведомления.
Обновление статуса заказа.
Логирование события.
Обработка ошибок.

И всё это нужно сделать так, чтобы не сломать остальные 50 файлов.

«Добавь кнопку» — это просто для вас, потому что вы видите только верхушку айсберга. Для разработчика это работа с тем, что под водой.

И когда вы говорите «сделайте за час», он знает, что это невозможно. Но он не может объяснить вам это за минуту. Потому что для этого нужно показать вам весь айсберг. А на это нет времени.

Поэтому он просто делает. Спешно. Кое-как. И получает «быструю» кнопку, которая через три месяца сломает весь проект. Потому что её проектировали не как часть системы, а как «быструю правку».

Я больше не говорю разработчикам «добавь кнопку». Я говорю: «Нам нужно, чтобы пользователь мог сделать действие X. Давайте спроектируем это как часть системы».

4. «Сделайте, как у конкурентов»

Это не задача. Это ссылка на чужой сайт.

Разработчик не знает, какая именно часть сайта конкурентов вам нужна. Дизайн? Функционал? Логика работы? Скорость?

И как только он сделает «как у конкурентов», вы скажете: «Нет, не так. У них по-другому».

Итог: разработчик начинает ненавидеть конкурентов и вашу фразу.

Есть вообще такое направление бизнеса — «конъюнктурщики». Смотрим, что у кого-то зашло, и пытаемся скопировать.

Отлично! Только давайте вернёмся к пункту выше и аллегории с айсбергом.

Что мы можем сделать для копирования? Мы можем скопировать чужой сайт. «Верхушка чужого айсберга» может быть перенесена к вам на сервер. Не поверите — за час!

Заходим на сервер.
Одной командой говорим скопировать всё и указываем web-адрес конкурентов.
Переходим в папку со скачанным кодом и меняем по всем файлам ссылки на новый домен.

Здорово? Быстро? Конечно!

Но дальше разработчик должен самостоятельно построить весь айсберг «под водой». И вот тут начинается самое печальное — нужно понимать бизнес, а бизнес разработчику не понятен.

У меня был опыт работы с таким направлением. В том бизнесе люди платили за участие, участвовали, выбирали победителя, победитель получал приз. Я понимал эту механику, но это не было ТЗ. Это был ад, который надо было придумывать и додумывать так, чтобы когда я услышу в очередной раз от директора «это не то, что я думал», умудриться быстро поменять логику.

И вот сидишь, смотришь на чужой сайт — и видишь только верхушку. А как там устроено под водой — никто не знает. Там может быть костыль на костыле, который держится на честном слове и молитвах. Но ты это копируешь, потому что «у них работает».

А через месяц выясняется, что у них тоже не работает. Просто они научились с этим жить.

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

Теперь я говорю: «Давайте не будем смотреть на конкурентов. Давайте поймём, что нужно вам».

5. «Документация? А зачем?»

Разработчик, который пишет код без документации, закладывает мину под ваш бизнес.

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

Но разработчики не пишут документацию по двум причинам:

Нет времени. Заказчик требует результат, а не «бумажки».
Нет ТЗ. Если вы не дали им чёткого описания, они не знают, что документировать.

Итог: разработчик знает, что документация нужна. Но он не может её сделать, потому что у него нет времени и нет основы.

Но самое интересное — что наиболее ответственные разработчики всё же пытаются оставить «наскальные надписи» для потомков. Как? Всё просто — комментарии в коде.

Времени нет. Проектировать некогда. Документация требует времени. А время расписано на решение горящих проблем здесь и сейчас.

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

Но вернёмся к ответственным авторам наскальной живописи. Единственный вариант документирования — комментарии в самом коде.

Я никогда не понимал избыточности комментариев к слову. Но шедевры были.

Самым запоминающимся, пожалуй, стал:

«Костыль в этой строке не трогать, иначе сломается костыль в строке 10547»

Что такое «костыль»? На профессиональном жаргоне — это добавление в код чего-то по принципу «лишь бы работало сейчас». Быстрое решение, которое закрывает проблему здесь и сейчас, но создаёт долгосрочную проблему завтра.

Вдумайтесь: все знают о костылях и ставят их так, чтобы не сломались костыли, поставленные кем-то когда-то и зачем-то. Никто не помнит, кто, когда и зачем.

И это не потому, что разработчики плохие. Это потому, что система проектировалась не как система. Она проектировалась как «закрыть задачу».

Каждый новый разработчик, приходя в проект, начинает разбираться с этим наследием. Он видит комментарий «не трогать». Он понимает, что если тронет — всё рухнет. Поэтому он добавляет свой костыль. И оставляет свой комментарий. Для следующего.

Это бесконечный цикл.

Так рождается легаси. Не от плохого кода. От отсутствия времени на проектирование. От «сделайте быстро». От «потом переделаем».

«Нет ничего более постоянного, чем временное». Это про 90% кодовой базы у компаний.

Потом не наступает никогда. Потому что завтра будет новая «срочная задача».