Hiring the Best Knowledge Workers Techies and Nerds, par Johanna Rothman

Note : 6 ; De la définition de poste jusqu’à l’embauche

Le recrutement est probablement le facteur le plus important de la constitution d’une équipe. Avec le temps, on finit par développer une certaine expérience sur le sujet, et aussi une approche de ce qui est important, déterminant et ne l’est pas. Et à un moment donné, on souhaite confronter ces idées instinctives aux personnes expertes du sujet. C’est à ce moment que l’on s’aperçoit que ces experts ne sont pas si nombreux, la plupart se bornant à de classiques conseils RH sans valeur dans notre domaine. S’il est un auteur auquel j’attache quelque importance dans ce domaine, c’est bien Johanna Rothman.

Sur ce sujet, notre experte du management agile nous gratifie tout de même d’un ouvrage comptant 280 pages sans les annexes (comptez une cinquantaine pour ces dernières). Johanna Rothman a délibérément choisi de couvrir tout le cycle de vie du recrutement, donc en ne se limitant pas à l’interview. Par ailleurs, ce livre ne s’adresse pas spécialement à de l’embauche en contexte agile et certains éléments du cycle de recrutement sont assez spécifiques du contexte américain. Toutefois, aucun de ces deux points n’est un obstacle, l’approche de l’auteur est en effet très convergente avec ce que l’on essaie de faire (en tout cas moi) lors d’un recrutement en contexte agile.

Passons maintenant en revue le texte. L’ouvrage compte 5 parties distinctes totalisant 15 chapitres. La première partie couvre globalement les questions de définitions de poste. Elle est longue de 65 pages et comprend 3 chapitres. Le premier couvre une vingtaine de pages et traite de la stratégie d’embauche. Il culmine avec un « hiring strategy template » permettant de s’orienter entre embauche externe, contractant, embauche interne, etc. en fonction du type de besoin et du contexte de la recherche. Malgré sa qualité, ce n’est pas ce qui m’a intéressé le plus. Le propos du chapitre suivant est « d’analyser le job », il occupe 30 pages et nous conduit à déterminer les compétences techniques et humaines nécessaires en fonction du type de travail. Une analyse très fine et pertinente qui va jusqu’à évoquer les questions de fit culturel avec l’entreprise et les facteurs d’élimination. Cette partie se conclut avec le chapitre 3 qui traite sur une dizaine de pages l’écriture de la fiche de poste. Il s’agit du chapitre qui m’a le moins intéressé : l’auteur nous propose une fiche de poste des plus classiques (bien que complète) mais qui ne sera pas à même de faire briller les yeux…

Lire la suite

Publicités

Des Ressources Humaines au Capital Humain avec l’agilité

Tel que nous les vivons aujourd’hui, la gestion des ressources humaines et l’état d’esprit agile ne semblent pas fait pour se marier ensemble. Mais c’est bien de cela que nous a parlé Jas Chong lors de ce Meetup organisé par Agilebee. J’avais rencontré Jas Chong il y a peu, lors de l’open-space du Scrum Day.

Aujourd’hui c’est le retour d’expérience d’une transition qu’elle évoque avec nous.

image

Jas a passé pas mal de temps à nous camper le contexte. Pour ma part, je vais faire beaucoup plus court : il s’agit d’une transformation digitale dans le domaine du voyage. Une transformation qui passe par l’agilité et la rationalisation de l’organisation des développements à l’échelle internationnale ! C’est là que Jas intervient.

Rationaliser l’organisation

Cette rationalisation passe par la création de « centres d’excellence », transverses aux DSI des différents pays. Conséquence logique, elle passe aussi par une standardisation technologique globale : le passage global à Java (donc le basculement d’équipes .NET à Java) en est l’aspect marquant. En pratique cela se traduira par de grandes transumances de personnels vers les centres d’expertises par sujet, déplacements qui devront s’opérer par pays. On voit déjà que l’on tient là un sujet complexe du point de vue ressources humaines !

Personnellement je note l’aspect en fait très peu agile de cette stratégie : la rationalisation globale et la standardisation « top down » n’empruntent pas grand chose des valeurs de l’agilité.

  • La globalisation éloigne fournisseur et client.
  • La standardisation se fait au détriment de la variété qui est souvent source de création. Elle génère aussi des évolutions par rupture qui empêchent l’adoption de nouvelles technologies : si l’on standardise sur Java, comment faire émerger des essais avec Scala ? Où verra-t-on éclore des projets essayant de nouvelles architectures applicatives ?

Le challenge est évidemment élevé. Très élevé !

Une transformation par sprints

Même lorsque les changements envisagés sont importants, il n’est pas nécessaire de procéder en « big bang ». En l’occurrence, il aura fallu compter 4 itérations de 3 semaines pour y parvenir. Quelques clés pour cela :

  • Conduire la formation des équipes par agrégation autour d’un « product lead ».
  • Ne pas négliger le volet opérations.
  • Le choix d’un Scrum Master qui est un Agile Project Management, avec une expérience du domaine métier.
  • Intégrer l’aspect « team building » ; en fait il y a deux aspects : le team building social et le team building travail.
  • L’engagement des équipes n’est possibles que si une orientation claire est définie et qu’il y a une sécurisation de la relation par rapport à l’employeur. C’est le rôle du contrat de travail, notre prochain sujet.
image

De l’usage de la fiche de poste

Le contrat de travail est nécessaire, et dans le cas présent complexe car on déplace du personnel entre pays, avec des legislations différentes.

Mais laissons de côté la partie contractuelle qui est un peu hors de notre propos. En préambule du contrat, il y a la fiche de poste. Celle-ci est importante. Tellement importante qu’elle entre dans ce que Jas appelle le « total talent management ». Cette fiche de poste ne concerne pas seulement les recrutement, mais les prestataires et les sous-traitants et également les transferts de poste en interne.

La fiche de poste agile est simple et réduite. Celle de Jas fait quand même 2 pages, pas vraiment ce que j’appelle « simple et réduite ». son contenu :

  • Purpose (finalité)
  • Accountability (responsabilités)
  • Skills (compétences). Cette partie est assez sommaire, ce n’est pas la plus importante de la fiche de poste !

Pour l’instant, je m’y retrouve ! Cela fait déjà un bout de temps que je n’accorde guère d’importance au diplôme et un intérêt assez modéré à la liste des compétences. Je me focalise beaucoup plus sur l’aptitude (ce qui n’est pas la même chose), le potentiel, le savoir-être et la curiosité… Sans doute faudra-t-il que je développe la question un jour prochain

Autre point sur lequel je suis en phase : en fonction du poste à pourvoir, on porte plus d’importance sur certains aspects de la fiche. Au final, on cherchera à avoir une équipe avec des compétences complémentaires. J’ajouterais personnellement : avec des personnalités complémentaires !

Le Sandwiche agile

Travailler en RH dans un environnement agile n’est pas facile. Nous-même (moi-même) voyons le plus souvent les RH comme un obstacle.

L’objectif d’être une RH agile est de devenir un support.
Jas nous propose de nous pencher sur le « Lean RH » dont nous pourrions définir les caractéristiques ainsi :

  • Eviter le gaspillage en externalisant les fonctions sans valeur ajoutée : paie, etc..
  • Faire du recrutement « just in time ».
  • Développer les personnes.

L’approche Lean diffère en certains points de l’approche agile, en fait une approche trop Lean tendrait à devenir non agile…

image

Mais si nous n’apprécions guère les RH, les RH eux-même ne sont pas heureux : réduits à gérer des ressources humaines alors qu’ils souhaiteraient développer le capital humain !

L’agilification des entreprises n’est souvent hélas que partielle, c’est ce que Jas appelle le « sandwich agile »:

  • Au-dessus, la gouvernance : PMO, Finance, RH, etc… ; pas agile !
  • Au milieu, les équipes agiles (ou qui tentent de l’être)
  • Au-dessous, les départements en relation avec les équipes agiles : ventes, acheta, marketing, services, etc..

Ma conclusion

Avant ma conclusion, celle de Jas : cette transition n’est pas une grande réussite. Au niveau de la gouvernance, par exemple, le financement annuel ou la gestion sclérosée de la roadmap sont de très gros handicaps.

image

Pour ma part, j’ai deux sensations :

  • Tout d’abord, le travail de gestion du changement au niveau RH est considérable, car il s’agit bien d’une restructuration massive !
  • D’un autre côté, je n’ai pas l’impression d’avoir appris grand chose. Mes pratiques de recrutement vont déjà en ce sens, par exemple. Et je n’ai pas d’éléments de reflexion pour une RH 2.0 qui changerai vraiment la donne…

Pour terminer, voilà le support de présentation de Jas.

Merci aussi à Régis pour le lien sur la vidéo de Laurence Vanhée que je vous recommande !

Carnet de route : Le ScrumDay 2014 (3/4)

Nouvelle journée, nouvelle énergie. Après la journée conférence que je vous ai comté ici et ici, voici la journée consacrée à l’open-space, à l’image de ce qui se fait à Grenoble depuis quelques années déjà.

L’organisation met à notre disposition tout ce qu’il faut pour se remettre dans le rythme : thé, café, jus de fruits, viennoiseries…

image

Mais on est vite intrigué par le grand cercle matérialisé à même le sol autour duquel nous sommes invités à nous rassembler pour débuter cet open-space.

image

Ce sont Laurent Bossavit et Raphael Pierquin qui se chargent d’expliquer les règles de fonctionnement de l’Open-space … ou du moins tentent de le faire ! Apparemment, la sonorisation pose quelques problèmes…

image

Le principes sont en fait assez simples. Une fois établis, il est temps d’utiliser le matériel mis à notre disposition au centre du cercle pour proposer nos sujets.

image

Ces sujets sont ensuite eux-mêmes affichés sur les différents créneaux horaires en mode auto-organisé. C’est la « place de marché ».

image

J’ai posté mon propre sujet. Il est temps de faire le tour de ceux qui peuplent le premier créneau horaire. Et je reste un peu perplexe devant le sujet traitant de l’utilisation des points de fonction dans les projets agiles. Quand je vois ce genre de sujet, mon reflexe est de me demander en quoi ces techniques peuvent nous apprendre quelque chose, si la technicité développée ici peut nous aider. Laurent Bossavit semble plus circonspect quand aux motivations. Du coup, nous décidons tous deux de nous joindre à ce débat.

Agilité et point de fonction

La première chose qui me trouble est une certaine confusion entre l’outil et l’usage. Dans l’esprit de beaucoup, il y a une relation directe entre projet au forfait et point de fonction.

image

En fait, il semble même que nous ayons un pattern d’usage : on se sert des points de fonction comme outil « commercial » pour chiffrer une réponse à appel d’offre. Ensuite, lors de la réalisation, on se servira des story points. Voilà un constat assez troublant pour moi, bien qu’instructif sur la vision que l’on peut avoir des différents outils :

  • Les points de fonction sont vus comme un outil donnant un chiffre absolu, alors qu’il donne un chiffre relatif (les points) qui se transforment en charge via des facteurs d’ajustements. Comme les story points, en fait, bien que de façon plus complexe.
  • Quel est l’intérêt de faire un « chiffrage agile » si en amont le projet est de toute manière verrouillé par un chiffrage contractuel ? Je dirais même : quel est l’intérêt de faire le projet en agile, mais c’est sûrement une autre question…

La discussion s’est beaucoup focalisée sur l’usage de l’une ou l’autre approche, alors que je pense que la question n’est pas là : on peut parfaitement utiliser les FP ou les story points dans les mêmes contextes.
Par contre les points de fonctions traitent des « blocs » plus gros, qui sont ensuite décomposés sous l’angle technique (requêtes, entités, I/O, etc…), alors que les story points s’adressent à des blocs plus fins que l’on évalue globalement, en différent les questions sur les choix de conception. Par son approche les points de fonction « vérouillent » les choix techniques dès le chiffrage.

image

J’ai été assez déçu par le débat qui ne s’est finalement pas dirigé vers la question de la nature de ces différents types d’estimation (ce que j’évoque plus haut). Dommage…

Ressources Humaines et agilité

Ce sont à la fois l’originalité du sujet et son importance qui m’ont attiré vers ce groupe. Une groupe à coloration un peu « grandes gueules » avec Pablo Pernot et Pierre Neis, par exemple !

image

Tout d’abord, quels sont les problèmes ?

  • La gestion du parcours professionnel.
  • La gestion des évaluations.
  • La dissonance cognitive entre rôle et fiche de poste.

Le constat partagé par tous est qu’aujourd’hui les RH ne sont pas une aide au sein des projets agiles. Dans le meilleur des cas. Dans le pire des cas, elles sont un frein, voir un obstacle. Bref, il n’y a pas grand monde dans le cercle à aimer les RH. On entend même que les RH n’ont pas de raison d’être !

image

Mais il nous faut aussi admettre que l’on doit mieux comprendre le problème des RH : celui de devoir composer avec la loi, le management, les syndicats, le C.E., etc… En fait, il nous semble que leur effort porte plus sur la composition de ces contraintes que sur une véritable fonction support au sein de l’entreprise (ce serait plutôt un fonction contrainte !). Le mécanisme des entretiens annuels est bien entendu montré du doigt.

Alors, quelle solution pour la RH dans un environnement agile ?

C’est que cette RH devienne elle-même agile, en portant les valeurs agiles au niveau de l’entreprise. Entre autre choses.

image

Pause déjeuner

Pas de pause déjeuner bien calée dans le temps pour cette journée open-space ! Les session occupent les créneaux horaires sans discontinuer. Aux participants de faire une pause quand ils le désirent !

image

On est un peu plus en mode picnic que la veille, d’ailleurs les tables ont disparu au profit de quelques « mange debout », mais on s’assoit aussi par terre.

image

Cela ne veut pas dire que la qualité n’est pas au rendez-vous. Au contraire ! Je n’ai aucune raison de renier mes éloges d’hier. Jugez-en !

image

De mon côté, j’ai passé cette pause déjeuner avec Pierre Hervouet, Joumana et Pierre Neis. Pierre Neis nous parle (et nous montre des photos) de #play14, un rassemblement autour des agiles games qu’il co-organisait au Luxembourg. Prochaine étape : en faire une sorte d’Agile Tour des agile games !

Le bureau du SUG en mode Happy

Christopher Mann était le photographe de ce ScrumDay (il avait fait un excellent boulot lors d’Agile France, une bonne raison pour moi de le recommander pour cet évènement). J’ai suivi le mouvement, quand lui-même et le bureau se sont dirigé vers l’extérieur pour ce qui semblait une photo de groupe. Le résultat est visible sur le reportage du ScrumDay, mais j’ai aussi pris mes propres clichés…

image

Backlog, cher boulet…

J’avais aussi soumi mon propre sujet. En quelque sorte une reprise d’un de mes thèmes préférés sur le backlog produit, à la fois vision de ce qu’il y a à faire et frein du changement.

image

Au final, on trouve deux grand types de situation :

  • Les projets agiles « classiques » où la vision d’un périmètre complet est plutôt une chose souhaitée. Le backlog Scrum rempli bien son office car il donne une vue partagée à tous les acteurs du « reste à faire ».
  • Les projets innovants pour lesquels on essaie de limiter le stock par diverses approches (parfois combinées) : approche type « kanban » où l’on limite volontairement et activement le nombre d’items dans le backlog, où backog à granularité différentielle, à deux ou trois niveaux.

Dans le cas d’une approche « kanban » nous nous sommes posé la question d’évacuer, c’est à dire supprimer les items de plus basse priorité dépassant le WIP. Nous en sommes arrivés à la conclusion qu’il n’y a aucun dommage à le faire : si l’item est important, il reviendra !

J’ai aussi évoqué les sujets qui m’interpellent en ce moment : combiner un backlog (limité) avec une approche type impact mapping et/ou Lean Canvas. Mais nos réflexions n’ont pour l’instant pas abouti…

image

Clôture des ScrumDays

Ce grand open-space s’est terminé par une retrospective type « tour de parole ». Un tour de parole à près de 200 personnes, il faut dire !

image

Il me manque le courage (ou la motivation) pour en être. Je préfère passer un peu de temps avec Samira Batahouche d’IBM qui représentait Big Blue au bureau l’an dernier et avait accueilli le ScrumDay à Bois Colombe l’an dernier.

Le stand de Cloudbees est juste à côté, j’en profite pour fixer pour la postérité Nicolas De Loof en hôtesse d’accueil…

image

Scrum.org était aussi partenaire du ScrumDay cette année. Je me suis vu interdire de prendre le stand en photo, une première pour moi. J’ai moi-même étendu cette interdiction à la keynote de clôture faite par son représentant (je ne me souviens même plus de son nom, pourtant il s’est cité lui-même durant sa présentation).

J’avais aussi décidé de ne prendre aucune note de l’intervention pour faire bonne mesure. Grand bien m’en a pris : elle manquait complètement d’intérêt, j’ai failli quitter la salle. Finalement je suis resté et j’ai consulté mon fil Tweeter pendant le reste de la présentation.

Si j’étais parti, je n’aurais pu prendre en photo l’équipe du French SUG, et cela aurait vraiment été dommage. Grand merci à toute l’équipe pour ce bel évènement ! De droite à gauche : Anne, Christopher, David, Arnaud, Valérie, Karine, Laurence et Xavier.

image

Voilà, il est temps de replier tous le matériel, et de tout remettre dans les cartons … jusqu’à l’an prochain.

image

Note à moi-même

Pour ce qui est du format tout d’abord : le ScrumDay (ScrumDays, donc comme je l’ai écrit par ailleurs), ça marche ! Les open-spaces dans des « coins de salle » ne sont toutefois pas une configuration idéale. il faudra trouver mieux et surtout moins bruyant !

Cette année, le thème était la « culture produit ». En fait cela ne me paraissait pas si évident au vu du programme. Maintenant, est-il nécessaire d’avoir des thèmes annuels ? Des tracks thématiques feraient assez bien l’affaire.

Concernant le lieu, eh bien il a clairement la taille voulu pour accueillir l’évènement. Le hall central (qui hélas n’était pas central) permettait une bonne circulation. Les stands des sponsors étaient disposés sur le pourtour.

Question sponsors, leur nombre était réellement à l’inflation, et cela fait un peu ressembler le ScrumDay à une expo (sans compter un traitement pas différentiant des platinums) … La raison est bien entendu le coût d’organisation, car le lieu est apparemment très cher, malgré son éloignement de Paris.

J’avais crains que cet éloignement, justement,  soit une cause de désaffection, d’autant que la venue en voiture n’est pas vraiment facilitée (pour ne pas dire franchement découragée), mais il semble au final que ce facteur n’ait eu aucune influence.

Bref, un bel évènement, avec deux fois plus de plaisir pour deux fois plus de durée !

Une dernière chose : nous n’en avons pas fini avec ce ScrumDay : je vous ai promis un 4ème volet : ce sera un « bonus track », je n’en dis pas plus. Je ferais aussi un petit post sur mon atelier sur l’acceptance testing.

Agile Playground #8 (en images) !

Pour changer un peu, l’Agile Playground de ce mois ne déroulait pas chez Valtech, mais dans les locaux de CLT Services. Un espace un peu plus réduit, donc une contrainte de places plus importante. Elle avait été fixée à une trentaine de personnes. Je m’étais dépêché de m’inscrire. Youpi, tant pis pour les autres …

3 jeux étaient en lice. J’avais fixé mon choix sur celui de Yannick Ameur

Atelier RH Team

Comment recruter agile ? Peut-on recruter agile ?

Yannick était ce soir-là le maitre de cérémonie pour ce défi !

apg8-yannick

Votre mission, si vous l’acceptez consiste à créer la fiche poste de votre job que l’on va afficher et trier.

apg8-rh2

S’en suivent les entretiens avec les candidats. Tout d’abord en mode “old school”. Avec vôtre serviteur pour être honnête… Puis en mode “agile” en faisant participer toute l’équipe.

apg8-rh4

Après, c’est le débriefing et les leçons tirées de l’exercice.

apg8-rh3

Yannick nous fait le plaisir de mettre à notre disposition le support servant de trame à l’atelier. Le voici donc.

Cocktail

On termine comme à l’acoutumée autour d’un verre et de longues discussions qui nous font toujours rentrer bien tard dans nos penates !

apg8-cocktail1

Nos discussions ont pas mal tourné autour du coaching : qu’est-ce qu’un coach agile ? Est-ce un coach sportif, un coach miroir “posture basse”, un expert, un mentor, etc… ou un mixte de ces différents rôles ? Le question est trop large pour que je m’étende dessus aujourd’hui. Un autre jour peut-être dans ces colonnes …

Evaluation des compétences et suivi de carrière

Comment évaluer et donner un sens au suivi et à l’évolution de carrière en informatique ? La traditionelle approche de l’escalade de l’échelle hiérarchique n’a pas réellement de sens et n’intéresse généralement pas les informaticiens. De plus il n’y a pas de place pour tout le monde sur cette foutue échelle.

Cette présentation date d’il y a 8 ans (déjà…) et propose une approche inspirée du SWEBOK et du “Professionnal Software Development” de Steve McConnell au sujet duquel j’avis déjà posté une note de lecture.

Note de lecture : New Programmer’s Survival Manual par Josh Carter

Note : 4 ; Manque de ciblage clair

Sur le papier, le public cible de ce livre est claire : donner au jeune développeur arrivant dans la vie professionnelle une boite à outil pour lui permettre d’acquérir plus rapidement les bonnes habitudes et les bons comportements. C’est pourquoi les 225 pages de cet ouvrage au format inhabituel, plus proche du roman que du livre informatique dont nous avons l’habitude, sont découpés en 33 « tips ». Jusqu’ici tout va bien. En fait, cela ressemble au format emprunté par son ainé, le « pragmatic programmer ». Bonne également, l’idée de découper l’ouvrage en 4 parties :

  • Professionnal programming : 14 tips sur 2 chapitres, couvrant près de 100 pages, donc pas loin de la moitié du livre.
  • People skills : 9 tips sur presque 50 pages et toujours 2 chapitres.
  • Corporate world : Les deux chapitres composant cette partie regroupent 6 « tips » sur presque 50 pages aussi.
  • Looking forward : clos le texte avec 3 tips sur un seul chapitre.

Les conseils toutefois, quand on rentre dedans semblent un peu disparates. C’est sans doute pour cela que l’auteur à attribué 3 niveaux de maturité aux conseils qu’il prodigue : ceinture blanche, ceinture marron et ceinture noire. De mon point de vue c’est l’erreur fondamentale du livre. Au lieu de cibler le débutant l’auteur tente d’adresser différents publics et finalement ne satisfait correctement aucun d’entre-eux. C’est dommage car l’auteur écrit fort correctement et son savoir-faire et la pertinence de ses idées est réelle.

Le livre a voulu cibler trop large en parlant à différents publics, mais aussi en élargissant son débat depuis le craftmanship jusqu’aux aspects sociaux dans l’entreprise. On se trouve ainsi avec du code (Ruby) en début d’ouvrage et des questions sur les cycles de développement produit vers la fin. Ce n’est pas une diversité qui me choque en soi, mais j’ai du mal à y trouver une cohérence dans le propos.

En lisant ce livre, je n’ai pu m’empêcher de le comparer à « SQL antipatterns ». Ce dernier réussit là où celui-ci échoue. En effet ce premier à choisit délibérément de s’adresser au développeur souvent peu expert (et peu intéressé) par les questions ayant trait aux bases de données et à la modélisation de celles-ci. Je pense que ce « new programmer’s survival manual » aurait dû atteindre la qualité du « SQL antipatterns » en ciblant son public et surtout en maintenant sa cible dans son contenu et aurait peu et dû atteindre le même niveau de satisfaction.

C’est donc une déception.

new-prog-survival-manual-pragprog

Référence complète : New Programmer’s Survival Manual, Navigate your workplace, cube farm or startup – Josh Carter – Pragmatic Bookshelf 2011 – ISBN : 978-1-93435-681-4

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup

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

Note de lecture : My Job Went to India (and all I go twas this lousy book), 52 ways to save your job par Chad Fowler

Note: 7; Une ligne de conduite pour sauvegarder son employabilité: utile bien au-delà du contexte cite dans le titre, et à reconsulter régulièrement.

Derrière un titre amusant (et une couverture qui ne l’est pas moins), Chad Fowler nous livre un propos tout à fait sérieux et profond: comment rester employable et éviter l’obsolescence. L’approche de l’auteur est à la fois simple et originale: il faut considérer sa carrière comme un produit. Cela conduit à une approche en 5 parties, plus une “supplémentaire”.

Choisir son marché: c’est orienter sa carrière selon ses capacités mais aussi par rapport aux opportunités de marché. C’est aussi garder le contrôle de la direction que l’on souhaite emprunter et éviter de se laisser embarquer dans des voies sans issues.

Investir dans votre produit: c’est définir et mettre en œuvre le plan d’action pour prendre la direction que l’on souhaite.

Exécuter : Ou comment se comporter et agir au jour le jour dans son poste. C’est aussi se remettre en cause continuellement et avoir une idée claire de sa valeur et de la valeur (ou du manque de valeur) de son travail. 

Marketing : comme son nom l’indique, c’est se vendre en mettant en valeur son travail sans penser que l’on sera automatiquement connu et reconnu par la simple production de livrables de qualité. C’est donc aussi savoir être un bon communiquant.

Maintenir son avantage : C’est éviter l’obsolescence en restant en mouvement, en ayant une gestion « agile » de sa carrière.

Si vous ne pouvez les battre… : Ce dernier chapitre adresse la position que l’on peut prendre par rapport à l’offshore, non en essayant de l’éviter, mais en prenant une position forte dans ce processus.

L’auteur est tout à fait aguerri sur son sujet : il a été manager sur la mise en place d’une entité offshore dans son entreprise. Chaque item est traité sur 2 à quatre pages environ, ce qui évite l’ennui, dans un style plutôt agréable et illustré d’exemples, mais dans un anglais parfois un peu sophistiqué qui en complique un peu la lecture. Chaque item se termine par des points de « mise en mouvements », certains sont bons et d’autres un peu forcés. Au final ils sont un peu nombreux, mais on peut utilement piocher dedans.

Un ouvrage qui invite à la réflexion, donc.

job-went-to-india

Référence complète : My Job Went to India (and all I go twas this lousy book), 52 ways to save your job – Chad Fowler – Pragmatic Bookshelf 2005 – ISBN: 0-9766940-1-8 (une seconde édition sous un autre titre existe qui fera l’objet d’une note de lecture ultérieure)

My Job Went to India: And All I Got Was This Lousy Book (Pragmatic Programmers)


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

Note de lecture : How to Become an Exceptional DBA, 2nd edition, par Brad M. McGehee

Note : 6 ; Toutes les facettes du DBA idéal !

Brad McGehee serait-il aux DBA ce que Chad Fowler est au développement logiciel? La lecture de cet ouvrage le laisse penser. En tout cas l’objectif de ce livre recoupe celui du « passionate programmer » : exceller dans son métier.

12 chapitres et 170 permettent et suffisent à l’auteur pour prendre la mesure de ce que devrait être le code de conduite du DBA exceptionnel. Et il est vrai (surtout pour moi qui en cherche un) que cela fait rêver. Le chapitre 2 est d’ailleurs consacré à l’énumération et à l’explication des trait important attendus de ce DBA.

Le chapitre 3 invite le lecteur à choisir sa voie, car on ne peut tout savoir. Et pour compléter cela, le chapitre 4 donne des pistes pour améliorer et entretenir son savoir. Savoir qu’il faudra peut-être valoriser ensuite : le chapitre 5 évoque les certifications, celles qui existent qu’elles soient utiles ou inutiles. L’auteur finalement évalue l’importance de ces certifications.

Les 4 chapitres suivants évoquent la valorisation du DBA exceptionnel : participation aux communautés (chapitre 6), gestion de carrières (chapitre 7), gestion et valorisation de l’image (chapitre 8 et 9) et finalement recherche d’un nouvel emploi (chapitre 10).

Les derniers chapitres reviennent sur les points évoqués tout au long du livre, en les synthétisant sous forme d’un code de conduite (chapitre 11) et d’un résumé des « best practices » du DBA exceptionnel.

Je dois dire que j’ai pas mal apprécié cet eBook, outre que je converge pleinement sur l’éthique développée, il m’a aidé à comprendre ce qu’est un DBA. Cela dit, et quoi qu’ait voulu exprimer l’auteur, il est essentiellement centré autour du « DBA production ».

exceptional-dba-2edt

Référence complète : How to Become an Exceptional DBA, 2nd edition – Brad M. McGehee – Simple Talk publishing 2009 – EAN: 978 1 9064 22 9

Note de lecture : Professional Software Development, par Steve McConnell

Note: 8; Comment faire du développement logiciel une profession… et une carrière!

L’informatique constitue-t-elle une véritable profession d’ingénierie ? C’est à cette difficile question que tente de répondre Steve McConnell dans ce livre. Le constat initial est plutôt sévère, c’est l’objet de la première partie du livre. Les pratiques d’usage les plus répandues sont encore et toujours le « code and fix » et le noyau de connaissances universellement partagé par les professionnels reste considérablement plus faible que dans les disciplines d’ingénierie classiques établies de longue date. Ce constat amène l’auteur à considérer deux dimensions à la mesure de maturité de la profession :

  • Le corpus de connaissance : il se décline en un noyau stable (pour lequel la demi-vie des connaissances est de 50 ans) et un « body of knowledge », plus large, dont la demie-vie est de 10 ans.
  • Les éléments statutaires de la profession : certification, code d’éthique, sociétés professionnelles (telles que IEEE et ACM), développement professionnel, licences et accréditations.

Le second thème développé par l’auteur est le « professionnalisme individuel », où comment, à titre individuel, s’engager dans une voie de développement personnel. Là encore l’auteur présente ce développement en étapes, depuis le « mode héros », auquel succède la prise de conscience, le partage au sein de communautés, l’étape la plus haute étant le partage par la publication de textes.

Après le professionnalisme individuel, viennent les organisations professionnelles : comment structurer, favoriser la montée en compétence et la reconnaissance du professionnalisme des membres d’une organisation ? Plutôt que de passer en revue les chapitres de cette partie, intéressons-nous plutôt au « Construx Professional Development Program ». Dans ce programme de développement que l’auteur a mis en place dans sa propre société, les consultants sont évalués et évoluent sur des échelles de compétences par discipline d’ingénierie. Ces disciplines d’ingénieries sont définies au sein d’un organisme, le Swebok (Software Body Of Knowledge, émanation de l’IEEE). Il définit une échelle allant de 9 à 15, 10 “knowledge area” déclinés en 4 niveaux (introduction, compétence, leadership et maitrise). Chaque étage de l’échelle définit le nombre de KA pour lesquelles il faut avoir l’un des 4 niveaux. Cette échelle permet de définir des plans de progression professionnelle, définissant les actions à mener, les formations à suivre, etc..

Si cet ouvrage est surtout une source de réflexion plus profonde sur ce que veux dire ou devrait vouloir dire être un professionnel de l’informatique. Il établit les bases de ce que devrait être une véritable reconnaissance de l’informatique en tant que profession. Et c’est là une réflexion que devraient mener toute société de service informatique. Il est clair que nous en sommes loin.

prof-sofware-dev-mcconnell

Référence complète : Professional Software Development – Steve McConnell – Addison Wesley 2004 – ISBN: 0-321-19367-9

Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers


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