Un produit axé sur les développeurs est-il une bonne chose?

Je travaille dans une entreprise où le PDG gère l'équipe produit, qui fait des maquettes de fonctionnalités et dépose sur les genoux des développeurs pour ensuite implémenter lesdites fonctionnalités. Il y a une certaine itération bien sûr, les opinions des développeurs sont respectées. Mais je me demande à quel point ce processus est efficace.

Jason Calacanis vient d' écrire :

La doctrine Zuckerberg: les développeurs conçoivent des produits avec une vitesse et des fonctionnalités considérablement améliorées par rapport aux chefs de produit et aux concepteurs, l'emportant sur les erreurs et les inconvénients potentiels.

...

Ensuite, cela m'a vraiment frappé: les startups axées sur les développeurs produisent toujours des produits plus rapidement.

Cela va de soi: nos non-techniciens ont des discussions et des débats pendant que Zuckerberg code son prochain long métrage. C'est pourquoi personne n'a pu suivre Facebook!

Alors que MySpacers a débattu de la façon d'itérer sur leur produit, Facebook a simplement essayé des trucs.

Est-ce que cela fonctionne mieux en pratique?

Les produits doivent être axés sur le client.

Si vos clients sont des développeurs de logiciels et que vous utilisez votre propre produit (ce que vous devriez dans tous les cas), je suppose que vous pouvez être votre meilleur client.

Mais en tant que développeur, votre point de vue est déjà compromis par ce qui se passe sous le capot. Vous avez besoin que le client vous dise que ce que vous faites avec l'interface utilisateur ou le flux de travail de l'application est maladroit et n'a aucun sens.

En tant que développeur, vous devez connaître les bonnes questions à poser aux parties prenantes afin de pouvoir combiner votre expérience avec leurs souhaits pour produire le meilleur produit possible.

En tant que développeur, j'aimerais penser que nous faisons un meilleur travail que les gestionnaires et les concepteurs. Mais je ne pense pas que vous puissiez généraliser.

L'un des problèmes rencontrés par les développeurs lors de la conception est qu'ils peuvent ne pas être en contact avec les besoins des utilisateurs finaux et ne pas être capables de poser les bonnes questions aux bonnes personnes. Un manager, et en particulier un bon designer, peut mieux comprendre cela.

Cependant, je pense que la chose la plus convaincante n'est pas les gens mais la façon dont ils abordent, ils abordent le problème. L'approche qui fonctionne est de descendre et de mettre en œuvre des choses, plutôt que de passer des réunions sans fin et d'abattre des arbres pour arriver à la conception «idéale». C'est vraiment l'Agile versus Waterfall revisité.

(Il devrait être clair que Facebook est un exemple de la façon de NE PAS faire les choses aussi. Par exemple, leur approche cavalière des problèmes de confidentialité commence à leur causer des problèmes juridiques ...)

À mon humble avis, je dirais que vous avez partiellement raison. Cela semble raisonnable. Mais cela peut ne pas s'appliquer à tous les produits / logiciels. Donc, je le dirais de cette façon. Un concepteur doit être une personne ayant une grande expérience du développement à son actif ET pas seulement - la personne doit toujours coder et pas seulement concevoir.

Réponse courte: parfois.

Réponse longue: le développement axé sur le client fonctionne si vous savez qui sont vos clients et s'ils savent ce qu'ils veulent.

Le développement axé sur les développeurs a du mérite pour les personnes qui ne réalisent pas qu'elles le trouveront encore utile. En d'autres termes, les clients ne savent parfois pas toujours ce qu'ils veulent. De nouvelles exigences peuvent provenir d'une expérience existante de la façon dont un produit existant est déficient. Il n'y avait pas de clients pour Facebook, Zuckerberg a créé un produit, une réponse avant la question. Désormais établi, Facebook est influencé par ses clients, mais avant sa création et pendant sa création, c'était une idée axée sur les développeurs.

Le développement axé sur le client est idéal pour les produits établis, peut-être matures, qui font de l'argent ou de nouvelles itérations du produit sur le même marché, où ignorer les souhaits du client serait très préjudiciable aux flux de revenus futurs.

Le développement axé sur les développeurs est une activité secondaire de prototypage, relevant de l'arène Google 20%, où leurs développeurs consacrent 20% de leur temps de travail à leurs propres projets.

Pour concevoir un bon produit, vous avez besoin de beaucoup de connaissances sur le domaine problématique. Un produit grand public comme Facebook peut être piloté par les développeurs, car il résout également un problème que les développeurs ont: comment se connecter et rester en contact avec des amis, etc. Cela est encore plus vrai pour les produits destinés aux développeurs de logiciels: les développeurs savent quoi un IDE devrait faire et comment.

Mais pour de nombreux autres domaines problématiques, les développeurs n'en savent souvent pas assez. Même avec un aperçu général et une certaine expérience, ils auront souvent tendance à implémenter des fonctionnalités intéressantes ou des fonctionnalités faciles à implémenter, mais n'ajoutent pas beaucoup de valeur pour le client et rendent le produit plus complexe. Ce sont des cas où les produits doivent être pilotés par des experts du domaine.

Je pense que c'est clairement la meilleure approche pour un produit orienté développeur (comme AWS ou Visual Studio), mais je ne suis pas sûr que c'est clairement la meilleure approche en général. Je veux dire, j'ai l'habitude de voir les choses se produire dans l'autre sens: les développeurs discutent de la meilleure approche tandis que les personnes non techniques prennent rapidement des décisions. Personnellement, je suis enclin à dire que la bonne réponse se situe quelque part au milieu. Il devrait y avoir un chef de produit capable de définir une direction générale que les développeurs mettront ensuite en œuvre.

Dans la plupart des cas, les logiciels pilotés par les développeurs peuvent être meilleurs que les logiciels pilotés par les gestionnaires. Le gestionnaire voit le plus de valeur dans les fonctionnalités (principalement les fonctionnalités de mots à la mode) qui semblent bonnes sur une annonce ou peuvent être utilisées dans un discours. Les développeurs voient différentes valeurs: performances, moins de bugs, lean design, maintenabilité. Cela conduit presque à de meilleurs logiciels.

Mais le meilleur serait un logiciel axé sur l'utilisateur. Les utilisateurs savent vraiment ce dont ils ont besoin, ce qui les aide à faire leur vrai travail. Ce serait l'idéal.

Et si vous produisez des produits plus rapidement que personne ne veut les utiliser?

Se concentrer sur un seul attribut (fonctionnalité, délai de mise sur le marché, prix, qualité, etc.) peut avoir un sens pour un certain moment. Par exemple, Apple a précipité l'iPhone et l'iPad hors de la porte. La qualité a un peu souffert mais c'était très important d'être le premier.

Je pense que cela vous fait mal, si vous vous concentrez sur un seul aspect à long terme.

NON, sauf si cela résout un problème du monde réel

• Les programmeurs aiment généralement résoudre des problèmes, parfois des problèmes qui n'existent pas encore :)
• Les programmeurs font généralement de terribles interfaces graphiques, car c'est une pensée secondaire
• La plupart des problèmes utilisateur ne sont pas les mêmes que les problèmes de programmation .
• Ainsi, un produit piloté par un programmeur sera généralement bon pour d'autres programmeurs, mais pas aussi bon pour les utilisateurs.

Également une note sur le face-book:

Le succès des face-books n'a rien à voir avec ses mérites techniques, c'est plutôt une idée de ferroutage qui vient de prendre vraiment de l'ampleur et de faire boule de neige. Face-book et al ne se produisent qu'une fois dans une "Google Blue Moon".

Pourtant:

• Si un programmeur a un vrai problème "utilisateur", qui n'est pas un problème programmeur. Alors c'est probable que c'est une très bonne chose. Si la partie prenante est également le développeur , par rapport au problème, c'est une situation idéale pour une excellente solution de produit.

(Oh mon Dieu ... où ai-je juste lu quelque chose comme "J'ai une excellente idée! Tout ce dont j'ai besoin, c'est d'un développeur." C'était dans une semaine, je pense. Quoi qu'il en soit ...)

Les bonnes idées sont un sou une douzaine. La mise en œuvre de la chose est ce qui compte. Si le développeur est celui qui a la bonne idée, il peut simplement l'implémenter.