Affichage des articles dont le libellé est Organisation. Afficher tous les articles
Affichage des articles dont le libellé est Organisation. Afficher tous les articles

dimanche 6 juillet 2014

Développeurs, devenez chef de projet

Il y a quelques temps, on pouvait voir pas mal de blabla sur le web qui disait que les développeurs devaient s'affirmer dans leur rôle, qu'on pouvait rester développeur après 30 ans, qu'on n'était pas obligé de passer chef de projet, etc. Belles paroles, peut-être réalistes dans les chez des éditeurs de logiciel, des clients finaux ou en tant que freelance MAIS certainement pas en SSII. Et les SSII, ça concerne 80 % des développeurs.

Alors arrétez le masochisme les mecs. Si vous êtes en SSII, allez le plus vite possible vers le poste de chef de projet (CP pour la suite de l'article because la flemme).

Je vous dis cela en connaissance de cause et parce que je regrette de ne pas avoir maintenu ce choix pour mon projet actuel. Les projets sur lesquels j'ai eu la meilleure expérience sont ceux pour lesquels j'occupais ce poste. Il apporte deux choses pour moi : confiance et liberté. Confiance d'abord parce qu'en devenant CP, j'ai eu l'impression d'arriver dans une communauté de gens éclairés. Je n'étais plus un connard de développeur, j'étais un mec qui avait accès à la stratégie liée à un projet (si merdique soit-elle), au budget, au contrat. Croyez-moi, le regard qu'on vous porte change. On vous donne les rennes du projet et on vous fait confiance, parce qu'on ne peut pas faire autrement. Vos supérieurs ont d'autre chats à fouetter (c'est ce qu'ils disent en tout cas), ils ne seront pas là pour vous materner au quotidien.

De cette confiance jaillit la liberté. Tant que vous jouez le jeu, c'est à dire que vous suivez correctement votre budget, mettez en place les actions qui auront été discutées lors de votre suivi (mensuel) et que le client ne vous perçoit pas comme un psycopathe pervers, vos supérieurs vous foutrons une paix royale.

Le meilleur pour la fin : vous avez accès à votre client. Vous pouvez pousser vos idées au vous aurez accès à toute l'information sur la situation du projet. Ça vaut de l'or.

Après, tout dépend de votre attitude. Votre chef actuel ne comprend pas ce que vous faites, ne soutient pas vos idées et ne tient pas tête au client ? Il a lui-même chiffré le projet et vous mets la pression pour livrer dans ses contraintes non réalistes ? Ça ne donne effectivement pas une bonne image de la fonction. Et heureusement que vous vivez ça : il vous donne l'exemple à ne pas suivre.

En tant que développeur expérimenté et passionné, vous avez tout pour faire un bon CP. Vous savez estimer sans trop vous planter en prenant en compte le fait que des développeurs junior vont faire le taf (car vous vous rappelez comment vous étiez à leur place), les développeurs vous font confiance et vous avez déjà prouvé votre valeur à vos supérieurs. Le gros plus est que vous savez ce qu'il y a à faire, vous connaissez le domaine métier sur lequel vous travaillez (ou êtes à même de monter en compétence dessus à la vitesse de la lumière) et êtes à même de mettre les mains dans le cambouis si nécessaire pour sauver la situation.

Les tâches de suivi ne sont pas compliquées à faire. Sur mon projet précédent, le suivi du budget me prenait entre 30 min et 1h par mois. Je passais 1h en suivi de projet hebdomadaire avec mon client. Pour le reste, je faisais de l'encadrement technique, de la conception, du chiffrage, de l'indus. J'étais seul membre expérimenté de l'équipe. Bref, j'occupais 80 % de mon temps sur des tâches de développeur confirmé. Surtout parce que j'ai un mal fou à déléguer :p. Et j'ai pu développer des supers outils dans les technos qui m'intéressaient pour me faciliter la vie. J'avais pas mal de boulot, mais prenez en compte le fait que je bossais au 4/5e.

Pourquoi rester développeur ? À plus de 30 ans, vous êtes sur un échelon trop élevé : vous coutez trop cher. Si vous avez un temps soit peu d'XP sur une techno donnée (genre du PLSQL ou mieux, du Cobol), vous pouvez être sûr qu'on va essayer de vous bloquer en régie sur cette techno à perpétuité. C'est ce que je ferais en tout cas : je négocie un bon TJM et je vous place. Vous êtes bon : le client ne se plaindra pas parce qu'il a l'habitude de se voir refourguer que des clampins par vos concurrents. La conséquence de ça est que vous allez voir un beau gel de salaire. En plus vous bossez sur des technos de merde. Franchement, de ce que j'ai connu, il n'y avait rien de bandant. Considérez que vous n'allez jamais travailler sur une tech qui a moins de 10 piges (même s'il peut y avoir des exceptions, bien sûr). Oubliez Angular, Mongo et Node. Pensez Cobol, ksh, Java 1.5 et .Net 3.5. Sans déconner : pourquoi se faire chier !?

Pour conclure, réfléchissez-y. Retrouvez un peu de liberté et accédez à un meilleur salaire tout en gardant un pied dans la techno. Innovez par rapport à vos chefs précédents qui n'ont rien compris à la gestion de projet et d'équipe. Mettez en place du Kanban si ça vous fait réver. Dites merde à votre client quand il le faut. Rester développeur en SSII ? J'ai essayé et je le regrette. Pour moi c'est terminé.

Allez, prenez soin de vous et à la prochaine.

dimanche 19 janvier 2014

GTD Reboot PT 2

Maintenant que j'ai décrit le concept de la méthode GTD dans l'article précédent, voici comment je tente de la mettre en œuvre au quotidien.

J'ai deux types de boites d'entrées : les boites mail (perso et pro) et un carnet dans dans lequel je note les idées qui me viennent. Mon système est composé de d'une chemise à intercalaires (oui oui, en carton) et d'une mind map dans le logiciel freemind pour le boulot. Pourquoi 2 ? Parce qu'hors du boulot, j'utilise habituellement peu l'ordi. La mind map, quant à elle, est intéressante car elle permet de tout voir en une fois et de réorganiser les éléments rapidement : j'ai essayé auparavant un wiki ou un simple fichier texte, ce n'est pas aussi synthétique.

J'utilise GTD conjointement avec la Pomodoro Technique dont j'ai déjà parlé ici et là. Ceci étant dit, je vais utiliser le terme tomate pour parler d'une pomodoro, c'est à dire 30 minutes de travail. Parce que ça m'amuse.

Le matin, je prends une tomate pour vider ma inbox outlook et mettre à jour ma mind map. Je vais réécrire pour faire genre. Je vide ma inbox. À un certain moment, je le faisais avec plus ou moins de sérieux mais maintenant, je traite tout. Si je peux répondre ou faire l'action en moins de 2 minutes, je fais. Si le mail contient de l'information utile sur projet, je l'archive. Si ce n'est pas utile de conserver un mail, je le supprime immédiatement.

Je termine ensuite d'organiser ma journée selon le principe de la Pomodoro Technique, en planifiant un total entre 10 et 12 tomates (quand je peux travailler seul). Je note les les prochaines actions qui prennent plus de deux minutes dans la mind map.

Pendant les pauses, éventuellement, je revois la mind map et je note sur mon cahier (ma 2e inbox) les idées qui me viennent en tête.

Pour tout ce qui est personnel, c'est un peu le même principe : je vide ma boite mail et essaie de faire les actions courtes immédiatement. Habituellement, je n'utilise pas la Pomodoro Technique hors du travail, sauf pour des trucs rébarbatifs ou quand je veux me limiter quand je surfe sur le Net.

Ceci étant dit, tout n'est pas si simple. J'aborderai les difficultés et les limites de ces pratiques selon moi dans un prochain article.

vendredi 22 novembre 2013

GTD Reboot PT 1

La semaine dernière, j'ai relu le bouquin Getting Things Done (GTD) de David Allen ; enfin, je ne vais pas vous mentir, je l'ai lu en Français… Il s'agit d'un bouquin de d'organisation life hacking assez connu orienté cadre sup. La grande classe. Dans ce livre Allen propose une méthode pour gagner en productivité sans stress. L'édition française est d'ailleurs sous-titrée l'art de l'efficacité sans le stress. Tout un programme…

Dans ce premier article, je vais décrire succintement en quoi consiste cette méthode. Je détaillerai la façon dont la mets personnellement en œuvre dans mon quotidien dans une prochaine note. Je terminerai par une synthèse. Comme ça, ça fera des articles pas trop longs et un peu de teasing de bon aloi.

C'est quoi GTD ?

La méthode GTD propose d'organiser ses projets sous forme de listes d'actions. Ces actions sont stockées dans un système et sont revues régulièrement dans le but d'être toutes effectuées.

Cela signifie que l'ensemble des choses que nous avons à faire doit être collecté, trié et organisé de façon à ce que nous sachions toujours quelle va être notre prochaine action.

Les objectifs du GTD sont :

  • De nous aider à extraire de l'information qui nous arrive des actions concrètes et unitaires que nous pouvons réaliser dès que possible.
  • D'introduire une routine dans la façon dont nous appréhendons les actions que nous avons à mener.
  • De tracer tout ce que nous avons à faire de façon à ne pas avoir à y penser constamment et d'être rassuré sur le fait que nous n'oublions pas de faire quelque chose.

Le processus

Le processus suit les étapes suivantes :

  1. L'information qui nous est destinée arrive dans une boite d'entrée.
  2. La boite d'entrée est vidée périodiquement. Pour chaque élément, nous regardons s'il implique une action ou s'il s'agit d'une information documentaire. S'il s'agit d'un document utile pour maintenant ou plus tard, nous le classons. Sinon, nous le jetons.
  3. Si l'élément implique une action de notre part nous effectuons l'action, la déléguons, planifions sa réalisation dans un agenda ou l'annotons dans une liste des actions suivantes à effectuer dès que possible.

La boite d'entrée, l'agenda et les listes d'actions suivantes sont fréquemment revus pour effectuer les actions qu'ils contiennent et être mis à jour.

Les règles à suivre

Les règles suivantes doivent être suivies :

  • Un élément quittant la boite d'entrée ne peut pas y retourner : nous devons prendre une décision quant à sa destination.
  • Si l'élément implique une action concrète que nous pouvons effectuer en moins de deux minutes, nous effectuons immédiatement l'action.
  • Si un élément implique plusieurs actions, il s'agit d'un projet. Nous le notons dans une liste de projets et nous réfléchissons à la prochaine action à réaliser pour avancer dans ce projet.
  • Nous revoyons la totalité de nos listes au moins une fois par semaine.

Voilà l'idée. J'aborderai la mise en œuvre dans le prochain post. Si vous voulez en savoir un peu plus sur le GTD, je vous invite à consulter les liens suivant :