Récemment, par pur hasard, grâce à une bonne personne, est née l'idée d'ajouter un résumé à chaque article. Pas une annotation, pas un appât, mais précisément un résumé. Un résumé qui permettrait de ne pas lire l'article du tout.
J'ai essayé, et j'ai adoré. Mais peu importe — l'essentiel est que cela a plu aux lecteurs. Ceux qui avaient arrêté de lire sont revenus, me qualifiant de graphomane. Et une autre bonne personne m'a conseillé d'écrire un résumé pour chaque ancien article. J'ai accepté, et maintenant, entre deux, j'écris ces petites résumés. Je les ai appelés des shorts.
Je vous propose quelques-uns de ces shorts, sur plusieurs publications. Peut-être trouverez-vous quelque chose d'utile pour vous.
Le chat est mort, la queue est pelée.
Les réunions se terminent très souvent sans résultat. On se réunit, on discute, puis on se sépare.
Les résultats, ou les produits de la réunion, ce sont des décisions. Or, celles-ci sont généralement absentes. Et quand elles existent, elles ne sont pas toujours de bonne qualité.
Si la réunion est limitée dans le temps, et qu'il faut absolument prendre une décision, alors cette décision est souvent de mauvaise qualité.
Si la réunion n'est pas limitée dans le temps et dure jusqu'à ce qu'une décision soit prise, alors n'importe quelle décision sera prise, juste pour que la réunion se termine.
Si la décision a été trouvée lors de la réunion, alors elle sera prise — tout simplement parce que le cerveau apprécie ce qu'il a inventé.
La compréhension de la mauvaise qualité de la décision viendra plus tard, mais il sera déjà trop tard.
Pour prendre une décision efficace, il vaut mieux ne pas participer à la discussion, mais observer en silence.
Tout d'abord, le cerveau ne sera pas occupé à trouver des réponses.
Deuxièmement, il n'y a pas de pression pour prendre une décision.
Après la réunion, on peut réfléchir calmement et prendre une décision. Elle sera de meilleure qualité.
L'essentiel : rester silencieux et écouter pendant la réunion. Pour rassurer les autres, dire que c'est une position consciente.
→
Parasites latents.
Il existe fondamentalement deux approches pour formuler des tâches et contrôler leur exécution : parasitaire et symbiotique.
L'approche symbiotique — faire en sorte que la tâche soit accomplie.
L'approche parasitaire — faire en sorte que la tâche ne soit PAS accomplie.
L'approche symbiotique est directe et simple, mais difficile à mettre en œuvre. C'est pourquoi elle est rarement rencontrée.
La tâche doit être formulée de manière à ce que tout soit clair — à la fois les objectifs, les ressources et les limites.
Le contrôle est effectué de manière à ce que la tâche soit résolue avec précision.
L'approche symbiotique consiste à laisser une partie de la responsabilité (et même une plus grande) de la résolution de la tâche à l'énonceur.
L'approche parasitaire est compliquée et astucieuse, mais facile à mettre en œuvre. C'est pourquoi elle est souvent rencontrée.
La tâche est formulée de manière à ce qu'il n'y ait aucune clarté. Moins c'est clair, mieux c'est.
Il est préférable de ne pas exercer de contrôle du tout.
L'énonceur de la tâche n’a aucune responsabilité, toute la « responsabilité » incombe à l'exécutant.
L'objectif de l'approche parasitaire : manipulation, égo surdimensionné, affirmation de soi. C'est pourquoi elle est souvent rencontrée dans le travail des mentors avec des employés débutants.
Il est préférable d'utiliser l'approche symbiotique.
→
Mesures vs Illusions
Si vous évaluez le processus et les résultats de votre activité sans mesures, vous serez constamment dans l'erreur.
L'évaluation sans chiffres dépend de l'humeur. Une mauvaise humeur vous fera penser que vous travaillez mal. Une bonne humeur, au contraire.
On peut ainsi passer une semaine à mal travailler, puis livrer un « bon » résultat le vendredi, ce qui donnera l'impression que toute la semaine s'est bien déroulée.
Il existe fondamentalement deux types de métriques : quantitatives et alternatives (plus connues des programmeurs sous le nom de Booléennes).
« La tâche a été réalisée à temps » est une affirmation booléenne. C'est le même principe que « La pièce est conforme » (un critère de qualité alternatif lorsque des chiffres ne peuvent être mesurés).
« Nous travaillons bien », « Nous respectons le plan », « Je suis génial » — c'est aussi booléen.
Construire un processus de gestion sur des évaluations de type booléen est difficile. Il est recommandé de passer le plus rapidement possible aux métriques quantitatives.
Le booléen engendre de la bureaucratie et du formalisme. Par exemple, pour respecter les délais des tâches, on peut augmenter les délais, se créer des tâches, ou procéder à des activités inutiles.
Pour gérer sur la base d'indicateurs booléens, il faut consacrer beaucoup de temps — à des réunions, des analyses, etc. Car l'information est trop limitée.
Il est recommandé de mesurer à la fois le processus et le résultat. Cela donnera un aperçu plus complet.
Pour les programmeurs, il est recommandé d'utiliser la méthode « Planning Poker » du Scrum.
→
C'est Sparte.
Supposons que vous êtes programmeur et qu'on vous présente une tâche sérieuse. Mais vous pensez qu'il n'est pas nécessaire de résoudre cette tâche — elle est stupide et nuisible.
Comportement typique dans une telle situation : sortir la tâche en public. Envoyer pour approbation au supérieur, lancer un projet interne, l'enregistrer dans le système, etc.
C'est à ce moment que tout se gâche. La personne qui a apporté la tâche ne veut pas être considérée comme un imbécile. Et maintenant qu'elle est en public, elle va se défendre.
Il est important pour une personne de ne pas perdre la face, au sens politique du terme. L'essentiel en politique est de ne jamais reconnaître ses erreurs. On peut ne rien faire, mais le principal est de ne pas avoir d'erreurs reconnues.
La personne fera tout pour prouver que le programmeur est un méchant, un idiot, un opposant au changement. Et le programmeur devra de toute façon résoudre la tâche.
Dans certains cas, la personne va tout mettre en œuvre pour que le programmeur ne résolve pas la tâche du tout. Dans ce cas, la personne sera ‘blanche’, et le programmeur sera absolument ‘noir’ (il a résisté et finalement n'a pas réussi).
Il existe plusieurs solutions.
La première est de devenir un programmeur commercial, de comprendre les domaines connexes et de déterminer soi-même ce qu'il faut automatiser et comment.
La deuxième est de devenir responsable des changements. Par exemple, directeur du développement.
La troisième est de se contenter de faire ce qu'on dit.
La quatrième est la voie de Sparte, un rejet rapide des solutions. Plus connu sous le nom de fail fast, fail cheap (échoue vite, échoue à moindres frais).
L'essentiel est de ne pas rendre la situation publique. Dire à la personne : ne perdons pas trop de temps, faisons un prototype et voyons si la solution est viable ou non.
Un prototype prendra peu de temps. En cas de succès, les deux obtiendront ce qu'ils veulent : une solution correcte et des points politiques.
En cas d'échec, personne ne sera lésé. Et la personne aura une meilleure opinion du programmeur.
→
Surrégats
Les entreprises n'aiment pas 1C et ses produits, les développeurs web, les systèmes de gestion de la qualité, la comptabilité, les économistes, les projets de développement, Scrum, TOC, le contrôle de gestion, les KPI et les systèmes de motivation.
Les entreprises aiment améliorer leur rentabilité grâce à l'automatisation, à l'augmentation du chiffre d'affaires par le biais de la promotion en ligne, à l'amélioration de la qualité des produits, à une image claire et compréhensible de l'entreprise en chiffres, à des prévisions sur l'état de l'entreprise, à une réelle augmentation de l'efficacité, à l'accélération de l'exécution des projets de 2 à 4 fois, à un accroissement significatif des bénéfices et à la réduction des stocks, à un système de gestion précis, à un système d'évaluation clair et compréhensible de la situation de l'entreprise, à un système d'évaluation du travail permettant de licencier la moitié des managers.
Les entreprises aiment atteindre des objectifs commerciaux. Les entreprises n'aiment pas les substituts.
Un substitut, c'est quand on a demandé d'atteindre un objectif commercial, mais qu'on a obtenu un projet d'automatisation, un site web, une pile de documents, une équipe d'employés incompréhensibles ou des rapports illisibles.
Un substitut, c'est quand l'objectif a été remplacé par le moyen d'atteindre cet objectif. Et l'objectif a été oublié par tout le monde.
La production de substituts repose sur trois piliers : le formalisme, la gradualité et la solidarité circulaire.
Le formalisme consiste à transférer les objectifs sur papier avec une décomposition. En réalité, c'est déplacer l'attention de l'objectif principal vers des détails mineurs. Plus personne ne se souvient de l'objectif — tout le monde discute des détails.
La gradualité, c'est la faible vitesse de transition des objectifs aux moyens. Au début, l'objectif est encore parfois discuté. Mais progressivement, étape par étape, il est mentionné de moins en moins. Jusqu'à ce que le client finisse par l'oublier, noyé dans les détails.
La solidarité circulaire réside dans le fait que tous les prestataires agissent de manière à peu près similaire. Il n'y a pas un seul automate qui augmente réellement les bénéfices. Par conséquent, le client n'a guère d'issue.
Que faire ?
Évitez les substituts et le premier pas vers leur création : le formalisme. Ne serait-ce que pour les projets internes. Fixez un objectif et parlez-en constamment avec l'exécutant. Également sur l'échelle, les ressources, les plans, etc. — mais surtout sur l'objectif.
Sinon, l'attention se déplacera inévitablement, et vous obtiendrez un énième substitut.
→
Wladimir Klitschko
Il y a ce boxeur — Vladimir Klitschko. Il a une particularité — l'utilisation constante du jab. Enfin, plus constante que celle des autres boxeurs.
Le jab garde constamment l'adversaire sur le qui-vive, l'épuise.
Les caractéristiques clés du jab de Klitschko : simplicité d'exécution (relative, bien sûr) et constance.
De nombreux auteurs parlent du fait que des actions simples, mais utiles, effectuées régulièrement peuvent apporter beaucoup de bénéfices.
J'ai aussi décidé d'essayer. J'ai mis en place un système simple de suivi — quelles tâches j'ai accomplies aujourd'hui.
C'était à l'usine. Je faisais mes tâches à l'heure du déjeuner (je ne déjeune pas), c'est-à-dire 1 heure par jour. Je faisais ce que les autres ne font pas (on dit que cela mène au succès).
J'ai configuré des vérifications pour un système auto-apprenant, j'ai imaginé des idées de développement, j'ai réalisé des idées de développement d'autres personnes, j'ai configuré des tâches automatiques, j'ai refactorisé et optimisé le code.
Chaque jour — n'importe quelle tâche de cette liste. J'ai accompli une tâche — super. Je peux en faire plusieurs.
J'ai mené des observations pendant 3 mois. Pendant ce temps, j'ai effectué 30 vérifications, imaginé 200 idées, réalisé 80 idées d'autres personnes, construit des processus automatisés pour deux départements, effectué trois super optimisations.
C'est génial, non ? C'est juste « entre deux tâches ». Je le recommande à tout le monde.
→
Un substitut flexible
Le terme « Scrum » désigne au moins deux entités : une philosophie et un cadre.
La philosophie, ou approche du travail, est décrite dans le livre de Jeff Sutherland.
Le cadre, c'est-à-dire l'algorithme d'actions, est décrit dans un document intitulé Scrum Guide.
La philosophie s'est transformée en cadre, car les auteurs de la philosophie voulaient en tirer de l'argent (selon leurs propres mots).
Le cadre est fortement simplifié par rapport à la philosophie. L'essentiel — l'objectif a été simplifié, ou plutôt supprimé.
L'objectif de la philosophie : accélérer l'atteinte des résultats. En fait, plusieurs fois. Le livre contient des exemples d'accélération jusqu'à 8 fois.
L'objectif du cadre : que vous ayez Scrum. Il est ainsi écrit : suivez les instructions — vous avez Scrum, enfreignez les instructions — vous n'avez pas Scrum.
Le cadre ne suppose pas l'accélération des résultats, du tout.
Les gens qui enseignent ou mettent en œuvre Scrum travaillent avec le cadre. Ils expliquent et mettent en œuvre un algorithme qui ne conduit à aucun résultat, à part 'nous avons maintenant Scrum'.
L'essence est claire. Vendre la philosophie est très difficile. Le cadre — c'est plus simple.
Le cadre est un produit. Il a bien été 'emballé'. Il est simple, clair, bénéficie d'un support et de nombreux spécialistes. Cela ne vous rappelle rien ?
Tout va bien, sauf le résultat — il n'y en a pas.
Si le client n'est pas familier avec la philosophie Scrum, la mise en œuvre du cadre le satisfera parfaitement.
Si le client est familiarisé avec la philosophie Scrum, il risque d'être déçu par l'implémentation du cadre – il n'y aura aucune accélération dans l'atteinte des résultats.
Cela sera amusant, à la mode, moderne, mais aucun objectif commercial ne sera atteint (sauf pour dépenser le budget pour « quelque chose de nouveau »).
Que faire ? Étudier la philosophie Scrum. Elle se base sur la philosophie japonaise de gestion de la qualité, dont le principe est : mesures et améliorations continues.
Malheureusement, il faut beaucoup réfléchir, expérimenter, observer et, hélas, travailler. Si cela ne vous convient pas, prenez le cadre.
→
Source : habr.com
