Comment nous avons commencé à publier des fonctionnalités deux fois plus rapidement (étude de cas)

Lorsque les entreprises s'appuient sur votre application pour leur travail quotidien, vous devez être suffisamment agile pour répondre rapidement à leurs besoins. Si vous ne le faites pas, d'autres le feront certainement. Dans le monde impitoyable du SaaS, retarder une fonctionnalité critique (ou précipiter un morceau de code bourré de bogues) signifiera perdre des clients. Un flux de travail agile solide peut faire toute la différence.

Nous sommes l'équipe derrière Active Collab , une application de gestion de projet avec un ensemble de fonctionnalités en constante évolution et une base d'utilisateurs importante. Cela signifie que même le plus petit changement de fonctionnalité affectera un grand nombre de personnes.

Lectures complémentaires sur SmashingMag :

• Comment déployer de nouvelles fonctionnalités sans blesser les utilisateurs fidèles
• La liste de contrôle de lancement de site Web - 15 vérifications essentielles avant de passer en direct
• Une approche centrée sur l'utilisateur de la conception Web pour les appareils mobiles
• Comment lancer n'importe quoi
  

Par conséquent, le processus de développement doit se dérouler sans heurts et selon une norme, avec des retards réduits au strict minimum. Avant qu'une modification n'arrive jusqu'à l'utilisateur final, elle passe par cinq phases cruciales : rétroaction, conception, développement, assurance qualité et déploiement . Dans cet article, je vais partager ce que nous avons appris (à la dure) sur chacune des étapes de plus de huit ans dans l'entreprise.

Un appel au réveil

Avant d'entrer dans les détails, regardons comment tout cela s'est passé. Après des années d'ajout de fonctionnalités sans examen suffisant, notre application souffrait d'un gonflement des fonctionnalités. Nous avons ajouté tellement de fonctionnalités au fil des ans que les nouveaux utilisateurs ont été intimidés par la complexité de l'interface utilisateur (pour ne plus jamais revenir). Nous savions que nous devions reconstruire à partir de zéro, même si cela impliquait de réécrire chaque fonctionnalité à partir de zéro.

Puis vinrent les retards. Les fonctionnalités des nouvelles versions étaient constamment en retard sur le calendrier. Par exemple, un développeur junior devait développer une intégration avec QuickBooks. Nous n'avons pas prédit avec précision la complexité, les compétences ou les connaissances nécessaires. De plus, il était le seul affecté à cette tâche, et personne ne pouvait intervenir rapidement pour l'aider. En conséquence, ce qui était censé être un travail de deux semaines a fini par en prendre cinq. C'étaient quelques drapeaux rouges.

Il était clairement temps de passer à une approche plus agile. Nous avons pris ce que nous aimions de diverses méthodes agiles (et pas si agiles), l'avons combiné avec l'expérience et avons créé notre propre version, qui a depuis donné d'excellents résultats.

Examinons de plus près le chemin qu'une fonctionnalité doit parcourir avant d'être proposée à l'utilisateur final.

De la suggestion à la fonctionnalité

Dans notre flux de travail, une nouvelle fonctionnalité commence à prendre forme bien avant qu'elle n'atteigne l'équipe de développement, et elle est généralement née des commentaires des utilisateurs. Ce n'est pas une coïncidence - nous avions l'habitude de publier des fonctionnalités dont personne n'avait besoin, généralement simplement parce qu'un utilisateur était particulièrement bruyant ou que nous pensions simplement que quelque chose serait formidable. Au lieu d'imaginer les fonctionnalités dont nos utilisateurs pourraient avoir besoin, nous prenons désormais des décisions en fonction de la demande réelle.

Si vous êtes dans le lean manufacturing, vous diriez que nos clients « tirent » certaines fonctionnalités en les demandant plus souvent que d'autres. Nos équipes de support et de vente jouent un rôle important dans le processus car elles sont constamment en contact avec les utilisateurs qui partagent leurs besoins et leurs idées.

Sur la base des retours, nos équipes mettent à jour un formulaire qui ressemble à ceci :

Lorsque nous ne disposons pas de toutes les informations dont nous avons besoin, nous contactons directement les clients. Cela se fait généralement au moyen d'enquêtes ciblées sur un échantillon soigneusement sélectionné. Le fait est que nous écoutons. Aucun commentaire n'est perdu pour nous. C'est toujours reconnu et documenté.

La prochaine étape est l'analyse. Nous comptons les scores chaque mois pour voir quelle fonctionnalité a obtenu le plus de votes. De plus, avec une catégorisation appropriée, nous obtenons une perspective plus large sur les parties de notre logiciel qui doivent être améliorées. Par exemple, si le calendrier reçoit de nombreuses plaintes, nous envisagerons de réorganiser toute la section, plutôt que d'introduire la fonctionnalité qui a obtenu le plus de votes (comme l'exportation du calendrier).

Cependant, même lorsque les résultats sont connus, la décision d'introduire une fonctionnalité n'est pas définitive. Avant qu'il ne figure sur notre liste de choses à faire, nous procédons toujours à un contrôle approfondi :

• Quels avantages cette fonctionnalité apportera-t-elle aux utilisateurs ?
• Cela correspond-il à notre philosophie de produit ?
• Cela ajoutera-t-il une complexité inutile?
• S'intègre-t-il bien à l'interface et aux fonctionnalités existantes ?
• Avons-nous les ressources pour le livrer dans un délai raisonnable?

Lorsqu'une fonctionnalité passe la liste de contrôle et que les Product Owners l'approuvent, il est temps de passer à la planche à dessin.

Concevoir pour l'utilisateur

L'expérience nous a appris que l'ajout d'une nouvelle fonctionnalité ne signifie pas seulement la coller au-dessus de l'interface utilisateur - vous devez la mélanger avec la conception existante, en pensant à l'utilisateur. Si vous ne le faites pas, vous vous retrouverez bientôt avec une application si complexe que seuls quelques courageux passeront les cinq premières minutes de l'essai (oui, nous y sommes allés). L'esthétique est également importante pour une bonne première impression, mais notre principale préoccupation est la facilité d'utilisation . Une fonctionnalité doit être ajoutée d'une manière qui semble naturelle à l'utilisateur.

Nous gardons les choses en perspective en demandant : où l'utilisateur s'attendrait-il à ce que cette option soit ?

Pour les utilisateurs existants, il est important que la nouvelle conception suive les modèles qu'ils connaissent et ne perturbe pas leur flux de travail. De plus, il existe des normes et des conventions de l'industrie auxquelles nous sommes tous (inconsciemment) habitués. Ne vous attendez jamais à ce que vos utilisateurs changent complètement leurs habitudes. Ils chercheront plus probablement ailleurs si l'interface n'est pas intuitive.

Prenez des raccourcis clavier. Vous pouvez créer votre propre ensemble de raccourcis et vous attendre à ce que les utilisateurs les apprennent (ils ne le feront probablement pas). Ou vous pouvez ajouter ceux que les gens utilisent déjà. Beaucoup de nos utilisateurs utilisent déjà Slack, par exemple, nous avons donc ajouté un raccourci qu'ils connaissent déjà ( Command + K pour les sauts rapides fonctionne également dans Active Collab ).

Lorsque les flux d'utilisateurs sont en place, notre designer UX modélise le design dans Sketch. Nous utilisons rarement HTML dans les premières étapes. Les visualisations Sketch bien pensées nous offrent suffisamment de flexibilité pour que nous n'ayons pas à revenir en arrière lorsque nous commençons à coder. La conception initiale finit généralement par correspondre à environ 80 % du produit final. Le reste est ajouté et ajusté en cours de route.

Une autre étape importante du processus de conception est la copie. Nos rédacteurs accordent une grande attention à chaque mot. Nous avons même notre propre guide de style, pour avoir l'air aussi accessible et facile à comprendre que possible. Par exemple, dire "certificat de sécurité" au lieu de "certificat SSL" transmet en termes simples quelque chose qu'un utilisateur moyen pourrait ne pas connaître.

Lorsque tout cela est fait, la fonctionnalité est attribuée à une équipe de développement. L'équipe est composée d'un chef de projet, d'un développeur principal et de plusieurs développeurs back- et front-end, selon la charge de travail. Le chef de projet s'assure que tout se passe bien et dans les délais, tandis que le développeur principal s'occupe de l'aspect technique des choses. Ils coordonnent et encadrent également les développeurs juniors.

Il est temps de lancer les choses

Nos réunions de lancement ne sont pas des réunions de motivation ennuyeuses. Ce sont des opportunités pour une équipe de développement (composée de développeurs juniors et seniors) de rencontrer le chef de projet et le propriétaire du produit.

Au lieu d'autoriser les monologues vides, nous nous concentrons sur la mise en œuvre des mots de chacun dans des tâches concrètes. Tout au long de la journée, trois rendez-vous importants ont lieu :

• Le propriétaire du produit présente la fonctionnalité donnée à l'équipe, les idées qui la sous-tendent, les conceptions initiales et les résultats attendus.
• Ensuite, l'équipe a sa propre réunion au cours de laquelle elle discute du plan d'action, des problèmes potentiels et du calendrier des tests.
• La réunion finale réunit toutes les personnes impliquées et le plan prend sa forme définitive. À la fin de cette réunion, l'équipe donne des estimations pour les démos et une date d'échéance finale.

Trois réunions peuvent sembler beaucoup pour une journée, mais c'est ainsi que nous nous assurons que les problèmes sont résolus dès le début. Remplir les blancs à ce stade permet à nos développeurs de gagner beaucoup de temps, de faux départs et de retours en arrière. Les réunions encouragent également le travail d'équipe et donnent à chacun le sentiment que ses contributions sont les bienvenues.

Après les réunions, l'équipe disposera de toutes les informations nécessaires :

1. Quoi? C'est la portée de la fonctionnalité et comprend tout ce qui doit être fait, ainsi que les bloqueurs et les goulots d'étranglement potentiels. Nous essayons d'anticiper autant de scénarios et de cas extrêmes que possible. Les prédire tous n'est pas facile; elles reviennent souvent au fur et à mesure.
2. Pourquoi? Le propriétaire du produit estime la valeur commerciale d'une fonctionnalité et explique pourquoi cela en vaut la peine. De cette façon, l'équipe obtient une image claire des avantages pour les clients et le produit. La principale motivation ici est que chacun doit comprendre pourquoi son travail est important et comment il contribue à l'entreprise dans son ensemble.
3. Comment? En décrivant les étapes nécessaires pour compléter une fonctionnalité , nous nous assurons que nos développeurs ne perdent jamais leur boussole. Nous définissons également des attentes réalistes en ajoutant une balise de complexité. Nous avons opté pour des tailles de t-shirts - S peut être résolu en quelques heures, tandis que XXL prend des semaines ou plus.
4. OMS? Le chef d'équipe est chargé de terminer une fonctionnalité ou une tâche à temps et d'informer le propriétaire du produit de l'avancement. Les autres membres de l'équipe sont affectés à leur propre ensemble de sous-tâches, de sorte qu'il est parfaitement clair qui est responsable de quoi. Garder cela aussi transparent que possible nous aide à voir si quelqu'un a des difficultés ou cause des retards.
5. Quand? Avec tout pris en compte, une date d' échéance est estimée . Si une tâche est retardée, nous analysons les raisons et utilisons cette expérience la prochaine fois. De cette façon, une échéance manquée devient une opportunité d'apprentissage et non une source de stress.

La journée de lancement peut être mouvementée, mais elle est également très fructueuse. Chacun apporte ses idées et ses commentaires. Une tâche se transforme d'une ardoise vide en un hub pour les commentaires, les modifications et les mises à jour. À la fin de la journée, l'équipe de développement a une image claire du travail à venir et une base solide sur laquelle s'appuyer.

Nous passons en revue cette liste de contrôle avant de commencer le travail :

• fonctionnalité expliquée,
• les étapes de réalisation décrites,
• valeur commerciale attribuée par le propriétaire du produit,
• complexité assignée par équipe,
• dépendances de fonctionnalités et de bogues identifiées,
• critères de performance identifiés (si besoin),
• démos programmées,
• dates de début et de fin fixées par le chef d'équipe.

C'est le moment où une tâche passe dans la colonne "En cours".

C'est l'heure du codage !

Travail d'équipe à l'affiche

Nos développeurs ne travaillent jamais seuls - c'est toujours un travail d'équipe et c'est de loin le moyen le plus efficace de publier de nouvelles fonctionnalités. Avant que les équipes ne soient introduites, un développeur (junior) se retrouvait coincé avec un problème et pouvait tourner en rond pendant des jours (sans que personne ne s'en rende compte). Ou, s'ils n'étaient pas du genre solitaire, ils distrairaient constamment leurs collègues et leurs managers.

D'autre part, avec les équipes, nous mélangeons des personnes ayant des compétences et des niveaux d'expérience différents. Cela signifie que chacun se voit attribuer un ensemble de tâches adaptées à son niveau. De plus, les seniors ont l'avantage d'apprendre à gérer et à entraîner des coéquipiers juniors - et les juniors peuvent demander de l'aide. Comme il s'agit d'un travail d'équipe et que tout le monde travaille vers le même objectif, les questions ne sont pas considérées comme des distractions et l'équipe peut s'attaquer à n'importe quel problème beaucoup plus efficacement. L'équipe devient une entité auto-organisée, divisant le travail en phases (ou sprints) et présentant son travail lors de démos.

Montrer et dire

Selon le calendrier, l'équipe fera une démonstration pour le propriétaire du produit. Le but des démos est de montrer à quel point une fonctionnalité fonctionne dans son état actuel et où elle a besoin de plus de finition. C'est une confrontation avec la réalité qui ne permet pas d'excuses telles que « Il a juste besoin de quelques touches finales » (touches qui prendraient encore un mois). De plus, si les choses commencent à mal tourner, les Product Owners peuvent réagir rapidement.

Réunions hebdomadaires

Nous avons commencé par de courtes réunions quotidiennes régulières auxquelles assistaient tous les développeurs. Chaque développeur décrirait brièvement ce sur quoi il travaillait, ses problèmes, ses blocages et s'il avait besoin d'aide. Il est rapidement devenu évident que ces réunions devaient être plus ciblées et fournir des résultats tangibles. Nous sommes donc passés à des réunions avec des équipes individuelles environ une fois par semaine. C'est ainsi que les propriétaires de produits et le chef de projet sont tenus au courant et que tous les problèmes potentiels sont traités sur place.

Le mettre à l'épreuve

Le code est écrit, les démos ont été réussies, tout semble bien se terminer… jusqu'à ce que vous libériez la fonctionnalité et constatiez que l'application plante. C'est pourquoi chaque fonctionnalité que nous créons passe par l'assurance qualité (Q/A). Toujours. Notre testeur passe méticuleusement en revue tous les scénarios possibles, vérifiant toutes les options et exécutant des tests dans différents environnements. Une fonctionnalité passe rarement Q/A du premier coup.

Pour augmenter la productivité, nous avions l'habitude de laisser les développeurs démarrer sur de nouvelles fonctionnalités pendant cette phase, mais cela n'a entraîné que de nombreuses fonctionnalités retardées et à moitié terminées. Donc, maintenant, l'équipe de développement s'occupe en travaillant sur de petites tâches de maintenance pendant que leur fonctionnalité est en cours d'examen. Si Q/A trouve un problème, les développeurs le corrigent immédiatement et le soumettent à nouveau. Le processus est répété jusqu'à ce que la fonctionnalité réussisse les questions/réponses et passe à la révision du code.

C'est à ce moment qu'un développeur senior s'assure que le code est écrit conformément à nos normes. Une dernière étape avant la publication consiste à rédiger la documentation - vous ne voulez pas être submergé par les e-mails d'assistance après avoir publié une fonctionnalité que personne ne sait utiliser. Nos rédacteurs mettent également à jour les notes de publication et rédigent des supports marketing, tels que des annonces par e-mail et des articles de blog.

Voici notre définition de "fait" :

• auto-tests écrits,
• Q / A fait et toutes les tâches résultantes terminées,
• révision du code effectuée et code fusionné pour maîtriser,
• notes de version mises à jour,
• dépendances de fonctionnalités et de bogues identifiées.

La tâche a atteint l'étape finale, appelée "Release Q".

Jour de la sortie

Lors du choix d'un jour pour les nouvelles versions, nous avons immédiatement décidé contre le vendredi et le lundi. Le vendredi n'est pas bon car les problèmes potentiels ne seraient pas résolus avant le lundi ; De plus, l'équipe d'assistance était déjà très occupée à l'époque. Le lundi n'est pas le meilleur moment car toute mise à jour majeure nécessite une préparation, qui devrait être effectuée le week-end. Il est toujours bon de laisser une journée pour les dernières retouches. Cela réduit les options à trois jours – et nous sommes allés avec mardi. Voici pourquoi:

• Nous avons lundi pour revoir la version et apporter les touches finales avant le déploiement.
• S'il y a des phrases non traduites (notre application Web est disponible en sept langues), nous avons suffisamment de temps pour terminer la traduction.
• L'équipe marketing a tout le temps d'envoyer des newsletters et des annonces via les réseaux sociaux.
• Nous sommes disponibles pour fournir une assistance de mise à niveau rapide et efficace pour le reste de la semaine.
• Si un délai est dépassé pour quelque raison que ce soit, nous avons encore mercredi ou jeudi pour terminer les travaux.

Journée d'activités gratuites

Le lendemain d'une version majeure est une journée libre pour l'équipe. C'est à ce moment qu'ils acquièrent de nouvelles compétences ou font quelque chose lié au travail qu'ils trouvent intéressant. Même si tout le monde est impatient de savoir quelle fonctionnalité nous lancerons le lendemain, l'équipe n'en parle pas encore. Au lieu de cela, ils se détendront et regarderont peut-être une présentation sur l'histoire d'Erlang, ou finiront de lire cet article expliquant pourquoi PSR-7 et le middleware sont importants pour le développement PHP moderne, ou auront leur propre discussion rétrospective. C'est une journée bien méritée pour recharger leur batterie et célébrer un travail bien fait.

Journée de chasse aux insectes

Outre le développement de nouvelles fonctionnalités majeures, il y a toujours du travail à faire sur celles qui existent déjà. Qu'il s'agisse d'une correction de bogue, d'une mise à jour de conception ou d'un petit changement de fonctionnalité, l'équipe doit s'en occuper dans un délai raisonnable.

C'est pourquoi nous avons des journées de chasse aux bogues au moins une fois par mois. C'est le moment où tous les développeurs arrêtent de travailler sur leurs projets principaux et se tournent vers la maintenance. Cet effort ciblé s'est avéré être un grand succès. Lorsque tout le monde travaille uniquement sur des bogues le même jour et est disponible pour s'entraider, l'équipe résout un grand nombre de problèmes.

Quel est le résultat?

La publication d'une grande fonctionnalité prend désormais environ trois semaines en moyenne, du lancement au développement, aux tests, à la révision du code, à la documentation et à la version finale. Une fonctionnalité de complexité équivalente nous prenait autrefois 45 jours. De notre point de vue, c'est une augmentation de 100 % de la productivité . Nous l'avons accompli avec les mêmes ressources et personnes, la seule différence étant un flux de travail amélioré.

Donc, si nous avons une chose à retenir pour vous, c'est celle-ci : Entretenir une culture d'entreprise qui élimine la peur du changement rendra votre équipe meilleure dans ce qu'elle fait. Que vous l'appeliez Scrum, Kanban ou Lean n'a pas d'importance, tant que cela aide votre entreprise à se développer. L'expérimentation et l'innovation sont au cœur de toute approche agile. N'ayez pas peur de tester différentes solutions, de mesurer les résultats et, en fonction des résultats, de modifier les pratiques existantes. De bons résultats suivront.