Alors, que dois-je faire pour rendre les PM responsables et nous donner les exigences appropriées?

Dès que vous ou vos collègues voyez une exigence peu claire, demandez immédiatement des éclaircissements.

Si vous voyez un tel champ 'timeOfEvent' et qu'il n'est pas clair, posez le type de questions que vous avez écrites ici (quel format nous voulons l'heure? Cela devrait-il être déclenché lors de la création? etc.). Ensuite, lorsque vous êtes clair, vous pouvez recommencer à travailler sur une telle fonctionnalité (si les commentaires ne sont pas donnés rapidement, continuez avec les choses que vous pouvez entre-temps).

En d'autres termes, au lieu de leur demander (ou à la direction) de fournir des exigences plus claires demandent de manière proactive des éclaircissements sur ces exigences.

La plupart des PM / BA semblent bien définir les exigences pour les histoires où nous devons développer une interface utilisateur, c'est-à-dire des choses que vous pouvez voir sur un écran. Mais, pour les choses non liées à l'interface utilisateur comme les API, soit elles ne fournissent pas d'exigences, soit elles ne fournissent pas d'exigences superficielles.

J'ai une observation générale que de nombreux non-techniciens ne comprennent pas les nuisances détaillées des détails techniques. Il me semble que vos PM / BA sont en mesure de vous donner des flux UX détaillés car c'est quelque chose de visiblement testable, mais pas pour les API technologiques.

Si tel est le cas, de nombreuses entreprises informatiques ont de plus en plus commencé à avoir des rôles pour Responsable de programme technique / Responsables de produit technique, qui sont essentiellement des personnes ayant une formation technique travaillant sur des produits techniques, afin qu'ils puissent vous donner des spécifications telles que celles que vous mentionnez, d'autres détails comme des diagrammes de flux de travail, etc., et également aider à rendre les intégrations, etc. plus rapides lorsque vous êtes bloqué dans des équipes externes.

Si vous êtes en mesure d'influencer les décisions d'embauche, c'est un domaine dans lequel vous pouvez proposer des changements.

Donc, que dois-je faire pour responsabiliser les PM et nous donner les exigences appropriées?

Vous pouvez essayer d'impliquer certains membres de votre équipe dans la phase de collecte des exigences elle-même, afin que votre équipe puisse collaborer avec le produit pour développer des spécifications appropriées. De cette façon, vous co-développez les spécifications.

Obtenez l'adhésion des dirigeants ici, et n'allez pas dans les cycles de penser que c'est leur travail, c'est notre travail. Bien qu'il aurait été bon que le PM donne de bonnes exigences au départ, en collaborant, vous pouvez minimiser les frictions que vous rencontrez actuellement.

Vous avez un chef de produit qui est censé savoir ce que les clients paieront. Et c'est ce qu'il écrit dans ses spécifications.

Et vous réalisez qu'il doit y avoir plus dans une spécification pour créer un produit qui fonctionne réellement. Les choses que les clients supposent «fonctionneront». Le chef de produit ne peut pas faire cela. Donc, quelqu'un doit le faire qui peut. Similaire à la conception graphique. Vous ne laissez pas le chef de produit décider cela, mais laissez le soin à un graphiste.

Étant donné que cette spécification va d'abord aux développeurs, il est logique que l'un d'entre eux remplisse les espaces techniques dans la spécification avant le début du travail (ou comme première étape du travail si vous préférez). Cette personne peut ajouter "timeOfEvent = heure de début de l'événement, stockée en secondes depuis l'époque en GMT, affichée dans le fuseau horaire de l'utilisateur au format défini par les paramètres système de l'utilisateur".

Ce n'est peut-être pas votre meilleur exemple, mais votre exemple met en évidence un point important.

dit qu'une réponse API a un champ appelé "timeOfEvent". Notre PM l'a défini comme this timeOfEvent = Heure à laquelle l'événement s'est produit. Cela ne nous aide pas. Doit-il être au format de date USA ou autre chose? Est-ce juste une date ou voulez-vous aussi l'heure exacte en secondes?

Maintenant, même si vous pensez que cette spécification n'est pas assez précise, dans certaines situations c'est parfaitement bien.

Si votre API représente toujours les horodatages à UTC avec des secondes, il est raisonnable de supposer que cet horodatage doit suivre cette convention. Spécifier le format exact à chaque fois qu'il y a un horodatage encombre le document des exigences.

Bien qu'il puisse être tentant de rendre les exigences, et que de nombreux développeurs bien pensants se sentent enclins à le faire, vous devez décider sur un plan d'action approprié pesant le coût de faire une mauvaise hypothèse sur les exigences peu claires et le temps que vous attendez qu'ils vous reviennent.

Supposons que vous supposiez qu'ils veulent le format USA avec quelques secondes, il ne vous faudrait pas longtemps pour changer cela si votre hypothèse est incorrecte. Donc, extrapoler des documents d'exigence de forme est très bien, à condition que vous documentiez toutes les hypothèses et les souleviez avec le chef de produit à un moment donné.

Cela ne doit pas seulement être autour des formats, cela peut aussi être un comportement.

S'il y a une exigence peu claire où une erreur se traduira par beaucoup d'efforts inutiles, il est parfaitement normal de retourner au chef de produit pour obtenir des conseils.

S'il y a un beaucoup de temps de développement perdu, les gens devraient le documenter. Gardez à l'esprit que l'objectif d'une entreprise n'est pas de minimiser le temps de développement perdu, mais de générer des bénéfices.

Ne pourriez-vous pas simplement avoir un échange direct avec l'émetteur, en direct ou par téléphone / Web. Cela aiderait à se concentrer sur le comportement souhaité et les cas extrêmes.

Sinon, j'ai l'impression que demander trop de détails peut être un fardeau pour les deux parties. Je suppose que le côté non technique laisse de côté les détails à remplir en supposant que vous savez ce qui est le mieux ou ce qui est le plus cohérent dans votre base de code et je pense que c'est normal dans une certaine mesure.

C'est pourquoi je pense que l'échange en direct serait préférable de mettre en valeur votre besoin et de bien documenter et évaluer le cas d'espèce et comment moduler l'échange afin d'optimiser les choses. Notamment en passant en revue le cas et en expliquant pourquoi certaines spécifications sont utiles et ce qui pourrait se passer sans elles. Mais vous devez également vous attendre à ce qu'ils ne soient pas des experts de tous les détails techniques.