Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
OK une exception pour Polytechnique, grande école qui mêle étroitement technique, politique, militaire.. Pour quelques raisons que je ne peux pas développer sans enfreindre des clauses contractuelles, cette grande école est exceptionnelle à plus d'un titre.Envoyé par Paenitentia
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+
"Winter is coming" (ma nouvelle page d'accueil)
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...
"Winter is coming" (ma nouvelle page d'accueil)
Principe de Peter
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.Un développeur informatique peut-il devenir un manager IT ? Les programmeurs seraient "trop" passionnés
Les développeurs semblent éprouver des difficultés à s'élever au sein de leurs entreprises et à passer à l'étape manager.
Pour devenir responsable d'une partie du système d'information, il faut mélanger aptitude à la programmation et compétences en direction. Les managers ont véritablement un rôle technique puisqu'ils passent en moyenne au moins 30% de leur temps à coder.
D'après certains spécialistes, le malaise viendrait justement de là. Ils expliquent que les développeurs sont avant tout des passionnés, et que pour eux l'accès au grade de "manager" ne les fait pas renoncer à l'exercice de leur passion. Le nouveau responsable continue de faire partie de sa communauté (et de respecter ses us et coutumes), et souhaite continuer de programmer, ce qui peut créer des conflits avec le reste de l'équipe du service IT.
"Les geeks, qui recherchent pourtant la reconnaissance de la société, même une fois parvenus au poste de leader et ayant acquis un certain pouvoir, ne parviennent pas à se défaire de ce qu'ils sont vraiment".
"Afin de diriger au mieux leur équipe et d'éviter autant que possible la « net negative producing programmer» - une moins-value constatée suite au lancement d'un projet -, ils doivent reconnaître quelles sont les compétences de chacun de leurs collaborateurs, les inciter à les développer. Et surtout, inter-agir et communiquer".
D'après vous, et selon votre expérience, un développeur informatique peut-il devenir un manager IT ?
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".
Principe intéressant. Toutefois, au-delà du constat, pourquoi?un employé compétent à un poste donné est[EDIT]-il[EDIT] promu à un niveau hiérarchique supérieur
"Winter is coming" (ma nouvelle page d'accueil)
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.
C'est peut-être ça qui fait toute la différence...
Pour vivre heureux, vivons cachés. Proverbe alien.
Effectivement, plus j'y pense, moins j'arrive à justifier le fait qu'un manager soit mieux payé qu'un développeur, à compétences égales.
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
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).
"Winter is coming" (ma nouvelle page d'accueil)
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.
Etre à l'écoute et faire confiance ne suffit pas? Sous-entendu on n'est un bon Manager que si on connait le métier? Etre un bon "leader" affranchit de cette "nécessité".
"Winter is coming" (ma nouvelle page d'accueil)
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.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
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.
"Winter is coming" (ma nouvelle page d'accueil)
manager ? manager de quoi ? d'une équipe de dev ?
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 à coder
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...
l'évolution logique d'un dev n'est pas manager
tout comme un manager ne peut pas devenir un dev
ce sont deux domaines qui n'ont aucun lien
+1+1
C'est ce que je pense également.
ce genre d'absurdité mène au Principe de Peter : « tout employé tend à s'élever à son niveau d'incompétence. »
Tutoriels OpenGL
Je ne répondrai à aucune question en MP
- Si c'est simple tu dis que c'est compliqué et tu le fait
- Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.
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.
Ne vous cassez plus la tête
Aide à distance et/ou intervention à distance à partir de 30€ TTC. Demandez moi un devis gratuit !
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.
Répondre avec citation
Partager