The post has been translated automatically. Original language: Russian
Requesting an unrealistic deadline is one of the most frequent points of tension between the customer and the development team. A formal refusal ("it's impossible") destroys trust and looks like an unwillingness to find a solution. Formal agreement ("okay, let's try") creates expectations that the team will not be able to fulfill, and moves the conflict to a later and more painful stage of the project. The "working" answer is not between these two extremes, but outside of them: it does not deny the urgency of the customer and does not agree with an unrealistic assessment, but changes the subject of the conversation from the question "will we meet the deadline in a week" to the question "what exactly can we get in a week".
What does a working dialogue sound like?
When a customer formulates a request as a deadline — "we need an MVP in a week" — this wording is almost always based not on an accurate estimate of the amount of work, but on the urgency of a business reason: for example, an upcoming meeting with an investor or a competitive launch. The answer starting with "it's unrealistic in a week" argues with the deadline, although the actual problem is not the deadline itself, but the uncertainty of the amount of functionality within it.
A more efficient reaction is to move the conversation to the prioritization plane: "in a week, we can show a demonstration of a key usage scenario — without authorization, without error handling, on test data. Will this close the task for the investor meeting?". Such a response does not negate the deadline, but clarifies exactly what is possible within it, and at the same time returns to the customer a decision on priorities — which part of the functionality is really necessary for a specific purpose, and which was included in the request by inertia.
If the customer insists on full functionality within the initial deadline, it is useful to explicitly state a compromise in terms of consequences, rather than in terms of rejection: "the full version with authorization and error handling will take three weeks; the demo version without this is real in a week." Phrasing it through concrete options, rather than an abstract "it's harder than it looks," leaves the decision up to the customer and removes the role of the party that refuses from the team.
What makes up this answer?
The basis of a working response is a three—element sequence applicable to almost any similar query. First, there is the recognition of the real reason for the urgency, rather than arguing with the fact of the deadline itself: if the customer has a deadline on his part, it is worth finding out first of all, since it depends on which compromise it makes sense to offer at all. Then there is the specification of what actually fits within the stated deadline, preferably in terms that can be demonstrated, rather than abstract percentages of readiness. And finally, an explicit designation of what remains beyond this period, indicating the actual cost of adding this part later.
A conversation built in this sequence relieves the main stress of such requests: the customer receives not a refusal or an unfulfilled promise, but a specific choice between options with an understandable price for each. It is the lack of choice — and not the very fact of a short deadline — that usually generates conflict around such requests.
Запрос на нереалистичный срок — одна из наиболее частых точек напряжения между заказчиком и командой разработки. Формальный отказ («это невозможно») разрушает доверие и выглядит как нежелание искать решение. Формальное согласие («хорошо, попробуем») создает ожидания, которые команда не сможет выполнить, и переносит конфликт на более поздний и более болезненный этап проекта. Работающий ответ находится не между этими двумя крайностями, а вне их: он не отрицает срочность заказчика и не соглашается с нереалистичной оценкой, а меняет предмет разговора — с вопроса «уложимся ли мы в неделю» на вопрос «что именно можно получить за неделю».
Как звучит рабочий диалог
Когда заказчик формулирует запрос как срок — «нам нужен MVP за неделю», — за этой формулировкой почти всегда стоит не точная оценка объема работ, а срочность бизнес-повода: например, приближающаяся встреча с инвестором или конкурентный запуск. Ответ, начинающийся с «за неделю это нереально», спорит со сроком, хотя фактическая проблема — не срок сам по себе, а неопределённость объёма функциональности внутри него.
Более рабочая реакция — перевести разговор в плоскость приоритизации: «за неделю мы можем показать демонстрацию ключевого сценария использования — без авторизации, без обработки ошибок, на тестовых данных. Это закроет задачу для встречи с инвестором?». Такой ответ не отрицает срок, а уточняет, что именно возможно внутри него, и одновременно возвращает заказчику решение о приоритетах — какая часть функциональности действительно необходима для конкретной цели, а какая была включена в запрос по инерции.
Если заказчик настаивает на полной функциональности в исходный срок, полезно явно проговорить компромисс в терминах последствий, а не в терминах отказа: «полная версия с авторизацией и обработкой ошибок потребует трёх недель; версия для демонстрации без этого — реальна за неделю». Формулировка через конкретные варианты, а не абстрактное «это сложнее, чем кажется», оставляет решение за заказчиком и снимает с команды роль стороны, которая отказывает.
Из чего складывается такой ответ
Основа рабочего ответа — это последовательность из трех элементов, применимая почти к любому подобному запросу. Сначала — признание реальной причины срочности, а не спор с самим фактом срока: если у заказчика есть дедлайн со своей стороны, это стоит выяснить в первую очередь, поскольку от него зависит, какой компромисс вообще имеет смысл предлагать. Затем — конкретизация того, что реально помещается в заявленный срок, желательно в формулировках, которые можно продемонстрировать, а не абстрактных процентах готовности. И наконец — явное обозначение того, что остаётся за пределами этого срока, с обозначением реальной стоимости добавления этой части позже.
Разговор, построенный в такой последовательности, снимает основное напряжение подобных запросов: заказчик получает не отказ и не невыполнимое обещание, а конкретный выбор между вариантами с понятной ценой каждого. Именно отсутствие выбора — а не сам факт сжатого срока — обычно и порождает конфликт вокруг подобных запросов.
Share
