Chez PagerDuty, nous nous efforçons de progresser et d'apprendre, individuellement et en équipe. Cela se traduit par des post-mortems, des revues de code, des rétrospectives, des discussions sur Slack/JIRA et des enquêtes de suivi, pour n'en citer que quelques-unes. Il est également possible de rejoindre des groupes d'intérêt, d'assister à des revues de sprint, des conférences techniques et de lire/écrire. articles de blog sur la technologie .

En tant qu'ingénieurs, nous sommes également tentés de refactoriser le code inefficace, de gérer la dette technique et d'améliorer les workflows. Avec tant de choses sur lesquelles nous pourrions travailler (et je n'ai même pas mentionné notre travail sur les produits ou l'infrastructure au sein de nos équipes Scrum), il est important d'examiner de plus près notre gestion du temps. Par exemple, quels projets devraient être prioritaires et pourquoi ? Sur quoi devrions-nous travailler pour progresser plus efficacement vers nos objectifs ?

Pour répondre à ces questions, il faut évaluer l'effet de levier d'un corpus d'œuvres donné. Effet de levier, écrit-il. Edmond Lau dans L'ingénieur efficace , est défini par une équation simple : c'est la valeur, ou l'impact, produit par temps investi.

En d'autres termes, travailler dur n'est pas synonyme de travailler efficacement. C'est la différence entre être occupé et être productif. Autrement dit, c'est le retour sur investissement de l'ingénierie. Le nombre de tâches sur lesquelles nous pourrions travailler peut être illimité, mais notre temps et nos ressources sont limités. Être efficace signifie se concentrer sur les tâches qui apportent le plus de valeur tout en demandant le moins d'efforts. La règle des 80-20, aussi appelée Principe de Pareto s'applique ici : 80 pour cent des résultats devraient provenir de 20 pour cent d'efforts.

Comment pouvons-nous augmenter notre effet de levier ?

L'ancien PDG d'Intel, Andrew Grove, explique dans son livre Gestion à haut rendement que votre effet de levier global (la quantité de valeur que vous produisez par unité de temps) ne peut être augmenté que de trois manières :

1. En réduisant le temps nécessaire pour réaliser une certaine activité.
2. En augmentant le rendement d’une activité particulière.
3. En passant à une activité à plus fort effet de levier.

Au cours de la journée, nous sommes occupés par une multitude d'activités : réunions, consultation de nos e-mails, lecture/écriture sur Confluence, commentaires/blogs, commentaires sur GitHub/Confluence, participation aux discussions Slack et sprints. Mais quelle que soit votre activité, posez-vous les questions suivantes pour améliorer votre influence :

1. Comment puis-je réaliser cette activité en moins de temps ?
2. Comment puis-je augmenter la valeur produite par cette activité ?
3. Y a-t-il autre chose sur laquelle je pourrais consacrer mon temps et qui produirait plus de valeur ?

Je vais fournir quelques exemples ci-dessous.

Réunions

Afin de rendre une réunion plus efficace, posez les questions suivantes :

1. Cette réunion doit-elle durer une heure ? Peut-elle se dérouler en 30 minutes ? Ou mieux encore, en 15 minutes ?
2. Les objectifs de la réunion sont-ils clairs pour tous ? Les participants doivent-ils venir préparés ? Doivent-ils lire quelque chose au préalable ?
3. Cette réunion est-elle vraiment nécessaire ? Le problème peut-il être résolu via Slack ou par e-mail ?

Vérification des e-mails et de Slack

Les préférences en matière d'e-mails et de Slack varient d'une personne à l'autre, et il est indéniable que consulter et répondre à ses e-mails est précieux (tout comme lire, se tenir informé et collaborer sur Slack). Mais à partir de quand tout cela perd-il de son efficacité ? Autrement dit, à partir de quand devient-il préjudiciable à notre productivité ?

Avec des interruptions constantes tout au long de la journée, il peut être difficile d'atteindre l'état d'esprit où vous produisez du code aussi rapidement. le commissaire-priseur peut parler Par exemple, lorsque je suis constamment en train de discuter dans des outils de communication (e-mail, Slack, JIRA, etc.), je travaille dans un état d'incertitude où je passe constamment d'une application à l'autre en utilisant la combinaison de touches Commande + Tabulation, jongle entre une multitude d'onglets Chrome et code. Aujourd'hui, j'ai mis en place un système qui me permet de consacrer au moins deux à trois heures par jour à coder sans interruption, concentré, concentré et assidu – ce que j'appelle du « travail approfondi ».

Cal Newport, auteur de Travail en profondeur , définit ceci comme :

« Activités professionnelles réalisées dans un état de concentration sans distraction, qui poussent vos capacités cognitives à leurs limites. Ces efforts créent une nouvelle valeur, améliorent vos compétences et sont difficiles à reproduire. »

J'ai également entendu ce concept appelé couler , une expression inventée par le psychologue Mihaly Csikszentmihalyi. Les personnes ayant expérimenté le flow le décrivent comme « un état de concentration sans effort, si profond qu'elles ont perdu la notion du temps, d'elles-mêmes et de leurs problèmes ».

Lorsque je travaille en profondeur, j'utilise généralement la fonction Snooze de Slack, qui supprime les notifications pendant une durée déterminée. Je consulte ensuite Slack régulièrement lorsque je suis à un point d'arrêt pour m'assurer que tout est en ordre.

Je pense que les ingénieurs sont plus performants lorsqu'ils effectuent un travail approfondi, et j'encourage les autres à essayer de le faire au moins une ou deux heures par jour pour voir s'ils sont plus productifs. Il ne faut pas confondre cela avec du temps de codage régulier/déconcentré. Idéalement, nous devrions essayer de coder tout au long de la journée, mais il y a une différence entre un codage distrait/déconcentré et un codage ininterrompu : quand je parle de travail approfondi, je fais référence à un codage ininterrompu.

Le ticket JIRA actuel sur lequel vous travaillez

En supposant que le ticket Jira ait déjà été priorisé par le Product Owner et qu'il ait suivi le processus de story time et de planification de sprint, il est toujours judicieux de le réexaminer et de voir si vous pouvez en optimiser l'efficacité. Analysons-le en profondeur à l'aide de nos trois questions :

1. Comment puis-je réaliser cette activité en moins de temps ?

Pouvons-nous utiliser des bibliothèques existantes ? Je sais qu'il peut être tentant pour les ingénieurs d'écrire quelque chose de zéro.

2. Comment puis-je augmenter la valeur produite par cette activité ?

Existe-t-il un moyen d'automatiser certaines parties de nos tâches actuelles afin de faciliter la tâche des futurs développeurs ? Pouvons-nous abstraire une tâche courante dans une fonction ou une classe ? Il est parfois judicieux d'investir un peu de temps en amont pour pouvoir itérer plus rapidement par la suite.

3. Y a-t-il autre chose sur laquelle je pourrais consacrer mon temps et qui produirait plus de valeur ?

Y a-t-il des tâches plus importantes à accomplir et plus pertinentes pour l'objectif ou la version actuelle ? Réfléchissez-y. MVP (produit minimum viable) dans cette situation : avons-nous vraiment besoin de ces optimisations sophistiquées dès le début, alors que nous essayons simplement de recueillir des retours précoces ? Quelle est la plus petite part livrable que nous pouvons publier ? Quel est le ratio 80-20 pour une version ? De quoi pouvons-nous nous passer ? Comment réduire la portée sans diminuer la valeur ?

Je sais qu'il est facile de se laisser emporter par le travail. Cependant, j'ai appris qu'en posant les bonnes questions, on peut travailler efficacement et être beaucoup plus productif.

Restez à l’écoute pour la partie 2, où je vous expliquerai plus en détail comment établir des priorités !