Task decomposition or why adding one field is NOT a one minute adventure
Let’s say you’re writing an app (how unexpected) and you’re tasked with displaying a phone number in a user’s profile. The manager asks how long it will take, expecting to hear the answer right away. But you reply that you need to think about it, and your manager passive-aggressively asks what there is to think about — it’s the same field.
“In and out, an adventure for 20 minutes, Morty!”
Unfortunately, that’s often not the case. Especially if the data for that field is not stored locally.
First, a manager demanding an immediate response is not a pleasant option. Professionals in their field understand why sometimes even such a seemingly obvious question can take time.
Second, it can be due to a lack of understanding of the steps a developer/team needs to go through in implementation.
When posing the question from the example, we should list the following points:
- Is it implemented on the server? Believe me, there are often communication complexities and workloads that vary from team to team, paradoxically. From the answer to this question, the estimate can take off for the obvious reason, because if the chip is not implemented, then so far in the extension is definitely not going to roll it out.
- How hard will it be to change the structure in the database? Is migration necessary? Experience from past updates will help here.
- Is it necessary to localize this field? For example, a placeholder? Here we see that, as with the question about the implementation on the server is not all up to us.
- Do we need validation of this phone number? Do we need regulars, can the number contain letters, for example? How many characters can there be? You might not be surprised, but letters in numbers are possible at least in advertising.
- What font, what color, how to design in general? Is animation needed when translating the input focus?
The sub-items may vary from problem to problem, but asking the question is half the solution.
There are actually two kinds of decomposition in the list above:
Vertical: server, translation from the translation team, implementation on the client.
And horizonal for the application: a subtask about validation, about design, about storage.
A developer with experience can give an answer quickly if he has done this decomposition 1,000 times. But his answer may be different from the one given by a junior developer who is ready to get into the firing line right away.
Decomposition is needed for next reasons:
- Understand the sequence of tasks.
- Estimate the deadline.
- Simplify the testing process.
- To help prioritize. In a sprint, but in a good way, initially in a backlog.
Two small conclusions:
1️⃣ We work for the business. So we need to understand why a manager might be unhappy with a slow assessment.
2️⃣ I want to believe that not only developers, but also project managers will read this post. Professionals will smile and say that they are. But those who are starting to manage teams — please read this post again.
Also I wrote more posts on my channel at the telegram blog:
