Chef de Projet / développeur ?

TerinTerin Membre
octobre 2014 modifié dans Coin canapé & détente #1

étant en école d'ingénieur ( inutile de dire le nom c'est assez générale aux écoles privée :D ) on nous rabâche quasiment au quotidien qu'un bon développeur dois le plus rapidement possible passer chef de projet mieux rémunérer et c'est vrai que en discutant avec d'ancien élèves passer chef de projet est perçue comme le seul moyen d'augmenter son salaire et même mieux de pouvoir poursuivre une carrière.


Le développeur étant alors perçue comme un technicien jeune voir même comme un stagiaire.


 


Or ce qui me dérange c'est qu'effectivement les salaires en tant que chef de projet sont bien supérieur à  celui de développeur cf : http://www.journaldunet.com/developpeur/algo-methodes/salaire-du-developpeur-par-profil-de-poste/chef-de-projet-etudes-et-developpement.shtml ce que je ne comprend pas au vue de la valeur ajouté d'un développeur expérimenté avec une dizaine d'année d'expérience, chef de projet nous étant présenté comme la récompense ultime de nos études, un emploi valorisant du moins assez pour pouvoir draguer les RH aux compétences varié allant de la maitrise quasi chirurgicale d'outlook à  une créativité sans cesse dépassé dans nos powerpoint  :p  mais surtout vous êtes chef( titre que portais bien 90% des gens dans la SSII ou l'administration où j'ai fais mes stages en dehors des stagiaires ), pas un geek dégarnis à  la trentaine présenté la encore comme le looser de la boite  donc c'est forcément mieux.


 


CHEF, CHEF tous tourne autour d'une hiérarchie ou il faut monter pour progresser, pas dans sa fonction mais dans l'entreprise en elle même qu'importe qu'on s'éloigne de plus en plus de notre domaine de prédilection et ce que nous sommes censé faire de mieux l'informatique, j'ai eu beaucoup de mal à  trouver des contres exemple de gens resté développeur avec un haut niveau avec un salaire équivalent à  chef de projet et surtout il semblait clairement pas heureux ne se sentais jamais écouté, sous estimé, râlant sans cesse sur ceux du dessus qui ne connaisse pas les technos et font des choix couteux et illogique ne connaissant absolument pas le technique mais décide de tous, après tous ils sont chefs.


 


De la j'en déduis une première chose, j'adore développer c'est vraiment quelque chose d'unique de voir son projet avancé pas à  pas depuis sa petite console noir jusqu'à  la fin  :'( mais pourtant j'ai presque honte d'aimer faire çà  comme si c'étais une tache indigne réserver au fameux " pisseur de code " limite on me regarde parfois comme un ovni quand je dis préférer faire moi même mon serveur plutôt que d'utiliser Window2012 ( bah oui mais c'est pas parce que j'ai accès à  dreamspark que l'entreprise sera forcément sur window que j'ose répondre ). les postes les plus valorisants et permettant une vrai perspective de carrière n'ont plus grand chose à  voir avec l'informatique au final, du moins comme on nous le présente. Le management ce que je perçois tantôt comme un vrai compétence tantôt comme un énorme brassage d'air semble être la clé à  tout il en faut partout mais même eux ont du mal à  savoir à  quoi ils servent  ???


 


De là  il en découle que la majorité des entreprises ( de grosse taille je pense SSII en tête ) semble avoir un fonctionnement quasi pyramidale ou tous en bas se trouve le développeur pourtant à  mon sens l'employé avec le plus de valeur ajouté avec le temps ( comme le vin on se bonifie avec l'âge dans notre openspace la ou le chef se ramollit dans son bureau sans pouvoir faire du technique ) et les postes comme commerciaux ou chef de projet semble au dessus et sont souvent mieux rémunérer sans même que l'on puisse en saisir là  cause, il en résulte quelque chose de fantastique dans l'ambiance et l'air générale d'une entreprise avec d'un coté les commerciaux qui ne font que le brasser et de l'autre les chefs de projet qui nous le pompe.


 


A force de chercher des informations je suis tombé sur ceci : http://fr.wikipedia.org/wiki/Principe_de_Peter assez édifiant, terrifiant et fascinant, sans tomber dans le cliché sa me parais être exactement la situation que je décris et pire je suis tombé sur : http://fr.wikipedia.org/wiki/Principe_de_Dilbert surtout ce passage 


 


Le nouveau principe, principe de Dilbert, s'énonce ainsi : " Les gens les moins compétents sont systématiquement affectés aux postes où ils risquent de causer le moins de dégâts : ceux de managers. "


 


Si le principe de Peter garantissait qu'un dirigeant incompétent serait compétent s'il occupait le poste d'un de ses subordonnés, dans une entreprise dilbertienne au contraire, les dirigeants sont ceux qui étaient les plus nuls aux postes subordonnés. En particulier, ils ne comprennent rien à  la technologie et manquent de bon sens dans les cas les plus graves.


 


Réciproquement, les employés les plus compétents ne sont en aucun cas promus, car irremplaçables à  leurs postes actuels.


 


 


Cela voudrais donc dire si part du principe que cela est plus ou moins vrai, et de mon idée de départ, qu'un bon développeur dois passer chef de projet et pour cela il ne dois pas savoir développer. Un bon développeur [...] ne dois pas savoir développer ( ou mal développer ). Et là  effectivement nos écoles française regorge de génie dans le genre  o:) et on peut applique cela un peu partout aussi  8--) .


 


 


Plus sérieusement il y a pas mal de développeur sur ce forum donc je vous pose la question voir plusieurs, pour ceux qui travail dans une boite reconnaissez vous vraiment ce que je décris ? les salaires et la reconnaissance de votre travail vous paraissent-t elles suffisantes ? vous sentez vous écouté par vos supérieurs ? Si vous avez ( la chance ) de travailler à  l'étranger c'est vraiment différent et plus adapté ? Vaut il mieux travailler dans une petite boite indépendante ou dans une grosse boites en tant que développeur ? Passer chef de projet est-il vraiment intéressant au niveau de la carrière et du salaire ? Merci d'avoir lu excusez moi pour les fautes.


«1

Réponses

  • AliGatorAliGator Membre, Modérateur
    octobre 2014 modifié #2
    Pour faire court :

    - Malheureusement le principe de Peter est souvent vérifié

    - En France, et c'est un cas assez propre au moins à  la France, le développeur est sous-évalué et le CDP surévalué. Aux US c'est totalement l'inverse, le dev est roi

    - Si le schéma que du décrit est vrai pour pas mal de boà®tes, ça reste ceci dit caricatural.


    Pour ma part par exemple je suis dans l'exception : dev puis architecte avec 10 ans d'expérience (et c'est pas demain que j'ai envie de passer CDP!), je suis l'expert iOS référent reconnu dans ma SSII ; je m'estime très bien payé, mon job me plait et je suis en grande partie écouté par mes chefs.

    Mais après je suis loin d'être l'exemple type, car j'ai aussi sûr sortir du lot et je suis conscient que mon cas n'est pas représentatif de la majorité des boà®tes ;)
  • Les salaires dépendent aussi beaucoup du domaine. En règle générale, l'informatique de gestion (banque, assurance) paye mieux que l'informatique technique (embarqué, industrie, transport).


    D'apres mon experience, il y a assez peu de postes d'experts dans les SSII. Dans les faits, il y a des experts mais ils ne sont pas reconnus, sauf dans des domaines hyper specifiques qui correspondent a des technos rares ou obsolete (cobol, sécurité).


    Les SSII sont souvent polyvalentes (ou opportuniste) car les technos changent vite, donc ils ne veulent pas se retrouver avec des experts bien payés dans des technos dont les clients ne veulent plus. D'autant que les développeurs ont tendance à  être moins ouverts aux nouvelles technos avec l'age.


    Contrairement a l'expert, le cdp est indispensable pour vendre.

    Sans CdP a mettre en face du client, on ne peut pas vendre de projet. Une fois que le projet est vendu, on peut toujours bricoler avec les developpeurs, prendre des stagiaires, des developpeurs non formés à  la techno, etc. Il y aura des consequences mais on arrivera a faire quelque chose.


    D'autre part, distinguer cdp et developpeur est une mauvaise habitude, entretenu en partie par le comportement des developpeurs eux-memes. Idéalement tout developpeur devrait avoir des competences de cdp : savoir concevoir, evaluer, planifier, faire du reporting, etre capable de poser des questions au client, etc.



    Cela dit, je suis d'accord qu'il y a un effet principe de Dilbert dans certaines sociétés (les plus grosses, qui ne savent plus vraiment comment elles gagnent de l'argent). La consequence d'un mauvais management sur la qualité des softs est visible tous les jours.

    Par exemple, il semblerait que la derniere app de canal+ soit de bonne qualité mais avant ça, je n'ai JAMAIS vu un soft grand public correct chez canal+. Je suis inquiet avec l'arrivee de netflix.

    Idem chez d'autres grand donneurs d'ordre où la qualité est possible, mais putot par accident que par maitrise.
  • Il n'y a encore pas si longtemps (disons, une vingtaine d'année) on trouvait de grandes boà®tes dans lesquelles il était possible de faire une jolie carrière aussi bien dans le management que dans le technique : IBM, ESD (qui n'existe plus) ... Ce type d'entreprise devient effectivement très rare.


    Je suis également convaincu de l'égale utilité des (bons) managers et des (bons) techniciens ; j'essaie à  ma petite échelle d'appliquer ce principe dans ma société. Plus précisément je recrute des techniciens et j'essaie de développer à  la fois leur compétence technique et leur compétence managériale, avec deux objectifs :


    - cela sert parfois de révélateur pour les individus, ils se découvrent une affinité pour de nouveaux boulots qu'ils n'avaient pas soupçonnée,


    - cela permet une meilleure communication entre développeurs et CdP, commerciaux, ...


     


    Sur le sujet, je recommande la lecture de Une politique pour le Système d'Information qui décrit bien ce principe d'égalité de considération entre autres choses. Ce livre est édité par un cabinet de consultants " OCTO Technologies " qui organise tous les ans un cycle de conférence dont le sous-titre est Des Geeks et des Boss. Il faudrait que tu y envoies tes chefs incompétents, qui sait ... peut-être vont-ils devenir compétents !


  • CéroceCéroce Membre, Modérateur
    octobre 2014 modifié #5

    Plus sérieusement il y a pas mal de développeur sur ce forum donc je vous pose la question voir plusieurs, pour ceux qui travail dans une boite reconnaissez vous vraiment ce que je décris ?

    Oui et non ;-)
    Développeurs ou chefs de projets, ce sont avant tout des postes de dépense pour une entreprise. Ce que je veux dire par là , c'est qu'un commercial peut aller voir son chef et dire "j'ai fait 15% de plus sur cette zone, je voudrais une augmentation", parce qu'il y a un lien direct entre son travail et le chiffre d'affaire. Bien sûr, sans techniciens, il n'y a rien à  vendre, mais leur apports au chiffre d'affaire est difficile à  évaluer.
    C'est en partie là  que les chefs de projets font aussi la différence, puisqu'ils sont normalement en charge du planning et du budget; leur travail a donc une incidence sur les coûts.
     

    les salaires et la reconnaissance de votre travail vous paraissent-t elles suffisantes ? vous sentez vous écouté par vos supérieurs ?

    Où je travaillais (une PME), les salaires étaient plutôt faibles, mais par contre notre travail était bien reconnu. À vrai dire, la gestion de projet était vue comme une compétence différente du développement, et les chefs de projets n'étaient pas vraiment des supérieurs hiérarchiques aux développeurs. C'est en partie parce que la boite vendait avant tout son expertise technique à  ses clients. Je veux dire que d'autres boites se distinguent par le prix, la disponibilité, la flexibilité, etc mais n'ont pas de différenciation technique à  offrir.

     

    Vaut il mieux travailler dans une petite boite indépendante ou dans une grosse boites en tant que développeur ?

    Là , la réponse est facile: dans une grosse boite, tu n'es qu'une personne parmi des milliers. On va t'hyperspécialiser et tu feras toujours la même chose.
     

    Passer chef de projet est-il vraiment intéressant au niveau de la carrière et du salaire ?

    Au niveau salaire, sans doute.
    Ensuite, ça dépend ce que tu entends par " intéressant ". J'ai vu des techniciens devenir chefs de projet et qui étaient malheureux à  leur poste.

    Ensuite, il n'y a pas qu'une manière de gérer sa carrière. Personnellement, je n'avais plus de possibilités de progresser dans un emploi salarié; la création d'entreprise fut la solution pour moi.
  • AliGatorAliGator Membre, Modérateur

    Ce que je veux dire par là , c'est qu'un commercial peut aller voir son chef et dire "j'ai fait 15% de plus sur cette zone, je voudrais une augmentation", parce qu'il y a un lien direct entre son travail et le chiffre d'affaire.

    Je ne suis pas trop d'accord. Enfin je veux dire, ce que tu dis est malheureusement effectivement ce qui est perçu dans le système français et vu par les dirigeants, donc ça correspond à  la réalité, mais à  mon avis pas à  la vérité.

    Un commercial qui arrive à  vendre 15% de plus sur une zone, parce qu'il a réussi à  vendre un projet à  115k cette année alors que l'an dernier il avait vendu 2 projets à  50k, ça ne va pas forcément être pour autant mieux sur les bénéfices de l'entreprise. L'important c'est surtout le profit dégagé.

    S'il a vendu un projet à  115k au client, mais qu'en fait ça coûte 130k à  produire à  l'entreprise, car il a sous-vendu le projet (les développeurs qui ont chiffré le projet ont estimé que ça coûterait 260 jours à  500€/jour, sauf que le commercial, pour réussir à  vendre le projet au client il a voulu baisser le prix de vente pour aguicher le client et au lieu de baisser le TJM et garder une date de livraison à  T0+260, il lui a vendu du rêve "oui oui on pourra vous livrer plus tôt" et a vendu 230 jours.

    Bilan les développeurs n'arrivent pas à  livrer dans les temps (comme ils avait déjà  annoncé lors du chiffrage), du coup y'a dépassement, et ça coûte même au final déjà  + cher que ce qui a été vendu, et encore + cher à  cause des pénalités de retard... et la boite a des pertes sur le projet.

    Alors le commercial est content, il a vendu 15% de plus sur sa zone, il a sa part variable supplémentaire, mais c'est un projet où on perd de l'argent. Alors que l'année d'avant où il avait vendu moins mais en ne baissant pas la charge estimée par les devs pour vendre moins cher, la boite avait fait + de bénéfices...

    Malheureusement, ce cas se rencontre assez souvent... Qu'est ce que ça changerait les choses si la part variable des commerciaux était indexée non pas sur le montant des ventes qu'ils faisaient, mais le montant des bénéfices rapportés par les projets qu'ils ont ramenés...
  • J'ai une vision un peu différente des choses ayant travaillé dans la recherche et n'étant pas informaticien. Dans la boà®te ou j'étais il était possible d'être chef de projet d'un coté et simultanément ingénieur de base dans un ou plusieurs autres projets. Ce qui fait que la bonne manière d'avancer était d'abandonner la technique et de se lancer dans la gestion du personnel, des plannings, des investissements....etc  En ce qui concerne l'informatique, la scientifique passait sur le cray local et la petite informatique était sous traitée.


  • AliGator, je suis d'accord avec presque tout ce que tu dis sauf ça :


     




    L'important c'est surtout le profit dégagé.

     




     


    Vu d'un financier, la croissance est plus importante que le profit.


    On peut ne pas être d'accord avec cette échelle de valeurs, notamment parce que c'est cette logique de croissance qui crée des bulles spéculatives, des crises des subprimes, ... Mais c'est malheureusement la réalité de notre merveilleux monde moderne.


  • Donc au final dans la hiérarchie des boites français, commercial et manager semble " au-dessus " de développeur. Sa semble très cliché mais je trouve que c'est un vrai manque de reconnaissance de ne pas valoriser l'aspect technique à  contrario de l'aspect commercial. On le retrouve dans ma formation avec des nombreux projets dépassant largement les compétences vue en cours obligeant les élèves à  chercher et à  apprendre par eux mêmes à  voir plus loin que la syntaxe de base d'un langage.


     


    Sauf que la moitié de la note vas correspondre à  la présentation du projet, c'est à  dire comment le présenter à  un Jury le plus souvent qui ne connais pas l'informatique composé de membres externes à  l'école ,des chefs d'entreprise locaux par exemple, à  qui la présentation vas uniquement correspondre à  présenter le cahier des charges dans un powerpoint en disant c'est génial on la fais ( ou non il n'en sais rien il n'utiliseras jamais le projet directement ) avec de jolies screenshot fais sur paint de ce à  quoi devrais ressembler le projet si on l'avais fais, puis on vendras le projet en estimant le temps de travail ( avec d'énorme largesse, on est sensée être bac+5 donc tous est facile non ? ) pour au final arrivé à  un prix vendeur qui correspondrait à  vue nez à  parfois 1/4 du temps réellement nécessaire au projet si on avais implanté tous les features vendues, on en sais rien ne maitrisant pas l'aspect technique.


     


    Au final on comprend rapidement que l'aspect commercial est bien plus valorisant et autant récompensé que celui technique, voilà  pourquoi on arrive avec de mauvais projet sur le plan technique, mais d'apparence énorme sur le papier ou aucun compétence technique n'est nécessaire. Entre passer des dizaines voir des centaines d'heures à  s'arracher les cheveux pour maitriser une techno inconnu, et 1h à  faire un powerpoint ou on vas juste présenter ce que devrais être le projet en parlant vaguement de l'équipe de Dev pour ce qui n'existe pas, le choix est trop rapidement fait et effectivement, on critique nos formations généralement à  tord en disant payeur de diplôme, certain élèves sont excellent grâce à  ce cursus, mais oui il y a une partie qui ont un master en informatique avec des compétences réel équivalente à  celle d'un ingénieur généraliste ( au niveau informatique ). L'aspect commercial comme tu dis est valorisé à  l'extrême, qu'importe si le commercial vas comme tu le montre vendre un projet à  perte, il la vendue, et bien généralement c'est le technicien qui dois rattraper les 30 jours hommes par son niveau de compétence pour combler les features vendues, si il réussis le commercial aura juste eu raison et toucheras sa prime qu'importe que les 30 jours homme sois en heure supp non payés.


     


    Cela se retrouve encore dans nos projets, les plus techniques ont souvent un prix et un temps de travail bien supérieur aux autres car il correspond non pas à  une prévision sur un coin de table mais le temps réel travailler, et donc pour éviter " mais je comprend pas on me la vendue moins chère avec moins de temps de travail, vous êtes incompétent ? " nous sommes obliger de cacher le temps réel pour s'aligner sur l'aspect commercial des autres, ce qui est extrêmement dévalorisant et frustrant car au final le résultat est le même la note n'a aucun importance seulement le acquis et non acquis l'est ...


     


    On nous incite donc à  négliger l'aspect technique pour celui commercial qui correspond à  celui qui à  la charge de la relation client le fameux chef de projet, car effectivement mieux rémunérer, le pseudo aspect élitiste des écoles fait que l'unique moyen de comparaison des compétences se décide sur le xxK€ que tu gagneras par an, rien d'autre, le mec qui après 2 ans de web passeras chef de projet car il à  fait trois cours de management et sais faire un diagramme de gant ( c'est beau les gens aime bien mais sa correspond bien souvent à  rien car il se base sur ce que les gens veulent voir ) pourra prendre de haut le monstre en Java qui toujours au statut de développeur ne bouge pas après 5 ans. 


  • Je trouve que li principe de Dilbert est plutôt représentatif sur certain point. En effet imagine que tu es gérant d'une entreprise ou d'une équipe et que tu as un employé, le monstre en Java, qui effectue 2 à  3 fois plus de boulot que les autres employées. Au premier coup d'oeil il parait normal de le promouvoir et de le mettre en avant mais après réflexion tu t'aperçois que ce mec qui fais énormément de boulot pour toi et qui ne demande rien ben si tu lui offres une promotion il le fera plus (ou plus pour toi) et tu vas être en difficulté. Donc comme tu as besoin de lui et que lui il réclame rien, tu le laisses là  où il est. A l'inverse le mec qui prend beaucoup la parole, qui va avoir tendance à  prendre ses propres décisions sans te consulté, et qui va clamer haut et fort qu'il veut prendre une place plus importante. Ben même si ces choix sont mauvais, pour les instances dirigeantes il fait parti d'une équipe qui tourne bien (grâce à  ton monstre en dev) et il est à  l'aise à  l'oral donc ils vont lui proposer un truc (en plus il est demandeur). Et toi tu vas pas l'empêcher puisque ça te permet de te débarrasser  d'un élément qui n'aide pas ton équipe.


     


    Dans mon école (Supinfo) ils accordent aussi beaucoup d'importance à  la présentation de ton produit. Une école à  Bac+5 n'a pas pour vocation de former des techniciens ! Le but ce n'est pas de faire de toi une brute en Java, ça il y en a en BTS ou en License. La valorisation de ton diplôme c'est dans une optique de chef de projet ou entrepreneuriat. C'est pour ça que les présentations sont importantes : la prise de parole, la gestion du projet, des coûts et des temps de réalisations. D'ailleurs je ne connais pas ton école mais nous en cinquième année nous on ne fait presque plus du tout de technique ! Buisness, management, législation, entreprenership... C'est pas le métier de développeur qu'on apprend. Bien sur l'informatique reste la base de notre formation mais le but c'est justement de ne pas être le mec qui reste dans son bureau (ou plutôt son open space) et qui n'évolue pas mais plutôt celui capable de prendre la parole, de monter un projet et de l'emmener à  son terme. Des compétences que tu n'acquiert pas dans un BTS, c'est la différence entre le technicien et l'ingénieur


  • FKDEVFKDEV Membre
    octobre 2014 modifié #11


    Buisness, management, législation, entreprenership... C'est pas le métier de développeur qu'on apprend. 




     


     


    On n'a pas fini de produire de la m...   ;)


  • LeChatNoirLeChatNoir Membre, Modérateur

    Aujourd'hui, bosser en agilité devrait être plus répandu.


    Et en agilité, pas de CP ; uniquement une équipe motivée et responsable, avec éventuellement, un "chef d'orchestre" (scrum master si méthode scrum).


     


    Les SSII s'y mettent mais les clients (info gestion) pas trop. Du coup, on voit encore bcp de projets menés à  l'ancienne avec des CP et des troufions (dev)....


  • FKDEVFKDEV Membre
    octobre 2014 modifié #13

    L'agilité est une bonne solution car elle réduit la pression sur le Cdp (y'a plus vraiment de cdp d'ailleurs), oblige à  impliquer les développeurs dans les estimations et OBLIGE le client à  s'intéresser à  son produit et au travail des développeurs.


     


    Malheureusement, ce n'est pas tellement applicable aux SSII car l'agilité réclame de la transparence et de la continuité qu'on obtient qu'avec une équipe de développement in-house.




  • Et en agilité, pas de CP ; uniquement une équipe motivée et responsable, avec éventuellement, un "chef d'orchestre" (scrum master si méthode scrum).




     


    ça ressemble quand même beaucoup à  un Chef de Projet.


    Un des inconvénients de l'agilité c'est qu'il est nécessaire de beaucoup impliquer le client (l'idéal étant qu'il soit carrément avec l'équipe de développement pendant le projet). Je suis pas sur que ça soit possible dans beaucoup d'entreprise.

  • AliGatorAliGator Membre, Modérateur
    octobre 2014 modifié #15
    Même l'Agilité quand les devs sont chez le client (In-House) ne marche pas quand le client n'est pas Agile.

    On a déjà  essayé avec des clients, qd ils demandent de l'agilité "On veut faire du Scrum et être Agile et que vos devs soient chez nous", nous on leur vend et on est content car on préfère. Sauf qu'une fois que le projet commence, ils ne participent pas aux Daily Meetings, ils nous demandent de chiffrer des fonctionnalités (avec un découpage ne correspondant pas aux découpage en story), en jours (et pas en points), et surtout changent d'avis en plein milieu de Sprint (alors qu'en vraie méthodo Agile, une fois qu'un Sprint Backlog est engagé il ne bouge pas, et s'il y a des modifications à  faire c'est pour le Sprint suivant).

    Bref ils fonctionnent encore à  l'ancienne et ne respectent aucun des principes Agiles, car pour ceux ce qu'ils entendent par "Agile" c'est "on peut changer d'avis comme on veut et c'est la SSII qui doit s'adapter à  tout moment". En gros ils confondent "méthodologie agile" et "SSII flexible qui accepte qu'on change tout le temps les specs (et qui ne sont que nos larbins à  obéir à  nos moindres désirs)".
  • LeChatNoirLeChatNoir Membre, Modérateur

    ^^


    Excellent :)


     


    Effectivement, le porteur de projet doit être dispo et formé à  l'agilité.


     


    Sinon, ça sert à  rien.


  • FKDEVFKDEV Membre
    octobre 2014 modifié #17

    En fait l'agilité n'est pas très flexible, ça devrait s'appeler la rigueurité.


     


    Le vrai problème de tout ça, quelle que soit la méthode, c'est bien que le client ne s'intéresse pas assez à  la conception de son produit.


    Il n'a pas le temps de le spécifier. Il ne sait pas ce qu'il veut. Il n'y comprend rien, il n'a pas de smartphone lui-même.


    C'est un peu comme si l'équipe marketing/produit de Renault se déplaçait à  cheval.


     


    Je caricature à  peine.


     


    Les produits Apple sont meilleurs car il y a de la cohérence et de la continuité à  tous les niveaux du produits.


    Dans l'AppleWatch, il y a des enseignements qui viennent de l'iPhone, de l'iPod, du Mac et même surement de Next.


  • Je fais la même école, et si Supinfo est effectivement la meilleur école au vue du système français pour progresser rapidement au final comme tu le dis tu peux survoler le "technique" et passer directement au "niveau" supérieur sans doute pour cela que nous sommes clairement une des meilleurs écoles de France taux d'embauche quasi à  100%, salaire de départ permis les plus élevés à  36k nous sommes quasiment en tête devant toutes les autres écoles dans les palmarès Supinfo est une excellente école parfaitement adaptés à  l'intégration dans nos entreprises.


     


     


    Mais comme on semble me le dire ce système est une aberration, le job de technicien est complètement dévalorisé ( réserver au BTS, et autre formation de "bas niveau" ... ) tandis que celui de Project Manager ( qui existe que en France j'ai bien l'impression ) est poussé en avant et considérer comme la suite logique et le grade supérieur. Le job de manager pur c'est très peu valorisé dans les pays anglo-saxon il n'est pas au dessus du projet mais au centre, c'est déjà  une énorme différence ah mon sens. Survoler le technique pour aller directement au management ne fais pas de toi un bon chef de projet pour autant, comment tu peux gérer des gens si les mecs sont tous plus calé que toi et auront sans doute tous une meilleur idée de comment faire dans ton propre projet ? J'imagine même pas l'ambiance dans une boite quand tu dois avoir un chef de projet de 5/10 ans de moins que toi sortant de son master  et qui veux t'apprendre ton métier alors qu'il a à  peine gratter la surface de ta techno.


     


    Ce que je dis parais impossible, paradoxale con ? bah sans doute pour ça que toute nos entreprises se cassent la gueule aujourd'hui en France. On devrais peut être s'inspirer des plus grosses boites dans l'informatique pour voir ce qui marche, la France à  été pendant longtemps un des acteurs de la technologie numérique, que se sois dans le minitel ou dans internet il en reste quoi aujourd'hui ? Si Microsoft, Apple, Cisco, Oracle, Google, Facebook sont tous du même pays c'est peut être qu'ils savent mieux faire que nous, quand je vois juste les conditions de travail dans les entreprises américaines en informatique et dans la majorités des start up la bas c'est juste  un autre monde, le péon de base, le technicien est bien au centre de l'entreprise car c'est bien lui qui rapporte le plus pas le manager/chef de projet qui rend des comptes aux clients, patron et distribue plus ou moins les taches, d'ailleurs cette fonction n'existe pas il y un manageur pur, qui fais des études de management pas un master en informatique sans faire de technique avec un peu de management, et à  mon sens ce qui manque vraiment dans les entreprises que j'ai vue, le métier de Lead Dev. Le métier de Lead Dev c'est une valeur ajouté monstrueuse bien plus qu'un chef de projet et une équipe de 4 stagiaires ou de 3 mec sortant d'un BTS. Et pourtant cette fonction existe pas ou est peu reconnue à  cause du chef de projet.


     


    Comme je le dis un bon développeur comme on nous le dis dois passer chef de projet rapidement comme tu le confirme ( on n'est pas technicien ) or un chef de projet sans compétence technique et avec de vague compétence en management peut difficile apporté une vrai valeur ajoutée à  une entreprises malgré les apparences et l'exemple au dessus.


  • AliGatorAliGator Membre, Modérateur

    En fait l'agilité n'est pas très flexible, ça devrait s'appeler la rigueurité.
     
    Le vrai problème de tout ça, quelle que soit la méthode, c'est bien que le client ne s'intéresse pas assez à  la conception de son produit.
    Il n'a pas le temps de le spécifier. Il ne sait pas ce qu'il veut. Il n'y comprend rien, il n'a pas de smartphone lui-même.
    C'est un peu comme si l'équipe marketing/produit de Renault se déplaçait à  cheval.
     
    Je caricature à  peine.

    Et je partage ton avis à  100%. Le nombre de projets qui nous arrivent où rien n'est spécifié, le brouillon qu'ils appellent "Spec" est en fait un CDC, ou alors ça ressemble à  une Spec mais ça couvre que 10% des cas d'usage... Le client ne s'intéresse pas à  son produit, ne réalise pas toutes les incohérences qu'il y a dans son app qu'il n'a mm pas soulevées voire qu'il a spécifié lui-même, aux problématiques qui tournent autour (cas d'erreur, cas où il n'y a pas de réseau, etc), n'utilise mm pas de smartphone lui-même ("pour Android ? Oh, faites le même design et la même ergo que pour iOS." " ou vice-versa...).

    C'est bien malheureux, mais c'est malheureusement souvent vrai (que ce soit en SSII ou en Auto-Entreprenariat, j'ai fait les 2 et c'est une constante). Bon il y a des exceptions de temps en temps (et ça fait plaisir à  voir) quand même. Mais c'est pas la majorité...


  • Et je partage ton avis à  100%. Le nombre de projets qui nous arrivent où rien n'est spécifié, le brouillon qu'ils appellent "Spec" est en fait un CDC, ou alors ça ressemble à  une Spec mais ça couvre que 10% des cas d'usage... Le client ne s'intéresse pas à  son produit, ne réalise pas toutes les incohérences qu'il y a dans son app qu'il n'a mm pas soulevées voire qu'il a spécifié lui-même, aux problématiques qui tournent autour (cas d'erreur, cas où il n'y a pas de réseau, etc), n'utilise mm pas de smartphone lui-même ("pour Android ? Oh, faites le même design et la même ergo que pour iOS." " ou vice-versa...).




     


     


    http://forum.cocoacafe.fr/topic/13025-lexpert-en-réunion/#entry124479  xd



  • Le job de manager pur c'est très peu valorisé dans les pays anglo-saxon il n'est pas au dessus du projet mais au centre, c'est déjà  une énorme différence ah mon sens.




     


    Il faut simplement se rappeler que "manager" se traduit par "gestionnaire", alors que par chez nous on aurait tendance à  le traduire par "chef". Si on appelait tous nos managers "gestionnaires" ce serait aussi dévalorisant chez nous.


    Dans l'organisation du travail à  l'américaine il y a beaucoup de gestionnaires, et qui sont effectivement moins côtés que les techniciens.

  • Je sais pas si il y a des traductions exacte vue que les postes sont pas les mêmes, manager se rapproche du chef de projet à  mon sens avec bien moins de responsabilité voir aucune décision sur le projet.


  • LeChatNoirLeChatNoir Membre, Modérateur

    la question que tu dois te poser est :


    => qu'est ce que j'ai envie de faire / devenir


     


    Et ensuite : est ce que ce que j'ai choisi est valorisé.


     


    Là , j'ai l'impression que tu te demandes ce qui rapporte le plus...


  • MarcoDahMarcoDah Membre
    octobre 2014 modifié #24

    Là , j'ai l'impression que tu te demandes ce qui rapporte le plus...



     


    C'est pas le sentiment que ça me donne. J'ai plus l'impression qu'il cherche à  faire ce qu'il aime ( développer ) tout en ayant une valorisation de son travail aussi bien financière que apprécié à  sa juste valeur.


     


    Pour ma part, mon contrat stipule que je dois bosser sur l'application en particulier mais mon patron me fait faire 36 choses à  coté comme de l'administration système ou de la création de page web . Et à  coté il veut que l'application avance aussi vite que possible.


  • Je cherche le meilleur équilibre entre tous ça, avec des opportunités de carrière. Oui le mieux serais de créer ma boite comme çà  j'esquive les questions bizarre ...




  • Je cherche le meilleur équilibre entre tous ça, avec des opportunités de carrière. Oui le mieux serais de créer ma boite comme çà  j'esquive les questions bizarre ...




     


    C'est ce que j'ai fait, avec la même volonté de me défaire de ces pseudos-managers et commerciaux véreux, et du coup maintenant je ne développe plus ; je ne fait plus que du management et du commerce  B)



  • C'est ce que j'ai fait, avec la même volonté de me défaire de ces pseudos-managers et commerciaux véreux, et du coup maintenant je ne développe plus ; je ne fait plus que du management et du commerce  B)




     


    Et c'est vraiment ce qui me fais peur me résigner de plus en plus, travailler dans une SSII à  être parfois traité comme une ressource par un commercial qui pense réellement apporter plus à  une entreprise que moi car il à  vendue un projet à  150k et je ne serais que son exécutant autant dire que je pourrais pas faire çà  longtemps sans déprimer et faire autre chose ou passer de l'autre coté.


     


    Après il y a bien sur les start-up elle semble bien mieux pour les développeur, il y en à  énormément, trop même,  je compte plus le nombre d'étudiant d'école de commerce/management qui cherche désespérément un "exécutant" pour leurs idées révolutionnaires, te montrant le bisness-plan s'improvisant autant CTO que chef de projet, pensant que le cout de développement d'une application mobile c'est uniquement des lignes de code sur notre ordinateur, et que, quand je dois pas boucler leur application en moins de deux mois pour éviter la rémunération, je n'aurai que le minimum légale stagiaire. Mais j'ai aussi des bon exemple des ingénieurs maitrisant pas totalement l'aspect dev qui cherchais des associés bien conscient que tous le monde à  des idées, mêmes les techniciens. Après ouais le clivage commercial/technicien c'est autre chose.


  • Je cherche le meilleur équilibre entre tous ça, avec des opportunités de carrière. Oui le mieux serais de créer ma boite comme çà  j'esquive les questions bizarre ...


    Mais tu n'esquives pas la problématique de toute entreprise : trouver des clients ! Et ça c'est du commercial ..
  • Oui c'était mal formulé de ma part, c'était d'avantage de l'ironie qu'une vrai solution, monter une boite ne s'apprend pas dans une école et demande bien plus de responsabilité que certain semble naà¯vement le penser autour de moi, j'ai pas envie de foncer dans un mur après quelque années à  vouloir griller des étapes emmenant avec moi au chômage ceux qui ont crue en moi. Je le ferais quand je penserais pouvoir le faire si je peux le faire un jour, planter 4 start-up en autoentrepeneur je trouve ça débile mais si on me soutien que c'est bon à  mettre sur CV.


  • De mon point de vue d'entrepreneur, je vois les choses ainsi:


     


    L'idéal serait d'impliquer ses collaborateurs sur l'ensemble du projet mais dans les faits, c'est impossible. Se consacrer au développement ET à  la gestion du projet demande des compétences et des capacités hors du commun. Sans compter que les journées n'ont que 24h...


     


    Je voyais régulièrement des salariés venir me voir pour me dire que ce qui était fait était mauvais et que si nous faisions les choses de telles façons, nous serions plus efficaces et moins chers. Certains avaient beaucoup de mépris dans la bouche et ne cachaient pas beaucoup l'idée qu'ils se faisaient de la qualité du management.


     


    La plupart du temps, ils avaient raison mais ils n'avaient qu'une vision très tronquée de l'ensemble du projet: ils voient le détour mais ne peuvent pas savoir pourquoi il y a un détour alors que celui-ci décuple l'efficacité du projet.


  • tabliertablier Membre
    octobre 2014 modifié #31

    L'idéal serait d'impliquer ses collaborateurs sur l'ensemble du projet mais dans les faits, c'est impossible.



    Tout à  fait d'accord. Et dans la mesure ou un collaborateur n'est pas l'élément moteur d'un projet, la seule manière de le motiver, c'est de trouver la carotte qui le fait avancer. Je sais que cela parait un peu hypocrite, mais c'est ce que j'avais constaté.


     


    @Terin


    Les chambres de commerce ont des "stages" de gestion d'entreprise. Je n'y ai jamais participer et je ne sais pas ce que ça vaut.


Connectez-vous ou Inscrivez-vous pour répondre.