C’est seulement un changement mal managé.
No such thing as scope creep
http://www.mindtheproduct.com/2016/12/no-such-thing-as-scope-creep/ par Jessica Hall et Jeff Nielsen
Cela commence par “Pourriez-vous juste … ?”, “En ce qui concerne …” ou “ne me tuez pas, mais … ?”. Ce qui vient est ensuite une nouvelle idée, fonctionnalité, ou demande qui n’a pas été abordée auparavant. Cette conversation arrive tout le temps et cause beaucoup de bougonnement sur “la dérive de contenu”.
Mais si vous considérez l’étude et la découverte comme étant des parties naturelles du processus de développement de logiciel, il n’existe pas de dérive de contenu. C’est seulement un changement mal managé.
Nous ne savons pas de quoi nous avons besoin quand nous commençons. De nouvelles choses surviennent toujours . Le client a besoin de changement. Le marché force le changement. Des personnes à l’extérieur de l’équipe trouvent de nouvelles idées. Les gens dans l’équipe ont de nouvelles idées. Ce changement constant est la seule chose sur laquelle nous pouvons compter. Donc arrêtons de feindre de pouvoir l’arrêter et améliorions-nous dans bien le manager.

Appréciez l’apprentissage
Un des problèmes avec la terminologie « dérive de contenu » est qu’elle implique que nous n’avons pas fait assez bien notre travail. Elle implique que quelqu’un, quelque part, a failli et si nous étions de meilleurs managers, ce ne serait pas arrivé. Nous aurions prévu toutes les demandes possibles ou nous aurions la force ou la capacité de dire « Non » à chaque fois quelqu’un a une nouvelle idée. Elle implique que la dérive de contenu est un monstre effrayant qui doit être tenu éloigné par un chef de produit toujours vigilant qui garde jalousement la porte de grange.
Cela décourage le changement et l’apprentissage. Une des leçons du mouvement de développement de logiciel Agile est qu’il n’y a aucune façon fiable de spécifier à l’avance ce que nous devons construire. Apprendre sur les besoins est nécessaire pour pouvoir converger sur une solution idéale.
L’équipe de développement doit apprendre ce qui est possible en fonction des contraintes des outils et de la technologie disponible. Les chefs de produit doivent valider leurs suppositions sur quelles fonctions ou technologies particulières sont les plus susceptibles de répondre à un besoin, tandis que les consommateurs du produit ne savent souvent pas vraiment ce qu’ils veulent avant qu’ils ne le voient.
Nous pouvons penser qu’une solution donnée sera idéale quand nous la considérons sur le papier ou sur un tableau blanc, mais quand nous mettons une application entre les mains d’un utilisateur, nous obtiendrons toujours une compréhension nouvelle et plus profonde de ce qu’est la « bonne » chose à construire. Apprendre est quelque chose qui doit être recherché et pas craint.
Le management du changement est une compétence
Une équipe de développement a une capacité fixée et aucune quantité de désirs, de pressions ni de contraintes ne générera de production plus significative. Au lieu de cela, la gestion du changement réussie est l’art d’optimiser le travail qui est fait avec cette capacité.
Cela commence par un processus pour rassembler toutes les nouvelles idées, demandes et choses apprises à travers toute votre organisation. Des modèles apparaîtront, montrant quelles nouvelles choses sont les plus importantes. Le management du changement n’a pas pour objet d’agir sur toutes ces idées; il s’agit plutôt de trouver l’équilibre entre être réactif et disruptif.
Si nous avons un processus robuste pour gérer notre capacité, nous pouvons considérer autant de nouvelles idées que nous voulons, sachant que le processus exigera que nous nous engagions seulement sur ce que nous pouvons raisonnablement faire. Les équipes arrêtent de craindre la dérive de contenu quand elles se rendent compte que de nouvelles idées ne signifient pas automatiquement des nuits plus courtes.
Certaines nouvelles idées qui surgissent sont suffisamment bonnes pour remplacer de vieilles idées. Certaines ne sont pas aussi bonnes que ce que nous avons déjà, et nous devrions y renoncer. Et parfois l’union d’une vieille idée avec une nouvelle crée quelque chose de magique.
Finalement, nous avons besoin d’un rythme raisonnable pour considérer de nouvelles idées et changer de direction. Si une équipe consomme une grande partie de son temps chaque jour à considérer de nouvelles choses, elle fait probablement peu de progrès sur le livrable. Plusieurs méthodes agiles spécifient une période courte pendant laquelle aucun changement de ce sur quoi l’équipe travaille n’est permis. Mais tout est alors à prendre en considération aux frontières de cette courte période de temps.
La dérive de contenu est un ennemi imaginaire
Nous n’avons absolument ni le temps ni les ressources pour agir sur toutes les bonnes idées qui sont déposées sur la table pendant le déroulement du projet. Mais agir sur quelques-unes de ces idées peut être essentiel.
Alors, la prochaine fois une nouvelle demande arrive, arrêtez-vous et considérez-la. Cette dérive de contenu à laquelle vous avez résisté pourrait juste être la chose qui fait réussir votre projet.