Est-il normal que les développeurs suggèrent des idées de fonctionnalités aux propriétaires de produits? [fermé]

16

J'ai commencé à travailler en tant que développeur assez récemment, après avoir travaillé en tant qu'administrateur système auparavant.

Ma compréhension de la façon dont une équipe de développement de logiciels utilisant les fonctions Agile est que la communication «ce dont nous avons besoin pour implémenter» se produit principalement dans une direction, du propriétaire du produit aux développeurs. Les développeurs peuvent exprimer leurs préoccupations au propriétaire du produit au sujet de la dette technique, mais proposer des idées de fonctionnalités ne devrait pas être l'une de leurs principales responsabilités.

L'entreprise dans laquelle je travaille a une vision différente. Pour eux, les développeurs doivent non seulement s'adresser aux propriétaires de produits de leur propre équipe pour suggérer des idées de fonctionnalités, mais également aux propriétaires de produits d'autres équipes s'ils pensent qu'ils ont quelque chose à apporter au produit de cette équipe. L'idée est que nous sommes tous une grande équipe <nom de l'entreprise>, et tous les développeurs devraient utiliser leur expertise pour pousser les fonctionnalités qu'ils pensent utiles.

Une telle approche est-elle "normale", faute d'un meilleur mot? Suis-je trop passif, dois-je prendre l'initiative et commencer à proposer des idées aux propriétaires de produits? Inversement, l'entreprise s'est-elle complètement trompée et je devrais chercher un emploi ailleurs?

louniks
la source
15
Bien sûr, les programmeurs savent souvent beaucoup de choses dont le propriétaire du produit n'a jamais entendu parler. Prenez le développement Web, il existe des services, des API, toute quantité de bibliothèques et de plugins et d'éléments d'interface utilisateur. Nous travaillons souvent avec des clients qui n'ont pas beaucoup plus qu'une idée approximative de ce qu'ils veulent faire, mais qui ne savent pas quels sont les moyens courants de les mettre en œuvre ou quelles fonctionnalités supplémentaires seraient possibles.
thorsten müller
1
Ressentez-vous du ressentiment ou des conséquences négatives de ne pas suggérer de fonctionnalités? Il semble que votre entreprise veuille encourager la pratique et ne pas punir ceux qui ne le font pas.
JeffO
C'est le processus normal dans deux entreprises pour lesquelles j'ai travaillé. Je me rends compte que les gens d'affaires n'ont tout simplement pas la moindre idée de la valeur des développeurs en solutions / résolution de problèmes. Sauter le navire est susceptible de rencontrer le même problème. Suggérer de nouvelles fonctionnalités aux gens du produit comme s'il s'agissait d'une solution, s'appelle gérer les gestionnaires et fonctionne bien. Le seul problème est que cela signifie que vous n'obtenez pas de crédit pour vos idées, mais au moins vos fonctionnalités sont implémentées.
Jason
OMI, c'est une très bonne chose et très saine. Les propriétaires de produits peuvent être des experts dans le domaine commercial, mais ils ne sont probablement pas au courant de toutes les nouvelles technologies ou approches techniques disponibles. En outre, les développeurs peuvent avoir des informations sur le système qui proviennent de la perspective différente de travailler directement avec le code. Vous voulez vraiment rester avec une entreprise qui accueille les idées de tout le monde, quel que soit le rôle. Cela ne signifie pas que les propriétaires sont désemparés, cela signifie qu'ils sont ouverts aux idées de chacun.
Ken Liu

Réponses:

2

Cela dépend de ce que vous entendez par idées de fonctionnalités.

Dans le jeu de planification, il n'est pas rare que les développeurs fournissent des informations sur une histoire qui pourrait finir dans l'itération. Cependant, cela est très différent des développeurs qui proposent eux-mêmes des histoires.

Dans les systèmes matures, les développeurs peuvent suggérer un moyen de contourner un problème connu qui pourrait en faire une itération.

Les améliorations pourraient être correctes, par exemple en ajoutant un graphique pour un rapport, mais des sonneries d'alarme sonneraient pour moi si les développeurs proposaient de nouvelles histoires de bonne foi. S'il y avait une réelle valeur à cela, je me demanderais pourquoi il n'y avait pas d'histoire non implémentée pour cela ou pourquoi elle n'était jamais apparue dans la rétrospective.

Robbie Dee
la source
1
Je n'interprète pas la philosophie de mon entreprise comme demandant aux développeurs de proposer des histoires, et je ne me souviens pas avoir vu cela se produire. Ce que je pense qu'ils veulent, c'est qu'une fois qu'une idée a été émise et qu'un développeur s'est approprié son exécution, c'est la responsabilité du développeur de défendre cette idée jusqu'à la fin.
louniks
1
Vous dites donc que les alarmes sonnent lorsqu'un développeur pense à une idée à laquelle un propriétaire de produit n'a pas pensé? Pourquoi serait-ce une si mauvaise chose?
Stefan Billiet
1
Lancer des idées, c'est bien - cela fait partie intégrante du jeu de planification. S'il s'agissait d'une nouvelle histoire, je remettrais cela en question. Les histoires offrent une valeur client qui, pour être franc, les développeurs ne sont normalement pas les mieux placés pour évaluer (à moins qu'ils ne soient des experts du domaine). L'apparition de quelque chose dans l'itération est déterminée par la valeur de l'histoire et l'effort du développeur dans le jeu de planification. L'implication des développeurs dans la création d'histoires pourrait provoquer un conflit d'intérêts potentiel ici. Cela ne veut pas dire que cela ne pouvait pas arriver - juste que le propriétaire du produit devrait alors le défendre, sinon c'est la queue qui remue le chien.
Robbie Dee
47

La raison pour laquelle de nombreux développeurs sont "passifs", comme vous le dites, est qu'il faut une certaine connaissance et expérience du domaine avant que de bonnes idées de produits ne vous parviennent. Mais s'ils viennent, il n'y a aucune raison de ne pas les suggérer et de les défendre.

Gardez à l'esprit - les développeurs, les propriétaires de produits, les vendeurs, etc., font tous partie de la même équipe, avec le même objectif: créer un produit réussi. Travaillez vers cet objectif comme vous le pouvez.

Stefan Billiet
la source
Je pense que vous l'avez compris - j'ai atterri dans une équipe travaillant avec des technologies avec lesquelles j'ai très peu d'expérience, il est donc difficile pour moi d'être proactif. Il devra y avoir une période d'apprentissage pendant laquelle je resterai passif. Ensuite, une fois que je me sens à l'aise avec la technologie, je peux commencer à être proactif.
louniks
1
@louniks non vous manquez le point. La technologie n'est pas ce qui compte. C'est l'entreprise qui compte. Dans quelle mesure les gens d'affaires sont-ils transparents? Savez-vous comment l'entreprise a l'intention de gagner de l'argent? Êtes-vous au courant de l'adéquation du produit sur lequel vous travaillez avec les autres produits de l'entreprise? Sinon, votre employeur est injuste envers vous. Vous ne pouvez pas suggérer de fonctionnalités si vous ne connaissez pas le plan d'affaires.
RibaldEddie
3
@RibaldEddie Je ne suis pas d'accord avec la dernière partie. N'importe qui devrait être libre de suggérer des fonctionnalités. La direction et les propriétaires de produits sont toujours libres de déterminer si la fonctionnalité va n'importe où. Ne négligez pas la possibilité qu'un développeur possédant un domaine et des connaissances techniques suffisantes puisse proposer une énorme fonctionnalité rentable qui est complètement en dehors du plan d'affaires d'origine. Un propriétaire de produit peut ne jamais avoir la même idée en raison de connaissances techniques limitées.
Dan Lyons
1
Cela ressemble à une situation dangereuse: cela signifie que les gens d'affaires pour lesquels vous travaillez ne savent pas ce qu'ils font. C'est LEUR TRAVAIL d'être des experts dans ce domaine. Sinon, pourquoi sont-ils là? Sérieusement. Si les développeurs fournissent ce type d'informations, ils peuvent tout aussi bien diriger l'entreprise. Tout le reste est du gaspillage.
RibaldEddie
Vous n'avez pas toujours besoin d'une connaissance détaillée du domaine pour suggérer des améliorations techniques ...
Robbie Dee
5

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

rumtscho
la source
+1 C'est une réponse vraiment complète. Les "Conclusions" fonctionnent comme un bien TL;DR.
James Khoury
4

Oui, c'est tout à fait normal.

Il existe un modèle de travail bien connu à 80% - 20% d'innovation chez Google, où les gens consacrent 20% de leur temps à quelque chose qu'ils aiment. De cette façon, non seulement ils obtiennent de nouvelles fonctionnalités, mais de nouveaux produits et services.

Suis-je trop passif, dois-je prendre l'initiative et commencer à proposer des idées aux propriétaires de produits?

Cela dépend de votre personnalité. J'ai travaillé avec des gens vraiment passionnés, mais aussi avec des gens sans émotion qui font leur quart de 8 heures et rentrent chez eux.

BЈовић
la source
On dirait que chez Google, les développeurs passent une partie de leur temps à être propriétaires de produits.
JeffO
Les employés de Google travaillant sur leurs propres projets ne sont pas la même chose à moins que vous ne parliez d'une autre initiative?
Robbie Dee
@RobbieDee Oui, c'est ça. Ils travaillent sur leurs projets, mais google vend des services qui sortent des projets.
BЈовић
Ce que je veux dire, c'est que de tels projets ne résident pas nécessairement dans la sphère d'un projet agile existant. Ils peuvent être complètement autonomes.
Robbie Dee