Avec votre discours sur les développeurs et les propriétaires de produits, il me semble que vous n'avez pas de personne intermédiaire responsable des fonctionnalités de votre organisation.
Eh bien, dans mon organisation, je suis cette personne. Je suis l'ingénieur des exigences, celui qui a appris à faire de bonnes spécifications et à choisir des fonctionnalités qui aboutissent à un logiciel de haute qualité avec une conception d'interaction conviviale. (Dans d'autres organisations, c'est la personne UX qui obtient le même emploi, vous connaissez peut-être mieux ce terme).
Et je peux vous dire: obtenir une bonne spécification est difficile. Bien sûr, les développeurs détestent le faire. C'est un fardeau pour eux - ils sont là pour construire un logiciel, pas pour penser aux jeux de pouvoir entre les parties prenantes et aux modèles mentaux des utilisateurs paresseux. Mais tu sais quoi? C'est aussi un fardeau pour les propriétaires de produits. Ils ne connaissent pas mieux les fonctionnalités que leur logiciel devrait contenir que les développeurs ou les utilisateurs. La création d'une spécification viable est une compétence acquise, et si vous ne l'avez jamais apprise, vous ne pouvez pas être bon dans ce domaine. Bien sûr, il y a beaucoup de développeurs et de propriétaires de produits qui peuvent le faire, car ils ont dû le faire dans les projets précédents. Mais le propriétaire de produit ou le développeur moyen a du mal à le faire, car ce n'est naturellement pas son travail de le faire. Tout le monde qui peut conduire une voiture ne peut pas concevoir une voiture; De même,
Pouvez-vous développer des logiciels sans ingénieur des exigences? Sûr que vous pouvez. Mais mettre tout le poids de ses spécifications sur les épaules du propriétaire du produit n'est pas juste et n'est pas bon pour le résultat du projet. Surtout parce qu'il est confronté à une tâche qui lui est inhabituellement difficile, obtenir la contribution et le soutien des autres est très utile. Si vous êtes dans une telle situation, ne regardez pas votre pauvre propriétaire de produit et dites "dites-moi quoi faire pour vous et je vous ferai", il ne sait vraiment pas de quoi il a besoin. Mais une discussion avec vous l'aidera à articuler ses pensées et à explorer ses idées.
Lorsqu'il n'y a pas d'ingénieur des exigences dans la structure du projet, il y a un autre problème: il n'y a pas de modérateur. Tous les développeurs sont du côté technique, tous les propriétaires de produits sont du côté commercial. Lorsque les deux cultures s'affrontent, des conflits peuvent survenir, chaque partie jugeant l'autre stupide et déraisonnable (car elle utilise son propre système de valeurs pour juger). Alors, parlez avec votre propriétaire de produit des fonctionnalités possibles, mais soyez poli et patient même lorsque vous pensez qu'il ne le mérite pas; le succès du projet dépend de la façon dont vous pouvez vous entendre, et parfois prendre la décision sous-optimale est mieux que de ne prendre aucune décision en raison d'un conflit. Il peut être utile d'établir une hiérarchie et de donner le dernier mot à l'un d'entre vous, car cela évite les conflits bloqués. S'il a le dernier mot, s'en remettre à lui même si vous pensez que c'est injuste.
À propos de la partie "passive": si vous n'avez pas d'idées, n'essayez pas de trouver quelque chose juste pour montrer l'activité. Si le propriétaire du produit n'est pas sûr et ne connaît pas de bons critères pour évaluer ses idées, des idées étranges «juste pour avoir quelque chose» rendront une situation déjà difficile encore plus difficile. Trouver de bonnes idées de fonctionnalités n'est pas magique, mais cela nécessite des connaissances. Si vous ne l'avez pas appris dans les manuels, vous aurez probablement besoin de quelques années d'expérience de développeur, en particulier dans les projets où vous êtes exposé aux utilisateurs ou aux données d'utilisation générées par l'utilisateur (analyses, mesures de satisfaction) avant que votre cerveau ne trie les modèles pour lui-même. et vous commencez à remarquer: il y a un problème que nous pouvons résoudre ici. Les utilisateurs semblent manquer quelque chose sur cette page, Qu'est-ce que ça peut être? Ensuite, vous aurez de bonnes idées à partager.
Conclusion 1: Dans les projets sans ingénieur des exigences, il est bon de faire des suggestions lorsque vous les avez. Faites-le avec sensibilité et tact - il est impératif d'éviter les conflits même si cela signifie que votre bonne idée est étouffée dans l'œuf.
Et si vous faites partie d'une équipe avec un ingénieur des exigences?
J'adore entendre les idées de fonctionnalités de tout le monde! Oui, parfois les idées des développeurs sont terribles (quand ils veulent faire en sorte que l'interface utilisateur suive la logique de programmation). Les idées des propriétaires de produits sont également souvent terribles (quand ils veulent le soleil et la lune avec un budget restreint - oh, et l'utilisateur est censé entrer des pages d'informations personnelles avec la plus haute qualité de données, sans rien obtenir en retour). Mais c'est mon travail de trouver une spécification qui soit bonne pour tout le monde dans l'équipe. Et même si votre idée ne marchera jamais, l'entendre me fait prendre conscience que vous avez un souci. Vous avez peut-être choisi la mauvaise solution à suggérer, mais cela ne rend pas votre préoccupation moins valable. Si vous l'avez repéré, il doit probablement être résolu (ou je dois trouver une raison pour laquelle ce n'est pas une menace). Si vous avez un ingénieur responsable des spécifications, n'hésitez pas à leur faire part de vos suggestions. S'ils ne vous entendent pas, ils font quelque chose de mal (notez que «considérer» ne signifie pas «accepter»).
Un ingénieur des exigences doit voir le projet du point de vue de chaque partie prenante séparément (et parfois en même temps). Nous ne sommes qu'humains et nous y échouons souvent. Si vous êtes là pour fournir votre véritable point de vue, au lieu du point de vue que nous pensons avoir, alors votre contribution est très précieuse.
Vous pouvez être plus libre dans votre comportement ici. C'est mon travail de faire la danse de la sensibilité. Ne soyez pas ouvertement agressif, cela gêne mon travail, mais vous avez besoin de moins de maîtrise de soi et de conscience culturelle / communicationnelle, car je peux prendre le relais. Vous ne flottez pas non plus, dans une situation où il y a deux idées contradictoires et où personne ne peut juger laquelle est la meilleure. Je suis censé le savoir, et si ça ne marche pas, c'est ma tête dans le noeud coulant.
Conclusion 2: S'il y a un ingénieur des exigences dans l'équipe, allez-y avec des suggestions de fonctionnalités du produit. Vous n'avez pas besoin de gants de velours cette fois.
Et enfin, que se passe-t-il s'il n'y a pas d'ingénieur des exigences, que le propriétaire du produit est débordé et a du mal à trouver des idées, que le patron vous regarde de manière ciblée et que vous n'avez aucune idée à proposer?
Vous avez quelques options. La première consiste, comme vous l'avez mentionné, à arrêter. Toutes les organisations ne fonctionnent pas de cette façon, et si cet environnement ne vous convient pas, trouvez-en un meilleur. Ce sera bon pour vous à long terme.
Vous pouvez également attendre et voir si quelque chose change. Le prochain projet peut avoir un propriétaire de produit plus expérimenté (ou un avec plus de leadership). Mais vous ne pouvez pas caler pour toujours.
La troisième option consiste à apprendre par vous-même l'ingénierie des exigences. C'est une compétence très recherchée de nos jours. Même si vous ne prévoyez jamais d'occuper des postes où vous êtes un ingénieur des exigences à temps plein, cette compétence améliore votre valeur en tant que développeur, car elle vous permet de mieux comprendre les autres membres de votre équipe (et vos utilisateurs) et le processus de développement se déroule plus facilement. Et vous n'avez pas besoin d'aller dans toute sa profondeur. Un manuel d'entrée de gamme qui explique les tâches, les flux de travail, les modèles mentaux et les modèles de données centrés sur l'utilisateur vous permettra déjà de repérer de nombreuses opportunités d'amélioration dans un logiciel conçu par une équipe d'hommes d'affaires et de développeurs. Don' t optez pour les livres les plus épais destinés à servir de référence pour les universitaires (comme la récente traduction de Pohl en anglais) - ils sont plus une liste de toutes les méthodes possibles pour chaque petite étape, sans explication sur la façon de les faire. Choisissez quelque chose orienté vers la pratique.
Si vous l'essayez et constatez que vous n'avez aucun intérêt personnel dans la région, c'est toujours bien. Ne vous forcez pas à faire quelque chose que vous n'aimez pas. Mais vous devriez probablement chercher un emploi dans une organisation avec une structure d'équipe différente.
Conclusion 3: Au lieu d'attendre des années pour obtenir une compréhension intuitive, lisez un livre ou deux et vous aurez déjà de bonnes idées à fournir