Libérez tôt : un cas pour un Strong 1.0

Je ne suis pas fan du mantra "bouger vite et casser les choses" que Facebook avait l’habitude de tenir et je ne pense pas qu’il y ait une raison de devoir justifier mon opinion à ce sujet. Je suis content qu’ils se soient éloignés de ça (ou semblent avoir – je ne sais pas ce qu’ils font en interne).

Je suis, cependant, un fan de l’idée "Release Early". Parfois, cela est également associé à «Release Souvent», nous obtenons donc la phrase presque tristement célèbre «Release Early, Release Souvent» dans la nomenclature du développement logiciel.

Je ne pense pas nécessairement qu’ils doivent aller ensemble.

Mais quand il s’agit de l’idée de «Release Early », il semble que peu importe ce que vous publiez, si ce n’est pas à la hauteur des attentes d’un client, alors ce n’est pas bon.

Et je comprends. Du moins de ce point de vue.

Mais que se passe-t-il si vous êtes un développeur de logiciels et que vous avez une idée de la façon dont ce genre de choses fonctionne ?

Libérer tôt

Le catalyseur de cet article est que Spotify a récemment publié une application Apple Watch. Leur première version est une télécommande pour l’application qui s’exécute sur votre téléphone. Ce n’est pas la première application Apple Watch à le faire.

Autrement dit, ce n’est pas la première application de ce type à avoir sa première version "rien de plus" qu’une télécommande pour l’application principale sur le téléphone.

Il semble cependant y avoir plus de critiques autour de ce produit particulier. Je ne peux que supposer que c’est parce que la montre n’est pas au même endroit qu’elle était autrefois, donc les attentes des gens sont plus élevées.

Mais je n’ai pas forcément le même avis. Donc, avant de partager mes raisons, je tiens à clarifier :

• Je suis un fan inconditionnel de Spotify. C’est de loin mon service musical préféré.
• La capacité cellulaire de l’Apple Watch est ce qui m’a permis d’en obtenir un, car la possibilité de sortir et d’être détaché de mon téléphone pour un rendez-vous, pour une course, pour une course, etc. a été formidable.

Enfin, d’autres applications ont également emprunté cette voie. C’est-à-dire qu’ils ont d’abord opté pour l’application «glorified remote», puis ont continué à itérer à partir de là.

Et c’est là que je remets en cause certaines critiques.

Deux types d’applications

À un niveau fondamental, je pense que cela peut être réduit aux attentes des clients et je pense que celles-ci peuvent être séparées en deux catégories :

1. Demandes d’accompagnement. Pensez à ce sont vos applications distantes qui aident à contrôler l’application principale en cours d’exécution sur un autre appareil iOS.
2. Applications entièrement développées (faute d’un meilleur terme). Considérez-les comme des applications complètes qui ne dépendent d’aucune autre application mais qui peuvent partager des données à un moment donné (via une connexion sans fil, une connexion LTE, etc.).

Et c’est là que les attentes des clients varient.

Cela n’implique pas un manque de polonais

Lorsqu’une application est publiée sur l’Apple Watch, nous avons commencé à nous attendre à ce qu’elle soit à égalité avec son homologue iOS. Je pense que cela est dû en partie à la puissance des montres (et watchOS) ainsi qu’à ce que nous attendons des différentes applications mobiles que nous avons.

Deuxièmement, je pense que plus une certaine technologie est disponible depuis longtemps, plus les applications "entièrement développées" courantes (par rapport aux homologues distants ou aux applications compagnons) sont attendues. Cela signifie que lorsque vous publiez une application compagnon, vous vous préparez automatiquement à la critique.

Mais la critique n’est pas intrinsèquement mauvaise (ni bonne). La manière de critiquer, bien sûr, la critique est neutre en ce qui me concerne.

De plus, si la première version d’une application est une application compagnon, cela ne signifie pas qu’elle n’est pas peaufinée. Cela signifie simplement qu’il est connecté à l’application iOS principale. Et, à mon avis, c’est correct pour une première version. J’ai longtemps défendu ce que j’appelle un 1.0 fort.

Vous pouvez avoir une première version bien développée et raffinée qui n’est pas "riche en fonctionnalités" et qui n’est pas non plus un mauvais logiciel. S’il s’agit d’une application bien conçue, cela ne donne-t-il pas aux développeurs la possibilité d’évoluer vers le haut ?

Avoir un retour

En ce qui me concerne, publier une version 1.0 forte est une décision intelligente car elle montre :

• le niveau de finition actuel de votre application,
• la direction que vous envisagez de prendre le produit,
• recueillir les retours et avis des utilisateurs,
• et préparez-vous à aller de l’avant.

Bien sûr, comme je l’ai mentionné précédemment, vous allez vous ouvrir à toutes sortes de critiques, mais cela n’a pas d’importance à quel point votre application est riche en fonctionnalités. Tout va être ouvert à la critique et il va la recevoir.

Ce qui compte, c’est ce que les développeurs font des commentaires. Et d’une manière générale, je pense que les développeurs prendront en considération les critiques réfléchies lorsqu’ils itéreront sur leur logiciel.

Itérer et recommencer

Au fur et à mesure que les développeurs continuent d’itérer sur leur produit, ils vont [espérons-le] créer un meilleur produit. La plupart du temps, c’est ce que j’ai vu se produire.

J’ai même l’impression que certaines entreprises ont une application riche en fonctionnalités, suppriment des fonctionnalités, puis reviennent avec des fonctionnalités précédemment supprimées car le système d’exploitation de l’appareil a changé. (Exemple, couvert .)

Quoi qu’il en soit, l’idée de rejeter un produit après sa première version s’il ne répond pas à vos attentes peut être une réaction instinctive. Je ne pense pas qu’il soit correct de supposer que la première version est la version principale. Je ne pense pas non plus qu’il soit mal d’être déçu.

En termes simples, je pense que c’est une opportunité pour les développeurs de proposer une application compagnon bien conçue, de recueillir des études de marché, puis de poursuivre le développement et de répéter le processus.

Tous les produits ne sont pas identiques

Bien sûr, tous les produits ne sont pas identiques. Prenez Audible, par exemple. Ils étaient complètement stagnants en ce qui concerne l’Apple Watch malgré le fait que les gens écouteraient absolument des livres audio sans leur téléphone.

D’accord, donc ils ne sont pas sortis plus tôt.

Ensuite, ils ont publié une application entièrement développée. Cependant, il a fallu plusieurs versions de l’Apple Watch pour le faire. Mais c’est la voie qu’ils ont choisie. Et c’est bien.

Mais si vous allez être celui qui critique les applications compagnons, je pense qu’il est normal de demander :

• préférez-vous avoir une application entièrement développée publiée des années après la sortie de l’appareil principal,
• préférez-vous qu’une application compagnon soit publiée et itérée rapidement ?

Bien sûr, il y a au moins un autre choix, non ? Ce n’est pas un vrai dilemme.

• Souhaitez-vous voir une application entièrement développée publiée dès la sortie de l’appareil ?

Je suis sûr que beaucoup d’entre nous préféreraient ce dernier mais nous sommes, en tant que développeurs, limités par les systèmes dans lesquels nous travaillons. Il faut donc s’en souvenir.

Ce ne sont que des réflexions

En fin de compte, tout ce qui précède ne sont que des réflexions sur l’état du marché de watchOS et certains des commentaires que j’ai vus. Je pense que les attitudes peuvent se traduire sur tous les marchés de logiciels, bien que je ne sache pas nécessairement comment je le ferais pour le moment dans le cas de WordPress.

Quoi qu’il en soit, je trouve que regarder comment les autres se comportent vis-à-vis de ce type de logiciel et de l’économie dans laquelle il existe est une opportunité d’apprendre à fonctionner efficacement dans un logiciel.

Si rien d’autre, cela renforce simplement l’idée que vous ne pouvez pas plaire à tout le monde tout le temps, mais vous pouvez certainement plaire à beaucoup de gens la plupart du temps. Et c’est peut-être le meilleur objectif que nous puissions viser.

Peut-être que j’aurai des réflexions supplémentaires à ce sujet plus tard, cependant. Cela semble être le cas.