Три месяца на одну кнопку: почему бизнес и разработка по-разному оценивают сроки
Бизнес просит добавить в личный кабинет одну кнопку и рассчитывает увидеть ее через неделю, но разработка оценивает задачу в три месяца. Для заказчика такой срок выглядит абсурдным: кнопка маленькая, а действие понятное. Техническая команда в ответ перечисляет API, интеграции и архитектурные ограничения — и только укрепляет подозрение в раздутых сроках. Знакомая ситуация? На деле спор обычно возникает не потому, что бизнес ничего не понимает, а разработчики не хотят работать быстрее: просто стороны по-разному представляют объем задачи. Разберемся, как увидеть реальный объем работы и договориться о сроках на понятном всем языке.
По ту сторону интерфейса
Представим, что интернет-магазин хочет добавить в личный кабинет возможность отменить заказ. Кажется, что достаточно вывести элемент на экран, настроить действие по нажатию и показать подтверждение.
Но сама кнопка — лишь последний шаг. Системе нужно проверить статус заказа и понять, можно ли его еще отменить. Затем остановить сборку на складе, вернуть деньги, восстановить остатки, пересчитать бонусы и отправить уведомление покупателю. Если товар уже передали в доставку, появляется другой сценарий. Если заказ оплачен частично бонусами или собран из товаров нескольких продавцов — еще несколько.
Бизнес смотрит на функцию снаружи и оценивает ее по видимой части — разработка же видит цепочку систем, которые должны правильно отреагировать на нажатие. Поэтому одна сторона обсуждает кнопку, а другая — изменение всего процесса обработки заказа. В этом нет ничьей вины: бизнес не обязан знать внутреннее устройство продукта. Но если техническая сложность не видна, объяснить ее — ответственность команды разработки.
Что значит «готово»
Расхождение часто начинается еще до оценки. Когда заказчик говорит «добавить кнопку», он имеет в виду работающий элемент на экране. Для разработчика готовая функция должна пройти ревью и тестирование, корректно обрабатывать ошибки, учитывать права доступа, быть связанной с другими системами и безопасно выпущенной в продакшен.
Особенно это заметно на демонстрациях: прототип можно собрать за несколько дней, и заказчик закономерно спрашивает, почему его нельзя сразу показать пользователям. Но между демонстрационной версией и полноценным запуском остаются обработка исключений, права доступа, нагрузочное тестирование, безопасность, аналитика и возможность отката.
Поэтому разговор о сроках лучше начинать не с недель, а с результата. Нужен прототип для проверки идеи, минимальная версия для небольшой группы клиентов или полноценный запуск? Все три варианта могут выглядеть почти одинаково, но потребуют разного объема работы.
Очередь для задачи
Еще одна частая ошибка — воспринимать оценку как количество рабочих дней программиста. Если задача требует десять дней чистой разработки, бизнесу закономерно кажется, что через две недели она должна появиться в продукте.
Но в реальности задача может «зависать» на разных этапах: в ожидании дизайна, ревью, уточнения требований или свободного тестировщика. Кроме того, команда работает не над одной функцией: параллельно она исправляет ошибки, поддерживает действующий продукт и выпускает другие изменения — и здесь уже начинается вопрос приоритетов.
Конечно, это не универсальное оправдание долгих сроков. Если небольшие изменения регулярно проводят месяцы в очередях, проблема, скорее всего, в самом устройстве процессов. Но для максимально точного понимания времени важно разделять трудоемкость и календарный срок: сколько времени займет сама работа и сколько задача проведет в ожидании.
Как обсуждать сроки без технического жаргона
Когда разработчик объясняет срок словами «нужно переделать API, добавить асинхронную обработку и обновить схему данных», бизнес слышит набор технических подробностей, которые невозможно проверить. В итоге даже обоснованная оценка начинает выглядеть как предложение просто довериться специалистам, а отсюда — подозрение, что разработчики просто ленятся.
Гораздо полезнее строить объяснение через последствия для продукта. Не «нужно изменить архитектуру авторизации», а «сейчас система не различает права сотрудников, поэтому без доработки любой менеджер сможет выполнить действие от имени администратора». Не «интеграция работает синхронно», а «если платежный сервис не ответит, пользователь увидит отмену, но не получит деньги».
При этом техническая команда тоже может быть не права. Иногда разработчики закладывают идеальную архитектуру там, где достаточно временного решения, учитывают маловероятные сценарии или пытаются заодно исправить старые проблемы системы. Поэтому полезно разделять обязательную работу, без которой функция небезопасна или бесполезна, и улучшения, которые вполне можно перенести на потом. Это позволяет обсуждать не один универсальный дедлайн, а несколько вариантов запуска: например, за неделю запустить базовый сценарий, за две — расширенный, а за месяц добавить редкие случаи. Так вместо попытки выяснить, почему задача занимает столько времени, заказчик выбирает соотношение скорости, функциональности и риска.
Наконец, оценка должна содержать условия. Срок реалистичен, если требования не меняются, смежная команда вовремя обеспечивает интеграцию, а задача сохраняет приоритет. Если одно из условий исчезает, дату нужно пересмотреть — это не провал разработчиков, а нормальная реакция на изменения.
Основная причина разного представления о сроках — в том, что обе стороны по-своему видят процессы. И важно, чтобы бизнес понимал не устройство кода, а стоимость ускорения и связанные с этим риски, а разработка могла объяснить тайминг через пользовательские сценарии и последствия для продукта. Оптимальный срок получается не тогда, когда одна сторона продавила другую, а когда обе понимают, что именно будет сделано, от чего зависит дедлайн и чем придется пожертвовать ради более быстрого запуска.
