Dans le désert des talents qualifiés, les développeurs d'eau sont en demande comme l'eau, même s'ils sont portés à la main ou insultés, mais c'est un fait. Sans eux, il n'y aura pas d'industrie et eux-mêmes en sont bien conscients. Cela conduit à un tel sentiment passionnant de droit de soi, qui est rarement vu dans l'histoire humaine. En conséquence, tout un éventail de personnalités à problèmes très brillantes est né.
Un bon développeur peut valoir son pesant d'or -
littéralement . Dans quelques professions, ce revenu est possible. Certaines des personnes les plus riches de la planète étaient des programmeurs, donc être un développeur au bon moment et au bon endroit est l'un des chemins les plus faciles et les plus directs vers une grande richesse.
Mais avec de telles opportunités vient souvent un manque total de respect pour les participants au projet dans d'autres professions. Ce manque de respect peut s’avérer si profond qu’il fait naître une ferme conviction dans l’esprit du développeur qu’il n’est pas seulement le participant le plus précieux du projet logiciel, mais également nécessaire pour l’entreprise dans son ensemble. Malheureusement, bien que seul un petit nombre de développeurs soient capables d'accumuler quelque chose qui ressemble à de la richesse, beaucoup se comportent comme s'ils suivaient Mark Zuckerberg, Bill Gates ou Steve Jobs; bien que ce soit très loin de la vérité. Cela conduit à des problèmes de personnalité, qui sont tout aussi excitants à regarder de côté qu'il est effrayant de les contempler en soi.
Voici
les identités problématiques parmi les développeurs de logiciels:
Prima donna
Le développeur est tellement convaincu de son caractère indispensable qu'il devient arrogant et impossible à diriger.
Le problème
À un certain niveau, pour gérer l'employé, il doit faire ce que vous dites. La prima donna ne peut pas être contrôlée, car de par sa nature même, elle ne croit pas qu'elle fonctionne pour vous. À son avis, c'est votre privilège de travailler avec lui. Il se considère tout à fait indispensable et juste dans toute discussion.
Contrairement à sa propre conviction, la prima donna n'est pas nécessairement une développeur qualifiée (voir
type rock star ). Son arrogance repose sur la présentation de sa place dans l'organisation, et non sur de réelles compétences techniques. En conséquence, les prima donnas notent trop souvent leur niveau de compétence beaucoup plus élevé que celui de leurs pairs,
bien que ce ne soit pas le cas . Cela conduit généralement au fait que la prima donna n'est généralement pas appréciée par ses collègues.
Vous pouvez identifier une prima donna par des expressions typiques:
- "C'est stupide - je ne le ferai pas de cette façon"
- "Nous devons le faire comme ça."
- "Si vous ne l'aimez pas, vous pouvez parler à mon manager"
- "Eh bien, nous verrons."
- "Je vais parler à ton patron et voir ce qu'il dit"
La prima donna n'accepte pas le leadership. Il considère toute tentative de leadership comme une insulte, car il est surtout tenu responsable de ses actes. Ce problème de personnalité se rencontre couramment chez les développeurs de longue date qui sont profondément impliqués dans le succès précoce des entreprises. Aujourd'hui, des années plus tard, grâce à de nombreuses années de relations avec les fondateurs de l'entreprise, il considère son opinion plus élevée que celle d'un simple cadre intermédiaire.
La prima donna ne représente pas un danger matériel pour le projet, car elle ne fait généralement rien, mais ne fait que secouer la loi. Cependant, cela affecte négativement le moral de l'équipe, en particulier des nouveaux développeurs plus productifs. Par conséquent, il doit être mis en place pour que le projet se déroule correctement.
Solution
La solution pour la diva est de réfuter la croyance de base:
qu'il est irremplaçable et peut donc faire ce qu'il veut . Le moyen le plus direct de réfuter cette croyance est d'engager un remplaçant pour travailler en étroite collaboration avec lui. Afin de faire savoir à la prima donna qu'il s'agit bien de son remplaçant, deux conditions doivent être remplies:
- Le remplacement devrait être plus qualifié.
- Il est nécessaire de faire comprendre à la prima donna que son remplaçant n'a d'autre tâche que de suivre l'ombre de la prima donna et d'apprendre à la remplacer.
Plus le remplaçant rassemblera rapidement toutes les connaissances sur le code hérité que la prima donna peut posséder (voir les types de développeurs que
le gardien de code hérité et le
preneur d'otages ), plus vite la prima donna reprendra le contrôle. L'effet peut être dramatique: tout peut changer en quelques jours seulement. Dans la forme, la diva commence à remplir une fonction supplémentaire à son remplacement. En fin de compte, il n'est plus indispensable, et donc plus une diva, mais simplement un pauvre employé.
Le seul espoir de la prima donna est de maintenir un sentiment de statut - d'obtenir une promotion à un poste de direction (voir un développeur comme le
marquage des gestionnaires ). Mieux il sera averti, plus tôt un remplaçant apparaîtra, il tentera de le faire. Cependant, l'augmentation n'est pas recommandée, car vous risquez de voir le licenciement des développeurs dont la diva est responsable. Par conséquent, lorsqu'il rejette une demande de promotion, il n'a que deux options: se tenir au même niveau que les autres développeurs ou partir. Dans tous les cas, votre problème est résolu.
Idéaliste
Le développeur est tellement obsédé par l'élégance architecturale et l'excellence du code qu'il oublie que son travail devrait profiter à l'entreprise.
Le problème
Le métier d'ingénieur logiciel nécessite un équilibre constant de deux tâches opposées:
- Le désir de bénéficier à l'entreprise (et d'être payé).
- Le désir d'écrire un excellent logiciel (et d'être fier).
L'idéaliste a complètement ignoré l'objectif de bénéficier à l'entreprise et s'est concentré uniquement sur l'écriture d'excellents logiciels.
Le développeur idéaliste est généralement très intelligent, expérimenté et professionnel. Il sait vraiment de quoi il parle. Il sait vraiment écrire un excellent logiciel, et s'il dispose de suffisamment de temps, il peut créer le système parfait. Le problème est
qu'il croit avoir tout le temps du monde et une liberté totale , bien que ce soit loin d'être le cas.
Au lieu de faire des compromis, il s'est concentré sur la création du système parfait. Il pense que c'est mieux pour les affaires. Ne les confondez pas avec des scientifiques qui créent quelque chose «d'absolu» ou de «cool»: les idéalistes croient sincèrement que leur système idéal est le mieux adapté au développement de l'entreprise. C'est à cause de la constance de cette foi qu'ils sont si difficiles à corriger.
Les idéalistes sont particulièrement dangereux pour le projet, car ils ont généralement le pouvoir sur les autres développeurs clés, car ils représentent l'idéal recherché par les développeurs, ils sont donc si faciles à obtenir d'autres programmeurs à leurs côtés, car tous les développeurs veulent être fiers du logiciel qu'ils écrivent. Ainsi,
ils prennent en otage toute l'équipe de développement , et vous êtes maintenant en leur pouvoir. Si vous êtes chanceux, ils commenceront à fournir de la valeur à l'entreprise, mais ce ne sera qu'un effet secondaire aléatoire dans leur quête pour créer un excellent logiciel. En fait, les avantages pour l'entreprise n'apparaîtront qu'à la fin du travail, mais ils ne peuvent pas vous dire le délai ni évaluer cet avantage. En vérité, ils ne sont même pas intéressés à terminer, car c'est le processus lui-même, et non le but, qui les satisfait.
Solution
Nous résumons les traits idéalistes:
- Très intelligent, expérimenté et professionnel.
- Croit sincèrement que son système est meilleur pour l'avenir de l'entreprise.
À bien des égards, il est un très bon employé, et si vous regardez les entreprises les plus innovantes au monde, elles ont beaucoup d'idéalistes dans les départements de recherche et développement. Cependant, les meilleures entreprises ont trois choses que les autres n'ont pas:
- Le personnel de direction est aussi compétent que les idéalistes, offrant des freins et contrepoids pour ses décisions techniques.
- L'espoir qu'un certain nombre de projets échouent, ce qui est le coût habituel de faire des affaires.
- Un budget important pour continuer à financer des projets non rentables.
Si votre entreprise a ces trois choses, laissez l'idéaliste tranquille, laissez-le faire ce qu'il veut. Mais si vous, comme la plupart des entreprises, ne disposez pas de ces conditions luxueuses, un vrai problème apparaît, car presque tout ce que vous faites entraînera un désastre:
- Si vous le renvoyez immédiatement, les développeurs fidèles pourront bientôt le suivre.
- Si vous définissez des règles strictes, il peut se déconnecter mentalement du projet, ce qui vous laissera sans conseils techniques.
- Si vous le laissez tranquille, les autorités finiront par se lasser du manque de progrès tangibles.
Pour forcer un idéaliste à changer de comportement, vous devez trouver quelqu'un qui peut le convaincre. Cette personne doit démontrer à l'idéaliste qu'il peut, lui aussi, créer un excellent système. C'est important, car une personne sans compétence technique sera simplement ignorée car incapable de comprendre le génie d'un design idéal.
Si une personne avec une telle confiance est trouvée, elle devra dériver lentement et méthodiquement l'idéaliste de sa façon de penser idéaliste. Cela nécessite qu'un professionnel hautement intelligent et expérimenté soit prêt à faire ce qu'il pense être juste. Les chances de cela sont peu nombreuses et, par conséquent, il y a peu de chances de corriger l'idéaliste.
Rock star
Le développeur est si talentueux, si productif, si important que s'il part, tout le projet s'effondre.
- Peut muter en preneur d'otages et diva
- C'est dangereux en combinaison avec un gestionnaire de type optimiste
- Possibilité de correction: non
- Danger du projet: extrêmement élevé
Le problème
Dans l'industrie du logiciel, le terme "rock star" est souvent utilisé par les recruteurs qui tentent d'attirer les développeurs en gonflant leur ego, c'est-à-dire "nous recherchons plusieurs développeurs de rock stars". Il est difficile de trouver de vraies stars du rock, car ce sont des programmeurs idéaux:
- Il n'y a aucun problème qu'ils ne peuvent résoudre (et rapidement).
- Ils travaillent toute la nuit pour rattraper le délai.
- Il n'y a pratiquement aucun bogue dans leur code ou des bogues sont rapidement corrigés.
- Ils prennent en charge les parties les plus difficiles du projet.
- Ils aiment généralement beaucoup leurs collègues.
Malheureusement, une fois embauchés, ils deviennent indispensables dans le projet.
Une rock star ressemble à un trou noir: le travail s'accumule autour d'eux et finit inévitablement par être aspiré. Il peut arriver qu'ils enlèvent du travail à des développeurs plus lents pour respecter les délais - au grand soulagement de tous. Si le projet se retrouve dans un dilemme, ils sauveront la situation. Si quelque chose de dramatique et d'inattendu se produit, ils sauront quoi faire. Ils sont vraiment formidables - et chaque recruteur le sait.
Les recruteurs appellent une rock star plusieurs fois par jour. Leur réputation les précède. Les entreprises veulent toujours attirer les stars du rock, car elles comprennent leur valeur, et dans de nombreux cas, elles feront presque tout pour les obtenir. Par conséquent, la situation est qu'il y a quelqu'un d'indispensable pour votre projet, qu'une entreprise sur deux veut attirer. S'ils le font, le projet échouera. Le cas classique est celui où trop d'oeufs sont placés dans le même panier.
Solution
Il n'y a pas de "solution" pour une rock star. En fin de compte, seul un imbécile voudra le «réparer», car il est votre développeur le plus productif à ce jour. Tout ce que vous pouvez faire est d'atténuer les dégâts en créant une équipe autour qui peut fonctionner efficacement s'il part. Très probablement, vous aurez besoin de plusieurs développeurs pour remplacer les performances d'une rock star, mais au moins vous pourrez survivre à son départ.
Pour vérifier la gravité de votre situation, portez une attention particulière à la productivité des développeurs lorsqu'une rock star part en vacances. Si pendant son absence hebdomadaire, tout développement s'arrête, vous devez redoubler d'efforts pour amener les autres développeurs au niveau où ils peuvent maintenir le développement du projet en l'absence d'une rock star.
Cela peut être difficile si les développeurs sont habitués au fait qu'il fait face à des problèmes complexes, ils deviennent paresseux et suffisants. Il y a une chance qu'avec le départ soudain de la rock star, d'autres développeurs passeront à l'action. Mais, très probablement, ils l'aiment tellement qu'ils le suivront dans une nouvelle entreprise.
Marquage chez les managers
Un développeur qui a décidé d'éviter les difficultés de programmation et de devenir l'un des managers.
Le problème
La programmation est difficile à apprendre. Cela nécessite la capacité de résoudre rapidement des problèmes, une grande quantité de connaissances et une expérience encore plus réelle. Contrairement à des domaines professionnels comparables, ces connaissances et expériences deviennent obsolètes beaucoup plus rapidement (parfois en quelques mois), ce qui nécessite le développement constant de nouvelles méthodes, technologies et outils. Jeter des gestionnaires
veut se débarrasser de cette agitation et voit une issue à la gestion .
En règle générale, pour les responsables du développement, les exigences en matière de compétences en programmation sont plus faibles que pour les développeurs. Le temps est consacré aux réunions, à l'envoi d'e-mails ou même à la marche et au chat avec d'autres personnes. Les managers ont également tendance à gagner plus que les codeurs, mais avec le statut viennent les pouvoirs. C'est un choix évident pour les développeurs qui veulent se débarrasser de l'écriture de logiciels.
Le problème avec le développeur, qui a commencé à penser à la carrière du manager, est qu'il cherche à démontrer ses compétences en gestion dans l'espoir d'une amélioration,
plutôt que de penser à la programmation . Pour mettre en pratique ses compétences en gestion, le futur manager essaie de commander à ses collègues développeurs: attribue le travail, parle lors des réunions et, en règle générale, cherche à participer à la prise de décisions plus stratégiques. Par conséquent, ils ne sont pas également aimés par les autres développeurs et autres gestionnaires qui voient une menace pour leur travail.
Solution
Il est impossible de résoudre le problème du futur manager, car il a déjà fait un choix de carrière clair. Une fois la décision prise, il n'y a plus de retour en arrière. Vous ne pouvez pas le forcer à réécrire des programmes. Même forcé, vous trouverez bientôt la raison pour laquelle il a commencé à penser à la carrière d'un manager: le gars n'est pas très bon en programmation. En raison de la complexité de cette situation, de nombreux programmeurs et managers obtiennent ce qu'ils veulent: une promotion au poste de manager, s'il y a une vacance.
En règle générale, les développeurs dans cette position ne sont pas particulièrement nuisibles au projet, car leur productivité est trop faible et ils n'ont généralement pas la confiance particulière des développeurs ou des gestionnaires. Souvent, ces personnes tout au long de leur carrière traînent dans l'organisation, et la
haute direction a du mal à trouver une application pour elle . En tant que tels, ils peuvent devenir dangereux s'ils sont chargés d'une mission critique, mais comme cela peut être complètement évité, ils peuvent rester en toute sécurité un petit facteur gênant.
Preneur d'otages
Un développeur qui a écrit un logiciel critique et ne permet à personne de travailler dessus afin de maintenir son caractère indispensable.
Le problème
Il est important pour toute personne ayant des obligations financières d'assurer la sécurité de son lieu de travail et de son salaire. De plus, travailler avec du code familier est beaucoup plus facile que de travailler avec du code inconnu. De la combinaison de ces deux désirs, un preneur d'otages est né - un développeur qui a
écrit et possède seul un logiciel critique, refusant de travailler sur autre chose .
En règle générale, il s'agit d'un mauvais ingénieur logiciel, ce qui, ironiquement, devient un avantage important: son code n'est
généralement pas compréhensible pour quiconque , alors les autres développeurs ont peur de pénétrer dans un tel marécage, craignant de faire plus de mal que de bien. Par conséquent, tous les nouveaux travaux sur un système critique sont transférés à l'envahisseur, poursuivant ainsi le cercle vicieux.
Le preneur d'otages adopte généralement une position défensive et conflictuelle, il est absolument fermé aux critiques ou à la coopération concernant sa base de code. Si vous le conduisez vraiment dans un coin, il menacera de partir, et puisque personne d'autre ne veut prendre un produit mal conçu et écrit, un tel bluff est rarement puni. Ils peuvent devenir un goulot d'étranglement dans le projet, car tout le sort du projet dépendra de leur désir et de leur capacité à émettre un code.
Solution
Quel que soit le danger du relanceur d'otages, la solution est simple: attribuer à deux développeurs ou plus la responsabilité d'une partie du système envahisseur, le transférer dans une autre partie.
Pendant un certain temps, les performances seront faibles jusqu'à ce que les nouveaux développeurs essaient de comprendre et de retravailler le code, mais à la fin de cette période, l'envahisseur est complètement neutralisé et ne présentera plus de problème.Éléphant dans un magasin de porcelaine
Le développeur est tellement concentré sur l'achèvement du travail qu'il abandonne complètement tout concept de qualité.
- Peut muter en soldat
- Il est dangereux en combinaison avec un chef de projet tel qu'un tyran et un testeur de type tuyau d'incendie
- Possibilité de correction: élevée
- Danger pour le projet: moyen
Le problème
Les développeurs sont toujours soumis à une pression énorme. «Internet ne dort jamais» signifie que les développeurs ne dorment pas non plus. Pour rétablir l'apparence d'un équilibre entre le travail et la vie, un éléphant dans un magasin de porcelaine veut compléter sa liste de tâches dès que possible et retourner à la maison avec sa famille.Ce type de programmeur crée une pression de projet. Peu importe la qualité du développeur, si la pression augmente dans une certaine mesure, il cessera inévitablement de tester son propre travail et s'appuiera plutôt sur le service de test (voir le type de testeur, le procureur) comme seul moyen de détecter les erreurs. En outre, pour des raisons de commodité, ils refuseront de vérifier le code par les pairs, de tester et de refactoriser automatiquement, laissant le code en mauvais état. Ce logiciel mal conçu provoque alors de nouvelles erreurs, et la base de code se transforme rapidement en marécage de bugs qui ne peuvent pas être complètement corrigés.Un éléphant dans un magasin de porcelaine vit dans un stress constant en raison de la pression de ses supérieurs. Il est victime d'un projet mal planifié, mais le développeur est toujours considéré comme un problème. C'est en ce qui concerne les éléphants dans le magasin de porcelaine que l'expression «burnout et remplacement» est utilisée, car un stress constant finira par les briser et ils partiront ou seront licenciés en raison de leur apparente incompétence.Solution
Étant donné que le problème ne concerne pas l'individu, l'organisation doit prendre les mesures suivantes:- , . .
- , .
- . . , , .
- , . , .
- , , .
Bien que ces étapes puissent clairement résoudre le problème, elles ne sont presque jamais prises. C'est-à-dire que la gestion reste la cause du problème, pas la source de la solution. Mais si la direction reconnaît son rôle dans l'apparition des éléphants dans le magasin de porcelaine, alors dans quelques semaines, les dommages peuvent être compensés et le développement du projet reviendra à la normale.Incompétent
Un développeur qui n'a pas l'intelligence ou les compétences pour écrire des logiciels.
Le problème
Tout le monde n'est pas en mesure de devenir un athlète professionnel, un musicien expérimenté ou un médecin. Il y a aussi des gens qui ne sont tout simplement pas créés pour être des développeurs de logiciels. Ces développeurs incompétents nient souvent leur incompétence et refusent de quitter la profession en raison du salaire élevé et du grand nombre de postes disponibles.Il peut être difficile pour un gestionnaire sans formation technique de reconnaître un développeur incompétent, mais il existe plusieurs signes:- Dans leur faible productivité, ils reprochent le manque de formation en entreprise.
- L'utilisation de technologies, d'outils et de méthodes «trop complexes» est contestée.
- Surestimez fortement le délai de travail (voir pessimiste ), puis ne le respectez pas à temps.
- Ils produisent des fonctions qui ne répondent pas aux spécifications.
- Les fonctions implémentées sont pleines d'erreurs.
- Les développeurs expérimentés évitent ou refusent de travailler avec eux.
- Lorsqu'on les interroge sur les progrès, ils font des excuses et prennent souvent une position défensive.
- Ils postulent pour un poste d'encadrement (voir marquage des managers ) afin d'apporter «plus d'avantages».
Toute l'industrie du logiciel souffre d'un problème d'incompétence. Il s'agit d'un exemple simple de l'offre et de la demande lorsqu'il n'y a pas suffisamment de développeurs qualifiés sur le marché du travail.Solution
Lorsqu'un gestionnaire remarque un développeur incompétent, le sens naturel de l'empathie le pousse souvent à attribuer des tâches plus facilement. Malheureusement, tout comme on ne peut pas être un chirurgien cardiaque semi-alphabétisé ou un pilote partiellement compétent, personne ne peut être développeur de logiciels seulement partiellement compétent. Si vous n'avez pas la compétence pour développer des logiciels, vous ne pourrez pas bien exécuter même des tâches simples.Lorsque les tâches simples sont trop complexes, l'étape suivante consiste généralement à réserver un budget de formation. Le principal problème ici est que si un développeur incompétent pouvait apprendre, il le ferait déjà - comme ses collègues les plus compétents, car les développeurs compétents apprennent eux-mêmes.On pense que la présence d'un développeur peu productif dans l'État ne fait pas de mal, mais c'est une grosse erreur. Ils provoquent deux effets très dommageables:- Destruction de la qualité de la base de code, apparition d'un nouveau code buggy et introduction de bugs dans le code de travail (voir aussi l' éléphant dans la boutique de porcelaine )
- Ils repoussent les développeurs compétents qui en ont assez de travailler avec eux.
En fin de compte, si le projet dépend d'un développeur incompétent, le projet ne sera pas terminé . Cela conduit à la triste conclusion que ces travailleurs doivent quitter l'organisation. S'ils ne sont pas d'accord (généralement après des indices de plus en plus directs), ils doivent être renvoyés.Optimist
Un développeur qui sous-estime constamment le temps nécessaire pour terminer une tâche.
- Peut muter en pessimiste
- Dangereux lorsqu'il est associé à un chef de projet optimiste
- Possibilité de correction: élevée
- Danger pour le projet: moyen
Le problème
La sous-estimation des délais est un symptôme si courant dans l'industrie du logiciel que beaucoup ne considèrent même pas cela comme un problème. Tout le monde sous-estime toujours le calendrier, et dans de nombreux cas, cela est accepté dans le cadre de l'entreprise. Néanmoins, le développeur optimiste prend le problème à un tout autre niveau, car il abandonne presque toujours le travail beaucoup plus tard.Un optimiste influence la prévisibilité d'un projet: sans bonnes notes, il est impossible de planifier pour l'avenir. La sortie du logiciel est parfois associée à des obligations contractuelles avec les clients et / ou partenaires, ce qui fait de la prévisibilité une nécessité commerciale. Bien sûr, vous pouvez toujours vous attendre à un peu d'imprévisibilité, car en réalité, l'ensemble de l'industrie du logiciel est construit autour du fait qu'il est impossible de prédire avec précision le temps qu'il faut pour écrire un logiciel. L'optimiste abuse de cette tolérance pour le non-respect des délais, accomplissant ses tâches en quelques semaines au lieu des quelques jours promis; ou, pire encore, dans quelques mois au lieu des quelques semaines promises.L'optimiste ne comprend pas fondamentalement l'impact négatif de ces retards sur la réussite globale du projet. Il peut également considérer que l'évaluation elle-même est une pratique futile, car rien ne peut jamais être estimé avec précision. Ainsi, il peut évaluer de manière impressionnante ou donner un nombre arbitraire sans aucune analyse.Solution
Heureusement, un optimiste peut être corrigé en suivant quelques règles:- Demandez-leur d'évaluer uniquement le code qu'ils connaissent.
- Demandez une évaluation uniquement pour les technologies qu'ils connaissent.
- Ne demandez jamais d'évaluer le calendrier de mise en œuvre de nouvelles fonctions, mais améliorez uniquement celles existantes.
- Il faut veiller à ce qu'ils comprennent parfaitement toutes les exigences - ils ne peuvent pas interpréter librement les exigences à la volée.
- Demandez à l'optimiste d'ajouter des commentaires «TODO» dans les domaines où il devra apporter des modifications. Cela renforcera la relation entre la complexité du logiciel et les délais.
- Rendez-les responsables: montrez leurs notes à un groupe qui peut contester de tels délais.
Lorsque l'optimiste a traversé ce processus à plusieurs reprises et a rempli ses obligations, vous pouvez commencer à vous fier à son évaluation des termes des nouvelles fonctions, ainsi qu'aux bases de code et aux technologies qu'il connaît moins.Pendant le processus de réhabilitation d'un optimiste, portez une attention particulière à la façon dont il respecte ses délais:- La qualité du travail souffre-t-elle d'obligations accrues (voir l' éléphant dans la porcelaine ). Si oui, suggérez d'ajouter le temps nécessaire pour les tests.
- Travaillent-ils des heures supplémentaires pour respecter les délais (voir soldat )? Dans ce cas, suggérez d'ajouter du temps pour terminer le travail pendant les heures ouvrables, et les heures supplémentaires devraient rester pour des circonstances imprévues.
Si un optimiste prend sa réhabilitation au sérieux, il peut devenir un membre de l'équipe hautement fiable, car les développeurs sont fiables et émettent un code de qualité suffisante qui répond aux exigences dans un délai convenu. Dès qu'ils prouvent qu'ils peuvent le faire de manière stable, ils peuvent obtenir une promotion ou un salaire, qui peut en soi être offert comme incitation à leur réadaptation.Pessimiste
Un développeur qui a tellement peur de manquer des délais qu'il demande le maximum de temps possible pour terminer la tâche.
Le problème
S'il y a un choix, la plupart des chefs de projet préféreraient les pessimistes aux optimistes. Bien qu'ils puissent fonctionner longtemps, ils sont au moins prévisibles. Le pessimiste le sait très bien et profite pleinement de cette circonstance, demandant le maximum de temps pour sa tâche, au lieu de considérer des termes réalistes.Les pessimistes sont parfois impossibles à remarquer. Ils peuvent être confondus avec matures et responsables, car contrairement à leurs collègues développeurs apparemment moins expérimentés, ils ne manquent jamais la date limite. Mais il y a quelques signes:- Leurs collègues développeurs avec la même évaluation donnent des délais d'exécution beaucoup plus courts.
- Si vous leur attribuez un délai, ils acceptent immédiatement, sans aucune évaluation formelle.
- Lorsqu'ils ont rapidement accepté, si vous déplacez légèrement la date vers une date antérieure, ils accepteraient également cette date. Cela signifie qu'entre les deux dates, cela ne prend vraiment pas de temps supplémentaire pour terminer la tâche.
Un pessimiste peut réduire la compétitivité d'une entreprise. Si vous participez à une course avec un concurrent, vous serez toujours plus lent que lui.Solution
Les pessimistes sont nés de la faute d'une organisation qui sanctionne le non-respect des délais. La réaction naturelle des gens est de demander autant de temps que possible afin de minimiser la probabilité de punition. Cela peut sembler une solution facile, mais trois choses vous sont défavorables:- Le travail pessimiste est beaucoup moins stressant que le travail normal.
- Les pessimistes sont généralement récompensés et promus plus souvent que ceux qui manquent des délais importants.
- Les entreprises devraient être plus tolérantes d'être en retard. Lorsqu'une certaine culture de développement est établie, la plupart des entreprises n'en sont pas capables.
Par conséquent, le problème peut être résolu, mais il n'y a généralement pas de volonté de le résoudre. De par leur nature, les pessimistes ne constituent pas une menace pour le projet, mais sont potentiellement très dangereux pour la viabilité future de l'entreprise.Un soldat
Un développeur qui fait exactement ce qu'il dit, sans aucun doute, que ce soit correct ou non.
Le problème
Du point de vue d'un gestionnaire, qui peut être meilleur qu'un développeur qui fait exactement ce qui est dit? En effet, le principal problème de la prima donna est qu'elle ne suit pas les ordres. Bien sûr, un développeur pleinement obéissant est une aubaine pour le projet. Malheureusement, le soldat a son propre inconvénient: il sautera docilement dans l'abîme, s'ils le lui disent, emportant avec lui tout le projet .Un soldat peut avoir n'importe quel niveau de compétence: de l' incompétent à la rock star . Une caractéristique clé est son obéissance: à chaque fois, il fera exactement ce que vous lui direz. Il est facile de faire une erreur, considérant cela comme un effet de leadership fantastique, mais les excellents patrons sont très rares.Les soldats sont nés de plusieurs manières:- , : . , , .
- , , , .
- , , , .
- , , , - .
- , , .
- , — , .
- Ils se sont convaincus que la soumission complète est le chemin de la croissance de carrière, ce qui est très triste, car cela n'est presque jamais vrai dans le domaine innovant du développement logiciel.
- Ce sont vraiment d'anciens militaires qui ont apporté avec eux une mentalité particulière.
Par conséquent, peu importe à quel point il peut sembler agréable d'avoir un soldat à son commandement, ce n'est guère bon.Solution
Si vous donnez les bons ordres, le soldat ne causera aucun problème. En fait, avec un leadership fort, la présence d'un détachement de soldats est une arme très efficace. Mais si vous avez besoin des commentaires des développeurs pour vous aider à mener le projet ensemble, vous n'obtiendrez pas une telle coopération. Cela vous laisse dans une situation de suspense, lorsque vous ne savez même pas que vous manquez quelque chose. Mais le soldat ne le dira pas.Si vous pouvez déterminer la raison pour laquelle le soldat vous obéit implicitement, alors il y a une chance de le réparer. Cependant, par nature, il ne dira pas ouvertement pourquoi il l'est devenu. En règle générale, un soldat préfère communiquer sur des sujets de travail spécifiques. Si vous appuyez et demandez s'il y a un problème, la réponse la plus probable est «Non», quels que soient ses véritables sentiments.Vous ne pouvez qu'espérer que ses collègues parleront du soldat, mais alors ils trahiront sa confiance, ce qui est peu probable. Même si vous identifiez le vrai problème, vous devrez le résoudre, ce qui peut être difficile. Ensuite, après avoir éliminé la cause profonde, il reste à espérer que le soldat va changer son comportement. Lui seul peut se changer.En général, ils sont presque impossibles à corriger. Ce sont donc généralement de bons employés pour soutenir un leader fort.Fan de technologie
Un développeur qui est si heureux d'essayer de nouvelles technologies qu'il les mettra en œuvre dans le projet, est-ce approprié ou non?
- Peut muter en preneur d'otages
- Dangereux en combinaison avec l' idéaliste
- Possibilité de correction: élevée
- Danger pour le projet: faible
Le problème
Pour réussir le lancement du produit, vous devez sélectionner la technologie. Il s'agit d'un choix prudent en tenant compte d'un ensemble spécifique de problèmes commerciaux qui doivent être résolus. Un fan de technologie adore les nouveaux jouets.Tous les développeurs sont quelque peu amoureux de la technologie: ils doivent être capables de maintenir leurs compétences. Mais quand un développeur confond sa responsabilité professionnelle et sa curiosité personnelle, vous pouvez vous retrouver avec une pile technologique qui est extrêmement incompatible avec les tâches commerciales.Un développeur amoureux de la technologie est très facile à distinguer de la foule. Il préconisera souvent et publiquement l'utilisation des nouvelles technologies, souvent avec des arguments peu concluants. Il change aussi brusquement de technologie au milieu du travail, sans rien dire à personne, prenant les autres par surprise. Dans de nombreux cas, cela peut être une excellente solution technique à un problème spécifique, mais comme la technologie n'a pas passé le test approprié, elle peut en fait être mal adaptée au projet dans son ensemble.Solution
Les amateurs de technologie se répareront si l'entreprise a installé une pile technologique standard. Il vous suffit ensuite de vous assurer que les développeurs n'en dérogent pas. Si vous n'avez pas de pile technologique installée, il est fortement recommandé de la définir à l'avance, car il ne sera pas pratique de la saisir une fois que le ventilateur de la technologie commencera à devenir actif.
La nouvelle selon laquelle vous ne pouvez pas utiliser votre nouvelle technologie est susceptible de nuire au moral d'un amateur de technologie, mais ce moral peut être rapidement restauré en lui demandant de faire une présentation sur cette nouvelle technologie. Il s'agit d'une décision extrêmement saine, car après la présentation, l'équipe peut discuter ensemble de l'opportunité d'élargir la pile de technologies d'entreprise. La plupart des amateurs de technologie seront satisfaits d'un tel essai, même s'ils n'aiment pas la décision finale.
Gardien de l'héritage
Un développeur dont la seule capacité est de maintenir à jour des logiciels obsolètes et qui n'est donc pas en mesure de prendre un nouveau travail.
Le problème
Lorsqu'un nouveau développeur arrive dans l'entreprise, il est généralement plein de feu et de passion, essayant de faire ses preuves de toutes les manières possibles. Mais au fil du temps, la place de la passion prend de la complaisance: le développeur estime que l'expérience en entreprise lui confère certains privilèges. Pour lui, il reconnaît l'obligation de maintenir ses systèmes, mais pas d'entreprendre le développement de nouvelles pièces.
Le problème avec le gardien de code hérité est lié à la mise à l'échelle: ils ne sont tout simplement pas inclus dans le pool de ressources disponibles pour les nouveaux travaux. À ce stade, la question se pose de savoir si vous pouvez vous permettre de les garder au sein du personnel, c'est-à-dire si d'autres développeurs peuvent assumer leur tâche de maintenance du code hérité. Il est généralement difficile de convaincre d'autres développeurs de le faire pour deux raisons:
- Le code ancien est généralement mal écrit et difficile à utiliser.
- Le soutien est un cheminement de carrière sans issue car vous ne faites rien de nouveau ou d'innovation, pour lequel vous pourriez être marqué.
C'est pourquoi les anciens mainteneurs font partie de l'entreprise depuis si longtemps. Souvent, ils font partie de l'entreprise depuis sa création et sont les auteurs du logiciel sur lequel l'entreprise est fondée. Cependant, à mesure que la société grandissait, ils ne progressaient pas dans le service ou n'essayaient pas de maîtriser de nouvelles compétences ou de nouvelles parties du système, ce qui les rendait fermement attachés au seul code qu'ils connaissaient.
Solution
Le gestionnaire de code hérité ne crée pas de problèmes si vous comprenez qu'il ne fait pas partie des ressources pour travailler sur de nouveaux projets. Dans le meilleur des cas, vous pouvez lui demander de corriger les erreurs et d'implémenter de petites améliorations de fonctionnalités. Le seul problème se pose s'ils interdisent aux autres de se familiariser avec leur partie du système (voir
preneur d'otages ).
Le gardien ne peut pas être fixé parce qu'il n'a pas un tel désir. Il a la mentalité d'un ouvrier d'usine: tordre la même noix tous les jours tout au long de sa carrière, puis prendre sa retraite. Cette attitude ne peut pas être changée, car c'est l'essence de l'homme.
L'une des options qui peut changer cette attitude est si une personne connaît des événements importants dans la vie (mariage, accouchement, achat d'une maison, etc.), qui nécessiteront des revenus supplémentaires. Dans ce cas, il comprendra que la prise en charge de logiciels obsolètes n'entraînera pas d'augmentation. Malheureusement, vous ne contrôlez pas ce facteur.
Voir aussi: