Un bon manager devrait consacrer 30% de son temps à coder.

J'avais déja traité ici même d'un sujet sur la véritable fonction de chef de projet (http://le-code-vulgarise.blogspot.fr/2014/01/le-chef-de-projet-web-n-pas.html). 
Un chef de projet comme on l'appelle, exerce en réalité une fonction de manager d'équipes, déléguant la responsabilité de chef de projet technique aux responsables techniques (lead dev, directeur technique).

Ok garçon, mais alors pourquoi nous dis-tu qu'un manager (chef de projet traditionnel) doit consacrer 30% de son temps à coder?

C'est simple, pour le comprendre, posons-nous une simple question:
Qu'est-ce-qui unit, un manager, une équipe technique et la direction?
La réponse est...? Le code.

Dans un métier qui ne cesse d'évoluer, pour qu'un manager puisse réaliser efficacement son boulot, et, le déléguer à l'équipe technique, il doit créer une connexion avec cette équipe et le meilleur moyen de se connecter, est de partager la connaissance du code que l'on délègue.

Oui, mais un manager n'a t'il pas déjà suffisamment à gérer pour rajouter un peu de technique à sa charge?
Il est légitime de penser celà, mais on peut aussi se poser ces questions:
- Une maman donne t' elle du lait chaud à son enfant sans le goûter elle même d'abord?
- Un développeur a t'il jamais contribué à la conception d'un cahier des charges, ou à l'estimation de deadlines?
- Un chef cuisinier passionné délègue t' il sans jamais se mettre lui même aux fourneaux?

A moins d'être totalement désintéressé par le projet, ou complètement overbooké, ou même, à moins de fuir les capacités mentales nécessaires à déployer pour, écrire quelque lignes d'instructions dans un nouveau langage, un bon manager se doit de montrer l'exemple à ses collaborateurs.

Quels sont les bénéfices à retirer d'un tel investissement?
- Gain du respect de l'équipe technique, favorisant ainsi la cohésion par la solidarité.
- Meilleure compréhension et estimation de la charge de travail imputée à l'équipe technique.
- Meilleure communication avec les différents pôles de l'entreprise sur la nature des projets.
- Meilleure compréhension des enjeux de chaque profession.

Il n'y a que des avantages.

Evidemment, il ne s'agit pas de le faire au quotidien, mais 30% de son temps mensuel ou annuel, pour comprendre et apprendre ce que l'on délègue est un premier pas vers une cohésion d'équipe plus forte, et des projets mieux aboutis, juste parce que le métier évolue si vite.

Merci.

Ce qu'il faut pour être un bon développeur web

Je viens de faire ma veille technique, et j'ai été pas mal inspiré par ce sujet.

Avant de devenir développeur web, j'avais une idée classique du métier, qui est celle de l'écriture d'une succession de logiques dans un langage.

On n'a pas tendance à y intégrer la difficulté et le facteur évolutif du secteur.

Hors, nous sommes dans un métier, dans lequel il est indispensable de se former aux perpétuelles nouveautés et bonnes pratiques, pour sortir de sa zone de confort et subsister.

Il faut se familiariser avec les différents outils pour atteindre un niveau de qualité toujours plus exigeant. C'est comme cela que l'on est reconnu et que l'on grandit au sein d'une entreprise.

Mais, surtout, et le plus important, il faut pouvoir vendre les requis, pré-requis et impératifs de ce métier à tous les collaborateurs, avec lesquels on est liés au quotidien.

C'est ce dernier point le plus important, car beaucoup de développeurs ont tendance à le négliger, mais il est souvent le point de départ d'un cycle de turnover regrettable.

Pourquoi? 

Parce que face à des impératifs financiers et de temps, la méconnaissance de ce qu'il faut pour livrer un produit qualitatif dans les temps peut emmener la direction à vous guider dans un mauvais courant.

Et c'est dans l'action de ce type de situations qu'il se peut que certains dirigeants ne voient simplement pas, ou n'aient pas la disposition suffisante pour adopter une attitude d'humilité nécessaire, pour réfléchir à une solution de compromis, quand à une livraison qualitative, dans un temps correct.

A partir de ce moment, la chaîne de responsabilités devient verticale, et chacun des salariés y a une part, qu'elle soit assumée ou pas.

En conclusion, pour être un bon développeur, il faut être avide de connaissances, mais surtout, il faut savoir communiquer avant toute chose sur les processus de développement d'une application auxquels on est soumis.