christianroy.tumblr.com

"As a founder, your job isn’t to make a great product. It’s to build a great team that makes great..."

Wed, 15 May 2013 22:07:21 -0400

“As a founder, your job isn’t to make a great product. It’s to build a great team that makes great products. You are who you hire. […] Making stuff as your team grows is often more harmful than helpful”

- Tiré de Psychological Pitfalls And Lessons of A Designer-Founder « Aza on Design, un texte particulièrement inspiré sur la difficulté pour le foundercontinuer à s’impliquer dans la création des produits de son entreprise qui croît.

"Good product managers validate their features before they build them, and that’s why their..."

Tue, 22 Jan 2013 07:19:53 -0500

“Good product managers validate their features before they build them, and that’s why their ideas are so much more likely to improve the bottom line of the company. They don’t necessarily have better ideas. They just kill the bad ones before spending too much time on them.”

- Tiré de Expect More From Product Managers, par Laura Klein

Préciser ses attentes

Thu, 03 Jan 2013 10:34:42 -0500

Préciser ses attentes:

Je retiens de ce texte l’importance, l’impact et la simplicité de l’exercice de «former» (c’est l’intention dans le billet) son équipe sur nos attentes comme manager. Je me promets de faire un exercice similaire dans les prochains mois.

Sur les petites équipes de développement informatique

Sat, 10 Nov 2012 12:13:53 -0500

C’est d’abord un article intitulé «PayPal va licencier 325 personnes pour devenir “plus agile”» qui a attiré mon attention. «N’importe quoi!», que je me suis dit. Mais j’ai quand même lu. Et il s’avère que les choix que fait le PDG de PayPal, David Marcus, sont justifiés par des réflexions intéressantes. Il dit:

il arrive un moment dans la vie d’une grande entreprise où elle se heurte à la loi des rendements décroissants, quand un grand nombre d’employé ralentit le fonctionnement

Ce qui m’amène à faire un lien avec un autre texte, Small teams are dramatically more efficient than large teams (via @frederickdubois), qui explique de façon un peu plus détaillée cette fameuse loi des rendements décroissants. C’est assez bien résumé par ce passage:

Communication and coordination overhead rises dramatically with team size. In the worst possible case where everyone on the project needs to communicate and coordinate with everyone else, the cost of this effort rises as the square of the number of people in the team. That’s such a powerful effect, in fact, that a large team couldn’t possibly hope to achieve the goal of everyone coordinating their effort. But a small team could.

Tout le monde sait ça, évidemment. Mais j’en soupçonne certains de penser que c’est de la théorie, et que plus de programmeurs, c’est mieux et ça va plus vite. C’est là que le texte est éclairant. On y apprend que selon une étude réalisée par le groupe QSM sur un grand nombre de projets informatiques comparables, les petites équipes (moins de 5 personnes) ne prennent que 2% plus de temps que les grandes équipes (plus de 20 personnes), générant évidemment beaucoup (beaucoup!) moins de frais. Pourquoi? À cause des coûts de communication et de coordination évoqués plus hauts, mais également parce que…

The defect rate for the large teams was five times greater than for the small teams. Defects consume time in discovery, documentation, and repair. That effort is obviously necessary, but doesn’t contribute directly to creating the desired software, and therefore inflates cost without any benefit to the schedule.

Ce qui nous ramène au texte sur PayPal. Ça a donc du sens de réduire la taille de l’équipe pour mieux se structurer et réduire ses coûts sans trop affecter les délais. En plus, ça les aidera peut-être à mieux recruter par la suite:

PayPal est considéré comme un mastodonte, lent et bureaucratique. Une réputation qui, selon Reuters, aurait rebuté des ingénieurs à venir grossir les rangs de la société.

Tout ça me confirme plusieurs décisions importantes sur mon processus d’embauches et me rappelle pourquoi on le fait comme ça.

laconcha: Join the repair...

Sun, 28 Oct 2012 08:24:56 -0400

laconcha:

Join the repair revolution

http://www.ifixit.com/Guide

"Some designers would term these six type of users as ‘personas’ but they weren’t..."

Wed, 10 Oct 2012 22:14:24 -0400

“Some designers would term these six type of users as ‘personas’ but they weren’t patterned on demographics. Rather, they were buckets intended to catch the primary mental models users would have about the product. […] I knew at the time that we had little to no data on how large a proportion each use type would represent in the real-world, but I was relatively confident that the buckets were comprehensive enough that they would represent almost all users. I used them as a guide to make sure the design decisions we made didn’t harm any of these mental models, just because we didn’t happen to hold those models ourselves.”

- Kevin Fox, designer chez Google, au sujet d’une approche que je veux tenter d’utiliser.

The Mythical Man-Month

Mon, 27 Aug 2012 21:09:00 -0400

The Mythical Man-Month

Résumé sous forme de mindmap du livre A Whole New Mind: Why...

Sun, 29 Jul 2012 08:44:40 -0400

Résumé sous forme de mindmap du livre A Whole New Mind: Why Right-brainers Will Rule the Future, lu il y a deux étés si ma mémoire est bonne. Je n’ai pas eu beaucoup d’occasions de faire des cartes de façon ludique depuis, et je viens de retrouver celle-ci, que je voulais publier à l’époque! La carte est en anglais puisque j’avais lu le livre dans sa version originale.

Producteer: A World Without Product Managers

Thu, 12 Jul 2012 07:23:03 -0400

Producteer: A World Without Product Managers:

Un texte que je veux relire au cours des prochaines semaines, parce que l’analyse est bonne, la conclusion est intrigante, et la suite pourrait être source de changements.

"Ça peut être dur à croire, mais on ne regarde pas une telle transaction strictement d’un point..."

Fri, 10 Feb 2012 12:53:00 -0500

“Ça peut être dur à croire, mais on ne regarde pas une telle transaction strictement d’un point de vue financier. On bâtit ces firmes-là par amour et par passion et avec la conviction profonde que nous développons des technologies qui révolutionneront le fonctionnement et l’efficacité des [utilisateurs].”

- Louis Têtu dans Taleo vendue 1,9 milliard $ | Gilbert Leduc | Techno. Je ne connais pas M. Têtu et ne peux pas juger de la conviction derrière ses propos, mais je veux y croire. C’est comme ça que ça doit se passer.

Ils ont complètement tout recodé. Je ne suis pas certain que je...

Tue, 07 Feb 2012 22:24:00 -0500

Ils ont complètement tout recodé. Je ne suis pas certain que je doive être rassuré. Je peux imaginer que dans certains cas ce soit une bonne idée… mais ce sont des cas rares. Réécrire le code n’amène aucune valeur ajoutée directe pour les utilisateurs. Pour que ça en vaille le coût, il faut que ça amène des changements majeurs qui changent tellement l’évolution du produit que ça devient pratiquement une fonctionnalité (des cycles de nouveautés plus rapides, un changement de modèle d’affaires, de plateforme, de canal de diffusion…). À moins qu’il y ait des problèmes hyper fondamentaux avec le code à l’origine, il y a sûrement des solutions alternatives. Me semble en tout cas un choix discutable, non?

"Hackers try to build the best services over the long term by quickly releasing and learning from..."

Wed, 01 Feb 2012 21:05:58 -0500

“Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.”

- Extrait de la lettre de Mark Zuckerberg aux actionnaires de Facebook, dans l’élan de l’appel public à l’épargne de la société (de Lessons Learned: The Hacker Way, via @ginatrapani).

"As far as polling for feature requests, we feel this would be a little unfair to users in a few..."

Thu, 26 Jan 2012 22:13:06 -0500

“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.”

- Tiré de Evernote User Forum - une excellente réponse pour illustrer la complexité d’une bonne gestion de produit

Sur le leadership

Tue, 24 Jan 2012 22:24:17 -0500

J’ai eu la chance il y a plus d’un an «d’hériter» d’une formation de deux jours à l’école de gestion MIT Sloan sur la thématique du leadership. J’avais pris plusieurs notes, dont la carte mentale suivante qui résume le modèle préconisé par le groupe ayant créé la formation, dont la formatrice Deborah Ancona et l’auteur légendaire Peter Senge.

Le 4 Capabilities Leadership Framework se résume ainsi:

En résumé, il faut retenir que les leaders efficaces savent utiliser les quatre compétences, qui interagissent ensemble. La compétence relationnelle («relating») permet d’obtenir de l’information, ce qui mène à se créer un ou des modèles qui permettent de comprendre les enjeux («sensemaking»). Une fois que c’est fait, le leader doit avoir une vision claire («visioning»), qu’il doit partager avec les autres, mais également bien exécuter en choisissant les bonnes actions («inventing»).

How agile methodologies can help publishers - O'Reilly R

Sun, 22 Jan 2012 09:37:00 -0500

How agile methodologies can help publishers - O'Reilly R:

La rencontre de deux de mes centres d’intérêts professionnels…

Comment leur expliquer ça en vulgarisant mais tout en démontrant...

Thu, 03 Nov 2011 20:41:52 -0400

Comment leur expliquer ça en vulgarisant mais tout en démontrant la complexité et les aspects dynamiques de la chose?… #defidecesoir (Taken with instagram)

Working Backwards - All Things Distributed

Wed, 02 Nov 2011 20:38:12 -0400

Working Backwards - All Things Distributed:

Sur l’approche de création de produits et service d’Amazon: j’aime l’idée de partir de la fin, en rédigeant le communiqué de presse et la FAQ avant de commencer le projet.

Une carte mentale pour préparer une présentation

Sat, 22 Oct 2011 10:37:38 -0400

Je prépare présentement une présentation dans le cadre de Agile Tour Québec 2011. Comme la plupart du temps quand j’ai à préparer un long document ou une présentation, je travaille d’abord sur une carte mentale avant de m’attaquer à la création des slides en tant que tel.

La carte évolue évidemment en cours de route. D’un support pour faire un brainstorming personnel au départ, elle se transforme progressivement…

en calepin de notes, pour regrouper des références trouvées pendant la recherche;
en plan de présentation, de façon à structurer ce que j’ai à dire dans des sections cohérentes, avec un fil conducteur;
en cahier de travail, qui me permet de faire des ajustements à la structure en cours de route, noter des idées «pour plus tard», ou me replonger dans le sujet après une interruption ou au début d’une nouvelle séance de travail sur la présentation.

À la fin, la carte devient assez grande:

Et ça mène à une série de diapositives qui ne correspondent pas nécessairement à des branches de la carte (bien que les grandes sections de la présentation correspnondent aux branches principales de la carte).

En complément, ma présentation consiste en un bilan après 2 ans de cheminement vers l’agilité chez De Marque. L’exercice de préparer la présentation m’a forcé à faire un bilan et à prendre du recul, ce qui est fort utile.

Vue dans les rues de Francfort.

Mon, 10 Oct 2011 16:32:09 -0400

Vue dans les rues de Francfort.

Steve Jobs: How to live before you die | Video on TED.com

Wed, 05 Oct 2011 20:19:24 -0400

Steve Jobs: How to live before you die | Video on TED.com:

Inspirant discours, très pertinent aujourd’hui. Deux citations fortes:

Death is likely live’s best invention.
Stay hungry, stay foolish.