Jordi Inglada

Posts tagged "rant":

25 Oct 2020

Sérendipité, productivité et télétravail

La pandémie a permis (obligé?) l'expérimentation à grande échelle du télétravail. Beaucoup de gens faisaient déjà du télétravail avant, non pas seulement comme un substitut de ce qui était fait dans les locaux de leur entreprise, mais aussi comme un complément (ramener du travail à la maison, travail pendant les déplacements professionnels de courte ou de moyenne durée). Mais dès le début du confinement, il a fallu mettre en place des outils de «communication», non, plutôt de «collaboration» pour pallier le manque d'interaction quotidienne.

Le résultat a été un recours précipité et sans esprit critique à des services de messagerie instantanée et visio-conférence pour générer des interactions non indispensables pour le déroulement normal du travail.

Certains ont attribué cela à un manque de confiance de la part des managers qui ne seraient pas formés à gérer ce genre de situations.

D'autres, ont justifié le besoin de ces outils pour favoriser la sérendipité et le brassage d'idées, malgré le fait qu'il est démontré que les interruptions et les échanges permanents son négatifs pour la productivité. En effet, la plupart des gens vivent mal les interruptions, dont la plupart ont lieu quand on est physiquement au travail. En effet, ces interruptions ont l'inconvénient de ne pas pouvoir être mises en mode avion. D'ailleurs, il existe un sens de la culpabilité associé au fait de désactiver les notifications dans les outils de «collaboration».

À l'inverse, une bonne hygiène dans la gestion de ces outils résulte en une augmentation de l'efficacité par rapport au travail en présentiel (ou par rapport au télétravail qui essaie de simuler le présentiel).

En fait, cette sacro-sainte sérendipité a vraiment du mal à marcher aussi bien qu'on le voudrait et des efforts importants (avec les budgets associés) sont déployés par les entreprises pour concevoir des locaux lui permettant de s'exprimer. Oui, on en est là.

Si on peut comprendre que certains aient besoin d'interaction fréquente, il semble peu approprié de vouloir imposer ce mode de travail à tout le monde. Mais, malheureusement, on peut s'attendre à ce que des startupeurs se positionnent sur le créneau de la e-serendipity. Déjà, les CIO (les DSI du monde d'avant) se frottent les mains en voyant venir des augmentations de leurs budgets.

Ces effets de mode dans un workplace où les promotions et la reconnaissance passent de plus en plus par le présentéisme (contemplatif o stratégique) et la visibilité (physique ou numérique) contraste avec des analyses moins sexies. En effet, il semblerait que les rencontres fortuites ne mènent qu'à des vraies collaborations que par un travail approfondi. Ce travail conjoint approfondi nécessite la co-présence, mais organisée et en évitant la culture du ASAP, le FOMO et le changement continu de contexte.

En gros, il faudrait éviter le travail superficiel composé de réunions d'information descendante, les échanges sur la messagerie instantanée, les appels téléphoniques non programmés, etc. On pourrait aussi apprendre la collaboration asynchrone, ce qui permettrait de sortir de la tradition orale où la mémoire des équipes est perdue, mais aussi de respecter le rythme de chacun.

Vaste programme …

Tags: rant fr productivity meetings
04 Feb 2015

expert.py

L'autre jour je discutais avec mon ami Gilles sur la frustration ressentie face à des services clients qui n'en sont pas. Que ce soient des avatars appelés conseillers virtuels ou des humains qui suivent une procédure préétablie pour essayer de vous donner une réponse à une question posée, il me disait que c'est pareil. Et qu'en fait, il vaudrait mieux qu'il n'y ait pas d'humain dans le système, car ça doit être désagréable pour eux de recevoir des remarques méprisantes voire des insultes de la part des clients.

Notre conversation a dérivé vers l'idée générale d'automatisation du travail pour enfin arriver au constat que les possibilités ne se limitent pas à des tâches répétitives pour lesquelles des procédures explicites peuvent être établies. Ce qui, il y a quelques années, était encore considéré comme de la science fiction ou des utilisations de l'intelligence artificielle qui restaient au niveau de la démonstration, est en train de devenir presque banal.

Ceux qui utilisent les services de Google, Twitter ou Facebook sont maintenant habitués à la reconnaissance faciale sur les photos ou l'interprétation automatique du langage naturel pour proposer des publicités ciblées.

Plus insidieux encore est le filtrage des messages reçus (priority inbox dans Gmail ou sur les flux de messages Facebook ou Twitter) qui ne présentent que ce qui est censé les intéresser en fonction d'un ensemble de critères qui leur conviennent mais qu'ils n'ont pas choisi explicitement. Cela a rappelé Gilles des idées qu'il avait eues il y a quelques années quand il participait à des commissions de choix où siégeaient des experts. Je ne dévoilerai de quoi s'agissait-il dans ces commissions, car ce qui vient pourrait être considéré comme un manque de professionnalisme de la part des experts mais aussi de Gilles.

Je n'ai pas les éléments pour défendre les experts, mais à la décharge de mon ami Gilles, je dirais qu'il était jeune et qu'il ne se rendait pas compte des enjeux de haute importance qui y étaient traités. Dans ces commissions il s'agissait d'évaluer des dossiers. Beaucoup de dossiers en peu de temps. Souvent, le panel d'experts était composé de vrais experts, très bons, mais pas du domaine concerné. Apparemment, ceci n'était pas considéré comme un problème par les méta-experts qui organisaient les commissions.

Malheureusement, cette situation transformait les évaluations en une sorte de mélange de loterie combinée à l'inquisition où chaque expert essayait de s'en sortir sans être trop ridicule.

Au bout que quelques commissions, Gilles croyait être capable d'anticiper les réactions de la plupart des experts (ils étaient des experts professionnels et donc souvent les mêmes). La quantité de dossiers à évaluer poussait les experts à faire très vite et malheureusement à bâcler le travail. La plupart fonctionnaient en pilotage automatique. Ceci désespérait Gilles. J'ai d'autres amis qui auraient eu envie de frapper certains des experts, mais l'ami dont il est question ici n'est pas un garçon violent. Il est plutôt passionné d'informatique et donc sa frustration vis-à-vis des experts s'est traduite par une envie de les remplacer par des algorithmes. En séance, il regardait les experts et voyait des logigrammes.

La frustration augmentant, ces logigrammes sont devenus du pseudo-code. Et de là, il n'a pas pu s'empêcher de franchir le pas et de coder chaque expert en séance. Il a fait de l'eXtreme programming en temps réel. Il est comme ça, mon ami : ce sont les méthodes à Gilles.

Certains des experts étaient parfaitement clairs ordonnés et élégants. Ils les remplaçait par un script Python. D'autres faisaient beaucoup attention à la forme et peu au fond des dossiers, ils devenaient des classes Ruby.

Certains, on le voyait, avaient été comme cela, mais appartenaient à une autre époque. Ils méritaient du Java. D'autres étaient, malgré tout efficaces, mais parfois difficiles à suivre. Il leur accordait du C++. D'autres étaient rapidement débordés dès qu'ils avaient plusieurs dossiers à traiter. Ils finissaient en script Matlab.

D'autres, avaient une telle mémoire des dossiers qu'ils avaient traités pendant des années, qu'il fallait les remplacer par du SQL. D'autres étaient incompréhensibles, désordonnés, embrouillés. Ils méritaient à peine un peu de Perl, voir de l'awk et il avait envie de les envoyer vers /dev/null.

Il était déçu de ne jamais avoir pu se servir du Lisp, qu'il réservait pour le jour où il croiserait un expert qui se conduirait de façon élégante, intelligente et iconoclaste, mais juste.

Gilles a beaucoup mûri professionnellement et a fait reconnaître ses compétences. D'ingénieur junior il est passé architecte, puis chef de projet. Il a récemment atteint la sublimation et a été nommé responsable technico-commercial.

Tags: fr humor programming rant
01 Jul 2010

Community building

In my last post I wrote about open approaches for Earth Observation. Open (science/source/whatever) means community. I am in the middle of the reading of "The Art of Community" and it is very inspiring. In some ways, it reminds me of very much of Chapter 4 "Social and Political Infrastructure" of Karl Fogel's "Producing Open Source Software - How to Run a Successful Free Software Project", although Bacon's book is more general.

Anyway, both books give very good insight on the issues and tricks involved in a community-based project and even the particular case of projects which are created and managed by companies.

This is an interesting point, since one could think that a project nfunded by a company has more chances to succeed than a pure volunteer-based one, but many real examples show that this is not the case. The main pitfalls of a corporate open source project are related to decision making and communication. For a project to succeed, the community has to be respected and open discussions and meritocracy are the 2 pillars of community.

Examples of this are the fact that all decisions involving the development have to be explained and discussed in a way that all developers are involved. Examples of closed discussions at the company level leaving out the volunteer contributors are given.

Another interesting example is the one given by Fogel about meritocracy: any developer should earn the write access to the source repository by proving his value. Usually, in corporate environments, developers have commit access from the first day, while external contributors, which usually are much more capable, have to wait long time before that.

An important player in any open source project is the Benevolent Dictator (BD). I will cite Fogel verbatim here:

"It is common for the benevolent dictator to be a founder of the project, but this is more a correlation than a cause. The sorts of qualities that make one able to successfully start a project—technical competence, ability to persuade other people to join, etc.—are exactly the qualities any BD would need. And of course, founders start out with a sort of automatic seniority, which can often be enough to make benevolent dictatorship appear the path of least resistance for all concerned.

Remember that the potential to fork goes both ways. A BD can fork a project just as easily as anyone else, and some have occasionally done so, when they felt that the direction they wanted to take the project was different from where the majority of other developers wanted to go. Because of forkability, it does not matter whether the benevolent dictator has root (system administrator privileges) on the project's main servers or not. People sometimes talk of server control as though it were the ultimate source of power in a project, but in fact it is irrelevant. The ability to add or remove people's commit passwords on one particular server affects only the copy of the project that resides on that server. Prolonged abuse of that power, whether by the BD or someone else, would simply lead to development moving to a different server.

Whether your project should have a benevolent dictator, or would run better with some less centralized system, largely depends on who is available to fill the role. As a general rule, if it's simply obvious to everyone who should be the BD, then that's the way to go. But if no candidate for BD is immediately obvious, then the project should probably use a decentralized decision-making process …"

And I will end this post by using the opening quote of Bacon's chapter 9:

"The people to fear are not those who disagree with you, but those who disagree with you and are too cowardly to let you know." —Napoléon Bonaparte

Food for thought.

Tags: open-source rant
Other posts
Creative Commons License
jordiinglada.net by Jordi Inglada is licensed under a Creative Commons Attribution-ShareAlike 4.0 Unported License. RSS. Feedback: info /at/ jordiinglada.net