Question d'entretien pour Chef de produit

Comment écrivez-vous une user story que les ingénieurs trouvent réellement utile ?

Ce que le recruteur cherche à évaluer, comment structurer votre réponse et un exemple parlé à adapter.

Réponse rapide

Les stories utiles portent le pourquoi et la limite, pas seulement le quoi. Gardez l'utilisateur et le résultat dans la phrase, puis mettez l'essentiel de votre effort dans des critères d'acceptation qui nomment les cas limites : état vide, permission refusée, hors ligne, et ce qui se passe en cas d'échec. Les ingénieurs n'ont pas besoin de poésie, ils ont besoin de savoir quand c'est fini et quels cas ils peuvent ignorer sans risque.

Pourquoi les recruteurs posent cette question

C'est une question d'artisanat qui montre vite si vous avez livré avec une équipe ou seulement écrit des tickets. Le recruteur écoute les critères d'acceptation plutôt que le format de story, des cas limites tranchés par vous plutôt que devinés par un ingénieur à minuit, et le fait que vous relisiez le ticket avec la personne qui va le construire avant l'estimation. S'obséder sur le modèle en tant qu'utilisateur en sautant les critères, c'est le signe qui trahit.

Comment structurer votre réponse

  • Dites que les critères d'acceptation portent l'essentiel de la valeur.
  • Listez les cas limites que vous tranchez toujours en amont.
  • Incluez ce qui est explicitement hors périmètre.
  • Décrivez la relecture du ticket avec un ingénieur avant estimation.

Exemple de réponse

Exemple parlé, à la première personne

La partie que les ingénieurs utilisent vraiment, ce sont les critères d'acceptation, donc c'est là que je passe mon temps. La phrase de la story porte le pourquoi en une ligne, mais ensuite je liste les cas : ce qui se passe avec un état vide, ce que voit un utilisateur sans permission, ce qui arrive si la requête échoue à mi-parcours, ce qu'on fait sur une connexion lente. Ce sont les questions pour lesquelles on me pingerait sinon sur Slack trois jours plus tard, et chacune est une décision que je devrais prendre plutôt que de laisser un ingénieur deviner à onze heures du soir. J'écris aussi ce qui est explicitement dehors, parce que ça coupe court aux embellissements bien intentionnés. Et je fais relire les critères par l'ingénieur avant que le ticket soit estimé. Ça prend dix minutes et ça fait en général remonter une exigence techniquement coûteuse pour presque aucun bénéfice utilisateur, que je peux alors abandonner. Une story estimée sans cette conversation, c'est à peu près un voeu pieux.

Vous passez cet entretien bientôt ? GhostPilot écoute votre appel en direct, repère la question dès qu'elle est posée et affiche une réponse structurée à l'écran en temps réel. Essayez-le lors de votre prochain entretien blanc, ou prenez un Session Pass à $29, sans abonnement, pour le jour J.

Voir comment ça marche

Questions de relance à prévoir

  • Comment dimensionnez-vous une story qui s'avère être trois stories ?
  • Qui écrit les critères d'acceptation dans votre équipe, vous ou la QA ?
  • Comment gérez-vous les stories pour un travail sans surface utilisateur visible ?

Autres questions pour Chef de produit

Votre recruteur posera sa propre version de celle-ci. Collez votre véritable fiche de poste dans le Question Predictor gratuit et obtenez les 20 questions que ce poste a le plus de chances de poser, avec ce que chacune cherche vraiment à sonder.

Prédire mes questions

Répétez les questions difficiles avant qu'on vous les pose

Entraînez-vous avec un copilote en direct, puis présentez-vous prêt. Un Session Pass à $29 vous accompagne pendant l'entretien, sans abonnement et sans engagement.

Obtenir GhostPilot