Note de lecture : Crossing the Chasm, par Geoffrey A. Moore

Note : 5 ; Un grand classique du marketing des produits High tech.

Geoffrey Moore est célèbre pour sa fameuse courbe d’adoption des produits High Tech, et c’est bien de cela qu’il est question ici : de l’adoption des produits. Ou plutôt, pour être exact, de la transition séparant les visionnaires et innovateurs des pragmatiques (et des frileux) constituant la « early majority ».

Cet ouvrage est un livre de marketing, il n’y a pas de doutes à avoir là-dessus, aussi les sujets abordés peuvent être troublants parfois pour des techniciens. Mais c’est aussi l’intérêt de ce type de livres : aborder un sujet qui nous est familier avec un regard complètement différent de ce à quoi nous sommes habitués.

Ce grand classique se focalise finalement sur un sujet précis : comment franchir le fossé qui sépare les innovateurs des pragmatiques. Tout d’abord le texte identifie précisément pourquoi ce fossé existe et en quoi il est difficile à franchir car l’approche envers les innovateurs n’est en rien une aide à conquérir les pragmatiques, c’est en fait même souvent l’inverse. La première partie du livre est entièrement consacrée à cet éclairage.

En seconde partie, Geoffrey More nous propose une tactique de conquête de cette autre rive de la courbe : cibler une niche très précise pour y prendre pied, prendre une position dominante sur cette niche étroite en proposant un « produit complet » adapté à la problématique métier, et non simplement un « bel outil » comme l’apprécie les innovateurs. Les chapitres 3 et 4 traitent de cet aspect.

Les derniers chapitres évoquent la façon de vendre ce produit aux pragmatiques et les choix à faire par rapport à la dualité de marché innovateurs / pragmatiques. Quels canaux de vente privilégier, quel profil de force commerciale rechercher.

En ce qui me concerne, deux choses m’ont rendu la lecture un peu difficile : le peu de structure que l’auteur apporte à son propos : Geoffrey Moore adopte un style assez littéraire, fonctionnant plus par association d’idée que par structuration de la pensée. Cela fonctionne certainement assez bien pour des lecteurs baignant déjà bien dans le sujet et qui y possèdent des repères. En revanche, pour les nouveaux venus comme moi, c’est bien plus dur ! Un autre point également, à mettre en perspective avec les livres d’informatique en Anglais que j’ai l’habitude de lire : la variété du vocabulaire. Cela a parfois ralentit ma lecture. Heureusement que le Kindle dispose d’un dictionnaire intégré !

En bref, je n’ai certainement pas perdu mon temps. Les petites difficultés d’immersion dans le texte ont certainement un peu réduit mon plaisir, mais je dois admettre que l’auteur m’a fait découvrir tout un nouveau pan de connaissances relatives à un monde qui est mon quotidien.

CrossingTheChasm

Référence complète : Crossing the Chasm – Geoffrey A. Moore – HaperCollins Publishers 2001 – ISBN : 0-06-008718-8 (Kindle édition)

Crossing the Chasm: Marketing and Selling Technology Project


http://www.goodreads.com/book/add_to_books_widget_frame/0060087188?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Dynamics of Software Development, par Jim & Michele McCarthy & Michele McCarthy

Note : 4 ; Difficile à lire…

Cet ouvrage (plutôt succinct, moins de 200 pages) a été originellement écrit en 1995. L’auteur fut chef de produit sur Visual C++ 1.0, produit que j’ai personnellement trouvé fort peu convaincant, mais il est vrai moins « has been » que son prédécesseur MSC 7.0 ! Le texte est donc assez ancien, datant d’une époque de croissance des applications Windows, et il ignore donc le nouveau paysage créé par l’Internet (dont le texte ne parle pas du tout). Curieusement, dans cette mise à jour, la prose originale n’a pas été touchée, hormis parfois une petite note.

Le livre est structuré en 2 parties, plus une « troisième partie » sous une forme de vidéo de l’auteur. La première partie compte 154 pages divisés en 5 chapitres (de tailles très inégales) plus une annexe, eux-mêmes structurés en 54 items. Ces chapitres correspondent aux phases de développement, non pas calquées sur les classiques et fort peu réalistes « recueil des besoins, analyse, conception, etc… », mais plutôt sur une analogie du jeu d’échec :

Opening moves : on parle ici du lancement du projet, de son organisation et de ses objectifs.

The middle game : il représente le « ventre mou » du projet, la partie la plus longue durant laquelle le projet est sur les rails, mais où les features doivent être construites.

Ship mode : Qu’est-il nécessaire de faire pour livrer le produit, une fois le développement complété ? Ce chapitre traite des activités de fin du projet.

The launch : Comment gérer une arrivée sur le marché, comment créer un évènement de lancement ?

J’ai trouvé le texte intéressant par endroit, certaines des idées sont franchement précurseur des principes agiles (je pense entre autre aux « feature teams », mais l’aspect historique est généralement de peu d’intérêt pour le lecteur. Le problème le plus ardu est celui de l’anglais, trop recherché et surtout souvent trop imagé qui en diminue l’impact pour le lecteur français. Que penser de « don’t flip the bozo bit », par exemple ?

Bref, malgré sa réputation, je ne saurais conseiller cet ouvrage, pas assez (ou plus assez) original par lui-même et trop difficile à lire, nonobstant son petit volume.

The Dynamics of Software Development

Référence complète : Dynamics of Software Development – Jim McCarthy & Michele McCarthy – Microsoft press 2006 – ISBN : 0-7356-2319-8 ; EAN : 978-0-735-62319-4

Dynamics of Software Development


http://www.goodreads.com/book/add_to_books_widget_frame/0735623198?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : The Human Interface: New directions for designing interactive systems, par Jef Raskin

Note : 7 ; Le testament du père du MacIntosh

Ce livre ne traite pas d’une démarche de conception d’interface homme-machine, pas plus qu’il ne propose un guide de réalisation de ces interfaces. Non, en fait cet ouvrage traite du fond du problème, c’est-à-dire comment concevoir une interface adaptée à la façon de fonctionner de l’esprit humain. C’est ainsi qu’avant toute chose Jef Raskin aborde le conscient et l’inconscient et le fonctionnement de la mémoire immédiate et de la « localisation de l’attention ». Les solutions que propose Raskin sont radicales et rompent avec le courant actuel des interfaces fenêtrées et s’appuient sur des paradigmes tels que des interfaces non modales (dont le comportement ne dépend pas du contexte d’utilisation) et une navigation par zooming plutôt que par défilement. Plus encore que ce qu’il avait fait pour le MacIntosh, Raskin veut « enfouir » le système d’exploitation pour le rendre invisible, par exemple via une manipulation centré sur l’appel des fonctionnalités plutôt que sur le lancement d’applications, en abandonnant la manipulation de fichiers et même l’invocation directe de l’enregistrement des données sur le disque.

Bref, c’est un nouveau bond que l’auteur veut accomplir pour une « interface humaine », ses préconisations sont de fait troublantes, voir dérangeantes, eut égard à ce que nous connaissons, mais c’est aussi ce que nous recherchons des visionnaires, qu’ils remettent en cause nos certitudes. Nombre des concepts exposés sont démontrés sur un ordinateur qu’a conçu l’auteur : le Canon Cat. Ce n’est pourtant pas la machine la plus connue qu’il ait développé. Le créateur du MacIntosh est décédé le 26 Février 2005.

Ce livre n’est pas facile à lire, beaucoup de concepts sont difficiles à appréhender et nécessitent une bonne capacité d’abstraction pour suivre l fil de l’auteur. Mais les idées qu’exposent l’auteur n’existent nulle part ailleurs.

human-interface

Référence complète : The Human Interface: New directions for designing interactive systems – Jef Raskin – Addison Wesley / ACM press 2000 – ISBN: 0-201-37937-6; EAN: 978-0-201-37937-2

The Humane Interface: New Directions for Designing Interactive Systems


http://www.goodreads.com/book/add_to_books_widget_frame/0201379376?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Software Requirements, 2nd edition, par Karl E. Wiegers

Note : 9 ; Encore meilleurs avec le temps … et toujours une référence sur la gestion des exigences!

Je l’avais dit ailleurs, mais j’estime qu’un ouvrage dans sa seconde édition qui ne s’améliore pas mérite une note en baisse ! Vous pouvez donc déjà conclure qu’en gardant la même note que j’avais attribué à la première édition, cette nouvelle mouture a amélioré le texte original. Pas seulement amélioré d’ailleurs, mais aussi amplifié car l’ouvrage est augmenté de 100 pages. Après presque 10 ans de perspective sur les écrits concernant la gestion des exigences, Karl Wieger et les Robertson restent mes ouvrages de référence sur le sujet. Ce n’est pas rien et cette mise à jour (qui est en fait plus que cela) remet le livre en selle pour autant qu’il fût jamais détrôné.

La structure du livre est passée de 3 parties à 4 et le découpage a également évolué. Je ne vais pas rentrer dans le détail des chapitres, mais tenter de parler de chacune des parties.

La première partie est intitulée « Software requirements : What and Why ». A priori cette partie est dévolue aux nouveaux venus dans la partie. Erreur, cette partie mérite d’être également étudiée par les analystes expérimentés tout autant ! A la place des banalités convenues, l’auteur explique clairement et nettement les différents types de besoins et les différentes perspectives à considérer sur leur expression. On y aborde avec honnêteté les attentes des utilisateurs et la façon concrète et pragmatique dont on peut les aborder dans le cadre d’un projet. Les « bonnes pratiques » nous renvoient aux droits et aux devoirs de l’analyste et de l’utilisateur durant l’expression des besoins. Sans jamais réellement évoquer l’approche agile, l’état d’esprit y est et je conseillerais sans hésitation la lecture de cette première partie à tout agiliste !

La seconde partie porte tout simplement comme titre « Software requirements developpement ». Avec ses 220 pages et ses 12 chapitres, c’est la plus longue du livre ! Il s’agit d’une approche « par facette » plus que par activité et qui couvre remarquablement toute l’activité de recueil du besoin : établissement de la vision, dialogue avec les utilisateurs, règles métiers, scénarios d’usage, documentation, validation, qualification, etc… Chaque chapitre est clairement focalisé sur un point de vue, clair et riche sans se perdre dans des considérations stériles.

La troisième partie est consacrée au « requirements managements », où comment gérer l’évolution des exigences dans le temps. Cela couvre l’outillage, la gestion des changements et de la traçabilité. Si cela ne couvre que 65 pages, ne croyez pas pour autant que le sujet est traité avec légèreté car l’essentiel est dit, même si il peut être complété par ailleurs.

La dernière partie « implementing requirements engineering » est nouvelle et certainement moins passionnante (sans être mauvaise). Mais on est plus loin des processus agiles.

La première édition était bonne, la seconde l’est plus encore. L’ouvrage couvre avec succès toutes les facettes du recueil des besoins et peut figurer comme seul ouvrage sur la gestion des exigences dans votre bibliothèque si vous ne souhaitez qu’un livre.

wieger-soft-reqt

Référence complète : Software Requirements, 2nd edition – Karl E. Wiegers – Microsoft press 2003 – ISBN: 0-7356-1879-8; EAN: 978 0 7356 1879 4

Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle

http://www.goodreads.com/book/add_to_books_widget_frame/0735618798?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Writing Effective Use Cases, par Alistair Cockburn

Note : 7 ; D’excellents conseils rédactionnels et une bonne approche “adaptative” de la modélisation des systèmes.

Ce livre se focalise entièrement sur la rédaction textuelle des cas d’utilisation. A ce titre, il relativise la description graphique comme étant une vue synthétique du périmètre fonctionnel. Alistair prêche une approche par décomposition fonctionnelle dans laquelle on part des business cases pour descendre jusqu’à des uses cases de type sous routines. A chaque niveau (représenté par une icône) on détermine l’objectif de l’acteur principal comme étant la force essentielle dans la détermination du cas d’utilisation.

Le livre est excellent pour ce qui est de décrire des Use Cases optimaux et clairs, donc suffisamment courts et concis pour être lus et compris. Qui plus est, des mémentos permettent de se rappeler quelles sont les règles à suivre dans l’écriture des Use Cases. Ce livre est d’avantage dédié aux personnes pratiquant déjà les cas d’utilisation et désireuses de progresser qu’aux nouveaux venus qui risquent de se retrouver quelque peu noyés. Enfin certains aspects tels que la décomposition fonctionnelle utilisant abondamment les relations d’inclusion sont critiquables voire dangereuses lorsque utilisées à mauvais escient.

writing-effective-use-cases

Référence complète : Writing Effective Use Cases – Alistair Cockburn – Addison Wesley / Crystal Collection for Software professionals 2001 – ISBN: 0-201-70225-8; EAN: 978-0-201-70225-5

Writing Effective Use Cases


http://www.goodreads.com/book/add_to_books_widget_frame/0201702258?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on