PM optant pour une configuration trop complexe avec laquelle personne n'a l'expérience
Récemment, j'ai commencé un projet qui ne semblait pas trop difficile à réaliser, le concept était une application assez simple qui devait accepter des entrées de temps en temps (peut-être 10 fois par jour), et essayer d'effectuer certaines opérations sur elles et collecter tous les résultats à la fin. Cette application obtiendrait alors un portail Web frontal que les clients pourraient utiliser pour afficher les résultats, pas exactement la science des fusées.
Pour cela, j'ai d'abord utilisé intelligemment les bibliothèques de concurrence intégrées de Python (ThreadPoolExecutor) et j'ai utilisé une bibliothèque facile à utiliser pour le front-end (j'ai choisi Flask as il est facile pour les débutants et est relativement facile à entretenir et à tester).
Une fois que nous étions à mi-chemin du projet, le PM a déclaré que nous devions utiliser des capacités de file d'attente de messages tierces au lieu de threads et que nous devions implémenter l'équilibrage de charge, ce qui s'est finalement produit, c'est que nous avons finalement commencé à travailler avec Céleri, Redis, RabbitMQ, Nginx, uWSGI et un tas d'autres grands services tiers avec lesquels personne n'avait vraiment d'expérience.
En fin de compte, cela a conduit à un tas de code spaghetti, à des tâches non testables (en raison de la complexité des bibliothèques tierces, le patch du code n'a même pas fonctionné) et à un tas de maux de tête parce que personne ne savait même quelle était la valeur ajoutée de ces services. .
Avant de dire "Oui, vous devez utiliser ces services", gardez à l'esprit personne sait comment les utiliser ou sait même ce qu'ils font en plus d'introduire du code en proie aux conditions de concurrence .
Que dois-je faire à ce sujet? À ce stade, il serait tout simplement trop coûteux de revenir à ce que nous avions et le PM est déterminé à utiliser ces services, même si le produit final est maintenant pire que ce qu'il était au début. Est-il même utile d'en discuter avec lui? Est-ce que je demande plus de temps? Ou la réponse dure, suis-je simplement trop stupide pour mon travail?
Une fois que nous étions à mi-chemin du projet, le PM a déclaré que nous devions utiliser des capacités de file d'attente de messages tiers au lieu de threads et mettre en œuvre l'équilibrage de charge
Ce n'est pas une chose appropriée pour un PM à "déclarer" unilatéralement. Deux raisons:
Les décisions de conception doivent être prises par une ressource technique et uniquement en réponse à NFRs . Alors demandez poliment à votre PM s'il y a un nouveau NFR et si vous pourriez avoir des détails.
Si un NFR est introduit à mi-chemin du projet, cela devrait probablement être fait via un changement de contrôle . Le contrôle du changement est très important du point de vue de la gouvernance; ce serait non seulement une entrée pour vos besoins, mais aussi une entrée importante pour les cas de test de QA, le déploiement des opérations et le manuel de support, et (voici la partie importante vraiment) les PM programme. Si la nouvelle exigence introduit plus de travail, l'équipe de développement devrait avoir la possibilité de communiquer de nouvelles estimations de développement, et le PM devra décider s'il peut vivre avec la nouvelle date, ajouter plus de ressources , ou repousser la partie prenante qui a introduit le NFR.
Maintenant, s'il existe vraiment un NFR de bonne foi et qu'il n'y a pas moyen de le contourner, il peut également être approprié de demander des ressources nouvelles ou différentes qui connaissent les technologies qui sont introduites, ou de demander un budget de formation pour une partie de vos ressources existantes. Ressources. Il y a donc un aspect coût également.
Si vous parlez la langue du PM - calendrier et coût - je pense que vous obtiendrez plus de traction que de parler de ce que les développeurs pensent de la conception résultante. Ces choses ont un impact réel.
A PM devrait savoir mieux que d'introduire des trucs comme ça à la volée sans gouvernance, sans contrôle et sans consensus. S'ils ne l'obtiennent tout simplement pas, vous devrez peut-être passer à gestion de produit ou gestion de programme, car il met inutilement la qualité et le calendrier en danger.
Ce qui serait stupide, c'est de se laisser prendre la mort a marché .
Ce que vous décrivez, c'est que vous avez perdu le sens critique. Il n'y a aucun sentiment de contrôle et aucun moyen clair d'y retourner.
La dernière chose à faire est de travailler dur, de garder la tête baissée et de souffrir tranquillement jusqu'à ce qu'ils admettent enfin que le projet est condamné.
Ce que vous devez faire, c'est réfléchir très sérieusement à ce que vous êtes en droit d'attendre.
S'ils veulent que vous utilisiez des technologies que vous ne comprenez pas, vous devez vous attendre à avoir le temps de les apprendre. N'ayez pas honte de ce que vous ne savez pas. Utilisez votre ignorance comme un gourdin. Quand ils vous demandent d'utiliser quelque chose, demandez pourquoi. N'acceptez pas "parce que". N'acceptez pas les "meilleures pratiques modernes". N'acceptez pas la "capacité d'échelle" sans obtenir des attentes réelles et vérifiables.
Par testable, je veux dire qu'ils DOIVENT vous dire combien de demandes par jour/heure/minute ils veulent qu'il puisse faire. Indiquez clairement que vous avez l'intention de construire quelque chose pour exercer ce système conformément à ces spécifications.
De cette façon, vous pouvez utiliser un essai gratuit de 30 jours pour prouver que la dernière chose qu'ils veulent en vaut la peine ou si vous feriez mieux de vous en tenir à ce que vous savez déjà.
Maintenant, gardez à l'esprit. Ce ne sont pas les outils qui ont introduit le code infesté par les conditions de concurrence. Vous avez fait ça. Vous devez savoir COMMENT vous avez fait cela pour pouvoir l'annuler.
Et non. Il n'est pas trop coûteux de revenir à ce que vous aviez. Le PM ne peut pas avoir ce qu'il veut juste en le demandant. Vous devez repousser jusqu'à ce que vous puissiez utiliser efficacement ce que le PM veut ou prouver que ce n'est pas le cas) ce dont le projet a besoin.
Sérieusement, le fait de céder est peu professionnel et mortel pour le projet.
Je suis ici mec. Plus d'une fois. Cela vous fait vous sentir stupide. Ce n'est vraiment pas ça. Tu es juste perdu.
Parlez au PM. Honnêtement. Étalez le tout. Montrez que vous êtes prêt à apprendre mais que vous ne voulez pas être emmené en balade. Jamais jamais concevoir ou coder basé sur la foi. Faites le PM vous montrer comment faire ce qu'ils veulent. Ne prétendez pas que vous comprenez quand vous ne le faites pas. Ne dites pas que ce sera fait quand ce ne sera pas le cas. Si vous êtes va croire en quelque chose croyez en vous. Vous devez être prêt à dire NON.
Si cela ne fonctionne pas, peaufinez le CV, car vous en aurez bientôt besoin. D'une façon ou d'une autre.
Cela devrait vraiment être sur lieu de travail.stackexchange.com, car le problème n'est pas vraiment une question de développement logiciel, mais des relations en milieu de travail.
Si vous êtes sûr que votre approche simple aurait fonctionné et produit un résultat de travail assez rapidement, alors votre PM est une force destructrice dans votre entreprise qui devrait être supprimée. Découvrez comment obtenir les nouvelles au niveau supérieur à lui: que votre équipe avait une solution simple et fonctionnelle qui avait bien progressé, et pour des raisons que personne ne peut expliquer votre PM vous a forcé à essayer une solution beaucoup plus complexe, en utilisant une multitude d'outils que personne ne connaît, personne ne comprend, personne ne sait s'ils sont utiles, et cette décision insondable de votre PM vous a causé tous les ennuis et fait que le projet est en retard et non travail.
Ne connaissant pas le contexte et la stratégie produit poursuivis par votre management, il est difficile de répondre objectivement à votre question.
Voici quelques arguments objectifs. Il est cependant possible que ce ne soit pas ce que vous attendiez:
- " Gardez à l'esprit que personne sait comment utiliser ces produits encore".
- Utiliser uniquement des outils et des techniques parfaitement connus garantira une productivité élevée. Mais cela limitera considérablement la capacité d'innover. Sur certains marchés, cela pourrait être fatal à votre produit. Par exemple, il y a près de 30 ans, j'ai proposé d'utiliser Windows 3.0 pour développer une nouvelle version d'un produit CAD qui a réussi sous MS-DOS. Le chef de produit a objecté que ce n'était pas une preuve environnement, qu'il serait trop complexe et trop difficile à apprendre pour l'équipe, et de toute façon, que " Windows ne sera jamais un environnement grand public " .. Je vous laisse deviner le succès de son produit 2 ans plus tard.
- Tout est une question de coûts et d'avantages. Le coût de l'expérimentation par rapport à l'avantage d'une évolutivité et d'une déployabilité assurées par un tiers expérimenté avec des installations énormes et une lourde charge de travail.
- Les inconvénients de l'ajout d'une nouvelle technologie peuvent être atténués, avec une formation appropriée, ou un soutien/coaching initial par un consultant expérimenté.
En définitive, le choix économique est de la responsabilité de votre chef de produit. Discutez avec lui des avantages et des inconvénients pour vous assurer qu'il prend une décision bien informée et ne sous-estime pas la complexité supplémentaire. Et s'il reste sur sa piste, essayez de faire de votre mieux: vous n'avez rien à perdre et dans le pire des cas, vous aurez une nouvelle technologie sur votre CV.
Il existe deux approches des bibliothèques tierces (et d'autres composants):
- Utilisez-en autant que possible
- Utilisez-en le moins possible
Mon approche est (2). Il semble que votre approche soit également (2), mais le chef de projet aime l'approche (1).
Il existe trois façons de gérer cette situation. Soit vous laissez le PM faire ce que le PM veut), vous essayez de convaincre le PM de changer l'approche en troisième -des bibliothèques de parti, ou vous votez avec vos pieds et sélectionnez un autre emploi.
Si vous voulez convaincre le PM pour changer l'approche, considérez ces arguments:
- Temps d'apprendre. Chaque bibliothèque externe nécessite du temps pour apprendre, temps pendant lequel un programmeur compétent peut écrire la fonctionnalité souhaitée, surtout si une énorme bibliothèque a été choisie juste pour faire une chose très simple qui pourrait être faite en quelques centaines de lignes de code.
- Remplaçabilité. Si vous avez une bibliothèque externe, comment vous assurez-vous que si son développement est arrêté, vous pouvez la remplacer par une autre bibliothèque similaire? Ma solution est d'éviter les bibliothèques externes chaque fois que je le peux, et chaque fois que cela n'est pas possible, j'écris un simple wrapper pour résumer la partie de l'interface de programmation que je veux. Habituellement, l'interface que je veux est beaucoup plus simple que celle qu'offre la bibliothèque. Ensuite, mon code accède à la bibliothèque externe uniquement via ce wrapper, ce qui facilite les remplacements. Construire votre application entière sur un framework est un gros no-no. Servlets? Oui, ils sont ici depuis longtemps et continuent de l'être dans un avenir prévisible. Moteurs de modèles? Oui, bien qu'ils ne soient pas exactement remplaçables (vous en choisissez généralement un et restez avec), la valeur qu'ils apportent est énorme, alors sélectionnez-la soigneusement - et gardez à l'esprit que lorsque vous changez de moteur de modèle, vous pouvez avoir deux moteurs de modèle dans le même application, mais vous ne pouvez généralement pas avoir deux cadres dans la même application. Apache Struts? Non, les frameworks se mettent à la mode et se démodent rapidement, et vous ne pouvez généralement pas avoir deux frameworks dans la même application.
- Version enfer. En sélectionnant une bibliothèque externe, vous devez la mettre à jour pour éviter les failles de sécurité, et la mettre à jour peut casser des choses. Des composants bien conçus (tels que Java JRE) sont compatibles avec différentes versions, mais mon expérience est que la plupart des bibliothèques sont de la merde en raison de l'imposition d'un énorme enfer de version. En outre, le composant X peut nécessiter Z version 1 et le composant Y peut nécessiter Z version 2, et vous ne pourrez pas nécessairement lier Z version 1 et Z version 2 dans la même application.
- Vulnérabilités de sécurité. En sélectionnant une bibliothèque externe, le nombre de vulnérabilités de sécurité facilement exploitables contre votre application augmente. Certains pourraient prétendre que le code développé en interne ressemble à la sécurité par l'obscurité, mais là encore, je dirais que c'est toujours une forme de sécurité.
- Problèmes de licence. Chaque bibliothèque externe impose sa propre licence sur des parties de votre programme. Par exemple, les bibliothèques GPL ne peuvent pas être utilisées dans des programmes non GPL, et les bibliothèques LGPL nécessitent également la distribution du code source avec des fichiers binaires, ce qui peut prendre des quantités considérables de bande passante.
- Heure de démarrage de l'application. Chaque grande bibliothèque externe ralentit le temps de démarrage de votre application. En écrivant une bibliothèque simple et allégée en interne, vous pouvez accélérer le démarrage de votre application.
- Empreinte mémoire. En ayant X nécessitant Y nécessitant Z nécessitant A nécessitant B, vous avez besoin de X + Y + Z + A + B dans la mémoire en même temps. En implémentant uniquement l'équivalent de X, appelons-le X ', en interne, vous n'avez besoin que de X' en mémoire. Et généralement, l'empreinte mémoire de X 'est inférieure à l'empreinte mémoire de X.
- Risque de bug. Plus il y a de lignes dans le composant externe, plus le risque est élevé que vous rencontriez un bogue qui sera difficile à corriger en raison de l'énorme quantité de code que vous devez comprendre. Si vous faites la chose en interne, vous le faites généralement avec moins de lignes de code (pour faire exactement ce dont vous avez besoin, rien d'autre), et donc un moindre risque de bugs.
- Personnalisation. Si j'écris moi-même des requêtes SQL, je sais à quoi ressemble la requête et comment elle fonctionne sur un moteur de base de données et un ensemble d'indices donnés. Si, en revanche, la requête SQL est écrite par un composant externe, je ne sais rien de ses performances. J'avais l'habitude de travailler dans une entreprise où chaque page Web prenait plusieurs secondes à récupérer. Je soupçonnais que la cause était la bibliothèque Hibernate qu'ils utilisaient, qui récupérait trop de données automatiquement de la base de données lorsque tout ce dont vous aviez besoin était un élément et pas tous les éléments liés à cet élément particulier. J'ai quitté l'entreprise avant de découvrir la véritable cause de la lenteur, car je n'aimais pas l'approche consistant à utiliser un grand nombre de bibliothèques existantes.
Méfiez-vous surtout si une bibliothèque s’appelle cadre. Cela signifie que la bibliothèque vous oblige à construire votre application entière autour d'elle. Vous ne pouvez généralement pas avoir deux cadres dans la même application; ils se battront sans coexister pacifiquement. Bibliothèque d'utilitaires de développement Web? Oui s'il vous plaît, il y en a trop peu. Si jamais je trouve une meilleure bibliothèque que celle que j'utilise maintenant, je peux utiliser la bibliothèque nouvellement trouvée dans le nouveau code tout en continuant à utiliser l'ancienne bibliothèque dans l'ancien code. Cadre de développement Web? Un grand klaxon NON!
Je pense que votre PM vise un système difficile à gérer qui produira beaucoup de travaux de maintenance pendant qu'il est en direct, donc il assurera vos revenus.
Personnellement, vous semblez être bloqué avec python, oubliez juste python pendant un certain temps, ne codez pas python pendant un an, apprenez de nouvelles choses, vous verra qu'il existe d'autres langues qui peuvent faire de même, et probablement mieux.
Comme d'autres l'ont indiqué, apprenez les outils avant de commencer à coder avec eux. Peut-être suggère-t-il qu'il serait bon d'évaluer ensemble la pile nécessaire, sur la base de la recherche de différents outils qui semblent adaptés à la tâche. Ou peut-être demander comment il a établi cette liste, il aurait pu avoir l'aide de quelqu'un qui est à jour.