Parlons de l'application pratique d'un sujet très intéressant - la pensée systémique.
Il existe de nombreux principes et méthodes dans la pensée systémique, je recommande fortement de lire la littérature pertinente. Par exemple, un
livre simple et intéressant. Aujourd'hui, nous n'aborderons qu'un seul principe: les propriétés émergentes ou émergentes des systèmes.
Je vais vous parler de la théorie et, surtout, des aspects pratiques de l'application. Dans notre vie - programmeurs, réalisateurs, architectes, analystes et chefs de projet.
Au début, cependant, un peu de théorie.
Systèmes et propriétés
Au travail, nous traitons presque toujours des systèmes - collections complexes de personnes, processus, relations (formelles et informelles), leaders explicites et cachés, objets matériels, systèmes d'information, clients, fournisseurs, équipements, etc., à l'infini.
Si vous avez tous les éléments devant vous, vous les connaissez, ou même les voyez - par exemple, mettez tout cela en un seul endroit - alors ce n'est pas un système, mais un ensemble d'éléments. Juste un tas de détails.
Comment faire un système avec ce tas? Vous devez mettre les éléments à leur place et les allumer - démarrez le système.
Ceci est bien compris par les programmeurs ou les ingénieurs ordinaires. Voici le code du programme, voici un ordinateur ou un serveur, voici les données d'entrée pour le traitement. Appuyez sur ON - le système fonctionne. Eh bien, ou n'a pas fonctionné s'il y a une erreur.
Dans les systèmes composés de personnes, le contraire est généralement vrai, et cette différence est essentielle. Des systèmes de personnes ont travaillé avant vous et fonctionneront après vous. Mais ils ne travailleront pas
avec vous , en votre présence. En fait, en votre présence, ils cessent d'être des systèmes et redeviennent un ensemble d'éléments.
Revenons à l'exemple ci-dessus, lorsque vous avez collecté tout et tous les éléments du système en un seul endroit. Qu'avez-vous fait? Vous avez
éteint le système.
Quelle est la différence entre l'activation et la désactivation du système? Les gens aiment les mêmes, les mêmes positions, les mêmes processus, le même leader - tout est en place.
La différence dans les propriétés du système, qui ne se manifestent que lorsqu'il est "allumé", c'est-à-dire lorsque le système fonctionne.
Des exemples de telles propriétés système sont partout, vous pouvez les trouver sans difficulté.
Un téléviseur sans électricité est un système éteint qui ne nous montre pas sa fonction principale - afficher une image. Allumez le téléviseur - vous verrez l'image, la fonction apparaîtra. Si vous éclaboussez de l'eau sur un téléviseur en état de marche, vous verrez une nouvelle propriété du système que vous ignoriez peut-être.
Ces propriétés du système sont appelées
émergentes ou
émergentes .
Ils surviennent lorsqu'un système est assemblé et activé à partir d'un ensemble d'éléments. Les deux conditions sont importantes - il est à la fois assemblé et allumé. Dans notre cas, quand il ne s'éteint pas.
Donc, notre tâche est de comprendre le système afin de le changer par la suite. Comment comprendre le système?
Ne pas éteindre
Il est très simple de la regarder sans s'éteindre.
Tout comme nous déboguons le code - allumez-le et voyez ce qui se passe. En principe, vous pouvez déboguer le code avec vos yeux, mais avec une impression - rappelez-vous, à l'institut, «lister un programme»? Mais il semble que peu de gens le fassent. Les systèmes que nous créons sont trop complexes. Beaucoup de dépendances, auxquelles nous ne sommes pas soumis, mais les bricoler pendant le débogage est une tâche ingrate.
Avec les systèmes conventionnels non informatiques, c'est encore plus compliqué. Il n'y a pas de "liste". Imaginez à quel point il serait élevé de travailler avec des systèmes «humains», si la case «Pause sur les exceptions interceptées» était là?
Comment éteignons-nous généralement le système:
- Nous parlons avec les employés individuellement
- Nous parlons avec tous les employés en même temps
- Nous emmenons tout le monde à un événement informel
- Nous faisons une demande aux employés, fixons une tâche, demandons un rapport
- Veuillez décrire leurs activités ou rédiger un processus opérationnel
- Rassembler les dirigeants lors d'une réunion
- Nous demandons aux anciens employés comment fonctionne le système
- Etc.
Il s'avère que toutes nos actions habituelles conduisent à l'arrêt de systèmes et tentent de comprendre les propriétés émergentes d'un ensemble d'éléments.
Sherlock Holmes a fait un excellent travail avec ce travail, il l'a appelé déduction - pour comprendre l'image en détail. Certes, il n'avait pas d'autre choix - vous ne demanderez pas au criminel de recommencer le crime en présence du génie de la recherche.
Notre situation est plus simple et nous avons la possibilité d'observer des systèmes inchangés qui fonctionnent.
Bien entendu, la meilleure méthode consiste à être constamment présent dans le système, à en faire partie et en même temps à l'observer à distance. C'est, par exemple, le chemin d'un scrum master. Et, par définition, le rôle du supérieur immédiat. À moins, bien sûr, qu'il ne passe pas par des réunions au lieu de travailler.
Un exemple similaire est un entraîneur, par exemple, dans une équipe de football. Là, surveiller le système en action, dans toute sa puissance, fait partie du travail.
Que faisons-nous, employés de bureau, divisés par des cloisons, des armoires, parfois des continents?
Effectuer une surveillance secrète, en personne ou en utilisant des moyens techniques.
Observation
L'observation personnelle n'est pas toujours possible, tout dépend de votre position par rapport au système observé.
Si vous travaillez au sein d'une organisation, vous pouvez simplement placer votre lieu de travail là où se trouve le système - des personnes dont vous souhaitez comprendre l'interaction.
Au début, vous serez un élément étranger qui éteindra le système. Mais progressivement, ils s'habitueront à vous et cesseront de faire attention à vous.
Pour vous habituer plus rapidement, faites comme si vous n'étiez pas particulièrement intéressé par ce qui se passe autour de vous. Vous pouvez prétendre que vous travaillez avec enthousiasme sur l'ordinateur, mettez vos écouteurs et allumez la musique - mais tranquillement pour entendre ce qui se passe autour. Ne prétendez pas écouter les conversations. Plus précisément, faites semblant de ne pas écouter les conversations. Je pense que vous découvrirez vous-même comment adhérer.
S'il y a des personnes dans votre équipe qui trouveront plus facile de rejoindre le système, vous pouvez les envoyer avec une installation claire.
Vous pouvez utiliser une variété d'
outils pour suivre les actions des personnes dans les systèmes . Vous ne verrez pas tout le système de cette façon, mais au moins vous saurez si les gens utilisent vos outils ou non. En mots, ils disent une chose, mais en réalité - une autre.
La pratique montre qu'en général 2 à 5 jours suffisent pour se faire une idée du système. Ce ne sera pas une image extrêmement précise, mais un croquis qui donnera une vision générale et intégrale du système.
L'esquisse peut ensuite être complétée par des détails, déjà sans observation. Par exemple, compléter avec des données de test d'hypothèse, des données de systèmes de contrôle, etc.
Fait intéressant, l'observation aide à développer des capacités de prédiction. La prévision permet de comprendre rapidement, sur la base de l'expérience et des connaissances sur le comportement des systèmes, quelles méthodes et changements fonctionneront et apporteront des résultats, et lesquels ne fonctionneront pas. Ceci est une autre application de la pensée systémique et des propriétés émergentes des systèmes; nous en parlerons ci-dessous.
Par conséquent, la surveillance d'un système qui n'est pas désactivé est une excellente méthode difficile à remplacer par quelque chose. L'observation aide à voir le système aussi précisément, impartialement et objectivement que possible, sans interprétation.
Toute autre option est l'
interprétation ou la projection dans un système de coordonnées spécifique. Surtout si vous posez des questions sur le système à son leader (comme cela arrive souvent). Cela s'applique non seulement au travail du programmeur, mais aussi à la routine quotidienne de gestion.
En fait, il n'y a rien de nouveau dans cette approche, elle est souvent utilisée dans certains domaines.
Par exemple, dans le commerce de détail et le secteur des services, des clients mystères sont utilisés - des personnes qui sont délibérément envoyées dans un magasin, un hôtel, etc., afin de voir le système en action tel qu'il est.
Une nouveauté dans cette approche est son utilisation dans le travail d'une entreprise ordinaire, en règle générale non liée à la vente au détail, par exemple. Nous reprenons l'ancienne méthode connue, trouvons une nouvelle application.
Prévision
Maintenant sur les prévisions. Dans le travail d'un programmeur, une situation est souvent rencontrée lorsque vous devez donner une prévision de la réussite d'un projet. Habituellement, nous parlons de projets de développement organisationnel interne de l'entreprise. Autrement dit, sur les projets de modifications.
Ils posent généralement des questions sur les projets d'autres personnes - ceux dans lesquels un programmeur d'entreprise n'est pas impliqué. C'est-à-dire sur les projets réalisés non pas selon les règles de la programmation d'entreprise, mais selon la règle «comme je peux».
Un programmeur d'entreprise, après une brève étude des informations sur un projet prévu, dit généralement que rien d'utile n'en sortira. Ou - rien ne fonctionnera du tout. La différence est claire - le projet peut être mené à bien, dans les délais et le budget, mais n'apportera aucun avantage à l'entreprise.
Opinion exprimée, c'est-à-dire les prévisions d'un programmeur d'entreprise provoquent généralement des réactions négatives - dépression, colère, rejet, «qui êtes-vous?», «agir Dieu sur Terre, ou quoi? " etc.
Une réaction négative s'intensifie lorsque la prévision se réalise, et elle se réalise très souvent.
Cependant, tout n'est pas si triste, et progressivement les gens commencent à s'habituer à une telle «superpuissance» d'un programmeur d'entreprise, et même à l'utiliser de manière adéquate au profit de l'entreprise ou de leur entreprise personnelle. Certains tiennent même des registres des prévisions - un cahier dans lequel ils cochent «il avait raison». Par exemple, deux de mes collègues managers avaient un tel carnet. Je ne sais pas, vraiment, virtuel ou réel.
Voyons maintenant comment un programmeur d'entreprise fait de telles prévisions.
D'où viennent les prévisions?
Il s'agit d'utiliser la connaissance du comportement du système.
Le projet de changements contient toujours au moins deux systèmes: variables et changeants.
Variable -
ce que nous allons améliorer . Processus métier, travail unitaire, interaction des fonctions, etc. Nous l'appellerons l'
objet du changement .
Changement -
celui qui invente, implémente et implémente les changements . Autrement dit, l'équipe de mise en œuvre du changement. Nous l'appellerons le
sujet du changement .
Les deux systèmes sont constitués d'un ensemble d'éléments et de relations entre eux. Il s'agit des personnes, des systèmes d'information, des objectifs, des relations formelles et informelles, du modèle de gestion, des approches de leadership, des forces influentes, etc.
Dans le sujet, c'est-à-dire le projet et l'équipe de changements, il y a des éléments spécifiques - l'algorithme de choix des méthodes à mettre en œuvre, le but et la motivation du chef de projet et de l'équipe, la méthodologie de mise en œuvre, les principes de gestion de projet, les approches de gestion pour évaluer l'avancement et les résultats du projet, les plans d'équipe pour la vie après le projet, le choix du problème à résoudre, etc. .d.
Personne ne peut voir de manière fiable tous les éléments et connexions, même le programmeur d'entreprise le plus aguerri. Mais certains, une certaine partie est vue par tout le monde - le chef de projet de la mise en œuvre, le chef de l'entreprise et tous les collègues environnants.
Cependant, c'est le programmeur d'entreprise qui donne les prévisions les plus précises. Tout le monde regarde la même chose. Voir l'objet, voir le sujet, le plan de projet, les ressources, l'environnement. Mais les prévisions sont fondamentalement différentes. Pourquoi?
La réponse est très simple, voire ennuyeuse: un programmeur d'entreprise prend en compte
des informations historiques . Informations historiques et statistiques sur le comportement de systèmes similaires.
Le résultat du projet de mise en œuvre du changement consiste en une
combinaison de deux systèmes - un objet et un sujet. Si les systèmes ne s'adaptent pas correctement, le résultat sera négatif.
Si un nouveau projet de changements est en cours de conception, mais que les systèmes de l'objet et du sujet n'ont pas beaucoup changé, le résultat sera très probablement similaire. Les mêmes personnes tentent d'implémenter la même méthode dans la même unité.
Il y a beaucoup d'exemples. Si vous regardez avec un regard systématique sur l'histoire de l'introduction des changements dans votre entreprise, vous verrez la confirmation de ce modèle.
Vous pouvez chercher des exemples dans la rue, maintenant juste le bon système - «hiver» est appelé. Hiver + ville + ceux-ci, comme eux, dont la neige doit être enlevée. Les années passent et le résultat est similaire. Parce que tous les systèmes sont en place, inchangés. Oh oui, parfois l'hiver est sans neige - alors le résultat est très bon. À qui appartient-il?
La partie la plus difficile de cette approche consiste à déterminer s'il
existe ou non des
différences dans les systèmes. Pour ce faire, vous devez apprendre à classer les éléments et les relations du système par ordre d'importance - pour mettre en évidence ses éléments et relations clés qui forment le système.
Il n'y a pas de recette unique, il existe de nombreuses options. Il y a, par exemple, la méthode 7S, créée chez McKinsey, qui analyse le système en 7 parties. Personnellement, je préfère ne pas me limiter, sinon vous pouvez voir quelque chose de nouveau par vous-même.
La compréhension des éléments clés peut se faire de manière intuitive, mais vous devez vous revérifier, car la qualité de l'intuition dépend du niveau actuel de votre développement en tant que programmeur d'entreprise et peut vous tromper.
La mise en évidence des éléments clés vous permettra de faire une prévision plus rapidement, sans plonger dans les détails et sans étudier le bruit. Vous voyez simplement que les éléments clés des deux systèmes restent en place et vous pouvez être sûr que le résultat sera répété avec une forte probabilité.
Plus vous faites cet exercice souvent, plus vos compétences se développeront rapidement et plus vos prévisions deviendront précises.
Il y a une telle expression populaire dans notre pays - «ils voulaient le meilleur, mais il s'est avéré comme toujours». Maintenant, après avoir lu, vous comprenez que quelque chose manque ici. Ce serait plus correct "ils voulaient le meilleur, agissaient comme toujours, eh bien, c'est le résultat ...".
J'ai vu un exemple d'une telle approche avec notre ministre des Affaires étrangères, Sergey Lavrov. Lors d'une conférence de presse après une réunion avec le secrétaire d'État américain Rex Tillerson, Lavrov a déclaré: «En ce qui concerne les problèmes spécifiques de la Syrie, en particulier B. Assad, nous avons discuté aujourd'hui d'excursions historiques, et R. Tillerson a déclaré qu'il était une nouvelle personne et préférait ne pas plonger dans l'histoire. et faire face aux problèmes d'aujourd'hui. Cependant, le monde est conçu de telle sorte que si nous n’apprenons pas du passé, nous ne pouvons guère réussir dans le présent. »
Lavrov a ensuite énuméré plusieurs exemples - combinaisons de systèmes de l'objet et du sujet, avec le même objectif du sujet - l'introduction d'un modèle de démocratie par le renversement du dictateur. OTAN et Irak, OTAN et Libye. Et prédit le résultat d'une combinaison de l'OTAN et de la Syrie.
Jusqu'à présent, semble-t-il, Lavrov a raison.