Você está familiarizado com a imagem descrita no título do artigo e já pensou na resposta a esta pergunta. Curiosamente, a mesma resposta pode funcionar para esses dois casos diferentes. E aqui e ali ganha quem entende e trabalha corretamente com os requisitos. Mas se você se aprofundar, descobrirá que o significado inerente à resposta em ambos os casos é muito diferente.
Analisando o primeiro caso Primeiro, vamos examinar a estrutura do requisito como tal. Links o que é um requisito Em resumo, temos dois componentes de um requisito. A parte que se relaciona com a gestão. E a parte que descreve o conteúdo real. No total, temos atributos gerenciais e uma descrição da essência. Os atributos de gerenciamento incluem autor, criticidade, complexidade e custo de implementação, tempo de implementação, etc.
Agora vamos imaginar que o PM e o analista chegaram a uma reunião com o cliente em algum estágio da conclusão do contrato. Eles terão que negociar em termos e valores. Eles têm um documento bem escrito por um analista pronto. Mas, ao mesmo tempo, o PM o conhece apenas superficialmente. E não me aprofundei na estruturação e no detalhamento do requisito especialmente. Tipo - “isso não é negócio de rei” ... E ele se depara com uma situação clássica: Numa reunião acontece, como acontece em quase todos os casos, que não há tempo e dinheiro para o desenvolvimento, ou ambos ao mesmo tempo.
O PM começa imediatamente a "apertar todos os pedais" para "avançar no documento" e barganhar pelo valor total planejado ... Não é difícil adivinhar o que espera nossos desenvolvedores ao longo do caminho ... Mas aqui um analista pode intervir com uma proposta para examinar o documento e decidir se tudo está descrito no documento é realmente necessário e necessário para o cliente? Muitas vezes acontece que o Cliente pode realmente fazer concessões, MAS! ... não por dinheiro, mas com a implementação de um ou vários requisitos. Assim, o analista passa a ser o elo condutor das negociações, e o PM, sobre o qual essa responsabilidade deveria recair, fica nas sombras. E, se ele não tirar as conclusões apropriadas, então muito em breve o PM-stvo pode ir ao analista. É com que frequência os PMs crescem de analistas.
, , , . " ", . -.
, . - , . .
. : " ". : . , . . " ".
-: , - . - .
, .
. , - - - , .
, , , - . , . , , , - .
.
- , .
, : - ? - .
"" : — , , .
, , .
, ( ) , , (, - , ).
. , , , , , .
: ( ). "", -, .
, " ", - …
, , , ( ) .
, " ", , - , .
Um leitor interessado pode ter uma pergunta legítima: Bem, em resumo, do que se trata e por que é? Tudo é muito simples: como regra, quando um PM acaba se revelando um "fraco" em um projeto e um analista é um "vigarista", então eles são, em primeiro lugar, suspeitos de desonestidade. Mas, na verdade, o motivo é a falta de alfabetização. Gente, se você se reconheceu em algum lugar da nota - vá até o "programa educacional" sobre gerenciamento de requisitos, mas apenas um programa educacional real . E você se tornará indispensável para a equipe de membros matadores na competição acirrada de hoje por projetos de TI.
Por Yuri Chernyavsky, analista líder da ReqnDoc