As far as polling for feature requests, we feel this would be a little unfair to users in a few ways. First, we’re adhering pretty strictly to a roadmap of feature rollouts, bug fixes and parity plans across ~15 platforms, all of which are also impacted by individual client updates. While our roadmaps are definitely 100% without a doubt impacted and adjusted by user feature requests, bug reports, etc (I cannot stress this enough so it gets underlined and bolded), the roadmap is also set by our development team based on all of these variables. We’d be doing everyone in our community a disservice if we rolled out a poll that gave you a false sense of choice over any of these variables.
Source : discussion.evernote.com
Le modèle de compétence de Dreyfus (How to Become an Expert: A Roadmap)
J’ai pris connaissance du modèle de Dreyfus dans Pragmatic Thinking and Learning: Refactor Your Wetware. Le texte lié ici est un résumé correct, mais le texte d’Andy Hunt est encore meilleur.
Je ne comprends pas trop pourquoi je n’avais pas entendu parler de ce modèle là avant… c’est une référence incontournable pour bien comprendre et bien gérer une équipe de professionnels.
Je ne prends même pas le risque de tenter un résumé ici pour l’instant: il faut lire l’original. Un très bon investissement.
The phrase ‘The Customer is Always Right’ is the single worst philosophy that has ever been adopted by American culture. It gave an entire generation of people the green light to be as impolite, unreasonable, and demanding as their little hearts desired because they were always going to be considered right.
Vous voulez connaître la différence entre un CTO et un VP du "engineering"?
Ce texte est un incontournable dont je tiens à garder la trace. Il aborde la question des rôles de gestion — humaine et technique — dans le contexte d’une entreprise technologique. C’est un sujet qui me tient évidemment à coeur. L’auteur, un entrepreuneur web devenu venture capitalist (capitalderisqueux?), propose une catégorisation des rôles dans un diagramme à quadrants. Évidemment, ça ne s’applique pas partout, mais j’ai trouvé les définitions assez éclairantes.
J’ai surligné les passages qui me marquent le plus, et je résume ma compréhension de la distinction entre deux rôles importants:
- le CTO est le responsable de la technologie, qui connaît et maîtrise tout, qui sait coder et qui le fait. C’est un perfectionniste, et il est au coeur de toute entreprise technologique. Dans la même catégorie, on retrouve les “chefs architectes”, que le texte distingue du CTO simplement par l’expérience. «Un “chef architecte” est une version jeune du “CTO”». Un peu simpliste, mais on comprend l’idée. Le CTO doit gérer la technologie, mais pas les gens.
- le VP de “engineering” est celui qui gère les gens. Il a une bonne connaissance de la technique, il a le respect de ses collègues parce qu’il sait faire (essentiel pour gérer une équipe de geeks), mais il est aussi très bon dans Excel, et il est même présentable devant des clients. C’est celui qui gère les gens.
L’auteur du texte rappelle qu’il est possible de rencontrer des gestionnaires qui sont en mesure de jouer les deux rôles à la fois, mais que c’est extrêmement rare, et que dans cet esprit, il vaut mieux combler ces postes progressivement quand on bâtit une organisation.
Merci à Clément pour la référence…
Source : bothsidesofthetable.com
Rework: une vision différente du monde du travail et de l’entrepreuneuriat
J’attendais la sortie du dernier livre des fondateurs de 37signals, Rework, avec intérêt depuis un certain temps. J’avais apprécié leur premier livre, Getting Real (en autopublication). Je n’avais pas trop d’attentes pour le second livre, pensant qu’il reprendrait en grande partie le contenu du premier, mais mieux présenté suite à l’implication d’un «vrai» éditeur. J’avais en partie raison et en partie tord: on retrouve dans Rework les idées de Getting Real (et plus largement, les idées que Jason Fried et David Heinemeier Hansson véhiculent sur toutes les tribunes), mais elles sont été «remixées» et distillées… Rework-ées??
Pour tenter de résumer la pensée des auteurs, retenons qu’ils ont une approche de gestion des projets, des ressources humaines et financières, du recrutement et du portfolio de produits qui s’appuie sur des valeurs de simplicité, de confiance, de transparence et de gros bon sens. Ces valeurs se manifestent dans des conseils de gestion simples (moins d’une centaine), chacun présenté dans Rework par un court essai d’une page ou deux, accompagné d’une illustration. Les conseils vont de «dites d’abord non» à «les meetings sont toxiques», en passant par «congédiez les bourreaux de travail». J’ai aussi beaucoup aimé «embauchez des gens qui savent rédiger», «le marketing n’est pas un département» et «les décisions sont temporaires».
La structure par courts essais, le soin qu’ont apporté les auteurs à rendre le livre le plus synthétique possible (on apprend qu’ils sont passés de plus de 50 000 mots à 27 000 au cours du processus éditorial) et le style direct, conversational, en font une lecture relativement facile et rapide. Le contenu est très intéressant, et j’ai tendance à rejoindre la majorité des commentaires élogieux qui ont été formulés sur le sujet.
Évidemment, les auteurs appliquent leur philosophie au maximum au livre. Ils recommandent des créer des produits qui émettent une opinion claire, et leur texte le fait. Ça mène parfois à quelques exagérations ou généralisations qui ne peuvent pas d’appliquer dans toutes les entreprises ou tous les contextes, mais ça n’enlève rien à la qualité du livre (au contraire!).
Somme toute un incontournable pour les amateurs du style 37signals, mais surtout un bon point de départ pour ceux qui veulent revisiter la façon dont ils travaillent.
Pour référence, le site officiel du livre: http://37signals.com/rework/.
Meilleures pratiques de gestion des ressources humaines en TI
Le 17 février dernier, PÔLE et des partenaires offraient aux entreprises de Québec une formation sur la gestion des ressources humaines en TI. La formation était confiée à Armelle Rossetti, d’Akova.
Le contenu était très riche et je n’en ferai pas un résumé ici. Je partage quand même mes notes manuscrites, sous la forme d’un mindmap:
Je note de plus d’aller consulter le résumé de l’étude sur le marché du travail au Québec pour les 10 prochaines années sur le blog d’Akova.
Texte d'opinion sur la gestion d'une équipe de geeks
Un texte très intéressant (via @fmarier) sur la gestion d’une équipe de professionnels des technologies. Bien que je n’endose pas tout ce qu’il y a dans le texte (dont voici une version où j’ai identifié mes passages préférés), on y trouve certaines idées intéressantes. J’en note certaines ici:
- on peut comparer les professionnels des TI à des médecins, qui ont à utiliser science et instinct;
- l’efficacité dans la gestion d’un groupe en TI est basée sur le respect, pas sur la hiérarchie;
- par leur côté logique développé, les gens de TI ont souvent tendance à être critiques lorsqu’ils constatent des politiques ou des façons de procéder qui n’ont pas de sens; on confond souvent cette critique factuelle avec du cynisme ou de la victimisation;
- dans le même ordre d’idée, il faut comprendre que lorsqu’un professionnel des TI cesse de nous souligner des problèmes, c’est probablement parce qu’il considère pragmatiquement que nous ne sommes pas compétent pour les régler (et donc, que le respect est à la baisse);
- comme dans un groupe de médecins, les meilleurs invidus pour juger d’un autre professionnel sont les pairs; ainsi, des bonnes pratiques incluent l’implication des professionnels dans l’embauche de leurs collègues (ou supérieurs), et des mécanismes d’évaluation à 360 degrés.
Source : computerworld.com
"Pour introduire l'innovation en entreprise, il faut penser usages "
J’ai fait une version annotée de ce texte pour identifier les passages les plus intéressants selon moi, en particulier les trois étapes d’introduction d’une innovation technologique en entreprise.
Source : atelier.fr
[…] des études ont démontré que la majorité des améliorations de performance sont systémiques. La motivation ou une intelligence supérieure ne font qu’une différence négligeable à long terme. Presque toutes les améliorations de performance sont un résultat direct de la qualité des outils et des processus utilisés.
et leur application dans le monde réel, p. 269.
A Sketchy Brain Booster: Doodling | Wired Science from Wired.com
Gribouiller pour mieux se concentrer. Des chercheurs en psychologie de l’université de Plymouth publient un article qui démontre que de gribouiller pendant une tâche (j’imagine une réunion ou un appel téléphonique) permet d’être plus concentré sur la tâche en question. L’étude démontre que les gribouilleurs retiennent par ailleurs plus d’information. (via)
L’article n’en parle pas, mais je fais un lien avec les théories du mindmapping de Buzan, que j’ai résumées récemment. Buzan dit que de stimuler plusieurs sens, en dessinant, aide à mémoriser les informations. Donc, gribouiller un mindmap pendant une réunion, c’est probablement pas fou…
Image sous licence CC par martouf.
Source : Wired
