Management et identifications


Avant de présenter une technique pour travailler sur les identifications, je vais vous décrire l’aspect pratique des identifications.
Plus exactement nous allons voir ce qui se passe dans la tête d’un responsable de projet.

Je suis responsable d’un projet

Je vais supposer qu’on vient de me nommer responsable d’un projet et qu’on m’a assigné une équipe.
Je veux donc prouver ma capacité à mener ce projet à bien.

Les identifications

La première identification est que j’ai plus de la valeur que les autres: ce n’est pas un hasard si on m’a choisi comme responsable.
Normalement, je ne peux jamais être certain de ma valeur parce que je n’ai pas de repère (à part le salaire).
Ici, le repère est clair et je peux clairement mesurer ce que je vaux.
Je veux me sentir spécial.

La seconde identification est que je dois absolument réussir alors je suis très motivé.
D’ailleurs je ne comprends pas trop pourquoi les membres de mon équipe ne sont pas aussi motivés que moi sur « mon » projet.
Je peux pourtant vous assurer que mon projet sera super !

La dernière identification est que je m’identifie à mon projet: ce projet représente ce que je suis et je suis quelqu’un qui réussit.

Ces 3 identifications semblent assez bénignes, mais je vais maintenant montrer leurs effets de bord.

Je suis le responsable, j’ai plus de valeur que les autres

Comme je suis le responsable, je veux prendre toutes les responsabilités du projet, je veux avoir mon mot à dire sur tout.
Comme cela, je suis certain que mon projet réusssira, c’est mathématique !
Mais en réalité, plus je m’accapare les responsabilités, plus les autres se sentent déresponsabilisés et finissent par ne plus rien décider par eux-mêmes. Ils réaliseront rapidement que ce projet va être un long calvaire.
Comme je suis le plus qualifié, je veux tout contrôler et donc je ne laisse aucune liberté aux autres, surtout pas la liberté de faire des erreurs.
J’appelle cette approche « le management de 1914 »: je veux que les soldats obéissent à tous mes ordres (y compris le sacrifice personnel), alors je n’hésiterai pas à fusiller ceux qui se rebellent.
D’ailleurs, je me rends compte que plus personne ne fait rien quand je ne suis pas là, quels fainéants ! Cela prouve bien que je dois être derrière eux tout le temps.
Mais en réalité, je peux être complètement débordé par l’ampleur des décisions, et cela peut retarder mon équipe qui attend mes ordres.

Un autre cas est quand je rentre en conflit avec un autre responsable sur mon projet.
Quoi ? Il ne voit pas les choses comme moi, c’est donc un nul, ou alors cela signifie qu’il remet ma valeur en cause, le salaud !

Je dois absolument réussir

Comme je dois réussir, mon projet est plus important que mon équipe et que moi-même.
Je suis prêt à ruiner ma santé pour réussir.
Je peux perdre toute mon équipe à la fin du projet, je m’en fous du moment que le projet soit fini.
Je vais aussi préférer défendre mon projet plutôt que mon équipe, de toutes façons, je peux les remplacer facilement.

Comme je dois absolument réussir, je dois forcer les autres à être le plus productif possible.
Si en plus je suis un expert, je sais mieux qu’eux comment faire, alors je vais décider à leur place.
Mais en réalité, ma façon de faire, qui me convient très bien, ne convient pas forcément aux autres.
De plus, comme je leur impose tout, ils se limitent à faire ce que j’ordonne et cessent d’être créatifs.

Si je vois que les forcer ne fonctionne pas, je peux être tenté de les motiver financièrement.
La motivation financière fonctionne bien quand la qualité n’est pas importante.
Par exemple, si on me propose une prime pour finir à une date donnée, je ne vais pas hésiter à bâcler pour toucher le pognon.

Enfin, l’obsession de la réussite me fait négliger les signaux avant-coureurs d’échec.
Comme je refuse l’éventualité d’un échec, le retour à la réalité risque d’être douloureux.

Je m’identifie à mon projet

Cette identification est de loin la plus douloureuse, parce qu’elle touche à ma propre image de moi.
Si mon projet va bien, je vais bien. Si mon projet va mal, je vais mal.
Dès qu’il y a un problème, je sur-réagis parce que je me sens concerné personnellement.
Si quelqu’un critique mon projet, je me sens agressé personnellement.
Et si par malheur mon projet échoue, je me sens comme la dernière des merdes ou alors je peux considérer qu’il a échoué à cause de mon équipe de nullards.

Comment faire ?

L’approche agile est simplement du bon sens.
Le point de vue est le suivant:

  1. je ne suis pas supérieur aux autres: comment laisser les autres décider de la façon dont ils peuvent réaliser mon projet ? Comment prendre en compte leur point de vue ? Et comment m’assurer que nous allons tous dans la même direction ?
  2. j’ai le droit d’échouer: comment faire en sorte que les erreurs restent petites ?
  3. je ne suis pas mon projet: comment rendre chaque membre de l’équipe plus responsable ?

Conclusion

Je tiens à rappeler que le processus d’identification est un processus naturel.
Chacun de nous y est sujet tout le temps, et cela ne pose pas de problème tant que nous n’en sommes pas dupe, ce qui n’arrive que très rarement.

Tant que je m’accroche à une identification, je vais souffrir parce que la réalité est différente de ce que j’imagine et en plus elle change tout le temps.
Qu’est-ce qui est définitif en fin de compte ?

Publicités

Les Leçons du jeu vidéo (6ème partie)


Suite de l’épisode précédent:
https://psychologieagile.wordpress.com/2014/02/14/les-lecons-du-jeu-video-5eme-partie/

Résumé: je viens de quitter PAM pour rejoindre le Comptoir des Planètes.

Leçon numéro 1: un jeu vidéo, c’est avant tout une aventure humaine

Pour travailler au Comptoir des Planètes, j’avais accepté une baisse de salaire.
En fait, j’avais rejoint le Comptoir des Planètes avant tout pour l’équipe:

Didier Bouchon

C’est l’auteur de l’Arche du Capitaine Blood.
C’est un vrai créatif très timide, et qui manifeste sa créativité en programmant.
A vrai dire, je crois qu’il est d’origine extra-terrestre.

Marcello Morra

Marcello est l’exact opposé de Didier au niveau du caractère.
Autant Didier rêve, autant Marcello a les pieds sur terre.
Je crois que c’est la personne la plus généreuse que j’ai jamais croisée dans ma vie.

Philippe Arbogast

Encore un extra-terrestre, qui est un animateur hors pair. Coucou Pilou !

Sébastien Guilbert

Un graphiste 3D qui a une vraie personnalité.

Avec le recul, je pense que tout projet informatique est avant tout une aventure humaine.
Je suis toujours surpris de voir qu’il y ait une telle obsession sur l’organisation plutôt que sur l’humain.

Leçon numéro 2: je deviens efficace quand je trouve du sens à mon travail

Le jeu que nous faisions s’appellait Trucks, et c’était une course de trucks dans un univers déjanté.
Très honnêtement, je me foutais pas mal du jeu.
Voici une petite vidéo du jeu:

N’étant pas particulièrement intéressé par la 3D, j’étais là pour travailler sur tout le reste.
J’ai donc programmé les outils de debugging, toute la partie sonore, l’intelligence artificielle du jeu et le gestionnaire de mémoire.

Mais le gros de mon travail était de centraliser le travail de chacun.
En effet, tout le monde programmait dans son coin (nous n’utilisions pas de gestionnaire de versions en 1995), et je rassemblais le code pour que tout fonctionne ensemble.
Pas si facile quand tout change tout le temps et quand de nouveaux bugs se révélaient après regroupement.

Le pire souvenir que j’ai de cette époque était un bug mystérieux quand on jouait en réseau: les positions des véhicules se décalaient légèrement lors des collisions, ce qui désynchronisait le jeu.
J’ai analysé le problème et découvert que nous utilisions des Pentium qui faisaient des erreurs de division en virgule flottante.
Cela m’a demandé une semaine d’efforts !

Leçon numéro 3: je fais des jeux pour moi avant tout

Ce que j’avais à faire peut sembler peu excitant, mais le rôle que j’avais pris me satisfaisait.
J’avais 3 axes de satisfaction:

  1. j’étais utile: mon travail permettait à des individus de collaborer
  2. j’étais apprécié: j’aimais les gens avec qui je travaillais
  3. je voulais évoluer: mon travail de psychanalyse commençait à porter ses fruits, et je pratiquais la sophrologie assidûment

Leçon numéro 4: un jeu vidéo doit être jouable

Le problème majeur de Trucks est qu’il était construit sur un univers décalé, ce qui avait fait le succès de l’Arche du Capitaine Blood, mais il n’y avait pas grand chose d’autre.
C’était un jeu d’action, mais il n’y avait pas de réflexion sur la jouabilité.
La jouabilité, c’est l’ingrédient mystérieux qui fait qu’on prend plaisir à jouer.
Chacun de nous mettait en place des éléments de jouabilité, mais cela ne rendait pas le jeu amusant pour autant.

Après toutes ces années, je ne suis pas certain qu’il y ait une formule magique qui rendrait un jeu amusant, à part peut-être jouer au jeu encore et encore, en essayant de l’améliorer progressivement.

Leçon numéro 5: le facteur de réussite le plus important est la chance

Pourquoi Trucks n’est-il pas devenu un jeu culte ?

En réalité, nous avons raté le coche à plusieurs moments.

  1. si Trucks n’avait pas été un jeu d’action, il aurait probablement trouvé son public grâce à son univers particulier.
  2. l’éditeur Microfolies qui nous finançait n’était qu’un petit acteur en France.
    Trucks était probablement leur meilleur jeu, mais je pense que cet éditeur n’avait pas les moyens de ses ambitions.
  3. Microsoft cherchait à cette époque des jeux pour promouvoir Windows 95 et DirectX 3 qui venaient juste de sortir.
    Je pense que Didier et Marcello ont eu peur de vendre leur âme à Microsoft, donc nous sommes restés sous DOS en VESA.

Leçon numéro 6: j’ai enfin une vie en dehors de mon travail

C’est à cette époque que j’ai croisé ma future femme, sur Minitel !
J’étais complètement coincé sexuellement.
Grâce à la remise en cause de toute ma façon de penser, j’ai pu enfin libérer ma sexualité.
Du coup, j’ai arrêté la psychanalyse, parce que ça ne faisait qu’encourager mes tendances à trop penser.

Leçon numéro 7: je découvre Internet

En 1996, j’ai découvert l’Internet grâce aux mathématiques.
A l’époque, j’étais passionné par les mathématiques, et notamment les équations diophantiennes.
Je calculais depuis de nombreuses années avec mes propres algorithmes, et j’étais stupéfait d’apprendre que certains individus avaient trouvé quelques résultats meilleurs que les miens !
J’étais surtout content de trouver des individus qui partageaient mes intérêts uniques.

Leçon numéro 8: je m’améliore en anglais

C’est à ce moment que j’ai commencé à échanger avec des correspondants en anglais, pratiquement tous les jours.
Mon anglais était assez minable au début, mais après quelques années, je suis devenu assez bon.
Maintenant, mon anglais écrit est excellent, mais mon anglais parlé est tout pourri par manque de pratique.

Conclusion

Malgré mon investissement personnel, comme il n’y avait plus d’argent pour aller jusqu’au bout du projet, j’ai été licencié.
J’imagine que Marcello et Didier s’imaginaient que je trouverais facilement du travail ailleurs.
En fait, j’ai continué à travailler avec eux jusqu’à la sortie du jeu.
Mais ma situation financière était devenue catastrophique, et j’ai dû emménager chez ma copine.

Le Comptoir a été pour moi la première expérience de libération de ma personnalité dans le cadre professionnel.
Je reparlerai plus longuement de ce thème dans mes prochains articles.

15 ans plus tard, j’ai croisé Pierre Dumas, qui avait été le producteur de Trucks, et il a été stupéfait de voir à quel point j’avais changé en profondeur.

Les Leçons du jeu vidéo (4ème partie)


Voici le quatrième épisode de mes aventures dans le jeu vidéo, et comme d’habitude les leçons que j’en ai tirées.
L’épisode précédent est ici: https://psychologieagile.wordpress.com/2013/08/25/les-lecons-du-jeu-video-3eme-partie/

Récapitulatif

Après avoir fait quelques jeux à Ocean Software France, cette société a fermé, et je me suis retrouvé au chômage.
Le chômage était commun entre 2 emplois dans le jeu vidéo.

Les relations

A cette époque, un de mes seuls amis était Pascal de France.
C’était un démomaker perfectionniste, c’est à dire qu’il ne sortait rien parce que ce n’était jamais assez parfait.
Il connaissait pas mal de monde, et il m’a dirigé vers Nicolas Choukroun qui cherchait un développeur sur Super Nintendo.
La Super Nintendo, c’est un processeur 65C816, qui ressemble beaucoup au 6502, processeur sur lequel je suis un expert.

Nicolas Choukroun travaillait avec Laurent Cluzel (avec qui j’avais travaillé à Titus) sur la maquette du jeu Trashman, et avait signé avec Electronic Arts pour sortir Trashman avec Cryo.

Cryo

En 1992, Cryo venait d’être récemment créée, avec tous les membres d’Exxos (Rémi Herbulot, Philippe Ulrich, Didier Bouchon, parmi d’autres).
Au moment où je suis entré, cette société se développait à un rythme incroyable.
Il devait y avoir moins de 50 personnes quand je suis entré, et plus de 200 quand je suis parti.

Trashman

Techniquement, j’avais mis en place un moteur de jeu assez impressionnant pour ce jeu.
Il y avait des scènes cinématiques pendant le jeu, mais à fortiori, je pense que ça cassait trop le rythme du jeu.
Le gros problème est qu’il n’y avait pas de gameplay, parce que je passais mon temps à résoudre les problèmes techniques que ce jeu proposait.
Electronic Arts insistait beaucoup sur les milestones.
Je me souviens que les managers d’EA étaient venus en France pour valider une milestone, et j’avais démontré que techniquement tout était prêt, mais cela ne les a pas empêché d’arrêter le jeu.

Il n’y a rien de plus démoralisant que d’arrêter un jeu

Quel gâchis !

Et là, tout s’est effondré intérieurement pour moi.
J’allais mal depuis quelque temps déjà, suite aux efforts que j’avais fournis chez Titus et Ocean, au manque de vacances depuis des années et aussi parce que j’étais seul (je n’avais aucune relation intime à cette époque).
J’étais hyper-stressé et je ne m’en rendais pas compte.
Je m’identifiais totalement à mon rôle de finisseur de jeux: je menais mes projets à leur finition, et j’en étais fier.
Quand le jeu a été arrêté, j’ai fait un burn-out complet.
Je ne pouvais plus rien programmer sans des efforts incroyables.

Quand tout va mal, je ne dois pas hésiter à demander de l’aide

Je me suis retrouvé tout seul au fond de mon trou.
A ce moment-là, j’ai compris très clairement que je ne pourrais pas m’en sortir seul.
Comme je ne voulais pas me suicider, je suis allé voir un psychanalyste (ma mère disait: c’est pour les fous), je crois en juillet 1993.
Le psy m’a dit qu’il ne pouvait pas me prendre avant septembre, et je ne sais pas comment j’ai pu tenir 2 mois.

J’apprends à découvrir mon fonctionnement intérieur

Dès mes premières séances, la barre au niveau de mon diaphragme (indicateur de stress) a complètement disparu, et j’ai commencé à me sentir léger.
J’ai aussi compris que si je voulais m’en sortir, je devais changer complètement et que parler ne servirait à rien si je n’agissais pas dans ma vie.
A ce moment-là, j’avais tellement de problèmes que je devais déjà commencer à résoudre les plus simples, c’est à dire mes interactions avec les gens.

La psychanalyse m’a apporté 2 choses essentielles:

  1. j’ai appris à exprimer mes états intérieurs: je suis capable de décrire toutes mes émotions avec des mots
  2. j’ai commencé à découvrir mon fonctionnement intérieur: je croyais que je me connaissais bien, et j’ai réalisé que mon image intérieure et mon image extérieure étaient complètement différentes

Avec le recul, je suis sorti du burn-out quand j’ai accepté de faire le deuil de ma vision du travail.
Je pensais que ma seule valeur était celle de mon travail, et donc que je devais programmer beaucoup pour montrer ma valeur.
J’ai dû réapprendre à travailler avec plaisir, et ce n’est que tout récemment que j’ai accepté d’être enfin bienveillant envers moi-même.

Je ne vais pas trop m’étendre sur ma psychanalyse, parce qu’elle ne concerne pas le jeu vidéo, mais j’y reviendrai peut-être dans de futurs articles.

Je programme beaucoup mais…

Chez Cryo, j’ai bossé sur pas mal de jeux, exclusivement sur consoles Super Nintendo et Mega-CD.

Le jeu que je préfère de cette période est Super Dany (de Danone), que j’ai coprogrammé avec Pierre-Eric Loriaux (ex d’Ocean Sotfware, Michel Janicki avait aussi rejoint Cryo).
Pierre-Eric avait fait le jeu principal, et j’avais fait tout le reste (présentation, intermèdes -c’étaient des démos- et même un jeu en intermède).
Nous avons eu l’occasion de présenter le jeu à des enfants de journalistes, avec Cyrille Drevet, et ce fut globalement une belle expérience, même si le jeu n’est pas terrible.

J’ai aussi bossé sur Timecop, l’adaptation d’un film avec Jean-Claude Van Damme, et nous avons eu l’occasion d’aller voir le film en avant-première.
Pour Timecop, j’ai travaillé sur la version Super Nintendo avec Fabien Fessard, qui m’admirait parce qu’il m’avait croisé à la Transbeauce.
Je me souviens des nuits passées à convertir la musique faite par David de Gruttola (David Cage) sur le SPC700. Le SPC700 avait seulement 64 kilooctets de RAM, et je devais convertir des samples de plusieurs mégaoctets. A la fin, tous les instruments ressemblaient à des cymbales !

Pour Timecop sur Mega-CD, j’étais le lead-coder, et un jeune stagiaire du nom de Bruno Galet était le manager. Il est maintenant producer chez Ubisoft.
Timecop n’est jamais sorti sur Mega-CD non plus, alors qu’il était fini.

Je ne supporte plus que mes jeux ne sortent pas

Chez Cryo, la moitié de mes projets n’étaient pas sortis, alors j’ai décidé qu’il était temps de changer d’air.

Conclusion

Cryo a été pour moi une renaissance.
Cela faisait déjà 10 ans que je programmais des jeux, j’étais devenu un expert.
Suite à l’effondrement complet de mon modèle intérieur de travail, j’ai décidé de me focaliser sur autre chose que le travail et la technique: j’ai commencé à essayer de comprendre ce que je suis et pourquoi j’agis ainsi.

J’ai croisé à Cryo de très nombreux talents, et comme je me reconstruisais, je considère tous ces gens comme des membres de ma famille.

Merci Cryo !

Les Leçons du jeu vidéo (3ème partie)


Voici le troisième épisode de mes aventures dans le jeu vidéo, et surtout les leçons que j’en ai tirées.
L’épisode précédent est ici: https://psychologieagile.wordpress.com/2013/08/04/les-lecons-du-jeu-video-2eme-partie/

Récapitulatif

Après avoir été exploité comme un esclave chez Titus, jusqu’à me dégoûter de programmer, j’ai tenté sans succès de fonder une société avec Philippe Pamart.
J’ai retrouvé le plaisir de programmer en réalisant des démos.
Mais il fallait que je retrouve du travail, parce que les démos, c’est bien gentil, mais ça ne fait pas gagner d’argent.

Ocean Software France

A cette époque, Marc Djan, le patron d’Ocean Software France, cherchait un développeur sur Atari ST pour finir le jeu Ivanhoé (le programmeur original étant parti faire son service militaire en Volontaire Service Long Outre-Mer sans finir le jeu !).
Ivanhoé était un jeu magnifique graphiquement, mais il fallait le sortir rapidement.

J’ai été embauché pour corriger les bugs, vu qu’on n’avait plus le temps d’ajouter quoi que ce soit.
Deux niveaux complets graphiquement ont disparu, parce qu’ils n’avaient pas été programmés.
Je me souviens d’un bug de folie découvert par nos testeurs anglais: au niveau 2, quand on sautait sur place pendant 3 minutes lorsqu’on était à gauche du niveau (sur le mât du bateau), le personnage finissait par tomber de manière infinie, et le jeu se bloquait.
J’ignore comment les testeurs ont trouvé cela, mais je me souviens d’une anecdote sur les testeurs de jeux: les meilleurs testeurs sont des malchanceux dans la vie, ils tombent toujours sur des problèmes, même sans les chercher. J’ai entendu parler d’un testeur qui était excellent à cause de sa poisse: il était capable de planter un jeu en 5 minutes.

Mon travail sur Ivanhoé a été surtout de finir le produit, ce que j’ai réussi sans trop de problème, c’était ma spécialité à l’époque !

Après Ivanhoé, j’ai converti Cabal sur ST en un mois, ce qui était un exploit chez Ocean (habitués à passer pas mal de temps à fignoler leurs jeux).

J’apprends à travailler en équipe

Après Cabal, j’ai travaillé sur Toki.

Curieusement, jusqu’à présent, je travaillais seul sur les jeux que je faisais, et pour moi, la programmation était une activité solitaire.
Sur Toki, j’ai dû travailler avec Michel Janicki et Pierre-Eric Loriaux.
Pierre-Eric était graphiste, programmeur et musicien et avait écrit son propre éditeur de musique sur Amiga.
Je l’ai converti sur ST afin d’utiliser au maximum les maigres capacités sonores de cette machine.

Je me souviens que nous utilisions des outils d’édition graphique qui tournaient sur Atari ST.
Les graphistes utilisaient une borne d’arcade sur laquelle ils avaient bricolé un bouton de pause. Quand ils arrivaient à l’image qu’ils voulaient, ils mettaient en pause et redessinaient l’image avec l’éditeur maison.
Parfois, la pause plantait la borne d’arcade, et il y avait un grand cri: ils devaient recommencer le jeu du début pour arriver à l’endroit concerné.
Encore bravo à Philippe Dessoly et Thierry Levastre pour leur patience !

Pour faire un bon jeu, je dois y jouer

Michel Janicki n’était pas un programmeur obsédé par la technique, mais il avait une approche nouvelle pour moi: il passait beaucoup de temps à jouer à son jeu, afin de le régler parfaitement.
Moi qui venait de chez Titus, où on bâclait pour finir les jeux, j’étais très impressionné que quelqu’un puisse passer autant de temps à régler le gameplay.
Par exemple, il programmait un comportement d’ennemi, et ensuite, il jouait des heures pour trouver le réglage parfait.
Je n’ai jamais croisé personne passant autant de temps sur ce réglage.

Toutefois, il avait un avantage: il programmait sur Amiga, alors que j’étais sur Atari ST.
Sur Atari ST, il fallait tout faire par programme en assembleur 68000: affichage, intelligence, musique, etc…
Sur Amiga, il y avait le même processeur 68000, mais aussi un processeur graphique performant et une puce sonore sans commune mesure avec le ST.
En fait, je passais mon temps à optimiser le code parce que l’affichage était fait en software sur ST alors que c’était fait en hardware sur l’Amiga.
Le focus sur ST était uniquement technique, alors que sur Amiga, on pouvait se permettre d’être créatif.

Je partage dans un esprit de compétition saine

Ces contraintes techniques ont notamment créé un certain esprit de compétition entre les programmeurs Amiga (Michel Janicki et Pierre Adane) et ST (Alain Boisramé et moi-même).
C’était vraiment une saine compétition qui tirait tout le monde vers le haut, je pense que tout le monde a profité de ce brassage de « culture ».
Le programmeur qui a le plus profité de cette compétition est probablement Pierre Adane, qui a réussi à allier l’esprit « qualité du code » à l’esprit « qualité du gameplay », ça lui a été utile pour faire Mister Nutz par la suite.

Toki, ma plus grande réussite

Toki est ma plus grande réussite chez Ocean, tout d’abord parce que j’ai bossé sur les aspects techniques tandis que Michel Janicki faisait le gameplay, et ensuite parce que les routines d’affichage des sprites m’avaient demandé 2 ans de travail: j’avais découvert une nouvelle technique pour aller 2 fois plus vite que ce qui était connu.

A propos de Toki, je me souviens que des amis avaient proposé une protection, mais qu’elle n’avait pas été retenue, à cause de problèmes de duplication.
Je me souviens aussi qu’une fois la protection Rob Northen mise en place, le jeu plantait.
Il a fallu que je cracke moi-même la protection pour découvrir les problèmes (à cause du format spécial de la disquette, il fallait déplacer la tête de lecture au tout début de la disquette pour que ça fonctionne, et la protection utilisait des compteurs système, que je faisais sauter avec mon programme, il a fallu les émuler).
Cracker cette protection m’a pris une demie-journée, mais je savais que mon programme ne serait pas aussi facile à copier, parce que j’avais fait un format de disque spécial, un loader spécial, etc…
Si vous avez Toki sur un émulateur ST, tapez les cheats suivants: POORTOKI pour les vies infinies, THEEND pour voir la fin (je porte une casquette avec des nichons à la fin du jeu).

La fin d’Ocean France

Enfin, le dernier jeu que j’ai fait pour Ocean est Snow Bros sur Atari ST, une conversion de la version Amiga programmée par Pierre Adane.
Malheureusement, le jeu n’est pas sorti (les droits n’avaient pas été achetés) mais il était fini sur les 2 supports.
Sur ST, j’avais fait sauter la bordure du bas, et le jeu était en 25 images/seconde, alors que sur Amiga, il était en 50 images/seconde.

Après cela, Ocean France a fermé (je viens de lire qu’il avait été racheté par Infogrames ??).
J’ai appris par la suite que les autres développeurs avaient été repris en indépendants (notamment pour faire Mister Nutz et Liquid Kids), j’ignore toujours pourquoi je n’ai pas été repris, mais je suis passé à autre chose: Cryo.

Conclusion

Le focus d’Ocean France était sur la qualité, ce qui est rare pour une société.
Presque tous les gens que j’ai croisés à cette époque (1990-1991) travaillent encore dans le jeu vidéo, ce qui prouve que ce fût une excellente école, peut-être aussi parce que nous étions peu nombreux et qu’il y avait un esprit de partage.

Psychologie de groupe


Je n’aime pas du tout la tendance actuelle qui est de considérer une équipe comme une entité à part entière, comme si l’individu disparaissait devant l’équipe.

Aussi, je vais vous expliquer les ressorts psychologiques dans une équipe.
Cela devrait vous aider à mieux comprendre la diversité des individus et comment ils fonctionnent.

L’équipe

Une équipe, c’est tout d’abord un ensemble d’individus.
Cet ensemble devient une équipe à partir du moment où ses membres partagent un but commun.

Comment comprendre une équipe ?

Je ne peux pas comprendre une équipe sans connaître les attentes de chacun de ces individus.
Quand j’observe une équipe, je vois avant tout des individus, qui sont tous pilotés par leurs propres désirs.
Je vais vous décrire les mécanismes très simples qui pilotent ces individus.
Ils sont de deux ordres: la recherche de valeur intérieure et la recherche de valeur extérieure.

La recherche de valeur intérieure

En tant que membre d’une équipe, je veux sentir que je fais partie de l’équipe.
Si le groupe m’accepte, alors je peux facilement confirmer que j’ai une vraie valeur intérieure: je ne suis ni détesté ni ignoré !
Pour rappel, l’ordre de préférence est:

amour > haine > indifférence

Comme je veux être accepté par l’équipe, je vais faire tout mon possible pour m’intégrer.
Cela peut inclure toutes les nuances entre le fait d’être simplement moi-même ou à l’opposé jouer un rôle plus ou moins facile à tenir.

La recherche de valeur extérieure

En tant que membre d’une équipe, je veux montrer que je suis utile au groupe.
Si le groupe apprécie ce que je fais, alors je peux facilement confirmer que j’ai une vraie valeur extérieure: je ne suis pas inutile !

Comme je veux montrer mon utilité, je vais tout faire pour démontrer ma compétence, quitte à cacher mes incompétences.

En cas de rejet

Quand je suis rejeté par un groupe, je sens tout de suite que ma valeur intérieure ou extérieure est remise en cause.
Comme j’ai basé pas mal de mon identification sur cette valeur, je vais énormément souffrir, pas tellement à cause du rejet, mais bien à cause de la négation de mon propre repère de valeur.
Si le groupe ne voit pas ma valeur intérieure (ma personnalité), alors je vais me sentir détesté.
Si le groupe ne voit pas ma valeur extérieure (ma compétence), alors je vais me sentir inutile et nul.
En cas de rejet, je ne vaux plus rien !

Quelques comportements

Curieusement, ce modèle super simple décrit absolument tous nos comportements dans un groupe.

En voici quelques uns:

  • je suis hyper sociable: j’essaye à tout prix de m’intégrer, même si je n’apporte rien d’utile au groupe. Je fais semblant d’être débordé de travail, l’essentiel est de bien tenir mon rôle.
  • je suis hyper compétent: j’essaye à tout prix de me montrer utile, même si je me fiche des relations humaines. Je préfère être détesté qu’ignoré. Je vois bien que je suis le meilleur de mon équipe. Si quelqu’un de plus fort que moi apparaît, je vais me sentir mal.
  • je suis compétent et sociable: je veux montrer que je suis à la fois très intégré et très utile. J’aime beaucoup l’idée d’être parfait, même si cela me demande beaucoup d’efforts. Je carbure pas mal au café et à la clope, afin de tenir le coup. Je vis pour mon travail.
  • je suis équilibré: j’essaye d’être à la fois compétent et sociable sans excès, cela renforce l’idée que je me fais de l’équilibre. Je suis quelqu’un de « normal », ce qui confirme que je ne suis pas fou.
  • je suis une merde: si j’ai une vision négative de moi-même, me sentir rejeté et inutile va me confirmer ma propre opinion négative. Je me complais dans cette image de moi-même et j’aime me mettre en échec, surtout par habitude.

Pourquoi j’agis ainsi ?

Chacun a son réglage unique de paramètres entre les extrêmes de la valeur extérieure et de la valeur intérieure.
En fait, ce réglage vient de notre enfance, des premiers modèles de valeur que notre éducation nous a appris.

Dans mon cas personnel, mes parents ont toujours insisté sur le côté utile, et jamais sur le côté sociable.
Ce qui fait que j’ai toujours privilégié la compétence par rapport à l’intégration.
Je pensais même que moins j’étais intégré, et plus cela montrait que j’étais compétent !

Ce réglage change tout le temps, en fonction de ma perception du groupe où je me trouve: est-ce que je reconnais un modèle familial ou un autre modèle ? En fonction de ma perception, je change d’attitude.

Comment corriger ces schémas dysfonctionnels ?

Personnellement, j’ai réussi à me reprogrammer entièrement, mais malheureusement il n’existe pas de méthode simple.
Je vais quand même vous décrire comment je m’y suis pris.

J’essaye d’être moi-même

Cela demande une bonne dose de courage, mais j’essaye toujours d’être le plus honnête possible envers moi-même.
Cela implique de faire tomber tous mes masques, d’avouer mes propres lacunes aux autres et d’admettre ma propre « nullité ».

Etre honnête avec soi-même s’apprend auprès des autres. La technique la plus simple est de consulter un psy ou d’avoir un confident proche, et surtout de ne rien lui cacher.
Un carnet de confidences fonctionne tout aussi bien, l’essentiel étant d’apprendre à exprimer ses propres limites, sans rien chercher à corriger.

Je laisse tomber tout système de valeurs

Malheureusement, tant que je cherche à mesurer ma valeur, je ne peux pas sortir de ces limitations.
Je dirais même que la maturité n’est arrivée que quand j’ai abandonné l’idée de m’intégrer ou de me montrer compétent.

Cet abandon intérieur surgit suite à une prise de conscience profonde, bien au delà des mots.
Malheureusement, personne ne peut vraiment nous aider à ce niveau-là, mais la vie nous pousse dans cette direction.
Tout dépend du degré de résistance de chacun à la réalité: plus on s’accrochera à sa valeur et à sa situation actuelles, plus on souffrira.

Conclusion

J’ai décrit quelques-uns des comportements dans un groupe, et vous ai expliqué comment ils se mettaient en place.

Maintenant, c’est à vous:

percevez-vous comment vous vous comportez dans chacun des groupes que vous fréquentez ?

Regardez vos modèles de l’enfance et comparez-les avec vos comportements actuels.

Ne cherchez pas à changer ! Soyez simplement le témoin de vos comportements, qui ne sont ni bons ni mauvais.
La simple acceptation de vos comportements (aussi culpabilisants soient-ils) fera que vous changerez naturellement et sans effort.

L’Expérience Hawthorne


Après les effets Zeigarnik et Ringelmann, je vais vous présenter l’effet Hawthorne, qui est un effet de motivation.

L’expérimentation Hawthorne

De 1927 à 1932, le professeur Elton Mayo a étudié la productivité des ouvrières dans l’usine Hawthorne de relais de téléphone.
Il a essayé de déterminer de manière exhaustive quels étaient les facteurs pouvant améliorer la productivité.

La légende dit qu’il a augmenté la luminosité des ateliers et a noté une amélioration de la productivité.
Puis en baissant la luminosité, il a constaté que la productivité ne baissait pas.
Il a donc expliqué que la productivité a augmenté parce que les ouvrières savaient qu’elles participaient à une expérience et étaient donc plus motivées.

La page Wikipedia donne plus de détails: http://fr.wikipedia.org/wiki/Effet_Hawthorne
Et la page anglaise est encore mieux: http://en.wikipedia.org/wiki/Hawthorne_effect

En fait, cet effet est au centre d’une polémique, parce que les chercheurs ne sont pas d’accord sur les conclusions, ni sur l’existence de cet effet.
Personnellement, je pense que le professeur Mayo s’est trompé. En faisant un mauvais jeu de mots, je dirais que sa conclusion est mal tournée.
Je vais vous expliquer ce qui se passe selon moi.

L’expérimentation revue sous l’angle des sexes

Il faut comprendre que les individus ont des attentes différentes en fonction de leur sexe.
Dans son livre « Les hommes viennent de Mars et les femmes viennent de Vénus », John Gray explique que:

  • les femmes veulent de l’attention
  • les hommes veulent de la confiance

J’appelle ces deux attentes des « motivateurs intrinsèques », mais il s’agit en fait de composantes de l’ego.

Comme l’expérience originale a eu lieu avec des femmes, il me paraît évident que l’expérimentateur a donné de l’attention aux employées, alors elles se sont senties plus motivées.

Sur un public masculin, je pense que de donner de la confiance est plus efficace que donner de l’attention.

Plus exactement, chaque individu est composé d’un pourcentage de masculinité et de féminité. Par exemple, je suis à 60% masculin et à 40% féminin.
Ma partie masculine veut de la confiance, alors que ma partie féminine veut de l’attention.

Et l’agilité dans tout cela ?

L’agilité utilise abondamment ces 2 puissants motivateurs intrinsèques !

L’auto-organisation et le planning poker agissent sur la confiance. Je montre que je fais confiance aux individus (mais pas trop quand même, parce que je vérifie le résultat au fur et à mesure).
Le feedback, le Daily Meeting et la rétrospective agissent sur l’attention, en montrant que je me préoccupe des attentes des individus.

Au niveau des jeux agiles, d’autres facteurs sont en jeu, j’en reparlerai lorsque j’aborderai la notion d’ego.

J’insiste encore une fois: la confiance et l’attention doivent être sincères.
Si je ne suis pas honnête, les individus vont très vite comprendre que je joue un jeu et je perdrai toute crédibilité, même si je suis le meilleur acteur du monde.

Conclusion

Finalement, j’ai parlé plus du livre de Gray que de l’effet Hawthorne, mais je voulais vous expliquer comment le sexe des individus déterminait une grosse partie de la motivation intrinsèque.
L’effet Hawthorne est simplement d’augmenter la motivation en donnant de l’attention.
Cela fonctionne bien avec les femmes.

Je tiens à signaler que donner de l’attention demande beaucoup d’énergie, parce que l’attente des individus augmente: chacun en veut toujours plus !
C’est ce qui explique pourquoi l’effet Hawthorne n’est pas durable dans le temps.

Pour les hommes, il vaut mieux donner de la confiance. L’absence de confiance est difficile à supporter.

Tout ceci explique pourquoi la majorité des managers ne savent gérer qu’un seul sexe.

Enfin, si vous êtes coach agile, vous devriez maintenant avoir compris que vous avez un biais cognitif en fonction de votre sexe.

La Programmation Informatique


Aujourd’hui, je vais vous parler de programmation, ou plus exactement, je vais expliquer pourquoi je n’aborde pas la programmation sur ce blog.

Récemment, un journaliste de Pix’n Love m’a demandé d’écrire un article sur mon expérience dans le jeu vidéo.
J’ai été programmeur de jeux vidéos de 1985 à 2003, et j’ai travaillé dans plus d’une dizaine de sociétés. Dans l’article que j’ai écrit, je décris les 28 plus grandes leçons humaines que j’ai retenues, je ferai probablement un post sur ces 28 leçons après la parution du magazine.

Mon histoire personnelle

Quand j’étais petit, je m’ennuyais profondément à l’école. Je n’avais pas de challenge intellectuel intéressant à résoudre (j’étais probablement un enfant surdoué).

A 14 ans, j’ai découvert par hasard les mathématiques. Non, pas à l’école, mais en lisant un livre de Martin Gardner, je crois qu’il s’agit de Jeux Mathématiques. Enfin, j’avais des challenges intéressants à résoudre, des problèmes dont la solution n’était pas connue !

La première conséquence de cette découverte fût que je suis devenu le meilleur de ma classe en mathématiques en moins d’un mois.
La seconde conséquence qui a été importante pour mon futur est que j’avais décidé de devenir mathématicien.
Mais en fait, ce qui m’intéressait dans les mathématiques, c’était l’algèbre, les nombres et les équations. La géométrie et les statistiques m’intéressaient beaucoup moins.

Deux ans plus tard, je me suis acheté une calculatrice TI58C (480 pas de programme, et quelques registres de stockage). Je pouvais enfin résoudre certains des problèmes de manière automatisée: le rêve de tout mathématicien !!!
Je me suis mis ensuite à essayer de dépasser les limites de la calculatrice en poussant l’optimisation au maximum.
Un an plus tard, je me suis acheté mon premier ordinateur: l’Oric 1.
48Ko de RAM, 1Mhz, cela explosait les limites de ma pauvre calculatrice.
Après moult efforts, j’ai appris le Basic et le langage assembleur tout seul, sans documentation, et j’ai à nouveau continué à essayer de dépasser les limites de la machine, en poussant l’optimisation et le hardware toujours plus loin.

Mon intérêt grandissant pour l’informatique allait de pair avec mon désintérêt grandissant pour les études, et à la mort de mon père, le dernier lien qui me poussait à continuer mes études ayant disparu, je me suis lancé à corps perdu dans l’informatique. Personne ne peut imaginer à quel point cette expression « à corps perdu » prend ici tout son sens, je pouvais enfin ne plus me consacrer qu’à mon esprit, mon corps n’existait plus du tout pour moi.

A cette époque, j’avais changé mon objectif de « devenir mathématicien » à « devenir le meilleur programmeur au monde » (il faut toujours viser haut).
Je me souviens que j’avais acheté très cher les 3 volumes de « The Art of Computer Programming » de Donald Knuth, et j’acquérais tout seul les bases algorithmiques.

J’ai programmé 2 jeux avant d’être embauché en 1985 par Titus Software, qui était la pire boîte que j’ai jamais connue, avec un encadrement méprisant les êtres humains. Titus était le parangon du harcèlement moral. Curieusement, cela m’a forcé à réfléchir sur ce qui motivait les gens, et comment travailler harmonieusement en groupe (bien avant qu’on ne parle d’agilité !).
J’ai quitté Titus en 1988, et je vous raconterai plus en détails mes péripéties par la suite.

En 1986, j’ai fait mon premier jeu en C, et 10 ans plus tard, mon premier jeu en C++, avec beaucoup de jeux en assembleur et sur consoles entre les deux.

Au fur et à mesure des années, les jeux demandaient de plus en plus de monde. Au début, j’étais seul (avec un graphiste), puis dans de petites équipes (<20), puis dans des grosses équipes (>40).

Si vous voulez avoir une idée du travail de programmeur dans le jeu vidéo, je vous conseille de lire cet article qui décrit bien la mentalité dans les années 90:
http://www.codeofhonor.com/blog/tough-times-on-the-road-to-starcraft

J’ai arrêté le jeu vidéo en 2003, lors de la 3ème crise du jeu vidéo en France, et après avoir réalisé que j’avais fait le tour en tant que programmeur, parce qu’à l’époque, aider les équipes à s’organiser n’était pas vraiment ma préoccupation.

Je vais dresser quelques constats de toute mon expérience informatique.

L’optimisation des ressources

J’ai programmé des jeux vidéos parce que faire un jeu avec des contraintes est un challenge passionnant. Il fallait à la fois écrire un jeu et faire tenir ce jeu dans les limites de la machine, tout en poussant la machine dans ses derniers retranchements.

Dans l’informatique professionnelle, il n’y a pas du tout ce genre de challenge, à part peut-être dans des sociétés comme Google, où chaque micro-seconde compte. J’ai essuyé des moqueries de mes collègues de travail quand je parle d’optimisation, tellement l’informatique est devenue une sorte de construction de Légo (avec des grosses pièces bien génériques et bien lentes).

Laissez les équipes s’auto-organiser !

Dans le jeu vidéo, les équipes sont assez petites pour être auto-organisées. Les seuls gros échecs que j’ai connus sont quand les équipes deviennent énormes (plus de 10 programmeurs). L’échec n’en est que plus retentissant.
Les meilleures équipes sont composées de programmeurs expérimentés auto-organisés.

En fait, le problème apparaît dès qu’on introduit une hiérarchie, ce qui entraîne un ralentissement de tout le processus de développement. Scrum essaye timidement d’enlever la hiérarchie, mais à force de vouloir plaire à tout le monde, Scrum ne plait plus à personne.
Certaines entreprises ont poussé l’auto-gestion encore plus loin.
Un ami qui travaille à Valve m’a expliqué comment on y travaille: si quelqu’un veut monter un projet, il peut former sa propre équipe en interne.

J’aime beaucoup l’approche du manifeste: http://programming-motherfucker.com/

Le manque de créativité de l’industrie informatique

Malheureusement, les projets informatiques sont de plus en plus construits avec des briques maîtrisées de logiciel, même dans le jeu vidéo.
On essaye de rester dans les limites de ce que l’on sait faire.
Le désir de réduire le risque logiciel à zéro fait qu’il ne reste plus vraiment quelque chose d’intéressant à programmer.
L’agilité fonctionne très bien sur des projets non créatifs, mais que se passe-t-il sur des projets hautement originaux et à risque ?

10000 heures pour devenir un expert

Il faut à peu près 10 ans de travail pour devenir un expert en programmation.
J’adore l’article de Peter Norvig: http://norvig.com/21-days.html

J’ai dû faire mes 10000 heures en 5-6 ans, parce que je ne faisais que ça à l’époque, j’étais un no-life.

Un point qui manque dans l’article est que programmer un projet n’apporte pas énormément de connaissances !
Dans un jeu, il y a assez peu de choses à apprendre.
Il faut vraiment développer sa culture générale informatique pour devenir excellent.
J’ai programmé des dizaines de projets tous différents, afin d’avoir le plus de culture possible. Dans mon cas: un calcul distribué sur Internet, plusieurs concours de programmations, des démos, des algorithmes de compression, des programmes de remplissage de mots croisés, etc…
Plus on fait de choses variées, et plus on est capable de résoudre des problèmes variés.

L’autre point qui manque est que programmer est presque devenu une activité sociale.

La programmation, une activité sociale ?

J’ai grandi avec l’idée que la programmation était une activité solitaire, où chacun faisait sa part du travail.
Cette activité devient sociale lorsque le projet requiert la coordination d’une équipe.
L’agilité essaye d’apporter une réponse au découpage des tâches.
Le pair-programming est d’un grand secours quand un programmeur inexpérimenté doit intégrer un nouveau projet et monter en compétence.
Mais le pair-programming n’est pas une solution quand l’équipe est expérimentée, à moins que le projet ne soit super chiant à programmer.

Introversion, extraversion et ambiversion

J’ai basculé il y a 4 ans de l’introversion à l’ambiversion.

Un introverti est quelqu’un qui est principalement intéressé par sa propre vie mentale. Tous les très bons programmeurs que j’ai croisés sont introvertis.
Un extraverti est quelqu’un qui est plutôt intéressé par les interactions avec les autres, mais il s’ennuie facilement.
Un ambiverti est quelqu’un qui a les 2 traits: il est confortable dans ses interactions avec les autres (comme un extraverti), mais apprécie d’être seul (comme un introverti).
Pour plus de détails, consultez http://en.wikipedia.org/wiki/Extraversion_and_introversion
Des statistiques montrent que 66% des gens sont introvertis, le reste se répartit équitablement entre extravertis et ambivertis.
Mes statistiques personnelles montrent que 100% des programmeurs sont introvertis, et le focus de l’agilité sur les rapports humains les met mal à l’aise.

L’éloge de la qualité

Dans l’article de Norvig, un point important est que le programmeur doit se focaliser sur la qualité, ce qui correspond bien à la démarche agile.
Malheureusement, dans la majorité des projets, la focalisation est sur le résultat, ce qui fait que les gens font n’importe quoi pour que ça tienne. J’ai vu d’innombrables horreurs à la fois techniques et humaines (souvent simultanées, il suffit de passer une nuit blanche sur un programme pour constater le résultat lamentable).
La qualité, ce n’est pas simplement écrire des tests, c’est aussi résoudre des problèmes de manière créative.

Les langages informatiques

Je vois beaucoup de programmeurs essayer d’utiliser toutes les fonctionnalités d’un langage même quand c’est inutile, juste pour flatter leur égo (oui, je faisais ça aussi, j’aimais montrer que je savais faire mieux que les autres !).
Pour moi, tout langage informatique est une langue, et il faut essayer de s’exprimer avec les mots les plus simples possibles.
Je parlerai dans un prochain article de la fascination de la complexité.
Bien évidemment, il faut toujours s’adapter. Je suis passé du Basic à l’assembleur, puis au C, puis au C++, puis au VB.Net et au C#.
J’ai appris à faire des tests unitaires avec NUnit et fonctionnels avec Selenium. J’ai dû me mettre au Perl et à Java récemment.

Le statut du Programmeur Senior

Cela va faire 30 ans que je programme.
Comme je l’ai expliqué précédemment, je suis persuadé que les meilleures équipes sont auto-organisées et sans hiérarchie.
Quelle peut-être l’évolution pour un programmeur dans ces conditions ?
J’avoue que je n’ai pas encore de réponse à cette question.

Conclusion

L’informatique a beaucoup changé en 30 ans.

La performance était obligatoire quand j’ai commencé et a progressivement disparu, au profit de la livraison du projet et d’une dégradation de la qualité du travail et l’augmentation du stress chez les programmeurs.

Nous sommes vraiment dans une culture d’instantanéité: comment résoudre mon problème le plus rapidement possible ?
Comment réduire le Time-to-Market ? Très simplement: en utilisant un langage qui résoudra tous les problèmes auxquels je peux être confronté !

Je pense que j’ai passé plus de 5000 heures à expérimenter la psychologie sur moi-même. La psychologie me semble très proche de la programmation, et son champ d’application est bien plus vaste que l’informatique.
Enfin, la psychologie des informaticiens me semble un domaine passionnant, mais trop limité pour les psychologues, qui ne peuvent pas comprendre la mentalité des informaticiens.