Tim Lister - Co-auteur de livres
- «Le facteur humain. Projets et équipes réussis "(le livre original s'appelle" Peopleware ")
- «Valse avec les ours: gestion des risques dans les projets de développement de logiciels»
- «Incroyable avec des motifs d'adrénaline et de zombies. Modèles de comportement de l'équipe de projet
Tous ces livres sont des classiques dans leur domaine et sont écrits avec des collègues de l' Atlantic Systems Guild . En Russie, ses collègues sont les plus célèbres - Tom Demarco et Peter Khrushchka , qui ont également écrit de nombreuses œuvres célèbres.
Tim a 40 ans d'expérience dans le développement de logiciels, en 1975 (personne qui a écrit ce pivot n'est né cette année), Tim était déjà vice-président exécutif de Yourdon Inc. Maintenant, il est engagé dans le conseil, la formation et la rédaction, assistant de temps en temps à des conférences à travers le monde avec des rapports .
Surtout pour Habr, nous avons fait une interview avec Tim Lister. Il ouvrira la conférence DevOops 2019, et nous avons accumulé beaucoup de questions, sur les livres et plus encore. Les interviews sont menées par Mikhail Druzhinin et Oleg Chirukhin du comité du programme de la conférence.
Michael: Pourriez-vous dire quelques mots sur ce que vous faites maintenant?
Tim: Je suis le chef de Atlantic Systems Guild. Nous sommes six dans la Guilde, nous nous appelons directeurs. Trois aux États-Unis et trois en Europe - c'est pourquoi la Guilde s'appelle l'Atlantique. Nous sommes ensemble depuis tant d'années que vous ne comptez pas. Nous avons tous nos propres spécialités. Au cours de la dernière décennie, voire plus, j'ai travaillé avec des clients. Mes projets incluent non seulement la gestion, mais également la définition des exigences, la planification du projet et l'évaluation. Il semble que les projets qui démarrent mal finissent généralement mal. Par conséquent, vous devez vous assurer que toutes les activités sont vraiment bien pensées et convenir que les idées des créateurs sont combinées. Cela vaut la peine de considérer ce que vous faites et pourquoi. Quelles stratégies utiliser pour mener à bien le projet.
Depuis de nombreuses années, je conseille les clients de différentes manières. Un exemple intéressant est une entreprise qui fabrique des robots pour la chirurgie des articulations du genou et de la hanche. Le chirurgien n'opère pas de manière totalement indépendante, mais utilise un robot. Ici, franchement, la sécurité est importante. Mais lorsque vous essayez de discuter des exigences avec des gens qui se concentrent sur la résolution de problèmes ... Cela semble étrange, mais aux États-Unis, il y a la FDA (Federal Drug Administration), qui autorise des produits comme ces robots. Avant de vendre et d'utiliser quelque chose sur des personnes vivantes, vous devez obtenir une licence. L'une des conditions est de montrer vos besoins, quels sont les tests, comment vous les avez testés, quels sont les résultats des tests. Si vous modifiez les exigences, vous devez recommencer ce processus de test énorme encore et encore. Nos clients ont réussi à intégrer la conception visuelle des applications dans leurs besoins. Ils ont pris des captures d'écran directement dans le cadre des exigences. Nous devons les retirer et expliquer que pour la plupart tous ces programmes ne savent rien sur les genoux et les hanches, toutes ces choses avec la caméra, etc. Nous devons réécrire les documents avec les exigences afin qu'ils ne changent jamais, à moins que certaines conditions fondamentales vraiment importantes ne changent. S'il n'y a pas de conception visuelle dans les exigences, la mise à jour du produit sera beaucoup plus rapide. Notre travail consiste à trouver les éléments qui traitent des opérations sur le genou, les hanches, le dos, les tirer dans des documents distincts et dire qu'ils seront des exigences fondamentales. Faisons un groupe isolé d'exigences concernant la chirurgie du genou. Cela créera un ensemble d'exigences plus robuste. Nous parlerons de l'intégralité de la gamme de produits, et non d'exemples spécifiques de robots.
Beaucoup de travail a été fait, mais ils sont néanmoins arrivés là où ils avaient auparavant passé des semaines et des mois de tests répétés sans signification ni nécessité, car leurs exigences, décrites sur papier, ne coïncidaient pas avec les exigences réelles sur lesquelles les systèmes ont été construits. Chaque fois que la FDA leur a dit: vos exigences ont changé, vous devez maintenant tout vérifier à partir de zéro. Des contrôles croisés complets de l'ensemble du produit ont tué l'entreprise.
Donc, il y a des tâches si merveilleuses lorsque vous vous trouvez au tout début de quelque chose d'intéressant, et les toutes premières actions établissent d'autres règles du jeu. Si vous le faites à la fois d'un point de vue managérial et technique, cette première activité commencera à bien fonctionner, il y a une chance à la sortie d'obtenir un excellent projet. Mais si cette partie a déraillé et s'est mal passée, si vous ne trouvez pas l'accord fondamental ... non, pas que votre projet échouera nécessairement. Mais vous ne pourrez pas dire: "Nous sommes bien faits, nous avons tout fait de manière très efficace". Ce sont les choses que je fais, communiquer avec les clients.
Michael: Autrement dit, vous lancez des projets, effectuez une sorte de coup d'envoi et vérifiez que les rails mènent dans la bonne direction?
Tim: Nous avons également des idées sur la façon de rassembler toutes les pièces de la mosaïque: quelles compétences nous avons besoin, quand exactement elles sont nécessaires, à quoi ressemble le noyau de l'équipe et d'autres choses fondamentales. Avons-nous besoin d'employés à temps plein ou pouvons-nous recruter quelqu'un à temps partiel. Planification, gestion. Des questions comme: quel est le plus important pour ce projet particulier? Comment y parvenir? Que savons-nous de ce produit ou projet, quels sont les risques et où est l'inconnu, comment allons-nous gérer tout cela? Bien sûr, quelqu'un en ce moment commence à crier "Mais qu'en est-il de l'agilité?!". Eh bien, vous êtes tous flexibles, mais alors quoi? À quoi ressemble exactement le projet, comment allez-vous le retirer pour qu'il corresponde au projet? Vous ne pouvez pas simplement dire que "notre approche est tirée par quoi que ce soit, nous sommes une équipe de mêlée!" C'est un non-sens et un non-sens. Où allez-vous aller ensuite, pourquoi devrait-il gagner, où est le point? J'enseigne à mes clients à réfléchir sur toutes ces questions.
19 ans de prison
Michael: À Ajail, les gens essaient souvent de ne rien déterminer à l'avance, mais de prendre des décisions le plus tard possible, en disant: nous sommes trop grands, je ne penserai pas à l'architecture générale. Je ne penserai pas à un tas d'autres choses, à la place, je vais maintenant fournir au client quelque chose qui fonctionne.
Tim: Je pense que les méthodologies agiles, à commencer par Agile Manifesto en 2001, ont ouvert les yeux de l'industrie. Mais d'un autre côté, rien n'est parfait. Je suis entièrement du côté du développement itératif. Les itérations ont beaucoup de sens dans la plupart des projets. Mais vous devez réfléchir à la question: après la sortie du produit et son utilisation, combien de temps dure-t-il? S'agit-il d'un produit qui durera six mois, puis sera remplacé par un autre? Ou est-ce un tel produit qui fonctionnera pendant de très nombreuses années? Bien sûr, je ne citerai pas de noms, mais ... A New York et sa communauté de financiers, les systèmes les plus fondamentaux sont très anciens. C’est incroyable. Vous les regardez et pensez que vous remonteriez dans le temps, en 1994, et dites aux développeurs: «Je viens du futur, à partir de 2019. Concevez simplement ce système autant que vous en avez besoin. Rendez-le extensible, pensez à l'architecture. Il sera ensuite amélioré pendant plus de vingt-cinq ans. Si vous retardez le développement un peu plus longtemps - personne ne le remarquera à l'échelle de l'histoire! » Lorsque vous évaluez des choses à long terme, vous devez considérer combien cela coûtera dans son intégralité. Parfois, une architecture bien conçue en vaut vraiment la peine, et parfois non. Vous devez regarder autour de vous et vous poser la question: sommes-nous dans une situation appropriée pour une telle solution?
Donc une idée comme «Nous sommes pour l'agilité, le client lui-même nous dira ce qu'il veut recevoir» - c'est surnaturel. Après tout, les clients ne savent même pas ce qu'ils veulent, et plus encore, ils ne savent pas ce qu'ils pourraient obtenir. Certains commenceront à citer des exemples historiques comme arguments, je l'ai déjà vu. Mais les gens techniquement avancés ne disent généralement pas cela. Ils disent: "C'est maintenant l'année 2019, nous avons de telles opportunités, et nous pouvons complètement changer notre vision de ces choses!" Au lieu d'imiter les solutions existantes, de les rendre un peu plus belles et peignées, il faut parfois sortir et dire: "Réinventons complètement ce que nous essayons de faire ici!"
Et je ne pense pas que la plupart des clients puissent penser à un problème de cette façon. Ils ne voient que ce qu'ils ont déjà, et c'est tout. Ensuite, ils viennent avec des demandes comme «simplifions un peu les choses», ou tout ce qu'ils disent habituellement. Mais nous ne sommes pas des serveurs et des serveuses pour prendre une commande, peu importe à quel point c'est stupide, puis la faire cuire dans la cuisine. Nous sommes leurs guides. Nous devons ouvrir les yeux et dire: hé, nous avons là de nouvelles opportunités! Vous rendez-vous compte que nous pouvons vraiment changer la façon dont cette partie de votre entreprise est réalisée? L'un des problèmes de l'adjayl est qu'il s'éloigne de la prise de conscience de ce qu'est une opportunité, de ce qui est un problème, de ce que nous devons faire, quelles technologies disponibles sont les mieux adaptées à cette situation particulière.
Je suis peut-être allé trop loin avec scepticisme: beaucoup de choses merveilleuses se produisent dans la communauté agile. Mais j'ai un problème avec le fait qu'au lieu de définir un projet, les gens commencent à hausser les épaules. Je voudrais demander ici - que faisons-nous, comment allons-nous faire cela? Et d'une manière magique, il s'avère toujours que ce client doit savoir le mieux. Mais le client ne sait mieux que lorsqu'il choisit parmi des choses déjà construites par quelqu'un. Si je veux acheter une voiture et que je connais la taille du budget familial, je prendrai rapidement une voiture qui convient à mon style de vie. Ici, je sais tout mieux que quiconque! Mais, s'il vous plaît, notez que quelqu'un a déjà fabriqué la machine. Comment inventer une nouvelle voiture, je n'en ai aucune idée, je ne suis pas un expert. Lorsque nous créons des produits personnalisés ou spéciaux, la voix du client doit être prise en compte, mais ce n'est pas la seule voix.
Oleg: Vous avez mentionné le Manifeste Agile. Avons-nous besoin de le mettre à jour ou de le réviser d'une manière ou d'une autre en tenant compte de la compréhension actuelle du problème?
Tim: Je ne le toucherais pas. Je pense que c'est un excellent document historique. Je veux dire, il est ce qu'il est. Il a 19 ans, il est vieux, mais à un moment il a fait une révolution. Ce qu'il a bien fait, c'est de déclencher une réaction, ils ont commencé à chuchoter à son sujet. Vous n'avez probablement pas travaillé dans l'industrie en 2001, mais vous avez tous travaillé sur les processus. Institut de génie logiciel, cinq niveaux du modèle potentiel d'intégrité logicielle (CMMI). Je ne sais pas si de telles légendes de l'antiquité vous disent quelque chose de profond, mais c'était une percée. Au début, les gens pensaient que si les processus étaient construits correctement, les problèmes eux-mêmes s'évaporeraient. Et puis le Manifeste apparaît et dit: "Non, non, non - nous serons basés sur des personnes, pas sur des processus." Nous sommes passés maîtres dans le développement de logiciels. Nous comprenons que le processus idéal est un mirage, non. Il y a trop d'idiosyncrasie dans les projets; l'idée d'un processus unique et sans faille pour tous les projets n'a aucun sens. Les problèmes sont trop complexes pour prétendre qu'une solution unique a été trouvée pour tout (salut, nirvana).
Je ne prétends pas regarder vers l'avenir, mais je dirai que les gens ont maintenant commencé à réfléchir davantage aux projets. Je pense que le Manifeste Agile est très bon, il bondit en avant et dit: «Hé! Vous êtes sur un navire et vous dirigez vous-même ce navire. Vous devrez prendre une décision - nous ne proposerons pas de recette universelle pour toutes les situations. Vous êtes l'équipage du navire, et si vous êtes assez bon, vous pouvez trouver le chemin vers le but. Il y avait d'autres navires avant vous, et d'autres navires seront après vous, mais néanmoins, dans un sens, votre voyage est unique. » Quelque chose comme ça! C'est une façon de penser. Pour moi, rien n'est nouveau sous la lune, les gens ont navigué plus tôt et vont nager à nouveau, mais pour vous c'est votre voyage principal, et je ne vous dirai pas exactement ce qui vous arrivera. Vous devez avoir les compétences d'un travail d'équipe coordonné, et si elles le sont vraiment, tout ira bien et vous arriverez où vous voulez.
Peopleware: 30 ans plus tard
Oleg: Peopleware a également été une révolution, comme le Manifeste?
Tim: Peopleware ... Tom et moi avons écrit ce livre, mais je ne pensais pas que tout se passerait. D'une certaine manière, cela a résonné avec les idées de beaucoup de gens. Ce fut le premier livre qui disait: le développement de logiciels est une activité très humaine. Malgré notre nature technique, nous sommes également une communauté de personnes qui construisent quelque chose de grand, voire énorme, très complexe. Personne ne peut créer de telles choses seul, non? L'idée d'une «équipe» est donc devenue très importante. Et pas seulement du point de vue de la gestion, mais aussi pour les gens d'un entrepôt technique qui se sont réunis pour résoudre des problèmes profonds vraiment complexes avec un tas d'inconnues. Pour moi personnellement, tout au long de ma carrière, cela a été un énorme test d'intelligence. Et ici, vous devez pouvoir dire: oui, ce problème est plus que je ne peux le gérer moi-même, mais ensemble, nous pouvons trouver une solution élégante dont nous pouvons être fiers. Et je pense que cette idée particulière a le plus résonné. L'idée est que nous travaillons une partie du temps par nous-mêmes, une partie du groupe, et souvent la décision est prise par le groupe. La résolution de problèmes en groupe est rapidement devenue une caractéristique importante de projets complexes.
Malgré le fait que Tim avait un grand nombre de rapports, il y en a très peu publiés sur YouTube. Vous pouvez voir le rapport 2007 sur le retour de Peopleware. Bien sûr, la qualité laisse beaucoup à désirer.
Michael: Quelque chose a-t-il changé au cours des 30 dernières années depuis la sortie du livre?
Tim: Vous pouvez le regarder sous de nombreux angles différents. Parlant sociologiquement ... une fois, dans des temps plus simples, vous et l'équipe étiez dans le même bureau. Vous pourriez être là tous les jours, boire un café ensemble et discuter du travail. Ce qui a vraiment changé, c'est que maintenant les équipes peuvent être réparties géographiquement, dans différents pays et fuseaux horaires, mais néanmoins elles travaillent sur la même tâche, ce qui ajoute une toute nouvelle couche de complexité. Cela peut sembler démodé, mais il n'y a rien de mieux que la communication en face-à-face, lorsque vous vous réunissez tous, travaillez ensemble, vous pouvez aller voir un collègue et dire: regardez, j'ai trouvé ce que vous ressentez à ce sujet? Les conversations en face à face offrent un moyen rapide d'évoluer vers une communication informelle, et je pense que cela devrait également plaire aux amoureux. Et je suis inquiet parce qu'en réalité le monde s'est avéré être très petit, et maintenant tout est couvert par des équipes réparties, et tout cela est très compliqué.
Nous vivons tous dans DevOps
Michael: Même du point de vue du comité du programme de la conférence, nous avons des gens en Californie, à New York, en Europe, en Russie ... à Singapour il n'y a toujours personne. La différence de géographie est assez grande et les gens commencent à se répartir encore plus. Si nous parlons déjà de développement, pouvez-vous nous en dire plus sur les devops et la destruction des obstacles entre équipes? Il y a un concept selon lequel tout le monde est assis dans ses bunkers, et maintenant les bunkers s'effondrent, comment aimez-vous cette analogie?
Tim: Il me semble, à la lumière des récentes percées technologiques, que le devops est d'une grande importance. Auparavant, vous aviez des équipes de développeurs et d'admins, ils travaillaient, travaillaient, travaillaient, et à un moment donné, une chose est apparue avec laquelle vous pouvez venir aux admins et la déployer vers le prod. Et ici, la conversation sur le bunker a commencé, car les administrateurs sont comme des alliés, pas des ennemis, du moins, mais vous ne leur avez parlé que lorsque tout était prêt à être mis en vente. Vous êtes allé vers eux avec quelque chose et leur avez dit: regardez, quelle est notre application, mais pourriez-vous déployer cette application? Et maintenant, tout le concept de livraison a changé pour le mieux. Je veux dire, l'idée est venue que vous pouvez pousser le changement rapidement. Nous pouvons mettre à jour les produits à la volée. Je souris toujours lorsqu'un Firefox apparaît sur mon ordinateur portable et dit: hé, nous avons mis à jour votre Firefox en arrière-plan, et dès que vous avez une minute, pourriez-vous cliquer ici et nous vous donnerons une nouvelle version. Et je me dis: "Oh oui, bébé!" Pendant que je dormais, directement sur mon ordinateur, ils travaillaient à me fournir une nouvelle version. C'est merveilleux, incroyable.
Mais voici la difficulté: vous avez cette fonctionnalité avec les mises à jour logicielles, mais l'intégration des gens est beaucoup plus difficile. Ce que je veux dire sur le discours principal de DevOops, c'est que nous avons maintenant beaucoup plus de joueurs que jamais auparavant. Si vous pensez à tous ceux qui participent au travail d'une seule équipe ... Vous le considérez comme une équipe, et c'est bien plus qu'une simple équipe de programmeurs. Ce sont des testeurs, des chefs de projet et un tas d'autres personnes. Et chacun a sa propre vision du monde. Les chefs de produit sont complètement différents des chefs de projet. Les administrateurs ont leurs propres tâches. Il devient un problème assez difficile de coordonner tous les participants, afin de continuer à être conscient de ce qui se passe et de ne pas descendre des bobines. Il est nécessaire de séparer les tâches du groupe et les tâches relatives à tous. C'est une tâche très difficile. D'un autre côté, je pense que tout cela est devenu bien meilleur qu'il y a plusieurs années. C'est exactement la voie sur laquelle les gens grandissent et apprennent à se comporter correctement. Lorsque vous êtes engagé dans l'intégration, vous comprenez qu'il ne devrait pas y avoir de développement souterrain, de sorte qu'au tout dernier moment le logiciel ne sorte pas de la boîte: comme, regardez, qu'avons-nous fait ici! L'idée est que vous pouvez faire l'intégration et le développement, et à la fin, vous vous déploierez de manière ordonnée et itérative. Tout cela est d'une grande importance pour moi. Cela permet de créer plus de valeur pour les utilisateurs du système et pour votre client.
Michael: L'idée de Devopse est de fournir un travail significatif le plus tôt possible. Je vois que le monde a commencé à s'accélérer de plus en plus. Comment s'adapter à de telles accélérations? Il y a dix ans, ce n'était pas le cas!
Tim: Bien sûr, tout le monde veut de plus en plus de fonctionnalités. Pas besoin de bouger, empilez-en plus. Parfois, vous devez même ralentir pour que la prochaine mise à jour incrémentielle apporte au moins quelque chose d'utile - et c'est tout à fait normal.
L'idée que vous devez exécuter-exécuter-exécuter n'est pas la meilleure. Presque personne ne veut vivre de cette façon. J'aimerais que le rythme des livraisons fixe le rythme propre du projet. Si vous produisez simplement un flux de petites choses relativement dénuées de sens, tout cela au total n'a pas de sens. Au lieu d'essayer sans réfléchir de publier les choses le plus tôt possible, ce qui mérite d'être discuté avec les principaux développeurs et chefs de produit et de projet est la stratégie. Est-ce même logique?
Patterns et antipatterns
Oleg: Vous parlez généralement de modèles et d'anti-motifs, et c'est la différence entre la vie et la mort des projets. Et maintenant, devops fait irruption dans nos vies. A-t-il ses propres modèles et anti-motifs qui peuvent tuer le projet sur place?
Tim: Les modèles et les antipatterns se produisent tout le temps. De quoi parler. Eh bien, il y a une chose que nous appelons des «choses brillantes». Les gens aiment vraiment, vraiment les nouvelles technologies. Ils sont simplement envoûtés par l'éclat de tout ce qui a l'air cool et élégant, et cessent de poser des questions: est-ce même nécessaire? Qu'allons-nous réaliser? Cette chose est-elle fiable, est-ce logique? Je vois souvent des gens, disons, à la pointe de la technologie. Ils sont fascinés par ce qui se passe dans le monde. Mais si vous regardez de plus près, à quoi bon ils font - souvent, il n'y a tout simplement rien d'utile!
, – , , . 1969. , – 1969 , 1960 62, NASA , . – , ! -, , , . : «, , , , !». - … , . , , , , , . , : « !».
: , ?
: , ! … , , -. ! , , , – . , , ? ! . , . , , … – . : . , .
: , « , »: ?
: . - . – - , , ? , – . , , - : « ! !». Vraiment? .
«-»
: . - , «-» . : , , «-», ? , – , - .
: -. - . - , . , , , ! , , «-», , , ? – . , «» — , ? . - , , , . , ?
, , , , – . , - , - – . , DevOps, , - . , , , . « », « » , , – «».
- , , . , , . – , « ». ? , , . - , , , , , . , - , , , , . ! - .
- -. , , ? , , ? - : --, , , , , .
, , . , . , , : , . , . , . .
. – , , , , , , ! - . – …
« »
: ? , , , – « ».
: ! – , - . - , ( , ). – , – , - , .
, . , « - , ». , -, , . , , . , , , , , . , , , – , . , . , .
: , . , , . , . , – , – . , , , .
: Move fast and break things!
: , , , – -. , ?
: : . . , - , . , , - , « », , : « ». , . , , . – .
, . , , , - . - , , . , – , , , , . , , , . .
, , . , – , . , , , , , ? ? , ? , : , . , , , - . : , .
, . , : , , - , . , , . , , , .
, ? , . , . 100%, : «, , !». . – , , , ! , , , : « – , – ». , - .
, , – . , . . !
: . , . ?
: , , – . , . - ? , , , , . , , . « , – ». . ( !) , . . , , – , . , . , . , , , , , , … , , . , , . . , , , !
: , , - , (, ) .
Tim: C'est vrai. Je pense que les meilleurs techniciens, si vous les regardez attentivement, ils sont comme des managers à part entière. Comment le formuler ...
Oleg: Votre vie est votre projet que vous gérez.
Tim: C'est vrai! Je veux dire, vous avez pris des responsabilités, vous comprenez le problème et vous entrez en contact avec des gens lorsque vous voyez que vos décisions peuvent affecter leur travail, le tout dans cet esprit. Il ne s'agit pas simplement de s'asseoir à la table, de faire son travail et de ne même pas savoir ce qui se passe autour. Non, non, non. Soit dit en passant, l'une des meilleures choses dans Agile est qu'ils ont suggéré de courts sprints, car la situation de tous les participants est bien observée, ils peuvent le regarder tous ensemble. Chaque jour, nous parlons les uns des autres.
Comment entrer dans la gestion des risques
Oleg: Existe - t-il une structure formelle de connaissances dans ce domaine? Par exemple, je suis développeur Java et je veux comprendre la gestion des risques sans devenir un vrai chef de projet pédagogique. Probablement, j'ai d'abord lu «Combien coûte un projet logiciel» de McConnell, et ensuite? Quelles sont les premières étapes?
Tim: Le premier est de commencer à communiquer avec les gens du projet. Cela permet une amélioration instantanée de la culture de communication avec les collègues. Vous devez commencer par tout ouvrir par défaut, au lieu de le cacher. Dis: ce sont les choses qui me dérangent, ce sont les choses qui me tiennent éveillé la nuit, aujourd'hui je me suis réveillé la nuit et comme ça: dieux, il faut y penser! Les autres voient-ils la même chose? En tant que groupe, devons-nous répondre à ces problèmes potentiels? Vous devez être capable de maintenir une discussion sur ces sujets. Il n'y a pas de formule pré-préparée par laquelle nous travaillons. Ce n'est pas la production de hamburgers, c'est une question de gens. «Faire un cheeseburger - vendre un cheeseburger» - ce n'est pas du tout de nous, et c'est pourquoi j'aime tellement ce métier. J'aime quand tout ce que les managers faisaient auparavant, devient désormais la propriété de l'équipe.
Oleg: Vous avez dit dans des livres et des interviews que les gens étaient plus préoccupés par le bonheur que par les chiffres du graphique. D'un autre côté, lorsque vous dites à l'équipe: nous passons aux devops, et maintenant le programmeur doit constamment communiquer, cela peut être bien au-delà de sa zone de confort. Et en ce moment, il peut, disons-le, être profondément malheureux. Que faire dans cette situation?
Tim: Je ne sais pas exactement quoi faire. Si le développeur est trop isolé, il ne voit pas du tout pourquoi le travail est fait, il regarde juste sa partie du travail, et il a besoin de se plonger dans ce que j'appelle le «contexte». Il doit comprendre comment tout est interconnecté. Et bien sûr, je ne parle pas de la présentation formelle ou quelque chose comme ça. Je dis que vous devez communiquer avec vos collègues sur le travail dans son ensemble, et pas seulement sur la partie de celui-ci dont vous êtes responsable. Et à ce moment, vous pouvez commencer à discuter des idées, des accords généraux, afin que votre travail se passe bien, et comment s'appuyer ensemble sur un problème commun.
Pour s'adapter, les techniciens veulent souvent aussi les envoyer en formation, discuter des formations. Un de mes amis aime dire que la formation est pour les chiens. Il y a de la formation pour les gens. L'une des meilleures choses à enseigner à un développeur est de communiquer avec ses collègues. Si quelqu'un a vraiment réussi quelque chose, vous devriez voir comment il fonctionne, ou discuter avec lui du travail, ou quelque chose comme ça. Certains Kent Beck conditionnels ont constamment parlé de programmation extrême. C'est drôle, car XP est une idée si simple, mais cela cause tellement de problèmes. Pour quelqu'un, faire de l'XP, c'est comme être obligé de se déshabiller devant des amis. Ils verront ce que je fais! Ce sont mes collègues, ils vont non seulement voir, mais aussi comprendre! Horrible Quelqu'un commence à devenir sérieusement nerveux. Mais quand vous réalisez que c'est le moyen ultime d'apprendre, tout change. Vous travaillez en étroite collaboration avec les gens et certaines personnes comprennent le sujet beaucoup mieux que vous.
Michael: Mais tout cela vous fait quitter votre zone de confort. En tant qu'ingénieur, vous devez sortir de votre zone de confort, communiquer. En tant que personne qui résout des problèmes, vous devez constamment vous mettre en position de faiblesse et réfléchir à ce qui pourrait mal tourner. Un tel travail est intrinsèquement conçu pour être gênant. Vous vous mettez consciemment dans des situations stressantes. Habituellement, les gens les fuient, les gens aiment être des enfants heureux.
Tim: Ce qui peut être fait, vous pouvez sortir et dire ouvertement: «Tout est en ordre, je peux le gérer! Je ne suis pas seul dans l'inconfort. Discutons de diverses choses inconfortables, tous ensemble, en équipe! » Ce sont nos problèmes communs, nous devons y faire face, vous comprenez? Je pense que les brillants développeurs idiosyncratiques - ils sont comme des mammouths, ils ont disparu. Oui, et ils ont une valeur très limitée. Si vous ne pouvez pas communiquer, vous ne pouvez pas participer normalement. Par conséquent, dites-le simplement. Soyez honnête et ouvert. Je suis vraiment désolé que quelqu'un soit désagréable. Imaginez, il y a de nombreuses années, il y avait une étude selon laquelle la principale peur aux États-Unis n'est pas la mort, mais devinez quoi? Peur de parler en public! Donc, quelque part, il y a des gens qui sont plus susceptibles de mourir que de dire un compliment à voix haute. Et vous, je pense, n'avez que quelques compétences de base, selon ce que vous faites. Compétences en conversation, compétences en rédaction - mais autant que cela est vraiment nécessaire dans votre travail. Si vous travaillez en tant qu'analyste, mais que vous ne savez ni lire, ni écrire, ni parler, alors vous n'aurez malheureusement rien à faire dans mes projets!
Prix de la communication
Oleg: L'utilisation de ces employés sortants est-elle plus coûteuse pour diverses raisons? Au final, ils parlent constamment au lieu de travailler!
Tim: Je pensais au noyau dur de l'équipe, et généralement pas de suite. Si vous avez un spécialiste qui configure vraiment vos bases de données cool, aime configurer vos bases de données et va continuer à configurer vos bases de données pour le reste de votre vie, et c'est tout cool, continuez. Mais je parle des gens qui veulent vivre dans le projet lui-même. Le noyau de l'équipe, visant à développer le projet. Ces personnes ont vraiment besoin de communiquer constamment entre elles. Et surtout au début du projet, lorsque vous discutez des risques, des moyens d'atteindre des objectifs mondiaux, etc.
Michael: Cela s'applique à tous ceux qui sont impliqués dans le projet, indépendamment de la spécialisation, des compétences et des méthodes de travail. Vous êtes tous intéressés par la réussite du projet.
Tim: Oui, vous sentez que vous êtes profondément immergé dans le projet, que votre tâche consiste à aider le projet à se réaliser. Soyez programmeur, analyste, concepteur d'interface, n'importe qui. C'est la raison pour laquelle je viens travailler tous les matins, et c'est ce que nous faisons. Nous sommes responsables de toutes ces personnes, quelles que soient leurs compétences. Il s'agit d'un groupe de personnes qui ont des conversations avec des adultes.
Oleg: En fait, en parlant d'employés bavards, j'ai essayé de simuler les objections des gens, en particulier des managers à qui l'on propose de passer aux devops, à cette toute nouvelle vision du monde. Et pour vous, en tant que consultants, ces objections doivent être bien mieux connues que pour moi en tant que développeur! Partagez ce qui intéresse le plus les managers?
Tim: Des managers? Hm. Le plus souvent, les gestionnaires sont sous la pression de problèmes, avant la nécessité de libérer d'urgence quelque chose et de faire une livraison, etc. Ils nous regardent constamment discuter et discuter, et ils le voient comme ceci: conversations, conversations, conversations ... Quelles autres conversations? Reprenez le travail! Parce que les conversations ne leur semblent pas du travail. Vous n'écrivez pas de code, ne testez pas de logiciel, ne faites apparemment rien - pourquoi ne pas vous envoyer faire des affaires? Après tout, la livraison dans un mois!
Michael: Allez écrire du code!
Tim: Il me semble qu'ils ne se soucient pas du travail, mais du manque de visibilité pour aller de l'avant. Pour qu'ils pensent que nous approchons du succès, ils doivent voir comment nous appuyons sur les boutons du clavier. Toute la journée du matin au soir. C'est le problème numéro un.
Oleg: Misha, tu as pensé à quelque chose.
Michael: Désolé, je pensais, j'ai attrapé un flashback. Tout cela m'a rappelé un rallye intéressant qui a eu lieu hier ... Hier, il y avait trop de rallyes ... Et tout cela semble très familier!
La vie sans salaire
Tim: Au fait, il n’est pas nécessaire d’organiser des «réunions» pour la communication. Je veux dire, les discussions les plus utiles entre les développeurs se produisent quand ils se parlent. Vous arrivez le matin avec une tasse de café, et là-bas, nous nous réunissons tous les cinq et discutons de quelque chose de technique. Pour moi, si je suis le gestionnaire de ce projet, il vaut mieux simplement sourire et aller quelque part au sujet de votre entreprise, laissez-les discuter. Ils sont déjà impliqués autant que possible. C'est bon signe.
Oleg: Au fait, ici, vous avez un tas de notes dans votre livre sur ce qui est bon et ce qui est mauvais. En utilisez-vous vous-même? Relativement parlant, vous avez maintenant une entreprise, et même une structure très peu orthodoxe ...
Tim: peu orthodoxe, mais un tel appareil est parfait pour nous. Nous nous connaissons depuis longtemps. Nous nous faisons confiance, nous nous faisions confiance avant de devenir partenaires. Et par exemple, nous n'avons aucun salaire. Nous travaillons simplement, et par exemple, si je gagnais de l'argent de mes clients, alors tout l'argent allait à moi. Après cela, nous payons des frais d'adhésion à l'organisation, et cela suffit pour maintenir l'entreprise elle-même. De plus, nous nous spécialisons tous dans des choses différentes. Par exemple, je travaille avec des comptables, je remplis des déclarations de revenus, je fais toutes sortes de tâches administratives pour l'entreprise et personne ne me paie pour cela. James et Tom travaillent sur notre site et personne ne les paie non plus. Tant que vous payez votre cotisation, personne ne pense même à vous dire ce que vous devez faire. Par exemple, Tom travaille désormais beaucoup moins qu'avant. Maintenant, il a d'autres intérêts, quelque chose qu'il ne fait pas pour la guilde. Mais tant qu'il paiera sa cotisation, personne ne viendra vers lui et lui dira: "Hé Tom, viens travailler!" Il est très facile de traiter avec des collègues lorsqu'il n'y a pas d'argent entre vous. Et maintenant, notre relation est l'une des idées fondamentales, appliquée à différentes spécialités. Cela fonctionne, et cela fonctionne très bien.
Le meilleur conseil
Michael: Pour en revenir au «meilleur conseil», y a-t-il quelque chose que vous répétez à vos clients encore et encore? Il y a une idée sur 80/20, et c'est certain que certains conseils sont répétés plus souvent.
Tim: Une fois que j'ai pensé que si vous écrivez un livre comme "Valse avec les ours", cela changera le cours de l'histoire et les gens s'arrêteront, mais ... Eh bien, regardez, souvent les entreprises prétendent qu'elles se portent bien. Dès qu'il s'est passé quelque chose de mal, ce fut un choc et une surprise pour eux. «Regardez, nous avons testé le système, et il ne passe aucun test du système, et c'est encore trois mois de travail extraordinaire, comment cela pourrait-il arriver? Qui savait Qu'est-ce qui aurait pu mal tourner? " Sérieusement, croyez-vous cela?
J'essaie d'expliquer qu'il ne faut pas trop se fâcher de la situation actuelle. Vous devez en discuter, pour vraiment comprendre ce qui aurait pu mal tourner et comment empêcher de telles choses à l'avenir. Si, néanmoins, le problème se manifeste, comment le combattre, comment le maîtriser.
Pour moi, tout cela fait peur. Les gens font face à des problèmes complexes et désagréables et continuent de prétendre que s'ils croisent simplement les doigts et espèrent le meilleur, ce «meilleur» se produira vraiment. Non, ça ne marche pas.
Engagez-vous dans la gestion des risques!
Michael: À votre avis, combien d'organisations sont impliquées dans la gestion des risques?
Tim: Ce qui me rend furieux, c'est que les gens écrivent simplement les risques, regardent la liste résultante et se mettent au travail. En fait, l'identification des risques pour eux est une gestion des risques. Mais pour moi, cela ressemble à une raison de la question: eh bien, il y a une liste, que changerez-vous exactement? Vous devez modifier votre séquence d'actions standard en tenant compte de ces risques. S'il y a une partie du travail la plus difficile, vous devez le faire et ensuite seulement passer à la plus simple. Dès les premiers sprints, commencez à résoudre des problèmes complexes. Maintenant, cela ressemble à la gestion des risques. Mais généralement, les gens ne peuvent pas dire ce qu'ils ont changé après avoir dressé une liste de risques.
Michael: Et pourtant, combien de ces sociétés de gestion des risques représentent 5%?
Tim: Malheureusement, c'est désagréable pour moi de dire cela, mais c'est une partie très insignifiante. Mais plus de cinq, car il y a de très gros projets, et ils ne peuvent tout simplement exister que s'ils font au moins quelque chose. Disons simplement que je serais très surpris si c'est au moins 25%. Les petits projets répondent généralement à ces questions de cette manière: si le problème nous touche, nous le résoudrons. Ensuite, ils plongent avec succès dans le problème et s'engagent dans la gestion des problèmes et la gestion des crises. Lorsque vous essayez de résoudre un problème, mais que le problème n'est pas résolu - bienvenue dans la gestion de crise.
Oui, j'entends souvent: «nous résoudrons les problèmes dès qu'ils seront disponibles». Aurons-nous raison? Allons-nous décider exactement?
Oleg: Vous pouvez le faire naïvement et simplement écrire des invariants importants dans la charte du projet, et si les invariants tombent en panne, redémarrez simplement le projet. Il se révèle d'une manière très pembucco.
Mikhail: Oui, il m'est arrivé que lorsque les risques ont fonctionné, le projet a simplement été redéfini. Bien, bingo, le problème est résolu, plus de soucis!
Tim: Appuyez sur le bouton de réinitialisation! Non, ça ne marche pas.
Keynote au DevOops 2019
Michael: Nous arrivons à la dernière question de cette interview. Vous venez au prochain DevOops avec un discours, pourriez-vous ouvrir le voile du secret sur ce que vous allez dire?
Tim: Actuellement, six d'entre eux écrivent un livre sur la culture de travail, les règles tacites des organisations. La culture est définie par les valeurs fondamentales de l'organisation. Habituellement, les gens ne le remarquent pas, mais nous, travaillant dans le conseil depuis de nombreuses années, sommes habitués à le remarquer. Vous entrez dans l'entreprise et quelques minutes plus tard, vous commencez à ressentir ce qui se passe. Nous l'appelons «arôme». Parfois, ce parfum est vraiment bon, et parfois c'est bien, oups. Différentes organisations ont des choses très différentes.
Michael: Je travaille également dans le conseil depuis des années et je comprends bien de quoi vous parlez.
Tim: En fait, l'une des choses qui mérite d'être discutée dans le discours d'ouverture est que tout n'est pas déterminé par l'entreprise. Vous et votre équipe, en tant que communauté - vous avez votre propre culture d'équipe. Il peut s'agir soit de l'ensemble de l'entreprise, soit d'un service distinct, d'une équipe distincte. Mais avant de dire: c'est ce en quoi nous croyons, c'est important ... Vous ne pouvez pas changer votre culture avant d'avoir réalisé les valeurs et les croyances derrière des actions concrètes. Le comportement est facile à observer et la recherche de persuasion est difficile. DevOps est juste un excellent exemple de la façon dont les choses deviennent de plus en plus difficiles. Les interactions deviennent seulement plus compliquées, elles ne deviennent pas plus propres et plus compréhensibles du tout, alors vous devriez penser à ce en quoi vous croyez et à ce que tout le monde est silencieux.
Si vous voulez obtenir des résultats rapides, voici un bon sujet: avez-vous vu des entreprises dans lesquelles personne ne dit "je ne sais pas"? Il y a des endroits où vous devez littéralement torturer une personne jusqu'à ce qu'il admette qu'il ne sait pas quelque chose. Tout le monde sait tout, tout le monde est un savant incroyable. Vous approchez n'importe qui et il doit répondre instantanément à quelque chose. Au lieu de dire "je ne sais pas". Hourra, ils ont engagé une foule de savants! Et dans certaines cultures, il est très dangereux de dire "je ne sais pas", cela peut être perçu comme une manifestation de faiblesse. Il existe des organisations dans lesquelles, au contraire, tout le monde peut dire "je ne sais pas". C'est tout à fait légal là-bas, et si quelqu'un en réponse à une question commence à se frotter au jeu, il est parfaitement normal de répondre: "Vous ne comprenez pas de quoi vous parlez, non?" et en faire une blague.
Idéalement, j'aimerais avoir un travail où vous pourriez être heureux tout le temps. Ce ne sera pas facile, tous les jours ne sont pas ensoleillés et agréables, parfois vous devez travailler dur, mais quand vous commencez à résumer, il s'avère: wow, c'est vraiment un endroit merveilleux, je travaille bien ici, à la fois émotionnellement et intellectuellement. Et il y a des entreprises dans lesquelles vous vous engagez en tant que consultant et réalisez instantanément que vous n'auriez pas survécu pendant trois mois et que vous vous seriez enfui avec horreur. C'est de cela que je veux parler dans le rapport.
Tim Lister arrivera avec la conférence "Personnages, communauté et culture: facteurs importants de prospérité" lors de la conférence DevOops 2019, qui se tiendra les 29 et 30 octobre 2019 à Saint-Pétersbourg. Les billets peuvent être achetés sur le site officiel . Rendez-vous à DevOops!