Le fluage de la portée correspond à ce qui se produit lorsqu'une modification non prévue ou une nouvelle demande interfère avec l'avancement d'un projet. Dans cet article, vous allez explorer sept raisons pour lesquelles une modification de l'étendue se produit et apprendre à réparer ces lacunes dans votre processus avant qu'il ne soit trop tard.
Par exemple, vous êtes en train de développer une application lorsque le client envoie un courrier électronique à votre chef de projet. pour obtenir une nouvelle fonctionnalité ajoutée. Le Premier ministre accepte avec enthousiasme d’ajouter la demande, car «cela ne devrait pas prendre trop de temps». Que ce soit ou non le cas, l’écart par rapport au cadre de travail initial met tout en ruine.
Le développeur continue de travailler sur l’application. , bien que souvent, arrête de vérifier sur le reste de l’équipe pour essayer d’anticiper ce que cette nouvelle fonctionnalité apportera à l’application. Le designer s'éloigne de ses autres projets pour simuler rapidement la nouvelle fonctionnalité. Et le chef de projet essaie de trouver un moyen de réduire les délais restants afin de respecter la date de livraison promise.
En résumé: le glissement de la portée affecte toutes les personnes impliquées dans un projet. De plus, cela a un impact négatif sur les échéanciers des projets et les marges bénéficiaires. Et si les modifications sont suffisamment importantes, le fluage de la portée peut même affecter le travail que vous effectuez pour d'autres clients.
Le fluage de la portée est malheureusement un risque professionnel courant pour les concepteurs et les développeurs. Mais ce n’est pas nécessaire. Voici ce que vous pouvez faire à ce sujet.
Comment prévenir le glissement de la portée
Il est facile de reprocher aux clients d’avoir jeté votre processus de travail dans le désarroi ou d’essayer d’ajouter plus à l’application que la portée initiale. En réalité, cependant, le dérapage de la portée provient d'un manque de contrôle de votre processus .
Voici quelques-unes des manières dont le fluage de la portée peut affecter le processus de développement de votre application et ce que vous pouvez faire pour empêcher it:
Scénario n ° 1: pas de contrat
Vous n’avez pas de contrat ou de portée des travaux pour définir clairement le projet, les produits livrables, les coûts, etc.
Dans certains cas, il peut sembler acceptable de prendre sur un nouveau client sans contrat. Peut-être avez-vous déjà travaillé avec eux auparavant ou s’ils sont amis d’un ami. Indépendamment de votre relation avec eux, ou de la facilité avec laquelle ils semblent au début, vous avez besoin d'un contrat pour vous protéger, ainsi que vous-même.
Vous pouvez facilement créer un contrat avec un outil tel que AND.CO :
Le logiciel de CO permet aux équipes de conception d'applications de créer des contrats à partir de ses modèles prédéfinis. Tout ce que vous avez à faire est de renseigner les détails pertinents sur le projet.
En utilisant le modèle de AND.CO (ou en créant le vôtre), vous n'aurez plus jamais à vous soucier de laisser de côté des détails importants.
Vous pouvez également utiliser AND.CO pour joindre un énoncé de travail au contrat:
Exemple de portée de travail créée dans un logiciel contractuel de AND CO. Ceci peut être joint à tout contrat pour fournir des détails plus clairs sur les implications d'un projet.
Vous pouvez obtenir encore plus de précision en incluant une liste contenant:
● Une explication du projet
● le client est responsable de (comme fournir des noms d'utilisateur, des fichiers, etc.)
● Étapes du projet
● Produits livrables de l'application
● Date limite
Une fois que vous avez défini votre SOW, dirigez soigneusement le client avant de signer le contrat. Cela garantit que vous avez bien saisi l'objectif du projet et et qu'ils s'accordent avec ce que vous avez prévu.
Avec un contrat et une étendue des travaux, vous avez la possibilité de définir la scène pour ce qui va se passer. Cela permet au client de savoir à quoi s'attendre en termes de coûts, de produits livrables et de délais. Ceci fournit également un cadre clair à votre équipe pour travailler en termes d'objectifs de l'application, de fonctionnalités à inclure, etc.
Scénario n ° 2: échéance ou budget trop serré
Le projet initial a été cadré, mais avec un délai trop serré ou un budget trop petit, ne laissant aucune marge d'erreur.
Lorsqu'un client s'adresse à vous (ou à votre responsable de compte) et déclare qu'il a désespérément besoin que son application soit configurée dans quatre cas. Bien sûr, vous voulez pouvoir dire «oui» dans quelques semaines. C’est une mauvaise idée que de s’engager dans quelque chose que vous et votre équipe ne pouvez raisonnablement accomplir. Ou s'engager dans quelque chose où la marge d'erreur est si faible que vous perdrez sûrement de l'argent au travail.
Avant d'envoyer un contrat à votre client, assurez-vous que quelqu'un a effectué une analyse coûts / bénéfices prudente afin de déterminer votre équipe a besoin de beaucoup de temps pour créer l'application de son choix et combien d'argent le client doit payer pour que le travail soit rentable.
Ensuite, soyez honnête avec le client s'il essaie de réduire les prix ou la chronologie. . Par exemple: «Nous pourrions le faire en quatre semaines, mais nous devions supprimer les fonctionnalités A et B, et nous n'aurions pas le temps de tester."
Si vous montrez aux clients ce que leurs compromis leur coûteront, ils
Scénario n ° 3: absence de contrôle des modifications
Votre processus ne dispose pas d’un flux de travail approprié pour les demandes de modification
Tout d’abord, votre contrat doit inclure une clause anticipe les retours. Voici un exemple des termes que votre contrat pourrait définir:
Un exemple des termes AND CO permet aux concepteurs et aux développeurs de définir leurs contrats. Cet extrait de contrat explique les limites des commentaires et les informations sur la manière dont les demandes de changement seront traitées.
Les «commentaires» limitent le nombre de fois que votre client peut fournir des commentaires sur ce que vous lui avez demandé de vérifier. Cela les oblige à réfléchir vraiment au type d’apport qu’ils fournissent. Cela, à son tour, donnera lieu à des réactions plus utiles et consolidées plutôt qu’à un flot incessant de réactions vagues ou inutiles telles que «l’onglet Analytics était peut-être meilleur que celui que nous avions auparavant».
«Changes» est un déclaration très basique concernant votre processus de demande de changement. Je recommanderais de regrouper cette section afin de bien préciser quand une demande de modification est requise et ce que cela apportera au projet. (C’est pourquoi un volume de travail doit toujours être livré avec un contrat.)
En d’autres termes, abordez des points tels que:
● Les nouvelles demandes de fonctionnalités ou une refonte de la conception interrompent-elles le projet?
● Le client doit des pénalités pour toute demande de modification
● Comment le délai sera-t-il affecté?
Utilisez votre contrat pour fournir des détails sur le processus de demande de modification. Veillez ensuite à rappeler à votre client, tout au long du projet, de l’impact de ses demandes sur sa capacité à gagner de l’argent avec son application.
Il n’a pas que la compréhension de votre client sur le fonctionnement des demandes de changement pouvant entraîner un glissement de la portée. Le contrôle des modifications peut dérailler en ne disposant pas de votre propre processus strict pour le gérer. Un outil de gestion de projet intuitif tel que Wrike serait utile, dans ce cas-là
Ce qui est particulièrement intéressant à propos de Wrike, c’est qu’il est fourni avec un outil de création de formulaire ( ici ). ]). Utilisez cette option pour créer un formulaire de gestion des modifications que les clients utilisent pour soumettre toutes les demandes de modification.
Scénario n ° 4: le PM dit toujours «oui»
Le gestionnaire de projet ne veut pas définir ou renforcer les attentes des clients. oui ”pour tout, sans ajustement des coûts ou des délais.
Un contrat ferme que votre client a signé est un bon point de départ. Mais cela n’empêche pas nécessairement votre chef de projet d’être un simple transfert.
Pour empêcher vos chefs de projet de laisser libre cours à leur champ d’application, vous devrez leur fournir une formation en gestion des clients. Être capable de dire «non» ou d’expliquer comment la volte-face affecte les résultats du projet est une compétence importante pour les responsables de projet. S'ils sont incapables de contrôler le client, personne d'autre ne le fera également.
Si cela ne fonctionne pas, vous devez trouver quelqu'un qui comprend l'importance de fixer des limites avec les clients et de suivre vos processus.
Scénario n ° 5: trop de cuisiniers dans la cuisine
Le client invite d'autres décideurs à prendre part au projet, ce qui retarde les choses et oblige le projet à déraper des rails.
Les clients vous paient pour créer leurs applications parce qu'ils Je ne sais pas la première chose à propos de développement d'applications. Cela dit, c’est ce manque de connaissances qui peut leur causer des problèmes en bout de ligne.
À moins que vous n’ayez une totale confiance en vous, un client nerveux ou peu sûr peut s’adresser aux autres pour connaître son travail. Ils ne savent rien du développement d'applications, alors peut-être que leur épouse qui travaille dans le marketing le sait. Ou bien leur partenaire commercial qui avait une application développée l'année dernière veut intervenir. C'est quand ils commencent à se détourner de vous et à amener les autres dans la boucle de rétroaction que les choses peuvent devenir désordonnées.
Pour avoir une bonne idée de cela, vous devez Prenez le contrôle du projet dès le départ et démontrez votre autorité. Vous êtes le développeur de l'application et savez exactement ce que vous faites. Mettez-les à l'aise en leur montrant les autres applications que vous avez créées et soyez transparent sur ce que vous allez faire pour eux. En gros, ne leur donnez aucune excuse pour demander l'aide de quelqu'un d'autre.
Scénario n ° 6: le client n'est pas dans la boucle
Le client ne reçoit pas d'informations en retour avant la fin du projet. 19659031] Les clients peuvent être difficiles à travailler, c'est certain. Cependant, c’est une mauvaise idée de développer une application sans leur examen continu et leurs retours.
Pour commencer, lorsque le client n’entend pas parler de vos progrès, c’est un sujet de préoccupation. Et l'inquiétude vient avec la méfiance, qui va rendre très difficile l'obtention de leur adhésion.
Deuxièmement, si vous attendez de leur montrer quoi que ce soit jusqu'à la fin, vous courez le risque de devoir faire face à de coûteux remaniements lorsqu'ils décident ils n'aiment pas la direction dans laquelle vous avez pris l'application.
Je sais que cela peut être ennuyeux et stressant de laisser les clients peser, par exemple, sur la copie, la conception et la fonctionnalité, mais vous obtiendrez probablement leur approbation si vous continuez.
Scénario n ° 7: collaboration inefficace (ou non) entre les membres de l’équipe
Votre flux de travail pour le développement des applications ressemble davantage à une hâte à la réalisation de tâches individuelles qu’à un effort de collaboration pour créer un produit étonnant. ] En parlant de communication, ce n’est pas seulement que vous vous isolez du client qui peut entraîner un glissement de la portée. Les membres d'une équipe peuvent également s'isoler les uns des autres.
Les grandes applications ne sont pas conçues par des équipes chargées de la conception, de la copie et du code. Ils sont construits par des équipes qui travaillent ensemble pour créer un produit.
La première chose à faire est donc de donner à votre équipe un canal dédié pour se parler. Slack est une bonne option, car elle est facile à organiser en fonction des projets, les membres de l'équipe peuvent discuter en temps réel et s'intègre à vos autres outils professionnels tels que Wrike.
Créez un canal dédié dans Slack pour que votre équipe puisse communiquer et collaborer plus efficacement.
Une autre chose qui améliore la collaboration au sein d'une équipe est l'organisation d'un appel de lancement au début d'un travail.
Zoom est un excellent outil pour ce faire car il vous permet de partager votre écran lors d'appels d'équipe:
Zoom permet aux utilisateurs de partager leur bureau, leur navigateur, l'écran de leur appareil mobile ou de dessiner sur un tableau blanc. 
Ainsi, tout le monde peut consulter en temps réel les informations et les documents et dissiper toute confusion avant le début des travaux. Chaque projet débute également avec la conviction que "nous sommes tous dans le même bateau" plutôt que chaque homme ou chaque femme pour eux-mêmes.
Une autre chose que vous pouvez utiliser pour prévenir le dérangement de la portée est d'adopter des outils de transfert facilitant la tâche. votre équipe à collaborer.
Unite UX par exemple, est un outil que vos concepteurs et développeurs peuvent utiliser pour convertir de manière transparente une application de la conception en code. Cela simplifie non seulement le transfert, mais réduit également le temps que votre équipe doit consacrer à la création d'un produit. De cette façon, si des demandes de changement ou des problèmes surviennent, ils n'auront pas autant d'impact sur la date limite.
Résumé (1965) Comme vous pouvez le constater, l'absence de processus et de contrôle des projets est finalement ce qui conduit au fluage de la portée. Ainsi, si vous souhaitez cesser de perdre de l'argent sur vos emplois, décevoir vos clients et frustrer votre équipe, utilisez les conseils ci-dessus pour améliorer votre flux de travail.
Source link