Avec la traduction (via DeepL)
Au début de ma carrière, lorsque je travaillais comme ingénieur, mon patron avait mis en place un processus selon lequel l'équipe d'ingénieurs devait rendre compte de l'état d'avancement du projet. Il insistait pour que nous suivions les étapes suivantes, dans l'ordre indiqué :
- Phrase clef : Les faits ; pas d'adjectifs, d'adverbes ou de modificateurs. "Le jalon 4 n'a pas été atteint à temps et nous n'avons pas commencé la tâche 8 comme prévu". Ou encore : "La charte a été approuvée comme prévu".
- Situation actuelle : Comment l'énoncé de la chute affecte le projet. "En raison de l'étape manquée, le chemin critique a été retardé de cinq jours."
- Prochaines étapes : La solution, le cas échéant. "Je pourrai rattraper trois jours au cours des deux prochaines semaines, mais j'aurai toujours deux jours de retard."
- Explication : La raison de la chute. "Deux des cinq jours de retard sont dus à la découverte tardive d'un problème d'interface matérielle, et les trois jours restants sont dus au fait que j'ai été appelé à aider le personnel du service d'assistance à la clientèle pour un problème de production."
Remarquez l'ordre presque inverse de ces points par rapport au style de rapport habituel dans lequel les membres de l'équipe commencent par une longue explication des raisons pour lesquelles les choses se sont mal passées. En suivant les quatre étapes décrites ci-dessus, le chef de projet apprend d'abord les informations les plus importantes, puis les informations complémentaires qui l'aideront à compléter l'histoire.
Au début, il n'était pas facile de rendre compte de cette manière. Cela nous obligeait à aller à l'essentiel rapidement et à ne pas recourir à l'obscurantisme. Mais je n'ai pas seulement appris à pratiquer ce style de rapport de situation au bureau, je l'ai aussi enseigné à mes enfants.Cette méthode a été mise à l'épreuve quelques années plus tard. Il était minuit passé, bien après l'heure à laquelle mon fils Raj, alors âgé de 17 ans, aurait dû rentrer à la maison. Il conduisait pour la première fois et la nuit était orageuse. Sa mère et moi étions anxieux et soucieux de son bien-être. Finalement, le téléphone a sonné. C'était Raj, et il a dit : "Papa, je vais bien ; le taureau est mort".
Dieu merci, mon fils allait bien, mais le commentaire sur le taureau mort m'a intrigué. Nous ne possédions pas de taureau. Où était-il ? Comment le taureau était-il mort ? Et pourquoi m'en parlait-il ?
Puis il a dit : "La voiture est endommagée mais utilisable."
D'accord. Il avait eu un accident, la voiture n'était pas une perte totale et il y avait un taureau mort (ce qui reste une grande énigme). Je me suis demandé si notre assurance automobile couvrait les taureaux morts.
Il m'a ensuite expliqué le lieu de l'accident et m'a informé qu'une personne à proximité avait appelé la police et qu'il (Raj) avait pris quelques photos de la scène de l'accident.
À ce moment-là, ma femme s'est réveillée et m'a demandé : "C'est Raj, et il va bien ?". Je lui ai répondu : "Il va bien, le taureau est mort". Cela a attiré son attention et elle était maintenant bien réveillée.
Bien qu'un peu fâchée que Raj soit rentré si tard et qu'il ait eu un accident, j'ai été impressionnée par son comportement calme et sa capacité à garder son sang-froid. Raj a poursuivi en disant : "Tu n'as pas besoin de te presser. Je vous expliquerai quand je vous verrai." J'ai raccroché le téléphone et j'ai commencé à me préparer à me rendre sur les lieux de l'accident.
A ce moment-là, ma femme, toujours intriguée par les informations qu'elle avait reçues, m'a demandé des détails. Je lui ai répété : "Il va bien, le taureau est mort et il m'expliquera les détails à mon arrivée". Un peu agacée, elle m'a dit : "C'est l'une de vos histoires à chute, n'est-ce pas ?".J'ai été très impressionné par la façon succincte dont Raj m'a donné la bonne information dans le bon détail, sans entrer dans des explications inutiles. En journalisme, c'est ce qu'on appelle la pyramide inversée, qui commence par la conclusion, suivie des faits les plus importants et, enfin, des détails. Ce style contraste avec la rédaction académique, qui commence par l'énoncé du problème, développe le contexte, discute des facteurs d'influence et enfin énonce les conclusions. Lorsque l'approche académique est utilisée pour présenter des rapports sur l'état d'avancement d'un projet, les personnes qui attendent encore la chute prient silencieusement : "S'il vous plaît, mon Dieu, tuez-moi maintenant". C'est précisément la raison pour laquelle je commence par la chute.
Pour de nombreux membres de l'équipe de projet, commencer par la chute peut être déconcertant, mais nous avons constaté qu'une fois qu'ils s'y sont habitués, ils apprécient vraiment la clarté du message et le temps gagné pour faire passer le message.
Essayez-le, vous l'apprécierez.
Lors de la planification de votre journée, dressez la liste de toutes les tâches que vous devez faire et ordonnez les selon la logique suivante :
- Une tâche « A » est une tâche importance avec des conséquences significatives
- Une tâche « B » est une tâche que vous devriez faire mais qui a des conséquences limitées
- Une tâche « C » est une tâche qui serait sympa à faire mais sans conséquences
- Une tâche « D » est une tâche que vous pouvez déléguer à quelqu'un d'autre
- Une tâche « E » est une tâche que vous pouvez éliminer sans aucune conséquence
Ajoutez une lettre devant chacune de vos tâche et ordonnez les en ajoutant un numéro, exemple :
- A1 - Écrire un article
- A2 - Publier l'article
- D1 - Faire ma comptabilité
- E1 - Acheter un poster
La règle veut que vous ne fassiez jamais de tâche de type B lorsqu'il reste encore une tâche de type « A » à accomplir.
J'aime bien l'idée. À caler avec un todo.txt
qui va bien. Et puis l'appli pter
sur Ubuntu ainsi que Simple Task (pour Nextcloud) sur Android.
Intéressant :
En 1944, l’OSS (ancêtre de la CIA) proposait un petit manuel de sabotage des organisations à la portée de tous. J’ai essayé de synthétiser ça en 10 points avec mes propres mots :
- Insistez systématiquement pour que les procédures en place soient respectées et suivies à la lettre. Ne laissez jamais personne prendre une initiative qui pourrait accélérer le processus.
- Soyez verbeux, à l’oral comme à l’écrit. Multipliez les références et les anecdotes, attirez l’attention sur des problèmes secondaires et abstenez-vous de résumer votre avis ou vos recommandations.
- Remettez toujours la légitimité de votre instance de décision en question : faites valider chacune de vos décisions par la hiérarchie et multipliez les comités consultatifs aussi larges que possible.
- Montrez-vous extrêmement prudent sur tous les sujets, insistez sur le fait que toute erreur pourrait avoir de graves conséquences et invitez régulièrement le groupe à reconsidérer des questions déjà tranchées.
- Convoquez fréquemment des réunions, multipliez les participants (au motif que leur avis pourrait être utile) et insistez pour que la réunion se fasse en présentiel pour que tout le monde perde autant de temps que possible.
- Récompensez les meilleurs opérationnels en leur offrant (ou en appuyant leur candidature pour) des postes prestigieux mais pour lesquels ils ne sont pas compétents et qui les éloignent le plus possible du terrain.
- Montrez-vous aussi pointilleux que possible sur les questions de vocabulaire mais insistez sur le fait que les délais impartis ne permettent pas d’organiser des réunions spécifiquement dédiées à ce problème.
- Privilégiez systématiquement les échanges écrits, même pour les choses les plus anodines, et demandez toujours (par écrit) le plus de précisions possibles avant de commencer à travailler effectivement.
- Assignez toujours les tâches critiques (i.e. potentiellement bloquantes) à des collaborateurs peu compétents ou lents et exigez que leur travail soit parfait avant de passer à l’étape suivante.
- À chaque dysfonctionnement, organisez une réunion (cf. point 5) afin d’établir une nouvelle procédure (cf. point 1) et discutez-en par écrit (cf. point 8) avec votre hiérarchie (cf. point 3).
Je vais tenter de traduire en français ce Minifesto :
Six manières de recréer des discussions de bureau rapides et informelles dans un monde où le travail est décentralisé.
- Organiser des permanences dans n’importe quel canal
Historiquement, bon nombre de responsables et de directeurs ont pratiqué la politique de la porte ouverte. Dans ce nouveau monde axé sur le numérique, cela se manifeste fréquemment par un créneau horaire libre où chaque collaborateur disposant du lien d’appel vidéo correspondant peut se connecter pour discuter de ses principales préoccupations. Les appels d’équipe sont une solution alternative plus inclusive.
J'aime bien cette idée : ouvrir un canal de télé-conférence type « permanence porte ouverte » d'une équipe pour échanger sans but prédéfini.
Dans les autres conseils sur la page, il y a :
- Les sessions de réflexion après les réunions
- Une programmation en binôme rapide et simplifiée
- Répondre aux commentaires de dernière minute d’un intervenant
- Un dépoussiérage hebdomadaire pour régler les derniers détails
- Des rencontres sociales
Règle 4
Aucune fonction ne doit être plus longue que ce qui peut être imprimé sur une seule feuille de papier, dans un format de référence standard, avec une ligne par instruction et une ligne par déclaration. En règle générale, cela signifie qu’il n’y a pas plus de 60 lignes de code par fonction.
Ayant parfois affaire à des fichiers Excel de quelques centaines de lignes, et parfois plusieurs dizaines de colonne, ça me rend fou.
Donc j'aime bien cette règle : maximum 60 lignes. À cela on peut ajouter une des règles du PEP-8 Python qui préconise pas + de 79 caractères par ligne.
Voir aussi la RFC 2223 qui indique :
3a. ASCII Format Rules
[…]
Each page must be limited to 58 lines followed by a form feed on a
line by itself.
Each line must be limited to 72 characters followed by carriage
return and line feed.
Cela donne un formatage un peu surprenant mais cela donne une bonne idée de ce qui est humainement révisable.
La fameuse cible (que je cherchais depuis hier…) ! On y retrouve :
-4
-3
-2
-1
Taper ici = faire du surplace
+1
+2
+3
C'est directement inspiré de la "pyramide" de l'auteur.
Voir aussi une nouvelle sur LinuxFr.org qui parle de "comment réfuter".
« À vouloir donner la possibilité de réaliser des choses complexes, on complexifie inutilement la réalisation des choses simples. »
Intéressant cette structuration des dossiers personnels :
L’action crée ma motivation. Pas le contraire
shit!, toujours aussi bons ses articles !!
Cette méthode est très conceptuelle mais ses bases m'intéressent beaucoup. Au moins à titre de curiosité je penses que c'est pertinent de la découvrir.
via https://fego.github.io/2020/11/01/J%27ai-enfin-appris-%C3%A0-prendre-des-notes.html
via https://chezsoi.org/shaarli/?Cs89yg
Je cherchais la notion de GO/NOGO et en lisant ce document, j'apprends que le “No Go” est à la base une notion où l'avion est en bout de piste mais qu'il ne décollera effectivement pas. Ici c'est le fait d'emmener un patient au bloc et d'arrêter le processus d'opération avant de l'inciser.
Je découvre donc dans ce document « aide cognitive POuR – DÉCider » : « L’objectif […] est de fournir, face à une situation inattendue, un outil structuré pour la prise de bonnes décisions en cas d’absence de procédures ou de règles préexistantes et quand une mauvaise décision peut avoir des conséquences graves. »
Cette aide cognitive comporte 3 parties :
Abr. | Terme | Question |
---|---|---|
P | Problème | Quel est le problème ? |
Ou | Options utiles | Quelles sont les options utiles et possibles ? |
R | Risques | Quels sont les risques et avantages de chaque option ? |
- | Échange | Échange et partage en équipe |
D | Décision | Que faisons-nous ? |
É | Exécution | Qui fait quoi ? Quand ? Comment ? |
Cider | Contrôle | Est-ce que tout s’est déroulé comme prévu ? |
Un surnom m’a un jour été donné : “Pompier du code”. J’aime cette notion. Un pompier c’est 50 % d’entraînement, 40 % de prévention et 10 % d’opération de secours.
Les étapes avant d'effectuer une performance (sportive) :
Alors, comment puis-je choisir un problème sur lequel travailler ? C’est une heuristique complexe calculée à partir des facteurs suivants :
- Nombre d’utilisateurs concernés
- Gravité (« problème de sécurité » vs « faute d’orthographe »)
- Opportunité (ce qui signifie que je l’ai remarqué lorsqu’il a été déposé)
- Disponibilité (est-ce que je me concentre sur autre chose lorsque je remarque le problème ?)
- Plaisir possible et humeur du moment (eh oui, car je suis bénévole, ça vous dérange ?).
Et en lisant le document source : https://faculty.washington.edu/ajko/papers/Li2015GreatEngineers.pdf
Pas mal ce diagramme qui concerne la méthode d'analyse SWOT : Strengths, Weaknesses, Opportunities, Threats.
Les 2 premières ayant une origine interne (organisationnelle), tandis que les deux seconds sont d'origines externe (environnementale). Puis le première et le troisième sont positifs tandis que le second et le dernier sont négatifs.
Des moyens pour apprendre le lâcher prise: lâcher prise implique parfois de nous changer nous-même ou de nous accepter avec nos limites.
J'aime bien cette image, elle porte à réflexion !
- Controlling
- Coordinating
- Delegating
- Directing
- Guiding
- Empowering
- Advising
- Collaborating
- Participating
authority of leader↓→ autonomy of team | low | medium | high |
---|---|---|---|
high | controlling | co-ordinating | delegating |
medium | directing | guiding | empowering |
low | advising | collaborating | participating |
(petite voix dans la tête : « Comment je suis arrivé sur cette page moi !?! »)
Wouhou, je viens d'apprendre que je présente une synesthésie spatio-temporelle : je vois les mois de l'année sur un anneau avec décembre/janvier en haut et juillet/août en bas (en fait c'est plutôt juin que je vois en bas mais bon, « j'me soigne »)
Édit201510T13:17 : j'apprends ici http://thomasd.eu/shaarli/?ZQI9NA qu'il existe le phénomène de la misophonie : « La misophonie, littéralement « haine du son », est un trouble neuropsychiatrique rarement diagnostiqué mais commun caractérisé par des expériences négatives (colère, haine ou dégoût) déclenchées par des sons spécifiques » (cf WP : https://fr.wikipedia.org/wiki/Misophonie ). Je ne suis pas « touché » mais je connais des personnes qui sont vraiment dérangées par les miasmes ou les craquements d'articulations... Intéressant
Ce qui me dérange, c'est la question que soulève cette phrase : « La maladie n'est pas classée comme un trouble discret dans le DSM-5 ou la CIM-10 ; cependant, une étude menée en 2013 par trois psychiatres […] suggère sa classification en tant que trouble psychiatrique à part »...
Wouhou, je reprends un peu d'activité sur mon blog (cf https://orangina-rouge.org/plux/index.php?allarchive ), alors je me fais un peu d'auto-promo.
Ici c'est pour parler d'une méthode de travail : Pomodoro.
J'avais déjà parlé de la méthode GTD mais je vous rassure : les 2 sont compatibles ;-) .
Sacrément intéressant cette vidéo !!!
via http://coreight.com/content/zone-de-confort-osez-en-sortir
via http://coreight.com/content/qualites-ingenieur-avec-ou-sans-diplome
via http://shaarli.pandouillaroux.fr/?Epy5Lw
via https://www.shaarli.fr/
Edit 20151019 : À voir également cette image : http://www.jesuisundev.fr/wp-content/uploads/2015/10/how-to-expand-my-comfort-zone.jpg : Dans une bulle d'un côté “Where the magic happens” (« Là où la magie se produit ») et dans une autre bulle “My comfort zone” (« Ma zone de confort ») ; tirée de cet article : http://www.jesuisundev.fr/pourquoi-developpeur-est-un-boulot-a-part/ .
via http://sebsauvage.net/links/?z4GAlg
Je cite : "
Niveau 0 : pisser du code ;
Niveau 1 : livrer du code ;
Niveau 2 : livrer un logiciel ;
Niveau 3 : livrer un produit ;
Niveau 4 : livrer de la valeur."
Très intéressant. Je pense que c'est adaptable à d'autre métiers. Mais par exemple dans le mien, je n'arrive pas à faire d'analogie avec "pisser du code"... (peut-être que ne pas réussir à concevoir le niveau 0 est plutôt bon signe ^_^ ).
En revanche là, on parle du développeur alors que le constat de l'article ce concentre sur la boîte d'édition de logiciel. J'aurais tendance à penser la même chose : créer de la valeur est très difficile au niveau individuel. Si l'on n'a pas la synergie de groupe c'est compliqué ; voire très compliqué lorsque l'on nous mets des bâtons dans les roues (consciemment ou non).
Pas mal ça ; je vais retenir la conclusion :
« Ne pas se justifier, c'est donc :
– simplement répondre à la question posée
– revenir toujours à la réalité et fuir comme la peste les digressions affectives
– responsabiliser l'autre pour ne pas être englué dans ses décisions
– répéter en boucle comme un robot. »
Cela me fait penser à la méthode DESC : http://www.fr.wikimediation.org/index.php?title=M%C3%A9thode_DESC :
« (D)écrire : être concret, précis, factuel, restituer l'observé ou l'observable
– (E)xprimer : mettre des mots sur sa manière de vivre les choses, d'éprouver, de ressentir. Dire ses appréhensions. Parler de soi et non sur l'autre.
– (S)pécifier : expliquer ses attentes : changement d'action, de comportements, proposer sa manière de résoudre une problématique
– (C)onséquences : anticiper ce qui serait positif dans le changement et ce qui serait négatif. »
Putain, qu'est-ce que je suis d'accord avec tout ça :
J'adore ce principe. Alors je cite : «
Quelqu'un vous manque ? ...Appelez
Besoin de voir du monde ? ...Invitez
Besoin d'être compris ? ...Expliquez
Des questions ? ...Demandez
Quelquechose vous déplaît ? ...Dites-le
Quelquechose vous plaît ? ...Faites-le savoir
Besoin de quelquechose ? ...Demandez
Amoureux de quelqu'un ? ...Dites-lui »
via http://shaarli.callmematthi.eu/?-6p7qA
J'ai l'impression d'avoir déjà lu ça quelque part, mais c'est pas grave, je reprends (organisé à ma sauce) - via Vader http://liens.vader.fr/?GC2IAA :
J'aime bien cette synthèse ; la définition des « 4 problèmes les plus rencontrés lors de la conduite de projet informatique.
1- Définition exhaustive du besoin en amont
2- Transferts de responsabilité
3- Validation tardive
4- Manque d’implication du client final »
Sans tomber dans les méthodes SCRUM et autre, penser à cela pendant la mise en place d'un projet avec au moins 2 intervenants (quelque soit la taille) réduire un certain nombre de soucis !
:-(
Dans le Readme, une info mise en avant : « Super easy setup »
Ouais... Pourquoi chez OVH je me tape juste un beau « This software require to have "Magic quotes" disabled, it's deprecated since PHP 5.4 ("magic_quotes_gpc = Off") ».
C'est mignon mais c'est pas ce que j'appelle « Super Easy » surtout qu'il n'y pas d'autres explications...
Edit: pour ceux qui auraient le même problème, la solution par là : http://guides.ovh.net/ConfigPhp .
J'aime bien cette idée !
Dans le principe du systèmier.
Tiens je ne connaissais pas cette méthode. Elle est simplissime, beaucoup l'utilise déjà mais lui donner un nom facilite : sa compréhension, sa mémorisation (et donc son application), sa transmission à d'autres, ... Donc ADRA sert pour savoir à évaluer une nouvelle tâche de travail :
Abandonner : ne pas faire fait gagner le temps que l'on aurait passé à la tâche.
Déléguer : quand d'autres savent faire et que l'on peut les suivre, autant qu'ils s'y mettent.
Reporter : ce que l'on fait le plus souvent mais encore faut-il bien planifier.
Agir : dernier recours, faire notre tâche « Do Our Own Duty ».
Tiens, c'est pas faux ça ; j'essaierai d'y travailler.
Hé ouais. Savoir dire non c'est important.
Je l'ai appris par moi-même et ça me rends de fiers services ! Pensez-y : savoir ce que vous voulez, c'est savoir dire non !
Oooouh mais j'adore cette idée ! J'ai toujours jamais compris pourquoi on avait toujours des logiciels complexes ( GanttProject : http://alternativeto.net/software/ganttproject/, msProject, MOOS, ... ) pour représenter quelque chose de simple.
Ici on a la solution avec un simple tableur (OpenOffice.org, LibreOffice ou le moins libre Excel) et qui fonctionne sans macro ou autre ramassis d'automatisation difficilement inter-opérable. En plus la solution est tellement simple qu'elle est facilement ajustable aux besoin.
(et comme la licence est gentiment une CC-BY-NC-ND, j'ai gardé le travail ici : http://orangina-rouge.org/tools/productive-tools/Apprendre%20%C3%A0%20cr%C3%A9er%20un%20diagramme%20de%20Gantt%20avec%20Tableur.htm )
Je suis en cours de déménagement.
Je vais changer de domicile.
C'est l'occasion de faire un point sur mes habitudes.
Le minimalisme, je suis preneur.
Alors ici la liste piochée sur le site original : «
via http://strak.ch/liens//?LDwYKQ
via http://shaarli.fr
source originale http://www.becomingminimalist.com/15-clutter-busting-routines-for-any-family/
Enfin un article bien présenté et argumenté sur la proxémie (Edward Twitchell Hall - 1963) avec la définition des différentes ou sphères (au moins dans notre culture) :
Voir aussi : https://fr.wikipedia.org/wiki/Proxémie
J'adore ce site.
J'aimerais bien savoir coder pour en faire un équivalent libre...
Edit : un autre site encore plus complet : http://orangina-rouge.org/shaarli/?vSBogg
« Les bases, les bases, les bases et encore les bases. [...] En boxe, il y a 7 techniques. En musique, il y a 12 notes. »
Et en escalade, il y a, allez 10 techniques de bases, et c'est simplement leur parfaite maîtrise et coordination qui permettra « d'atteindre les sommets ».
Intéressant cet article :
« Pourquoi ? ». « Pourquoi je me lève tôt tous les matins et que j’accepte de voyager régulièrement plus d’une heure durant dans des conditions souvent difficiles ? » ; « Pourquoi je suis content de ma journée, malgré que je doive emprunter les mêmes transports au fonctionnement douteux dans l’autre sens ? » ; « Pourquoi tout ça ? » et « pourquoi pas autre chose ? »
Alors pensez à définir votre WHY !
Je vais tâcher de m'y atteler. Cela me semble important, tout comme être capable d'affiner ses idées « politiques », ses idéaux, se que l'on considère « bien ou mal », etc.
Vraiment très intéressant ce paradoxe. Je vois le phénomène se produire globalement à mon travail pour un certain projet. Et j'essaierais de le percer lors de plus petites réunions.
Parce qu'il est m'est arrivé d'en chercher.
Ça peut toujours servir...
Une bonne analyse de ce qui se fait.
Il faut, je pense, tendre vers une gestion agile (au sens propre du terme, pas de la méthode) en se basant sur des principes "monolithiques"..
Lovely
le titre parle de lui-même
Ca y est, je crois que j'ai trouvé mon remplaçant de RememberTheMilk...
Encore en test mais ça me plaît déjà.
Ca risque de vite faire partie de mon couteau suisse d'application Web.