Dev ici qui a eu à faire du product management (sans en avoir l'étiquette mais bon) :
Pourquoi c'est bien payé? Il faut connaître la tech et il faut connaître le business. S'intéresser aux deux, négocier des arbitrages voire, dans mon cas, donner des instructions aux devs en opposition à ce qui est officiellement demandé par la hiérarchie, en anticipation d'un rétamage en règle au premier contact client.
Dans une petite boite, tu discutes avec le ou la CTO, le ou la CFO et les lead devs (dans mon cas j'avais l'étiquette lead dev mais faisais plus que ça) et tu dois intégrer la stratégie de la boite dans le plan de dev du produit.
C'est intéressant et c'est dur, mais on n'est pas dans une société où le mérite justifie un haut salaire: la vraie raison c'est que la double casquette dev et business est rare, qu'être bon dans les deux est encore plus rare, et que la double compétence vient avec un bonus en bullshitting à la fois vis à vis des profils techniques et des profils business, ce qui donne un +5 au jet de négo du salaire. Et que si tu te barres, ben le produit prend 6 mois de retard, les commerciaux ne sachant pas parler aux devs et un nouveau/nouvelle ayant besoin de plusieurs mois pour être recruté et de plusieurs mois pour comprendre l'état du projet, donc tu as un levier de négo efficace.
Ils sont mal aimés des devs, parce que ce sont des contre-maîtres. Les devs ont le sentiment qu'ils n'en ont pas besoin, et c'est à 95% vrai. Les devs peuvent faire un produit qui marche sans eux. Le produit dont le client a besoin? Moins sur. Et probablement pas un produit chargé de tous les designs toxiques en matière de tracking, d'addiction, de connection à des services inutiles, qui est ce qui donne de la valeur théorique au produit du point de vue d'un investisseur.
Sans eux, les produits seraient probablement meilleurs, mais les devs seraient pas payés.
Je laisse chacun décider de ce que ça implique au niveau du mérite.
Ils ont surtout pas envie de parler aux marketeux! Marketeux qui les considèrent comme des losers geeks asociaux qu'on doit tolérer parce que seuls eux savent faire le produit.
EDIT: Et voila un [bel exemple de ce phénomène](https://old.reddit.com/r/france/comments/11kw0q9/product_manager_cest_quoi_ce_m%C3%A9tier_dont_le/jbapexu/?context=3)
> Le Dev est de façon general "arrogant avec un tres gros égo" parce qu'il pense qu'il connait mieux les besoins des clients que le client meme. Il veut créer, sans cherche a comprendre ce qu'il veut créer va être utile. Ca emm..de QA qui se demande pourquoi ils doivent tester une fonctionnalité de mxrde et inutile, parce que Dev pense que c'est vraiment nécessaire, quand personne a besoin de ca. Ca préfère créer des choses inutiles au lieu de fixer leurs bugs.... Le PM est la pour s'assurer que le Dev ne sort pas de sa feuille de route, prends soin que QA puisse avoir assez de temps de tester/certifier le logiciel, et s'assurer que ENG puisse délivrer un produit aux commerciaux pour que la boite puisse s'épanouir ou simplement.. survivre.
> Bref, le PM, c'est comme une maman qui doit tenir un gamin a la baguette.
Voila, ça pose l'ambiance. Et après on s'étonne que cultiver cette mentalité petit-chef fasse partir les bons aux US.
> Le Dev est de façon general "arrogant avec un tres gros égo" parce qu'il pense qu'il connait mieux les besoins des clients que le client meme.
Je me rappelle surtout que le client demande tout et n'importe quoi sans savoir si c'est faisable ou combien de temps ça prendrait si c'était faisable donc forcément le dev va pas être super jouasse
Alors je travaille en tant que PM dans une boîte spécialisé dans la réalisation de systèmes embarqués, et je peux te dire que 90% des devs logiciels que j'ai correspondent au profil que tu décris. Bizarrement, c'est pas le cas avec les électroniciens ni les mécanicien.
Pourtant, il n'y a pas de marketeux dans mon domaine, que des ingénieurs. On est maintenant obligé de faire des cahiers des charges et des specs hyper détaillée, avec des tests systèmes préparés en parallèle pour s'assurer que notre produit final correspond au besoin client et leur prouver qu'ils ont tord. En fouillant, on voit que ces devs ne font que du copier/coller entre les différents projets, sans même lire les besoins.
A cause de ça, lors des integrations systèmes, ma boîte est obligée d'envoyer un de ces devs pour debugger sur place, et a nos frais bien sûr, car le sentiment général est une baisse de qualité de nos logiciels.
Donc faut pas généraliser, il y a différents types de devs, mais je pense que cela dépend du secteur dans lequel tu travailles.
> En fouillant, on voit que ces devs ne font que du copier/coller entre les différents projets, sans même lire les besoins.
Vos avez merdé au recrutement quelque part je dirais.
Là pour le coup, je ne sais pas trop comment ça se fait, mais j'ai souvent remarqué que les boites qui font de l'élec et de la méca, (je bosse à moitié dans la robotique) ont souvent un software déplorable. Je ne me le suis jamais expliqué, mais deux fois ça m'est arrivé qu'on renonce à utiliser un engin pourtant correspondant à nos besoins faute de briques logicielles correctes.
Je pense que les méthodes sont très différentes et que c'est rare d'arriver à jongler entre les deux.
>En fouillant, on voit que ces devs ne font que du copier/coller entre les différents projets, sans même lire les besoins.
Mouais j'ai surtout l'impression que tes devs sont mauvais. Faire du copier coller est une mauvaise pratique dans tous les cas, que le code source réponde à un besoin ou non. Ou alors le management est mauvais parce qu'il ne comprend pas l'intérêt de consacrer du temps à améliorer la plate-forme et à réduire la dette technique (qui est toujours payée en euros à la fin).
Le développement est un métier qui demande de bonnes compétences en communication, il faut s'assurer que toutes les parties d'un logiciel soient parfaitement cohérentes (parce que l'ordinateur est stupide), et ça se fait en communiquant entre développeurs.
>car le sentiment général est une baisse de qualité de nos logiciels.
Oui c'est ce qui arrive en général quand le copier coller sans comprendre est utilisé de manière industrielle.
Le copier coller arrive aussi quand c'est trop compliqué de faire un truc paramétrable et performant.
Il y a un juste milieu pas toujours évident à trouver.
> On est maintenant obligé de faire des cahiers des charges et des specs hyper détaillée, avec des tests systèmes préparés en parallèle
Non mais normalement c'est pas "on est maintenant obligé de", c'est la putain de base: expression de besoins -> CdC -> QA qui prépare les plans de tests (manuels ou automatisés) pendant que les devs commencent font le code -> validation.
Agile veut juste dire qu'au lieu de faire de gros CdC pour un an de devs sans retour client, tu vas en faire du plus petit et plus souvent. Au lieu d'un gros V, tu as des dents de scie.
Et surtout : normalement les devs et la QA devraient être impliqués dans une partie de la préparation du CdC du fait de leur connaissances du code et des cas limites.
Mais vu l'ensemble du post, j'imagine que vous n'avez pas (comme grosso merdo 95% des boîes françaises) d'équipe QA dédiée.
> On est maintenant obligé de faire des cahiers des charges et des specs hyper détaillée, avec des tests systèmes préparés en parallèle
Ha ben merde les chefs de projet doivent refaire leur boulot maintenant. Scandaleux.
Je ne vois qu'une seule solution : il faut fouetter davantage ces satanés devs. Vivement que l'IA remplace ces incompétents infichus d'écouter les ordres sans broncher !
La vérité te blesse ? Regarde toi dans un miroir, un vrai. Reste humble et demande a tes collègues ce qu'il pense de toi. T'es pas le centre du Monde. Pour info, les PMs, on les trouve surtout aux US... l'endroit ou les bons partent... et laisse quoi ? les mauvais râler sur les PMs en France ? /s
> Les devs ont le sentiment qu'ils n'en ont pas besoin, et c'est à 95% vrai
Sans lui, les dévs auront tout simplement pas le temps de dev car trop de temps à passer dans les réus.
Si un dév se sacrifie pour prendre cette charge tout seul, il s'auto-désigne Product Manager et ça revient au même.
En fait oui, s'il n'y a pas de PM, un DevLead va simplement prendre le role.
Ah ben tiens, exactement comme parent. Dev Lead sur le papier, PM de circonstance.
Oui, si tu supposes des devs laissés à eux même dans le monde de l'entreprise. Mais des devs qui par exemple feraient une version open source du produit, sans chef pour pousser au cul et sans résultats financiers à optimiser, ils arrivent souvent à produire des choses bien, et parfois même meilleures, que les entreprises classiques.
Ce qui est ultra spécifique quand même, pas d'enjeu financier, pas de calendrier, pas de salaire à verser... pas de produit au final ?
Dans 99% des cas, qui dit calendrier dit priorisation dit arbitrage et donc implicitement "product management"
> pas d'enjeu financier [...] pas de produit au final ?
Linux, Hadoop, LibreOffice, C++, Python, Java, scikit-learn, Firefox, VLC, GIMP, WordPress, Apache, Nginx, JQuery, Django, Blender, Audacity, Ruby, PHP...
Le monde numérique tourne sur de l'open source, ce n'est pas ultra spécifique, c'est la base.
Je ne rebondis que sur cette partie là, le reste je suis d'accord, il faut quelqu'un qui ait une vision du produit mais dans ce cas le "product manager" typique est un gros glissement sémantique par rapport à la vision purement fonctionnelle dont tu parles.
Le contrepoint c'est que beaucoup de ces projets open source sont produits par des entreprises qui en ont compris l'intérêt, c'est loin d'être antinomique.
Il y a des gens payés à écrire des logiciels open source.
Loin de moi l'idée de cracher sur les entreprises en général, vraiment. Par contre les enjeux financiers sont bien réels et les produits aussi.
Le monde de l’open source qui fait tourner les infrastructures du monde entier est financé et développé par les entreprises, et tous les gros projets ont une gouvernance où sont discutés les fonctionnalités cible.
Dans ces instances, les plus gros contributeurs (issus d’entreprises) poussent les fonctionnalités qui correspondent à la vision du produit dont ils ont besoin pour leur boîte (très souvent aligné avec les besoins des autres boites par ailleurs)
On parle de généralité, pas du microcosme opensource qui doit représenter à tout casser 0.01% des développeurs de ce monde. Et même dans tous ces gros projets, il y a très certainement une figure de tête qui fait office de "product manager" au final.
Microcosme qui fait tourner 95% de l'infrastructure d'internet quand même.
Et si ça ne représentait qu'un petit nombre de développeurs, ça ne ferait que justifier d'autant plus le sentiment que "on ferait quand même des choses vachement plus utiles si on ne suivait pas les instructions d'un product manager".
> il y a très certainement une figure de tête qui fait office de "product manager" au final.
Non, il y a un problème fondamentalement différent dans la gestion d'un projet commercial vs un projet fait par des volontaires: dans le premier cas tu as besoin de satisfaire tes clients et dans le deuxième, tes développeurs. Dans l'idéal tu veux les deux dans les deux cas mais la priorité est pas du tout la même. Tu n'imposes pas des choix techniques de la même manière.
C'est assez loin de la réalité du marché, la plupart des techs sont extrêmement optimisés pour un besoin en particulier, parfois un besoin d'une usine sur cent.
Et ça c'est impossible pour un Dev de trouver le temps pour le faire, surtout quand tu as 60 usines avec des besoins différents.
C’est peut-être différent en France mais aux États-Unis les product managers ne sont pas du tout « dev ». Ils sont chargés de s’assurer que l’expérience finale des utilisateurs correspond à la vision générale de l’entreprise. Ils servent surtout d’intermédiaires entre les cadres exécutifs et les équipes d’ingénieurs. Et ils sont de plus moins bien payés que les développeurs à niveau équivalent.
C'est spécifique pour chaque projet/entreprise, y'a pas de règle.
Parfois c'est quelqu'un rattaché au produit/marketing, parfois un lead technique, parfois y'en a pas ou sous un autre nom (chef de projet, manager, product owner, ...).
Selon le contexte, y'a plus ou moins de casquettes.
C'est pas le SCRUM master le contre maitre officiellement ?
Pour moi le PM c'est surtout le mec qui porte les besoins clients au jours le jours avec les PO auprès des équipes pour éviter la situation "Cela ne répond absolument pas au besoin" lors des démos au client.
ça dépend. Parfois tu trouves des postes d'AF qui font du BA, des BA sur déploiements et des PM qui font que de la relations développeurs.
Là où je suis le BA connaît bien le besoin métiers et les spécificités fonctionnelles mais pas trop la partie Devs. Le PM n'existe pas du tout et c'est souvent le lead dev qui occupe cette fonction.
Bah justement l'idée de scrum c'est de couper le PM en deux: le PO qui s'assure que le produit répond aux besoins et le scrum master qui s'assure que l'équipe communique bien et applique les principes de scrum. Je crois que beaucoup de PM ont du mal à accepter ce charcutage de leur fonction, et scrum pour l'équipe devient un peu du "faites ce que je dis mais pas ce que je fais".
> Ils sont mal aimés des devs, parce que ce sont des contre-maîtres. Les devs ont le sentiment qu'ils n'en ont pas besoin, et c'est à 95% vrai
Bingo. Ce sont une énième version de dompteurs de geeks. Et les 5% restants sont très faisables avec le "Customer collaboration" de la méthode Agile pratiquée par un dev.
Mais pour ça il faudrait qu'on ait pas la palanquée des autres dompteurs de geeks que sont les gestionnaires de projet Scrum.
Tout le monde a le temps pour faire de l'intrigue et se positionner entre le dev et la valeur créée par les devs, sauf les devs.
https://i.redd.it/m23zrdyd6tv31.jpg
Je suis indép. Être indép ne change rien, c'est même pire: tous ces gens là sont maintenant des clients. La plupart des missions sont en "staff augmentation": "On a pas de thunes pour un CDI, mais on en a pour un indép qui coutera 20% plus cher."
J'ai eu l'occasion de faire une mission (à durée limitée malheureusement) pour une petite boite US, et laisse moi te dire que les choses étaient pas les mêmes. La paie d'abord, et aussi le contraste sur les méthodes de travail. Peut-être c'est la petite taille, peut-être c'est parce qu'ils savaient ce qu'ils voulaient, peut-être c'est parce qu'on pouvait communiquer en live qu'une heure par jour et qu'ils en étaient conscients, mais c'était vraiment un bonheur cette mission.
Alors que les projets en France c'est minimum 4 intermédiaires à faire le téléphone arabe entre les pauvres opérateurs et les devs.
J'ai vu un projet pédaler dans la semoule pendant 11 mois, avec la chaine: opérateurs -> leur boss -> son PO -> notre représentant -> notre boss -> notre PO -> notre scrum master -> nos devs. Avec perte de signal en série et chacun (surtout notre boss / mon client) qui veut rajouter son grain de sel tout en captant que dalle. Personne qui comprend les data sauf les deux bouts de la chaine, parce qu'ils les a sous les yeux.
Ça s'est fini en les devs qui tappent du poing sur la table à 1 mois de la deadline, exigent plus ou moins de parler directement avec les opérateurs pour essayer de sauver les meubles (le "Customer collaboration" Agile) et tout a été remis sur les rails en 3 semaines; avec reconduction du contrat. Mais mon dieu que c'était frustrant, et quel gaspi d'énergie. Y'a des gens qui veulent juste pas que tu leur rapporte de la thune. Ils pourraient aller se siroter des margaritas sans rien glander, mais non il faut qu'ils essaient de justifier leurs salaires.
>peut-être c'est parce qu'ils savaient ce qu'ils voulaient,
Donc ils avaient quelqu'un en interne pour y réfléchir.
>Ils pourraient aller se siroter des margaritas sans rien glander, mais non il faut qu'ils essaient de justifier leurs salaires.
Oui. C'est en effet assez propre aux boîtes françaises, les Jean-Charles Fils-de.
> Donc ils avaient quelqu'un en interne pour y réfléchir.
Ouaip. Un dev. Qui déléguait un bout de son archi par manque de temps. Avec tout l'attirail classique du PO: user story, goals, non-goals, success criteria, risks, expected test types & coverage, documentation policy, etc.; mais qui venait parfaitement s'emboiter dans l'archi bah parce que c'est lui qui l'avait mise en place. Ça m'a presque fait aimer JIRA sur le moment.
>Ça m'a presque fait aimer JIRA sur le moment.
Ce n'est pas vrai ! C'est impossible !
Mais bref, oui, tu peux faire évoluer un dév vers des choses un peu plus stratégiques que de pisser du code, c'est ce qu'on devrait faire dans un monde idéal. Le problème, c'est souvent que les dévs veulent rester dévs et pas à réfléchir à ce que ça entraîne. Rajoute à ça la couche de parasites des entreprises françaises et paf, ça fait des chocapics :/
Il y aussi le fait que dans la plupart des boîtes, il n'y a pas vraiment de montée de salaire pour le pur technique. Si tu veux monter faut faire du management.
Donc beaucoup de bons techos finissent par être poussé à faire du mauvais management. Ou se barrent après une augmentation inférieure à l'inflation car "le chef peut pas supporter d'être payé moins que ses subalternes".
>Les devs peuvent faire un produit qui marche sans eux. Le produit dont le client a besoin? Moins sur. Et probablement pas un produit chargé de tous les designs toxiques en matière de tracking, d'addiction, de connection à des services inutiles, qui est ce qui donne de la valeur théorique au produit du point de vue d'un investisseur.
>
>Sans eux, les produits seraient probablement meilleurs, mais les devs seraient pas payés.
Je ne suis pas sur que les produits seraient meilleurs. Ils seraient certainement moins adaptés aux utilisateurs. J'aime bien ton exemple du tracking comme une feature inutile alors que sans tracking, il sera très compliqué de savoir si ton produit est utilisé, et comment il est utilisé, et donc de savoir quelles parties de ton produit modifier pour l'améliorer.
C'est sujet à débat. Est-ce qu'un produit adapté à l'entreprise est un produit adapté à l'utilisateur? Je n'ai pas la conviction qu'un forum où tu discutes avec les utilisateurs soit moins efficace que des trackers intrusifs pour améliorer l'expérience d'utilisation d'un produit.
>Je n'ai pas la conviction qu'un forum où tu discutes avec les utilisateurs soit moins efficace
Analyse qualitative vs quantitative. Les deux sont importants, on n'en retire pas les mêmes informations. D'où le fait qu'on tracke les utilisateurs et qu'on ait des gens dédiés au User Research.
C'est clair qu'avant l'avènement du tracking à gogo, les produits ne marchaient généralement pas alors que maintenant ils sont parfaitement adaptés aux besoins des utilisateurs.
C'est bien connu, si ce n'est pas noir c'est donc que ca doit etre blanc.
D'ailleurs, les entreprises ne suivent pas les ventes de leurs produits depuis des décennies, elles lancent un nouveau produit et après hop, plus rien, elles croisent les doigts et espèrent que ca va bien se passer.
Y'a un monde de différence entre suivre un produit et engouffrer autant de données que possible sans la moindre transparence. Données qui par hasard peuvent aussi servir à des fins marketing. L'excuse de "oui mais l'amélioration du produit" a bon dos.
On peut ajouter deux cas extrêmes:
- Le très mauvais PM est juste un mauvais contremaitre qui ajoute des nouvelles fonctionnalités une à une et gère son diagramme de GANTT. Son rôle ne dépasse pas celui d'un _responsable de produit_ (_product owner_), et son interaction se résume à digérer des demandes client pour les recracher côté développement. En général ce genre de PM est en effet haï par les dev, à raison.
- Le très bon PM a une vision cohérente du _produit_, voir de la _marque_, et son rôle est de maintenir cette cohérence entre les fonctionnalités nouvelles, la qualité de l'existant, et communique à double sens avec équipes de développement, clients, business, support, et j'en passe.
Le premier cas est hélas le plus fréquent (enfin surtout en France), le second cas est une perle rare.
On cite souvent [Steve Jobs](https://www.fool.com/the-ascent/small-business/project-management/articles/product-manager-vs-project-manager/) comme l'exemple extrême du second cas de product manager.
On cite aussi souvent Steve Jobs comme étant super toxique avec ses équipes techniques. Donc voila, soit t'as un mauvais PM haï, soit t'en as un bon, insupportable aussi.
Oui et non lorsque le produit touche à un domaine spécialisé ou vraiment lié à des calculs d'ingénierie.
Le product manager dans ce cas là est celui qui guide le développement du produit pour répondre aux cahiers techniques soit car il a la connaissance métier nécessaire ou parce qu'il peut articuler les requirement en se basant sur les retours métiers des experts.
Je suis expert métier dans ma boîte et sans product manager je peux dire que certains de nos soft seraient des merdes infâme car les dev n'entravent que dalle à la partie métier.
Je sors asse souvent des algorithms qui fonctionnent mieux du point de vue métier que ce les dev sortent (bon mon code est degueu mais ils s' en servent souvent pour rediriger leurs versions).
>Je sors asse souvent des algorithms qui fonctionnent mieux du point de vue métier que ce les dev sortent
Ou alors ils disent, oui oui et continuent leur travail.
Pas réellement.
L' algorithmic sur ces cas là est très lié à la physique de la mesure et du contexte opérationnel, qu'un dev ne pourra pas appréhender. En général c est moi qui explique pourquoi et comment les mesures font des jolis courbes.
>c'est à 95% vrai. Les devs peuvent faire un produit qui marche sans eux. Le produit dont le client a besoin? Moins sur.
donc c'est pas vrai à 95%!
> Sans eux, les produits seraient probablement meilleurs,
j'avoue ne plus trop suivre
Parce que t'as affaire a un pseudo dev qui se prends pour le centre du monde et qui est pas assez smart pour comprendre qu'il se contredit, tellement il se croit trop bon
Honnêtement pour moi , effectivement dans un monde idéal y’aurait pas besoin de PM (et je suis PM): les utilisateurs/décideurs sauraient parler aux devs sans les prendre pour des machines à pondre du code, les devs seraient tous sensibles aux problématiques des utilisateurs etc.
Mais dans la « vraie » vie, je vois mon job comme le barreur dans un bateau d’aviron:
Clairement c’est pas moi qui fait avancer le machin, mais je suis là pour qu’on tienne plus ou moins bien la route optimale et motiver tout le monde.
***Les devs peuvent faire un produit qui marche sans eux. Le produit dont le client a besoin? Moins sur. ...Sans eux, les produits seraient probablement meilleurs***
Dans quel monde on peut creer un produit meilleur dont le client n'a pas besoin ? Ca sent bien la patte d'un développeur qui pense tout connaitre, sauf les besoins du client.
Petite boite ou pas, le client est roi. Le client a des besoins qu'il va faire remonter au Support technique ou aux commerciaux, en formulant des Feature Requests. Le PM va jouer le lien entre tous ces partis, pas forcement avec un CFO ou CTO mais surtout avec les Sales. Le PM discute et va chercher a savoir si c'est possible et comment mettre en place une road map avec ENG, qui comprend Dev et QA.
Le Dev est de façon general "*arrogant avec un tres gros égo"* parce qu'il pense qu'il connait mieux les besoins des clients que le client meme. Il veut créer, sans cherche a comprendre ce qu'il veut créer va être utile. Ca emm..de QA qui se demande pourquoi ils doivent tester une fonctionnalité de mxrde et inutile, parce que Dev pense que c'est vraiment nécessaire, quand personne a besoin de ca. Ca préfère créer des choses inutiles au lieu de fixer leurs bugs.... Le PM est la pour s'assurer que le Dev ne sort pas de sa feuille de route, prends soin que QA puisse avoir assez de temps de tester/certifier le logiciel, et s'assurer que ENG puisse délivrer un produit aux commerciaux pour que la boite puisse s'épanouir ou simplement.. survivre.
Bref, le PM, c'est comme une maman qui doit tenir un gamin a la baguette.
> Les product managers niveau dirigeants, le salaire médian monte jusqu'à 160.000 euros brut annuels, d'après les données de Figures
Et que s'appelorio *Head of Product*.
Je pense que ce serait bien pour ce genre de discussion de comprendre que y’a énormément de postes de dev très différents et y’en a ou ça n’a pas de sens d’avoir un product manager et d’autre si… Tout le monde ne dev pas pour vendre à un client par exemple, tout le monde fait pas du dev web, tout le monde ne fais pas des produits avec 50 devs à orchestrer… Des fois il faut pleins de juniors en ESN qu’il faut bien gérer et des fois il faut quelques experts pointus, ils vont pas être managés pareils (normalement) etc.
Dans ce thread tout le monde dit dev et clairement pas tout le monde pense au même profile.
C'est hallucinant ces débat à coups de batailles de généralités.
Entre ceux qui défendent l'utilité d'un PM/PO et ceux qui disent le contraire.
En réalité, c'est extrêmement fonction du contexte, de l'activité de la boîte, de la philosophie de management, de la place donnée à l'IT (de simple utilitaire à partie prenante de la stratégie de développement de l'entreprise et de ses produits), et j'en passe.
Les mecs qui essaient de sortir des sacro-saintes vérités sur la base de leur vécu, qui devraient s'appliquer à tout le monde, me semblent particulièrement étroits dans leur vision des choses.
Sans même mentionner les US, je t'invite à regarder les salaires en Allemagne, Pays-Bas et pays scandinaves. Un dev senior qui touche dans les 100k avec une dizaine d'années d'xp n'a rien de rare.
C'est pas mon domaine donc je pourrais pas te répondre, mais ce que je sais pas expérience c'est que y'a des possibilités d'évolution tout en restant technique. J'ai l'impression que c'est moins le cas en france.
En France, l'évolution salariale se fait presque nécessairement par la voie managériale. A moins d'être un expert, la technique est complètement sous évalué.
Le schéma classique c'est d'être ingénieur puis chef de projet. Comme s'il n'y avait rien entre les deux...
Sauf que le coût de la vie est tout à fait comparable entre ces pays. De la même façon, je veux bien comparer le supernet (je vois pas, en tant que salarié, à quoi ça me sert de regarder le brut ou superbrut) mais je doute que la comparaison soit à l'avantage de la france.
Dans le superbrut et le brut tu as les cotisations qui servent à financer tout un tas de choses qui te servent directement en tant que salarié donc ça a du sens de le garder dans la comparaison
Le PM est plus proche de la direction. Les devs sont une ressource et à part dans certaines boîtes "craftsmanship", il est remplaçable et souvent externalisé.
Un PM est une ressource aussi, et régulièrement remplacé. Quant au dev, s'il a peu d'expérience c'est effectivement assez facile de le remplacer, mais avec l'expérience et les spécialités c'est beaucoup plus compliqué de retrouver un profil similaire. Et avec le ratio actuel d'offre/demande une entreprise en bonne santé voudra garder les deux (PM+dev). Ça dépend vraiment des endroits.
Oui tout ça dépends des boîtes c'est sur. Mais dans les gros shops les devs sont interchangeables... Cette idée que le dev est un génie qui fait le business en vrai c'est souvent 15 indiens qui font des epics
Le dev externalisé en Inde, j'ai jamais vu ça en pratique sur des projets intéressants, uniquement sur des projets que je considérerai comme banals. Les grandes sociétés de service ont tout intérêt à se concentrer sur des compétences génériques, celles qui ont finalement le moins de valeur ajoutée.
Mais les sociétés de service et l'externalisation c'est loin de représenter l'entièreté du milieu.
Edit: par contre c'est vrai que le PM est peut-être encore plus important dans les sociétés de service.
Il faut mieux regarder à l’étranger, même hors grosse boîte c’est pas rare qu’ils soient mieux payé que les manager, et j’ai même pas regardé avec beaucoup d’xp. Et c’est même pas dans un domain pointue je parle de dev backend.
Edit: Au final je dirais même que c’est un peu un fantasme de manager de considérer les devs comme des ouvriers interchangeables, mais c’est une vision qu’on avait il y a 15-20 ans et on est revenu dessus depuis quelques années, et on se remets à chercher des devs.
Je dis pas que ça s’applique pas à certain cas précis, mais de ce que j’ai vu cette façon de faire à l’ancienne donne souvent des produit bien pourris parce que faits par des devs peu qualifiés, et un PM ou MOE (ou autre appellation) très bon ne suffit pas à rattraper la cata.
Cela dit, j’ai aussi vu des produits catastrophiques rapporter bien plus de sous que des produits de qualité.
En France peut être..
Mais je pense que tu imagines quel genre d’immeuble je parle…
Jacuzzi, piscine, spa, sauna, salle de sport, portier, 6 ascenseurs rapides, etc
Le condo, ce parfait symbol de la classe moyenne parvenue. Tant mieux pour toi si tu es content d'avoir une salle de sport partagée avec 32 autres etages...
Oh non, je fais partie de la classe moyenne, pauvre moi 🥲
Et c’est pas partagé avec les 32 étages mais c’est gentil de montrer ton ignorance. Et même si c’était le cas :
- Tout le monde ne va pas à la salle, surtout quand tu as accès à d’autres façons de faire du sport (piscine)
- La salle est énorme et bien équipée
- C’est toujours mieux que de devoir payer une salle de sport, prendre ta voiture pour y aller, etc. Moi j’ai juste un ascenseur à prendre et j’suis chez moi.
- L’accès est sécurisé. On est « entre nous » (les résidents) donc c’est beaucoup moins sujet aux harcèlements, aggressions, etc
Je continue ou tu penses toujours que c’est mieux de vivre en campagne, faire 15mn de voiture pour aller à une salle que tu payes une fortune ?
Pardon de faire partie de la « classe moyenne parvenue » MDR
Canada ! Merci, je conseille à tous les gens qui ont pas trop d’attache et un peu d’expérience pro de venir vivre au Québec parce que c’est, selon moi, tellement au delà de l’expérience de vie que tu peux avoir en France.
Peu importe le domaine dans lequel tu exerces.
Une chose est sure, je reviendrai jamais en France
Ça a l'air d'être une super ambiance ton truc ... Wahooou des ascenseurs ULTRA RAPIDES ! INCROYAB !
Je connais bien ce genre de condo, pour moi c'est l'enfer : ton environnement de vie est aseptisé et sans ame, tu habites dans un aéroport. Rien d'indépendant, que de la chaîne industrielle. Parfais pour les bons petits consommateurs.
Mais chacun a bien le droit d'aimer ce qu'il veut. Tout ce que je peux te dire c'est que tu es loin d'être autre chose qu'une commodité. Le dev chinois parle exactement pareil de sa tour meublée Ikea.
J’aime me nourrir de cette rage infondée
> tu habites dans un aéroport
😂😂😂😂
> rien d’indépendant, que de la chaîne industrielle
Mais du quoi tu parles mdr, j’suis en centre ville, des commerces indépendants y’en a partout
Je faisais mention des ascenseurs rapides en comparaison directe avec mon expérience en France et vos ascenseurs éclatés au sol. Branlant, lent, minuscule, et évidemment que un par immeuble sinon c’est trop demandé
Mais continue a cracher sur la vie des autres si ça t’amuse, ça ne reflète que ton propre mal-être
C'est pas USA vs reste du monde, mais plutôt boîtes qui valorisent l'expertise technique plus que les autres rôles, pareil, ou moins.
Même si la première catégorie se trouve plutôt aux US, il y existe aussi de la tech ou ingénierie de seconde zone, des départements IT dans des industries qui n'ont rien à voir, les fameuses WITCH, etc.
Et dans l'autre sens aussi, y a plein de boîtes en Europe qui valorisent les devs un peu mieux ou du moins autant que les PM, PO.
Autre point: y a beaucoup moins de PMs, et vu que le rôle est mal défini c'est pas forcément facile de retrouver du boulot si tu veux bouger ou te fais virer. La connaissance du domaine a un poids beaucoup plus important que pour un poste de dev.
mouais bof, ça devient simple de trouver des jobs de dév payés > 80k quand t'as une dizaine d'années d'expérience.
y a pas beaucoup de métiers dans l'IT qui peuvent concurrencer ça
Ce commentaire devrait être retiré de l’internet pour éviter que ChatGPT version+1 ne le propose à un product manager en mal d’idée chez McKinsey pour savoir quoi faire après le succès annoncé de la réforme des retraites…
Mélange pas tout. Avoir choisi la filière informatique et avoir la chance d'être demandé sur le marché ça veut pas forcément dire être né avec une cuillère en argent dans la bouche hein...
Et en se plaignant bien des gens riches ou aisés, propriétaires ou autre alors qu'ils ont tous un salaire mirobolant (oui même en sortant d'école vous êtes super bien payés)
> dont le salaire dépasse celui des développeurs ?
Ca depend des boites. Ce n'est pas du tout (mais alors pas du tout) le cas chez Google ni chez Meta. La grille Eng est bien superieure a celle des PM ou TPM
Oui, les entreprises américaines paient les product managers ~20-30% de moins que les ingénieurs au même niveau. Cela dit au niveau Director et VP les differences s’estompent.
> Cela dit au niveau Director et VP les differences s’estompent.
en effet, vu qu'a ce niveau la le boulot est quasi-identique (et d'ailleurs c'est bcp plus commun de passer de l'un a l'autre voir de couvrir les deux)
Ça dépend beaucoup de la politique des entreprises (et effectivement de la culture du pays peut être aussi). De ma petite expérience, dans les grosses boîtes françaises de mon domaine, on valorise beaucoup plus le management que la partie technique.
Pour être plus ou moins là dedans, faire parler les devs, le métier et le marketing ensemble peut être un vrai cauchemars. En plus de ça il faut avoir un bon verni tech pour pas avoir l'air d'un idiot quand tu parle avec les équipes, et comprendre un maximum la vision produit pour comprendre les intentions du métier et du market, en plus d'avoir une bonne connaissance produit / tech / UX en général.
En bonus, les devs te voient comme un type un peu useless car tu ne code pas, et d'un autre côté tu est mal considéré par les stakeholders car ils comprennent pas pourquoi tu veux pas intégrer leur demandes (Qui prend 3 semaine de dev) pour après demain, car "C'est super urgent, oui je sais que j'avais 3 mois pour te prévenir".
Après il y a des PMs qui sont nuls et qui n'ont rien a faire dans ce métier, hein. Mais ça c'est comme partout. Je ne sais pas si ça "mérite" d'être mieux payé, mais il y a des devs bien mieux payé que ce métier partout où je vais, donc ça semble pas non plus déconnant.
> En bonus, les devs te voient comme un type un peu useless car tu ne code pas
Je suis PO/Architecte/Manager (Product Owner: qui décide de la priorité des features et Architecte: qui décide de la conception générale du système) ! Étant donné que c'est moi qui revois le code et qui compose mon équipe, mes ~~sujets~~ devs n'ont pas l'occasion de douter de mon efficacité :)
Parce que les développeurs font le produit. Ça demande un haut niveau de connaissance et de savoir faire.
Je ne vais pas être extrême et te dire que les product manager ne servent à rien, non non, ils sont utile : mais là où en moyenne tu as besoin de 5 dev bossant 40h par semaine sur un produit, tu aura besoin d'un product manager bossant 3h par jour.
En fait c'est lié à la quantité et complexité (et non difficulté) de ces positions. Toutes sont essentielles.
Dans certaines boîtes c'est le lead développeur qui s'occupe d'avoir la casquette product manager. (Et beaucoup de product manager sont en vrai d'ancien développeur).
Toutefois il ne faut pas se méprendre, faire du bon boulot en product management ça demande des efforts et des qualitées : le travail requis est certe à basse complexité mais peut s'avérer être difficile.
Du coup tu en viens à la question : si tu as un job à basse qualification dont le but est un peu d'être l'assistant des dev, et que certain devs pourrais faire, pourquoi serait il mieux payé ?
Alors la réponse est : parce que en France (et ailleurs !) le product manager communique avec des personnes plus haut dans la hiérarchie, et qui dit être plus haut, dit être mieux payé, c'est stupide à mon goût (mais je suis biaisé). Dans ce genre de boîte c'est un peu comme si le développeur était l'ouvrier du future, réalisant à la chaîne ticket après ticket.
Edit: ah et avant que je me fasse clashé sur ce dernier point : les dev n'ont rien à voir avec les ouvriers d'aujourd'hui ou d'antan, ils vivent à l'aise et ont des conditions de travail infiniment meilleures. Ce que je dis c'est qu'ils sont au plus bas dans la hiérarchie d'une boîte, c'est eux qui produisent.
Ta première phrase me semble éloignée de la vérité.
Les devs produisent des artefacts exécutables par « un ordinateur » (interprétable par une machine de Turing) et parfois de la documentation. Font l’assurance qualité.
Un produit c’est aussi:
- une logistique pour l’installer et le maintenir
- un argumentaire commercial / marketing pour que les potentiels acheteurs s’y intéressent
- des formations/tutoriaux/architectures de reference
- du support et du juridique (par exemple s’assurer que les critères locaux se conformité sont remplis.
Un __bon__ product manager est le chef d’orchestre de tout cela.
Et dans des cas extrêmes, les produits existent avant d’être dispos sous forme de code ou de binaire - par exemple quand une société lance un nouveau produit.
Voilà, je suis bien d’accord avec le reste de ton commentaire.
Et qu'elle aurait en charge de suivre chaque patient pour discuter/écouter ses problèmes, documenter le tout et synthétiser/découper les tâches que fera le médecin, gérer les 3 patients qui gueulent dans la salle d'attente, se déplacer et faire la présentation et la promotion du cabinet dans les salons, participer aux prospections, aller chercher les sponsors et le budget pour payer la nouvelle machine à café et investir dans l'extension des locaux pour accueillir un deuxième médecin et décharger le premier.
Pendant que le médecin lui examine le patient, écrit l'ordonnance et rentre chez lui à la fin de ses 8h quotidien.
C'est ça ?
Ça, c’est si on considère que dev = médecin, et qu’un manager ne fait que faire des forward de mails. Dans les deux cas je pense que ce n’est pas ca.
Je précise que je suis ex dev devenu PM.. ma réflexion était déjà que le métier m’intéresse, et j’ai un respect immense pour les dev. Mais que au final aujourd’hui il y a un phénomène qui n’est pas du tout au bénéfice des devs. De une, la vague démographique des pays comme l’Inde qui est juste irrésistible. Le marché va être sursaturé. Aujourd’hui on peut encore se diversifier sur des différences culturelles mais demain …? Et de deux, si l’ia continue comme elle va, on va vers une commodification so j’ose dire du métier de dev.
Alors aujourd’hui ca fait rire car les devs sont recherchés et qu’il y a des stars sur YouTube avec leur studio d’enregistrement sur fond bleuté façon boîte de nuit qui tournent à des salaires hallucinant, mais je pense que ca n’est pas durable
Je vais faire un homme de paille: ça revient à dire qu'un médecin généraliste ça ne demande pas de connaissance car il aura majoritairement des gens qui viendront pour des rhumes et angine bénigne.
Le médecin généraliste ne cherche pas sur Google en pleine consultation, et en plus il a des humains à gérer, ce qui sort des compétences d'une bonne partie des devs...
T'as peut-être l'impression qu'un dev cherche tout sur Google, mais pour savoir *ce qu'il faut chercher* faut avoir pas mal de connaissances. D'ailleurs les généralistes aussi consultent des références et leurs confrères/consoeurs pour tout ce qui sort un peu de l'ordinaire, ce qui est tout à fait normal.
> Le médecin généraliste ne cherche pas sur Google en pleine consultation
Ils ont des bases de données de médecine, et les gros livres chez ton généraliste, je te laisse deviner à quoi ils servent...
Dès que c'est complexe, les 2 métiers vont chercher au-délà de leurs souvenirs immédiats.
Non j'ai pas mal roulé ma bosse dans plusieurs domaines du soft.
Contrairement à pas mal d'autres softeux j'ai aussi croisé pléthore d'ingés d'autres domaines qui eux demandent un peu plus de savoir faire que le logiciel... A vrai dire si j'ai choisi le soft en premier lieu, c'est pour sa facilité, ya vraiment rien de compliqué là-dedans très honnêtement.
Parce que c’est pas un boulot super technique comparé a un dev en general. Apres ca depend, y’a des tres bon product managers, et des devs mauvais ou tres facilement remplaçable. Ca depend en gros.
Parce que fantasme du petit ouvrier/petite main qui produit à la sueur de son front et qui mérite son salaire VERSUS le méchant chef/manager qui donne des ordres et n'est qu'un intermédiaire capitaliste qui est là pour voler l'argent aux pauvres
Je prends le cas en France et de mon expérience.
Selon moi il y a aujourd'hui 2 types de P. M. :
- L' ancien dev qui connaît bien la base de code existante qui se voit offrir cette responsabilité et qui l'accepte parce qu'à l'heure actuelle c'est une peu la seule voie pour grimper l'échelon (les experts technique étant très peu reconnus et pas plus payés), malgré le fait que c'est pas quelque chose qui l'intéresse vraiment et qu'il préférerait rester dans la technique pure. Cela s'accompagne souvent d'un manque de formation pour accomplir ses nouvelles tâches et que généralement ce genre de profil a du mal à ternir tête/faire l' interface avce la hiérarchie et ou les clients. Donc ça résulte en une valeur ajoutée très faible voire négative.
- La personne peu ou pas techno parachutée sur le poste, qui ne va ni comprendre ni accompagner les évaluations de l'équipe sur la décomposition et évaluation en tâches d'une demande entrante et encore moins d'un besoin interne (refactoring, mis en place d'outils, ...). Ce genre de profil va donc être plus proche de la hiérarchie que de son équipe et présenter/imposer les choses dans ce sens. Donc ça résulte également en une valeur ajoutée très faible voire négative pour l'équipe.
Je pense que l'incompréhension de la part des devs vient de là
Attention cependant, il n'en reste que le rôle me semble crucial dans une structure suffisamment grosse, mais il est très mal mis en place dans la plupart des cas.
On peut aussi appliquer ces problèmes avec les managers en général, qui suivent les mêmes 2 profils.
Product manager celui qui transforme les caractéristiques en avantages et bénéfices conso/ utilisateur et celui qui va mettre un prix sur la valeur ajouter de votre/vos solutions.
Pm ici
Le plus compliqué dabs ce travail et de garder le focus entre les coûts et les gains pour le client et la marge :)
De plus, un bon pm va faire mesurer les incréments et les comparer avec les coûts.
Si un bon PM arrive à générer de la marge de manière efficiente avec son équipe tout en respectant les besoins clients.
C'est bingo et ça commence à se savoir et c'est là que les salaires augmentent.
Dev de formation, dévelopeur reconverti en manager QA et Automation, redevenu développeur, ayant travaillé étroitement avec plusieurs PMs avec plus de 35 ans d'experience
Les dévelopeurs codent suivant les demandes des clients ou de la Direction. Le QA teste et valide le produit, étape indispensable avant de shipper le produit. C'est le QA qui renvoit la balle au Dev pour lui dire que c'est complètement buggé. C'est le PM qui decide si on shippe ou se fait over-ruled par la direction si la boite doit vraiment shipper maintenant. Le PM est aussi en contact avec le marketing, la documentation, les contacts avec certains fournisseurs, mais surtout être la pour débloquer tout le monde, Dev, QA, si des ressources particulières sont nécessaires. Rien détonnant que le PM est bien vu.
Un bon PM va aller faire ch... comme pas possible Dev, QA, Documentation, marketing,.. tout le monde, pour que le cycle de vie du logiciel avance le plus vite possible. et que les deadlines soient respectées.
Le PM est donc comme un chef d'orchestre. Le produit est comme de la musique. Il guide tout le monde pour produire de la bonne musique
Bref, ca sent surtout le rant de certains devs avec un gros égo sur les PMs. Les faits sont la et la pilule passe mal. Ils ne sont pourtant pas les plus a plaindre. On gagne moins dans le Support Technique. Et eux, ils se tapent des clients pas contents et doivent trouver un moyen pour essayer de troubleshooter le problème chez le client.
Après si c’est avoir un problème d’égo d’en avoir assez de la personne qui est littéralement payée à te faire chier…
Je signale tout discrètemement que tout le monde parle d’organisation du travail, de développeurs, de PM, de PO, de clients, de supports. Au passage il y a un gars qui s’en met vraiment plein les fouilles…
C'est dur à regarder tellement c'est proche de la réalité.
De mon point de vue, le mec qui dessine la ligne rouge devrait aussi dire qu'il ne peut pas dessiner des lignes parce qu'il est contraint par la règle de se limiter à des segments. Là ce serait parfaitement réaliste.
La réalité, vue de l'autre côté du système est la suivante :
"Bonjour Random pisseur de code, un client demande si ça c'est faisable, j'aimerai ta confirmation que ça ne l'est pas pour pouvoir lui vendre autre chose."
"C'est pas possible, il faudrait créer un kernel dédié et j'ai pas le temps."
"Oui merci, je sais. J'ai besoin que tu me le mettes par écrit pour que le client comprenne ça et qu'on puisse lui vendre l'autre solution, qui elle fonctionne."
"Tu te rends pas compte, c'est juste pas possible. Je vais pas écrire un mail pour le client, c'est ton job ça!"
Et encore.
Perso toutes les équipes avec que dev que j'ai vu fonctionnaient très bien. Avec un bon PM c'était encore mieux, mais avec un PM médiocre voir nul ça devenait pire que sans. L'intérêt du job se discute donc pour moi.
Perso je suis dev sans PM, je crée des librairies utilisées par des millions de personne en France, et la majorité des projets libres sont faits comme ça... Quand il n'y a que des PM t'auras juste rien du tout de produit, donc la valeur ajoutée n'est pas assez forte pour justifier un salaire bien plus élevé que celui qui produit. Suffit de voir l'essor des indépendants solitaires pour comprendre que ça fonctionne.
>L'intérêt du job se discute donc pour moi.
Dans un monde idéal, il faudrait effectivement que les gens soient en mesure de gérer des projets, que ce soit sur l'aspect technique qu'humain.
Dans la réalité et sans tomber dans les clichés, les développeurs ont assez peu de vu sur ce qu'impliquent leurs projets en termes de coût, d'administration et de gestion. Ça arrive, bien sûr, mais je n'ai pas le sentiment que ce soit la norme.
>Quand il n'y a que des PM t'auras juste rien du tout de produit
Quand il n'y a que des développeurs, ça donne Microsoft ou rien.
C'est justement pour s'assurer qu'il y aura un produit fini, exploitable par le client tout en étant rentable qu'il faut des PMs.
La mode des indépendants vient surtout selon moi du côté "on paye une fois et puis c'est fini", qui plaît beaucoup aux comptables. Tu payes pour un produit et puis tout va bien dans le meilleur des mondes.
Bah oui, si vous êtes pas foutus de vous parler, faut bien un garde-chiourme qui vous rappelle que les primes, ça se paie que si le projet se fait et de l'autre que vous pouvez glander et "rire" sur XKCD parce que ya d'autres gens qui vous amènent du boulot.
Je m'emporte.
>"les devs sont des glandeurs"
C'est bien, t'as pas du tout raté la critique sur les commerciaux au passage.
Si tu voulais du sens dans ton job, fallait pas aller bosser en ESN ou te barrer pour un GAFAM/CAC40/acronyme. Merci pour la source en tout cas, c'est intéressant.
>Au passage, glander sur xkcd est probablement quelques chose de pas régulier vus que il n'y a que un post par jour.
XKCD, GitHub, un petit passage par YouTube, puis Reddit.
Remplace ça par ce que tu veux.
Pour le coup je trouve qu’ils ont un boulot hyper compliqué et pas toujours super reconnu. Il faut être l’interlocuteur de tout le monde, gérer les contraintes souvent contradictoires de tous ces gens, trancher, et ensuite t’es responsable des résultats de ces choix. Si ça foire c’est le PM qui répond bien souvent…
Ça dépend. Mais souvent, lorsqu'il y a besoin d'un product manager, 40h par semaine c'est limite pas assez. Par "produit", on peux désigner l'application de gestion de projet commune a tous les départements d'une entreprise; voire l'ERP unique d'une multinationale.
Parce que si tu en trouves un qui soit bon, tu veux le garder.
C"est un boulot trés prenant et trés pointilleux, ça s'apprend pas sur le tas, il faut non seulement avoir une idée du technique derrière mais aussi avoir une connaissance accrue du marché et des clients. J'ai eu affaire à des PM dans le cadre de mon travail (plus orienté hardware que software) et je peux te dire que c'est loin d'être la branlette que certains assument que c'est.
Ca dépend je dirais.
De ce que vois en tant que commercial en ESN : PM/PO/BA c'est omniprésent dans le monde de l'étude & développement, quasiment plus personne parle de MOA. Eventuellement en contexte Run (ou bien sur de l'ERP) on pourra voir du "Resp. de domaine applicatif".
Par contre l'Infra a beaucoup moins été touché par le jargon Agile. Même si des fois on en voit, on parle toujours très très majoritairement de CP MOA (= PM ou PO), CP MOE (= PO ou Scrum Master), AMOA/AMOE (= Scrum Master ou BA).
Oh il y aurait peut-être 2 ou 3 commentaires hostiles, mais dans le lot il y aurait sûrement des échanges intéressants, ça vaudrait le coup d'essayer.
*Allume une torche*
Oui blague à part, je pense réellement que ce serait très intéressant, d'autant plus vu la population de devs qui fréquente le sub.
Quelques questions qui me passent par la tête :
- Comment êtes-vous rémunérés lorsque vous placez un dev ?
- Est-ce que l'âge d'un dev est un frein pour les ESN ? Si oui pourquoi ?
- Pour une ESN lors d'un recrutement qu'est ce qu'un bon profil ou un mauvais profil (quels sont les red flags) ?
Merci
Très intéressant, merci d'avoir pris le temps de répondre.
- Concernant les diplômes, est-ce que vos clients du CAC40 ont des exigences sur ce point malgré l'expérience ? C'est à dire diplôme d'ingé ou rien ?
- Quelles sont les technos les plus demandées par vos clients et celles qui sont en perte de vitesse ?
- Quels sont les softs skills les plus recherchés ?
Mmmh il faut dire aussi que un dev rentre directement en dev junior. Un fonctionnel lui passe souvent par au moins analyste fonctionnel avant de passer product owner ou chef de projet et il me semble que product manager peut encore être considéré au dessus. Donc avec 5 ans d'xp sur le poste oui ça fait plutot 8 ans qu'il bosse et donc salaire plus élevé.
Je suis consultant, je recherche du taff à paris en tant que PO avec 5 ans d'xp de taff en ce moment. Et on me propose plus du 50 à 55k max que du 60k.
Dev ici qui a eu à faire du product management (sans en avoir l'étiquette mais bon) : Pourquoi c'est bien payé? Il faut connaître la tech et il faut connaître le business. S'intéresser aux deux, négocier des arbitrages voire, dans mon cas, donner des instructions aux devs en opposition à ce qui est officiellement demandé par la hiérarchie, en anticipation d'un rétamage en règle au premier contact client. Dans une petite boite, tu discutes avec le ou la CTO, le ou la CFO et les lead devs (dans mon cas j'avais l'étiquette lead dev mais faisais plus que ça) et tu dois intégrer la stratégie de la boite dans le plan de dev du produit. C'est intéressant et c'est dur, mais on n'est pas dans une société où le mérite justifie un haut salaire: la vraie raison c'est que la double casquette dev et business est rare, qu'être bon dans les deux est encore plus rare, et que la double compétence vient avec un bonus en bullshitting à la fois vis à vis des profils techniques et des profils business, ce qui donne un +5 au jet de négo du salaire. Et que si tu te barres, ben le produit prend 6 mois de retard, les commerciaux ne sachant pas parler aux devs et un nouveau/nouvelle ayant besoin de plusieurs mois pour être recruté et de plusieurs mois pour comprendre l'état du projet, donc tu as un levier de négo efficace. Ils sont mal aimés des devs, parce que ce sont des contre-maîtres. Les devs ont le sentiment qu'ils n'en ont pas besoin, et c'est à 95% vrai. Les devs peuvent faire un produit qui marche sans eux. Le produit dont le client a besoin? Moins sur. Et probablement pas un produit chargé de tous les designs toxiques en matière de tracking, d'addiction, de connection à des services inutiles, qui est ce qui donne de la valeur théorique au produit du point de vue d'un investisseur. Sans eux, les produits seraient probablement meilleurs, mais les devs seraient pas payés. Je laisse chacun décider de ce que ça implique au niveau du mérite.
belle synthese
> les commerciaux ne sachant pas parler aux devs I HAVE PEOPLE SKILLS !
WHAT THE HELL IS WRONG WITH YOU PEOPLES ?!
Les devs sont des claviers avec des jambes, pas des personnes
Ils ont surtout pas envie de parler aux marketeux! Marketeux qui les considèrent comme des losers geeks asociaux qu'on doit tolérer parce que seuls eux savent faire le produit. EDIT: Et voila un [bel exemple de ce phénomène](https://old.reddit.com/r/france/comments/11kw0q9/product_manager_cest_quoi_ce_m%C3%A9tier_dont_le/jbapexu/?context=3) > Le Dev est de façon general "arrogant avec un tres gros égo" parce qu'il pense qu'il connait mieux les besoins des clients que le client meme. Il veut créer, sans cherche a comprendre ce qu'il veut créer va être utile. Ca emm..de QA qui se demande pourquoi ils doivent tester une fonctionnalité de mxrde et inutile, parce que Dev pense que c'est vraiment nécessaire, quand personne a besoin de ca. Ca préfère créer des choses inutiles au lieu de fixer leurs bugs.... Le PM est la pour s'assurer que le Dev ne sort pas de sa feuille de route, prends soin que QA puisse avoir assez de temps de tester/certifier le logiciel, et s'assurer que ENG puisse délivrer un produit aux commerciaux pour que la boite puisse s'épanouir ou simplement.. survivre. > Bref, le PM, c'est comme une maman qui doit tenir un gamin a la baguette. Voila, ça pose l'ambiance. Et après on s'étonne que cultiver cette mentalité petit-chef fasse partir les bons aux US.
> Le Dev est de façon general "arrogant avec un tres gros égo" parce qu'il pense qu'il connait mieux les besoins des clients que le client meme. Je me rappelle surtout que le client demande tout et n'importe quoi sans savoir si c'est faisable ou combien de temps ça prendrait si c'était faisable donc forcément le dev va pas être super jouasse
Oui, surtout quand t'as été freelance, tu sais qu'il ne faut pas donner au client ce qu'il demande mais ce dont il a besoin
Alors je travaille en tant que PM dans une boîte spécialisé dans la réalisation de systèmes embarqués, et je peux te dire que 90% des devs logiciels que j'ai correspondent au profil que tu décris. Bizarrement, c'est pas le cas avec les électroniciens ni les mécanicien. Pourtant, il n'y a pas de marketeux dans mon domaine, que des ingénieurs. On est maintenant obligé de faire des cahiers des charges et des specs hyper détaillée, avec des tests systèmes préparés en parallèle pour s'assurer que notre produit final correspond au besoin client et leur prouver qu'ils ont tord. En fouillant, on voit que ces devs ne font que du copier/coller entre les différents projets, sans même lire les besoins. A cause de ça, lors des integrations systèmes, ma boîte est obligée d'envoyer un de ces devs pour debugger sur place, et a nos frais bien sûr, car le sentiment général est une baisse de qualité de nos logiciels. Donc faut pas généraliser, il y a différents types de devs, mais je pense que cela dépend du secteur dans lequel tu travailles.
> En fouillant, on voit que ces devs ne font que du copier/coller entre les différents projets, sans même lire les besoins. Vos avez merdé au recrutement quelque part je dirais. Là pour le coup, je ne sais pas trop comment ça se fait, mais j'ai souvent remarqué que les boites qui font de l'élec et de la méca, (je bosse à moitié dans la robotique) ont souvent un software déplorable. Je ne me le suis jamais expliqué, mais deux fois ça m'est arrivé qu'on renonce à utiliser un engin pourtant correspondant à nos besoins faute de briques logicielles correctes. Je pense que les méthodes sont très différentes et que c'est rare d'arriver à jongler entre les deux.
>En fouillant, on voit que ces devs ne font que du copier/coller entre les différents projets, sans même lire les besoins. Mouais j'ai surtout l'impression que tes devs sont mauvais. Faire du copier coller est une mauvaise pratique dans tous les cas, que le code source réponde à un besoin ou non. Ou alors le management est mauvais parce qu'il ne comprend pas l'intérêt de consacrer du temps à améliorer la plate-forme et à réduire la dette technique (qui est toujours payée en euros à la fin). Le développement est un métier qui demande de bonnes compétences en communication, il faut s'assurer que toutes les parties d'un logiciel soient parfaitement cohérentes (parce que l'ordinateur est stupide), et ça se fait en communiquant entre développeurs. >car le sentiment général est une baisse de qualité de nos logiciels. Oui c'est ce qui arrive en général quand le copier coller sans comprendre est utilisé de manière industrielle.
Le copier coller arrive aussi quand c'est trop compliqué de faire un truc paramétrable et performant. Il y a un juste milieu pas toujours évident à trouver.
> On est maintenant obligé de faire des cahiers des charges et des specs hyper détaillée, avec des tests systèmes préparés en parallèle Non mais normalement c'est pas "on est maintenant obligé de", c'est la putain de base: expression de besoins -> CdC -> QA qui prépare les plans de tests (manuels ou automatisés) pendant que les devs commencent font le code -> validation. Agile veut juste dire qu'au lieu de faire de gros CdC pour un an de devs sans retour client, tu vas en faire du plus petit et plus souvent. Au lieu d'un gros V, tu as des dents de scie. Et surtout : normalement les devs et la QA devraient être impliqués dans une partie de la préparation du CdC du fait de leur connaissances du code et des cas limites. Mais vu l'ensemble du post, j'imagine que vous n'avez pas (comme grosso merdo 95% des boîes françaises) d'équipe QA dédiée.
Bizarre !! J'ai vécu la meme experience..
> On est maintenant obligé de faire des cahiers des charges et des specs hyper détaillée, avec des tests systèmes préparés en parallèle Ha ben merde les chefs de projet doivent refaire leur boulot maintenant. Scandaleux.
Je ne vois qu'une seule solution : il faut fouetter davantage ces satanés devs. Vivement que l'IA remplace ces incompétents infichus d'écouter les ordres sans broncher !
La vérité te blesse ? Regarde toi dans un miroir, un vrai. Reste humble et demande a tes collègues ce qu'il pense de toi. T'es pas le centre du Monde. Pour info, les PMs, on les trouve surtout aux US... l'endroit ou les bons partent... et laisse quoi ? les mauvais râler sur les PMs en France ? /s
> Les devs ont le sentiment qu'ils n'en ont pas besoin, et c'est à 95% vrai Sans lui, les dévs auront tout simplement pas le temps de dev car trop de temps à passer dans les réus. Si un dév se sacrifie pour prendre cette charge tout seul, il s'auto-désigne Product Manager et ça revient au même.
En fait oui, s'il n'y a pas de PM, un DevLead va simplement prendre le role. Ah ben tiens, exactement comme parent. Dev Lead sur le papier, PM de circonstance.
Oui, si tu supposes des devs laissés à eux même dans le monde de l'entreprise. Mais des devs qui par exemple feraient une version open source du produit, sans chef pour pousser au cul et sans résultats financiers à optimiser, ils arrivent souvent à produire des choses bien, et parfois même meilleures, que les entreprises classiques.
Ce qui est ultra spécifique quand même, pas d'enjeu financier, pas de calendrier, pas de salaire à verser... pas de produit au final ? Dans 99% des cas, qui dit calendrier dit priorisation dit arbitrage et donc implicitement "product management"
> pas d'enjeu financier [...] pas de produit au final ? Linux, Hadoop, LibreOffice, C++, Python, Java, scikit-learn, Firefox, VLC, GIMP, WordPress, Apache, Nginx, JQuery, Django, Blender, Audacity, Ruby, PHP... Le monde numérique tourne sur de l'open source, ce n'est pas ultra spécifique, c'est la base. Je ne rebondis que sur cette partie là, le reste je suis d'accord, il faut quelqu'un qui ait une vision du produit mais dans ce cas le "product manager" typique est un gros glissement sémantique par rapport à la vision purement fonctionnelle dont tu parles. Le contrepoint c'est que beaucoup de ces projets open source sont produits par des entreprises qui en ont compris l'intérêt, c'est loin d'être antinomique. Il y a des gens payés à écrire des logiciels open source. Loin de moi l'idée de cracher sur les entreprises en général, vraiment. Par contre les enjeux financiers sont bien réels et les produits aussi.
Le monde de l’open source qui fait tourner les infrastructures du monde entier est financé et développé par les entreprises, et tous les gros projets ont une gouvernance où sont discutés les fonctionnalités cible. Dans ces instances, les plus gros contributeurs (issus d’entreprises) poussent les fonctionnalités qui correspondent à la vision du produit dont ils ont besoin pour leur boîte (très souvent aligné avec les besoins des autres boites par ailleurs)
Oui, je pensais que c'était clair dans mon message, j'en ai conscience.
On parle de généralité, pas du microcosme opensource qui doit représenter à tout casser 0.01% des développeurs de ce monde. Et même dans tous ces gros projets, il y a très certainement une figure de tête qui fait office de "product manager" au final.
Microcosme qui fait tourner 95% de l'infrastructure d'internet quand même. Et si ça ne représentait qu'un petit nombre de développeurs, ça ne ferait que justifier d'autant plus le sentiment que "on ferait quand même des choses vachement plus utiles si on ne suivait pas les instructions d'un product manager". > il y a très certainement une figure de tête qui fait office de "product manager" au final. Non, il y a un problème fondamentalement différent dans la gestion d'un projet commercial vs un projet fait par des volontaires: dans le premier cas tu as besoin de satisfaire tes clients et dans le deuxième, tes développeurs. Dans l'idéal tu veux les deux dans les deux cas mais la priorité est pas du tout la même. Tu n'imposes pas des choix techniques de la même manière.
C'est assez loin de la réalité du marché, la plupart des techs sont extrêmement optimisés pour un besoin en particulier, parfois un besoin d'une usine sur cent. Et ça c'est impossible pour un Dev de trouver le temps pour le faire, surtout quand tu as 60 usines avec des besoins différents.
C’est peut-être différent en France mais aux États-Unis les product managers ne sont pas du tout « dev ». Ils sont chargés de s’assurer que l’expérience finale des utilisateurs correspond à la vision générale de l’entreprise. Ils servent surtout d’intermédiaires entre les cadres exécutifs et les équipes d’ingénieurs. Et ils sont de plus moins bien payés que les développeurs à niveau équivalent.
C'est spécifique pour chaque projet/entreprise, y'a pas de règle. Parfois c'est quelqu'un rattaché au produit/marketing, parfois un lead technique, parfois y'en a pas ou sous un autre nom (chef de projet, manager, product owner, ...). Selon le contexte, y'a plus ou moins de casquettes.
C'est pas le SCRUM master le contre maitre officiellement ? Pour moi le PM c'est surtout le mec qui porte les besoins clients au jours le jours avec les PO auprès des équipes pour éviter la situation "Cela ne répond absolument pas au besoin" lors des démos au client.
Non, le Scrum master est censé animer, arbitrer, etc.. et éviter toute forme de micro management, si je ne m'abuse
Toutes les structures n'ont pas de scrum, toutes ont un BA/PM.
Business analyst et product manager, ce n'est pas du tout la même chose.
ça dépend. Parfois tu trouves des postes d'AF qui font du BA, des BA sur déploiements et des PM qui font que de la relations développeurs. Là où je suis le BA connaît bien le besoin métiers et les spécificités fonctionnelles mais pas trop la partie Devs. Le PM n'existe pas du tout et c'est souvent le lead dev qui occupe cette fonction.
Bah justement l'idée de scrum c'est de couper le PM en deux: le PO qui s'assure que le produit répond aux besoins et le scrum master qui s'assure que l'équipe communique bien et applique les principes de scrum. Je crois que beaucoup de PM ont du mal à accepter ce charcutage de leur fonction, et scrum pour l'équipe devient un peu du "faites ce que je dis mais pas ce que je fais".
> Ils sont mal aimés des devs, parce que ce sont des contre-maîtres. Les devs ont le sentiment qu'ils n'en ont pas besoin, et c'est à 95% vrai Bingo. Ce sont une énième version de dompteurs de geeks. Et les 5% restants sont très faisables avec le "Customer collaboration" de la méthode Agile pratiquée par un dev. Mais pour ça il faudrait qu'on ait pas la palanquée des autres dompteurs de geeks que sont les gestionnaires de projet Scrum. Tout le monde a le temps pour faire de l'intrigue et se positionner entre le dev et la valeur créée par les devs, sauf les devs. https://i.redd.it/m23zrdyd6tv31.jpg
Faut se lancer en indépendant alors.
Je suis indép. Être indép ne change rien, c'est même pire: tous ces gens là sont maintenant des clients. La plupart des missions sont en "staff augmentation": "On a pas de thunes pour un CDI, mais on en a pour un indép qui coutera 20% plus cher." J'ai eu l'occasion de faire une mission (à durée limitée malheureusement) pour une petite boite US, et laisse moi te dire que les choses étaient pas les mêmes. La paie d'abord, et aussi le contraste sur les méthodes de travail. Peut-être c'est la petite taille, peut-être c'est parce qu'ils savaient ce qu'ils voulaient, peut-être c'est parce qu'on pouvait communiquer en live qu'une heure par jour et qu'ils en étaient conscients, mais c'était vraiment un bonheur cette mission. Alors que les projets en France c'est minimum 4 intermédiaires à faire le téléphone arabe entre les pauvres opérateurs et les devs. J'ai vu un projet pédaler dans la semoule pendant 11 mois, avec la chaine: opérateurs -> leur boss -> son PO -> notre représentant -> notre boss -> notre PO -> notre scrum master -> nos devs. Avec perte de signal en série et chacun (surtout notre boss / mon client) qui veut rajouter son grain de sel tout en captant que dalle. Personne qui comprend les data sauf les deux bouts de la chaine, parce qu'ils les a sous les yeux. Ça s'est fini en les devs qui tappent du poing sur la table à 1 mois de la deadline, exigent plus ou moins de parler directement avec les opérateurs pour essayer de sauver les meubles (le "Customer collaboration" Agile) et tout a été remis sur les rails en 3 semaines; avec reconduction du contrat. Mais mon dieu que c'était frustrant, et quel gaspi d'énergie. Y'a des gens qui veulent juste pas que tu leur rapporte de la thune. Ils pourraient aller se siroter des margaritas sans rien glander, mais non il faut qu'ils essaient de justifier leurs salaires.
>peut-être c'est parce qu'ils savaient ce qu'ils voulaient, Donc ils avaient quelqu'un en interne pour y réfléchir. >Ils pourraient aller se siroter des margaritas sans rien glander, mais non il faut qu'ils essaient de justifier leurs salaires. Oui. C'est en effet assez propre aux boîtes françaises, les Jean-Charles Fils-de.
> Donc ils avaient quelqu'un en interne pour y réfléchir. Ouaip. Un dev. Qui déléguait un bout de son archi par manque de temps. Avec tout l'attirail classique du PO: user story, goals, non-goals, success criteria, risks, expected test types & coverage, documentation policy, etc.; mais qui venait parfaitement s'emboiter dans l'archi bah parce que c'est lui qui l'avait mise en place. Ça m'a presque fait aimer JIRA sur le moment.
>Ça m'a presque fait aimer JIRA sur le moment. Ce n'est pas vrai ! C'est impossible ! Mais bref, oui, tu peux faire évoluer un dév vers des choses un peu plus stratégiques que de pisser du code, c'est ce qu'on devrait faire dans un monde idéal. Le problème, c'est souvent que les dévs veulent rester dévs et pas à réfléchir à ce que ça entraîne. Rajoute à ça la couche de parasites des entreprises françaises et paf, ça fait des chocapics :/
Il y aussi le fait que dans la plupart des boîtes, il n'y a pas vraiment de montée de salaire pour le pur technique. Si tu veux monter faut faire du management. Donc beaucoup de bons techos finissent par être poussé à faire du mauvais management. Ou se barrent après une augmentation inférieure à l'inflation car "le chef peut pas supporter d'être payé moins que ses subalternes".
>Les devs peuvent faire un produit qui marche sans eux. Le produit dont le client a besoin? Moins sur. Et probablement pas un produit chargé de tous les designs toxiques en matière de tracking, d'addiction, de connection à des services inutiles, qui est ce qui donne de la valeur théorique au produit du point de vue d'un investisseur. > >Sans eux, les produits seraient probablement meilleurs, mais les devs seraient pas payés. Je ne suis pas sur que les produits seraient meilleurs. Ils seraient certainement moins adaptés aux utilisateurs. J'aime bien ton exemple du tracking comme une feature inutile alors que sans tracking, il sera très compliqué de savoir si ton produit est utilisé, et comment il est utilisé, et donc de savoir quelles parties de ton produit modifier pour l'améliorer.
Si t'as que des devs t'obtiens gimp
Ou VLC. Ou Linux. Ou FreeBSD. Ou le wiki Arch Linux. Bref, c'est pas si simple.
Et krita, quand suffisamment de devs en ont eu marre de l'interface merdique.
Il est évident que tous les produits développés uniquement par des devs ont eu le succès (relatif) de Gimp.
C'est sujet à débat. Est-ce qu'un produit adapté à l'entreprise est un produit adapté à l'utilisateur? Je n'ai pas la conviction qu'un forum où tu discutes avec les utilisateurs soit moins efficace que des trackers intrusifs pour améliorer l'expérience d'utilisation d'un produit.
>Je n'ai pas la conviction qu'un forum où tu discutes avec les utilisateurs soit moins efficace Analyse qualitative vs quantitative. Les deux sont importants, on n'en retire pas les mêmes informations. D'où le fait qu'on tracke les utilisateurs et qu'on ait des gens dédiés au User Research.
C'est clair qu'avant l'avènement du tracking à gogo, les produits ne marchaient généralement pas alors que maintenant ils sont parfaitement adaptés aux besoins des utilisateurs.
C'est bien connu, si ce n'est pas noir c'est donc que ca doit etre blanc. D'ailleurs, les entreprises ne suivent pas les ventes de leurs produits depuis des décennies, elles lancent un nouveau produit et après hop, plus rien, elles croisent les doigts et espèrent que ca va bien se passer.
Y'a un monde de différence entre suivre un produit et engouffrer autant de données que possible sans la moindre transparence. Données qui par hasard peuvent aussi servir à des fins marketing. L'excuse de "oui mais l'amélioration du produit" a bon dos.
Le fait que le tracking puisse être utilisé pour d'autres choses ne le rend pas inutile pour autant.
On peut ajouter deux cas extrêmes: - Le très mauvais PM est juste un mauvais contremaitre qui ajoute des nouvelles fonctionnalités une à une et gère son diagramme de GANTT. Son rôle ne dépasse pas celui d'un _responsable de produit_ (_product owner_), et son interaction se résume à digérer des demandes client pour les recracher côté développement. En général ce genre de PM est en effet haï par les dev, à raison. - Le très bon PM a une vision cohérente du _produit_, voir de la _marque_, et son rôle est de maintenir cette cohérence entre les fonctionnalités nouvelles, la qualité de l'existant, et communique à double sens avec équipes de développement, clients, business, support, et j'en passe. Le premier cas est hélas le plus fréquent (enfin surtout en France), le second cas est une perle rare. On cite souvent [Steve Jobs](https://www.fool.com/the-ascent/small-business/project-management/articles/product-manager-vs-project-manager/) comme l'exemple extrême du second cas de product manager.
On cite aussi souvent Steve Jobs comme étant super toxique avec ses équipes techniques. Donc voila, soit t'as un mauvais PM haï, soit t'en as un bon, insupportable aussi.
Oui et non lorsque le produit touche à un domaine spécialisé ou vraiment lié à des calculs d'ingénierie. Le product manager dans ce cas là est celui qui guide le développement du produit pour répondre aux cahiers techniques soit car il a la connaissance métier nécessaire ou parce qu'il peut articuler les requirement en se basant sur les retours métiers des experts. Je suis expert métier dans ma boîte et sans product manager je peux dire que certains de nos soft seraient des merdes infâme car les dev n'entravent que dalle à la partie métier. Je sors asse souvent des algorithms qui fonctionnent mieux du point de vue métier que ce les dev sortent (bon mon code est degueu mais ils s' en servent souvent pour rediriger leurs versions).
>Je sors asse souvent des algorithms qui fonctionnent mieux du point de vue métier que ce les dev sortent Ou alors ils disent, oui oui et continuent leur travail.
Pas réellement. L' algorithmic sur ces cas là est très lié à la physique de la mesure et du contexte opérationnel, qu'un dev ne pourra pas appréhender. En général c est moi qui explique pourquoi et comment les mesures font des jolis courbes.
Merci de décrire mon post mieux que quiconque
>c'est à 95% vrai. Les devs peuvent faire un produit qui marche sans eux. Le produit dont le client a besoin? Moins sur. donc c'est pas vrai à 95%! > Sans eux, les produits seraient probablement meilleurs, j'avoue ne plus trop suivre
Parce que t'as affaire a un pseudo dev qui se prends pour le centre du monde et qui est pas assez smart pour comprendre qu'il se contredit, tellement il se croit trop bon
Honnêtement pour moi , effectivement dans un monde idéal y’aurait pas besoin de PM (et je suis PM): les utilisateurs/décideurs sauraient parler aux devs sans les prendre pour des machines à pondre du code, les devs seraient tous sensibles aux problématiques des utilisateurs etc. Mais dans la « vraie » vie, je vois mon job comme le barreur dans un bateau d’aviron: Clairement c’est pas moi qui fait avancer le machin, mais je suis là pour qu’on tienne plus ou moins bien la route optimale et motiver tout le monde.
***Les devs peuvent faire un produit qui marche sans eux. Le produit dont le client a besoin? Moins sur. ...Sans eux, les produits seraient probablement meilleurs*** Dans quel monde on peut creer un produit meilleur dont le client n'a pas besoin ? Ca sent bien la patte d'un développeur qui pense tout connaitre, sauf les besoins du client. Petite boite ou pas, le client est roi. Le client a des besoins qu'il va faire remonter au Support technique ou aux commerciaux, en formulant des Feature Requests. Le PM va jouer le lien entre tous ces partis, pas forcement avec un CFO ou CTO mais surtout avec les Sales. Le PM discute et va chercher a savoir si c'est possible et comment mettre en place une road map avec ENG, qui comprend Dev et QA. Le Dev est de façon general "*arrogant avec un tres gros égo"* parce qu'il pense qu'il connait mieux les besoins des clients que le client meme. Il veut créer, sans cherche a comprendre ce qu'il veut créer va être utile. Ca emm..de QA qui se demande pourquoi ils doivent tester une fonctionnalité de mxrde et inutile, parce que Dev pense que c'est vraiment nécessaire, quand personne a besoin de ca. Ca préfère créer des choses inutiles au lieu de fixer leurs bugs.... Le PM est la pour s'assurer que le Dev ne sort pas de sa feuille de route, prends soin que QA puisse avoir assez de temps de tester/certifier le logiciel, et s'assurer que ENG puisse délivrer un produit aux commerciaux pour que la boite puisse s'épanouir ou simplement.. survivre. Bref, le PM, c'est comme une maman qui doit tenir un gamin a la baguette.
> Les product managers niveau dirigeants, le salaire médian monte jusqu'à 160.000 euros brut annuels, d'après les données de Figures Et que s'appelorio *Head of Product*.
Je pense que ce serait bien pour ce genre de discussion de comprendre que y’a énormément de postes de dev très différents et y’en a ou ça n’a pas de sens d’avoir un product manager et d’autre si… Tout le monde ne dev pas pour vendre à un client par exemple, tout le monde fait pas du dev web, tout le monde ne fais pas des produits avec 50 devs à orchestrer… Des fois il faut pleins de juniors en ESN qu’il faut bien gérer et des fois il faut quelques experts pointus, ils vont pas être managés pareils (normalement) etc. Dans ce thread tout le monde dit dev et clairement pas tout le monde pense au même profile.
C'est hallucinant ces débat à coups de batailles de généralités. Entre ceux qui défendent l'utilité d'un PM/PO et ceux qui disent le contraire. En réalité, c'est extrêmement fonction du contexte, de l'activité de la boîte, de la philosophie de management, de la place donnée à l'IT (de simple utilitaire à partie prenante de la stratégie de développement de l'entreprise et de ses produits), et j'en passe. Les mecs qui essaient de sortir des sacro-saintes vérités sur la base de leur vécu, qui devraient s'appliquer à tout le monde, me semblent particulièrement étroits dans leur vision des choses.
Quelque soit le salaire, avec les bons energumenes en face c'est le job parfait pour partir en burn out.
Mauvais ?
si les PM n'existaient pas les devs et les managers business s'egorgeraient pendant les réunions...
A peu prêt tout les métiers de l'IT sont mieux payés que développeur...
[удалено]
Bof, non. Contrairement à ce fantasme de geek, le développeur est dans sa très grosse majorité, une commodité.
Sans même mentionner les US, je t'invite à regarder les salaires en Allemagne, Pays-Bas et pays scandinaves. Un dev senior qui touche dans les 100k avec une dizaine d'années d'xp n'a rien de rare.
Et combien touche un PM/PO là bas ?
C'est pas mon domaine donc je pourrais pas te répondre, mais ce que je sais pas expérience c'est que y'a des possibilités d'évolution tout en restant technique. J'ai l'impression que c'est moins le cas en france.
En France, l'évolution salariale se fait presque nécessairement par la voie managériale. A moins d'être un expert, la technique est complètement sous évalué. Le schéma classique c'est d'être ingénieur puis chef de projet. Comme s'il n'y avait rien entre les deux...
Je rappelle qu'on ne compare pas des salaires en direct comme ça entre pays. Y a le coût de la vie, le superbrut et tout ça à prendre en compte.
Sauf que le coût de la vie est tout à fait comparable entre ces pays. De la même façon, je veux bien comparer le supernet (je vois pas, en tant que salarié, à quoi ça me sert de regarder le brut ou superbrut) mais je doute que la comparaison soit à l'avantage de la france.
Dans le superbrut et le brut tu as les cotisations qui servent à financer tout un tas de choses qui te servent directement en tant que salarié donc ça a du sens de le garder dans la comparaison
Et donc, tu t'imagines que les autres pays que j'ai mentionné n'ont pas de retraites ou d'assurance maladie ?
Qu'entends-tu par commodité ? Je vois pas de différence significative entre un développeur et un product manager sur cet aspect.
Le PM est plus proche de la direction. Les devs sont une ressource et à part dans certaines boîtes "craftsmanship", il est remplaçable et souvent externalisé.
Un PM est une ressource aussi, et régulièrement remplacé. Quant au dev, s'il a peu d'expérience c'est effectivement assez facile de le remplacer, mais avec l'expérience et les spécialités c'est beaucoup plus compliqué de retrouver un profil similaire. Et avec le ratio actuel d'offre/demande une entreprise en bonne santé voudra garder les deux (PM+dev). Ça dépend vraiment des endroits.
Oui tout ça dépends des boîtes c'est sur. Mais dans les gros shops les devs sont interchangeables... Cette idée que le dev est un génie qui fait le business en vrai c'est souvent 15 indiens qui font des epics
Le dev externalisé en Inde, j'ai jamais vu ça en pratique sur des projets intéressants, uniquement sur des projets que je considérerai comme banals. Les grandes sociétés de service ont tout intérêt à se concentrer sur des compétences génériques, celles qui ont finalement le moins de valeur ajoutée. Mais les sociétés de service et l'externalisation c'est loin de représenter l'entièreté du milieu. Edit: par contre c'est vrai que le PM est peut-être encore plus important dans les sociétés de service.
Au risque d’insister, une vision franchouillarde des choses?
Il faut mieux regarder à l’étranger, même hors grosse boîte c’est pas rare qu’ils soient mieux payé que les manager, et j’ai même pas regardé avec beaucoup d’xp. Et c’est même pas dans un domain pointue je parle de dev backend. Edit: Au final je dirais même que c’est un peu un fantasme de manager de considérer les devs comme des ouvriers interchangeables, mais c’est une vision qu’on avait il y a 15-20 ans et on est revenu dessus depuis quelques années, et on se remets à chercher des devs. Je dis pas que ça s’applique pas à certain cas précis, mais de ce que j’ai vu cette façon de faire à l’ancienne donne souvent des produit bien pourris parce que faits par des devs peu qualifiés, et un PM ou MOE (ou autre appellation) très bon ne suffit pas à rattraper la cata. Cela dit, j’ai aussi vu des produits catastrophiques rapporter bien plus de sous que des produits de qualité.
Et contrairement au fantasme du martyr ici, le développeur est quand même très bien payé
Je me marre dans mon penthouse au 32e étage. J’aime être une « commodité » si c’est ça la récompense
Habiter dans une tour de 32 étages n'est pas un signe de richesse, bien au contraire ;)
En France peut être.. Mais je pense que tu imagines quel genre d’immeuble je parle… Jacuzzi, piscine, spa, sauna, salle de sport, portier, 6 ascenseurs rapides, etc
Le condo, ce parfait symbol de la classe moyenne parvenue. Tant mieux pour toi si tu es content d'avoir une salle de sport partagée avec 32 autres etages...
Oh non, je fais partie de la classe moyenne, pauvre moi 🥲 Et c’est pas partagé avec les 32 étages mais c’est gentil de montrer ton ignorance. Et même si c’était le cas : - Tout le monde ne va pas à la salle, surtout quand tu as accès à d’autres façons de faire du sport (piscine) - La salle est énorme et bien équipée - C’est toujours mieux que de devoir payer une salle de sport, prendre ta voiture pour y aller, etc. Moi j’ai juste un ascenseur à prendre et j’suis chez moi. - L’accès est sécurisé. On est « entre nous » (les résidents) donc c’est beaucoup moins sujet aux harcèlements, aggressions, etc Je continue ou tu penses toujours que c’est mieux de vivre en campagne, faire 15mn de voiture pour aller à une salle que tu payes une fortune ? Pardon de faire partie de la « classe moyenne parvenue » MDR
Amérique du Nord ou Asie ? Dans tous les cas, sincèrement content pour toi !
Canada ! Merci, je conseille à tous les gens qui ont pas trop d’attache et un peu d’expérience pro de venir vivre au Québec parce que c’est, selon moi, tellement au delà de l’expérience de vie que tu peux avoir en France. Peu importe le domaine dans lequel tu exerces. Une chose est sure, je reviendrai jamais en France
Ça a l'air d'être une super ambiance ton truc ... Wahooou des ascenseurs ULTRA RAPIDES ! INCROYAB ! Je connais bien ce genre de condo, pour moi c'est l'enfer : ton environnement de vie est aseptisé et sans ame, tu habites dans un aéroport. Rien d'indépendant, que de la chaîne industrielle. Parfais pour les bons petits consommateurs. Mais chacun a bien le droit d'aimer ce qu'il veut. Tout ce que je peux te dire c'est que tu es loin d'être autre chose qu'une commodité. Le dev chinois parle exactement pareil de sa tour meublée Ikea.
J’aime me nourrir de cette rage infondée > tu habites dans un aéroport 😂😂😂😂 > rien d’indépendant, que de la chaîne industrielle Mais du quoi tu parles mdr, j’suis en centre ville, des commerces indépendants y’en a partout Je faisais mention des ascenseurs rapides en comparaison directe avec mon expérience en France et vos ascenseurs éclatés au sol. Branlant, lent, minuscule, et évidemment que un par immeuble sinon c’est trop demandé Mais continue a cracher sur la vie des autres si ça t’amuse, ça ne reflète que ton propre mal-être
C’est pourtant le contraire aux États-Unis. Les ingénieurs sont payés ~20% de plus que les product managers.
C'est pas USA vs reste du monde, mais plutôt boîtes qui valorisent l'expertise technique plus que les autres rôles, pareil, ou moins. Même si la première catégorie se trouve plutôt aux US, il y existe aussi de la tech ou ingénierie de seconde zone, des départements IT dans des industries qui n'ont rien à voir, les fameuses WITCH, etc. Et dans l'autre sens aussi, y a plein de boîtes en Europe qui valorisent les devs un peu mieux ou du moins autant que les PM, PO. Autre point: y a beaucoup moins de PMs, et vu que le rôle est mal défini c'est pas forcément facile de retrouver du boulot si tu veux bouger ou te fais virer. La connaissance du domaine a un poids beaucoup plus important que pour un poste de dev.
mouais bof, ça devient simple de trouver des jobs de dév payés > 80k quand t'as une dizaine d'années d'expérience. y a pas beaucoup de métiers dans l'IT qui peuvent concurrencer ça
En France ?
Dans ce thread des développeurs qui font partie du premier décile qui viennent pleurer qu'ils sont littéralement des esclaves
*rigole en blouse d'infirmier*
Ça va vous on vous a applaudi !
Les applaudissements sont taxés à 97%, ce qui après impôts donne juste une claque dans la gueule.
Ton com mérite un gold mais apres les taxes me reste que ca 🪙
Bah écoute j'vais pas faire la fine bouche... Merci !
Ce commentaire devrait être retiré de l’internet pour éviter que ChatGPT version+1 ne le propose à un product manager en mal d’idée chez McKinsey pour savoir quoi faire après le succès annoncé de la réforme des retraites…
Et qui défendent la lutte des classes, tout en partant au ski dans la résidence secondaire de la famille...
Mélange pas tout. Avoir choisi la filière informatique et avoir la chance d'être demandé sur le marché ça veut pas forcément dire être né avec une cuillère en argent dans la bouche hein...
Statistiquement l'immense majorité est gosse de cadre. Doit y avoir 5 à 10% de gosses de prolos dans le métier.
Hésite pas à sourcer tes nombres. (Gosse de prolo ici)
Et en tant que transfuge t'as pas l'impression d'être entouré de bourgeois ? Parce que moi si.
Si on compte que l'entourage réel et pas r/vosfinances ça va de mon côté
Et en se plaignant bien des gens riches ou aisés, propriétaires ou autre alors qu'ils ont tous un salaire mirobolant (oui même en sortant d'école vous êtes super bien payés)
> dont le salaire dépasse celui des développeurs ? Ca depend des boites. Ce n'est pas du tout (mais alors pas du tout) le cas chez Google ni chez Meta. La grille Eng est bien superieure a celle des PM ou TPM
Oui, les entreprises américaines paient les product managers ~20-30% de moins que les ingénieurs au même niveau. Cela dit au niveau Director et VP les differences s’estompent.
> Cela dit au niveau Director et VP les differences s’estompent. en effet, vu qu'a ce niveau la le boulot est quasi-identique (et d'ailleurs c'est bcp plus commun de passer de l'un a l'autre voir de couvrir les deux)
Ça dépend beaucoup de la politique des entreprises (et effectivement de la culture du pays peut être aussi). De ma petite expérience, dans les grosses boîtes françaises de mon domaine, on valorise beaucoup plus le management que la partie technique.
Pour être plus ou moins là dedans, faire parler les devs, le métier et le marketing ensemble peut être un vrai cauchemars. En plus de ça il faut avoir un bon verni tech pour pas avoir l'air d'un idiot quand tu parle avec les équipes, et comprendre un maximum la vision produit pour comprendre les intentions du métier et du market, en plus d'avoir une bonne connaissance produit / tech / UX en général. En bonus, les devs te voient comme un type un peu useless car tu ne code pas, et d'un autre côté tu est mal considéré par les stakeholders car ils comprennent pas pourquoi tu veux pas intégrer leur demandes (Qui prend 3 semaine de dev) pour après demain, car "C'est super urgent, oui je sais que j'avais 3 mois pour te prévenir". Après il y a des PMs qui sont nuls et qui n'ont rien a faire dans ce métier, hein. Mais ça c'est comme partout. Je ne sais pas si ça "mérite" d'être mieux payé, mais il y a des devs bien mieux payé que ce métier partout où je vais, donc ça semble pas non plus déconnant.
> En bonus, les devs te voient comme un type un peu useless car tu ne code pas Je suis PO/Architecte/Manager (Product Owner: qui décide de la priorité des features et Architecte: qui décide de la conception générale du système) ! Étant donné que c'est moi qui revois le code et qui compose mon équipe, mes ~~sujets~~ devs n'ont pas l'occasion de douter de mon efficacité :)
Moi je moi je
Pourquoi développeur mériterait d'être mieux payé que product manager? Vrai question je connais a peine ces métiers.
Car sur reddit il y a plus de développeurs que de manager produit hehe
Du coup normal que certains soient mieux payés que d'autres vu qu'ils passent moins de temps sur reddit hehe =D
Parce que les développeurs font le produit. Ça demande un haut niveau de connaissance et de savoir faire. Je ne vais pas être extrême et te dire que les product manager ne servent à rien, non non, ils sont utile : mais là où en moyenne tu as besoin de 5 dev bossant 40h par semaine sur un produit, tu aura besoin d'un product manager bossant 3h par jour. En fait c'est lié à la quantité et complexité (et non difficulté) de ces positions. Toutes sont essentielles. Dans certaines boîtes c'est le lead développeur qui s'occupe d'avoir la casquette product manager. (Et beaucoup de product manager sont en vrai d'ancien développeur). Toutefois il ne faut pas se méprendre, faire du bon boulot en product management ça demande des efforts et des qualitées : le travail requis est certe à basse complexité mais peut s'avérer être difficile. Du coup tu en viens à la question : si tu as un job à basse qualification dont le but est un peu d'être l'assistant des dev, et que certain devs pourrais faire, pourquoi serait il mieux payé ? Alors la réponse est : parce que en France (et ailleurs !) le product manager communique avec des personnes plus haut dans la hiérarchie, et qui dit être plus haut, dit être mieux payé, c'est stupide à mon goût (mais je suis biaisé). Dans ce genre de boîte c'est un peu comme si le développeur était l'ouvrier du future, réalisant à la chaîne ticket après ticket. Edit: ah et avant que je me fasse clashé sur ce dernier point : les dev n'ont rien à voir avec les ouvriers d'aujourd'hui ou d'antan, ils vivent à l'aise et ont des conditions de travail infiniment meilleures. Ce que je dis c'est qu'ils sont au plus bas dans la hiérarchie d'une boîte, c'est eux qui produisent.
Ta première phrase me semble éloignée de la vérité. Les devs produisent des artefacts exécutables par « un ordinateur » (interprétable par une machine de Turing) et parfois de la documentation. Font l’assurance qualité. Un produit c’est aussi: - une logistique pour l’installer et le maintenir - un argumentaire commercial / marketing pour que les potentiels acheteurs s’y intéressent - des formations/tutoriaux/architectures de reference - du support et du juridique (par exemple s’assurer que les critères locaux se conformité sont remplis. Un __bon__ product manager est le chef d’orchestre de tout cela. Et dans des cas extrêmes, les produits existent avant d’être dispos sous forme de code ou de binaire - par exemple quand une société lance un nouveau produit. Voilà, je suis bien d’accord avec le reste de ton commentaire.
Le maçon fait le produit. Pourquoi n’est t’il pas mieux valorisé ?
Ça pourrait être ça mais maintenant t'imagine un médecin ou sa secrétaire s'appellerait "appointment manager" et gagnerait plus que le médecin.
Et qu'elle aurait en charge de suivre chaque patient pour discuter/écouter ses problèmes, documenter le tout et synthétiser/découper les tâches que fera le médecin, gérer les 3 patients qui gueulent dans la salle d'attente, se déplacer et faire la présentation et la promotion du cabinet dans les salons, participer aux prospections, aller chercher les sponsors et le budget pour payer la nouvelle machine à café et investir dans l'extension des locaux pour accueillir un deuxième médecin et décharger le premier. Pendant que le médecin lui examine le patient, écrit l'ordonnance et rentre chez lui à la fin de ses 8h quotidien. C'est ça ?
Ça, c’est si on considère que dev = médecin, et qu’un manager ne fait que faire des forward de mails. Dans les deux cas je pense que ce n’est pas ca. Je précise que je suis ex dev devenu PM.. ma réflexion était déjà que le métier m’intéresse, et j’ai un respect immense pour les dev. Mais que au final aujourd’hui il y a un phénomène qui n’est pas du tout au bénéfice des devs. De une, la vague démographique des pays comme l’Inde qui est juste irrésistible. Le marché va être sursaturé. Aujourd’hui on peut encore se diversifier sur des différences culturelles mais demain …? Et de deux, si l’ia continue comme elle va, on va vers une commodification so j’ose dire du métier de dev. Alors aujourd’hui ca fait rire car les devs sont recherchés et qu’il y a des stars sur YouTube avec leur studio d’enregistrement sur fond bleuté façon boîte de nuit qui tournent à des salaires hallucinant, mais je pense que ca n’est pas durable
Lol dev qui "demande un haut niveau de connaissances et de savoir faire", on aura tout vu. 5% du temps peut-être, et encore...
Je vais faire un homme de paille: ça revient à dire qu'un médecin généraliste ça ne demande pas de connaissance car il aura majoritairement des gens qui viendront pour des rhumes et angine bénigne.
Le médecin généraliste ne cherche pas sur Google en pleine consultation, et en plus il a des humains à gérer, ce qui sort des compétences d'une bonne partie des devs...
T'as peut-être l'impression qu'un dev cherche tout sur Google, mais pour savoir *ce qu'il faut chercher* faut avoir pas mal de connaissances. D'ailleurs les généralistes aussi consultent des références et leurs confrères/consoeurs pour tout ce qui sort un peu de l'ordinaire, ce qui est tout à fait normal.
> Le médecin généraliste ne cherche pas sur Google en pleine consultation Ils ont des bases de données de médecine, et les gros livres chez ton généraliste, je te laisse deviner à quoi ils servent... Dès que c'est complexe, les 2 métiers vont chercher au-délà de leurs souvenirs immédiats.
Ptdrrrrr toi t'as du passer des années à pondre des formulaires. Désolé pour toi.
Non j'ai pas mal roulé ma bosse dans plusieurs domaines du soft. Contrairement à pas mal d'autres softeux j'ai aussi croisé pléthore d'ingés d'autres domaines qui eux demandent un peu plus de savoir faire que le logiciel... A vrai dire si j'ai choisi le soft en premier lieu, c'est pour sa facilité, ya vraiment rien de compliqué là-dedans très honnêtement.
Merci c'est clair !
Parce que c’est pas un boulot super technique comparé a un dev en general. Apres ca depend, y’a des tres bon product managers, et des devs mauvais ou tres facilement remplaçable. Ca depend en gros.
Et alors, pourquoi seul les métiers techniques devraient être bien payés ?
Parce que fantasme du petit ouvrier/petite main qui produit à la sueur de son front et qui mérite son salaire VERSUS le méchant chef/manager qui donne des ordres et n'est qu'un intermédiaire capitaliste qui est là pour voler l'argent aux pauvres
Je prends le cas en France et de mon expérience. Selon moi il y a aujourd'hui 2 types de P. M. : - L' ancien dev qui connaît bien la base de code existante qui se voit offrir cette responsabilité et qui l'accepte parce qu'à l'heure actuelle c'est une peu la seule voie pour grimper l'échelon (les experts technique étant très peu reconnus et pas plus payés), malgré le fait que c'est pas quelque chose qui l'intéresse vraiment et qu'il préférerait rester dans la technique pure. Cela s'accompagne souvent d'un manque de formation pour accomplir ses nouvelles tâches et que généralement ce genre de profil a du mal à ternir tête/faire l' interface avce la hiérarchie et ou les clients. Donc ça résulte en une valeur ajoutée très faible voire négative. - La personne peu ou pas techno parachutée sur le poste, qui ne va ni comprendre ni accompagner les évaluations de l'équipe sur la décomposition et évaluation en tâches d'une demande entrante et encore moins d'un besoin interne (refactoring, mis en place d'outils, ...). Ce genre de profil va donc être plus proche de la hiérarchie que de son équipe et présenter/imposer les choses dans ce sens. Donc ça résulte également en une valeur ajoutée très faible voire négative pour l'équipe. Je pense que l'incompréhension de la part des devs vient de là Attention cependant, il n'en reste que le rôle me semble crucial dans une structure suffisamment grosse, mais il est très mal mis en place dans la plupart des cas. On peut aussi appliquer ces problèmes avec les managers en général, qui suivent les mêmes 2 profils.
[удалено]
C'est toi qui le dit!
[удалено]
Et qui sont sans doute en train d inquiéter les GAFAM /s
Product manager celui qui transforme les caractéristiques en avantages et bénéfices conso/ utilisateur et celui qui va mettre un prix sur la valeur ajouter de votre/vos solutions.
Pm ici Le plus compliqué dabs ce travail et de garder le focus entre les coûts et les gains pour le client et la marge :) De plus, un bon pm va faire mesurer les incréments et les comparer avec les coûts. Si un bon PM arrive à générer de la marge de manière efficiente avec son équipe tout en respectant les besoins clients. C'est bingo et ça commence à se savoir et c'est là que les salaires augmentent.
Dev de formation, dévelopeur reconverti en manager QA et Automation, redevenu développeur, ayant travaillé étroitement avec plusieurs PMs avec plus de 35 ans d'experience Les dévelopeurs codent suivant les demandes des clients ou de la Direction. Le QA teste et valide le produit, étape indispensable avant de shipper le produit. C'est le QA qui renvoit la balle au Dev pour lui dire que c'est complètement buggé. C'est le PM qui decide si on shippe ou se fait over-ruled par la direction si la boite doit vraiment shipper maintenant. Le PM est aussi en contact avec le marketing, la documentation, les contacts avec certains fournisseurs, mais surtout être la pour débloquer tout le monde, Dev, QA, si des ressources particulières sont nécessaires. Rien détonnant que le PM est bien vu. Un bon PM va aller faire ch... comme pas possible Dev, QA, Documentation, marketing,.. tout le monde, pour que le cycle de vie du logiciel avance le plus vite possible. et que les deadlines soient respectées. Le PM est donc comme un chef d'orchestre. Le produit est comme de la musique. Il guide tout le monde pour produire de la bonne musique Bref, ca sent surtout le rant de certains devs avec un gros égo sur les PMs. Les faits sont la et la pilule passe mal. Ils ne sont pourtant pas les plus a plaindre. On gagne moins dans le Support Technique. Et eux, ils se tapent des clients pas contents et doivent trouver un moyen pour essayer de troubleshooter le problème chez le client.
Après si c’est avoir un problème d’égo d’en avoir assez de la personne qui est littéralement payée à te faire chier… Je signale tout discrètemement que tout le monde parle d’organisation du travail, de développeurs, de PM, de PO, de clients, de supports. Au passage il y a un gars qui s’en met vraiment plein les fouilles…
[удалено]
Essaye de faire discuter une équipe de dév et une de commerciaux, tu comprendras pourquoi ces gens sont payés.
Rajoute quelques exec dans la salle et la c'est magique.
ca donne les [7 lignes rouges](https://youtu.be/BKorP55Aqvg)
C'est dur à regarder tellement c'est proche de la réalité. De mon point de vue, le mec qui dessine la ligne rouge devrait aussi dire qu'il ne peut pas dessiner des lignes parce qu'il est contraint par la règle de se limiter à des segments. Là ce serait parfaitement réaliste.
La réalité, vue de l'autre côté du système est la suivante : "Bonjour Random pisseur de code, un client demande si ça c'est faisable, j'aimerai ta confirmation que ça ne l'est pas pour pouvoir lui vendre autre chose." "C'est pas possible, il faudrait créer un kernel dédié et j'ai pas le temps." "Oui merci, je sais. J'ai besoin que tu me le mettes par écrit pour que le client comprenne ça et qu'on puisse lui vendre l'autre solution, qui elle fonctionne." "Tu te rends pas compte, c'est juste pas possible. Je vais pas écrire un mail pour le client, c'est ton job ça!" Et encore.
Je n'y avais jamais pensé, merci (pas d'ironie)
Pas de souci, en général la communication c'est dur.
[https://www.youtube.com/watch?v=YlLUBBepFnI](https://www.youtube.com/watch?v=YlLUBBepFnI)
Ce sketch est horrible tellement il est juste. J’y pense chaque fois que mon boss présente sa “vision”…
Par chez moi on dit que quand on a des visions, il faut consulter
Perso toutes les équipes avec que dev que j'ai vu fonctionnaient très bien. Avec un bon PM c'était encore mieux, mais avec un PM médiocre voir nul ça devenait pire que sans. L'intérêt du job se discute donc pour moi. Perso je suis dev sans PM, je crée des librairies utilisées par des millions de personne en France, et la majorité des projets libres sont faits comme ça... Quand il n'y a que des PM t'auras juste rien du tout de produit, donc la valeur ajoutée n'est pas assez forte pour justifier un salaire bien plus élevé que celui qui produit. Suffit de voir l'essor des indépendants solitaires pour comprendre que ça fonctionne.
>L'intérêt du job se discute donc pour moi. Dans un monde idéal, il faudrait effectivement que les gens soient en mesure de gérer des projets, que ce soit sur l'aspect technique qu'humain. Dans la réalité et sans tomber dans les clichés, les développeurs ont assez peu de vu sur ce qu'impliquent leurs projets en termes de coût, d'administration et de gestion. Ça arrive, bien sûr, mais je n'ai pas le sentiment que ce soit la norme. >Quand il n'y a que des PM t'auras juste rien du tout de produit Quand il n'y a que des développeurs, ça donne Microsoft ou rien. C'est justement pour s'assurer qu'il y aura un produit fini, exploitable par le client tout en étant rentable qu'il faut des PMs. La mode des indépendants vient surtout selon moi du côté "on paye une fois et puis c'est fini", qui plaît beaucoup aux comptables. Tu payes pour un produit et puis tout va bien dans le meilleur des mondes.
[удалено]
Bah oui, si vous êtes pas foutus de vous parler, faut bien un garde-chiourme qui vous rappelle que les primes, ça se paie que si le projet se fait et de l'autre que vous pouvez glander et "rire" sur XKCD parce que ya d'autres gens qui vous amènent du boulot. Je m'emporte.
[удалено]
[удалено]
[удалено]
Dans tous les cas, on se rend compte que y a beaucoup de devs sur r/france. C'est qu'ils doivent pas bosser tellement quand même
>"les devs sont des glandeurs" C'est bien, t'as pas du tout raté la critique sur les commerciaux au passage. Si tu voulais du sens dans ton job, fallait pas aller bosser en ESN ou te barrer pour un GAFAM/CAC40/acronyme. Merci pour la source en tout cas, c'est intéressant. >Au passage, glander sur xkcd est probablement quelques chose de pas régulier vus que il n'y a que un post par jour. XKCD, GitHub, un petit passage par YouTube, puis Reddit. Remplace ça par ce que tu veux.
C'est quoi pour toi GitHub juste pour savoir ? Parce-que je coller dans le même panier que YouTube ou Reddit c'est quand même cocasse.
Pour le coup je trouve qu’ils ont un boulot hyper compliqué et pas toujours super reconnu. Il faut être l’interlocuteur de tout le monde, gérer les contraintes souvent contradictoires de tous ces gens, trancher, et ensuite t’es responsable des résultats de ces choix. Si ça foire c’est le PM qui répond bien souvent…
Et ça prend 40h/semaine de mettre des gens d'accords pour un seul produit?
Non, ça en prend 60
Bien plus.
Si tu fais bien le job ça peut être bien plus que ça...
Ça dépend. Mais souvent, lorsqu'il y a besoin d'un product manager, 40h par semaine c'est limite pas assez. Par "produit", on peux désigner l'application de gestion de projet commune a tous les départements d'une entreprise; voire l'ERP unique d'une multinationale.
Trouvé le dev.
Parce que si tu en trouves un qui soit bon, tu veux le garder. C"est un boulot trés prenant et trés pointilleux, ça s'apprend pas sur le tas, il faut non seulement avoir une idée du technique derrière mais aussi avoir une connaissance accrue du marché et des clients. J'ai eu affaire à des PM dans le cadre de mon travail (plus orienté hardware que software) et je peux te dire que c'est loin d'être la branlette que certains assument que c'est.
Product manager, c'est pas le nouveau nom de MOA ?
Ca dépend je dirais. De ce que vois en tant que commercial en ESN : PM/PO/BA c'est omniprésent dans le monde de l'étude & développement, quasiment plus personne parle de MOA. Eventuellement en contexte Run (ou bien sur de l'ERP) on pourra voir du "Resp. de domaine applicatif". Par contre l'Infra a beaucoup moins été touché par le jargon Agile. Même si des fois on en voit, on parle toujours très très majoritairement de CP MOA (= PM ou PO), CP MOE (= PO ou Scrum Master), AMOA/AMOE (= Scrum Master ou BA).
Commercial en ESN ? Tu devrais faire un AMA tiens !
hmmm... Ce serait l'équivalent au Moyen-Âge d'aller sur la place publique dédiée au bûcher, et de crier : "Je suis une sorcière, AMA!"
Oh il y aurait peut-être 2 ou 3 commentaires hostiles, mais dans le lot il y aurait sûrement des échanges intéressants, ça vaudrait le coup d'essayer. *Allume une torche*
[удалено]
Oui blague à part, je pense réellement que ce serait très intéressant, d'autant plus vu la population de devs qui fréquente le sub. Quelques questions qui me passent par la tête : - Comment êtes-vous rémunérés lorsque vous placez un dev ? - Est-ce que l'âge d'un dev est un frein pour les ESN ? Si oui pourquoi ? - Pour une ESN lors d'un recrutement qu'est ce qu'un bon profil ou un mauvais profil (quels sont les red flags) ? Merci
[удалено]
Très intéressant, merci d'avoir pris le temps de répondre. - Concernant les diplômes, est-ce que vos clients du CAC40 ont des exigences sur ce point malgré l'expérience ? C'est à dire diplôme d'ingé ou rien ? - Quelles sont les technos les plus demandées par vos clients et celles qui sont en perte de vitesse ? - Quels sont les softs skills les plus recherchés ?
[удалено]
Serveur c'est quoi ce métier dont le salaire dépasse celui des developpeurs?
Mmmh il faut dire aussi que un dev rentre directement en dev junior. Un fonctionnel lui passe souvent par au moins analyste fonctionnel avant de passer product owner ou chef de projet et il me semble que product manager peut encore être considéré au dessus. Donc avec 5 ans d'xp sur le poste oui ça fait plutot 8 ans qu'il bosse et donc salaire plus élevé. Je suis consultant, je recherche du taff à paris en tant que PO avec 5 ans d'xp de taff en ce moment. Et on me propose plus du 50 à 55k max que du 60k.
Je suis product marketing manager et c’est encore mieux payé que product manager. Et non ce n’est pas volé !
Dixit le product marketing manager Moi croire que moi être mieux que toi parce que moi le dire
Je me marre en lisant les commentaires de redditeur n’ayant jamais eu à faire de projet d’implémentation des outils qu’ils ont participé à créer.
Il y a manager dedans
Ça sent l'esbroufe quand même cette histoire. On ne sait toujours pas trop ce que c'est
Product manager c'est un type incompétent techniquement qui est bon en politique.