Cela revient à ce que j'ai commencé à considérer comme "le conflit éternel" (entre les entreprises et l'ingénierie). Je n'ai pas la solution car c'est un problème qui ne disparaît jamais, mais vous pouvez faire des choses pour aider à atténuer les effets.
Ce que les gens ne réalisent pas souvent, c’est qu’en tant qu’ingénieurs, nous ne faisons que supposer que le problème des "entreprises prospères" est toujours acquis. Nous voulons que notre code soit agréable, net et facile à gérer, afin que nous puissions ajouter de nouvelles fonctionnalités et peaufiner celles qui existent déjà rapidement et avec un minimum de clients effectuant l'assurance qualité pour nous en découvrant d'étranges problèmes marginaux qui auraient été contrecarrés par un meilleur code. Garder les clients et conserver un avantage concurrentiel avec des fonctionnalités et une finesse que personne d'autre ne peut produire assez rapidement sont des avantages commerciaux qu'un code de qualité contribue directement et explique en grande partie la raison pour laquelle nous souhaitons un code de meilleure qualité.
Alors épelez-le. "Nous voulons utiliser X dans notre base de code parce que, sinon, cela aurait un impact négatif sur votre activité en raison de Y" ou "... car cela améliorera notre capacité à rester compétitif en améliorant notre capacité à appliquer plus rapidement les nouvelles améliorations et fonctionnalités." . "
Et faites de votre mieux pour essayer d’obtenir des preuves tangibles du bon fonctionnement des améliorations. Si l'amélioration d'un sous-ensemble d'une application entraîne une amélioration / fonctionnalité plus rapide, vérifiez quel outil d'arriéré que vous utilisez peut-être pour en apporter la preuve et signalez-le lors des réunions appropriées.
- Obtenez l'équipe sur la même fichue page
Les égos sont souvent un problème. Une chose dont les équipes d’ingénierie ont vraiment besoin, c’est d’établir l’utilité d’une approche convenue pour résoudre certains types de problèmes, et ce, pour que chacun puisse faire sa propre tasse de Kool Aid d’jour, car ils savent mieux. Il est normal de croire que les préférences de l'autre homme sont pires que les vôtres, mais valorisez la cohérence plutôt que d'avoir plus raison si son approche est réalisable et qu'il s'agit d'un argument que vous ne pouvez pas gagner. Le compromis dans un souci de cohérence est la clé. Lorsque les choses sont cohérentes, il est plus difficile de les mal faire, car la méthode établie et cohérente sera généralement la méthode la plus rapide.
- Choisissez les bons outils
Il existe deux écoles de cadres / outils / bibliothèques / peu importe. "Définissez 99% de la somme pour moi, donc je dois savoir / faire très peu" contre "rester en dehors de mon chemin quand je ne veux pas de vous, mais aidez-moi à bricoler très rapidement et avec cohérence avec ce que je veux réellement à utiliser sur la carotte plutôt que le principe de bâton ". Favoriser le second. La flexibilité et le contrôle granulaire ne devraient jamais être sacrifiés à l'autel d'un redressement rapide, car, pour les entreprises, "nous ne pouvons pas le faire car nos propres outils ne nous laissent pas" n'est jamais une réponse acceptable et la question ne se posera jamais. ingénierie produit triviale / jetable. D'après mon expérience, les outils inflexibles sont presque toujours ouverts ou manipulés de manière peu élégante et créent un gâchis géant et incontrôlable. Plus souvent qu'autrement, les solutions flexibles / plus faciles à modifier sont aussi ou presque aussi rapides à court terme, peu importe. Rapide, flexible et maintenable sont possibles avec les bons outils.
- FFS, si les ingénieurs ne décident pas, obtiennent au moins les commentaires des ingénieurs sur le choix des outils
J'ai l'impression qu'il s'agit d'une question du point de vue du développeur, mais je me suis trouvé dans beaucoup trop de situations où les décisions technologiques ont été prises sans aucune intervention de l'ingénieur. Qu'est-ce que c'est que ça? Oui, il faut bien que le dernier appel soit passé, mais si vous êtes un responsable non technique, obtenez des opinions nuancées, mais pas ce que certains vendeurs ou un site de démonstration disent de ses propres produits. Tout ce qui promet de vous faire économiser de l’argent parce que les gens n’ont pas besoin d’être aussi intelligents ou parce que cela protège les développeurs contre eux-mêmes est un mensonge sale et sale. Embauchez des talents en lesquels vous pouvez avoir confiance. Expliquez-leur ce que vous attendez d'une pile ou d'une autre solution technique et prenez leur contribution au sérieux avant de décider quel mouvement technologique adopter.
- Mettre l'accent sur la conception plutôt que sur la mise en œuvre
Les outils sont destinés à la mise en œuvre et peuvent donc vous aider, mais la priorité absolue doit être l'architecture, quel que soit le jeu de jouets dont vous disposez pour construire cette architecture. À la fin de la journée, KISS et DRY et toutes les excellentes philosophies qui en découlent sont plus importantes que le fait de savoir s'il s'agit de .NET ou de Java ou de quelque chose qui est à la fois gratuit ET nul, c'est nul.
- Connectez-vous à vos préoccupations
Lorsque le côté commercial insiste pour que vous le fassiez de la mauvaise façon, enregistrez cet e-mail, en particulier la partie où vous dites pourquoi cela vous coûterait. Lorsque toutes vos prévisions se réalisent et que de graves problèmes qui nuisent à votre entreprise en résultent, vous disposez de nombreux arguments pour prendre plus au sérieux les préoccupations des ingénieurs. Mais chronométrez les choses avec soin. Au milieu de l'enfer flamboyant, le moment est mal choisi pour un "Je te l'avais bien dit" après avoir suivi un code d'incendie. Eteignez le feu et apportez votre liste de problèmes précédemment ignorés à une réunion / conversation rétrospective, et essayez de garder le focus sur les problèmes d'ingénierie exprimés et ignorés et sur le raisonnement que vous avez compris, et non sur le nom des personnes. prendre la décision d'ignorer. Vous êtes un ingénieur. Restez sur les problèmes, pas les gens. " Nous avons exprimé notre inquiétude à propos de X parce que nous avions peur que cela pose des problèmes à Y. On nous a dit à Z et de remettre ça à plus tard. "