Transparence - La panacée des bouchers

J'ai déjà essayé de traiter une mêlée «mécanique» ( partie 1 , partie 2 , partie 3 ), et dans cet article je vais essayer d'écrire un médicament universel pour «brûler». En soi, "brûler", "bouillonner", etc. - c'est bien, cela signifie que vous ne vous souciez pas ( mais l'indifférence est un pas vers le découragement, ou, comme c'est la coutume en informatique, vers l'épuisement professionnel ). De nombreux documents ont été écrits et tournés sur le thème des brûlures, par exemple: ici , ici , ici ou ici .

Une sagesse commune dit: "Les Buttherts sont le moteur du progrès." Mais cela se produit souvent comme ceci: il est brûlé => une solution superficielle est rapidement adoptée, masquant le problème => la solution prend vie => elle continue de brûler. En d'autres termes, au lieu de trier et de poser un diagnostic, nous procédons immédiatement au traitement. Je vais essayer d'illustrer cela avec des exemples.


Définissons d'abord le terme «transparence». Le guide Scrum le définit ainsi:

Les aspects importants du processus doivent être visibles pour les responsables du résultat. La transparence exige que ces aspects soient définis par une norme commune afin que les observateurs partagent une compréhension commune de ce qui est vu.

Les aspects importants du processus devraient être visibles pour les responsables du résultat. Ces aspects devraient être définis par une norme commune afin que les observateurs comprennent également l'objet d'observation.

Ces définitions ne s'appliquent qu'au processus, je veux considérer le concept plus largement. Je ne m'engagerai pas à donner des définitions scientifiques exactes, mais j'essaierai de décrire la «transparence» à travers les conditions nécessaires à son existence. Donc, pour plus de transparence, vous avez besoin de:

• L'objet dont quelqu'un a besoin ;
• Un objectif commun pour toutes les parties prenantes liées à l'installation;
• Le désir de toutes les parties prenantes d'atteindre l'objectif;
• La capacité de tous à communiquer dans une seule langue, c'est-à-dire la capacité à développer un tel cadre conceptuel qui sera significatif pour toutes les parties intéressées ( par exemple, des termes tels que ROI et Redux , il semble qu'ils se trouvent dans des plans différents et distants, bien que très volumineux dans des environnements d'information spécifiques ).

Si ces conditions nécessaires sont remplies, vous pouvez commencer le processus de construction de la transparence: définir la tâche, définir des critères de réussite pour résoudre le problème, développer une méthode pour évaluer les critères. Comment cela peut-il être:

Tout d'abord, nous répondons aux principales questions:

• Qu'est-ce que tu vas faire?
• Quel est le but?

La séquence d'actions suivante est possible:

• Nous définissons la terminologie ( par exemple, tout le monde comprend la tâche terminée de la même manière, et non pour que, pour le développement, ce soit lorsque le code est écrit, et pour les entreprises, c'est lorsque le client a commencé à utiliser les résultats );
• Nous sommes d'accord sur les aspects clés et comment nous mesurerons leur état, comment nous percevrons les résultats ( par exemple, nous nous réunissons une fois par jour, examinons le plan, déterminons notre état par rapport à ce plan );
• Nous incarnons notre plan.

Par ailleurs, je tiens à souligner que la cohérence et l'adoption générale des accords sont importantes, sans lesquelles il est difficile de parvenir à un engagement. En effet, dans les systèmes de prise de décision ( par exemple, dans l'armée ) la base conceptuelle est uniforme, les actions et les critères d'évaluation sont clairs, mais combien est accepté ( y a-t-il empathie ) par les participants est une grande question.

J'espère avoir réussi à révéler mon idée de la transparence, alors je vais essayer de donner quelques exemples de situations qui peuvent être améliorées si la transparence est ajoutée.

Suis-je une créature tremblante ou ai-je le droit?

Récemment, il me semble que la question de l'épuisement professionnel dans l'environnement informatique a été très aiguë ( des mitaps thématiques entiers sont organisés sur ce sujet, par exemple PiterJS , où il y avait un rapport de ma collègue Zhenya Kot bunopus ).


Notre travail est intellectuel, l'état d'esprit est analytique, eh bien, vous êtes vous-même au courant. Il me semble qu'il y a une tendance à inventer des difficultés là où elles n'existent pas. Parfois, cela vient précisément du manque de transparence ( voici quelques résultats de recherche: un et deux ), et non en raison de la grande quantité de travail: il n'y a pas d'informations nécessaires - je vais les fournir moi-même ( rappelez-vous la mentalité analytique ), je tirerai des conclusions de l'hypothèse - je ferai un plan et aller à la guerre avec des châteaux en l'air. Voici les questions qui peuvent nous concerner ( informaticiens ):

• Mais est-ce que je fais des bêtises? Comment mon travail améliore-t-il le monde?
• Dans quelle mesure suis-je bon dans mon entreprise?
• Oui, ils savent qui je suis? Qui sont-ils? Que se permettent-ils?
• Et ensuite? Où vais-je? Dois-je aller avec ceux-ci?

Les questions sont correctes, il est important pour une personne de réfléchir sur le passé, de penser au présent et de planifier l'avenir. Il est important de penser aux gens qui sont autour. Et le transférer au travail, bien sûr, nous pouvons nous attendre à ce que les travailleurs eux-mêmes cherchent des réponses à ces questions, clarifient ce qui les concerne. Mais vous pouvez simplement rendre tout cela transparent, puis les gens se concentreront sur des sujets plus élevés et résoudront les problèmes au niveau suivant, visant l'optimisation, l'innovation, etc. Il existe des tonnes d'outils pour fournir ce type de transparence, voici quelques exemples:

• Les objectifs, la mission et la stratégie de l'entreprise sont ouverts et compréhensibles pour les employés, et ils sont bien connus. Toutes les tâches tactiques sont enseignées par la communication avec la stratégie, il est toujours clair pour quel objectif actuel tel ou tel travail est requis. Il est clair non seulement ce qui doit être fait, mais aussi pourquoi cela doit être fait.
• Les employés reçoivent régulièrement des informations sur les résultats de leur travail: réalisations, points de croissance ( par exemple, 360 ou 1 à 1 sondages ). Planification conjointe du développement et inspection de la dynamique de réalisation de ce plan.
• La structure organisationnelle décrite et les communications qu'elle contient: quoi et avec qui vous pouvez parler. Contrats sociaux, cartes de visite d'équipe, etc.
• Un système de motivation transparent, un arbre de carrière et, éventuellement, une gamification de ce processus. Vous pouvez vous inspirer d'exemples de litres ou de 2GIS , et construire votre culture dans laquelle les employés comprennent comment déterminer et influencer leur niveau de motivation matérielle.

Maintenant, cependant, comme toujours, tout le monde est engagé dans la recherche de «la place d'une personne dans ce monde», et si les outils sont donnés pour se définir au moins au travail, un tel employé sera un peu plus harmonieux et plus heureux, et il y aura peut-être moins de cas d'épuisement professionnel.

Croisades

Nous, les Blancs, aimons briser les lances dans les guerres saintes: React vs Angular , iOS vs Android, OOP vs fonctionnalité, etc. Mais malheureusement ou heureusement, il n'y a pas de «solution miracle». Il existe une tâche et des solutions spécifiques. Lorsque nous sommes confrontés au choix de la technologie, du cadre, de l'architecture, etc., avec un degré élevé de probabilité, nous sommes dans un domaine «confus», selon le modèle de Kenevin , et, par conséquent, il n'y a pas de bonne réponse. Dans cette situation, il est souhaitable de réaliser et de résoudre le problème résolu, de comprendre quelles alternatives nous envisageons, quels critères nous avons pour prendre des décisions. Il est nécessaire de collecter ces données ensemble, de faire un choix et de les documenter également. Au fil du temps, il vaut la peine de revenir sur ces artefacts et de se réconcilier avec l'endroit où nous nous déplaçons. Tout est variable: le monde, l'entreprise, l'équipe, les personnes spécifiques, les conditions, etc., donc, lorsque nous avons des informations sur les domaines et pourquoi nous avons choisi, il est plus facile d'ajuster le chemin en fonction de ces connaissances. Et pour ne pas tomber dans la situation classique de déchirer un gilet sur sa poitrine : «Mais qui a jamais inventé tout ça?! Il semble que les gens n'étaient pas adaptés, une fois que cela est entassé. Voici la bonne réponse, c'est évident. Je vais sauver tout le monde et tout refaire. "

Je pense que beaucoup de gens connaissent la situation où, dans le but de construire un "nouveau monde merveilleux", ils changent leurs chefs, l'équipe, en ceux qui sont prêts à brûler Babylone, mais le résultat n'est pas un phénix, mais un gobelin.

Vous pouvez essayer de ne pas vous couper l'épaule, mais analyser rétrospectivement toutes les erreurs et inexactitudes, suivre la logique des décisions techniques, prendre en compte les risques et avancer une nouvelle hypothèse. Et la base de la prise de décision ne sera pas "ils sont tous des imbéciles ...", mais "les conditions ont changé et nous résolvons déjà un nouveau problème".

Il me semble qu’il est difficile de toujours prendre les bonnes décisions techniques. Vous pouvez apprendre à mettre en place des expériences, évaluer les résultats obtenus et planifier les prochaines étapes, en tenant compte des nouvelles informations reçues. Et cela peut être plus facile si vous avez à la disposition de toutes les parties intéressées des artefacts décrivant la logique des décisions techniques.

Implémenter agile / scrum / kanban / lean dans cp * ki compressé

Il y a un débat éternel dans l'environnement Agile: "Par où commencer la transformation: de la culture / des valeurs / de l'état d'esprit ou de la mécanique / des rituels / des artefacts?". Un tel dilemme classique du poulet et des œufs. Ma position est qu'avec un entraîneur agile «fort et indépendant», il peut arriver qu'une équipe de mécaniciens vienne progressivement à la pleine conscience. Mais le plus souvent, si vous commencez par la mécanique et introduisez une sorte d'approche en tant que culte du fret, alors nous aurons probablement du scepticisme et de la déception dans la méthodologie, et dans le pire des cas, nous gagnerons également des ennemis. Comment cela peut se produire est bien décrit dans le Scream Guide ( ici une traduction ardente ).

Par conséquent, je suis en faveur d'analyser la quantité de valeurs Agile dans votre cas, et ensuite de procéder à l'application d'un cadre ou d'une technique. Il n'y a pas de test universel, mais il y a des articles décisifs ( par exemple: test agile et guide agile ): réfléchissez d'abord si la mêlée conditionnelle vous aidera dans votre cas ou non ( un autre exemple de table de test ).



Prenons un exemple: une entreprise est brûlée parce que le développement est lent, une décision est prise - implémentons scrum / kanban / lean, car cela accélère le développement ( donc cela ne veut pas dire ). Et au fil du temps, nous concluons: "c'est du charlatanisme et des astuces marketing, ça ne marche pas." Une histoire familière? Mon avis est de commencer par la transparence. Comprenons ce qui dérange exactement. Commençons à parler dans les mêmes termes et comprenons les termes de la même manière. Formulons les questions: "Quel est le problème?", "Comment comprenons-nous qu'il est mauvais?", "Comment comprendre ce qui est mieux?", "Comment déterminer ce qui est bon?", "Tout le monde a-t-il réalisé le problème et perçu elle comme un problème ( par exemple, pas les caprices de gestionnaires stupides )? " Et lorsque tout est devenu transparent, à ce moment-là, vous pouvez rechercher des solutions. En effet, un «développement lent» peut signifier:

• Il n'y a pas de processus de déploiement normal; le déploiement de modifications sur les produits est une douleur. Options de solution - implémentez la culture DevOps , exécutez CI / CD ;
• Les affaires et le développement n'ont pas appris à parler. Il semble aux entreprises que le développement ne comprend rien, et le développement, au contraire, pense que l'entreprise ne sait pas ce qu'elle veut. Solutions possibles - essayez de créer un objectif, de créer une cartographie d'impact ou d'utiliser OKR ;
• La structure hiérarchique est remplie de microgestion, dans laquelle il y a une lente adoption des décisions tactiques en raison du besoin de coordination avec les plus hautes. Options de solutions - former les gens à la facilitation, mener des expériences en toute confiance ( regarder une vidéo de motivation avec TED );
• La liste continue.

Il peut y avoir de nombreuses situations, pour chacune d'elles, il y a ses propres outils d'amélioration. Et souvent l'implémentation de agile / scrum / kanban / lean / etc. cela ressemble à marteler des ongles avec un microscope et, en fait, à créer l'apparence d'une activité violente, mais ne cherche pas une solution au problème. Par conséquent, la règle «ne vous faites pas une idole» fonctionne ici: vous ne devriez pas chercher une solution miracle dans les approches / méthodologies / cadres hype, tout d'abord, réalisez quel problème vous résolvez et choisissez un outil de solution après cela. Et il s'avère que, après s'être engagé sur la voie de l'amélioration continue ( prise de conscience du problème, formalisation du travail avec celui-ci, transparence, recherche de solutions par le biais d'expériences ), vous construirez votre processus comme nulle part ailleurs, mais cela fonctionne très bien pour vous.

Pourquoi suis-je tout ça

Selon le modèle de Kenevin, presque tout notre travail informatique est dans un domaine confus, ce qui signifie que l'opinion d'experts ne fonctionne pas ici et qu'il n'y a pas de bonnes réponses. Et l'une des options possibles pour une existence confortable en elle est un processus empirique qui commence par la transparence. Il semblerait que ce soient des vérités communes, mais il semble qu'elles ne soient pas toujours mémorisées.

Si vous lisez cet endroit et que vous êtes bombardé par un autre article d'un capitaine populiste, alors vous pouvez essayer de vous poser des questions:

• Pourquoi est-il brûlé?
• Pourquoi cela m'a-t-il exaspéré?
• Qu'est-ce qui pourrait être différent, pour ne pas me provoquer de telles émotions?

Écrivez tout cela dans les commentaires: mettez tous les points sur i et rendez cette question transparente.
En résumé: l'opacité peut conduire à la désintégration de la société en groupes, guerres saintes, manifestes , etc. Mais vous pouvez vous asseoir et essayer d'abord de parler la même langue et de vous entendre. Toute transparence!

Merci pour l'illustration, Sai Kin !