Comment sauver un projet jeune et mourant?

Je poste cela de manière anonyme parce que je ne veux pas avoir d'ennuis potentiels.
J'ai un gros problème.
J'ai récemment rejoint une équipe de moins d'un an. Je suis ici depuis un mois pour le démarrage du projet. La structure de l'entreprise ressemble à ceci:

• Propriétaire (non technique)
  • Chef de projet (non technique)
    • Développeur principal (technique, mais mauvais dans ce domaine)

Ce projet est un site Web utilisant ASP.Net pour lequel le développeur principal a conçu une horrible architecture. Vous devrez me croire sur parole, mais fondamentalement, la façon dont nous sommes tenus de créer des pages Web nous donne des temps de chargement de plus de 3 minutes sur une seule page Web via VPN en mode débogage.

Il a grimpé en flèche au point où d'autres collègues conviennent qu'ils passent plus de leur journée à attendre que les pages soient chargées que le développement réel.

Maintenant, le gros problème est le suivant. Le chef de projet ne connaît pas la technologie et l'admet. Il a spécifiquement déclaré qu'il faisait confiance au développeur principal pour faire les bons choix sur l'architecture d'application.

Personne dans l'équipe ne sait ce que serait l'opinion des propriétaires, mais tout le monde a peur de faire des vagues dans cette économie (moi en particulier).

Qu'est-ce que tu ferais?

Ce problème peut être démontré au chef de projet en termes très non techniques. Mettez votre site dans une fenêtre de navigateur devant le PM et demandez-lui de jouer avec lui pendant un certain temps. Après environ deux chargements de page, le développeur principal doit être appelé sur le tapis, si les choses sont aussi mauvaises que vous le dites.

Le PM n'a peut-être pas les connaissances spécialisées en développement pour comprendre pourquoi c'est mauvais, mais il peut voir par lui-même en tant qu'utilisateur général du site Web que c'est le cas. D'autres sites affichant des informations similaires se chargent en une fraction du temps que vous utilisez, et le vôtre se charge sur le réseau local depuis le serveur dans la pièce voisine.

Si cela ne marche pas, allez chez le propriétaire. Le propriétaire est un gars de l'argent, mais il pourra très vite voir qu'un site Web lent que personne ne visitera == pas d'argent. Configurez la même démonstration, et avant le chargement de la première page, il devrait appeler à la fois le Premier ministre et le chef sur son tapis beaucoup plus luxueux.

Si vous craignez qu'un gars fasse des vagues, alors demandez à plus d'un développeur de s'exprimer. Honnêtement, dans une entreprise aussi plate que la vôtre, si le produit que vous développez est une bombe, vous êtes sans emploi, que vous parliez ou que vous restiez silencieux. Donc, en regardant les choses de cette façon, vous n'avez rien à perdre, mais quelques semaines ou mois supplémentaires avec l'entreprise. Si c'est un problème, planifiez des «rendez-vous chez le dentiste» et cherchez un nouvel emploi avant d'exprimer vos préoccupations, donc si vous perdez cet emploi, vous commencez le lundi suivant.

En supposant que vos déclarations sont exactes, vous avez un développeur principal qui est incompétent et un chef de projet qui est incompétent (au moins dans la mesure où il ne peut pas évaluer les compétences de l'équipe). Bien. Vous avez exactement les mêmes options que les développeurs de chaque équipe partout dans le monde.

1. Travaillez-vous sans vous soucier de la santé de l'entreprise.

2. Cherchez du travail ailleurs.

3. Faites des suggestions raisonnables au responsable, au Premier ministre et au propriétaire et espérez qu'ils seront adoptés.

Vous êtes libre de faire n'importe quelle combinaison de ce qui précède simultanément.

Si vous voulez assurer agressivement la santé du projet, vous devrez travailler avec les autres développeurs pour trouver un nouveau cadre pendant votre temps libre et démontrer au reste de l'équipe pourquoi il est supérieur et l'ancien travail devrait être abandonné en sa faveur.

J'ai travaillé dans une situation similaire, où le développeur principal qui était en fait un partenaire de l'entreprise avait créé le "noyau" du logiciel et à l'exception d'un ami proche qui travaillait directement avec lui, les autres développeurs n'étaient pas autorisés à toucher le coeur.

Les «pouvoirs en place» ont également créé des règles comme chaque module ne pouvaient avoir qu'une seule table de base de données, car c'est plus propre de cette façon. Et résultant de cela, les listes déroulantes existantes ont été créées en sélectionnant "DISTINCT" à partir des tables de la base de données, plutôt que d'avoir une table distincte.

Il y avait un certain nombre de correctifs défectueux flottant parce que l'équipe d'implémentation devait faire le travail, et le produit ne fonctionnerait pas hors de la boîte. Ces correctifs ont causé autant de problèmes qu'ils ont résolu et ont été personnalisés (piratés) pour chaque installation.

Mon approche était de prendre une petite partie de la spécification que le noyau ne supportait pas et d'écrire un petit correctif générique pour cela. Quelque chose qui a satisfait l'équipe de mise en œuvre, mais qui n'était pas aussi menaçant que "Nous devons changer complètement notre façon de penser". En raison de l'animosité entre l'équipe d'implémentation et les développeurs principaux, il a fallu des mois pour convaincre l'équipe d'implémentation que mon approche était meilleure que leurs hacks. Mais une fois qu'ils ont vu que je les écouterais et mettrais en œuvre des ajustements supplémentaires pour les soutenir, ils étaient ravis et de mon côté. Il a fallu encore un mois au développeur principal pour accepter le correctif, mais une fois qu'il l'a fait, cela a vraiment ouvert la communication entre nous tous sur de meilleures façons de concevoir d'autres parties du système.

Ce n'est jamais un court chemin pour changer la pensée des gens, surtout si vous avez besoin de garder une relation civile avec eux. Mais si vous vous en approchez bien, vous pouvez gagner le respect sans insulter votre patron.

J'espère que cela pourra aider!

Réponse et solution très simples. Il semble que tout le monde soit conscient du problème. Ainsi, le fait de souligner le problème n'a de valeur pour personne. En fait, cela vous fait ressembler à un pleurnichard. Si vous souhaitez ajouter de la valeur, vous devez indiquer la solution et élaborer l'analyse de rentabilisation pour passer à votre solution. Ensuite, vous pouvez signaler le problème avec une solution correspondante. Une démo permettrait également de prouver votre solution. Bien sûr, cela peut signifier que vous travaillez sur votre propre temps, mais tout dépend de l'importance de vous aussi.

Tout d'abord, je vous suggère fortement de vous assurer de vos faits car c'est un problème d'architecture d'application et non quelque chose dans la configuration VPN. J'ai vu des VPN mal configurés provoquer ce problème exact. Savez-vous avec certitude que l'application est aussi lente à l'intérieur du bureau?

Si vous avez exclu le réseau, j'irais avec la suggestion de KiethS et demanderais au PM de remonter la page.

Cela ressemble à l'entreprise, ou du moins le projet va bientôt tomber. À moins d'arrêter, j'essayerais de m'en éloigner le plus rapidement possible, par exemple. bénévolat / demande de travail sur d'autres projets en cours. Espérons qu'avec le temps, vous passerez moins de temps sur cette catastrophe, et plus sur d'autres projets qui ont une chance de fonctionner. Vous ne voulez pas être considéré comme «le gars qui a travaillé sur le projet qui n'a pas fonctionné». Il s'agit de protéger votre réputation.

Le propriétaire veut-il ou non un bon produit? Je soupçonne fortement que la réponse est "Oui" ... et par conséquent, vous devez parler. Vous devez documenter l'architecture actuelle, puis (avec de bonnes données impériales), montrer comment le produit ne répond pas aux attentes de performances appropriées. Vous dites que vos collègues savent tous que cela fonctionne mal - eh bien ... qu'en est-il du client? Qu'est ce qu'ils disent? Utilisez un outil de mesure du rendement et déterminez ce qui prend si longtemps. De nombreux outils vont même jusqu'à vous montrer combien de temps prend chaque appel de fonction. À partir de toutes ces données, vous devriez avoir suffisamment de munitions pour parler avec votre chef de projet et le responsable technique des raisons pour lesquelles les choses ne sont pas comme elles devraient et comment une refactorisation majeure peut être nécessaire pour mettre le produit à jour.

Ensuite (seulement après avoir parlé au PM et au responsable), cela DEVRAIT être suffisant pour commencer à apporter des modifications. Si le PM n'est pas convaincu à ce moment-là, alors vous devez décider si c'est vraiment un endroit que vous voulez être. Si oui, alors éventuellement une rencontre avec le propriétaire. Sinon, préparez ce CV.

Assurez-vous de documenter chaque étape du processus.

En termes techniques, je suis d'accord avec les suggestions ci-dessus. D'un autre côté, je pense que cela ressemble plus à un problème relationnel qu'à un problème technique.

Si vous souhaitez prendre la bonne voie, parler au développeur principal sera un choix approprié. Je ne parlerais pas au bureau cependant. Prendre un café à l'extérieur rendra les choses un peu informelles et plus détendues.

Si cela ne fonctionne pas, vous pouvez essayer de parler au PM puis au propriétaire.

Si aucun ne fonctionne, je vous suggère de chercher un nouvel emploi.

Honnêteté - et autant de tact que possible.

Commencez par le développeur principal et progressez si vous le devez. Essayez d'engager les meilleurs côtés de leur personnalité - Si vous dirigez les développeurs, ils aiment résoudre les problèmes / aiment sauver la journée / aiment être efficaces / etc. ont eu du succès dans le passé comme motivation supplémentaire.

Si vous ne faites pas de vagues, vous êtes probablement mort dans l'eau.

Serait-il possible de ramener les problèmes à un niveau mesurable et non technique afin que le chef de projet et le maître d’œuvre puissent comprendre.

Par exemple, vous avez mentionné le temps de chargement lent de 3+ minutes, je suppose qu'il y a une exigence de performance quelque part dans la spécification, quelque chose d'aussi simple que "la page à charger en 1 seconde". Quelque chose comme ça est mesurable et ne peut pas être réfuté. Si la cause première de ce problème est l’architecture douteuse, le chef de projet et / ou le propriétaire doivent intervenir pour forcer certains changements.

Sinon, vous avez un problème systématique dans votre entreprise où l'analyse initiale a été mal effectuée et où il n'y a pas assez de processus en place pour détecter ce type de problèmes. Pensez à sauter le navire!

Les vrais hommes s'expriment sans ressentiment ni émotion. Voilà l'astuce.

La seule raison valable pour laquelle quelqu'un pourrait vous contrarier pour avoir pris la parole, c'est si vous rencontrez du ressentiment:

LE LEAD DEVELOPER N'A AUCUNE INDICATION DE CE QU'IL FAIT. Je savais que ça allait arriver, mais personne ne m'a écouté bla bla bla.

tandis que

Le modèle de code est incorrect car il est difficile à maintenir et lent. Nous devons être stratégiques à ce sujet pour aller de l'avant et régler ces deux problèmes.

Le premier est une bataille à détruire, le second est une bataille pour la paix, et à long terme, vous obtiendrez le respect d'une personne pour être honnête.

Si le chef de projet prend cela comme une façade, ce qu'il pourrait certainement envisager de se faire renvoyer, alors dites simplement:

Ne me tenez pas responsable des choses que je n'étais pas responsable de la mise en œuvre. Je suis juste honnête.