Salut à tous! Au début, je voulais refléter dans le titre quelque chose sur l'efficacité personnelle, mais j'ai ensuite fortement rejeté l'idée. Je tiens à noter à l'avance qu'il ne s'agira pas tant d'accomplir et de fixer correctement l'objectif (bien que cela soit important), mais plutôt d'expérience personnelle et des événements qui m'ont conduit directement dans les bras de cette question (et cela s'est produit assez spontanément). Je soulignerai également les moyens de base pour simplifier le travail, ils sont aussi simples qu'efficaces.
Contexte
Pendant la majeure partie de ma carrière de développement (à la fois front-end et full-stack), j'ai réfléchi à une tâche importante: la performance du code. Cependant, mon efficacité personnelle est en quelque sorte sortie de la zone de mes intérêts ... Eh bien, pas du tout, mais je n'y suis pas restée longtemps, donc mes connaissances dans ce domaine jusqu'à présent ont été très, très limitées et abruptes.
En sautant de longues explications, j'irai directement à ... Le point culminant de mon histoire qui s'est déroulée cet été. Il se trouve que toutes les stars qui pouvaient le faire se sont réunies. Tout y était: je n'aimais pas activement mon projet, et j'étais aussi transféré vers un nouveau, ce que j'aimais (à l'époque) encore moins, «ajouté» de la joie et un délai serré, ajouté de l'huile sur le feu par des incidents réguliers avec l'environnement local, assez gros problèmes dans ma vie personnelle, l'annulation du vol, grâce à laquelle j'étais coincé dans une autre ville, si vous ajoutez une épidémie ici, vous obtenez une image assez complète et claire. Tout cela a conduit au fait que j'ai commencé à brûler: c'était difficile pour moi de travailler, c'était dur d'accomplir des tâches plus ou moins difficiles, tout le temps je voulais m'enfuir quelque part: du thé, YouTube, un livre, etc. À un moment donné, j'ai réalisé que je ne pouvais plus travailler (enfin, pas du tout).C'est compréhensible, car tout mon travail de ces derniers mois a été construit sur l'auto-contrainte: je me suis forcé à travailler. Résultat assez logique.
Les moyens évidents de sortir de cette situation sont d'essayer de changer de projet ou de partir en vacances. Mais, premièrement, cela ne se produit pas instantanément et, deuxièmement, je ne savais pas combien j'allais durer après des vacances ou sur un nouveau projet. Puis il s'est posé la question: qu'est-ce que je veux en fait? Il s'est avéré être tout sauf programmable (incroyable). Par exemple, boire du thé (je me demande comment les autres répondent à cette question, se trouvant dans une situation similaire, mais peut-être que nous ne le saurons jamais). Et je me suis dit: "D'accord, je vais prendre le thé, mais d'abord je vais faire quelque chose." Et c'est un point très important, en essayant de comprendre ce que je peux faire dans un tel état, j'ai commencé à diviser la tâche en microtâches et à couper les tâches inutiles. Cela semble simple et logique, de plus, ce sont les bases du design. Cependant, en fait, tout n'est pas si rose. En cours de réalisation d'une tâche,nous considérons toujours la tâche comme une sorte de monolithe, bien qu'elle ait pu être décomposée en ses composants auparavant. De plus, nous posons constamment des centaines de questions différentes, et que se passera-t-il si cela se produit (par exemple, une erreur viendra du serveur).
Dans quelle mesure pour simplifier la tâche
J'ai divisé la tâche non pas en modules indépendants, mais jusqu'à ce qu'ils deviennent élémentaires et cessent de provoquer une résistance interne en moi. En général, cela peut ressembler à ceci:
- Créer un stub de composant avec une interface de base
- Connectez-la
- Ajouter un balisage
- Transférer des données réelles
- Ajouter des styles
- Rédiger des tests
Si cela s'avère difficile, alors ces étapes peuvent être soit affinées, soit le composant peut être développé en plusieurs parties. (Comment faites-vous?)
Ensuite, je veux attirer l'attention sur trois principes importants:
Diviser la tâche en élémentaire
Dans mon cas, la première étape ressemblait à ceci:
- Stub un composant avec du texte louche
- Ajoutez un itinéraire pour elle
- Vérifiez qu'elle est connectée
- Découvrez à quelles adresses vous devez recevoir des données du serveur
Le résultat de cette décision:
- Les tâches sont élémentaires, même dans cet état je les regarde avec soulagement, pas dégoût.
- Il est plus facile de se concentrer sur des tâches comme celle-ci.
- Également réduit les niveaux de stress (je ne me force pas et les tâches ne sont pas si effrayantes)
Concentrer l'attention sur une gamme restreinte de sous-tâches
- Moins de temps passé sur les sous-tâches
- Moins de ressources cérébrales sont dépensées
- En conséquence, la tâche elle-même est terminée plus rapidement.
Durée limitée d'une itération
- Je peux facilement convenir avec moi-même que maintenant je vais travailler pendant 15 minutes, puis je vais faire une agréable pause de 5 minutes. Bien que se convaincre (se mettre) au travail toute la journée sera plus difficile et plus frustrant
Résumons
Afin de ne pas perdre mon temps et celui des autres, je vais essayer de le faire le plus rapidement possible:
- Le travail n'est plus stressant pour moi
- Je me suis moins fatigué à la fin de la journée
- Les performances ont augmenté par rapport à la valeur sans stress: auparavant, une tâche pour 3 points d'histoire + des tests d'écriture me prenait 2 jours, maintenant il ne s'est avéré pas plus d'un et demi
- Une approche plus professionnelle consiste à utiliser une minuterie. Je voudrais parler de mes succès (et échecs, où puis-je m'en passer) en introduisant une autre fois la technique de la tomate.