Lorsque « tout va bien », c’est normal pour tout le monde l’équipe de prod, le client, les prestas… mais c’est surtout parce le chef de projets est cette force de l’ombre qui dirige les flux des différents interlocuteurs.

Comme vous le dites, et le souligne Ally, la principale variable dans la qualité d’un taf de CDP c’est le temps. Préparer les échanges entre clients et prod, parfois faire la conception, suivi planning et prod sur au moins 5/6 projets actifs, plus la dette projets, c’est du temps.

Il n’y a pas de chef de projet parfait, mais il y a des chefs de projets qui apprennent et s’améliorent. Je pense que c’est le mieux que l’on puisse avoir :)

Il est important que le chef de projet comprenne effectivement bien ses équipes et leur travail afin de bien communiquer avec elles et organiser le projet. Il me paraît primordial qu’il ait lui-même des notions dans ces différents métiers afin d’être plus efficace aussi bien côté équipes que côté client. Il pourra ainsi émettre des premières réserves si besoin quant à la faisabilité technique et pas dire oui tout azimut aux idées fantaisistes du client ou du commercial face également à un timing et budget limité.

La seule chose qui ne ressort pas j’ai l’impression dans cet article c’est justement la dimension commerciale. Parfois, le chef de projet n’a pas le pouvoir de dire non au client sur certaines décisions qui lui paraissent tout aussi injustifiées qu’à son équipe. Tout dépend de la politique de la boîte, vendre ou non à perte, vendre du non qualitatif mais vendre à tout prix… Après, le rôle du chef de projet est clairement d’expliquer au mieux les délais, de conseiller, trouver un compromis avec le client, anticiper de part et autres les problématiques afin de faciliter la production, être transparent avec ses équipes et éviter les quiproquos sur la finalité avec le client, mais il n’a pas toujours le dernier mot sur ce qui est vendu ou décidé au final.

C’est en tout cas très chouette de pouvoir discuter de ce sujet et de voir les avis/difficultés que peuvent rencontrer les intégrateurs aujourd’hui. Pour améliorer les process, il est également bon de faire un bilan une fois qu’un projet est fini afin de voir ce qui pourrait être améliorer la prochaine fois, si on a le temps et encore une fois, si la culture de l’entreprise le permet.

Comme vous l’avez évoqué dans les commentaires, la notion temps du chef de projet qui courre partout à gérer 5/6 projets à la fois est primordiale, limitative et affecte effectivement parfois son travail qualitatif avec les équipes de production. Je pense que dans ces cas là, la première chose qui saute, c’est malheureusement le côté transparence qui donne la visibilité globale à TOUS les acteurs du projet, même s’ils ne sont pas directement impactés, provocant ainsi le fameux côté silo et le « on ne sait pas trop pourquoi on fait çà comme çà mais on le fait parce qu’on doit le faire », provocant forcément certaines frustrations.

Mais bon, dans un monde idéal, on ferait tous des projets où les variables temps, délai, budgets seraient en adéquation !

Salut Frank !

désolé si je t’ai brusquée, mais prendre plaisir dans son travail et se sentir soutenu et respecté c’est essentiel pour progresser. Et ça me chagrine que tu aies à écrire ce type d’article. Pour toi ou pour quiconque vite cela. Vraiment. Et d’autant plus venant de quelqu’un d’aussi passionnée et qualifiée que toi.

Y’a pas de mal du tout, au contraire ! Je suis contente qu’on me rentre un peu dans le lard, je m’étonne d’ailleurs que tu aies été le seul ;-)

Je pars du principe que tu as déjà du faire face à ce genre de situation. (…) Et du coup, je suis curieux : Comment décidez-vous du workflow de travail général ? Comment l’équipe sait-elle où elle en est, ce qui reste à faire ?

Alors, avant de te répondre plus avant, je tiens à rappeler que cet article ne parle pas de moi ni de mon travail au quotidien (bien que certaines situations puissent me rappeler certains trucs que j’ai vécus).

Pour écrire ce conte de Noël, je me suis certes appuyée sur ce que me racontent parfois des confrères et consœurs intégrateurs, mais j’ai aussi pas mal grossi le trait à des fins de caricature. Si ça te paraît exagéré, c’est donc volontaire. Ce n’est pas un reportage ; c’est une satire.

Cela étant dit, il y a certaines anecdotes que j’ai à peine reformulées. Tout choquant que cela puisse sembler, ce genre de situations, ce morcellement du travail en silos, ce manque de communication et de valeurs communes, existent bel et bien.

À en juger par tes deux commentaires, il semble que toi, tu aies la chance de travailler dans un contexte qui, par bien des aspects, semble idéal, mais crois-moi, c’est loin d’être le cas pour tous les intés et tous les CP avec qui j’ai déjà discuté !

Si il y a une liste de tâches correctement découpées (s’inscrire sur le site, afficher la liste des derniers articles, etc.), elle devrait être visible par toute le monde, s’il y a des limites de temps, elles doivent être connues de tous, de même que l’avancement, le restant à faire etc. Plus ces informations sont difficiles à avoir, plus il y a de risques d’incompréhension entre les différentes parties et donc de ralentissement.

Je sais, je sais, tout cela paraît évident. ET POURTANT. ;-)

Le Kanban physique est un outil très simple et très souple, bien adapté aux équipes pluridisciplinaires co-localisées. Il existe des versions en ligne comme le populaire Trello mais on perd l’essentiel, les interactions humaines.

Entre autres avantages, le Kanban permet de générer des discussions au bon moment en face to face, plutôt que par mail.

Il a pour but de faciliter la gestion du flux des tâches (rôle qui incombe au chef de projet), en focalisant l’équipe sur le travail en cours, pour le « tirer vers la droite », vers la colonne FINI au plus vite. Le kanban est un outil visuel, il va permettre de rapidement voir où le flux « bloque ».

Bref c’est un super outil sur lequel il y aurait beaucoup à dire et je ne peux qu’inviter les équipes à se pencher sérieusement dessus, car outre le fait de fournir une vision commune du flux de travail il pousse l’équipe à s’améliorer en la laissant s’organiser comme bon lui semble pour atteindre les objectifs fixés.

Merci beaucoup pour tout cela ! Les méthodes agiles sont bien ancrées en matière de développement back, mais j’en entends beaucoup moins parler côté front.

Aux chefs de projet, je dirais « arrêtez de vouloir tout contrôler, partagez la responsabilité, donnez des objectifs précis.

Car le problème que révèle ce conte est profondément humain, et derrière la problématique du « chef de projet » idéal se cachent des problématiques culturelles.

Oui, il y a de ça en effet. Le syndrôme du petit chef. Mais il y a aussi, comme le soulève Philippe dans son commentaire, des problèmes d’organisation qui découlent d’une surcharge d’activité. Si un CP est amené à gérer quatre ou cinq sujets importants en même temps, je ne vois pas trop comment ça peut fonctionner, qualitativement, humainement. Derrière tout ça, il y a aussi une responsabilité prise par les managers.

Bon, et sinon, j’écouterai la conférence de Kevin Goldsmith avec intérêt !

Merci encore pour ces échanges intéressants, Frank, tout cela m’apporte un point de vue complémentaire et d’autres axes de réflexion. Si, un jour, nous en discutons de vive voix de cette fantaisie de l’avent, j’aurai sans doute d’autres précisions à t’apporter.

Hello Philippe, merci pour tes retours !

– on voit souvent l’intégrateur/front-end dev comme le casque bleu qui se retrouve entre la tranchée du DA et celle du développeur back, or j’ai l’impression que ces 2 nations sont plus proches de l’armistice que de la guerre nucléaire. Aujourd’hui l’intégrateur échange beaucoup avec le CP parce que c’est lui qui est responsable de ce que voit le client. L’intégrateur travaille quasiment en binôme avec le CP lors de la phase de recette.

Je suis tout à fait d’accord avec toi.

À propos du mythe de la mésentente entre intégrateurs et web designers, j’avais donné mon avis chez l’ami Cabaroc il y a un an et demi : mon avis n’a pas bougé d’un iota.

Par ailleurs, c’est bien parce que le travail des intégrateurs et des CP est éminemment complémentaire que je me suis fendue de cette petite satire. La notion de binôme est très juste.

Et au final, ce n’est pas le meilleur CP qui s’en tirait le mieux, mais celui (ou celle) qui :
– avait/prenait le temps de communiquer avec son équipe
– connaissait les problématiques techniques/graphiques
– n’avait pas 20 projets en même temps

(…) puisqu’un des rôles du CP est de gérer le temps de chacun, il est important qu’il est le temps de bien le faire afin d’éviter un terrible effet domino.

Tout à fait ! La problématique du staffing du CP est stratégique. Or, ce staffing dépend rarement de lui. Dans mon article, il y a pas mal de points qui sont liés plus ou moins directement à ça, aux écueils essuyés lorsqu’un CP est débordé, pressé par sa hiérarchie, et qu’il manque de temps pour soigner les finitions.

Merci Régis, et bonne chance pour ton évolution en tant que CP. :)