Si l'ajout de personnes à un projet tardif aggrave les choses, quelles options fonctionnent?
Je travaille sur un projet avec un délai fixe (il y a des pénalités financières si nous sommes en retard ou que nous abandonnons des fonctionnalités).
Nous sommes en retard.
Mon chef de projet ne cesse de demander si nous pouvons ajouter des personnes afin que nous puissions reprendre le chemin.
Selon la loi de Brook et le Mois de l'homme mythique ,
L'ajout de ressources humaines à un projet logiciel tardif le rend plus tard
Je dois donc dire "non merci" à mon chef de projet aux personnes supplémentaires. Ils n'acceptent pas cette réponse. Que puis-je leur dire d'autre?
Existe-t-il d'autres options pour accélérer un projet logiciel tardif?
Il existe cinq façons de gérer cela:
- augmenter la capacité
- renégocier
- démissionner
- descendre vaillamment
- baisse de la qualité
Comme vous êtes déjà derrière le ballon, vous n'avez pas le temps d'investir pour augmenter votre capacité globale. Mais si vous l'avez fait:
- Pour agrandir l'équipe, il faut sacrifier un ou plusieurs développeurs actifs à l'enseignement et à la formation. Il y a aussi une limite supérieure sur la taille de l'équipe avant que cela ne commence à ralentir le développement global même une fois que les nouveaux développeurs sont opérationnels.
- Réduire les formalités administratives/supprimer les limitations nécessite d'affecter un ou plusieurs membres de l'équipe qui comprennent ce que la bureaucratie est censée faire et comment elle ne fonctionne pas, pour supprimer ou retravailler la bureaucratie qui n'offre aucun avantage.
- Automatisation des charges de travail répétitives. XKCD cloue ceci , il y a un compromis dans combien de temps investir dans cela sera payant. Comme vous êtes déjà proche, la période de paiement est petite et ne vaut probablement pas la peine d'être automatisée.
Faire cela peut être bénéfique, mais ils ont leur plus gros gain s'ils sont faits tôt et systématiquement des heures supplémentaires.
Retournez voir le client et soyez honnête. Nous n'allons pas livrer cela à temps. Permet de négocier.
Oui, il y a des sanctions, elles vont être invoquées. Plus tôt vous reconnaissez que cela se produira, plus les retombées seront faibles.
- Le projet pourrait être annulé et annulé. Une mauvaise journée mais maintenant vous avez deux mois pour faire quelque chose d'utile qui aurait fait chuter le gargouilleur.
- Vous pourriez négocier une portée réduite à livrer, avec des livraisons de suivi. Au moins maintenant, vous savez ce que votre client trouve important, planifiez-le et faites-le. Ensuite, nettoyez le désordre et livrez le prochain ensemble de fonctionnalités.
- Vous pourriez négocier une réduction de la portée. Similaire à avant, mais vous n'aurez pas à nettoyer.
- Vous pourriez avoir plus de temps. Fais-en bon usage.
Quel que soit le résultat, votre réputation inclura le fait que vous gérez de manière proactive l'échec du projet tôt. De nombreuses entreprises verront cela comme un signe de maturité.
Démissionner
Si vous choisissez de démissionner, le projet sera encore plus compromis et il est fort probable que vous:
- pas une bonne recommandation,
- nuire gravement à vos relations professionnelles, et
- peut-être être responsable de certains des dommages contractuels.
Toutefois:
- vous n'alliez probablement pas obtenir une bonne recommandation de toute façon car vous ne jouiez pas en tant que surhumain,
- si vous pensez que vos relations professionnelles ne vont pas subir de coups en livrant un logiciel brûlant et brûlant, détrompez-vous.
- sans compter que si cela se produit ou se casse, vous serez de toute façon impayé pour le temps travaillé.
Il s'agit donc de savoir si vous pensez ou non que c'est mieux. C'est probablement à ce stade. Mais parfois, nous n'avons même pas ce choix.
Descendez avec le navire.
- Du côté professionnel, vous arrivez à garder votre moralité et votre dignité.
- Du côté des inconvénients, vous n'allez pas respecter ce délai.
Qu'as tu besoin de faire:
- Soyez bruyant, soyez direct, soyez professionnel.
- Continuez à énoncer explicitement que vous ne respecterez pas le délai et projetez la meilleure estimation actuelle avec incertitude. ex: 6 à 10 mois si tout se passe comme prévu. 8-20 mois si plus de x problèmes surviennent.
- Assurez-vous de conserver une copie imprimée et attestée de chaque communication autour du projet.
- N'acceptez pas, ou ne ratifiez aucun calendrier qui vous est donné, qui n'est pas proportionné à votre calendrier sainement projeté. par exemple: pouvez-vous faire une démonstration lundi? Non, nous sommes à au moins deux mois de quelque chose qui peut être démontré. Mais votre emploi du temps indique 3 semaines .. au plus tôt, plus probablement deux mois.
- Renseignez-vous sur les politiques de votre entreprise, en particulier concernant vos droits, et comment escalader les problèmes qui affectent la réputation de l'entreprise. Suivez ces processus.
Vous serez soumis à une pression énorme. Vous risquez de perdre votre emploi, vos bonus, votre place de parking spéciale. Vous serez probablement défilé avant et utilisé comme chèvre de scape.
Vous pouvez devenir soumis à la suite de droit. C'est pourquoi vous avez conservé vos communications pour prouver que vous avez fait preuve de diligence raisonnable.
Il sera utile de suivre une formation sur la façon de considérer, puis d'exprimer votre argument à un public hostile. Des choses comme la prise de parole en public, le débat, la formation à l'affirmation de soi seront utiles.
Sacrifiez la qualité
C'est la réponse la plus vile, mais si vous êtes coincé entre deux entreprises implacables qui ne négocieront pas à temps ou sur des fonctionnalités ... et que vous ne pouvez pas quitter pour une raison quelconque, et pour une raison quelconque, vous ne pouvez pas prendre le haut moral de descendre avec votre vaisseau.
Personnellement, je ne pardonne pas de sacrifier la qualité. Je souligne ceci pour expliquer pourquoi cette solution n'est pas PAS UNE SOLUTION .
Le problème est que les deux parties sont en guerre et que vous êtes coincés entre elles, ce qui conduira inévitablement à la destruction autour de vous. Il y a ceux qui choisissent intentionnellement ou non cette action par dépit, pragmatisme ou autre justification. C'est certainement quelque chose à prendre en compte et à se méfier à la fois en vous-même et chez les autres.
Si cette option est celle qui est retenue:
S'il vous plaît, mettez votre dignité et votre moralité à la poubelle - vous ne pouvez pas vous les permettre. Bienvenue dans un enfer que vous adaptez personnellement pour vous-même.
Vous avez un délai et un ensemble de phrases qui décrivent l'état final du système. Votre rôle est de jouer le génie de la lampe, vous avez reçu une demande déraisonnable, votre objectif est de la résoudre avec le moins d'effort, de considération ou de réflexion tout en respectant la lettre de la demande. Ne vous occupez pas de l'esprit de la demande - il a déjà prouvé qu'il ne peut pas changer les termes du contrat et peut être envoyé dans le même bac que votre moralité et votre dignité.
- Trouvez chaque coin et prenez-le. Si vous avez le choix entre passer une demi-journée ou une journée complète sur une "fonctionnalité", passez une demi-journée. Même si cela imposera une punition au prochain groupe de développeurs.
- S'il y a une exigence moelleuse, trouvez une solution globale. par exemple: doit être sécurisé. Définissez ceci comme utilise SSL. Supposons que le boîtier du serveur est sécurisé. Ainsi, vous pouvez stocker les informations d'identification du mot de passe non cryptées. etc...
- S'il y a une exigence qui peut être lue de deux manières. Interprétez-le de manière à réduire le temps de mise en œuvre. Et reformulez l'exigence dans un document de partie prenante qui est signé.
- Si possible, satisfaire une exigence en ne faisant rien. Un paragraphe expliquant comment cela est fourni par quelqu'un/quelque chose d'autre est 100 fois plus rapide qu'en réalité.
- Ne vous embêtez pas avec une bonne ingénierie. Pensez programmeur novice: codez directement dans l'interface utilisateur, les spaghettis sont roi, écrivez toujours plus, ne réutilisez jamais.
- Si vous avez satisfait à toutes les exigences, chaque instant restant est votre bonus.
En tant qu'ingénieur expérimenté, vous serez en mesure de deviner quelles parties du code vous mordront tôt. Ce sont les seuls morceaux de code dont vous devriez vous soucier suffisamment pour bien faire.
Mais sérieusement, ne vous laissez jamais placer dans cette position. Poussez pour l'une des autres solutions, même arrêter de fumer est préférable. Au moins, il envoie clairement le message aux deux parties que ce n'est pas le cas.
Fais ton choix.
Tout dépend de nombreux facteurs que vous n'avez pas partagés avec nous. Tout d'abord, comment avez-vous déterminé que vous serez en retard et de combien:
- Êtes-vous proche de la date limite?
- Dans quelle mesure le travail reste-t-il bien défini?
- Quelle est la fiabilité de votre estimation des efforts pour le travail inachevé?
Si vous déterminez que vous pouvez terminer à temps avec une accélération modérée (10-15%), vous devriez examiner les options d'ajustements et les facteurs qui ont empêché votre équipe d'atteindre cette vitesse.
- Existe-t-il des tâches/responsabilités indépendantes que votre équipe peut abandonner, reporter ou déléguer à d'autres?
- Avez-vous une certaine flexibilité de portée dans la façon dont les fonctionnalités sont implémentées si vous ne pouvez pas les supprimer? Par exemple, si des exportations Excel sont demandées, vous pouvez créer des fichiers xlsx avec des styles Nice ou de simples fichiers csv. Devinez ce qui peut être fait en moins de temps.
- Y a-t-il des goulots d'étranglement dans votre processus qui pourraient être assouplis par de nouveaux travailleurs sans effort d'introduction significatif? (c'est en fait un endroit où le plan de votre manager pourrait fonctionner)
S'il existe de tels facteurs, éliminez-les.
En fin de compte, si vous constatez que votre équipe ne peut rien faire de manière réaliste, votre organisation doit mordre la balle et payer les pénalités. Il a accepté un projet mal défini ou impossible à réaliser à temps compte tenu des ressources disponibles, n'a pas réussi à suivre les progrès et à s'adapter lorsqu'il était encore temps, ou autre. Votre équipe n'est pas responsable des échecs de gestion.
Si votre manager insiste sur le fait que l'ajout de travailleurs vous permettra d'atteindre l'objectif, vous pourriez aussi bien accepter son offre et lui prouver le contraire. Il pourrait vous en vouloir de toute façon, que vous refusiez d'accepter de nouveaux travailleurs ou que vous ne puissiez pas livrer à temps avec des travailleurs supplémentaires.
Malheureusement, il existe des moyens sûrs d'accélérer un projet.
- Fonctionnalités Drop
- Qualité de chute
Il est donc évident de supprimer des fonctionnalités.Si vous venez de rayer certaines fonctionnalités que vous n'avez pas encore démarrées, mais qui sont incluses dans l'estimation, votre estimation est présentée.
Le problème est d'identifier les fonctionnalités que vous n'êtes pas obligé contractuellement de fournir.
C'est là que la qualité entre en jeu. Dans tout projet logiciel, il y a tout un tas de trucs dont "le client ne se soucie pas" (assez pour le mettre par écrit). Trucs plaqués or comme par exemple la sécurité, les performances, le travail en dehors des conditions de laboratoire, etc., etc.
Ces choses inutiles que vos développeurs ajouteront normalement de certaines bêtises socialistes comme "l'éthique du travail" ou "les exigences légales". Mais la vérité est que vous pouvez tout supprimer et que le client ne le remarquera pas jusqu'à ce que vous ayez été payé. Le cas échéant!
Si vos développeurs sont à la hauteur, laissez-les reprendre dans la prochaine phase du projet ou lorsque le client demande des fonctionnalités supplémentaires (payantes). Personne ne saura jamais qu'ils manquaient !!
Maintenant, il y a un piège. Remarquez que j'ai dit "pas encore commencé". Évidemment, si vous avez déjà effectué 90% du travail, vous ne pouvez économiser que 10% du temps. max!
Ces développeurs embêtants aiment construire ce type de placage d'or dès le départ. Il faut donc être ferme et ne pas les laisser mettre en danger l'ensemble du projet (votre échéance) !!
Assurez-vous qu'ils ne fonctionnent que sur des fonctionnalités précieuses dès le début! dites-leur que "ce n'est qu'un pilote", "utilisez simplement une licence de démonstration" et le favori de tous "nous pouvons mettre cela en phase 2"
L'ajout de ressources humaines à un projet logiciel tardif le rend plus tard
C'est un peu simplifié. Ajouter plus de développeurs améliorera la productivité à long terme. Mais à court terme, cela ralentira le développement car plus de personnes ont plus de frais généraux et nécessitent plus de planification, et les nouveaux développeurs auront besoin d'informations et d'assistance des développeurs existants.
Il faudra donc un certain temps avant que la productivité n'atteigne son équilibre. Peut-être un mois ou plus selon la complexité du projet. Si les nouveaux développeurs sont inexpérimentés et ont besoin de beaucoup de mentorat, cela prendra beaucoup plus de temps.
La citation est un contrepoint important à la pensée naïve du "mois-homme", où vous pensez que vous pouvez simplement augmenter la productivité proportionnellement en ajoutant plus de personnes. Mais évidemment, il n'est pas vrai que l'ajout de personnes ne peut pas augmenter la productivité globale.
Certains facteurs affectent la facilité de montée en puissance:
- La qualité de la documentation du projet. Si la seule documentation existe dans les têtes des développeurs actuels, alors la perte de productivité en introduisant de nouveaux développeurs sera plus sévère.
- La modularité de l'architecture. Les nouveaux développeurs peuvent-ils commencer à travailler sur un module sans marcher sur tout le monde?
Le problème est que si le projet est déjà en retard il y a un risque que les développeurs existants aient lésiné sur la documentation et la modularité afin de gagner du temps à court terme ...
Vous êtes dans une mauvaise situation, c'est certain, mais il existe des tactiques qui pourraient atténuer votre situation.
La suppression ou le report de fonctionnalités est peut-être la meilleure tactique. Appliquez une analyse coûts/avantages - déterminez l'ensemble des fonctionnalités pouvant être implémentées dans le calendrier restant qui minimise les pénalités pour les fonctionnalités manquées, puis effectuez ces fonctionnalités. Idéalement, ceux-ci devraient être négociés avec le client qui paiera la facture - partagez la liste, si vous différez une fonctionnalité que le client considère comme plus valable, vous pourrez peut-être renégocier les fonctionnalités et les pénalités.
Cela va sans dire, mais déchargez toutes les activités hors développement de l'équipe jusqu'à la date limite (ou, par miracle, le projet se remet sur les rails). Protégez les développeurs de tout support, maintenance, correction de bogues, dépannage, etc. qui n'est pas lié à votre projet. Annuler les réunions obligatoires du département et du personnel. Déléguez les tâches administratives. (Par exemple, si vos ingénieurs remplissent des demandes d'achat, suivent les livraisons et effectuent un suivi auprès des fournisseurs, demandez à votre chef de projet d'affecter du personnel administratif à ces tâches à la place). Si la période d'examen des performances a lieu avant la date limite, reporter les examens à plus tard. Ne différez pas les relances.
Enfin, l'ajout de ressources à un projet n'entraîne pas nécessairement un retard global - cela dépend de la distance qui vous sépare, du temps dont vous disposez avant la livraison et du fait que des membres potentiels de l'équipe connaissent déjà le cadre et les outils que vous utilisez. en utilisant. Par exemple, vous avez cinq développeurs, 25 tâches "d'un mois" restantes et 4 mois avant le début des sanctions. À ce stade, vous pouvez faire appel à deux développeurs familiers avec votre projet, votre framework, votre ensemble d'outils, etc. et respectez votre horaire. Les clés ici sont de former plusieurs personnes, d'identifier rapidement les problèmes de planification et de résoudre les problèmes de planification de manière agressive.
Pour vraiment résoudre ce problème, vous devez remonter le temps et:
Identifiez les problèmes de calendrier au début du projet. Si votre vitesse est de 3 tâches par mois et que vous planifiez des appels pour 4 par mois, ajoutez des ressources.
Si possible, négociez les fonctionnalités et les livraisons avec vos clients en tant que processus de développement agile collaboratif.
Former les membres de votre équipe de développement de manière croisée - dans la mesure du possible, utilisez des cadres et des outils communs. Faites-en un objectif que vous pouvez ajouter des développeurs à un projet sans avoir besoin de formation approfondie et de "mise à niveau".
Vous pouvez réduire le montant que vous livrez. Supprimez les fonctionnalités, réduisez la qualité, livrez un produit non testé. Rien à être fier, mais si cela vous permet d'éviter les pénalités, c'est quelque chose que votre direction devrait considérer.
Du point de vue du développement logiciel, comment pouvez-vous fournir plus en même temps? Il existe de nombreuses possibilités.
Ajoutez des développeurs vraiment bien. Peu importe ce que dit "le mois de l'homme mythique", si ces développeurs sont vraiment bons, ils peuvent éloigner le travail des autres sans formation et avec un minimum de conseils. Bien sûr, ils seront moins productifs que dans de meilleures circonstances, mais ils seront productifs.
Éliminez tout travail inutile des développeurs. Absolument pas de réunions inutiles, et seulement pour le temps le plus court nécessaire. Ne demandez pas de rapports de situation quotidiens, le temps peut être utilisé pour produire des choses. Si les développeurs doivent effectuer des tâches qui ne sont pas liées au développement, supprimez-les.
Permettez aux développeurs de travailler davantage. Faites livrer des aliments sains à l'entreprise au lieu de sortir pour le déjeuner. Réservez-les dans un hôtel à côté au lieu de rentrer chez vous. S'ils doivent travailler à la maison, laissez l'entreprise organiser cela.
Payé heures supplémentaires. Cela fonctionne pendant une courte période mais pas à long terme. Cela fonctionne mieux si vous prenez des mesures (voir 3) pour réduire la quantité de travail qu'ils doivent faire en dehors du travail.