S'il y a une échéance irréaliste, l'une des choses suivantes doit se produire:

1. a. Prolonger la date limite / b. livrer après la date limite.
2. Supprimer des fonctionnalités.
3. Qualité de la baisse (attendez-vous à un crash ou à une perte de données ici et là).
4. Faites appel à une personne hautement qualifiée qui peut contribuer de manière significative à la travail, c'est cher.
5. Travaillez des heures ridicules et rendez-vous malade en conséquence, avec des résultats douteux.

Ce qui ne fonctionne pas, mais ce que votre direction semble faire, c'est

6. Fermez les yeux et les oreilles à quiconque le dit vous la date limite est en danger.

Le numéro 5 a l'inconvénient de vous rendre malade, sans aucun avantage pour vous (l'entreprise ne va pas payer d'heures supplémentaires, ni vous remercier, mais réalisez que vous pouvez en profiter), et cela n'aide pas beaucoup de toute façon, c'est donc l'option que vous devez éviter et refuser à tout prix.

Je suggérerais de créer une liste de fonctionnalités qui pourraient être supprimées tout en ayant toujours un produit utile, et une liste de points où la qualité peut être baissée, y compris les conséquences évidentes. Votre direction doit alors décider quoi faire. Si nécessaire, faites-leur savoir que l'option 6 ne fonctionne pas (allez-y attentivement) et que l'option 1b. se produira automatiquement.

Ce que vous devez souligner, c'est que sans action, le délai ne sera pas respecté.

Premièrement, acceptez que si c'est vraiment le cas, ce n'est pas correct. Trop de programmeurs ramènent leur travail à la maison avec eux et restent silencieux sur ces problèmes, laissant la direction dans le noir (même s'ils semblent ne pas l'être).

Vous ne voulez jamais non plus présenter un problème sans une sorte de raisonnement ou une solution. Pour ce faire, la communication est essentielle. Non seulement en disant à votre responsable que vous ne pourrez pas atteindre une date limite, mais en affinant la façon dont vous le communiquez.

Si j'étais à votre place, je décomposerais le travail en éléments et placerais le calendrier et les délais autour de chacun d'eux. Vous pouvez ensuite l'utiliser pour expliquer exactement pourquoi le délai n'est pas réalisable, avec des données concrètes sur lesquelles l'entreprise peut se sentir à l'aise pour prendre une décision. Si vous êtes à l'aise pour le faire (en fonction de votre niveau et de l'équipe), vous pouvez même suggérer des compromis qui pourraient être faits (avec des changements ou votre propre calendrier) pour aider à remettre le projet sur les rails.

Si cela ne fonctionne pas, je continue souvent de mettre à jour une feuille de calcul lorsque le projet commence à envoyer un résumé hebdomadaire (ou si nécessaire quotidiennement) des éléments de travail qui ont été terminés, des obstacles à l'exécution du travail et du calendrier prévu.

Tout d'abord, il semble que votre entreprise abuse du concept de délais et d'estimations - les estimations sont des estimations et c'est tout ce qu'elles sont. Personne, jamais, ne devrait s'attendre à ce qu'une estimation corresponde exactement à une date limite et la date limite devrait avoir un tampon de sécurité très raisonnable sur l'estimation pour exactement ces situations. Livrer plus tôt, c'est bien, mais livrer après la date limite ne l'est pas.

En modifiant les réponses précédentes, et d'après mon expérience précédente, cela pourrait tout aussi bien être un problème de communication pour une raison simple: les cadres manquent souvent de techniques les compétences et la compréhension, et en termes simples, ils sous-estiment l'importance de la qualité des logiciels, qui est apparemment un réel besoin dans ce cas, car vous avez déclaré que beaucoup de refactoring sera nécessaire. Sur cette base, vous devriez probablement présenter à la direction le fait que le faire plus tard coûtera plus cher, car la dette technique ne fait qu'augmenter et le problème qui existe déjà ne disparaîtra pas simplement s'il est reporté - il augmentera en gravité à mesure que vous en ajouterez de plus en plus. complexité du projet, et cette augmentation sera exponentielle au point où le maintien du projet absorbera une énorme quantité de ressources. Je ne pense pas qu'une direction avisée transmettra cela si elle est absolument certaine qu'elle perdra de l'argent si cela continue de la même manière.

S'il s'agit d'un produit intérieur, l'argument selon lequel nous devrions produire quelque chose qui fonctionne bien au lieu d'un gâteau à moitié cuit devrait passer avec brio.

S'il s'agit d'un produit pour un client externe, encore plus - les gens sont généralement assez raisonnables pour accepter de prolonger les délais si cela signifie que le résultat final s'améliorera par ordre de grandeur.

Enfin, mais non des moindres, vous devriez comprendre pourquoi cette sous-estimation flagrante s'est produite en premier lieu et placer un mécanisme pour l'empêcher de se produire à l'avenir - les techniciens n'étaient-ils pas impliqués dans les estimations? Quelque chose d'important a-t-il été exclu des estimations, et si oui, pourquoi? Et si tel est le cas, pourquoi le délai n'a-t-il pas été prolongé après qu'il s'est avéré irréaliste?

Désolé, mais je pense que vous abordez le problème d'un point de vue trop technique. Il est facile d'accuser la direction de ne pas être raisonnable, surtout si elle n'est pas techniquement avertie, mais vous perdez des clients. C'est une réalité.

Comme toutes les situations d'urgence (pertes et dommages graves avec peu de temps et de ressources), vous devez trier. Dans votre cas, cela doit se produire à la fois dans les zones Refactoring et Feature / Requirements. Synchronisez ces deux si possible. Si la fonctionnalité A permet de conserver le plus de clients, refactorisez cette partie de la base de code si nécessaire. Limitez au moins le refactoring dans les zones présentant le moins d'intérêt pour vos clients. Je me rends compte que vous êtes peut-être en train de refactoriser des zones, des utilitaires ou des frameworks généralisés.

Je suis sceptique quant à cette grande transformation à un moment où les clients ne sont pas satisfaits de votre application. Réparez ce que vous avez pour résoudre leurs problèmes. Si vous pouvez me faire traverser la rivière, je n'ai pas besoin d'un nouveau pont.