Huit règles pour une production logicielle efficace

Au cours de ma carrière, j'ai participé à plusieurs projets logiciels réels et observé comment les choses se font à tous les niveaux : prise de décision, adoption des pratiques, constitution d'équipe, recrutement, répartition des compétences, etc. Évidemment, différentes approches ont donné des résultats différents. . Étant une personne orientée vers l'amélioration, j'ai remarqué et rassemblé les pratiques les plus efficaces et les meilleures astuces pratiques pour m'aider dans mon travail.

Apprendre de l'observation est une manière difficile et longue de le faire. Je serais extrêmement heureux de choisir cette connaissance plus tôt dans les livres à la place. Malheureusement, je n'en ai trouvé aucun sur le sujet. J'ai donc décidé de partager mon expérience avec d'autres chercheurs de ce genre de connaissances. Espérons que cela leur fera économiser quelques années de recherche personnelle.

Dans cet article, vous apprendrez comment vous pouvez battre les performances moyennes de l'industrie en produisant des produits logiciels robustes et fiables qui nécessitent 5 à 10 fois moins de maintenance. Je peux dire sans fausse modestie qu'au cours des 10-15 dernières années, j'ai (personnellement ainsi que mes équipes) dépassé toutes les attentes, laissant derrière moi une traînée de succès. Les gestionnaires ne peuvent pas être plus heureux.

Une fois, mon équipe a lancé un projet important dans un délai incroyablement court, pour lequel nous avons reçu le prix « Équipe de haute performance » de la part de la haute direction. Tout cela sans passer les nuits et les week-ends à s'épuiser. Juste un travail normal.

Vous voyez, une connaissance efficace de la production de logiciels est en elle-même un pouvoir. En fait, c'est une sorte de magie noire que peu de gens peuvent saisir même lorsqu'elle est expliquée en termes clairs. Vous l'obtiendrez gratuitement. Lisez la suite si vous voulez être perçu comme un magicien de la production de logiciels.

C'est pour qui ?

Permettez-moi de faire ici une clause de non-responsabilité importante, importante et importante.

Je m'adresse à ceux qui ont besoin d'un coup de pouce de productivité. Tout dans la vie n'est pas une question de productivité. Pas tous les projets logiciels non plus. Il y a des cas où vous n'êtes pas jugé sur votre performance. Évidemment, ces pratiques n'aideraient pas alors.

Ces techniques seront particulièrement utiles pour les chefs d'équipe, les architectes et les chefs de projet, bien que les développeurs de logiciels expérimentés puissent également en bénéficier.

Règle n°1 : Comprendre la mentalité informatique

L'industrie informatique est un mélange de science, de technologie, d'art et d'affaires. Il est assez difficile d'y naviguer sans comprendre ces aspects à un niveau suffisamment bon. Le plus gros problème est que l'industrie elle-même est assez complexe; par conséquent, les meilleures pratiques sont également complexes. Vous devez apprendre beaucoup et vérifier vos connaissances en pratiquant beaucoup pour réussir.

Le taux de mise à jour technologique incroyable le rend doublement difficile. Rien de ce que vous avez appris il y a dix ans n'est plus nécessaire. Il faut donc apprendre à un rythme accéléré.

En résumant tout ce qui précède, nous pouvons dire que réussir dans le domaine informatique ne repose pas sur des compétences ou des sentiments innés, mais sur des exemples concrets concrets. Ne jamais « suivre les tripes » ou croire uniquement en se basant sur les sentiments, y compris les vôtres.

Si oui, l'idée mérite réflexion. Sinon, exigez une très bonne et très détaillée explication sur la façon dont le choix de cette voie améliore la vie de votre équipe. S'il réussit ce test, planifiez un projet léger de preuve de concepts qui prouve expérimentalement qu'il s'intègre dans votre environnement.

La chose importante à comprendre ici est qu'il n'y a pas de bonnes et de mauvaises solutions car il existe de nombreuses façons de résoudre les problèmes logiciels. Cependant, il existe de bonnes et de mauvaises compréhensions de la solution.

Si une personne peut clairement articuler une idée en détail ou établir un lien entre l'adoption de cette solution et le succès de l'équipe pour persuader les autres membres de l'équipe, alors nous pouvons compter sur la vision de cette personne et espérer de grandes chances de succès.

Règle n°2 : ne mélangez pas les méthodologies de production de logiciels et de développement de logiciels

La production de logiciels est basée sur le développement de logiciels. Cependant, ces deux-là ont des objectifs, des mentalités et des pratiques complètement différents. Essayer de résoudre un problème de l'un de ces domaines avec les méthodes d'un autre produit des résultats ridicules. Il est important de comprendre la distinction et d'utiliser des méthodes appropriées pour chacun de ces mondes.

Le développement de logiciels est une combinaison d'art et d'artisanat. Le composant artistique sera toujours là, quels que soient les outils d'automatisation et les méthodologies de développement de logiciels disponibles. Par conséquent, la résolution des tâches de développement nécessite une concentration maximale et une protection contre tous les autres signaux gênants.

La meilleure façon de motiver un développeur expérimenté est de lui présenter une tâche sous sa forme purement technique en excluant tout facteur humain. Toutes les exigences doivent également être exprimées en langage technique. Ils doivent être facilement vérifiables pour leur permettre de naviguer vers l'objectif pendant leur phase de recherche en solo.

La production de logiciels, en revanche, relève davantage du domaine de l'administration des affaires. Vous savez ce dont votre client a besoin d'un côté et vous savez quelles ressources d'équipe vous avez à votre disposition d'un autre. Alors maintenant, vous essayez de diriger les efforts de votre équipe pour atteindre l'objectif. Pendant ce temps, vous pouvez également estimer votre vitesse de progression et présenter un plan bien documenté au patron. Les compétences importantes sont la compréhension des souhaits de votre client, la compréhension des forces de votre équipe et la communication de plans et d'échéanciers formels.

Ceci étant dit, j'aimerais souligner que de nombreux rôles dans le développement de logiciels travaillent dans ces deux mondes - en construisant un pont entre les affaires et la technologie - tels que les chefs d'équipe, les architectes, les analystes et les chefs de projet. Les personnes occupant ces rôles devraient être capables de se déplacer facilement entre deux plans de réalité et de comprendre quand il est temps de parler affaires et quand il est temps de parler art.

Règle n° 3 : Utiliser le stockage persistant comme extension de la mémoire humaine

La mémoire humaine, bien qu'incroyable en capacité, a ses limites. Vous vous souvenez des choses avec une précision et une durée imprévisibles, et lorsque vous oubliez, il n'y a aucun moyen de vous en souvenir à volonté.

C'est pourquoi nous utilisons un stockage en mémoire persistante pour avancer à une vitesse prévisible. Il ne s'agit pas de documentation formelle comme les manuels d'utilisation que vous créez longtemps après coup et que d'autres personnes peuvent utiliser. Il s'agit d'utiliser littéralement des documents comme extension externe de votre mémoire pendant le travail qui vous aide à passer par le processus de développement logiciel.

Je vous recommande de documenter vos pensées et vos plans en cours de route chaque fois que vous faites face à des tâches non triviales ou à des tâches qui impliquent plus d'une personne. Essayez de le rendre aussi bon marché que possible. Ne créez pas de documents formels avec le logo de l'entreprise dessus. Un bon outil serait un wiki d'entreprise avec votre espace de projet. Créez des pages dédiées aux tâches ou aux problèmes (30 secondes). Ensuite, mettez-le à jour chaque fois que vous avez une idée ou que vous êtes sur le point d'en discuter avec d'autres.

Lors d'une réunion, dites « attendez, laissez-moi écrire » et passez 10 à 30 secondes pour l'exprimer par écrit. L'écriture ne doit pas être longue, mais elle doit être complète et cohérente, comme si vous transfériez l'idée dans son intégralité sur le papier. Plus tard, vous ou toute autre personne lisant votre passage devriez le comprendre aussi clairement que vous le comprenez maintenant. Cette astuce permet de gagner beaucoup de temps, tout en vous permettant de documenter à la volée.

Cette technique a deux objectifs.

Tout d'abord, il verrouille votre progression sur la voie du succès en l'enfonçant fortement dans la pierre. Plus de risque que quelqu'un oublie quelque chose, réitère encore et encore la même chose ou renégocie la même chose qui a déjà été négociée.

Deuxièmement, vous faites le vide dans votre esprit, en vous débarrassant du problème qui vous tourmentait. Maintenant, votre esprit a faim pour le prochain défi. Quel gain de productivité !

Cela s'applique à n'importe quelle taille de projet ou de tâche. Pour les plus grands, vous aurez juste des espaces plus grands avec une hiérarchie de pages qui grandit au fur et à mesure que votre projet évolue. Le concept important ici est de préparer un espace et une structure de documentation avant de commencer votre tâche pour établir un protocole de vidage mémoire rapide !

Pour les personnes privilégiant les analogies technologiques, je comparerais notre esprit à un processeur doté d'une immense puissance de traitement mais d'une mémoire opérationnelle limitée. Vous pouvez essentiellement penser à une chose à la fois. Dans cette analogie, votre documentation sert de stockage persistant, tandis que votre esprit résout des problèmes complexes dans une approche itérative. À un moment donné, vous décidez de commencer la prochaine itération, de lire la documentation précédente et de charger l'état actuel dans votre mémoire opératoire, en y réfléchissant pendant un moment et en mettant à jour le code et la documentation avec vos nouvelles découvertes. Étape par étape jusqu'à ce qu'il soit terminé.

Tout ce qui précède étant dit, je n'encourage pas les gens à traiter un grand nombre de tâches à la fois. Au contraire, moins vous avez de tâches, mieux c'est. Cependant, peu de situations de travail sont vraiment optimisées pour l'homme, et le multitâche peut être nécessaire et vous devez le gérer d'une manière ou d'une autre. L'astuce ci-dessus aide à mieux le gérer.

Règle n°4 : Arrêtez de perdre du temps sur l'estimation formelle du temps

Il n'y a pas deux projets identiques. La prochaine fois que vous ferez un projet similaire, vous aurez des clients différents, des objectifs différents, une équipe différente ; peut-être même des technologies différentes. Même en utilisant des outils et des composants standard, vous devrez toujours personnaliser leur configuration et leur architecture. Lorsque vous gérez des projets logiciels, gardez à l'esprit qu'ils impliquent entre 50% et 100% de travail personnalisé. Ils nécessitent des recherches, des discussions, des réflexions, des essais et d'autres activités hautement imprévisibles. En pratique, vous pouvez rencontrer une énorme différence entre ce qui apparaît à la surface comme étant exactement le même type de projet et ce que vous avez fait auparavant. Un nouveau type de projet, par extension, est presque impossible à estimer exactement.

S'il est si imprévisible, comment les chefs de projet sont-ils censés présenter un calendrier de projet et s'y tenir ?

Il existe une méthode formelle pour le faire décrite dans la littérature; à savoir, pour diviser l'ensemble du projet en étapes plus petites, estimer la durée de chaque étape, puis calculer la durée totale du projet en combinant la durée de travail des pièces individuelles. Il y a des tonnes de théorie derrière cette méthode enseignée dans les cours de MBA.

Malheureusement, cependant, aucune quantité de mathématiques ne peut le sauver. Cette méthode est notoirement imprécise, dans la mesure où elle est complètement inutilisable et peu pratique, sans parler de son incroyable perte de temps. Je n'ai jamais vu un chef de projet qui utilisait des méthodes de calcul formelles sans aucun ajustement, pas même chez les mordus de méthodologie. Pas même lorsque l'entreprise imposait strictement l'utilisation d'une telle méthode ! En fait, les managers les plus performants utilisent des méthodes alternatives totalement différentes, décrites ci-dessous :

Un bon chef de projet tient compte du type de projet, de l'environnement, des ressources impliquées, du type d'organisation et de tous les autres aspects du travail qui influencent la durée réelle du projet. Bien sûr, personne n'a besoin d'apprendre uniquement de ses propres erreurs. De telles observations peuvent être faites à la fois directement et indirectement ; par exemple, à travers des livres ou en étudiant des projets réalisés par d'autres personnes ou même simplement en transmettant les connaissances de personne à personne. Une telle connaissance statistique de haut niveau améliore la navigation dans le calendrier du projet personnel.

Je voudrais souligner deux conséquences importantes de la méthode décrite ci-dessus.

Premièrement, la précision de l'estimation s'améliore avec l'expérience. Il n'y a aucun moyen possible pour une personne inexpérimentée armée d'une méthodologie solide quelle qu'elle soit d'être bonne dans ce domaine. Deuxièmement, même la meilleure estimation n'est bonne qu'en termes statistiques. Autrement dit, on peut dire qu'un certain projet peut prendre entre quatre et douze mois. En supposant que cela soit correct, il faut comprendre qu'il y a 50% de chances que le projet se déroule sur sa durée moyenne de huit mois.

Comprendre la prédiction statistique a un effet incroyable. Un gestionnaire avisé mettrait simplement une estimation de douze mois sur un projet comme celui-là, puis impressionnerait tout le monde en le terminant tôt. En d'autres termes, personne ne s'attendrait à ce qu'une équipe suive le calendrier du projet à une journée.

Le conseil général aux chefs de projet et à leurs patrons serait d'arrêter de perdre du temps avec des méthodologies formelles d'estimation du temps. Au lieu de cela, encouragez la collecte d'informations statistiques sur la durée du projet et partagez ces informations dans toute l'entreprise. Je connais des entreprises où une telle approche a été mise en œuvre à l'échelle de l'entreprise, ce qui a donné une précision prédictive miraculeuse.

Règle n° 5 : Comprendre le coût d'un changement de tâche et d'un jonglage avec les priorités

L'esprit humain est incroyablement conçu par la nature. Même si c'est incroyable, ça a ses limites. En d'autres termes, il est conçu pour exceller dans des domaines particuliers et dans un type de tâche particulier.

L'esprit d'un développeur est définitivement un atout majeur dans le développement de logiciels. En tant que chef de projet, seriez-vous intéressé à mieux le comprendre et à le placer dans une position où il fonctionne le mieux ?

Disons-le en termes simples, en évitant trop de théorie. N'oubliez pas que la théorie ne vous emmène que très loin avant que vous n'ayez besoin d'apprendre de l'expérience, soit la vôtre, soit celle des autres.

L'esprit humain a un fort potentiel de résolution de problèmes et de génération d'idées. Malheureusement, il n'est pas toujours possible d'exploiter ce potentiel, principalement parce que pour soutenir la génération d'idées, vous devez conserver tous les éléments du problème ensemble dans votre mémoire active en même temps. C'est pourquoi la résolution de problèmes complexes passe par une étape de simplification lorsqu'une tâche est généralisée ou reformulée pour supprimer des morceaux sans importance et pour diminuer le nombre d'éléments gardés en mémoire simultanément. En d'autres termes, nous pouvons soit résoudre un problème complexe très étroit, soit plusieurs problèmes simples.

Le rapport n'est cependant pas linéaire. Augmenter le nombre de choses que vous faites simultanément nuit considérablement à vos capacités de résolution de problèmes. C'est pourquoi l'humanité a toujours utilisé et utilisera la séparation des rôles comme une optimisation de la vie. Deux personnes travaillant séparément sur deux tâches feront une percée plus rapide que si elles travaillaient toutes les deux sur les deux tâches en même temps.

Un autre trait important de l'esprit humain est son incapacité à passer immédiatement d'une tâche à l'autre comme le font les ordinateurs. En effet, vous ne pouvez pas simplement arrêter de penser à quelque chose à volonté. Vous ne pouvez pas non plus immédiatement commencer à penser à un nouveau concept à toute vitesse. Cette sorte d'inertie mentale est parfaitement illustrée par les opérateurs du contrôle aérien. Même s'ils regardent le radar et voient l'ensemble de l'image, ils doivent toujours le charger dans leur mémoire pour opérer rapidement. Il faut dix minutes à un nouvel opérateur pour regarder l'écran avant de pouvoir remplacer l'ancien lors d'un changement d'équipe.

Ce qui est pire, c'est que nous ne pouvons pas oublier les choses à volonté. Tout ce que nous avons appris reste avec nous et s'estompe progressivement avec le temps, occupant un espace que nous pourrions utiliser pour de nouvelles connaissances. Et pire encore, cet effet est parfois aggravé par un sentiment de « travail inachevé ». Il est beaucoup plus facile d'oublier quelque chose qui est terminé et dont vous n'aurez plus jamais besoin à l'avenir. Alors que lorsque vous mettez les choses de côté pour les terminer plus tard, votre cerveau s'accroche naturellement aux informations marquées comme "pour référence future", ne voulant pas laisser de nouvelles connaissances prendre sa place.

D'accord. Maintenant que nous avons décrit l'idée de changer de tâche, voyons comment cela fonctionne dans une expérience de pensée réelle (pour ainsi dire).

Imaginez que vos dix développeurs habituels travaillent sur dix tâches régulières, une tâche par personne. En supposant que nous puissions les enfermer dans un environnement parfait sans distraction, chaque tâche peut être résolue en un certain laps de temps par un seul esprit. Le tout prendra le temps nécessaire pour accomplir la tâche la plus longue.

Maintenant, répétons la même expérience mentale. Cette fois, nous changerons constamment les affectations de tâches entre les développeurs sans raison (importante). Chaque jour, chaque développeur a une nouvelle tâche sur laquelle travailler. Encore mieux, changeons-le toutes les heures. Dans combien de temps finiront-ils, pensez-vous? Peut-être jamais.

Le chef de projet dans le premier scénario a pu exécuter le projet efficacement. Les seconds ont réussi à « l'exécuter », c'est sûr… dans le sens où ils ont facilité sa mort. Toutes nos félicitations. Cette technique de tuerie de projet est extrêmement efficace car, en plus de la simple perte de temps, elle fait également chuter le moral des employés à zéro.

La plupart des gens seraient d'accord avec l'exemple ci-dessus lorsqu'il leur est présenté d'une manière purement académique comme celle-là. Cependant, dans la vraie vie, ils oublient soudainement tout sous la moindre pression. Le grand patron exige un rapport d'avancement, ou le client demande une certaine date de mise en œuvre des fonctionnalités - presque n'importe quel événement externe peut amener un chef de projet à se précipiter vers l'équipe et à exprimer son inquiétude, suivi d'une vague de réaffectations de tâches et de jonglage des priorités dans un tenter de gagner un peu de temps ici et là, ce qui n'aboutit finalement qu'à faire dérailler encore plus le projet.

C'est un scénario réel qui se produit assez souvent, malheureusement.

Un bon manager se lève et protège l'équipe de ces perturbations mineures en absorbant l'onde de choc émotionnelle et en la convertissant en futurs sujets de discussion productifs. C'est certainement difficile émotionnellement, mais c'est la seule façon de maintenir l'équipe dans un bon rythme de travail et de les laisser livrer.

Règle n° 6 : Utiliser les revues d'architecture comme moyen d'améliorer la conception du système

L'industrie informatique fonctionne avec des notions de sur- et sous -ingénierie. Quand cela revient dans une interview, tout le monde dit que la sur-ingénierie est mauvaise. Il est facile de répondre à cette question car la question elle-même véhicule une connotation négative de "plus" qui signifie "trop". Le véritable savoir-faire pratique serait de reconnaître quand votre architecture devient trop technique et de l'éviter dès les premières étapes.

Permettez-moi de vous donner quelques-uns de mes conseils éprouvés à ce sujet.

Tout d'abord, la solution peut être considérée comme trop sophistiquée s'il existe une autre solution plus simple offrant toutes les fonctionnalités requises. Cela signifie que si vous ne connaissez pas de solution plus simple, la solution la plus simple que vous puissiez proposer est la meilleure à vos yeux, à moins que quelqu'un ne vous prouve le contraire.

Si notre architecte imaginaire s'efforce véritablement d'atteindre la perfection de la solution, la révision habituelle de l'architecture garantit qu'elle est suffisamment optimale. Malheureusement, l'examen de l'architecture nécessite au moins quelques autres architectes qualifiés. Il court le risque d'être indisponible ou peu pratique dans de nombreux cas. En l'absence d'examen par les pairs, les architectes sont sujets aux erreurs courantes. Examinons-les un par un et discutons des remèdes possibles pour chacun.

L'une des erreurs les plus courantes consiste à concevoir sans objectif commercial en tête. Il semble évident que toute activité professionnelle devrait être liée à la satisfaction du consommateur final ou au succès de l'entreprise ou à un besoin commercial similaire. Pourtant, souvent, vous pouvez voir une architecture conçue en tout ou en partie sans un tel objectif en tête. Le raisonnement est soit absent, soit se résume à utiliser autant de cloches et de sifflets modernes que possible.

L'architecte dans ce cas ne fait pas ce que le consommateur a payé. Au contraire, ils jouent avec des jouets sympas pour leur plaisir et leur plaisir. Ceci n'est en aucun cas acceptable dans l'industrie formelle. Et pourtant, cela semble arriver assez souvent de toute façon.

Parfois, le problème réside dans la personnalité de l'architecte et son obsession pour certaines technologies ou certains outils. Ils aiment simplement les utiliser et ne peuvent pas expliquer de manière cohérente le besoin commercial qu'ils essaient de résoudre. Près de cela se trouve un autre cas où les gens ne savent rien d'autre que construire quelque chose à partir de petits morceaux. Certes, tout événement extérieur déclenche leur envie de plonger dans le monde du design et de ne jamais revenir vers un vrai client. Même si le déclencheur initial peut être une contribution commerciale valable, leur détachement prolongé de la réalité diminue l'utilité de leur œuvre.

Le remède à cela est très simple, mais nécessite de l'autodiscipline. Un bon architecte ne devrait jamais toucher un stylo et du papier jusqu'à ce qu'il puisse répondre clairement et honnêtement pour lui-même pourquoi c'est nécessaire. Un tel besoin peut prendre différentes formes. Il peut s'agir d'une exigence formelle, d'un besoin implicite d'amélioration du produit ou de l'émergence de nouvelles technologies qui rendent la conception précédente moins efficace. Dans tous les cas, cela ne devrait pas être un déclencheur formel tant que les architectes eux-mêmes comprennent la force motrice. Ensuite, ils peuvent utiliser cette force comme vérification ultime de la qualité de leur conception.

Un autre problème plus difficilement détectable est lié à la pensée de l'architecture en blocs. Les personnes ayant une telle mentalité croient qu'il existe une solution à tout et ladite solution est toujours mise en œuvre comme un élément de base. En d'autres termes, ils traduisent directement les fonctionnalités en composants sans évaluer l'architecture dans son ensemble. Ils peuvent simplement attacher un composant fournissant la fonctionnalité souhaitée au système lorsqu'un besoin pour une telle fonctionnalité se fait sentir. La plupart du temps, cela satisfait aux exigences formelles mais laisse le système dans un état incohérent. Le nouveau bloc n'a pas été sélectionné sur la base de la compatibilité du système existant pour le développement, le support ou même le modèle de licence de l'entreprise. L'équipe essaie donc de modifier la configuration existante ou d'implémenter cette fonctionnalité via la capacité système existante. En conséquence, le support et la maintenance du système se transforment progressivement en un cauchemar alambiqué suivi de près par une dégradation des performances.

Il n'y a pas de solution simple à ce problème, car l'ingénierie du système est un art et il n'est jamais possible de prédire si un nouveau composant doit être ajouté ou peut être évité. La meilleure pratique consisterait probablement à conserver un arriéré de problèmes de maintenance et d'architecture qui s'accumulent au fil du temps, suivi d'examens périodiques de l'architecture globale du système. Cet examen périodique peut également tenir compte des technologies émergentes. Ainsi, l'objectif général des revues d'architecture ne devrait pas être de résoudre les problèmes mais d'évaluer la viabilité potentielle des améliorations souhaitées et du système dans son ensemble face à l'inévitabilité imminente de l'obsolescence.

Règle n° 7 : Équipe de valeur

La plupart des professionnels de l'industrie informatique ont été interrogés lors d'un entretien s'ils sont de bons joueurs d'équipe ou s'ils travaillent bien en équipe. Pourtant, personne n'a probablement jamais vu de définition claire pour cela dans la littérature. Évidemment, une telle personne contribuerait au succès de l'équipe en général, mais peu de gens peuvent réellement définir des qualités personnelles distinctives assurant un tel succès.

J'ai observé de nombreuses personnes travaillant à différents niveaux et j'ai vu comment leurs qualités personnelles influençaient l'avancement du projet. Je voudrais présenter les indications suivantes concernant les qualités personnelles qui sont les plus utiles dans le travail d'équipe.

Communicant

La première qualité, bien sûr, est la capacité à communiquer.

Imaginez une personne avec des capacités de communication nulles. Ne recevoir aucun retour des membres de l'équipe les rend complètement inutiles. C'est tellement évident que personne ne mesure réellement cette compétence pendant l'entretien, ce qui implique que la compétence est à un niveau suffisamment bon tant que la personne peut bien parler.

La communication n'est pas une compétence binaire oui/non ; il s'agit plutôt d'une fenêtre de transfert d'informations. Plus il est large, plus l'échange d'informations est rapide et clair.

Étant donné que la plage d'ouverture de cette fenêtre varie considérablement au sein de la population, la mesure de la largeur d'une telle fenêtre est une caractéristique importante d'un joueur d'équipe. Gardez à l'esprit que nous parlons de transmettre des informations dans ce contexte, mais pas de parler en douceur ou d'encourager les gens ou de les motiver ou de les organiser par la parole et les communications.

Le style de communication est également sans importance. Les informations peuvent être fournies oralement, textuellement, sous forme d'images ou de manière mixte. La personne peut parler vite ou lentement. Ils peuvent être amicaux, comme vous regarder dans les yeux et sourire tout le temps, ou ils peuvent détourner le regard et parler d'une voix monotone. Le style peut affecter votre perception personnelle de votre collègue, mais tant que vous comprenez clairement ce qu'il veut dire, n'importe quel style est suffisant.

Passons aux cas pratiques de détection et de mesure des capacités de communication.

Les compétences en communication en général comportent deux aspects majeurs. Premièrement, la volonté de partager l'information. Certaines personnes sont désireuses de partager, mais d'autres essaient de dissimuler des informations. Cette inclination est plus ou moins naturelle, mais peut être modifiée lentement avec l'auto-motivation et l'entraînement. Il est prudent de supposer que la personne affichant une sorte de volonté de partage d'informations le démontrerait également à l'avenir. C'est pourquoi ce trait est bon pour prédire le succès futur d'un candidat dans une équipe.

Dans la vraie vie, les personnes essayant de dissimuler des informations sont facilement perceptibles. Ils essaient généralement de donner intentionnellement des informations inutiles au lieu de tout ce dont ils ont réellement besoin. Ou bien, ils posent des questions préliminaires pour orienter le flux d'informations vers l'intérieur et minimiser leurs réponses à un événement "besoin de savoir". Quelle que soit leur tactique, vous aurez l'impression à la fin que vous n'avez pas obtenu les informations souhaitées de leur part, ou que l'obtention des informations a demandé trop d'efforts supplémentaires.

Il est important de comprendre l'intention, car certains types de personnes ouvertes peuvent vous poser des questions préliminaires pour mieux comprendre votre question, puis vous fournir la réponse de la manière la plus pratique. La personne qui a l'intention de dissimuler l'information posera des questions supplémentaires juste pour détourner la conversation et ne répondra jamais à votre question initiale à la place.

Une autre partie de la compétence de communication est la capacité de s'accorder à l'auditeur.

Différentes personnes ont un niveau différent de compréhension du sujet, un style de communication différent et peut-être même un intérêt différent pour des détails spécifiques. Certaines personnes intelligentes communicatives varieraient leur flux de conversation en fonction de la capacité de l'auditeur à le comprendre et à préparer leur réponse pour fournir des informations spécifiques. Dans une telle préparation, certaines questions préliminaires peuvent être posées pour réduire l'intérêt de l'auditeur. La capacité de « résoudre » les différences de communication est vraiment une grande compétence, car elle nous permet de parvenir à une compréhension dans presque tous les cas. Les locuteurs flexibles, d'autre part, peuvent parfois être coincés dans des impasses insolubles de malentendus.

Comprendre les forces et les faiblesses

Concentrons-nous sur une autre qualité personnelle essentielle pour un joueur d'équipe.

La plupart des gens conviendraient qu'un environnement d'équipe devrait être plus convivial que le monde environnant moyen pour favoriser la collaboration et augmenter la productivité. Par conséquent, il est important pour une équipe de comprendre les points forts et les points faibles de chaque membre afin de répartir correctement les tâches et de couvrir les faiblesses par des forces. La première étape sur cette voie est que tous les membres mesurent honnêtement leurs compétences les uns par rapport aux autres. Psychologiquement, cela peut être difficile car nous avons naturellement tendance à cacher nos points faibles aux autres, en nous protégeant.

C'est là que l'ambiance conviviale de l'équipe vient aider.

Ainsi, le nouveau membre doit jouer selon les règles de l'équipe. Malheureusement, certaines personnes ne peuvent pas baisser leur garde même dans un environnement amical. Ils se comportent comme des loups solitaires tout au long de leur vie. C'est plus fort qu'eux. Malheureusement, une telle attitude ne contribue pas aux efforts d'équipe.

Il existe une technique simple pour reconnaître ces loups solitaires lors de l'entretien. Ils n'admettent jamais qu'ils ne savent rien. Bien sûr, les gens aiment montrer leur meilleur, montrer toutes leurs capacités et essayer de résoudre chaque problème difficile. Pourtant, il y a une limite de connaissances pour tout le monde. Nos limites façonnent nos compétences. Ne pas admettre de limites signifie que les candidats se présentent comme des touche-à-tout, aussi bons à tout qu'à rien.

Lorsque vous embauchez un spécialiste, vous voudriez probablement éviter de telles personnes. De plus, cette attitude arrogante s'accompagne souvent d'un autre trait d'alarme : la réticence à demander de l'aide. La capacité à demander de l'aide est absolument essentielle au travail d'équipe. Sans elle, nous ne pouvons pas progresser et nous développer aussi rapidement. Une personne aussi têtue brûlerait les ressources et le temps de l'entreprise, se battant indéfiniment pour des tâches difficiles mais n'appelant jamais ses coéquipiers à l'aide. Il existe une astuce simple pour détecter ces candidats lors d'un entretien. Posez-leur une question qui n'a pas de sens ou mentionnez un terme qui n'a pas de sens. Une personne normale, idéalement curieuse, dirait simplement qu'elle ne sait pas et demanderait ce que c'est. Une personne défensive ne ferait jamais cela, même si vous soulignez qu'il n'y a pas de bonne ou de mauvaise réponse et que « je ne sais pas » ne la disqualifie pas.

Règle n°8 : Concentrez-vous sur l'organisation du travail d'équipe

Il y a aussi peu d'informations sur l'organisation du travail d'équipe que sur n'importe quel sujet précédent ci-dessus. Tout le monde sait que le travail d'équipe est meilleur, mais comment construire et maintenir une équipe reste un mystère. Cependant, même s'il est impossible de couvrir tous les aspects du team building, nous pouvons au moins explorer quelques techniques clés de team building ici.

Expertise en bâtiment

Chaque projet informatique est unique. Pour y réussir, il faut apprendre et maîtriser les spécificités du projet. Ils peuvent inclure à la fois des connaissances techniques et non techniques. Un exemple de connaissances non techniques pourrait être un réseau personnel pour la direction, les clients, les équipes de support technique, etc. Les connaissances techniques spéciales sont des détails supplémentaires en plus des compétences générales en informatique.

Par exemple, vous devrez peut-être connaître Maven pour construire un projet. Cependant, la structure de construction exacte, l'emplacement des propriétés et le filtrage varieront toujours d'un projet à l'autre. Comme pour tout type de connaissances, maîtriser de tels détails prend du temps ; plus on y investit de temps, mieux ils peuvent performer. Le temps est la ressource la plus précieuse dont vous disposez. Vous souhaitez garder votre équipier concentré sur le même domaine fonctionnel le plus longtemps possible pour capitaliser sur son expertise et la développer encore plus, améliorant ainsi constamment la performance de l'équipe.

Malheureusement, il n'est pas possible de le faire indéfiniment. D'un côté, les gens peuvent juste s'ennuyer. De l'autre côté, vous courez le risque de perdre leur expertise, mettant votre projet en péril de manière inattendue.

Voyons s'il existe des moyens de faire face aux inconvénients sans trop entraver les performances de l'équipe.

Répartissez les domaines d'intérêt entre les membres de l'équipe et laissez-les développer leur expertise. À un moment donné, ils atteignent un niveau suffisamment élevé qui a du sens dans la portée de ce projet. Un effort d'apprentissage supplémentaire ne l'améliorera pas de manière significative à ce stade. Sans motivation ni défi, les gens intelligents s'ennuient et commencent à détester leur travail.

Empêchez cela en leur ouvrant des possibilités d'apprentissage ailleurs. Tenez-les informés des projets et de la pile technologique de l'entreprise, et ouvrez-leur de nouveaux défis. Si leur intérêt se situe dans le cadre du projet, vous obtenez la double récompense de maintenir votre équipe au défi et d'étendre en même temps les compétences utiles de l'équipe. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!