Не бывает «плохих разработчиков»
Коротко: в 8 из 10 проектов проблема не в «руках программистов», а в отсутствии понятной цели, ТЗ и критериев приёмки. Разработчики делают то, что попросили. Бизнес получает не то, что ожидал. Ниже — как разорвать этот круг и я расскажу об этом подробнее.
Быстрый разбор причин
| Симптом | Истинная причина | Что делать |
|---|---|---|
| «Делают не то» | Нет цели и бизнес-метрики | Сформулировать цель и KPI: CR, AOV, скорость, SLA |
| «Сроки поплыли» | Плавающий объём, нет приоритизации | ТЗ с приоритетами, заморозка объёма на спринт |
| «Костыли и баги» | Не описаны сценарии и критерии приёмки | User stories + acceptance criteria + Definition of Done |
| «Красиво, но не продаёт» | Задача была про дизайн, не про конверсию | Страховка метриками: до/после, план экспериментов |
| «Никто не отвечает» | Нет владельца задачи | Назначить owner’а, RACI, ритм синков и демо |
Почему разработчики «виноваты» по умолчанию
Разработчик — исполнитель требований. Если требований нет, он вынужден догадаться.
Когда ожидания не совпали с догадками, рождается миф про «плохих разработчиков». Это удобно, но бесполезно. Проблема системная:
- Не определили зачем делаем.
- Не договорились, что считается готовым.
- Не зафиксировали, как измерим результат.
- Не расставили приоритеты и не защищали спринт от «маленьких срочных правок».
- Не назначили владельца решения.
Команда не может угадать бизнес-логику. Она может реализовать её, если логика оформлена.
Что нужно командами разработки на входе
1) Цель и метрика
Формула простая: цель → гипотеза → метрика → дедлайн проверки.
Примеры целей:
- «Увеличить CR листинга +5–7% за 6 недель».
- «Сократить отказ на шаге оплаты −20% за 1 спринт».
- «Снизить TTFB до 300 мс на 90% трафика».
2) ТЗ и сценарии
Коротко, по делу:
- User story: кто, что хочет и почему.
- Acceptance criteria: что проверяем, чтобы считать задачу выполненной.
- Не-функциональные требования: скорость, адаптивность, доступность, логирование.
- Интеграции: куда и что пишем (CRM/ERP/BI), форматы, поля, webhooks.
- Макеты/схемы: только то, что влияет на результат.
3) Правила игры
- Definition of Ready: когда задача готова в разработку.
- Definition of Done: когда готово к релизу.
- Заморозка объёма в спринте.
- Change-log: всё, что меняет объём, фиксируем отдельно.
- Демо/ретро: показать, измерить, решить, что дальше.
Где чаще всего ломается коммуникация
- «Сделайте красиво». Красиво — не цель. Цель — скорость выбора, кликабельность CTA, CR.
- «Нам срочно». Срочно — без приоритета и метрики = минус к качеству и плюс к техдолгу.
- «Давайте параллельно». Без владельца и общей схемы интеграций параллельность превращается в гонку конфликтов.
- «Потом допилим аналитику». Потом — значит никогда. Без данных невозможно доказать пользу.
- «У нас особенный кейс». Особенность без формализации = хаос. Любая уникальность описываема.
Модель «честного договора» между бизнесом и разработкой
1. Совместный бриф (30–60 минут).
Контекст, цель, риски, ограничения, метрики, сроки проверки гипотезы.
2. Короткое ТЗ (до 10 страниц).
User stories, критерии приёмки, макеты ключевых состояний, схемы интеграций, требования к данным и логированию.
3. План релиза.
Разбивка на инкременты, что покажем на первом демо, что пойдёт во второй итерации.
4. Контроль качества.
Чек-лист тестов, UAT, готовность аналитики, кто и где подписывает «готово».
5. Измерение эффекта.
Дашборд «до/после», флаг эксперимента, окно наблюдения, решение «масштабируем / перерабатываем / откатываем».
Что делать, если уже «всё плохо»
- Стоп-кадр. Фиксируем текущие задачи, замораживаем новые.
- Диагностика. 1–2 дня на карту проблем: техника, UX, SEO, аналитика, процессы.
- Re-scope. Убираем лишнее, оставляем 3–5 задач с максимальным влиянием на метрику.
- Быстрые победы. Даем результат за 2–3 недели, возвращаем доверие.
- Новый ритм. Вводим DoR/DoD, демо, ретро, change-log и ответственность владельцев.
Как я помогаю как аудитор и автор ТЗ
Я работаю на стыке бизнеса и разработки. Моя задача — снять туман вокруг целей, записать их понятным для команды языком и обеспечить предсказуемость результата.
Что делаю в проектах:
- провожу аудит сайта, данных и процессов;
- формирую приоритезированное ТЗ с критериями приёмки и оценкой эффекта;
- подбираю специалистов под конкретные задачи и координирую внедрение;
- выстраиваю ритм: демо, замер, корректировка;
- оставляю работающую систему, а не «папку с отчётами».
Так выигрывают все: бизнес получает результат, разработчики — понятные задачи и уважение к своей работе.
Вывод
Большинству проектов нужны не «другие программисты», а другой способ постановки задач.
Когда есть цель, ТЗ, критерии приёмки и измерение эффекта — разработчики делают отличные продукты.
Если хотите проверить эту модель на своём проекте — начнём с короткой диагностики и понятного плана из 10 шагов.
