Mission comme analyste fonctionnel

pacodoso a écrit : Leur fonctionnement est le suivant :
- il y a un Product Owner qui a rédigé et fait évoluer un cahier des charges fonctionnel en français
- il y a actuellement 1 rédacteur de spec, qui part de ce cahier des charges, pour rédiger en anglais les tâches qui seront affectées aux développeurs
- ensuite, les 2/3 développeurs (1 français, 2 à l'étranger) réalisent les développement à partir des spécifications fonctionnelles
- il faut ensuite être en mesure de répondre aux questions des développeurs

Déjà, si un client qui dit qu'il y a un PO qui rédige un cahier des charges, je prend mes jambes à mon cou et je m'en vais loin, loin, loin. Si en plus il y a des dev en offshore...

quid de l'architecture et de l'intégration?

Hello.
Pourquoi prendre ses jambes à son coup s'il y a un PO?
Il réalise ses expressions de besoin que tu dois transformer en spec. Rien ne t'empêche de lz challenger si l'expression de besoin n'est pas clair, au contraire.
Après, plus que le client, c'est le domaine fonctionnel qui va étoffer ton Cv car tu vas intégrer tous les à côté (planning chiffrage budget suivi etc....).
Sur la région parisienne, le tjm client est entré 600 et 750e voire plus sur du règlementaire...
C'est juste mon avis:)
Jean Louis

Pitivier a écrit : Déjà, si un client qui dit qu'il y a un PO qui rédige un cahier des charges, je prend mes jambes à mon cou et je m'en vais loin, loin, loin. Si en plus il y a des dev en offshore...

C'est pas vraiment du "offshore" : comme c'est un groupe international, ils ont des sites dans différents pays (Allemagne, Pologne, Roumanie, ...)
Apres ils ont plus d'un développeur ici, mais sur ce projet c'est a priori le seul français.

mixomatose a écrit : quid de l'architecture et de l'intégration?

Il n'y aura a priori pas grand chose à faire en terme d'architecture comme le projet a commencé depuis plus d'un an. Il s'agit de développement mobile "cross-platform" : je suppose que ce qui les intéresse, c'est que j'ai une connaissance sur cette techno, mais également que j'ai déjà fait de l'analayse et que je m'en sorte pas trop mal à l'anglais.

Apres pour l'intégration également il y a un existant, qui pourrait être un peu optimisé, mais je suppose que ce n'est pas une priorité.

guessavril a écrit : Hello.
Pourquoi prendre ses jambes à son coup s'il y a un PO?
Il réalise ses expressions de besoin que tu dois transformer en spec. Rien ne t'empêche de lz challenger si l'expression de besoin n'est pas clair, au contraire.
Après, plus que le client, c'est le domaine fonctionnel qui va étoffer ton Cv car tu vas intégrer tous les à côté (planning chiffrage budget suivi etc....).
Sur la région parisienne, le tjm client est entré 600 et 750e voire plus sur du règlementaire...
C'est juste mon avis:)
Jean Louis

Je ne sais pas justement si je vais intervenir sur d'autres sujets (planning, chiffrage, suivi, ...) que la rédaction de spécifications fonctionnelles. On m'a vraiment vendu la mission comme le fait de devenir le "tampon" entre le PO et les développeurs : comprendre ce qu'a écrit le PO, le traduire en tâches pour les développeurs, être en mesure de répondre aux questions des développeurs,...

C'est moi qui ait utilisé le terme de "consultant fonctionnel" comme il ne s'agit plus de développement : est-il le plus approprié?

Apres ce qui me fait un peu peur c'est justement que ce soit trop "fonctionnel" et pas assez technique. Si le travail se résume à traduire le cahier des charges, en découpant le travail des développeurs, ça ne me conviendra pas longtemps. Et comme fonctionnellement il y a peu de clients sur ce créneau, pas sur que ce soit valorisant à long terme.

Si j'ai bien compris leur principal soucis, c'est qu'ils estiment ne pas avoir assez de specs en avance : du coup les développeurs seraient parfois "bloqués" et n'avanceraient pas assez vite.

Ils parlent d'agilité, mais si les développeurs se contentent de réaliser un travail pré-maché à l'avance, peut-on encore parler d'agilité?

guessavril a écrit : Pourquoi prendre ses jambes à son coup s'il y a un PO?

Un PO qui rédige un cahier des charges.... Sérieux ? Il n'y a rien qui te choque ?

pacodoso a écrit : Si j'ai bien compris leur principal soucis, c'est qu'ils estiment ne pas avoir assez de specs en avance : du coup les développeurs seraient parfois "bloqués" et n'avanceraient pas assez vite.

D'après ce que tu nous dis, leur principal soucis c'est qu'ils n'ont pas compris scrum (qui semble être le framework agile qu'ils veulent utiliser).

Pitivier a écrit : D'après ce que tu nous dis, leur principal soucis c'est qu'ils n'ont pas compris scrum (qui semble être le framework agile qu'ils veulent utiliser).

C'est bien possible, mais je pense que c'est souvent le cas dans les "grosses" boites qui fonctionnaient depuis des années avec le cycle en V.

La personne que j'avais en entretien a lui-même reconnu qu'ils utilisaient une approche Agile/"maison", mais je pense que ça doit leur convenir.

Mouais. Ça me fait penser à des missions que j'avais refusé. Peut-être il s'agit du ou des mêmes clients.

On est attiré par le mot Product Owner et on s'aperçoit que le poste est en fait celui d'un Business Analyst ou Proxy Product Owner. Autrement dit le PO en titre ne met pas les pieds dans le process Agile.

Mais ce qui m'avait dérangé ce n'est pas tant le poste de proxy PO qui déroge un peu de la méthode Agile (soit on n'a pas toutes les prérogatives d'un PO en titre mais dans la vie de tout les jours j'aurais été PO), mais c'était dans une organisation disséminée à l'extrême avec des dévs aux 4 coins du monde, pas un groupe de personnes sous traitées à un seul endroit, nan une équipe de 3 dévs avec un dans chaque pays...d'ailleurs c'est "interdit" de développer en France.

Et puis on s'aperçoit, que le PO en titre et /ou l'expert métier n'est pas non plus en France.

Donc que ce soit avec les dévs et/ou les experts métiers on ne peut que constater que tout échange dynamique et quotidien typique de la méthode Agile n'est pas possible de toute façon.

Et en creusant un on voit que la mise en œuvre technique est tordue à pour pouvoir être appliquée à cette dissémination.

Donc, non je suis désolé, ce n'est pas une simple adaptation de la méthode Agile, pour certains cas c'était du n'importe quoi. À ce compte là, je préfère une bonne vieille méthode en V assumée, qu'une pseudo méthode Agile complétement dévoyée qui n'a plus rien d'Agile.

Et les entretiens téléphoniques avec les prestataires en place avaient conforté ma mauvaise impression.

En tout cas récemment sur 4 offres de Product Owner avec équipes de dévs offshorisés, (si si c'est bien le cas quoique tu en dises), 2 étaient à peu près sérieuses, mais je n'avais pas envie de me balader aux 4 coins du monde ni de passer ma vie au téléphone, les 2 autre c'était du n'importe quoi qui n'avaient rien à voir ni de près ni de loin avec la méthode Agile, et quelques soit la dénomination de cette méthode je n'avais pas envie de participer à cette mascarade d'organisation.

Et la description de ta mission me fait plutôt penser au pire des 2 cas c'est-à-dire une mission qu'on présente comme Agile alors qu'elle semble plus bureaucratique qu'une mission en V, que ça soit du point de vu organisationnelle et géographique.

C'est pour cela, en ce qui me concerne, que j'avais pris mes jambes à mon coup.

Si je peux me permette Pacodoso, dans beaucoup de tes messages tu essayes de tordre les balivernes que les clients/intermédiaires te racontent pour qu'elles soient conformes à tes attentes. Souvent je donne trop le bénéfice du doute aux gens mais tu me bats à plate couture. On peut chacun avoir des tolérances sur les divergences avec l'état de l'art, le contrat idéal, le développement idéal, mais ne pas se raconter des histoires. Pour ce sujet, il est préférable de se dire "je vais accepter cette mission qui n'est pas en fait de l'Agile" que "alors en fait si c'est de l'Agile", ou dans d'autres sujets on te démontre par A+B qu'on te raconte des salades et tu trouves encore des excuses aux gens, ou alors il est préférable se dire "je vais accepter cette mission pourrie car j'ai besoin de revenus" que d'enjoliver une mission.

Tout le monde peut se faire avoir, même les plus aguerris, par contre une fois qu'on t'a ouvert les yeux je te comprends moins 🙂 Mais bon que tu poses tes questions ici montrent quand même que tu as des doutes. Et puis finalement tu finis par accepter au bout de plusieurs pages que tu voyais trop la vie en rose :)

J'espère que tu ne prendras pas trop mal ma façon directe de te parler :)

En tout cas ne perd pas de vue que cette mission c'est de la rédaction de spécs que tu dis ne pas apprécier.

A titre perso, je ne pourrais jamais rédiger les specs. C'est surement une des tâches qui m'ennuient le plus.

Pour ce qui est AGILE, nul besoin de chercher trop loin. AGILE ne se résume pas à SCRUM. Pratiquant SCRUM depuis quelques années, je trouve qu'elle n'est pas vraiment adaptée pour les nouvelles technos qui nécessitent beaucoup de montée en compétence de l'équipe, mais c'est un autre débat.

Sinon, quand je vois "rédaction des specs", c'est un signe très fort pour dire qu'ils ne sont pas AGILE. Je ne dis pas que c'est incompatible, mais c'est 90-99% des cas selon le niveau d'importance ils mettent dedans. Faut pas oublier 1 des 4 valeurs fondamentales de manifeste agile:

Des logiciels opérationnels plus qu’une documentation exhaustive

Merci pour retour plutôt complet phili_b.

Donc tu as profil plus fonctionnel que technique? Ou c'est plutôt au niveau méthodologie que tu interviens? Parce que j'ai du mal à voir comment "valoriser" une expertise fonctionnelle quand on est freelance, et qu'il y peu de clients sur le créneau...

phili_b a écrit :
Si je peux me permette Pacodoso, dans beaucoup de tes messages tu essayes de tordre les balivernes que les clients/intermédiaires te racontent pour qu'elles soient conformes à tes attentes. Souvent je donne trop le bénéfice du doute aux gens mais tu me bats à plate couture. On peut chacun avoir des tolérances sur les divergences avec l'état de l'art, le contrat idéal, le développement idéal, mais ne pas se raconter des histoires. Pour ce sujet, il est préférable de se dire "je vais accepter cette mission qui n'est pas en fait de l'Agile" que "alors en fait si c'est de l'Agile", ou dans d'autres sujets on te démontre par A+B qu'on te raconte des salades et tu trouves encore des excuses aux gens, ou alors il est préférable se dire "je vais accepter cette mission pourrie car j'ai besoin de revenus" que d'enjoliver une mission.

Tout le monde peut se faire avoir, même les plus aguerris, par contre une fois qu'on t'a ouvert les yeux je te comprends moins 🙂 Mais bon que tu poses tes questions ici montrent quand même que tu as des doutes. Et puis finalement tu finis par accepter au bout de plusieurs pages que tu voyais trop la vie en rose :)

J'espère que tu ne prendras pas trop mal ma façon directe de te parler :)

En tout cas ne perd pas de vue que cette mission c'est de la rédaction de spécs que tu dis ne pas apprécier.

Je comprends ton point de vue, et je ne prends pas mal tes remarques ;)

Mais c'est justement parce que je me suis fait "avoir" par 2 SSII pour mes premières missions que j'essaie de mesurer le pour et le contre, particulièrement si la mission doit être "longue".

Comme tu l'as compris, la rédaction de spécs ne me passionne pas, donc je me demandais si l'approche "pseudo Agile" ou l'environnement technique du client pouvaient être intéressantes.

Je n'ai pas vraiment eu l'occasion de prendre part à des missions en mode Agile sauf pendant une mission de 3/4 mois : du coup une expérience dans un contexte Agile m'intéresserait, et je serais prêt à faire des concessions. Mais comme plusieurs personnes l'ont souligné, l'approche du client n'est pas vraiment Agile ici, donc de ce côté l'intérêt est limité.

Pour l'environnement technique, ça me semble également limité, car même si le client me "promet" 50% de dév d'ici 2 mois, rien ne me le garantit : et même un TJM correct ne me permettra pas de rester hyper motivé par de la rédaction de spécs dans le temps...

Pour répondre à ta question j'ai un profil technique très fonctionnel.

Une mission uniquement technique, sans investissement dans la compréhension du métier, m'ennuie, et une mission purement fonctionnelle, sans lien avec la technique, m'ennuie.

J'avais apprécié d'être PO, car je n'étais pas loin des problématiques techniques (notamment les dévs parlent technique lors des mornings), contrairement aux 2 propositions foireuses de PO qu'on m'a fait dont je parle plus haut.

phili_b a écrit : Pour répondre à ta question j'ai un profil technique très fonctionnel.

Une mission uniquement technique, sans investissement dans la compréhension du métier, m'ennuie, et une mission purement fonctionnelle, sans lien avec la technique, m'ennuie.

J'avais apprécié d'être PO, car je n'étais pas loin des problématiques techniques (notamment les dévs parlent technique lors des mornings), contrairement aux 2 propositions foireuses de PO qu'on m'a fait dont je parle plus haut.

Merci pour ton retour. C'est sûr que l'idéal c'est toujours de pouvoir "mixer" technique et fonctionnel. J'ai informé le client que le projet me semblait trop fonctionnel et que je préférais décliner. Il m'a répondu en expliquant qu'il comprenait et que je pouvais revenir vers lui si je changeais d'avis les prochains temps...

Et du coup il y a des domaines fonctionnels ou tu t'es vraiment spécialisé? (banque, assurance, ...)

Pour revenir à l'Agile, j'ai l'impression que dans la plupart des "grands comptes", c'est rarement appliqué correctement. Ca donnait quoi chez tes derniers clients?

Il y a des domaines que je finis par connaître depuis le temps que je travaille mais je préfère découvrir de nouveaux métiers.

Non ça n'a rien donné, ou bien de vraies propositions de PO, mais mon année et demi de PO était trop limite car ils voulaient trop souvent un spécialiste métier ou bien les mic macs que j'ai refusé.

Ou d'autres propositions où ils voulaient en même temps que je sois Scrum Master.