Conception continue en développement: méthodologie et principe

En pratique, il arrive que vous développiez un produit et après le lancement, les clients ne l'utilisent pas comme prévu. Il s'avère alors que les tâches de l'utilisateur sont différentes et vont à l'encontre du développement de produit prévu et de votre vision du projet. Pourquoi?

En fait, vous travaillez avec une tâche utilisateur qui n'est pas entièrement comprise et qui change sous l'influence du produit. Cela suggère que le produit doit être finalisé, en outre, jumelé avec le client. Vous vous protégez donc immédiatement de la création de solutions inutiles basées uniquement sur des hypothèses.

Je pense qu'il est préférable d'établir une communication avec l'utilisateur selon le principe de la conception continue, qui sera abordé dans l'article.

Cher et douteux chaos informatique

La plupart des produits et fonctions fournis par l'informatique ne trouvent pas d'application pratique. Les ressources, applications et logiciels ne sont pas réclamés. Toutes les entreprises ne se demandent pas si leurs produits sont vraiment nécessaires.

Une preuve vivante est le marché du développement mobile, qui a des indicateurs mesurables. Bien que les meilleures pratiques soient concentrées ici, les statistiques laissent beaucoup à désirer: en 2017, la société d'analyse Localytics a publié une étude Sql , dont il s'ensuit que 24% des applications ne sont ouvertes qu'une seule fois par les utilisateurs.

Cela tient compte du fait que le pourcentage d'utilisateurs ayant ouvert l'application moins de 10 fois ne dépasse pas 63% . Si l'on prend en compte la «stabilité» des statistiques, il devient clair qu'aucune conclusion n'en est tirée. Les gens savent se développer, mais ils manquent l'aspect de la façon dont le produit entre dans la vie d'une personne, c'est-à-dire qu'ils n'utilisent pas le modèle centré sur l'humain. Ce dernier implique une interaction à long terme avec le client; généralement pendant plusieurs années.

Cela nous amène à la conclusion: dans une approche centrée sur le client, vous devez vous tourner vers des pratiques de développement existantes comme DevOps, agile ou scrum, qui sont généralement appliquées séparément. Mais si nous les combinons, nous obtenons quelque chose de plus appelé design continu. Il se compose des principes classiques du DevOps et du design thinking. Nous proposons de l'examiner et de l'adopter, mais pour mettre en œuvre le principe en cours de développement, vous devez reconsidérer la relation entre les deux composants: la conception et les opérations.

Introduction aux opérations et à la conception

Les opérations sont ce qui se passe actuellement. Cela peut être l'administration système, le support utilisateur, les processus métier. Les opérations sont construites sur différents modèles, par exemple, en utilisant les DevOps mentionnés. Il prévoit un processus de rétroaction continu, des améliorations et la livraison de solutions. Une «boucle» est créée à partir des commentaires, de la planification, de la recherche de solutions et de leur présentation. Et pour chacune des étapes, il existe des outils qui aident au travail, automatisent les processus et fournissent un échange constant d'informations et de solutions.

Le design est tout ce qui est impliqué dans la définition des actions, des méthodes de construction et des façons d'emballer un produit pour le consommateur. Habituellement, nous considérons la conception comme une solution à un problème. Si nous comprenons l'essence du problème, nous pouvons offrir la bonne solution.

Il s'agit d'une approche traditionnelle.

4 circonstances que l'approche traditionnelle ne prend pas en compte

Mais lors de la combinaison de la conception et des opérations, 4 facteurs apparaissent qui fonctionnaient auparavant séparément pour les équipes. Et pour ces aspects, la conception continue devient la solution:

# 1 Le problème ne peut pas être entièrement compris.

Avec l'aide de l'analyse et de la recherche, nous émettons l'hypothèse de la façon dont les gens utiliseront le produit, mais ils donnent une idée incomplète du problème, car nous ne pouvons pas couvrir tous ses aspects. Ce n'est que lorsque le produit tombe entre les mains du consommateur que l'on voit son utilité pour le consommateur, les tâches qu'il a aidé à résoudre ou ce qu'il a changé.

Un exemple simple: sur un jean, il y a une petite poche pour une montre. Il a été inventé par Levi Strauss en 1873. Depuis lors, personne n'a utilisé la poche pour son usage prévu. La société a même publié une vidéo entière dédiée à cela.

# 2 Le produit change de consommateur

Une expérience active d'interaction avec le produit change l'utilisateur. Et cela transforme le problème que le produit résout, ce qui crée de nouvelles difficultés pour vous et le client.

Rappelez-vous comment nous avons commandé un taxi il y a 5-6 ans: l'opérateur à l'autre bout du fil a accepté la commande et a dit que la voiture serait servie dans 20-30 minutes. Et nous étions prêts à attendre. Avec le lancement de services comme Uber, Gett et Yandex.Taxi, notre perception a changé: en 2018, le moment optimal pour livrer une voiture est de 2-3 minutes pour nous. Si nous attendons plus longtemps, cela commence à devenir ennuyeux. Et il ne s'agit pas de numérisation ou d'ubérisation, mais de changer notre modèle de consommation.

# 3 La valeur est quelque chose de créé ensemble

La valeur d'un produit ne peut être imaginée au moment de sa création. Après le lancement, le service commence à vivre sa propre vie et à acquérir une nouvelle valeur, qui se forme pendant l'utilisation. Certaines fonctions seront demandées, d'autres non. Et la valeur créée par vous et le consommateur mûrit. Par conséquent, l'utilité reste souvent non évidente jusqu'à ce qu'un bien ou un service soit utilisé.

Rappelez-vous l'AppStore, qui semblait contraire à la perception de la valeur d'Apple. En 2007, Steve Jobs a présenté l'iPhone avec les mots: «Vous n'avez pas besoin d'écrire des programmes. C'est inutile: vous avez html5. " Cela n'a pas empêché les utilisateurs: ils ont piraté des appareils et écrit leur logiciel, distribué via l'application logicielle Cydia. Il a été lancé en mars 2008 et déjà le 10 juin de la même année, les gars de Cupertino ont adopté l'expérience réussie et ont lancé l'AppStore, changeant la situation en leur faveur et devenant le numéro 1 sur le marché mobile.

Cette thèse nous amène à la conclusion que le développeur et le consommateur font partie du problème et de la solution.

# 4 La difficulté élimine le contrôle

Nous créons constamment des systèmes complexes qui ne peuvent pas être entièrement contrôlés. Et cela entraîne des échecs et des erreurs inévitables. L'un des principaux problèmes liés à l'utilisation de tels systèmes réside dans les tentatives de contrôle à trop de niveaux, lorsque vous réfléchissez soigneusement à ce qui se passera ou peut arriver.

Je suis sûr que nous avons tous une fois appelé le service client, où nous avons été redirigés de nombreuses fois vers différents opérateurs. Et encore et encore, nous avons décrit le problème et attendu une réponse à la musique de fond de l'entreprise. Ce sont des cas où le service - les opérateurs - est pensé trop attentivement. Les employés disposent d'algorithmes de communication client qui sont constamment mis en correspondance et détaillés. Au lieu de servir les intérêts des utilisateurs, ils ne font que compliquer et confondre le système. En raison de la politique de l'entreprise, un seul opérateur ne peut pas résoudre votre problème, même s'il est simple. Il doit simplement vous rediriger vers quelqu'un d'autre.

Logiciel de numérisation

Regardez l'évolution de l'iPod

Ces facteurs non comptabilisés affectent non seulement le monde numérique, mais aussi le monde physique. Il devient de plus en plus difficile d'acquérir une expérience qui ne comprend pas de composant logiciel intermédiaire. L'environnement dans lequel nous vivons est vérifié par logiciel, ce qui change la perception des choses et la façon dont nous les utilisons.

Par exemple, Tesla a publié une mise à jour logicielle qui augmente la durée de vie de la batterie de la voiture. Dans le même temps, ses caractéristiques physiques sont améliorées: vous pouvez maintenant vous rendre non seulement au supermarché ou au travail, mais aussi dans la ville voisine. Ce n'est pas le nombre de voyages et la durée du voyage qui ont changé, mais la qualité de la voiture et, avec eux, la compréhension des tâches et des objectifs de son utilisation. Maintenant, vous n'avez plus besoin de dépenser d'argent pour un taxi ou de mettre d'autres restrictions, car la batterie dure 2 fois plus longtemps. Une machine ferme toutes les tâches de son propriétaire.

La marque s'éloigne de la promesse au dialogue

Si tout est devenu plus clair avec les opérations et le design, alors un concept plus large et plus abstrait de la marque demeure. Il travaille également dans un tas de conception continue.

Nous avions l'habitude de prendre la marque comme une promesse. Par exemple, la stabilité ou l'immuabilité. Mais maintenant, sa fondation évolue vers le dialogue, car nous vivons dans un paradigme de valeurs changeantes. Et le dialogue avec l'utilisateur ne doit pas être unilatéral, il est lié à une communication constante, l'informatique est exactement l'environnement où cela se fait le plus rapidement. Après tout, nous avons des outils pour fournir une rétroaction constante à différents niveaux: des services analytiques externes aux méthodes DevOps.

L'informatique devient un environnement de dialogue continu

Nous commençons à changer le produit sans arrêt grâce aux commentaires des clients, que nous observons et dont nous analysons les actions. La boucle DevOps se ferme donc à l'infini lorsque les opérations, le développement, la conception et le marketing sont impliqués dans ce processus: nous sélectionnons une solution parmi plusieurs, la mettons en œuvre et voyons comment elle se comporte dans la pratique. C'est sous cette forme que fonctionne la conception continue.

Paradigme de conception continue

Et pour que le design devienne un dialogue fascinant, il y a 4 recommandations:

# 1 Concevoir les interactions client-employé aux points de contact

Concevez une expérience utilisateur avant de lancer un produit. Et il est nécessaire de l'étudier non seulement dans des conditions idéales lorsque le produit ou le service est utilisé correctement, mais aussi là où le client entre en contact avec des processus métier: un back office ou une architecture informatique. Concevoir une expérience basée sur l'environnement extérieur et le mode de vie de l'utilisateur permet d'identifier comment le produit et les employés avec lesquels il interagit s'intégreront dans la vie de la personne. Il précisera également quel sera le terrain d'entente avec les divisions de l'entreprise et dans quelles conditions. Vous pouvez utiliser CJM et les clients et collègues à faire pour cela.

# 2 Minimiser les retards, maximiser les commentaires

Les méthodologies de développement flexibles comme la pratique agile et DevOps fournissent plus que la vitesse et la livraison de mises à jour ou de versions bêta. En les utilisant, nous pouvons rapidement obtenir des commentaires, tester des hypothèses et ajuster les actions pour améliorer encore le produit. Nous apprenons de chaque sprint de travail ou mise à jour de produit et en tirons des connaissances tout au long du cycle de vie.

# 3 Conception pour les bugs. Faire pour étudier

Transformez les trempettes en informations qui servent vos intérêts et ceux de l'utilisateur. Les erreurs sont inévitables à toutes les étapes, qu'il s'agisse de concevoir des fonctions ou de développer une campagne marketing. Mais vous devez vous y préparer et construire une conception continue afin de pouvoir constater l'erreur dans le temps et tirer des conclusions. Il est important d'utiliser des pratiques Lean UX telles que les tests UX, les tests AV, les hypothèses, etc.

En fin de compte, une culture de travail avec les bogues et les outils qu'il crée se forme: comme Chaos Monkey ou Blameless post mortem.

# 4 Le concept de «fait» n'existe pas

Nous sommes dans une situation où le problème ne peut pas être entièrement compris et la solution en même temps le modifie. Par conséquent, l'équipe ne peut pas simplement suivre les hypothèses sur la valeur du produit et concevoir davantage l'architecture et le service informatiques. Au lieu de cela, vous devez regarder comment les produits et services fonctionnent lorsqu'ils échappent à tout contrôle. Les commentaires dans la boucle DevOps sont inutiles jusqu'à ce que les opérations et le monde extérieur influencent le processus d'amélioration du produit. Et dans ce cas, le concept de «fait» est exclu. Vous changez constamment le produit. Cela signifie que le processus se poursuit dans le système DevOps et la conception.

Travailler dans le paradigme du design continu vous apprend à réagir rapidement aux erreurs, il est plus facile de les identifier et de ne pas faire de travail inutile. Son avantage est que, étape par étape, de plus en plus de tâches clients sont fermées, ce qui apporte des bénéfices supplémentaires et a un effet bénéfique sur l'entreprise.

ps L'écriture de ce matériau a été inspirée par la performance de Jeff Sassna.