В одном из недавних интервью CEO веб-студии сказал: «Наши разработчики должны просто писать код. Общение с клиентом — задача менеджеров». Звучит разумно? Да. Работает? Нет. И вот почему.

Ошибка 1: Менеджер как переводчик

Когда между заказчиком и разработчиком стоит посредник, каждый перевод теряет 30% смысла. Заказчик говорит «нам нужен современный сайт». Менеджер переводит как «лонгрид с анимациями». Разработчик делает лонгрид с анимациями. Заказчик получает красивую, но неработающую конструкцию и говорит: «Это не то». Кто виноват? Все по очереди.

Проблема в том, что менеджер — не инженер. Он не может оценить технические риски при каждой хотелке. И разработчик — не продавец. Он не умеет объяснить, почему «простая правка» займёт три дня.

Ошибка 2: Оценка без контекста

Разработчик оценивает задачу в 8 часов. Менеджер говорит заказчику «два дня». Заказчик не понимает, почему «два дня» превращаются в неделю. Потому что между оценкой и дедлайном — ревью, правки, тестирование, интеграция, правки по правкам.

Клиент видит конечную цифру. Разработчик знает реальный объём. Менеджер пытается продать «два дня» и нести ответственность за срыв дедлайна.

Решение: смотреть на задачу вместе. Не посредник переводит — заказчик и разработчик садятся за один стол. Даже если это созвон на 20 минут раз в неделю.

Ошибка 3: Разработчик как исполнитель, а не партнёр

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

Когда разработчику запрещают говорить с клиентом, бизнес теряет экспертизу. Клиент получает то, что менеджер понял. Не то, что нужно.

Что с этим делать

Несколько практик, которые реально работают:

  • Прямой канал «разработчик — заказчик» для технических вопросов, хотя бы раз в неделю
  • Совместная приёмка: заказчик и разработчик тестируют результат вместе, не через менеджера
  • Оценка в диапазоне: не «5 дней», а «3–7 дней» с объяснением переменных
  • Приоритизация — вместе: что делаем сейчас, что потом, почему

Когда я работала с веб-студией, самые успешные проекты были там, где заказчик мог написать разработчику напрямую. Не чтобы контролировать, а чтобы понимать. Это сокращает правки в три раза.