On y découvre le mode de fonctionnement de Facebook, ou comme le géant du web utilise la culture geek pour piloter ses développements. Ce que je note, c'est l'importance et la liberté données aux ingénieurs, et la contrepartie : l'engagement qu'on leur réclame.
Je vais tenter de résumer l'article en quelques lignes (en tout cas, les points qui on retenu mon attention...)
Cette liberté totale et le manque d'emprise des PM sur le projet est à contre courant de tout ce que j'ai pu rencontrer jusqu'ici :) D'un autre côté, avec un cycle de release très rapide, ça ne doit pas être aussi anarchique qu'on pourrait le croire a priori. Sur des projets de 6 mois évidemment ce serait ingérable, mais si on compte en jours ?
La contre-partie de cette très grande liberté est que les développeurs sont ici partie prenante du projet avec une très lourde responsabilité. Sans doute facilité par une connaissance de l'ensemble du SI et pas juste d'une brique isolée, les ingénieurs assurent le reporting, ils sont le contact direct pour toutes les questions relative au projet. Autrement dit, ils incarnent implicitement le rôle de PM. D'autre part, il y a le mardi.
Le mardi, c'est le jour de la mise en prod - oui, une par semaine, ça surprend toujours tant cette notion est lourde dans nos contextes traditionnels. Tout les développeurs qui ont introduit du code doivent être présents sur site et disponibles. Ne pas répondre aux demandes des Ops et/ou ne pas supporter un bug détecté dans son code est un motif de licenciement. Et avec 60.000 serveurs à mettre à jour, il doit y en avoir quelques unes des demandes de la part des Ops !
On rentre dans une logique différente, un esprit de responsabilité que la culture MOA/MOE, forfait, prestataire nous a fait perdre : on ne développe pas juste du code, on développe du code qui doit tourner en production. La logique DevOps semble particulièrement mise en pratique chez Facebook.
Pourrait-on appliquer cela ailleurs ?
Je vous vois venir, je ne parlerais pas de mon cas personnel. Par contre, globalement il y a des lessons à retenir :
- On ne motive pas des développeurs en les infantilisant. Les ingénieurs ont besoin de créer quelque chose, d'en être fier, et de le porter au yeux de leurs pairs. Arrêtons de leur affecter des tâches, de leur imposer des roadmaps à plusieurs mois. Evidemment, cela passe par un raccourcissement des cycles de production. Compter en mois (voir en années) cela impose une planification. Compter en semaines cela permet de tenter des choses, de laisser une part d'inconnu, d'expérimenter sans faire de gros frais.
- La culture DevOps a encore du chemin à faire. On ne crée pas de l'engagement en les mettant dans des silos. On pourra faire toute l'agilité qu'on veut, si le développeur n'est pas directement responsable des bugs constatés en production et du client qui gueule au bout du fil, il continura à délaisser sa stratégie de test pour passer à quelque chose de plus "intéressant".
Pour moi, le premier point à traiter est notre cycle de release. Il ne s'agit pas juste de créer tous les 30 jours un "logiciel potentiellement livrable" comme nous le suggère Scrum, il s'agit de mettre à l'épreuve toute notre chaine de production aussi souvent que possible. Le liens vers DevOps est alors évident et rapidement indispensable.
Comment vendre cette évolution à nos Managers ?
Un seul argument à vous proposer (je vous laisse trouver les vôtres) : combien de temps faut-il pour fournir une évolution ou un correctif sans désorganiser l'équipe (je ne parle donc pas du gros bug critique "stop the line") ? Avec un cycle tel que celui de Facebook, cela peut être juste une semaine, sans créer le moindre stress supplémentaire. Avec une approche traditionnelle, en 13 ans, je n'ai connu aucun projet qui faisait des mises en production à moins de quelques mois d'intervalle. Le time-to-market est le nerfs de la concurrence, et de ce point de vue tous les CMMi du monde n'ont rien à nous proposer.
(1) pour ceux qui en doutent, twitter est aussi un outil de veille technologique et de support. Comme tout réseau social, il peut porter des choses totalement futiles ou des infos pertinentes, le tout est de mettre en place les bon filtres.
5 commentaires:
Les avantages mis en valeur dans ton billet me paraissent pertinent... Mais pour moi qui suit en train de lutter pour intégrer des features Facebook sur un gros site, tout ne me semble pas si rose!
Toutes les fonctionnalités FB auquel j'ai touché (FB Connect, Pages, Graph API, Likes...) sont pleines de bugs et souvent incohérente (impossible de comprendre clairement les permissions entre application et admin d'une page par exemple). Pour les intégrateurs comme moi, c'est l'enfer et la doc comme le forum ne servent à rien. A tel point qu'on a effectivement l'impression d'une absence totale de specs... et qu'ils passent à une nouvelle techno quand c'est trop bugué pour être maintenu.
Difficile de dire où le bât blesse dans leur organisation : pas assez de tests, absence de specs, peu ou pas de maintenance/support... mais c'est certain que qq chose cloche. Et ils ont juste la chance d'être les rois du web en ce moment, sinon personne ne passerait du temps à décrypter le fonctionnement des outils qu'ils produisent!
Effectivement quand on lit ce genre d'articles, ça laisse réveurs/songeurs.
=>c'est la montée
Après on regarde son chef, ses collègues, son build Hudson encore cassé...
=>c'est la descente
Un point important à chaque fois: les ingénieurs sont "triés sur le volet" et j'ai souvent entendu dire que c'était hyper-select comme boite facebook.
Ensuite on parle souvent de "comment ça se passe", mais pas comment on mobilise les forces créatives des développeurs.
Et la recette suivante ne marche pas à tous les coups:
"si le développeur n'est pas directement responsable des bugs constatés en production et du client qui gueule au bout du fil..."
=> Gros risque de désengagement des personnes selon moi.
"Les ingénieurs ont besoin de créer quelque chose, d'en être fier..."
=> j'ai du mal à être convaincu sur ce point
Il faut une cultiver le goût du risque en amont et c'est là ou y a 1 manque de feedback, de retours d'expériences:
- comment sont gratifiés les dév qui ont proposé une fonction/mené un projet?
- Est-ce que le seul fait de le voir en prod suffit?
- Est-ce que la culture américaine suffit à expliquer tout ça?
- Certaines personnes fuient "consciemment" les responsabilités (pas de goût du risque) => comment les encourager
Y a t-il des "dessous" moins glorieux qu'on nous raconte moins?
En tout cas, billet intéressant. Je n'ai pas encore lu l'original, le blog étant HS. Peut-être l'effet de ton tweet :-)
@Thibuad "Gros risque de désengagement des personnes selon moi" disons que c'est quite ou double. Sois le développeur prend conscience de sa responsabilité et adhère à l'esprit DevOps, soit il se désengage et ... ira voir ailleurs
"Les ingénieurs ont besoin de créer quelque chose, d'en être fier" c'est en tout cas mon cas, ainsi que la majorité des gens que j'ai pu rencontrer lors des JUGs, maintenant ce ne sont eux-même qu'une minorité. En tout cas, l'opensource montre qu'il y a une attente de ce côté, et que la gratification se fait plutôt en termes d'ego que de salaire - l'un n'empêchant pas l'autre, pas vrai boss ;)
Un JUG leader que je connais bien m'a déjà dit que les gens qui viennent aux JUGs représente la "crème" des développeurs : des passionnés, curieux, intéressés par l'échange avec les pairs et peu attachés aux horaires de bureaux (quand on voit les horaires des sessions du Paris JUG...)
C'est comme ça qu'il attire les sponsors je crois :-)
Pour ma 'tite xp, nous on est un micro-éditeur pour l'instant mais on teste les principes de mise en prod régulière
Je pense que les principales source de motivation en entreprise sont:
(a) le salaire
(b) la reconnaissance des pairs
(c) le plaisir de faire des choses constructives
Il est dommage qu'à l'heure où les augmentations salariales tendent à être limitées, on a plutôt tendance à brider la hiérarchie technique (car elle est mieux valorisée que la hiérarchie managariale), et on est frileux face aux réseaux sociaux d'entreprise (alors que cela permettrait de mieux aggréger les compétences/bonnes volontés techniques, et de mieux structurer les gens de la technique face à la hiérarchie managariale, mais c'est peut être cela qui fait peur...).
Au final, cela laisse peu de motifs à se mettre sous la dent, quand on travaille dans la partie technique.
En France, Free, une boite technique, a fait la nique à France Télécom, une boite de managers... cherchez l'erreur !
Mais cela reste une exception.
Tiens, cela me rappelle aussi un billet lu récemment:
"Did the Microsoft Stack Kill MySpace?"
http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html
Au final, il ne semble pas que ce soit la stack Microsoft qui ait tué MySpace.
L'explication (lue dans ce billet) qui me semble la plus plausible est la suivante:
""
MySpace failed because the users left. The users (myself included) didn't leave because it was running on a Microsoft stack; we left because all MySpace was interested in was being a media company. People wanted a social network, and to this day that's more or less all Facebook is.
""
Ceci étant, après avoir lu la totalité de ce billet, il semble que le manque de compétences techniques du top-management MySpace n'ait pas aidé à la bonne gestion de la stack technique MySpace et à sa saine évolution.
Enregistrer un commentaire