Il ne s’agit pas là d’une réponse complète - il y en a déjà plusieurs très bonnes qui mentionnent des choses importantes telles que l’utilisation de votre VCS et de votre logiciel de gestion de projet ", mais plutôt d’un addendum qui ajoute quelques points que je n’ai vus trouve très utile et que j’espère que d’autres le trouveront également.
1. Aucune tâche n'est trop tôt ou trop petite pour écrire
Les gens font généralement des listes TODO pour des choses qu’ils envisagent de faire à l’avenir , mais comme la programmation nécessite de la concentration et que nous pouvons être interrompus à tout moment , j’ai trouvé utile d’écrire même ce que je fais en ce moment, ou ce que je suis sur le point de commencer en quelques secondes . Vous pensez peut - être que vous êtes dans la zone et vous ne pourriez oublier la solution qui vient de vous frapper dans ce aha moment, mais quand votre collègue tombe par votre cube pour vous montrer une photo de son orteil infecté , et vous êtes ne pouvant finalement que se débarrasser de lui en commençant à se ronger le bras , vous souhaiteriez peut-être avoir écrit une note rapide, même si ce n'est que sur une note Post-It ™.
Bien sûr, un autre support plus persistant pourrait être meilleur (j'aime particulièrement OmniFocus ), mais le but est au moins de l'avoir quelque part , même si vous terminez dans 20 minutes avant de jeter le Post-It ™. Bien que vous découvriez peut-être que ces informations deviennent utiles, vous pouvez mettre des feuilles de temps ou des factures au client, ou lorsque votre patron / client vous demande sur quoi vous avez travaillé et dont vous ne vous souvenez plus. Si vous déposez toutes ces notes dans une boîte, un tiroir ou un dossier, puis lorsqu'une grosse interruption survient - un projet interrompant -, vous pouvez les parcourir et vous souvenir de tout ce que vous avez fait pour obtenir votre code au point de trouvez-le quand vous revenez au projet.
2. Utilisez un tableau blanc à votre bureau pour capturer de grandes idées
J'ai un tableau blanc de 3 "x 4" à côté de mon bureau. Ainsi, lorsque je commence un projet, je peux réfléchir aux solutions à tous les problèmes que je perçois dans un projet. Il peut s'agir de diagrammes architecturaux, de cas d'utilisation, de listes de risques et d'obstacles, ou de tout ce qui vous semble pertinent.
Certaines approches plus formelles exigent que vous génériez des diagrammes et des cas d'utilisation, etc. sous forme de "livrables" dans un format papier ou électronique, mais je trouve que cela peut créer beaucoup de travail supplémentaire et devenir simplement une série de sous-projets qui se terminent. être divorcé de l'objectif réel du projet principal, et fait simplement partie d'un processus formalisé que vous devez faire, mais auquel personne ne prête beaucoup d'attention. Un tableau blanc est la chose la plus simple qui fonctionne réellement, du moins selon mon expérience. Il est aussi persistant que vous le souhaitez (avec une caméra) et surtout, il vous permet d’obtenir vos idées immédiatement.
Je pense mieux avec un crayon à la main, alors j’exprime naturellement mes pensées sur une surface blanche, mais si vous estimez que ce n’est pas le cas, voici quelques questions qui pourraient vous aider à décider ce qui est pertinent. :
- Si j'étais le développeur principal, sur le point de partir en lune de miel pendant 3 mois pendant que d'autres développeurs terminaient le projet, quelle direction générale voudrais-je leur donner? Quelles idées voudrais-je être sûr de savoir, ou quelles approches voudrais-je m'assurer de suivre? Quelles bibliothèques ou autres solutions utiles voudrais-je être sûr de connaître?
- Si ce projet était mon idée à un million de dollars, je savais que cela garantirait mon indépendance financière future, mais que je devais subir une intervention chirurgicale cruciale qui m'inciterait à rester invalide pendant 3 mois, qu'est-ce que je souhaiterais que mon futur le projet?
(Lorsque je note mes idées pour la première fois, je ne m'inquiète que de leur donner un sens à mon moi actuel. Une fois qu'elles sont en baisse, je peux les regarder de manière plus critique et faire des changements pour m'assurer qu'elles ont un sens pour moi-même ou pour les autres. ne pas communiquer avec les autres au fur et à mesure que vous les écrivez peut conduire à un blocage des rédacteurs - un esprit encrassé par des objectifs opposés.
Je vous recommande de dépenser de l'argent pour acheter un tableau blanc correct, au moins 3 "x 4", et le suspendre à l'espace où vous travaillez normalement. Un tableau blanc physique présente de nombreux avantages par rapport à tout système virtuel.
- C'est large. En prenant beaucoup de place, elle fait sentir sa présence, et les plans qui y sont associés donnent l’impression qu’ils font partie de votre espace de travail, vous aidant à vous orienter dans la bonne direction tout le temps.
- C'est là constamment: vous n'avez pas à lancer une certaine application ou un site Web pour y accéder, et vous ne risquez pas d'oublier comment y accéder, ou d'oublier que c'est là.
- Il est immédiatement accessible lorsque vous avez une idée à laquelle vous souhaitez réfléchir.
Vous perdez de nombreux avantages si vous utilisez simplement un tableau blanc dans une salle de réunion, puis prenez un instantané avec votre téléphone. Si vous gagnez de l'argent en programmant, cela vaut bien le coût d'un tableau blanc décent.
Si vous avez un autre projet interrompre celui qui a rempli votre tableau blanc, vous devrez peut - être recourir à l'instantané sur votre téléphone, mais au moins vous aurez que dans 3 mois lorsque le projet « urgent » est terminé et vous devez retourner à l'autre. Si vous voulez le recréer sur votre tableau blanc, cela ne vous prendra probablement que 15 minutes et vous constaterez que vous pouvez l’améliorer beaucoup en cours de processus, ce qui rend ce petit investissement de temps très rentable.
3. Sensibiliser les intervenants au coût d’une interruption de projet
Je trouve la métaphore d’un avion utile: commencer et terminer un projet, c’est comme piloter un avion. Si vous renflouez au milieu du vol, l'avion n'attendra pas que vous reveniez, et vous avez besoin d'un moyen de transport pour vous rendre du projet / vol en cours au suivant. En fait, si vous êtes au milieu d’un vol Phoenix-Fargo et qu’on vous dit que vous devez interrompre ce vol pour prendre un autre avion de Denver à Detroit, vous devez atterrir au premier avion à Denver (qui heureusement pas très loin de votre trajectoire de vol - pas toujours le cas avec de vraies interruptions) et quelqu'un doit trouver quoi faire avec la cargaison et les passagers. Ils ne vont pas rester assis et attendre pour toujours.
L’intérêt de ces projets est que la transition d’un projet à l’autre entraîne une lourde dépense de temps et laisse beaucoup de points faibles qu’il faut régler.
Dans un projet, il y a évidemment et inévitablement beaucoup de choses qui se passent dans votre tête pendant que vous travaillez et toutes les pensées ne peuvent pas être sérialisées sur un support écrit, et toutes les iotes de ces pensées qui sont sérialisées ne resteront pas après la désérialisation. Bien que nous puissions partiellement capter nos pensées par écrit, il s’agit bien d’un format avec pertes.
Le problème (à mon sens) est que les chefs de projet et autres hommes d’affaires voient les projets comme une série d’étapes qui peuvent souvent être réorganisées à volonté (sauf s’il existe une dépendance explicite à leur diagramme de Gantt) et qu’elles peuvent être facilement réparties entre les utilisateurs. ou retardé jusqu'à ce que cela soit plus pratique pour l'entreprise.
Tous ceux qui ont déjà programmé savent que les projets logiciels ne peuvent pas être traités comme des blocs Lego et qu’ils se déplacent comme vous le souhaitez. Je trouve que la métaphore du transport aérien donne au moins aux parties prenantes un élément concret auquel elles peuvent penser et qui ne peut manifestement pas être traité comme une série d'étapes disparates à réorganiser sur un coup de tête. Au moins, il est facile de comprendre votre argument selon lequel de telles interruptions ont un coût. Bien sûr, c'est toujours leur décision, mais vous voulez leur faire prendre conscience de cela avant qu'ils n'interrompent un projet pour vous en donner un autre. Ne soyez pas combatif, mais offrez des informations utiles et la perspective utile du développeur, prêt à faire tout ce dont il a besoin de votre part, mais proposez simplement des informations dont il ne serait peut-être pas au courant si vous ne le lui dites pas.
En bref:
- Notez tout ce que vous êtes sur le point de faire, même si vous pensez ne pas en avoir besoin par écrit. Même un petit crayon bat une longue mémoire.
- Faites un brainstorming sur l’ensemble d’un tableau blanc physique auquel vous avez un accès persistant.
- Vous pouvez éviter les interruptions de projet si vous informez les décideurs que de telles interruptions ont un coût, et au moins vous aurez défini les attentes afin qu'ils sachent que le projet prendra un peu plus de temps lorsque vous le reprendrez.