Ma première fois

Publié le 20 April 2010, par mere-teresa

De nombreuses personnes m’ont déjà entendu dire que je continuerais à faire de l’informatique jusqu’à ce que je vois un projet sortir en temps et en heure. C’est une blague récurrente, qui reflète, malheureusement le manque de soin apporté à l’évaluation des risques, des ressources et des spécifications dans les projets de développement web.

Pour faire écho à l’article de Damien Mathieu, j’ai déjà rencontré de très bons chefs de projet. Mon expérience de consultante-formatrice m’a amenée dans des entreprises privées aussi bien que dans des établissements publics, au contact d’équipe variées. J’ai toujours constaté une certaine fatalité envers le retard dans les projets web.

Et pour la première fois, lors d’une mission, nous livrons des features au rythme prévu. Parfois, cette date a été ré-ajustée au fil du développement, parfois la feature B devance en produit livrable la feature A et se retrouve livrée plus tôt. Tout va bien, me direz vous, alors plutôt que de pointer encore et encore les erreurs des projets, les erreurs des développeurs, je vous propose d’examiner les conditions de cette réussite.

Maîtrise des développements

Pour une fois, ma mission de développement se déroule chez un éditeur de logiciels, et pas dans une SSII ou web agency. Les contraintes sont différentes : ajouter des nouveautés permet de continuer à faire évoluer le site web. Et maintenir l’existant permet de gagner la confiance des utilisateurs. Le besoin de qualité est important pour un code pérenne et maintenable, cette qualité est plus importante que le besoin de livrer rapidement. Les dates limites existent néanmoins et permettent de border les tâches, et de découper les features en tâches.

Direction du projet

Les projet ont deux têtes pensantes : un lead développeur, une chef de projet (commune aux projets). Et en plus, un directeur technique est disponible, pour les points plus critiques ou les choix techniques d’évolution du projet (modification du système de traduction, par exemple). Les technologies les plus performantes sont envisagées pour remplacer les technologies classiques. Cela donne du dynamisme au projet, et attire des développeurs de qualité dans l’entreprise.
Malgré un recrutement soutenu, les développeurs sont bien intégrés aux équipes par des formations aux outils, et comme habituellement, des tâches autonomes et indépendantes des autres du projet à réaliser. Le temps de midi est également mis à profit pour la convivialité.

Des horaires souples

Pour mes besoins personnels, je préfère arriver tôt et repartir tôt. D’autres collègues préfèrent arriver plus tard (après 10h) et j’imagine qu’ils partent plus tard. La pause déjeuner n’est pas non plus chronométrée. Nous sommes managés à la tâche plutôt qu’au créneau horaire, et responsabilisés sur notre tâche. Les dates de planning nous ont permis de déterminer un rythme à tenir pour la sortie de notre feature.

Rencontres fréquentes

Malgré l’open space, dont on sait qu’il est moins bon pour la productivité que les bureaux individuels, les développeurs s’isolent pour se concentrer. Les rencontres sont donc provoquées par un stand-up quotidien, qui a lieu après la pause déjeuner. Parfois, les développeurs d’un même projet — qu’on croirait connectés — se retrouvent à échanger, parfois c’est une simple énumération de ce sur quoi chacun travaille.
Même si nous travaillons sur des logiciels différents, nous avons des fonctionnalités communes, pour résoudre les mêmes problèmes, nous communiquons entre les projets. Les solutions éprouvées sont alors dépistées, ainsi que les impasses.

Challenge technique

En plus d’utiliser des technologies de pointe, toutes les deux semaines, une journée consacrée à la technique est organisée, les développeurs comme l’infra se retrouvent à mettre en place des nouveautés techniques dans l’application, à faire des tests sur les futurs produits techniques, à réparer de petits agacements dans le code ou la configuration qui ralentissent tout le monde.
Cette journée de technique pure, sans but de plaire aux commanditaires (ou actionnaires) des logiciels est toujours un jour agréable. Nous passons en production des nouveautés qui ont été testées précédemment, ou des ajustements qui augmentent le confort de développement.

Convivialité

La pause repas ayant déjà été évoquée, j’ajouterais les outils d’Instant Messaging, la mise à disposition de consoles de jeux (et canapés), le café à volonté, ainsi que la présence d’un outil de “Perles” qui recueille les propos les plus amusants, sortis de leur contexte, évidemment. Ces différents outils renforcent les liens inter-personnels et la confiance entre les développeurs.

Pour terminer, les développeurs sont considérés comme essentiels à la production de valeur dans l’entreprise. Le fait qu’ils soient nombreux les rend majoritaires par rapports aux autres services (marketing, RH ou comptabilité). La direction des projets fournit le matériel nécessaire au confort de chaque développeur (écrans, lampes, etc.) et les responsabilise sur leur code et le code de leur projet.
Sans utiliser de l’eXtrême Programming ou du Scrum, quelques pratiques issues des méthodes agiles améliorent le confort des développeurs et la qualité des produits.

billet invité rédigé par Sarah Haïm-Lubczanski

Enquête salaire des Travailleurs Du Web : Chefs de projets fonctionnels

Publié le 6 February 2008, par Babozor

Et non, je n’avais pas oublié la merveilleuse enquête des salaires des Travailleurs Du Web… j’avais juste super pas le temps de finaliser mes bidouillages de graphiques et autres statistiques.
Voici donc les résultats pour les Chefs de projets fonctionnels (suivront d’ici peu pour les Développeurs et les Chefs de projets techniques, les trois catégories les plus représentés dans l’étude…)

Légende: Pour tous les graphiques, j’ai mis la moyenne des salaires en vert, le salaire le plus bas en bleu et le plus haut en jaune…

Sexe
cp_sexe.jpg
Là on voit clairement que la différence de salaires entre les hommes et les femmes n’est pas un mythe, mais bien une réalité… entre 15 et 20% moins bien payé pour le salaire moyen. Le salaire le plus bas est lui aussi 20% moins que celui des hommes et pour le salaire le plus haut la différence atteint 30%. Cela ne fait que confirmer ce que tout le monde dit.

Age
cp_age.jpg
A part la partie 0 (qui correspond aux personnes qui n’ont pas souhaité communiquer leur âge lors de l’enquête) on voit une courbe ascendante avec néanmoins deux pics autour de 25 et 31 ans (ce qui correspond plus ou moins à la fin de l’époque junior et au début de l’époque sénior à peu de chose près) ce qui semble cohérent avec les remarques glanées ici et là.

Expérience
cp_experience.jpg
La aussi la courbe est en croissance quasiment constante avec un pic autour de 8 ans d’expérience. On peut remarquer aussi un plafonnement des salaires moyens entre 3 et 7 ans d’expérience alors que les salaires max jouent au yoyo.

Type d’entreprise
cp_type.jpg
Là non plus, pas vraiment une révélation, les annonceurs et les start-up sont ceux qui paient le mieux, alors que les Agences de Com et WebAgency sont les vilains petits canards des gros chèques.

Taille de l’entreprise
cp_taille.jpg
Là par contre une semi-surprise, puisque le salaire moyen semble suivre une progression similaire à la taille de l’entreprise (cela reste un salaire moyen) avec un salaire moyen de 40 k€ pour les entreprises de 500 personnes et plus. Je ne m’attendais pas à ce résultat, mais plutôt à un pic pour les entreprises autour de 50 salariés alors que c’est là où les prix sont les plus “serrés” (le moins d’écart entre le salaire moyen et le plus et moins bien payé)

Type de contrat
cp_contrat.jpg
Le CDI reste le type de contrat stable qui paye le mieux, mais avec les écarts les plus importants…

Quelle conclusion?
L’écart de salaire entre hommes et femmes dans cette profession est assez frappant. Il est aussi intéressant de voir les paliers de salaires par âge et expérience…

Et vous vous en pensez quoi de ces chiffres, ils vous semblent cohérents ou complètement ubuesque par rapport à votre expérience?

Conduite de projet Intranet

Publié le 6 February 2008, par Babozor

livre_proj.jpg
(oui je sais je fais toujours des têtes bizarres quand je me prends en photo avec PhotoBooth, je prends rendez-vous avec mon psy tout de suite).

Aujourd’hui un livre intéressant pour tous ceux qui manquent un peu de théorie sur la conduite de projet… un petit livre qui s’avale facilement en une heure (une centaine de pages, petit format) et qui traîte de la conduite d’un projet intranet (quelques petites spécificités par rapport à un projet classique mais la méthodo est sensiblement la même).
Pour les chefs de projets fonctionnels confirmés se sera principalement un rappel des méthodes que tout le monde est censé suivre (mais que personne n’a le temps de suivre).

Un bon livre pour introduire la méthodo de suivi de projet.
Et vous c’est quoi votre livre de chevet de chef de projet? (perso j’en ai pas vraiment…)

Conduite de projet technique: les 5 pièges a éviter

Publié le 4 February 2008, par Babozor

piege.jpg

Lors de la conduite d’un projet, les pièges sont nombreux surtout niveau technique, voici donc une petite liste des écueils connus à éviter à tout prix.

1. Conception fermée
C’est souvent une des difficultés majeurs pour le suivi d’un projet technique. Le projet en cours de route évolu, change, se métamorphose… certains fonctionnalités disparaissent, d’autres apparaissent, des contraintes nouvelles viennent s’ajouter au projet. Tous ces changements doivent pouvoir être pris en compte au fur et à mesure et ne pas être un frein pour le bon déroulement technique du projet. La conception aussi bien de la plateforme de production, que de la base de donnée ou de l’applicatif doit être flexible et ouverte… donnant du champ à des modifications.

2. Outils performants
C’est un des pièges récurrents, principalement dans les grandes structures, trouver des outils performants qui ne freinent pas le développement. Cela peut consister en des machines vieillottes ou qui tombent en panne, des problèmes réseau, des serveurs de l’ère du crétacé… ou simplement des procédures de mise en ligne trop longues qui vous bouffent votre temps de développement.

3. Versionning / sauvegarde
Un de vos soucis (si vous suivez un projet) est de s’assurer de deux choses:
– que des sauvegardes régulières sont faites aussi bien des données que du code source, à des intervalles réguliers, en essayant de varier les supports et en archivant régulièrement (je me souviens plus où j’avais lu ça, mais une étude avait montré qu’environ 20% des boites high-tech fermaient les portes après un accident de matériel faute de vraie politique de sauvegarde).
– que les développeurs ne se marchent pas sur les pieds, et donc utiliser un outil de versionning… éviter les cas classiques, qui sont: pierre enregistre un vieux fichier qu’il avait en local et bousille une semaine de boulot de paul, ou encore pouvoir revenir à une version précédente du code, très très pratique.

4. L’euphorie post-démo
Souvent pour sortir une démo à temps, on est tenté (et certaines fois on a pas trop le choix) de couper dans certaines principes qu’on c’est fixé… on fait des dev un peu plus cradocs, on néglige certaines parties, etc… rien de dramatique en soit, si on redresse au plus vite la situation. Le risque majeur est qu’on ait pas le temps de redresser les petites cochonneries qu’on a pu faire pour que la démo marche et que l’on continue dans cette voix. Pansement sur jambe de bois, sur bout de scotch, sur bout de ficelle et on va à moyen terme dans le mur.

5. Garder le cap
C’est une des tâches les plus dures et c’est un des rôles essentiels du Chef de projet technique: emmener tout le monde dans la même direction, avec le moins d’accrocs possibles, avoir une double vision: macroscopique du projet, mais aussi aller dans les détails du code ou de la conception de données pour que le projet fonctionnellement et techniquement ailles dans la bonne direction.

Il doit certainement ex exister d’autre mais ce sont les 5 principaux écueils à éviter quand on gère un projet technique. Et vous des expériences ou remarques à partager?

Chef de projet Junior: le juste prix?

Publié le 17 January 2008, par Babozor

cdp.jpg

[image honteusement repompée sur un site trouvé via Google Images… pouquoi quand on tape “chef de projet” on a que des images de vieux ou presque?]

Hier, un des lecteurs/commantateur régulier m’a envoyé un email pour me demander en gros le prix d’un Chef de projet fonctionnel junior, puisque ses sources lui donnaient des prix plus que variables (de moins de 30 k€ à plus de 50) pour entamer une négociation sérieuse.

Je n’ai pas vraiment d’idée sur la question, mais je me suis dit que certains des lecteurs doivent avoir une idée, une connaissance ou une expérience sur le sujet….

Donc pour vous, combien vaut un Chef de projet fonctionnel Junior?

[petit aparté] Au passage “salaire de développeur” ça n’a rien de péjoratif (puisque certains développeurs sont très décemment payés, et pour certains beaucoup plus que les chefs de projets, même ceux qui ne sont plus junior). [/petit aparté]