Chronologique Discussions  

< Chronologique >       < Discussions >

---

salut,

c'est exactement ce que j'allais te proposer au sujet de l'architecte, il est responsable de ses choix et doit pouvoir les justifier.

Donc il est censé connaître vos domaine de compétences et évaluer celles nécessaires au projet.

Ainsi il pourra dire si le projet est réalisable par vous, ou s'il faut trouver d'autres ressources ou s'il faut tout simplement le refuser.


Bien sûr, tu dois avoir une idée de comment réaliser le projet mais est-tu certain que ta méthode remplira parfaitement le cahier des charges ?

Ce n'est pas ton rôle et tu n'as probablement pas toutes les informations du client.

Donc tu ne devrais pas t'avancer à faire de propositions sur l'architecture de ce projet, tu risquerais de te planter.

D'autant que cela serait une belle opportunité pour l'architecte de dire que tu traines parce que ses choix ne te plaisent pas.

Si tu avais des réticenses sur ses choix tu aurais dû les faire dès le départ pour qu'il est la possibilité de les ajuster.

S'il te les as ordonner, comme tu semble le dire, c'est là qu'il aurait fallu aller voir la direction pour exprimer tes réticences.


Maintenant, à mon sens, vous devriez aller voir l'architecte et quand même lui exposer vos difficulté.

C'est d'ailleurs choquant qu'il ne viennent pas à vous pour voir votre avancement.

Soit il a pas conscience de ce qu'il vous a demandé, soit il se croit chez Google ! Tu dois bien en avoir une petite idée, non ?

Dans tout les cas, s'il doit y avoir un changement cela devrait venir de lui, puisqu'il à la maitrise globale du projet et pourrait devoir le justifier.

Donc, soit vous arrivez à vous entendre sur des changements acceptables pour ne pas informer la direction, soit vous serez tous responsable du retard à votre niveau de responsabilité.


Ce qui est sûr, c'est que vous devriez faire front avec ton équipe pour ne pas laisser une chance à l'architecte de dire que c'est seulement votre faute.


Bonne chance à toi




Le 20/08/2023 à 18:36, Yannick Daniel Youalé a écrit :

Salut Quentin,

Merci, ton avis me touche beaucoup.

Je crois que je vais suivre ton conseil et plutôt que de m'adresser
directement à la direction, je vais plutôt me retourner vers mon
équipe pour en discuter, et voir ce qu'il en ressortira.
Pourquoi pas même saisir l'occasion d'une réunion avec l'architecte
attitré pour évoquer aussi pertinemment que possible le sujet.

J'ai lu un jour ce conseil d'une vieille personne: "L'homme
intelligent, c'est celui qui sait revenir au carrefour et prendre une
autre voie. L'orgueilleux et l'incrédule, lui, maintient sa
trajectoire même s'il aperçoit au loin un ravin."

Bon dimanche!

Yannick Daniel Youalé




Le 20/08/2023, QuentinC<progliste AT framalistes.org> a écrit :

Salut Yannick,


Je ne crois pas que ce soit la compexité de l'application en elle-même
le problème. Docker, le queue messaging, le cloud, l'architecture
microservice, ce sont toutes des choses qui commencent à être bien
connues et qui fonctionnent bien quand on les maîtrise. La performance
et la fiabilité de ces systèmes ne sont plus à prouver.


Par contre si dans votre équipe il n'y a personne qui maîtrise bien
telle ou telle technologie, s'il y a des "trous", effectivement, c'est
compliqué. Il y a tellement de choses que c'est difficile pour une seule
personne de tout savoir dans son ensemble dans les détails, et on ne
s'improvise évidemment pas architecte d'un jour à l'autre.


Je pense donc que le problème, c'est que votre équipe a une trop grande
marche à franchir entre ce qu'elle connaît et maîtrise bien
actuellement, et ce qui est demandé.


Pour maximiser ses chances de réussir, il faut introduire les nouveautés
progressivement et non pas les aborder toutes en même temps, et pour
introduire les nouveautés progressivement, il n'y a pas de miracle, il
faut se donner du temps pour les apprendre. Sinon effectivement, vouloir
tout faire en même temps, c'est le meilleur moyen de foncer dans le mur.


Au moment où vous avez reçu le projet et ses exigeance, il aurait très
certainement fallu en parler à vos supérieurs, et leur dire que ça
faisait trop d'un coup pour vous et/ou qu'il faudrait recruter tel ou
tel spécialiste pour vous aider à vous lancer. Ils devraient savoir
quelles sont les compétences de chacun, et donc plus ou moins savoir où
sont les trous, mais c'est aussi à vous de leur dire où sont vos limites
et ce que vous pouvez supporter.


Maintenant que vous avez accepté la mission, par contre, ça me parait
difficile de revenir en arrière sans que vous soyiez perçus comme des
incompétents. Plus le temps passe, plus ça sera difficile de discuter,
donc mieux vaut malgré tout quand même essayer sans trop tarder. Par
contre, il faut absolument que vous y alliez en équipe, ou en tout cas
une partie de l'équipe. N'y vas pas seul, sinon ça sera probablement toi
le con; du moins c'est comme tu le sens, si tu te sens prêt à affronter
la hiérarchie seul contre tous et qu'elle te fait assez confiance,
vas-y, mais moi j'aurais beaucoup de mal à le faire.


Dans le pire des cas, si tu en souffres et que tu es vraiment tout seul,
le mieux, c'est encore d'aller voir ailleurs... c'est triste, mais c'est
comme ça... laisse-les se casser la gueule tout seuls.


Voilà, ce n'est évidemment que mon avis tiré de seulement 6 ans de
boîte, d'autres auront sûrement des autres points de vue.


Dans tous les cas, bonne chance.














Le 20.08.2023 à 03:29, Yannick Daniel Youalé a écrit :

Salut à tous,

Je voudrais aujourd'hui venir vous soumettre une situation que je
rencontre en entreprise.

Il se trouve que la direction nous a ordonné, à l'équipe de
développeur à laquelle j'appartiens, de créer une application de
gestion d'évènements, qui est destinée à être proposée en SAAS à des
clients.

Dès lors, dans notre équipe, l'informaticien qui a reçu le rôle
d'architecte, nous a commandé les caractéristiques suivantes pour
cette nouvelle application:

* elle devra se subdiviser en micro-services.
Autrement dit en plusieurs sous-projets, hébergeable sur des serveurs
distincts, et communiquant entre eux par des requêtes dites queue.

* selon les sous-projets, nous pourront les faire en soit: laravel,
jango, ou même nextJS.
J'ai même entendu parlé de java, même si je crois que ce dernier a été
abandonné en fin de compte.

* La base de données devra être gérée en PostGreSQL, et sera hébergée
sur microsoft Azure.

* nous devrons employer docker pour gérer les déploiements et
redéploiements.

Moi, n'ayant jamais travaillé sur un projet aux envergures aussi
ambitieuses, j'ai dans un premier temps décidé de taire mes
rétissances, et de suivre le mouvement afin de voir comment les choses
évoluent.

Et, après un peu plus d'un mois de travail en équipe, nous en sommes
toujours à finaliser la première étapes de notre plan d'action, qui
est de faire fonctionner la communication entre les différents
micro-services.

Donc, plus d'un mois et demi après, nous n'avons pas encore commencé à
travailler véritablement sur le coeur de l'application que nous devons
construire, mais nous évertuons en réalité à employer notre énergie à
apprivoiser les différentes nouvelles technologies que nous devons
mettre en oeuvre.

Personnellement je ne trouve pas ça correct, et pense que le délai qui
a été donné à la direction de produire un MVP de l'appli de gestion
des évènements pour la fin du mois de novembre, ne sera pas atteint.
Tout ça est trop ambitieux pour une équipe de seulement trois
développeurs à temps plein.

Moi, je pense que si on avait commencé dès le départ à faire le plus
simple possible, c'est-à-dire un simple projet laravel, avec le type
de base de données MySQL fournie par défaut, nous serions à l'heure
actuelle beaucoup plus avancée.

Je ne renie pas le démembrement d'une telle application en
micro-services, ou l'emploi de technologies tierces comme PostGreSQL
ou docker, mais je pense que ce genre de sophistication doit se faire
à la fin du projet, lorsqu'on est sûr que le prototype ou coeur de
l'application fonctionne convenablement, et que l'on a de ce fait
donner des assurances à la direction de ce à quoi l'application
ressemblera et comment elle fonctionnera au final.

Ainsi, rendu donc à près de six semaines après le commencement
effectif de notre phase de développement, il me démange d'aller voir
la direction pour leur faire part de mon avis.

Mais j'hésite. Je me demande s'il n'est pas déjà trop tard.
Et ce serait probablement aussi perçu comme de la trahison par mon
équipe.

Equipe avec laquelle, j'ai bien essayé une ou deux fois de faire
allusion à ce que je pense vraiment, mais chez qui je n'ai pas senti
de volonté de véritablement remettre en question la direction vers
laquelle nous sommes en train d'aller.

Or, je sens bien de la part de la direction, une certaine impatience à
ce que ce projet avance.
Car, quand on entend dans une réunion des expressions de cette
direction comme: "est-ce que nous sommes en train d'aller quelque
part?", ou encore: "faites des efforts les gars", on comprend qu'il y
a un besoin pressant de voir plus de choses concrètes.

Qu'est-ce que vous en pensez?

Pensez-vous que je devrais aller voir la direction pour lui soumettre
mon idée de revenir à des choses plus simple et de se concentrer sur
le coeur de fonctionnement de l'application d'abord?

Avez-vous déjà vécu une telle situation?

Je vous remercie d'avance pour toute suggestion.

Yannick Daniel Youalé

--
LavaChri

---

• [progliste] application trop complexe dès le départ, Yannick Daniel Youalé, 20/08/2023
  • Re: [progliste] application trop complexe dès le départ, QuentinC, 20/08/2023
    • Re: [progliste] application trop complexe dès le départ, Yannick Daniel Youalé, 20/08/2023
      • Re: [progliste] application trop complexe dès le départ, LavaChri, 21/08/2023
        • Re: [progliste] application trop complexe dès le départ, Yannick Daniel Youalé, 21/08/2023

---

Archives gérées par MHonArc 2.6.19+.