Connaissez-vous l'image décrite dans le titre de l'article et avez-vous réfléchi à la réponse à cette question. Curieusement, la même réponse pourrait fonctionner pour ces deux cas différents. Et ici et là, celui qui comprend correctement et travaille avec les exigences l'emporte. Mais si vous creusez plus profondément, vous constatez que le sens inhérent à la réponse dans les deux cas est très différent.
Analyse du premier cas Examinons d'abord la structure de l'exigence en tant que telle. Liens ce qui est une exigence En bref, nous avons deux composantes d'une exigence. La partie qui est liée à la gestion. Et la partie qui décrit le contenu réel. Au total, nous avons des attributs de gestion et une description de l'essence. Les attributs de gestion comprennent l'auteur, la criticité, la complexité et le coût de mise en œuvre, le calendrier de mise en œuvre, etc.
Imaginons maintenant que le PM et l'analyste se soient réunis avec le client à un moment donné de la conclusion du contrat. Ils devront négocier des conditions et des montants. Ils ont un document d'analyste bien écrit prêt. Mais en même temps, PM ne le connaît que superficiellement. Et je n'ai pas particulièrement approfondi la structuration et le détail de l'exigence. Comme - "ce n'est pas l'affaire d'un roi" ... Et il fait face à une situation classique: lors d'une réunion, il s'avère, comme cela arrive dans presque tous les cas, qu'il n'y a pas assez de temps ou d'argent pour le développement, ou les deux en même temps.
Le PM commence aussitôt à "appuyer sur toutes les pédales" pour "faire passer le document" et négocier le montant total prévu ... Il n'est pas difficile de deviner ce qui attend nos développeurs en cours de route ... Mais ici un analyste peut intervenir avec une proposition pour parcourir le document et décider si tout est décrit dans le document est-il vraiment nécessaire et nécessaire pour le client? Très souvent, il s'avère que le Client peut vraiment faire des concessions, MAIS! ... pas pour de l'argent, mais avec la mise en œuvre d'une ou plusieurs exigences. Ainsi, l'analyste devient le maillon principal des négociations et le Premier ministre, qui semble avoir une telle responsabilité, est dans l'ombre. Et, s'il ne tire pas les conclusions appropriées, alors très bientôt le PM-stvo peut aller chez l'analyste. C'est la fréquence à laquelle les PM sortent des analystes.
, , , . " ", . -.
, . - , . .
. : " ". : . , . . " ".
-: , - . - .
, .
. , - - - , .
, , , - . , . , , , - .
.
- , .
, : - ? - .
"" : — , , .
, , .
, ( ) , , (, - , ).
. , , , , , .
: ( ). "", -, .
, " ", - …
, , , ( ) .
, " ", , - , .
Un lecteur intéressé peut avoir une question légitime: Eh bien, bref, quel est - il au sujet et pourquoi est - il? Tout est très simple: en règle générale, lorsqu'un PM se révèle être un "faible" sur un projet, et qu'un analyste est un "escroc", alors ils sont principalement soupçonnés de malhonnêteté. Mais en fait, la raison est la non-alphabétisation. Les gars, si vous vous êtes reconnu quelque part dans la note - passez par le "programme éducatif" sur la gestion des exigences, mais seulement un véritable programme éducatif. Et vous deviendrez indispensable pour l'équipe des membres tueurs dans la concurrence féroce d'aujourd'hui pour les projets informatiques.
Par Yuri Chernyavsky, analyste principal chez ReqnDoc