Comment mener un projet de développement sans expertise technique


17

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?


12
pour éviter de devenir détesté comme ça, parlez simplement aux membres de votre équipe Parlez régulièrement, parlez souvent, parlez 1: 1 "... Votre récompense pour une culture de 1: 1 en bonne santé est un manque évident de drame."
moucher

1
Quel est votre titre et votre responsabilité exactement pour ce projet? Êtes-vous un PM, développeur principal, ...?
NoChance

Apprenez des meilleurs ... youtube.com/watch?v=GjJCdCXFslY
jfrankcarr

1
Mais sérieusement, j'ai écrit il y a un certain temps cette série d'articles que vous pourriez trouver utiles: vbnotebookfor.net/2007/07/25/…
jfrankcarr

Réponses:


19

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.


2
Droite. L'essentiel est d'être prêt à laisser vos «stars» techniques prendre des décisions différentes de celles que vous auriez prises. Si vous pouvez le faire, alors tout le monde (sauf, bien sûr, la haute direction) sera heureux et productif.
Daniel R Hicks

"Donc, vous n'avez pas à dire" Voici la meilleure chose à utiliser ", vous pouvez dire" J'ai utilisé cela en Java, connaissez-vous un équivalent .NET? " Dans la plupart des cas, si un outil équivalent existe, il sera préfixé par un «N», vous pouvez donc généralement les trouver vous-même
Dan Neely

Gardez à l'esprit qu'il se considère comme "Lead Developer" et non comme "Project Manager". D'après mon expérience, ce sont deux choses très différentes.
Wonko the Sane

@WonkotheSane: Il est vrai que le PO fait référence au chef de projet, au chef d'équipe et au développeur principal comme s'ils étaient tous la même chose, et c'est déroutant. Mais je me suis inspiré du contexte dans lequel ils sont utilisés.
pdr

@pdr - presque d'accord. La partie sur "Je peux tirer parti des modèles de conception et des paradigmes OO" me fait un peu me demander.
Wonko the Sane

6

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.)


4

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:

  • Quelles compétences chaque membre de votre équipe apporte-t-il à la table?
  • Quels composants sont essentiels à la réussite du projet?
  • Que devez-vous produire en plus du code réel? (Tests? Documentation?)
  • Comment rassemblerez-vous les exigences, si vous ne l'avez pas déjà fait?
  • Comment vous et votre équipe aborderez-vous le processus de conception?
  • Vous savez qu'il est important d' avoir une norme de codage, mais vous pouvez compter sur votre équipe pour déterminer exactement quelle norme elle veut suivre.
  • Comment pouvez-vous détecter les problèmes tôt?

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.


2

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.


3
Je dirais que c'est exactement le contraire de ce qu'il faut faire en tant que manager. Il peut être tentant d'entrer et de jeter du code, mais ce n'est plus votre travail ... votre travail consiste à permettre à votre équipe de faire ce que vous avez embauché et de faire confiance à son expérience et à son jugement. Essayer de se mettre à niveau sur une autre plateforme est contre-productif.
Michael Brown

@MikeBrown Cela n'est vrai que si le poste est de gestion. Tous les postes de direction d'équipe que j'ai occupés ont nécessité un temps de codage important en plus de la gestion de projet, de la planification et des autres responsabilités que vous attendez de ce poste. Si le PO avait dit qu'il devait être gestionnaire , ma réponse aurait été très différente.
S.Robins

Tu as raison. J'assumais le manager du fait que c'était pour une technologie dans laquelle il n'avait aucune expérience. Faites un montage et j'annulerai mon downvote :)
Michael Brown

@MikeBrown Je ne sais pas ce que vous pensez que je dois modifier. J'ai répondu à la question du PO sur la base de sa propre déclaration selon laquelle il devait devenir chef de projet ... cependant, je vais étendre un peu la réponse. :)
S.Robins

Oh, ce n'était pas que je pensais que vous deviez modifier ... juste que SO ne me laisserait pas changer mon vote sans modifier :(
Michael Brown

1

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.


1

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!


0

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.


0

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!


-1

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.

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.

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.

Vrai.

Apprenez de la communauté open source.


2
Parfois, les personnes travaillant sur des projets open source n'utilisent pas les meilleurs outils disponibles ou ne suivent même pas les normes (bonnes pratiques). Je connais peu de projets open source (je ne veux pas les nommer) qui sont vraiment très mauvais en termes d'utilisation des bons outils ou même de respect des conventions de l'industrie.
Christian P

@ChristianP: Bien qu'il existe des projets open source moins que stellaires, il est facile d'en trouver de grands qui sont assez bons. Et trouver n'importe quel projet open source comme exemple est mieux que pas d'exemple du tout.
S.Lott

Je suis d'accord que n'importe quel exemple est meilleur qu'aucun. Mais lors de la recherche de bonnes pratiques, d'outils, etc., on peut en apprendre plus d'un bon projet open source même si le projet ne résout pas le même problème.
Christian P
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.