J'ai été un développeur pratique pendant toute ma carrière et j'adore travailler avec du code. J'ai toujours eu du ressentiment envers le chef d'équipe qui a peu ou pas d'expertise concernant une technologie particulière et insiste pourtant sur une certaine mise en œuvre.
Maintenant, je me retrouve de l'autre côté du miroir. Je suis le développeur principal d'un gros client à implémenter en C #, mais mon expertise est dans la construction d'applications web Java. Bien que je sache que je peux tirer parti des modèles de conception et des paradigmes OO dans n'importe quelle langue, je suis perdu en ce qui concerne les normes de codage, les outils de cycle de vie des projets et les procédures de publication / distribution. Je ne doute pas que je puisse reprendre les bases en un mois ou deux, mais il y a certaines expériences que l'on ne peut que rassembler avec le temps.
Que dois-je faire et comment éviter de devenir le chef de projet que je détestais lorsque je développais?
Réponses:
Honnêtement, peu importe votre expérience avec une technologie, mon conseil est le même: n'appliquez pas les décisions technologiques à ceux qui devront vivre avec eux pendant que vous êtes occupé à gérer.
Soit honnête avec toi. Je parie que la raison pour laquelle vous détestiez ces anciens gestionnaires n'était pas parce qu'ils n'avaient pas la base de connaissances à partir de laquelle prendre des décisions, c'était parce qu'ils appliquaient les décisions et n'en traitaient jamais les conséquences.
Cela s'applique que vous n'ayez jamais touché à .NET auparavant ou que vous soyez le développeur le plus expert de l'équipe. Votre travail consiste maintenant à gérer et non à prendre des décisions techniques.
La gestion peut, selon le niveau de compétence de vos développeurs, impliquer de les conseiller lorsqu'ils le demandent. "Avez-vous regardé Spring.NET?" (notez le manque d'instruction là-bas) est une très bonne chose à dire. Aussi, "Google autour, voyez ce que fait le reste du monde, nous ne sommes pas les premiers à faire face à ce problème."
À certains égards, en tant que développeur Java expérimenté, vous pouvez être en meilleure position que la plupart pour cela. La plupart des frameworks et technologies Java ont un équivalent analogue dans .NET. Vous n'avez donc pas à dire "Voici la meilleure chose à utiliser", vous pouvez dire "J'ai utilisé cela en Java, connaissez-vous un équivalent .NET?"
Encouragez également beaucoup de conversations au sein de l'équipe. Organisez des réunions de discussion technique hebdomadaires. Tout ce dont vous avez besoin, c'est de l'information, au final; vous devez savoir quelles décisions ils ont prises et pourquoi. Vous n'avez pas besoin de prendre ces décisions pour l'équipe.
la source
J'ai eu de très bons managers / chefs d'équipe qui connaissaient très peu la technologie, et certains de mes pires managers ont été ceux qui pensaient tout savoir.
Pour être un leader, si vous avez des gens raisonnablement compétents, l'essentiel est de pouvoir juger de leur compétence et de leur jugement, et de donner à chacun autant de latitude qu'il peut, tout en gardant les «canards sauvages» à la tâche et les «à peine». des concurrents "occupés à des activités" sûres "mais productives. Assurez-vous que tout le monde marche vers le même batteur.
Votre plus grand défi est probablement de garder la haute direction à distance. Ils voudront des rapports, des calendriers et des coches, et vous devez comprendre ce qu'ils veulent et comment les simuler assez bien. (Eh bien, pas exactement "faux", mais produisez une documentation qui les satisfait sans perdre votre temps ou le temps de votre équipe.)
la source
Vous n'avez pas été choisi pour vos compétences en codage C #, et à moins que vous n'écriviez du code dès le départ, peu importe que vous connaissiez C # ou non. Vous devez commencer à penser à un niveau supérieur:
Certaines de ces choses peuvent traverser le territoire de la gestion de projet, mais en tant que développeur principal, vous travaillerez en étroite collaboration avec le chef de projet sur ces questions et d'autres.
Par tous les moyens, apprenez à travailler efficacement en C # aussi rapidement que possible. N'oubliez pas que votre rôle est de voir au-delà de la syntaxe et des détails du cadre et de voir la situation dans son ensemble.
la source
Adoptez une approche pratique. Commencez par vous procurer une simple amorce C # et écrivez du code. Essayez quelques choses de base que vous sauriez faire les yeux bandés dans une autre langue.
Renseignez-vous sur le style de programmation et les conventions. Vous devriez trouver cela en partie dans votre amorce de toute façon, mais vous pouvez également utiliser des produits comme StyleCop et Resharper pour appliquer des règles de style que vous ne connaissez pas. Cela vous formera efficacement très rapidement pour faire les choses d'une manière communément acceptée afin d'éviter les problèmes de compilation de votre logiciel.
Soyez simplement vous-même et appliquez les connaissances que vous avez déjà en matière de conception. Les bases sont essentiellement les mêmes quelle que soit la langue. Là où il y aura des différences, la différence entre les langues en termes de structure sera assez minime, et une grande partie deviendra apparente très rapidement lorsque vous lancerez une ou deux applications de test.
S'il y a des choses évidentes que vous ne savez pas, soyez à venir. Votre équipe respectera l'honnêteté plus que de simplement faire irruption sans aucun indice. Prenez des décisions bien informées et motivées, et prenez toujours quelques minutes pour réfléchir à votre réponse. Vous devrez être sûr de vous sans tenter de dominer, et vous ne pouvez pas laisser votre manque de connaissances dans un domaine apparaître comme une réflexion sur votre capacité à diriger l'équipe. Le leadership implique le mentorat, mais le mentorat ne signifie pas que vous ne pouvez pas également montrer une volonté d'apprendre quelque chose de nouveau.
la source
Si vous pensez ainsi et que vous vous inquiétez vraiment, vous avez déjà évité le risque de devenir ce type de chef de projet. C'est un type de personnalité totalement différent qui oserait prendre des décisions sans la connaissance appropriée. Gardez simplement l'esprit ouvert à ce que vos collègues vous disent et créez et encouragez une culture de dialogue et d'échange d'informations dans votre équipe.
la source
Il semble que ce soit quelques problèmes en jeu ici.
La technologie utilisée dans le projet que vous dirigez et le processus qui régit le développement de ce projet.
Êtes-vous le chef d'équipe ou un développeur principal? Un développeur principal effectue également une bonne partie du travail de conception et de développement. Donc, le seul moyen de contourner cela est simplement de se mettre à genoux et d' apprendre la nouvelle technologie .
Si vous dirigez réellement l'équipe, vous devrez faire confiance à l'équipe et la laisser diriger la majorité de la direction technique du projet. Bien sûr, conceptuellement, vous pourrez garder cette direction dans la bonne direction.
Les processus qui régissent le développement du projet devraient être pour la plupart en place . Il s'agit simplement de les lire, de les comprendre et de les exécuter.
Sinon, négociez avec votre patron pour trouver un mentor pour vous aider à mettre en place un processus de développement. C'est assez important. Il échouera assez rapidement si le processus n'est pas en place et est ponctuel.
Bonne chance!
la source
L'occasion se présente de temps en temps .. Saisissez-la .. Je dirais, essayez d'apprendre les bases du C #. Obtenez un tutoriel en ligne, essayez de travailler dessus. au début, il serait difficile d'apprendre le nouveau concept, plus tard, lorsque votre première tâche sera terminée, vous aurez une certaine confiance en lui.
Pensez positif, essayez de prendre une tâche difficile, déboguez votre propre code et je suis sûr que vous le maîtriserez.
Ne perdez pas votre chance.
la source
Je pense que si vous avez un bon groupe de développeurs .Net, il y a beaucoup de connaissances dans l'équipe que vous devrez peut-être exploiter pour commencer. Il y a beaucoup de similitudes entre Java et .Net que ce que vous savez déjà peut s'appliquer plus ou moins directement. L'important est de savoir ce qui est important pour réussir dans ce projet et les risques encourus. Communiquez avec votre équipe aussi souvent que nécessaire. La pratique du génie logiciel évolue tout au long d'un projet, il peut donc être difficile d'avoir une «meilleure pratique» très tôt dans le projet.
J'ai eu un peu l'inverse de votre expérience où l'on me donne une équipe très verte de diplômés qui ne sont pas issus d'un domaine lié aux logiciels. Alors que j'ai toutes les raisons de préciser ce qui doit être fait (j'étais employé pour), j'ai plutôt cherché de la pratique pour nous faire bouger et beaucoup de coaching et de discussion pour faire évoluer notre pratique en génie logiciel. J'ai appris des tas de choses en cours de route et nous sommes presque arrivés à livrer notre premier projet maison après plus d'un an de travail!
la source
Trouvez un produit open source qui utilise la même technologie que vous allez utiliser.
Si possible, trouvez-en un qui est en quelque sorte similaire au domaine problématique. Ce n'est pas aussi important que de trouver un projet avec la même technologie et les mises à jour actives.
Téléchargez leur code de travail. Lis le.
Découvrez quels outils ils utilisent. Utilise les.
Découvrez comment créer et publier le projet open source. Construisez-le et libérez-le.
Un projet open source (avec un certain nombre de contributeurs) illustrera les meilleures pratiques.
Vrai.
Apprenez de la communauté open source.
la source