The post has been translated automatically. Original language: Russian
One project was on the verge of failure. The team was preparing to work overtime for two weeks in order to release the next feature. It seemed the only option left was to accelerate and put the squeeze on.
But at the next meeting, the team leader asked a simple question.:
"Why do we need this feature at all?"
The customer thought about it. It soon became clear that the feature for which the team was going to storm the deadline had no effect on the purpose of the release. Once it was simply added to the list of requirements, and since then no one has asked if it is really still needed.
It wasn't a change in methodology or a heroic leap by the developers on the last night that saved the project. He was saved by an inconvenient question asked in time.
The industry likes to argue about which works better: Scrum or Kanban, Waterfall or Agile. But in practice, the timing and budget of a project often depend on something else: whether the team can report a problem on time, ask an inconvenient question, identify a risk, or stop a questionable decision.
Here are three situations familiar to almost any team.
1. Bad news is postponed until the last
On the second day of the sprint, the developer realizes that the estimate was too optimistic. But I don't want to talk about it: what if I catch up? What if the team can handle it? And it's embarrassing to admit to a mistake.
The problem remains inside until the demo. And then it turns out that it's too late and expensive to redo.
What could have been discussed calmly on the third day turns into an emergency on the last.
2. It's easier to agree than to clarify
The customer says, "Do it like the competition."
The manager nods, and the task is sent to the backlog. Although there are actually dozens of questions: what exactly needs to be repeated? Why does a business need this? Which result will be considered successful? What happens if you don't do this?
It can be awkward to ask such questions. What if they think we don't understand the obvious?
As a result, the team does something that only vaguely resembles the competitor's decision. And when the customer sees the result for the first time, he says, "No, I meant something completely different."
And a new round of work begins.
3. No one wants to talk about scope
"There's a little refinement."
This phrase is familiar to many. The problem is that the task, which is small in terms of the interface, sometimes requires major changes within the system.
In such a situation, it's easy to say, "Okay, we'll do it," and leave the details for later.
Only this "later" usually comes along with additional deadlines, architectural changes, and a legitimate question: why didn't we warn you about this earlier?
In all three cases, the team can be quite strong technically. People know how to write code, evaluate tasks, and work according to their chosen methodology. The problem arises elsewhere, where you need to be the first to say out loud what others are already beginning to suspect.
What should I do about it?
It is not necessary to conduct another communication training. It's much more useful to develop a few simple habits.
Asking "why" before "how?" is even before the task has turned into work.
Talk about the risk at the moment it appears, rather than waiting for it to become a problem.
And the most difficult thing is to allow yourself to be an uncomfortable conversationalist sometimes. It's much easier to stop a questionable task today than to explain three weeks later why the team spent time and money on it.
The methodology sets the framework in which the team works. But by itself, it does not determine how expensive the project will eventually cost.
This is decided by people within the framework: how openly they discuss problems, whether they know how to ask questions and whether they are ready to say what they don't want to hear.
The methodology can be changed in one sprint.
But the habit of saying uncomfortable things on time has to be rebuilt with each new team.
Один проект оказался на грани провала. Команда готовилась работать сверхурочно две недели, чтобы успеть выпустить очередную фичу. Казалось, оставался единственный вариант — ускориться и дожать.
Но на очередном созвоне тимлид задал простой вопрос:
«А зачем нам вообще эта функция?»
Заказчик задумался. Вскоре выяснилось, что фича, ради которой команда собиралась штурмовать дедлайн, никак не влияла на цель релиза. Когда-то её просто добавили в список требований — и с тех пор никто не спрашивал, действительно ли она всё ещё нужна.
Проект спасли не смена методологии и не героический рывок разработчиков в последнюю ночь. Его спас вовремя заданный неудобный вопрос.
Индустрия любит спорить о том, что работает лучше: Scrum или Kanban, Waterfall или Agile. Но на практике сроки и бюджет проекта часто зависят от другого: может ли команда вовремя сообщить о проблеме, задать неудобный вопрос, обозначить риск или остановить сомнительное решение.
Вот три ситуации, знакомые почти любой команде.
1. Плохие новости откладывают до последнего
Уже на второй день спринта разработчик понимает, что оценка была слишком оптимистичной. Но говорить об этом не хочется: вдруг получится нагнать? Вдруг команда всё-таки справится? Да и признаться в ошибке неловко.
Проблема остаётся внутри до демо. А там выясняется, что переделывать уже поздно и дорого.
То, что можно было спокойно обсудить на третий день, превращается в аврал в последний.
2. Проще согласиться, чем уточнить
Заказчик говорит: «Сделайте как у конкурентов».
Менеджер кивает, и задача отправляется в бэклог. Хотя вопросов на самом деле десятки: что именно нужно повторить? Зачем это нужно бизнесу? Какой результат будет считаться успешным? Что произойдёт, если этого не делать?
Задавать такие вопросы бывает неловко. Вдруг подумают, что мы не понимаем очевидного?
В итоге команда делает нечто, лишь отдалённо напоминающее решение конкурента. А когда заказчик впервые видит результат, говорит: «Нет, я имел в виду совсем другое».
И начинается новый круг работы.
3. Никто не хочет говорить о scope
«Там небольшая доработка».
Эта фраза знакома многим. Проблема в том, что задача, небольшая с точки зрения интерфейса, иногда требует серьёзных изменений внутри системы.
В такой ситуации легко сказать: «Хорошо, сделаем», — а детали оставить на потом.
Только это «потом» обычно приходит вместе с дополнительными сроками, изменениями архитектуры и закономерным вопросом: почему мы не предупредили об этом раньше?
Во всех трёх случаях технически команда может быть вполне сильной. Люди умеют писать код, оценивать задачи и работать по выбранной методологии. Проблема возникает в другом месте — там, где нужно первым произнести вслух то, что остальные уже начинают подозревать.
Что с этим делать?
Не обязательно проводить очередной тренинг по коммуникации. Гораздо полезнее выработать несколько простых привычек.
Задавать вопрос «зачем?» раньше, чем «как?» — ещё до того, как задача превратилась в работу.
Говорить о риске в тот момент, когда он появился, а не ждать, пока он станет проблемой.
И самое сложное — разрешить себе иногда быть неудобным собеседником. Гораздо проще остановить сомнительную задачу сегодня, чем через три недели объяснять, почему команда потратила на неё время и деньги.
Методология задаёт рамку, в которой работает команда. Но сама по себе она не определяет, насколько дорого в итоге обойдётся проект.
Это решают люди внутри рамки: насколько открыто они обсуждают проблемы, умеют ли задавать вопросы и готовы ли сказать то, что не хочется слышать.
Методологию можно поменять за один спринт.
А вот привычку вовремя говорить неудобные вещи приходится выстраивать заново с каждой новой командой.
Share
