[HELP] How to "chef de projet" (conseils, ressources etc)

Bonjour à tous :slight_smile:

Petit résumé très rapide de ma situation : je suis actuellement développeur (Unity, C#) dans une agence marketing, ou plutôt sa branche AR/VR/MR (XR donc).
Je n’ai pas un gros background technique, et je ne pense pas rester à un tel poste toute ma « carrière ».

J’ai pour objectif de passer chef de projet (ou son équivalent selon les boites / pays), de prendre de l’expérience là-dessus et de voir les opportunités que ça pourrait m’offrir.

Je n’ai pas d’expérience à proprement parler dans ce domaine (au-delà de mes expériences passées diverses), et je suis donc à la recherche d’avis, de retours, de conseils et d’autre ressources (bouquins, talks, contacts) afin de commencer à préparer cette transition.

Je suis évidement conscient que certaines choses ne peuvent s’apprendre qu’en étant confronté à des situations précises, mais le plus d’éléments j’aurais en tête, le mieux je pourrais (je pense) m’adapter à ces situations.

Je me tourne dans un 1er vers la Zone, parce que bon, c’est quand même vous les meilleurs hein (sauf @AnA-l, faut pas déconner)

Chef de projet c’est très large comme concept.
Quelle méthodologie de projet?
Pour des projets internes ou des projets clients ?

Quel aspect te plait dans la gestion de projet?

Dans mon parcours, j’ai été Product Owner/Product Manager en R&D pour ensuite passer Chef de projets clients dans une boite de 15 personnes.
Le suivi budgétaire, les relances sans cesse du client pour avancer dans le projet et les contraintes d’être absolument « facturable » m’ont pourri la vie, trop de stress.
Je suis revenu à un poste de Product Owner pur en R&D et je ne le regrette pas.

1 « J'aime »

Ouais, chef de projet ça se traduit dans beaucoup trop de boîte par « je fais de l’excel toute la journée, le feu du côté des devs et le feu du côté du client ». C’est vraiment pas un poste que j’envie.

Je rejoins complètement l’avis de @Bernie : need moar details, et ouais, PO/PM semble bien plus valorisant.

(bon après, voir un @nzx se transformer en @az (il est plus là aziz ?), je suis pas sûr.

1 « J'aime »

Avant de vouloir ça, la vie de Chef de Projet, pose toi quelques questions notamment :

Suis-je prêt à lâcher le côté maker et donc un certain type « d’aboutissement » ?

Suis-je prêt à devoir gérer quotidiennement des « problèmes » ou des « situations », pas tout le temps porteurs de beaucoup de valeur y compris dans la solution ?

Suis-je assez rigoureux au quotidien tout en sachant me projeter ?

Est-ce que je sais anticiper ?

Suis-je prêt à gérer des choses plus « administratives » ou qui relèvent plus des fonctions supports (suivi budgétaire par exemple, relance des fournisseurs) ?

Suis-je assez bon communicant pour faire circuler la bonne information parmi les acteurs du projet sans créer de tension ?

Suis-je assez empathique et diplomate pour savoir gérer les situations conflictuelles entre acteurs du projet ?

Suis-je assez politique pour passer mes demandes ou mes besoins auprès des N+ et autres décideurs de l’organisation ?

Déjà, des réponses à ces questions devraient te permettre de voir si oui ou non c’est un bon choix pour toi.

Ensuite, il y a autant de CdP ou Directeur de projet qu’il y a de boites, avec des fonctions et des engagements qui peuvent largement diverger.

Tu as des CdP en agence web, 25 ans et fraîchement diplômé d’une école de commerce, petite expérience, payés au lance pierre pour gérer de la merde h24.

Tu as des CdP dans le BTP, 25 ans d’xp, qui gèrent des chantiers à qques millions d’euros…

Bon courage dans tes réflexions en tout cas !

5 « J'aime »

Je partage complètement les réflexions d’@exeo.
Je viens de faire 5 ans en aMoa en interne client et j’ai adoré mais tout ce qui est mentionné est à prendre en compte

Merci pour vos réponses, je n’aurais donc pas fais de bide :smiley:
Pour Az, je voulais le ping mais je n’étais pas sur duquel tag

image


Alors : je pense que l’une des premières choses à mettre au point, c’est effectivement de savoir tout ce qu’il existe comme « type » de chef de projets et ce vers quoi je souhaite me diriger.

Clairement, mon but n’est pas de faire de l’Excel toute la journée.
Actuellement, je suis dans une petite agence, composée de 7 personnes (moi compris) : un directeur d’agence multi-tâches, qui ne pourra pas continuer à être sur tous les fronts sans exploser en vol, un directeur artistique, un web designer (qui fait du WP, comme du motion-design ou de la modélisation 3D), un dev web senior qui sait relativement bien se gérer et à beaucoup aidé sur la mise en place d’un gros projet cette année, un commercial et une nouvelle venue qui prête main forte sur un projet, avec pas mal de relation clients.

Cela risque de faire réponse bateau, mais j’aime bien planifier les choses, mettre en place des process, faciliter la vie en fait.
Cela sonne presque comme la description d’un rôle logistique : offrir une solution adaptée à un problème donné, avec ou sans outil particulier.

Actuellement, on manque de compétences en interne : on va donc devoir faire appel, au moins dans un premier temps, à des compétences extérieures (du dev, mais pas uniquement).

L’une de mes « premières tâches » serait de rechercher ces compétences, de prendre contacts avec des freelances et de voir comment avancer avec nos projets.

J’ai du sang B.R.E.T.O.N mec, quelque part du côté de mon père.

Sur la partie pro, oui, je pense.
Je suis entouré de créatifs (pour l’instant), et c’est assez frustrant de ne pas pouvoir complétement les suivre dans leurs délires par manque de compétences.
J’ai vraiment le sentiment de ne pas être fait pour continuer dans du dev pur.
Je vois ça comme un moyen d’accéder à d’autres choses, sans être sorti d’une école : engranger un set de compétences qui me servirait pour mieux dialoguer avec des équipes, et mieux les aider à venir à bout d’un projet.
Et puis surtout, je garde toujours au fond de mon petit cœur l’espoir de bosser un jour dans le JV, et je sais que ce n’est pas en tant que développeur que j’y arriverais (et dans le jv, ya encore d’autres dénomination pour parler de chef de projet).

Je pense que oui.
Aucun boulot n’est de toute façon « super trop cool, journée tip-top » tout le temps. Ou alors je n’ai pas conscience de ce(s) boulot(s). Et encore une fois, j’aime voir au sens équipe plus qu’individuel.

La rigueur, c’est pas inné : ça s’acquiert et je suis convaincu que ça vient aussi avec le job / le hobby : quand on aime ce que l’on fait, et qu’on se projette un minimum, ça se fait naturellement.

J’aurais tendance à dire que ça vient avec l’expérience ? À force de situations vécues, on y voit plus clair et l’anticipation devient meilleure, plus optimisée.

Ce n’est jamais trop, et très clairement ce n’est pas mon but que de ne faire que de ça. Mais ça dépend aussi de la taille de l’entreprise, et des équipes : un chef de projet, ça doit aussi savoir déléguer (et pas simplement se décharger hein).

J’ai bossé en boutiques Orange, chez Darty dans le 8ème arrondissement et dans grotte au cœur d’une réserve naturelle et coin touristique : j’ai géré des clients mécontents, des clients mécontents et handicapés (difficultés à s’exprimer, et à comprendre), j’ai géré des cars d’Allemands bourrés à 9h du mat’, j’ai dû nettoyer des chiottes pourries par ces même cars en saison pleine, et j’ai dû gérer un mort lors d’une de mes visites de grotte.

Je pense, j’espère, que ça pourrait m’aider. Ah, et jsuis beau-père donc les conflits … :smiley:

Aucune idée. C’est peut-être ce qui me fait le plus « peur » dans le fait de bosser dans une grande boîte.

Yep, c’est encore flou pour moi :confused:


Again, si vous avez (en plus de vos avis) des ressources à filer, je prends !
Ah, et précision : je suis actuellement (et normalement jusqu’au mois de juin prochain) en temps partiel (20h par semaine), car ça me permet de gérer « à la maison » pendant la formation d’aide-soignante de ma compagne. Et forcément, 20h/semaine pour bosser en tant que dev, je trouve que c’est compliqué en ça que je n’avance pas aussi rapidement que je le souhaiterais.

1 « J'aime »

Aucune pub de ma part, j’avais trouvé ceci pas mal comme mooc sur le sujet

Si, mais y’a un trick :stuck_out_tongue:
@_az

2 « J'aime »

Alors, je prends le temps de répondre ici (je n’ai pas vraiment eu l’occasion de me poser depuis ce week-end).
J’ai échangé rapidement avec @_az via Discord, et il m’a envoyé quelques liens :

Et … c’est pas du tout ce que je fais / ce que j’entends par « chef de projet », pour la simple raison qu’on ne fait pas de produit dans l’agence.

Notre objectif est de pouvoir proposer des solutions personnalisées à des industriels, pour répondre à certaines problématiques (de formation, de prototypage etc) grâce à la réalité mixte / réalité virtuelle.
Je n’ai pas l’impression que ce qu’on a en tête se dirige vers du produit (et donc toute l’organisation que ça implique).
Je suis le seul dev’ sur la partie XR, on n’est pas Agile (pas encore ?), et on ne fait visiblement pas de produit donc … retour à la case départ ?
Encore une fois, si vous avez des références de bouquins ou autres, qui pourraient m’aider à y voir plus clair, je prend :slight_smile:

Tu veux faire chef de projet côté technique ou chef de projet côté « programme » ?

Côté technique plus que « programme », je dirais.

C’est pas la même chose ?

Je ne pense pas (mais je ne suis peut-être pas le mieux placé pour en parler, justement) : tel que je le comprends, le chef de projet « côté technique » ne code pas/plus ou peu, là ou celui côté « programme » est plus impliqué dans le développement.

On peut être agile même en faisant des projets clients.
Dans mon ancienne boite on était 15, le rôle du PM était dans un premier temps:

  • analyse des besoins des clients
  • écriture des solutions (challengée par l’équipe IT et le client)
  • budgétisation et priorisation

Ensuite on créait des phases (qu’on pourrait appeler Sprint), afin de pouvoir délivrer très vite quelque chose en production pour le client. Le plus dur dans mon ancien domaine (déploiement ERP) était de faire passer le client en prod, il aura toujours une bonne raison de pas le faire. En agissant de la sorte on diminuait les frictions et on a un meilleur suivi budgétaire. Car soyons clair, le sales promettait des rolls royce (ce que demande le client) pour le prix d’une clio. Dès qu’on travaille dans l’immatériel, il est très dur de s’imaginer le cout d’un projet.
Bien sur la formation est très importante.

Dans ce cas, on appliquait pas une méthodologie précise, c’était un peu à notre sauce mais on pouvait très vite changer les priorités. Par exemple la mise en place de l’ecommerce à cause du lockdown qui à la base était juste un nice to have.

J’avais un rôle pur PM, mais pour certains projets les devs avaient la double casquette.

Je pense que j’ai une grosse lacune sur les termes, les rôles, et que ça m’embrouille un peu mais ce que tu décris …

- analyse des besoins des clients
- écriture des solutions (challengée par l’équipe IT et le client)
- budgétisation et priorisation

… me semble être un bon début, une bonne manière d’amener le sujet au sein de l’agence. Cela me semble être une bonne manière de prendre de l’expérience, et d’initier ma transition.
J’ai quelques notions d’Agile (SCRUM en particulier) vu que le sujet avait été abordé dans ma (courte) formation Simplon : le problème étant qu’une grande majorité de la promo ne jouait pas le jeu, donc forcément …

Pas de souci, quand on baigne dedans ca parait logique, j’aurais du donner + de précisions.
Si j’ai bien compris, ton agence offre à ces clients des solutions de réalité virtuelle, augmentée.

Imaginons qu’une agence immobilière vient demander une solution pour que ses clients puissent visiter les maisons à l’aide d’un casque de réalité virtuelle, probablement que ton commercial va vendre tout le package Hardware + logiciel maison sans trop entrer dans les détails.
Une fois que tu seras en charge du projet, tu vas devoir définir à quoi s’attend le client. Faut-il juste modéliser les murs ou bien aussi mettre des meubles ? Jusqu’ou faut il pousser la perso ?
Quand faut il que ce soit livré ? Est-ce qu’on commence sur une maison ou bien l’agence veut que toutes les maisons en ventes soient toutes dispo en VR?
Le but du PM est aussi de raisonner le client et de calmer ses ardeurs, et de l’autre coté de voir si les ressources nécessaires en entreprise sont dispo. Imaginons que le sales ait vendu la totale, mais qu’on est en pleine période de congé, peut-être que le minimum peut être délivré dans un premier temps.

Analyse du besoin = ce que le client a vraiment demandé. Surtout que le commercial n’a souvent pas la connaissance du produit. Si ca tombe il va proposer un Occulus relié à un PC alors qu’il faut quelque chose de nomade avec une résolution basse.
Solution = écrire dans un langage interne ce que le client veut. Et découper le travail.
Budgetisation = pouvoir estimer la charge de travail et le cout de chaque point, si ca tombe le client va dire OK pour juste modeliser les murs et mettre + d’argent dans le casque VR.
Priorisation = que faut-il faire en premier ? Quel est le MVP (solution minimum viable pour le client).

La mise en place d’un tel processus est à prendre au niveau de la direction de ton agence à mon avis.

Top comme use case, c’est effectivement plus clair ainsi (et c’est +/- e que j’avais en tête en parlant de « chef de projet »).

Tous les points que tu présentes peuvent être mis en place au sein de l’agence.
Reste que c’est peut-être la partie « budgétisation » qui pourrait s’avérer la plus délicate.

Merci pour ces éclaircissements !

Le role/métier de PM ne se cantonne pas qu’aux méthodes Agile :slight_smile:
C’est plus le cas pour le role de PO qui est généralement spécialisé sur le delivery, et souvent dans une méthodo agile ou approchant (scrum, scrumban etc…)
Le premier lien mentionné par @nzx résume plutot bien les différents métiers et roles dans le product management.

Tu veux rester dans ta boite actuelle donc, et pas faire un plan d’evolution/carrière ? Si tu prends un titre de Chef de Projet, tu risque de te retrouver limiter a la rigueur a des roles de PO dans les métiers du product management. Et pour le coup si tu fais des fonctions de business analyst (analyse des process&co chez le client), du recueil de besoins, de la priorisation etc… tu as de facto un role proche du product management.
Un chef de projet est souvent assimilé à un role qui se limite au delivery. Mais si tu bosse en ESN ensuite ou sur des grosses boites FR c’est compris. Par contre sur les startups ou autres boites tech tu vas plutot avoir des organisations orientées produit, et tu risques d’avoir un petit décalage (principalement sémantique et un peu en méthodo/best practices)
Tu ne peux pas faire un peu évoluer la philosophie dans ta boite et essayer simplement de montrer qu’ils ont au final des fonctions autour du product management, juste qu’ils ne le prennent pas en compte explicitement ?
Je suis rentré dans une boite de prestation qui se rapproche de ce que tu décris (bon, ya un startup studio qui se monte qui justifiait aussi mon recrutement), ce qui me change de ce que j’avais l’habitude d’avoir comme cadre auparavant, et on a en plus un focus sur des projets qui m’étaient pas vraiment familiers jusque la vu qu’on traite principalement des problématiques d’IA/ML
Ca n’empeche pas d’avoir une approche « Product » dans ce qu’on fait, et effectivement pas mal de méthodologies sont communes si tu mélanges des roles de business analyst et de project management.

Le premier chapitre de ce petit bouquin est pas mal sur le sujet : https://blog.thiga.co/organisation-produit-definition-partie-1/
J’ai découpé dans le pdf le premier chapitre qui est vraiment un bon survol de la place du produit dans une organisation, des différents roles, des interactions avec le reste des fonctions de la société etc…

Product-Academy-3_Les-organisations-produit-ch1.pdf (1,3 Mo)

1 « J'aime »

Tou à fait, je voulais juste rebondir que les méthodologies agile ne s’appliquent pas qu’à du produit, mais pour tous les types de projets.
Et soyons clair, être agile veut tout dire et rien dire. Concernant la méthodo SCRUM, je n’ai jamais rencontré une seule entreprise qui appliquait tous les principes à 100%.

Le problème des titres de jobs, c’est qu’en général ca a une signification différente d’une entreprise à une autre. Sans oublier les titres « honorifiques » ou pour attirer des profils à des postes qui attirent peu de gens (j’ai un pote qui a décroché un job intitulé ‹ ingénieur réseaux › alors qu’il n’a fait qu’une formation de 3 mois et ce job consiste à faire du support).

D’ailleurs, de nombreuses sociétés demandent encore des certifications genre Prince II pour être Project Manager alors que ces sociétés font tout à leur sauce. Mais ca devient de plus en plus rare. (en tout cas dans le milieu de l’IT en Wallonie).

Merci pour le lien, ca a l’air de bien résumer les différents fonctions.

2 « J'aime »

On est d’accord :slight_smile:
Pour les méthodos agile après avoir grappillé dedans j’ai fini par favoriser la méthode « Scrumban » qui est un mélange de Scrum et de Kanban. Le principal avantage de cette méthode c’est qu’on a pas la rigidité du Scrum sur le scope des sprints et les rituels associés. C’est bien plus pratique pour le type de boites ou j’évoluais (startup « early stages », en gros entre 10 et 100 personnes)
La tendance en ce moment c’est apparemment de se tourner vers la méthode « Shape Up » : Shape Up: Stop Running in Circles and Ship Work that Matters | Basecamp
Je n’ai pas encore eu l’occasion de m’y mettre, mais ca a l’air de coller avec certaines tendances de fonds, notamment le fait de ne pas « shipper des fonctionnalités » pour le plaisir de sortir des fonctionnalités (on parle de Output (livrer des features) vs Outcome (atteintes d’objectifs mesurables)

Pour les titres je te rejoins ouais, et encore on a dans l’ecosysteme un sacré paquet de trucs qui frisent le n’importe quoi sur ces titres. Genre les « growth hackers », que j’appelle les « gros sacs ».

Le Product Management étant a cheval entre quasiment toutes les fonctions des organisations, a la fois métier/technique/design/opérationnel/etc… et étant arrivé très récemment en France, a peine 10-15 ans hein, on essaye de faire un peu d’évangélisation. Je sais que certains trouvent ca dérisoire, mais il y a effectivement une vraie différence entre le role de PO et le métier de PM. Progressivement, avec les boites comme Thiga, les conférences comme la LPC, et le travail d’evangélisation de certains CPO, on arrive a faire avancer un peu le bouzin et ca commence a se structurer :slight_smile:

En tout cas pour en revenir au post initial, il vaut mieux en terme de perspectives de carrières (et de grille salariale) essayer de rentrer dans un cadre de PM plutot que faire du project management ou business analyst. C’est plus gratifiant je pense, et ca permet de mettre le pied dans les boites tech/inno, pas forcement que de la startup StationF-style

1 « J'aime »