Are you familiar with the picture described in the title of the article and have you thought about the answer to this question. Oddly enough, the same answer might work for these two different cases. And here and there the one who correctly understands and works with the requirements wins. But if you dig deeper, you find that the meaning inherent in the answer in both cases is very different.
Analyzing the first case First, let's look at the structure of the requirement as such. Links what is a requirement In short, we have two components of a requirement. The part that is related to management. And the part that describes the actual content. In total, we have managerial attributes and a description of the essence. Management attributes include author, criticality, complexity and cost of implementation, timing of implementation, etc.
Now let's imagine that the PM and the analyst came to a meeting with the customer at some stage of the contract conclusion. They will have to bargain on terms and amounts. They have a document well written by an analyst ready. But at the same time, PM is only superficially familiar with him. And I did not delve into the structuring and detailing of the requirement especially. Like - "this is not a king's business" ... And he faces a classic situation: At a meeting it turns out, as it happens in almost all cases, that there is not enough time or money for development, or both at the same time.
The PM immediately starts to "press all the pedals" in order to "push through the document" and bargain for the total planned amount ... It is not difficult to guess what awaits our developers along the way ... But here an analyst can intervene with a proposal to go through the document and decide whether everything described in the document is it really necessary and necessary to the customer? Very often it turns out that the Customer can really make concessions, BUT! ... not for money, but with the implementation of one or several requirements. Thus, the analyst becomes the leading link in the negotiations, and the PM, which seems to have such a responsibility, is in the shadows. And, if he does not make the appropriate conclusions, then very soon the PM-stvo can go to the analyst. This is how often PMs grow out of analysts.
, , , . " ", . -.
, . - , . .
. : " ". : . , . . " ".
-: , - . - .
, .
. , - - - , .
, , , - . , . , , , - .
.
- , .
, : - ? - .
"" : — , , .
, , .
, ( ) , , (, - , ).
. , , , , , .
: ( ). "", -, .
, " ", - …
, , , ( ) .
, " ", , - , .
An interested reader may have a legitimate question: Well, in short, what is it about and why is it? Everything is very simple: as a rule, when a PM turns out to be a "weakling" on a project, and an analyst is a "crook", then they are first of all suspected of dishonesty. But in fact, the reason is non-literacy. Guys, if you recognized yourself somewhere in the note - go through the "educational program" on managing requirements, but only a real educational program. And you will become indispensable for the killer-members team in today's fierce competition for IT projects.
By Yuri Chernyavsky, Lead Analyst at ReqnDoc