Posts tagged "rant":

SFR & Moi, et mon transit

tl;dr¹ : Soudainement, il y a quelques semaines, ma connexion internet par câble coaxial a commencé à souffrir de constipation intermittente. La solution de mon opérateur : manger de la fibre pour améliorer le transit moyennant une augmentation de 25% du prix de l'abonnement.

Un service technique à votre écoute

Début janvier, j'ai donc appelé le service technique pour leur faire part de mon problème. La première proposition qu'on m'a faite, avant toute autre chose, a été de «passer sur la vraie fibre, car la connexion est plus stable». Je leur ai expliqué que ma connexion a été très stable pendant des années et qu'il devait y avoir un autre problème. Ils ont été suffisamment gentils pour me proposer le vaudou habituel : réinitialiser la box, débrancher le câble, souffler dedans, rebrancher et ajouter une patte de poulet. Après cela, la connexion marchait! J'ai essayé d'expliquer que, comme les coupures sont intermittentes, on n'était pas vraiment surs que le problème soit résolu. Mon interlocuteur m'a fait comprendre qu'il ne pouvait rien d'autre pour moi. Fin du premier acte.

Deux jours plus tard, je me suis permis de rappeler le service technique, car la situation était la même qu'avant mon premier appel. J'ai passé l'étape habituelle de l'identification (numéro de téléphone fixe, nom et prénom, numéro de portable), ce qui est cocasse, car en appelant avec mon portable, on me demande d'appuyer sur 1 si ma demande concerne ma ligne 05.67.XX.XX.XX. Ils savent bien que je suis, quel est mon numéro de portable et de fixe. Mais bon, je suppose que ça leur donne le temps d'ouvrir mon dossier. J'explique à nouveau mon problème (même si mon interlocuteur a mon dossier devant les yeux) et on me propose de … «passer sur la vraie fibre, car la connexion est plus stable». Je leur explique à nouveau que le problème n'est pas là (ça marchait correctement avant) et que je n'ai pas envie d'augmenter ma facture de 25%. Réponse : on peut me faire une réduction de 25% la première année. J'insiste pour une solution technique et non pas commerciale et on accède finalement à m'envoyer un technicien dans quelques jours.

Le jour J, le technicien arrive chez moi, je lui explique le problème et il regarde la qualité du signal qui arrive dans mon salon, juste avant la box. Tout est OK. Son verdict : il y a un problème réseau, soit sur le branchement sur le poteau dans la rue (là où la fibre dérive vers le coaxial), soit plus loin. Évidemment, il n'a pas le droit de sortir son échelle et regarder le poteau, parce qu'il ne fait pas partie de l'équipe réseau, même s'il saurait faire le boulot. Mais, pas de panique, une personne habilité interviendra dans les 48h.

Le lendemain, ou le surlendemain (désolé, je commence à fatiguer), je reçois un SMS de SFR en me disant que le compte-rendu d'intervention est disponible sur mon espace client. Chouette! Le technicien réseau est passé et a réparé la panne. Je regarde mon espace client et je vois ceci :

Passée la déception de constater qu'il s'agissait de l'intervention du monsieur qui est venu chez moi et non pas de McGyver 🛠 habilité à intervenir sur le poteau, il y a eu une surprise. Je n'ai rien signé lors de la visite du technicien. Même pas un gribouillis avec le doigt sur une tablette. C'est sans doute à cause des gestes barrière pour me protéger, mais ça fait bizarre de n'avoir même pas été interrogé sur le fait que j'étais d'accord sur ce compte rendu. Je ne vais pas appeler la répression des fraudes pour un simple malentendu!

 1/23/2022, 11:37:28 AM 	 Dynamic Range Window violation 
 1/23/2022, 11:37:28 AM 	 Unicast Ranging Received Abort Response - Re-initializing MAC;... 
 1/23/2022, 12:57:00 PM 	 Dynamic Range Window violation 
 1/23/2022, 12:57:00 PM 	 Unicast Ranging Received Abort Response - Re-initializing MAC;...

Une relation humaine et respectueuse du client

Si on résume, on a :

1. un service technique qui propose un changement d'abonnement (plus cher) à chaque appel au lieu de résoudre le problème technique;
2. un technicien qui diagnostique un problème, mais qui n'a pas le droit d'intervenir;
3. une équipe réseau qui n'intervient pas et qui ne peut pas être contactée par le service technique;
4. un forum d'aide avec des Community Managers de SFR qui font des réponses (certifiées par SFR) dont l'utilité est douteuse.

Je ne sais pas juger s'il s'agit de mauvaise foi ou de simple incompétence. C'est peut-être une combinaison des deux, ou encore autre chose.

Je comprends bien que les personnes auxquelles j'ai eu à faire ne sont pas à la cause du problème, mais elles pourraient être à la source d'une solution. Il ne doit pas être agréable de se prendre en pleine figure la frustration des clients, dont certains sont sans doute méprisants (j'avoue avoir perdu patience au moins une fois).

Mais les travailleurs qui acceptent de se cantonner à répéter un script imposé ou un logigramme de questions-réponses risquent de se faire remplacer par des machines très rapidement.

C'est peut-être naïf de ma part, mais je pense qu'il serait sans doute plus utile pour les clients, mais aussi pour le bien-être au travail des employés en première ligne, de sortir des procédures inefficaces, prendre un peu d'initiative et trouver de vraies solutions.

En tout cas, le régime alimentaire que SFR veut m'imposer ne me convient pas. Et il est bien connu que l'excès de fibres produit des flatulences.

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 …

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.

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.