The first draft of anything is shit.
Résultat en mindmap d’une séance d’innovation ouverte.
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.
Source : azarask.in
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
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
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.
Source : ifixit.com
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.
Source : quora.com
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.
Page 1 sur 15
