Il n'est pas question de mérite, mais de pragmatisme. Si un Manager IT fait encore de la programmation c'est qu'il manque des ressources. Maintenant, cela arrive d'autant plus dans les petites structure. Ce n'est pas une critique. C'est un constat. Il faut bien s'adapter.
Rigide? C'est une répartition des rôles. Conflictuel? Il n'y a de conflit qu'en cas de mauvais management. Oui, il faut un consensus et de la communication. Un manager doit écouter les personnes sous sa responsabilité.
Méfiance? Oui, c'est possible que certains Managers se méfient des techniciens. La raison est que les non techniciens comprennent mal les raisons/explications des développeurs. Du coup, on peut comprendre qu'on se méfie de quelqu'un qui expliqueIl n'y a pas forcement de raison de lui expliquer (et ce n'est pas pour lui cacher).comment fonctionne un scrolling, une mise à jour dynamique, une contrainte d'intégrité référencielle, une recherche dichotomique...
Exemple de dialogue:
- Le Chef de projet: Le client A veut une moulinette à défriser le persil. Voilà ce que cela doit faire: Le persil entre par là et sort défrisé par ici. Comment on fait?
- Le Développeur 1: Je pense qu'on devrait utiliser le cyclotron à peigner les cheveux en quatre.
- Le Développeur 2: Non, non, j'ai vu un truc super: le PetroselinumDefrisum. On pourrait l'adapter.
- Le Chef de projet: Ca semble bien. Tout le monde est d'accord? Combien de jours?
- Le Développeur 2: A mon avis 2 jours.
- Le Chef de projet: Avec un peu de marge on dit 3. Je vais voir Le Manager.
- Le Chef de projet: Bon, il nous faut 3 jours pour la moulinette à défriser le persil de A.
- Le Manager: Ok.T'es certain? Parce que on a des pénalités si c'est pas livré à temps.
- Le Chef de projet: Oui oui, c'est un truc qui vient de sortir. Du tonnerre!
- Le Manager: Bon, je vais voir A cet après-midi. Là je dois faire tous les plannings des congés + un compte rendu des coûts des projets. J'ai réunion avec la Direction dans 10 minutes.
- Le Manager: Pas de problème Monsieur A, dans 4 jours c'est fait.
- Client A: Super!
4 jours plus tard:
- Le Manager à l'équipe de développement: Merci à tous. Grâce à vous on a livré à temps. Le PetroselinumDefrisum est génial. Développeur 2, tu iras loin!
- Le Développeur 2: Bah moi y'a que le développement qui m'intéresse. J'veux devenir expert! Alors, je vais partir aux US.
- Le Manager version 1: Super! C'est ce que je dis, tu iras loin!
- Le Manager version 2: Argh, pas question de te laisser partir. On mettra le prix qu'il faut
- Le Manager: Allez, je vous invite tous au restaurant pour fêter la réussite du contrat.
Allez, on rigole!
A+
Zut, je dois visiter un grand compte cet après midi !
Je vais essayer d'oublier ce que j'ai écrit sinon je vais gaffer
La particularité des IT est d'être un art (un sport) en devenir où les ruptures technologiques sont fréquentes et les sujets parfois incongrus.
Si je vois mon dev1 que j'ai laissé avec une tache que j'aurais pu faire moi-même si j'avais eu le temps. Je fais attention à ne pas imposer mon point de vue
Manque de pot, il est pas loquace aujourd'hui... il parle par oui et par non et n'a rien d'autre à montrer qu'un gros paté de code que je n'arrive pas à comprendre.
Je me dis : ce n'est pas son jour... Je parle d'autre chose et lui propose un bon café
A deux tiers de la tasse de café, la conversation vient sur les objectifs à court terme. Il passe sur la défensive .. je le laisse reprendre confiance. Je finis par comprendre qu'un SELECT... GROUP BY ... HAVING est 20 fois plus lent que prévu.
Finalement je lui dis que c'est pas grave et qu'il peut sauter le problème et passer directement sur ce qui est plus marrant, il se sent mieux
Je passe la soirée à refaire les indexes , demain je lui dirai qu'il a super bien bossé - ce qui est parfaitement exact puisqu'il m'a montré ce qu'il ne fallait pas faire (et qu'on ne pouvait pas deviner sans essayer)
Un de ces quatre, je lui montrerai la mise au point au debugger en mesurant le temps des step-out, qui est plus rapide et moins stressante..
Au final, je supprime 4 jours de charge devenue inutile, je les réimpute sur la finition de l'écran principal... une histoire de rafraichissement en cascade qui fait clignoter l'écran pendant le scroll . Finalement le scroll sera tellement impeccable qu'on lui ajoutera une dimension pour multiplier la spec de tout le programme. Ca fait un peu style iPhone .... et cette particularité nous vaudra une nouvelle commande " aux mêmes normes"
Une norme ?
Pas du tout ! c'était une histoire de dev mal luné au départ qui a forcé à revoir la spec et réimputer du temps libéré sur un poste "esthétique"
le side scroll de l'iPhone : Esthétique ou opportunité stratégique ?
Qu'est-ce qu'un scroll ?
Dernière modification par Invité ; 19/07/2010 à 14h27.
Je ne dis pas le contraire. Mieux vaut un qui sait que 10 qui cherchent. Quel qu'il soit si quelqu'un a la solution ce serait idiot de se priver. Pour autant tu aurais très bien pu ne pas savoir résoudre son problème non plus. La solution aurait pu venir du nouvel entrant d'hier qui se serait rappelé avoir vu ça sur un forum. Seulement, en tant que Manager, ce n'est pas ton rôle et le fait d'être Manager issu de la tech n'est pas en soit une garantie. C'est tout. Un technicien expérimenté "devrait" rester dans la technique et faire profiter les autres de son expérience. C'est dommage de passer 20 ans de sa vie à faire du dev sur une dizaine de langages et "finir" Manager à remplir des planning et assister à des réunions avec la Direction. Malheureusement, apparemment, en France c'est mal vu. Toutefois, s'il a envie d'évoluer là-dedans pourquoi pas...
Je suis surpris que personne n'est évoqué ceci
Maintenant c'est un vaste sujet que la progression au sein d'une entreprise d'un développeur...
Effectivement, dans mon cas comme dans celui des anciens développeurs, après 25 ans de programmation et de gestion de projet, il n'est pas facile de tourner le dos à la technique pour ne faire que du management.
En fait, tout dépend du job que va vous conférer la société.
Si vous avez trop de projets et d'équipes à gérer, il restera peu de temps pour "mettre la main à la pâte".
Par contre, pour un poste de chef de projet sur une équipe réduite, il est possible de concilier les deux.
Mais effectivement, c'est un métier de passionnés et il est difficile de renoncer complètement au "coding".
J'ai tendance à péter un cable quand j'entend la plupart des élèves à peine sorti de l'école qui veulent "ne pas coder toute leur vie et vite devenir manager".
Je trouve ça fou que le manager, en france, est considéré comme un échellon plutôt qu'un métier.
J'ai lu ce livre Amazon.com: How We Test Software at Microsoft (9780735624252): Alan Page, Ken Johnston, Bj Rollison: Books@@AMEPARAM@@http://ecx.images-amazon.com/images/I/41XE3G9666L.@@AMEPARAM@@41XE3G9666L, à l'intérieur ils expliquent qu'à Microsoft, les managers et les développeurs sont au même niveau (même salaire), et que un développeur peut devenir manager si il le souhaite.
Le manager est avant tout là pour permettre à son équipe de bosser efficacement, en les allégeant aux mieux des taches "administratives", en aménagent leur espace de travail, ou en servant de bouclier sur ce qui vient d'en haut.
C'est un métier totalement différent de développeur, non pas un échellon au dessus.
Après peut être que beaucoup de personne confondent chef de projet et manager.
Effectivement, plus j'y pense, moins j'arrive à justifier le fait qu'un manager soit mieux payé qu'un développeur, à compétences égales.
Fort probable qu'on confonde un peu les deux. Peut-être à cause de l'ascension des développeurs justement.
Compétences égales? C'est pas les mêmes métiers. On ne peut pas comparer.
Mettons qu'on essaye quand même, il y a le stress en plus. Je sais pas dans les autres pays mais dans les boites que j'ai pu fréquenter, le manager rend des comptes sur des trucs qu'il ne maîtrise pas. Et ça c'est super stressant en comparaison du travail de développeur. En général, ce sont ses choix qui sont mis en place. La responsabilité est plus importante. Quand personne ne sait plus quoi faire c'est lui qui prend la décision (même quand on sait ce qu'il faudrait faire mais que le manager décide de faire autrement )
Sinon, qu'est-ce qui fait la différence entre un manager et le reste? Sa compétence à maintenir la cohésion du groupe.
Perso la différence de salaire ne me dérange pas. Qu'est-ce qui justifie que Bill gagne encore autant d'argent alors qu'il fait plus rien? Parce que ses décisions en tant que Manager/Directeur font travailler beaucoup de gens. Un manager n'est pas un assistant, c'est un décideur (en France du moins).
Pour commencer, un manager IT n'est pas vraiment la continuation d'un développeur... plutôt celle d'un administrateur réseau.
Ensuite, il y a effectivement une légende comme quoi être développeur n'est pas une fin en soi et qu'il faut passer par le management pour faire carrière.
J'en ai interviewé un paquet qui sortaient de l'école. Ils savaient à peine coder, n'avaient aucune expérience d'un projet à plus d'une semaine, mais ils savaient déjà qu'ils voulaient devenir managers, voire plus. Comme si moi je passais un diplôme de marketing pour expliquer à mon premier entretien d'embauche dans mon costard tout frais que le marketing c'est bien gentil mais ce qui m'intéresse, ce n'est pas de définir des produits, c'est de siéger au conseil d'administration. Je pense que je vais faire rire et qu'on va m'apprendre la vie.
Ce qui se passe, c'est qu'on inverse la conclusion avec les prémices, la fin avant les moyens : pourquoi diable devenir manager ? Au début, c'est un plan de carrière qui se résume à "gagner plus de sous", car on sait que le manager est mieux payé que nous sans comprendre pourquoi. Une fois qu'on a un peu de bouteille, on veut être manager pour avoir politiquement plus d'influence, c'est-à-dire éviter de se faire assigner des tâches qu'on n'a pas eu le loisir de discuter, ou éviter que l'équipe du manager Tartempion ne nous pourrisse trop la vie.
Les véritables vocations positives de manager sont en fait assez rares : qui veut devenir manager après s'être rendu compte que tout seul, on ne peut pas tout coder ? que la plupart des problèmes des techniciens ne sont pas techniques (mauvaise communication, stratégie d'équipe floue, conflit de priorité, hiérarchie bancale, délais irréalistes...) et qu'il faut quelqu'un pour les résoudre ou faire le tampon ? que c'est bien d'être le meilleur du monde, mais c'est encore mieux de faire progresser les autres ? qu'il y a plein de talents dans cette équipe mais qu'ils sont désorganisés et que cela vaut bien que je sacrifie mon propre temps de code ?
Soyons honnêtes. Devenir manager est rarement l'expression d'une volonté positive, et la plupart des codeurs sont des enfants qui n'ont pas fini de grandir, et qui jouent encore à celui qui pisse le plus loin par compilateur interposé. Devenir manager n'est malheureusement souvent que la prolongation de cette envie de compétition. J'en trouve très peu qui se fichent de leurs propres résultats au profit de ceux de l'équipe en général. Et pour leur rendre justice, je connais peu d'entreprises qui valorisent cette attitude.
Ce qui sont devenus managers pour des raisons autres que positives font en général de mauvais managers parce qu'ils passent leur temps à penser que ça irait plus vite s'ils faisaient tout eux-mêmes. Ils se projettent sur leurs sbires et comparent ce qu'ils feraient avec ce que la personne fait (et même parfois, projettent leur idéal d'eux-mêmes sur cette personne, ce qui est encore pire). La bonne attitude est de s'extraire complètement de l'équation et de se considérer comme ressource non-productive. Un manager est entre le leader et le coach, mais est tout sauf un super-développeur.
Ça n'est pas tout à fait vrai. Ce qui est vrai, c'est que le salaire n'est pas fonction du nombre de personnes qu'on gère. Il est fonction d'une échelle séparée, dont les échelons sont chèrement gagnés au fur et à mesure que la personne est capable de faire rayonner ses propres compétences sur elle-même, sur ses voisins de bureau, sur son équipe, sur son unité de produit, sur son organisation, sur l'entreprise, sur l'industrie en général, et ainsi de suite. Dans la pratique, une personne qui a 3000 personnes sous elle va gagner plus qu'un développeur de base ; mais ce qui est important c'est que le développeur de base sache qu'il n'a pas besoin de gérer 3000 personnes pour devenir millionnaire. Et ça change bien des choses.à l'intérieur ils expliquent qu'à Microsoft, les managers et les développeurs sont au même niveau (même salaire)
Au fur et à mesure qu'une personne accroit son aura (dans les entreprises on parle aussi de "key people"), les compétences en question sortent très vite de la pure capacité de coder, mais cela ne veut pas dire qu'on bascule automatiquement dans le management, il peut aussi s'agir d'architecture, de recherche, d'évangélisation, de formation directe ou indirecte d'autre développeurs... pourquoi uniquement chercher à être manager ?
Il y a en fait 3 compétences de base : technicien (développeur, testeur...), chef de projet/produit, et manager. Un manager de développeurs est souvent un ancien développeur qui a montré des compétences de management, mais cela peut être un non technicien.
Microsoft (comme toute autre boîte similaire) vend du code. Ils ont besoin de recruter et de garder les meilleurs développeurs possibles. Il est facile de comprendre que tout le monde ne peut pas devenir manager, et surtout que si les meilleurs codeurs deviennent systématiquement managers, il ne restera que les boulets pour coder (ce qui leur est arrivé dans les années 90). Donc ils ont été obligé de penser un système où on peut progresser en carrière et en salaire sans pour autant nécessairement monter en hiérarchie. Ce que d'autres boîtes ne savent ou ne peuvent pas faire. Notre mentalité et notre système français fait reposer l'avancement et le salaire sur le nombre de personne qu'on dirige. C'est cette mentalité qu'il faudrait combattre.
Moi-même codeur à la base, j'ai souvent pensé qu'on non-technicien serait incapable de me manager. Mon meilleur boss - et de loin - s'est avéré quelqu'un qui ne sait pas écrire une ligne de code mais qui comprend tout à une vitesse astronomique, sait placer les bonnes personnes aux bons endroits, déjoue les méandres nauséabonds de la politique ras-de-moquette pour avoir les bons produits sortis de la bonne façon, balance la qualité contre la pression du planning, et par-dessus le marché arrive à faire progresser les gens en dessous de lui.
Donc pour réponse finale, je dirais que la question n'a pas de sens. Un développeur peut devenir manager autant qu'il peut tenir un bar, vendre des pizzas, ou être GO au club Med. Certains peuvent et pas d'autres.
Bien sur, si c'est son envie.
On peut très bien avoir une expérience de quelques années en tant que développeur, puis de chef de projet, directeur de projet. Ensuite, si on a expérience conséquente et très large, on peut intégrer une DSI en tant que manager si c'est un souhait de carrière. le plus important est de passer beaucoup de temps en développement (au moins 5 ans je pense) avant de faire moins de technique. Ceci pour comprendre les problématiques de tous les jours dans les équipes que les managers auront à gérer.
Il n'y a pas de réponse évidente à cette question. Connaitre le métier, c'est un avantage certain, parce que ça permet d'anticiper certains problèmes, de comprendre les problèmatiques. Un chef qui va demander plus de CPU pour ses subordonnés sera plus convaincant s'il comprend la raison. Voire, il saura refuser à bon escient si la demande est injustifiée.
Maintenant, connaitre le métier ne signifie pas être bon. Les meilleurs chefs que j'ai eu avaient été de bien piètres programmeurs. Mais ils comprenaient ce que je disais quand je parlais d'une "double rupture sur clef partielle des deux cotés".
On peut certainement faire sans, mais en acceptant ses limites. La plupart des soucis que j'ai eu avec les purs managers, c'était qu'ils croyaient savoir, alors qu'ils ne savaient rien.
Justement, question de confiance. Personne peut prétendre en savoir suffisamment. Personnellement, je pars du principe que si les gens demandent c'est qu'ils en ont besoin. On peut toujours leur demander si c'est vraiment nécessaire et expliquer les problèmes de budget et finalement perdre en temps de discussion le prix de la RAM.
manager ? manager de quoi ? d'une équipe de dev ?Envoyé par Katleen Erna
ou vous parlez de chef de projet ? ça c'est une évolution de développeur, pas manager
un manager ne code pas tout comme un développeur ne passe pas 100% de son temps à coderEnvoyé par Katleen Erna
je ne sais pas d'où vous sortez vos 30% mais il est impossible pour un manager de passer 30% de son temps à coder
il passe déjà plus de 50% de son temps à manager + faire des rapports + participer à des réunions + faire du relationnel + résoudre les problèmes de resources dans l'équipe qu'il manage + résoudre les problèmes de l'équipe (social, technique, logistique)
en plus vous parlez de moyenne alors que c'est déjà impossible que ce soit le maximum
les chiffres on peut (vraiment) leur faire dire n'importe quoi
ah bah tout s'explique...Envoyé par Katleen Erna
l'évolution logique d'un dev n'est pas managerEnvoyé par Katleen Erna
tout comme un manager ne peut pas devenir un dev
ce sont deux domaines qui n'ont aucun lien
+1
ce genre d'absurdité mène au Principe de Peter : « tout employé tend à s'élever à son niveau d'incompétence. »
Entièrement d'accord avec shenron666, manager n'est pas l'évolution logique de développeur, au contraire. Il existe certainement des bons managers également bons développeurs, mais ce n'est certainement pas la majorité des cas, et laisser coder un manager, qui sera le plus probablement un mauvais développeur, n'est franchement pas une bonne idée, comme de confier de la gestion à un excellent développeur.
Avoir une culture et un bagage technologique pour comprendre et faire les bons choix, oui, mais coder non. Seule exception, à mon sens, à la règle, les petites structures où il faut bien tout faire avec un minimum de personnel.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager