Il n’y a pas de taille parfaite pour une boucle de rétroaction

Plus je rédigeais cet article, plus j’avais l’impression que je devais écrire une sorte de TL; DR pour certaines personnes qui liraient ceci. Donc, dans un effort pour gagner du temps, voici:

J’écris ceci pour ceux qui sont nouveaux dans le travail indépendant, la gestion de projet ou qui ont généralement moins d’expérience que ceux qui demandent "Pourquoi écrivez-vous ceci?" En fin de compte, c’est quelque chose que la plupart d’entre nous apprennent à un moment donné dans ce l’industrie, mais si nous pouvons nous entraider pour le raccourcir le plus tôt possible, nous en bénéficierons tous.

Si vous êtes toujours intéressé après avoir lu la note ci-dessus, je suppose que vous cherchez à vous améliorer dans cet aspect de la communication. Ce qui est bien, car moi aussi 😏, et utiliser une petite boucle de rétroaction est un moyen que j’ai trouvé pour le faire.

---

Chaque industrie a son propre jargon et beaucoup d’entre nous en rions, mais nous continuons tous à l’utiliser dans un cadre professionnel. On est marrant comme ça.

Quoi qu’il en soit, dans notre industrie, l’une des expressions que nous utilisons beaucoup – moi y compris – est "boucle de rétroaction". La première fois que j’ai rencontré cette expression, c’était en ce qui concerne le retour des amplificateurs. Cela n’avait rien à voir avec le logiciel. Néanmoins, dans ce que nous faisons, nous l’utilisons généralement pour l’appeler :

• envoyer une demande, un commentaire ou une information générale à un client,
• recevoir une réponse du client concernant lesdites informations.

Et pour ceux qui ne sont pas habitués à l’idée (parce qu’il y a ceux qui font des "big bang releases" dont je parlerai dans une minute), les boucles de rétroaction sont généralement considérées comme petites ou grandes.

Plus j’ai travaillé longtemps dans le logiciel, plus je vise toujours Une petite boucle de rétroaction quoi qu’il arrive.

La boucle de rétroaction parfaite

Une petite boucle de rétroaction signifie qu’il y a une communication fréquente entre une entreprise et le client (donc, naturellement, une grande boucle de rétroaction se produit lorsqu’il y a une communication moins fréquente).

Si vous comptez utiliser du jargon, pensez-y au moins d’une manière amusante, n’est-ce pas ?

Mais vous savez tout ce truc de jargon que j’ai mentionné au début de l’article? En conversion normale, je dirais simplement :

Quand il s’agit de travailler sur un projet, je préfère une communication plus fréquente.

Et la raison pour laquelle je préfère cela et même par défaut est que lorsqu’il s’agit de créer une solution, quelle que soit sa taille, pour quelqu’un d’autre, il y a toujours des éléments mobiles à prendre en compte.

Lorsqu’il y a plusieurs parties dans un projet, il y a plusieurs points d’endroits où quelque chose pourrait avoir besoin d’être peaufiné ou changé (ou qui peut avoir un impact sur le système global) et bien faire les choses tôt plutôt que plus tard permet d’économiser beaucoup de temps (et donc d’argent) et stress pour la plupart des parties impliquées.

Et alors?

Pourquoi s’embêter à écrire à ce sujet, cependant? Pour moi, la raison en est que plus je dirige une petite boutique, plus j’entends les clients parler des problèmes liés au manque de clarté, de communication et de gestion de projet dans les projets précédents.

Dommage. Je ne veux pas exécuter ce type d’opération. C’est donc une chose facile à réparer, n’est-ce pas ?

De plus, l’industrie du développement est remplie de personnes qui prendront les exigences d’un projet, supposeront qu’elles comprennent tout ce qui est nécessaire et reviendront ensuite seulement pour avoir construit quelque chose qui non seulement manque la cible, mais qui ressemble un peu à ce que le client avait prévu.

Ce n’est pas nécessairement un coup dur pour les programmeurs, mais tout ce "[manquer] la cible" peut être corrigé si nous communiquons simplement avec ceux avec qui nous travaillons un peu plus souvent qu’autrement.

Ne supposez pas que vous savez ce qu’ils veulent.

Au lieu de cela, posez des questions, clarifiez l’exigence, travaillez sur la fonctionnalité, puis présentez-la au client dans un environnement de mise en scène. Ils sauront si vous avez construit ce qu’ils ont demandé. Si tel est le cas, passez à la fonctionnalité suivante. Sinon, il y a plus de travail à faire. Ce mode de fonctionnement rationalise une grande partie des points de tension qui surviennent dans les projets.

Et oui, poser beaucoup de questions peut devenir fastidieux voire agaçant. Grosse affaire. Mentionnez dès le départ que vous allez poser beaucoup de questions pour bien comprendre le problème avant d’essayer de le résoudre. Donnez une raison pour laquelle vous faites ce que vous faites. Cela a tendance à bien rapporter.

Sorties Big Bang

Plus tôt dans l’article, j’ai mentionné les « versions big bang » et cela fait généralement référence à l’idée qu’un client vous fournit des exigences, vous revenez travailler dessus pendant des semaines, puis revenez et dites « Hé, je J’ai terminé – jetez un coup d’œil !" seulement pour découvrir que c’est loin.

Si je devais contextualiser cela dans un type de boucle de rétroaction, je dirais qu’il n’y en a pas. Ce n’est même pas un grand parce qu’aucune rétroaction n’a été sollicitée. C’est simplement :

• Voici les exigences du projet,
• J’en ai fini avec le projet.

Souvent, cela conduit les développeurs à mal comprendre les exigences, les clients étant dans l’ignorance des progrès et le projet global allant vers le sud. Autrement dit, ne le faites pas de cette façon.

La taille parfaite ?

Je ne sais pas quelle est la taille parfaite d’une boucle de rétroaction. Il y a des clients avec qui j’ai travaillé où il y a des enregistrements quotidiens, il y a quelque part où il y a des enregistrements hebdomadaires, et il y en a qui ont dit "complétez simplement ceci et faites-moi savoir quand vous avez terminé".

Les check-ins hebdomadaires, les commits, les releases, etc. ont tendance à être mes préférés, mais c’est à cause de la taille du projet et de la taille de l’équipe avec laquelle je travaille. Le quotidien n’est pas mal non plus selon la tâche.

Je ne fais jamais le style big bang même si un client dit que ça va. J’aime toujours avoir des points de contrôle pour ma propre santé mentale. Ainsi, quel que soit le type de boucle de rétroaction qui fonctionne le mieux pour vous, votre équipe et votre client, il sera de la taille idéale.