Tim Lister - co-auteur de livres
- "Facteur humain. Projets et équipes réussis" (le livre original s'appelle "Peopleware")
- "Valser avec les ours : gérer les risques dans les projets logiciels"
- « Fou d'adrénaline et zombifié par les schémas. Modèles de comportement des équipes de projet"
Tous ces livres sont des classiques dans leur domaine et ont été écrits en collaboration avec des collègues de . En Russie, ses collègues sont les plus célèbres - и , qui a également écrit de nombreuses œuvres célèbres.
Tim a 40 ans d'expérience dans le développement de logiciels ; en 1975 (aucun de ceux qui ont écrit cet Habrapost n'était né cette année), Tim était déjà vice-président exécutif de Yourdon Inc. Il consacre désormais son temps à consulter, à enseigner et à écrire, avec des visites occasionnelles à conférences à travers le monde.
Nous avons réalisé une interview avec Tim Lister spécialement pour Habr. Il ouvrira la conférence DevOops 2019, et nous avons beaucoup de questions, sur les livres et bien plus encore. L'interview est menée par Mikhail Druzhinin et Oleg Chirukhin du comité du programme de la conférence.
Michael: Pouvez-vous dire quelques mots sur ce que vous faites actuellement ?
Tim: Je suis à la tête de l'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 Atlantic. Nous sommes ensemble depuis tellement d'années qu'on ne peut pas les compter. Nous avons tous nos spécialités. Je travaille avec des clients depuis au moins une décennie. Mes projets incluent non seulement la gestion, mais également la définition des exigences, la planification de projet et l'évaluation. Il semble que les projets qui démarrent mal se terminent généralement mal. Par conséquent, il convient de s'assurer que toutes les activités sont vraiment bien pensées et coordonnées, que les idées des créateurs sont combinées. Cela vaut la peine de réfléchir à ce que vous faites et pourquoi. Quelles stratégies utiliser pour mener à bien le projet.
Je conseille des clients de diverses manières depuis de nombreuses années. Un exemple intéressant est celui d’une entreprise qui fabrique des robots pour la chirurgie du genou et de la hanche. Le chirurgien n’opère pas de manière totalement autonome, mais utilise un robot. Franchement, la sécurité ici est importante. Mais lorsque vous essayez de discuter des exigences avec des personnes qui se concentrent sur la résolution de problèmes... Cela peut paraître étrange, mais aux États-Unis, il existe (Federal Drug Administration), qui autorise des produits comme ces robots. Avant de vendre quoi que ce soit et de l’utiliser 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 devrez alors recommencer encore et encore tout ce processus de test énorme. Nos clients ont réussi à inclure la conception visuelle des applications dans leurs exigences. Ils avaient des captures d'écran directement dans le cadre des exigences. Il faut les sortir et leur expliquer que pour la plupart, tous ces programmes ne connaissent rien aux genoux et aux hanches, à toutes ces choses avec la caméra, etc. Nous devons réécrire les documents d'exigences afin qu'ils ne changent jamais, à moins que certaines conditions sous-jacentes vraiment importantes ne changent. Si la conception visuelle ne fait pas partie des exigences, la mise à jour du produit sera beaucoup plus rapide. Notre travail consiste à trouver les éléments qui concernent les opérations du genou, des hanches et du dos, à les regrouper dans des documents séparés et à dire que ce seront les exigences fondamentales. Faisons un groupe isolé d'exigences concernant les opérations du genou. Cela nous permettra de construire un ensemble d’exigences plus stable. Nous parlerons de l'ensemble de la gamme de produits et non de robots spécifiques.
Beaucoup de travail a été fait, mais ils sont quand même arrivés à des endroits où auparavant ils passaient 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 pour lesquelles les systèmes avaient été construits. La FDA leur disait à chaque fois : vos exigences ont changé, vous devez maintenant tout vérifier à partir de zéro. Des revérifications complètes de l’ensemble du produit tuaient l’entreprise.
Ainsi, il y a des tâches tellement merveilleuses lorsque vous vous trouvez au tout début de quelque chose d'intéressant, et les toutes premières actions fixent les autres règles du jeu. Si vous vous assurez que cette première activité commence à bien fonctionner, tant d'un point de vue managérial que technique, il y a de fortes chances que vous obteniez un grand projet. Mais si cette partie a déraillé et a mal tourné, si vous ne parvenez pas à trouver les accords fondamentaux... non, ce n'est pas que votre projet échouera nécessairement. Mais vous ne pourrez plus dire : « Nous avons très bien fait, nous avons tout fait de manière très efficace. » Ce sont les choses que je fais lorsque je communique avec les clients.
Michael: C'est-à-dire que vous lancez des projets, effectuez une sorte de coup d'envoi et vérifiez que les rails vont dans la bonne direction ?
Tim: Nous avons également des idées sur la façon de rassembler toutes les pièces du puzzle : de quelles compétences nous avons besoin, quand exactement elles sont nécessaires, à quoi ressemble le noyau de l'équipe et d'autres éléments fondamentaux. Avons-nous besoin d’employés à temps plein ou pouvons-nous embaucher quelqu’un à temps partiel ? Planification, gestion. Des questions telles que : Qu’est-ce qui 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ù se situent les inconnues, comment allons-nous gérer tout cela ? Bien sûr, à ce moment-là, quelqu'un commence à crier « Et l'agilité ? ! » D'accord, vous êtes tous flexibles, mais et alors ? À quoi ressemble exactement le projet, comment allez-vous le réaliser d’une manière qui convient au projet ? Vous ne pouvez pas simplement dire que « notre approche s’étend à tout, nous sommes une équipe Scrum ! C’est absurde et absurde. Où allez-vous aller ensuite, pourquoi cela devrait-il fonctionner, à quoi ça sert ? J'apprends à mes clients à réfléchir à toutes ces questions.
19 ans d'agilité
Michael: En Agile, les gens essaient souvent de ne rien définir à l’avance, mais de prendre des décisions le plus tard possible en disant : nous sommes trop grands, je ne penserai pas à l’architecture globale. Je ne penserai pas à beaucoup d'autres choses ; à la place, je livrerai quelque chose qui fonctionne immédiatement au client.
Tim: Je pense que les méthodologies agiles, à commencer par en 2001, a ouvert les yeux de l'industrie. Mais d’un autre côté, rien n’est parfait. Je suis tout à fait favorable au développement itératif. L'itération a beaucoup de sens dans la plupart des projets. Mais la question à laquelle vous devez réfléchir est la suivante : une fois le produit sorti et utilisé, combien de temps dure-t-il ? Est-ce un produit qui va durer six mois avant d’être remplacé par autre chose ? Ou s’agit-il d’un produit qui fonctionnera pendant de très nombreuses années ? Bien sûr, je ne citerai pas de noms, mais… À New York et dans sa communauté financière, les systèmes les plus fondamentaux sont très anciens. Ceci est incroyable. Vous les regardez et pensez, si seulement vous pouviez remonter le temps, jusqu'en 1994, et dire aux développeurs : « Je viens du futur, de 2019. Développez simplement ce système aussi longtemps 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 encore un peu le développement, dans l’ensemble, personne ne le remarquera ! » Lorsque vous estimez les choses sur le long terme, vous devez considérer combien cela coûtera au total. Parfois, une architecture bien conçue en vaut vraiment la peine, et parfois non. Nous devons regarder autour de nous et nous demander : sommes-nous dans la bonne situation pour prendre une telle décision ?
Donc une idée comme « Nous sommes pour l’agilité, le client lui-même nous dira ce qu’il veut obtenir » est super naïve. Les clients ne savent même pas ce qu’ils veulent, et encore plus, 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 : « Nous sommes en 2019, ce sont les opportunités que nous avons et nous pouvons complètement changer notre façon de voir ces choses ! » Au lieu d'imiter les solutions existantes, en les rendant un peu plus jolies et plus 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 envisager le problème de cette façon. Ils ne voient que ce qu'ils ont déjà, c'est tout. Après quoi, ils viennent avec des demandes du type « simplifions cela un peu » ou tout ce qu'ils disent habituellement. Mais nous ne sommes ni serveurs ni serveuses, nous pouvons donc prendre une commande aussi stupide qu'elle s'avère et ensuite la faire cuire dans la cuisine. Nous sommes leurs guides. Nous devons leur ouvrir les yeux et leur dire : hé, nous avons de nouvelles opportunités ici ! Réalisez-vous que nous pouvons vraiment changer la façon dont cette partie de votre activité est réalisée ? L’un des problèmes de l’Agile est qu’il supprime la conscience de ce qui constitue une opportunité, de ce qui constitue un problème, de ce que nous devons faire et des technologies disponibles les mieux adaptées à cette situation particulière.
Peut-être que je suis trop sceptique ici : il se passe beaucoup de choses merveilleuses dans la communauté agile. Mais j'ai un problème avec le fait qu'au lieu de définir un projet, les gens commencent à lever la main. Je demanderais ici : que faisons-nous, comment allons-nous le faire ? Et d’une manière ou d’une autre, comme par magie, il s’avère toujours que le client devrait le savoir mieux que quiconque. Mais le client ne sait mieux que lorsqu'il choisit parmi des éléments déjà construits par quelqu'un. Si je souhaite acheter une voiture et que je connais la taille de mon budget familial, je sélectionnerai rapidement une voiture qui convient à mon style de vie. Ici, je sais tout mieux que quiconque ! Mais attention, quelqu'un a déjà fabriqué les voitures. Je ne sais pas du tout comment inventer une nouvelle voiture, 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 elle n'est plus la seule.
Oleg: Vous avez mentionné le Manifeste Agile. Devons-nous le mettre à jour ou le réviser d’une manière ou d’une autre en tenant compte de la compréhension moderne 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 en son temps il a fait une révolution. Ce qu'il a bien fait, c'est qu'il a déclenché une réaction et que les gens ont commencé à chuchoter à son sujet. Vous ne travailliez probablement pas encore dans l'industrie en 2001, mais à l'époque, tout le monde travaillait selon des processus. Software Engineering Institute, cinq niveaux du modèle d'exhaustivité logicielle (CMMI). Je ne sais pas si de telles légendes de la plus haute antiquité vous disent quelque chose, mais ce fut alors une percée. Au début, les gens croyaient que si les processus étaient correctement mis en place, les problèmes disparaîtraient d’eux-mêmes. Et puis le Manifeste arrive et dit : « Non, non, non – nous nous baserons sur les personnes, pas sur les processus. » Nous maîtrisons le développement de logiciels. Nous comprenons que le processus idéal est un mirage ; il ne se produit pas. Il y a trop de particularités dans les projets, l'idée d'un seul processus parfait pour tous les projets n'a aucun sens. Les problèmes sont trop complexes pour prétendre qu’il n’y a qu’une seule solution à tout (bonjour le nirvana).
Je n’ai pas la prétention de 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 efficace pour sauter le pas et dire : « Hé ! Vous êtes sur un navire et vous conduisez 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 l'objectif. Il y a eu d’autres navires avant vous, et il y aura d’autres navires après vous, mais néanmoins, dans un sens, votre voyage est unique. Quelque chose comme ca! C'est une façon de penser. Pour moi, il n'y a rien de nouveau sous le soleil, des gens ont déjà navigué et navigueront encore, mais pour vous c'est votre voyage principal, et je ne vous dirai pas ce qui va vous arriver exactement. Vous devez avoir les compétences nécessaires pour un travail coordonné en équipe, et si vous les possédez vraiment, tout se passera bien et vous arriverez là où vous le vouliez.
Peopleware : 30 ans après
Oleg: Peopleware a-t-il été une révolution au même titre que le Manifeste ?
Tim: Peopleware... Tom et moi avons écrit ce livre, mais nous ne pensions pas que cela se passerait ainsi. D’une manière ou d’une autre, cela a trouvé un écho dans les idées de beaucoup de gens. C'était le premier livre qui disait : le développement de logiciels est une activité à très forte intensité humaine. Malgré notre nature technique, nous sommes aussi une communauté de personnes qui construisent quelque chose de grand, voire immense, de très complexe. Personne ne peut créer de telles choses seul, n’est-ce pas ? L’idée d’« équipe » est donc devenue très importante. Et pas seulement du point de vue de la gestion, mais aussi du point de vue des techniciens qui se sont réunis pour résoudre des problèmes profonds vraiment complexes avec un tas d'inconnues. Pour moi personnellement, cela a été un énorme test d’intelligence tout au long de ma carrière. Et ici, vous devez être capable de dire : oui, ce problème est plus que ce que je peux gérer seul, mais ensemble, nous pouvons trouver une solution élégante dont nous pouvons être fiers. Et je pense que c’est cette idée qui a le plus résonné. L'idée selon laquelle nous travaillons une partie du temps seul, une partie du temps en 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 des projets complexes.
Malgré le fait que Tim ait donné un grand nombre de conférences, très peu d'entre elles sont publiées sur YouTube. Vous pouvez consulter le rapport « The Return of Peopleware » de 2007. La qualité laisse bien entendu beaucoup à désirer.
Michael: Quelque chose a-t-il changé au cours des 30 dernières années depuis la publication du livre ?
Tim: Vous pouvez voir cela sous de nombreux angles différents. Sociologiquement parlant... autrefois, dans des temps plus simples, vous et votre équipe étiez assis dans le même bureau. Vous pourriez être proches tous les jours, boire un café ensemble et discuter du travail. Ce qui a vraiment changé, c'est que les équipes peuvent désormais être réparties géographiquement, dans différents pays et fuseaux horaires, mais elles travaillent toujours sur le même problème, ce qui ajoute une toute nouvelle couche de complexité. Cela peut paraître old-school, mais il n'y a rien de tel qu'une communication en face-à-face où vous êtes tous ensemble, travaillant ensemble, et vous pouvez vous adresser à un collègue et lui dire : regardez ce que j'ai découvert, qu'est-ce que vous aimez ? Les conversations en face à face offrent un moyen rapide de passer à une communication informelle, et je pense que les passionnés d'agilité devraient également l'apprécier. Et je suis aussi inquiet parce qu'en réalité, le monde s'est avéré très petit, et maintenant tout est couvert d'équipes distribuées, et tout est très complexe.
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... il n'y a encore personne à Singapour. La différence géographique est assez grande et les gens commencent à se disperser encore plus. Si nous parlons de développement, pouvez-vous nous en dire plus sur le devops et la suppression des barrières entre les équipes ? Il existe une idée selon laquelle tout le monde est assis dans son bunker, et maintenant les bunkers s'effondrent, que pensez-vous de cette analogie ?
Tim: Il me semble qu'à la lumière des récentes avancées technologiques, le devops revêt une grande importance. Auparavant, vous aviez des équipes de développeurs et d'administrateurs, ils travaillaient, travaillaient, travaillaient, et à un moment donné, une chose est apparue avec laquelle vous pouviez vous adresser aux administrateurs et la déployer en production. Et ici, la conversation sur le bunker a commencé, car les administrateurs sont en quelque sorte des alliés, pas des ennemis, du moins, mais vous ne leur avez parlé que lorsque tout était prêt à passer en production. Êtes-vous allé vers eux avec quelque chose et leur avez-vous dit : regardez quelle application nous avons, mais pourriez-vous déployer cette application ? Et maintenant, tout le concept de livraison a changé pour le mieux. Je veux dire, il y avait cette idée selon laquelle on pouvait imposer des changements rapidement. Nous pouvons mettre à jour les produits à la volée. Je souris toujours lorsque Firefox sur mon ordinateur portable apparaît et dit, hé, nous avons mis à jour votre Firefox en arrière-plan, et dès que vous aurez une minute, cela vous dérangerait-il de cliquer ici et nous vous donnerons la dernière version. Et je me suis dit : "Oh ouais, bébé !" Pendant que je dormais, ils travaillaient à me livrer une nouvelle version directement sur mon ordinateur. C'est merveilleux, incroyable.
Mais voici la difficulté : vous disposez de cette fonctionnalité avec la mise à jour du logiciel, mais l’intégration des personnes est beaucoup plus difficile. Ce que je veux exprimer lors du discours d'ouverture de DevOops, c'est que nous avons désormais beaucoup plus de joueurs que jamais. Si vous pensez simplement à toutes les personnes impliquées dans une seule équipe…. Vous l'avez considéré comme une équipe, et c'est bien plus qu'une simple équipe de programmeurs. Ce sont des testeurs, des chefs de projet et bien 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. Cela devient un problème plutôt difficile de coordonner tous les participants afin de continuer à être conscients de ce qui se passe et de ne pas devenir fous. Il faut séparer les tâches du groupe et les tâches qui s'appliquent à chacun. C'est une tâche très difficile. D’un autre côté, je pense que tout va bien mieux qu’il y a de nombreuses années. C'est exactement le chemin sur lequel les gens grandissent et apprennent à se comporter correctement. Quand on fait de l'intégration, on comprend qu'il ne doit pas y avoir de développement souterrain, pour qu'au tout dernier moment le logiciel ne sorte pas comme un jack-in-the-box : genre, regardez ce qu'on a fait ici ! L'idée est que vous serez capable de faire de l'intégration et du développement, et à la fin vous effectuerez un déploiement soigné et itératif. Tout cela signifie beaucoup pour moi. Cela permet de créer plus de valeur pour les utilisateurs du système et pour votre client.
Michael: L'idée même du Devops est de fournir des développements significatifs 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, cela n’existait pas !
Tim: Bien sûr, tout le monde veut toujours plus de fonctionnalités. Pas besoin de bouger, il suffit d'en accumuler davantage. Parfois, vous devez même ralentir pour la prochaine mise à jour incrémentielle afin d'apporter quelque chose d'utile - et c'est tout à fait normal.
L’idée selon laquelle il faut courir, courir, courir n’est pas la meilleure. Il est peu probable que quiconque veuille vivre sa vie de cette façon. J’aimerais que le rythme des livraisons donne le rythme du projet. Si vous produisez simplement un flux de petites choses relativement dénuées de sens, tout cela n’a aucun sens. Au lieu d’essayer inconsidérément 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, c’est la stratégie. Est-ce que cela a un sens ?
Modèles et anti-modèles
Oleg: Vous parlez généralement de modèles et d’anti-modèles, et c’est la différence entre la vie et la mort des projets. Et maintenant, le Devops fait irruption dans nos vies. A-t-il ses propres modèles et anti-modèles qui peuvent tuer le projet sur le coup ?
Tim: Les modèles et les anti-modèles se produisent tout le temps. Quelque chose a raconter. Eh bien, il y a ce qu'on appelle des "choses brillantes". Les gens aiment vraiment, vraiment les nouvelles technologies. Ils sont simplement fascinés par l'éclat de tout ce qui a l'air cool et stylé, et ils arrêtent de se poser des questions : est-ce même nécessaire ? Qu’allons-nous réaliser ? Est-ce que cette chose est fiable, est-ce que cela a un sens ? Je vois souvent des gens, pour ainsi dire, à la pointe de la technologie. Ils sont hypnotisés par ce qui se passe dans le monde. Mais si vous regardez de plus près les choses utiles qu’ils font, il n’y a souvent tout simplement rien d’utile !
Nous venons de discuter avec nos camarades du fait que cette année est une année anniversaire, cinquante ans depuis que les hommes ont atterri sur la lune. C’était en 1969. La technologie qui a aidé les gens à y arriver n’est même pas celle de 1969, mais plutôt celle de 1960 ou 62, parce que la NASA voulait utiliser uniquement ce qui avait de bonnes preuves de fiabilité. Et donc vous le regardez et comprenez - oui, et c'était vrai ! Maintenant, non, non, mais vous avez des problèmes avec la technologie simplement parce que tout est poussé trop fort, vendu de toutes les fissures. Les gens crient de partout : « Regardez, quelle chose, c'est la chose la plus récente, la plus belle chose au monde, qui convient à absolument tout le monde ! » Eh bien, c'est tout... en général, tout cela s'avère n'être qu'un leurre, et il faut ensuite tout jeter. Peut-être est-ce dû au fait que je suis déjà un vieil homme et que je regarde ces choses avec beaucoup de scepticisme, lorsque les gens se précipitent et disent qu'ils ont trouvé la seule et la plus correcte manière de créer les meilleures technologies. À ce moment-là, une voix se réveille en moi qui dit : « Quel gâchis !
Michael: En effet, combien de fois avons-nous entendu parler de la prochaine solution miracle ?
Tim: Exactement, et c’est la marche habituelle des choses ! Par exemple... il semble que cela soit déjà devenu une plaisanterie dans le monde entier, mais ici, on parle souvent de la technologie blockchain. Et ils ont du sens dans certaines situations ! Lorsque vous avez vraiment besoin de preuves fiables des événements, que le système fonctionne et que personne ne nous a trompé, lorsque vous avez des problèmes de sécurité et tout le reste mélangés, la blockchain a du sens. Mais quand on dit que la Blockchain va désormais déferler sur le monde, balayant tout sur son passage ? Rêve plus! Il s’agit d’une technologie très coûteuse et complexe. Techniquement complexe et chronophage. Y compris de manière purement algorithmique, chaque fois que vous devez recalculer les mathématiques, avec les moindres changements... et c'est une excellente idée - mais seulement dans certains cas. Toute ma vie et ma carrière ont tourné autour de ça : des idées intéressantes dans des situations très précises. Il est très important de comprendre exactement quelle est votre situation.
Michael: Oui, la principale « question de la vie, de l’univers et de tout » : cette technologie ou cette approche est-elle adaptée à votre situation ou non ?
Tim: Cette question peut déjà être discutée avec le groupe technologique. Peut-être même faire appel à un consultant. Jetez un œil au projet et comprenez : allons-nous maintenant faire quelque chose de juste et d'utile, mieux qu'avant ? Peut-être que ça conviendra, peut-être pas. Mais surtout, ne prenez pas une telle décision par défaut, simplement parce que quelqu’un a laissé échapper : « Nous avons désespérément besoin d’une blockchain ! Je viens de lire quelque chose sur lui dans un magazine dans l'avion ! Sérieusement? Ce n'est même pas drôle.
Le mythique « ingénieur Devops »
Oleg: Maintenant, tout le monde implémente Devops. Quelqu'un lit des articles sur les Devops sur Internet et demain, un autre poste vacant apparaît sur un site de recrutement. "ingénieur devops". Ici, je voudrais attirer votre attention : pensez-vous que ce terme « ingénieur devops » a droit à la vie ? Il existe une opinion selon laquelle le Devops est une culture, et quelque chose ne colle pas ici.
Tim: Tellement tellement. Qu'ils donnent alors immédiatement quelques explications sur ce terme. De quoi le rendre unique. Jusqu'à ce qu'ils prouvent qu'il existe une combinaison unique de compétences derrière un poste vacant comme celui-ci, je ne l'achèterai pas ! Je veux dire, eh bien, nous avons un titre de poste, « ingénieur DevOps », un titre intéressant, oui, et ensuite ? Les titres de poste sont généralement une chose très intéressante. Disons « développeur », qu’est-ce que c’est ? Différentes organisations signifient des choses complètement différentes. Dans certaines entreprises, des programmeurs de haute qualité écrivent des tests qui ont plus de sens que les tests rédigés par des testeurs professionnels spéciaux dans d'autres entreprises. Et alors, sont-ils désormais programmeurs ou testeurs ?
Oui, nous avons des titres de poste, mais si vous posez des questions suffisamment longtemps, il s'avère finalement que nous sommes tous des résolveurs de problèmes. Nous sommes des chercheurs de solutions, et certains ont des compétences techniques et d’autres des compétences différentes. Si vous vivez dans un environnement où DevOps a pénétré, vous êtes engagé dans l'intégration du développement et de l'administration, et cette activité a un objectif assez important. Mais si on vous demande ce que vous faites exactement et de quoi vous êtes responsable, il s’avère que les gens font toutes ces choses depuis des temps immémoriaux. "Je suis responsable de l'architecture", "Je suis responsable des bases de données" et ainsi de suite, peu importe, voyez-vous - tout cela était avant "devops".
Quand quelqu’un me donne le titre de son poste, je n’écoute pas beaucoup. Il vaut mieux le laisser vous dire de quoi il est réellement responsable, cela nous permettra de mieux comprendre le problème. Mon exemple préféré est celui où une personne prétend être un « chef de projet ». Quoi? Ça ne veut rien dire, je ne sais toujours pas ce que tu fais. Un chef de projet peut être un développeur, le leader d'une équipe de quatre personnes, écrivant du code, effectuant un travail, devenu chef d'équipe, que les gens eux-mêmes reconnaissent entre eux comme un leader. Et aussi, un chef de projet peut être un manager qui gère six cents personnes sur un projet, gère d'autres managers, est chargé d'établir les plannings et de planifier les budgets, c'est tout. Ce sont deux mondes complètement différents ! Mais leur titre de poste sonne le même.
Tournons les choses un peu différemment. Dans quoi êtes-vous vraiment bon, avez-vous beaucoup d’expérience, avez-vous du talent ? De quoi allez-vous assumer la responsabilité parce que vous pensez pouvoir gérer la tâche ? Et ici, quelqu'un commencera immédiatement à nier : non, non, non, je n'ai aucune envie de m'occuper des ressources du projet, ce n'est pas mon affaire, je suis un mec technique et je comprends la convivialité et les interfaces utilisateur, je ne le fais pas Je veux gérer des armées de personnes, laissez-moi mieux aller travailler.
Et d'ailleurs, je suis un fervent partisan d'une approche dans laquelle ce type de séparation des compétences fonctionne bien. Où les techniciens peuvent développer leur carrière autant qu’ils le souhaitent. Cependant, je vois encore des organisations où les techniciens se plaignent : je vais devoir me lancer dans la gestion de projet car c'est la seule voie dans cette entreprise. Parfois, cela conduit à des résultats terribles. Les meilleurs techniciens ne sont pas du tout de bons managers, et les meilleurs managers ne savent pas gérer la technologie. Soyons honnêtes à ce sujet.
Je vois beaucoup de demande pour cela maintenant. Si vous êtes un passionné de technologie, votre entreprise peut vous aider, mais quoi qu'il en soit, vous devez vraiment trouver votre propre cheminement de carrière, car la technologie ne cesse d'évoluer et vous devez vous réinventer en même temps ! En seulement vingt ans, les technologies peuvent changer au moins cinq fois. La technologie est une chose étrange...
"Des experts en tout"
Michael: Comment les gens peuvent-ils faire face à une telle rapidité d’évolution technologique ? Leur complexité augmente, leur nombre augmente, le volume total de communication entre les personnes augmente également, et il s'avère qu'il est impossible de devenir un « expert en tout ».
Tim: Droite! Si vous travaillez dans le domaine de la technologie, oui, vous devez absolument choisir quelque chose de spécifique et vous y plonger. Une technologie que votre organisation trouve utile (et qui sera peut-être réellement utile). Et si cela ne vous intéresse plus - je n'aurais jamais cru dire cela - eh bien, vous devriez peut-être déménager dans une autre organisation où la technologie est plus intéressante ou plus pratique à étudier.
Mais en général, oui, vous avez raison. Les technologies se développent dans toutes les directions à la fois ; personne ne peut dire : « Je suis un technologue expert dans toutes les technologies qui existent ». D’un autre côté, il y a les éponges qui absorbent littéralement les connaissances technologiques et en sont folles. J'ai vu quelques-unes de ces personnes, elles respirent et vivent littéralement, c'est utile et intéressant de leur parler. Ils étudient non seulement ce qui se passe au sein de l'organisation, mais en général, ils en parlent, ce sont aussi des technologues vraiment sympas, ils sont très conscients et déterminés. Ils essaient simplement de rester au sommet de la vague, quel que soit leur travail principal, car leur passion est le mouvement de la technologie, la promotion de la technologie. Si vous rencontrez soudainement une telle personne, vous devriez aller déjeuner avec elle et discuter de diverses choses sympas pendant le déjeuner. Je pense que toute organisation a besoin d’au moins deux de ces personnes.
Risques et incertitudes
Michael: Des ingénieurs honorés, oui. Parlons de la gestion des risques pendant que nous en avons le temps. Nous avons commencé cette interview par une discussion sur les logiciels médicaux, où les erreurs peuvent avoir des conséquences désastreuses. Ensuite, nous avons parlé du programme lunaire, où le coût d'une erreur s'élève à des millions de dollars, et peut-être à plusieurs vies humaines. Mais maintenant, je constate le mouvement inverse dans l’industrie : les gens ne pensent pas aux risques, n’essaient pas de les prédire, ne les observent même pas.
Oleg: Déplacez-vous vite et cassez des objets !
Michael: Oui, avancez vite, cassez des choses, toujours plus de choses, jusqu'à mourir de quelque chose. De votre point de vue, comment le développeur moyen devrait-il désormais aborder l'apprentissage de la gestion des risques ?
Tim: Tirons ici une ligne entre deux choses : les risques et l’incertitude. Ce sont des choses différentes. L'incertitude survient lorsque vous ne disposez pas de suffisamment de données à un moment donné pour arriver à une réponse définitive. Par exemple, au tout début d’un projet, si quelqu’un vous demande « quand allez-vous terminer le travail », si vous êtes une personne assez honnête, vous répondrez : « Je n’en ai aucune idée ». Vous ne le savez tout simplement pas, et ce n'est pas grave. Vous n'avez pas encore étudié les problèmes et ne connaissez pas l'équipe, vous ne connaissez pas ses compétences, etc. C’est l’incertitude.
Des risques surviennent lorsque des problèmes potentiels peuvent déjà être identifiés. Ce genre de chose peut arriver, sa probabilité est supérieure à zéro, mais inférieure à cent pour cent, quelque part entre les deux. Grâce à cela, tout peut arriver, depuis des retards et des travaux inutiles, jusqu'à une issue fatale pour le projet. Le résultat, quand vous dites : les gars, plions nos parapluies et quittons la plage, on n'en finira jamais, c'est fini, point barre. Nous avions supposé que cela fonctionnerait, mais cela ne fonctionne pas du tout, il est temps d’arrêter. Voilà les situations.
Souvent, les problèmes sont plus faciles à résoudre lorsqu’ils sont déjà apparus, lorsqu’ils surviennent au moment même. Mais lorsqu'un problème est devant vous, vous ne faites pas de gestion des risques, vous faites de la résolution de problèmes, de la gestion de crise. Si vous êtes un développeur ou un gestionnaire principal, vous devez vous demander ce qui pourrait arriver qui pourrait entraîner des retards, une perte de temps, des coûts inutiles ou l'effondrement de l'ensemble du projet ? Qu’est-ce qui nous fera arrêter et recommencer ? Quand toutes ces choses fonctionneront, qu’en ferons-nous ? Il existe une réponse simple qui s’applique à la plupart des situations : ne fuyez pas les risques, travaillez-y. Voyez comment vous pouvez résoudre une situation à risque, la réduire à néant, la transformer d'un problème en autre chose. Au lieu de dire : eh bien, nous résoudrons les problèmes au fur et à mesure qu’ils surviennent.
L’incertitude et le risque doivent être au premier plan de tout ce à quoi vous faites face. Vous pouvez prendre un plan de projet, examiner certains risques critiques à l’avance et dire : nous devons nous en occuper maintenant, car si quelque chose de tout cela tourne mal, rien d’autre n’aura d’importance. Ne vous inquiétez pas de la beauté de la nappe sur la table si vous ne savez pas si vous pouvez préparer le dîner. Vous devez d’abord identifier tous les risques liés à la préparation d’un délicieux dîner, y faire face et ensuite seulement penser à toutes les autres choses qui ne constituent pas une menace réelle.
Encore une fois, qu’est-ce qui rend votre projet unique ? Voyons ce qui peut faire dérailler notre projet. Que pouvons-nous faire pour minimiser la probabilité que cela se produise ? Habituellement, on ne peut pas les neutraliser à 100 % et déclarer en toute bonne conscience : « Ça y est, ce n’est plus un problème, le risque est résolu ! » Pour moi, c'est un signe de comportement adulte. C'est la différence entre un enfant et un adulte : les enfants pensent qu'ils sont immortels, que rien ne peut aller mal, que tout ira bien ! En même temps, les adultes regardent les enfants de trois ans sauter sur l'aire de jeux, suivre les mouvements des yeux et se dire : « ooh-ooh, ooh-ooh ». Je me tiens à proximité et me prépare à rattraper l'enfant lorsque celui-ci tombe.
D’un autre côté, la raison pour laquelle j’aime tant ce métier, c’est parce qu’il est risqué. Nous faisons des choses, et ces choses sont risquées. Ils nécessitent une approche adulte. L’enthousiasme à lui seul ne résoudra pas vos problèmes !
Pensée d'ingénierie adulte
Michael: L'exemple avec les enfants est bon. Si je suis un ingénieur ordinaire, alors je suis heureux d'être un enfant. Mais comment évoluer vers une pensée plus adulte ?
Tim: L'une des idées qui fonctionne aussi bien avec un développeur débutant qu'avec un développeur confirmé est le concept de contexte. Ce que nous faisons, ce que nous allons réaliser. Qu’est-ce qui est vraiment important dans ce projet ? Peu importe qui vous êtes sur ce projet, que vous soyez stagiaire ou architecte en chef, tout le monde a besoin de contexte. Nous devons amener chacun à réfléchir à une échelle plus large que son propre travail. «Je fabrique ma pièce, et tant que ma pièce fonctionne, je suis heureux.» Non et non encore. Cela vaut toujours la peine (sans être impoli !) de rappeler aux gens le contexte dans lequel ils travaillent. Ce que nous essayons tous de réaliser ensemble. L’idée que vous pouvez être un enfant tant que tout va bien dans votre partie du projet – s’il vous plaît, ne faites pas ça. Si nous franchissons la ligne d’arrivée, nous ne la franchirons qu’ensemble. Vous n'êtes pas seul, nous sommes tous ensemble. Si tous les participants au projet, jeunes et vieux, commençaient à parler de ce qui est exactement important pour le projet, de la raison pour laquelle l'entreprise investit de l'argent dans ce que nous essayons tous de réaliser... la plupart d'entre eux se sentiront beaucoup mieux parce qu'ils verrons comment leur travail est en corrélation avec le travail de tous les autres. D’une part, je comprends la pièce dont je suis personnellement responsable. Mais pour terminer le travail, nous avons aussi besoin de tous les autres. Et si vous pensez vraiment avoir terminé, nous avons toujours du travail à faire dans le projet !
Oleg: Relativement parlant, si vous travaillez selon Kanban, lorsque vous rencontrez un goulot d'étranglement lors de certains tests, vous pouvez quitter ce que vous y faisiez (par exemple, programmer) et aller aider les testeurs.
Tim: Exactement. Je pense que les meilleurs techniciens, si vous les regardez de près, sont en quelque sorte leurs propres managers. Comment puis-je formuler cela...
Oleg: Votre vie est votre projet, que vous gérez.
Tim: Exactement! Je veux dire, vous prenez vos responsabilités, vous comprenez le problème et vous entrez en contact avec les gens lorsque vous voyez que vos décisions peuvent affecter leur travail, des choses comme ça. Il ne s’agit pas simplement de rester assis à votre bureau, de faire votre travail et de ne même pas réaliser ce qui se passe autour de vous. Non non Non. D’ailleurs, l’une des meilleures choses d’Agile est qu’ils proposent des sprints courts, car de cette façon, la situation de tous les participants est clairement observable, ils peuvent tout voir ensemble. Nous parlons les uns des autres tous les jours.
Comment se lancer 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 souhaite comprendre la gestion des risques sans devenir un véritable chef de projet de formation. Je lirai probablement d'abord "Combien coûte un projet logiciel" de McConnell, et ensuite quoi ? Quelles sont les premières étapes?
Tim: La première est de commencer à communiquer avec les personnes participant au projet. Cela permet une amélioration immédiate de la culture de communication avec les collègues. Nous devons commencer par tout ouvrir par défaut, au lieu de le cacher. Dites : ce sont les choses qui me dérangent, ce sont les choses qui m'empêchent de dormir la nuit, je me suis réveillé la nuit aujourd'hui et je me suis dit : mon Dieu, je dois y penser ! Est-ce que d'autres voient la même chose ? En tant que groupe, devrions-nous répondre à ces problèmes potentiels ? Vous devez être capable de soutenir une discussion sur ces sujets. Il n’existe pas de formule pré-préparée avec laquelle nous travaillons. Il ne s’agit pas de faire des hamburgers, mais des gens. « Faire un cheeseburger, vendre un cheeseburger » n'est pas du tout notre truc, et c'est pourquoi j'aime tant ce métier. J’aime quand tout ce que faisaient les managers devient désormais la propriété de l’équipe.
Oleg: Vous avez parlé dans des livres et des interviews du fait que les gens se soucient davantage du bonheur que des chiffres sur un graphique. Par contre, quand on dit à l'équipe : on passe au devops, et maintenant le programmeur doit constamment communiquer, cela peut être bien en dehors de sa zone de confort. Et à ce moment-là, il peut, disons, être profondément malheureux. que-faire dans cette situation?
Tim: Je ne sais pas exactement quoi faire. Si un développeur est trop isolé, il ne voit pas pourquoi le travail est effectué en premier lieu, il regarde simplement sa part du travail et il doit entrer dans ce que j'appelle le « contexte ». Il doit comprendre comment tout est connecté. Et bien sûr, je ne parle pas de présentations formelles ou quoi que ce soit du genre. Je parle du fait que vous devez communiquer avec vos collègues sur le travail dans son ensemble, et pas seulement sur la partie dont vous êtes responsable. C'est ici que vous pouvez commencer à discuter d'idées, d'accords communs pour que votre travail s'articule bien et de la manière de résoudre ensemble un problème commun.
Pour les aider à s'adapter, ils souhaitent souvent envoyer des techniciens en formation, et ils discutent de formation. Un de mes amis aime dire que le dressage est réservé aux chiens. Il y a une formation pour les gens. L'une des meilleures choses dans l'apprentissage en tant que développeur est d'interagir avec vos pairs. Si quelqu'un est vraiment bon dans quelque chose, vous devriez le regarder travailler ou lui parler de son travail ou de quelque chose du genre. Certains Kent Beck conventionnels parlaient constamment de programmation extrême. C'est drôle parce que XP est une idée si simple, mais elle pose tellement de problèmes. Pour certains, faire XP, c'est comme être obligé de se déshabiller devant des amis. Ils verront ce que je fais ! Ce sont mes collègues, non seulement ils verront, mais ils comprendront aussi ! Terrible! Certaines personnes commencent à devenir sérieusement nerveuses. Mais quand on réalise que c’est la meilleure façon d’apprendre, tout change. Vous travaillez en étroite collaboration avec les gens et certaines personnes comprennent le sujet bien mieux que vous.
Michael: Mais tout cela vous oblige à sortir de votre zone de confort. En tant qu'ingénieur, vous devez sortir de votre zone de confort et communiquer. En tant que solutionneur de problèmes, vous devez constamment vous mettre dans une position de faiblesse et réfléchir à ce qui pourrait mal se passer. Ce type de travail est par nature conçu pour être une nuisance. Vous vous mettez consciemment dans des situations stressantes. Habituellement, les gens les fuient, ils aiment être des enfants heureux.
Tim: Que peut-on faire, vous pouvez sortir et dire ouvertement : « Tout va bien, je peux le gérer ! Je ne suis pas le seul à me sentir mal à l'aise. Discutons de diverses choses inconfortables, tous ensemble, en équipe ! Ce sont nos problèmes communs, nous devons les résoudre, vous savez ? Je pense que les développeurs de génie idiosyncrasiques sont comme des mammouths : ils ont disparu. Et leur importance est très limitée. Si vous ne pouvez pas communiquer, vous ne pouvez pas bien participer. Par conséquent, parlez simplement. Soyez honnête et ouvert. Je suis vraiment désolé que cela soit désagréable pour quelqu'un. Pouvez-vous imaginer qu'il y a de nombreuses années, il y a eu une étude selon laquelle la principale peur aux États-Unis n'est pas la mort, mais devinez quoi ? Peur de parler en public ! Cela signifie que quelque part, il y a des gens qui préfèrent mourir plutôt que de dire un compliment à haute voix. Et je pense qu’il suffit d’avoir quelques compétences de base, selon ce que l’on fait. Compétences orales et écrites - mais seulement dans la mesure où cela est réellement nécessaire dans votre travail. Si vous travaillez comme analyste, mais que vous ne savez pas lire, écrire ou parler, alors, malheureusement, vous n'aurez rien à faire dans mes projets !
Le prix de la communication
Oleg: Embaucher de tels employés extravertis n'est-il pas plus coûteux pour diverses raisons ? Après tout, ils discutent constamment au lieu de travailler !
Tim: Je parlais du noyau de l’équipe, et pas de tout le monde. Si vous avez quelqu'un qui est vraiment doué pour régler des bases de données, qui adore régler des bases de données et qui va continuer à régler vos bases de données pour le reste de sa vie et c'est tout, cool, continuez comme ça. Mais je parle de personnes 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 les objectifs mondiaux, etc.
Michael: Cela s'applique à toutes les personnes impliquées dans le projet, quelles que soient leur spécialisation, leurs compétences ou leurs méthodes de travail. Vous êtes tous intéressés par la réussite du projet.
Tim: Oui, vous sentez que vous êtes suffisamment immergé dans le projet, que votre tâche est d'aider le projet à se réaliser. Que vous soyez programmeur, analyste, concepteur d'interfaces, 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 ayant des conversations entre adultes.
Oleg: En fait, en parlant d'employés bavards, j'ai essayé de simuler les objections des personnes, notamment des managers, à qui on demande de passer au Devops, à cette toute nouvelle vision du monde. Et vous, en tant que consultants, devriez être bien mieux conscients de ces objections que moi, en tant que développeur ! Partagez ce qui inquiète le plus les managers ?
Tim: Des gestionnaires ? Hum. Le plus souvent, les managers sont sous pression en raison de problèmes, confrontés à la nécessité de publier de toute urgence quelque chose et d'effectuer une livraison, etc. Ils regardent comment nous discutons et argumentons constamment sur quelque chose, et ils le voient comme ceci : des conversations, des conversations, des conversations... Quelles autres conversations ? Retourne travailler! Parce que parler ne leur semble pas être un travail. Vous n’écrivez pas de code, ne testez pas de logiciels, ne semblez rien faire – pourquoi ne pas vous envoyer faire quelque chose ? Après tout, la livraison est déjà dans un mois !
Michael: Allez écrire du code !
Tim: Il me semble qu’ils ne s’inquiètent pas du travail, mais du manque de visibilité des progrès. Pour donner l’impression que nous nous rapprochons du succès, ils ont besoin de nous voir appuyer sur les boutons du clavier. Toute la journée du matin au soir. C'est le problème numéro un.
Oleg: Misha, tu penses à quelque chose.
Michael: Désolé, je me suis perdu dans mes pensées et j'ai eu un flash-back. Tout cela m'a rappelé un rassemblement intéressant qui a eu lieu hier... Il y a eu trop de rassemblements hier... Et tout cela me semble très familier !
La vie sans salaire
Tim: D'ailleurs, il n'est pas du tout nécessaire d'organiser des « rassemblements » de communication. Je veux dire, les discussions les plus utiles entre développeurs ont lieu lorsqu'ils se parlent simplement. Vous arrivez le matin avec une tasse de café et cinq personnes sont rassemblées et discutent furieusement de quelque chose de technique. Pour moi, si je suis le responsable de ce projet, il vaut mieux simplement sourire et vaquer quelque part à mes affaires, les laisser en discuter. Ils sont déjà impliqués autant que possible. C'est un bon signe.
Oleg: À propos, dans votre livre, vous avez un tas de notes sur ce qui est bon et ce qui est mauvais. En utilisez-vous vous-même ? Relativement parlant, vous avez désormais une entreprise, et une structure très peu orthodoxe...
Tim: Peu orthodoxe, mais cet appareil nous convient parfaitement. Nous nous connaissons depuis longtemps. Nous nous faisons confiance, nous nous faisions beaucoup 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 auprès de mes clients, alors tout l'argent me revenait. Après cela, nous payons des cotisations à l'organisation, ce qui suffit à subvenir aux besoins de l'entreprise elle-même. De plus, nous sommes tous spécialisés dans des domaines différents. 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 Web et personne ne les paie non plus. Tant que vous payez votre cotisation, personne ne pensera à 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 ; il fait certaines choses qui ne sont pas pour la Guilde. Mais tant qu’il paie sa cotisation, personne ne viendra vers lui pour lui dire : « Hé, Tom, va 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 par rapport aux différentes spécialités. Cela fonctionne et cela fonctionne très bien.
meilleur conseil
Michael: Pour en revenir aux « meilleurs conseils », y a-t-il quelque chose que vous dites encore et encore à vos clients ? Il existe une idée autour de 80/20, et certains conseils sont probablement répétés plus souvent.
Tim: Un jour, j'ai pensé que si vous écriviez un livre comme Valser avec les ours, cela changerait le cours de l'histoire et les gens s'arrêteraient, mais... Eh bien, écoutez, les entreprises prétendent souvent que tout va bien pour elles. Dès que quelque chose de grave arrive, c’est pour eux un choc et une surprise. « Écoutez, nous avons testé le système, et il ne réussit aucun test du système, et c'est encore trois mois de travail imprévu, comment cela a-t-il pu arriver ? Qui savait? Qu'est-ce qui pourrait mal se passer? Sérieusement, tu crois ça ?
J'essaie de vous expliquer qu'il ne faut pas trop se mettre en colère face à la situation actuelle. Nous devons en parler, vraiment comprendre ce qui aurait pu mal se passer et comment empêcher que de telles choses ne se reproduisent à l’avenir. Si un problème apparaît, comment allons-nous le combattre, comment allons-nous le contenir ?
Pour moi, tout cela semble effrayant. Les gens sont confrontés à des problèmes complexes et épineux et continuent de prétendre que s’ils croisent les doigts et espèrent le meilleur, le « meilleur » se produira réellement. Non, ça ne marche pas comme ça.
Pratiquez la gestion des risques !
Michael: Selon vous, combien d’organisations s’engagent dans la gestion des risques ?
Tim: Ce qui m'exaspère, c'est que les gens notent simplement les risques, regardent la liste qui en résulte et se mettent au travail. En fait, identifier les risques pour eux est une gestion des risques. Mais pour moi, cela ressemble à une raison de demander : d’accord, il y a une liste, qu’allez-vous changer exactement ? Vous devez modifier vos séquences d'actions standard en tenant compte de ces risques. S'il y a une partie du travail la plus difficile, vous devez vous y attaquer et ensuite seulement passer à quelque chose de plus simple. Dès les premiers sprints, commencez à résoudre des problèmes complexes. Cela ressemble déjà à de 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 entreprises sont impliquées dans la gestion des risques, cinq pour cent ?
Tim: Malheureusement, je déteste dire cela, mais c'est une partie très insignifiante. Mais plus de cinq, car il y a de très grands projets, et ils ne peuvent tout simplement pas exister s’ils ne font pas au moins quelque chose. Disons simplement que je serai très surpris si c'est au moins 25 %. Les petits projets répondent généralement à ces questions de cette façon : si le problème nous affecte, alors nous le résoudrons. Ensuite, ils réussissent à se mettre en difficulté et à s’engager dans la gestion des problèmes et de la gestion des crises. Lorsque vous essayez de résoudre un problème et que celui-ci n’est pas résolu, bienvenue dans la gestion de crise.
Oui, j’entends souvent : « nous résoudrons les problèmes au fur et à mesure qu’ils surviennent ». Nous le ferons sûrement ? Allons-nous vraiment décider ?
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. Cela s'avère très piembucky.
Michael: Oui, il m'est arrivé que lorsque des risques se déclenchaient, le projet était tout simplement redéfini. Bien, bingo, problème résolu, ne vous inquiétez plus !
Tim: Appuyons sur le bouton de réinitialisation ! Non, ça ne marche pas comme ça.
Discours d'ouverture à DevOops 2019
Michael: Nous arrivons à la dernière question de cet entretien. Vous venez au prochain DevOops avec une keynote, pourriez-vous lever le rideau du secret sur ce que vous allez raconter ?
Tim: En ce moment, six d’entre eux écrivent un livre sur la culture du travail, les règles tacites des organisations. La culture est déterminée par les valeurs fondamentales de l’organisation. Habituellement, les gens ne le remarquent pas, mais ayant travaillé dans le conseil pendant de nombreuses années, nous avons l'habitude de le remarquer. Vous entrez dans une entreprise et, en quelques minutes, vous commencez à ressentir ce qui se passe. Nous appelons cela « saveur ». Parfois, ce parfum est vraiment bon, et parfois c'est, eh bien, oups. Les choses sont très différentes selon les organisations.
Michael: Moi aussi, je travaille dans le conseil depuis des années et je comprends bien de quoi vous parlez.
Tim: En fait, l’une des choses qui méritent d’être évoquées lors du discours d’ouverture est que tout n’est pas déterminé par l’entreprise. Vous et votre équipe, en tant que communauté, avez votre propre culture d'équipe. Il peut s'agir de l'ensemble de l'entreprise, ou d'un département distinct, d'une équipe distincte. Mais avant de dire, voici ce que nous croyons, voici ce qui est important... Vous ne pouvez pas changer une culture avant que les valeurs et les croyances qui sous-tendent des actions spécifiques ne soient comprises. Le comportement est facile à observer, mais la recherche de croyances est difficile. DevOps n’est qu’un excellent exemple de la façon dont les choses deviennent de plus en plus complexes. Les interactions ne font que devenir plus complexes, elles ne deviennent pas du tout plus claires ou plus claires, vous devriez donc penser à ce en quoi vous croyez et à ce sur quoi tout le monde autour de vous reste silencieux.
Si vous souhaitez obtenir des résultats rapides, voici un bon sujet pour vous : avez-vous vu des entreprises où personne ne dit « je ne sais pas » ? Il y a des endroits où l’on torture littéralement une personne jusqu’à ce qu’elle admette qu’elle ne sait pas quelque chose. Tout le monde sait tout, tout le monde est un érudit incroyable. Vous approchez n'importe quelle personne et elle doit répondre instantanément à la question. Au lieu de dire « je ne sais pas ». Hourra, ils ont embauché une bande d'érudits ! Et dans certaines cultures, il est généralement très dangereux de dire « je ne sais pas » ; cela peut être perçu comme un signe de faiblesse. Il existe aussi des organisations dans lesquelles, au contraire, chacun peut dire « je ne sais pas ». Là, c’est tout à fait légal, et si quelqu’un commence à dire des bêtises en réponse à une question, il est tout à fait normal de répondre : « Vous ne savez pas de quoi vous parlez, n’est-ce pas ? et transformer tout cela en blague.
Idéalement, vous aimeriez avoir un travail dans lequel vous pourriez être heureux à tout moment. Ce ne sera pas facile, tous les jours ne sont pas ensoleillés et agréables, il faut parfois travailler dur, mais quand vous commencerez à faire le point, vous obtiendrez : wow, c'est un endroit vraiment merveilleux, je me sens bien en travaillant ici, à la fois émotionnellement et intellectuellement. Et il y a des entreprises où vous allez en tant que consultant et réalisez instantanément que vous ne pourriez pas le supporter pendant trois mois et que vous vous enfuiriez avec horreur. C’est ce dont je veux parler dans le rapport.
Tim Lister arrivera avec un discours à la conférence DevOops 2019, qui aura lieu les 29 et 30 octobre 2019 à Saint-Pétersbourg. Vous pouvez acheter des billets . Nous vous attendons chez DevOops !
Source: habr.com