Deux mondes ou «ingénieurs ont quelque chose à dire». Sur les différents types de tâches complexes et les processus qui leur sont associés

Je pense que les chefs des services informatiques seront d'accord avec moi que parfois il semble que nous sommes à la frontière de deux mondes vivant selon des lois différentes, dans des rythmes temporels différents, et que nous devons vivre dans ces deux mondes. Et, si nous diffusons le «style de vie» de haut en bas, des cadres supérieurs aux ingénieurs, nous, sur la base de nos responsabilités professionnelles, régulièrement, mais en sens inverse - hélas ...

Par conséquent, ce poste traite de ce que moi, en tant qu'ingénieur, je veux dire à nos chers managers et à ceux qui considèrent que leur «style de vie» est le seul vrai. :)

Planification, diagrammes de Gantt, "suivre un processus", discipline, échéance, routine, "Je n'explique pas deux fois la même chose", "Je n'ai pas eu le temps, alors j'ai mal planifié" ... - connaissez-vous les choses? Ce sont l'essence et les méthodes du «monde managérial». Il est clair que quelque part plus, quelque part moins et généralement la simplification, mais il ne s'agit pas de ce monde. Il est certainement important. Ses méthodes fonctionnent très bien à bien des égards. Mais il y a une énorme couche de tâches où rien de tout cela ne fonctionne, mais une toute autre, parfois l'inverse, fonctionne.

Je vais expliquer ma pensée.

Toutes les tâches complexes peuvent être divisées en deux classes. Je les appellerai les mots anglais complexes et difficiles. D'après les noms, il est plus ou moins clair de quoi je parle, mais je vais le formuler.

Une tâche complexe est une tâche composée de nombreuses sous-tâches élémentaires. Élémentaire dans le sens où le résultat est connu, les méthodes de résolution sont connues, la quantité de ressources dont elles ont besoin et le temps nécessaire pour les réaliser. La complexité de la tâche complexe réside dans le fait que, par exemple, la participation de diverses personnes, spécialistes, équipes et leurs actions doit être coordonnée, mais chaque action spécifique est tout à fait compréhensible et prévisible. Un bon exemple est la construction d'une maison. Et ici, les techniques du «monde managérial» fonctionnent parfaitement.

Mais lorsque nous parlons d'une tâche difficile, il s'agit d'un problème avec un résultat incertain, et cette incertitude peut être au point qu'il n'est pas clair s'il existe une solution et, dans l'affirmative, ce qu'elle est, combien de temps et de ressources cette tâche prendra. Ceci est une étude. Dans ce cas, il ne s'agit pas de créer un réacteur à fusion, mais de vivre quotidiennement dans le «monde de l'ingénieur».

Nouveau logiciel, nouvelle «fonctionnalité», nouveau bug, mise en place de nouveaux équipements, construction d'une nouvelle architecture, test de nouvelles solutions, création d'un nouveau produit ... Il n'est pas nécessaire que personne ne le sache. Il suffit que cela ne soit pas connu de l'équipe et qu'il n'est pas si facile de trouver de la documentation.

Bien sûr, le "monde d'un ingénieur" ne se compose pas seulement de cela, il y a des composants complexes ici, mais c'est une partie essentielle de celui-ci, ou vous n'êtes pas tout à fait un ingénieur.

Et des processus complètement différents fonctionnent dans ce monde. Et c'est important à comprendre. Voici quelques exemples de méthodes efficaces pour résoudre des problèmes difficiles.

  • l'ingénieur doit plonger dans la tâche. Il ne peut pas être distrait toutes les 15 minutes. Parfois, une plongée peut être si consommatrice qu'elle ne peut pas dormir ou mal dormir, «souffrir» de la tâche pendant plusieurs jours, semaines ou mois. C'est une qualité importante d'un ingénieur solide. Il ne peut pas se calmer avant d'avoir décidé. Il faut lui donner du temps, la possibilité de se concentrer et, éventuellement, d'être exclu pendant un certain temps de divers processus périodiques.
  • dans ces conditions, il est étrange de demander à un ingénieur de vivre strictement selon un horaire. Et cela se comprend dans l'institut de recherche (en tout cas, dans le lieu où je travaillais), c'est compris, par exemple, au PhysTech - et là et là en accès libre.
  • il est clair que le mot «discipline» dans la résolution de problèmes de ce type a déjà un sens différent. Ce n'est même pas de la discipline, mais plutôt de la passion. Le processus créatif, le brainstorming, la discussion, l'intérêt pour le résultat - c'est la colle qui remplace la discipline dans la résolution de ce type de problème.
  • il est clair que toutes les dépendances temporelles s'affaiblissent également de manière significative ici, il est difficile d'insérer une tâche difficile dans un processus temporel strictement réglementé
  • il n'est pas encouragé la fluidité (en conformité avec toutes les conventions et procédures) de la tâche, mais simplement le fait de résoudre le problème. Les mots tels que «vous êtes resté 2 jours» ne devraient pas s'appliquer ici. Si le timing est important, il vous suffit de décider à quel moment vous arrêter et de ne pas dépenser plus de ressources.
  • on ne peut pas juger une personne pour ne pas pouvoir résoudre un problème. Même avec un spécialiste très fort, le courant de pensée peut aller dans l'autre sens et il peut passer beaucoup de temps supplémentaire. À bien des égards, la solution à de tels problèmes est une énumération des options, et non le fait que vous choisirez rapidement la bonne.
  • si l'ingénieur est coincé, vous ne pouvez pas le laisser seul - vous avez besoin de l'aide du chef ou de toute l'équipe.

Un monde complètement différent, non?

Est-ce à dire que vous ne pouvez pas planifier du tout? Non, non. Habituellement, vous pouvez évaluer la probabilité d'achèvement et le temps, mais ce n'est qu'une probabilité et seulement une estimation.

Est-ce à dire que l'anarchie doit régner dans le département? Non, non. Dans le département, bien sûr, les processus de tâches complexes qui sont dans le département et auxquels l'unité participe doivent être observés. Et c'est la tâche du leader de pouvoir combiner ces deux mondes.

Afin de résoudre habilement des problèmes difficiles, vous avez besoin de compétences sérieuses. Habituellement, c'est une capacité innée et un amour pour de telles tâches, plus une formation à long terme (généralement depuis l'enfance) (résolution de problèmes - mathématiques, programmation, «cueillette» sur un ordinateur ...). Et je crois que seul un ingénieur ayant les compétences nécessaires pour résoudre des tâches difficiles peut être un ingénieur solide. Et lors de l'entretien dans notre département, nous recherchions exactement cela.

La capacité de résoudre des problèmes complexes est plus abordable. L'inclinaison des personnages est également importante ici, mais s'il y a cette inclinaison, la maîtrise des compétences n'est pas si difficile.

Vous pouvez être un gestionnaire complètement réussi sur votre propre étape dans la hiérarchie et ne pas avoir les compétences nécessaires pour résoudre des tâches difficiles. Il existe de nombreux postes de ce type. Mais il me semble qu'il sera difficile de devenir un véritable leader dans le monde informatique.

Voilà pourquoi.

  • un tel gestionnaire ne comprend souvent pas et ne valorise donc pas les personnes capables de résoudre des problèmes difficiles. Il n'aura donc pas d'ingénieurs solides.
  • Dans le cas général, le manager doit certainement résoudre des problèmes difficiles. Par exemple, déterminez des objectifs ou créez des processus de travail. C'est une tâche difficile. Le problème est que le gestionnaire peut penser que c'est simple, car il ne voit pas la profondeur du problème et crée des objectifs et des processus à la volée, mais lorsqu'ils sont examinés en détail, ils ne fonctionnent pas.

Un gestionnaire solide est une combinaison rare de ces deux mondes. Habituellement, les gens ont tendance à choisir l'un ou l'autre.

Si le monde des tâches difficiles est fermé pour vous, alors je vous conseillerais d'apprendre à aimer et à apprécier une équipe d'un autre monde et ce monde vous en remerciera.

Source: https://habr.com/ru/post/fr432566/


All Articles