Chronologique Discussions  

< Chronologique >       < Discussions >

---

Coucou Lavachri,

Merci pour ta réponse.

En fait, l'architecte est en réalité un ancien employé à temps plein,
qui travaille aujourd'hui dans une très grosse boite.

Et comme tu dis, c'est peut-être ce fait qui lui joue des tours.
Il nous voit peut-être aussi comme une grosse boite, qui doit
appliquer des méthodes de grosses boites.

Et effectivement, sa disponibilité est plus que parcimonieuse.



Yannick Daniel Youalé




Le 21/08/2023, LavaChri<progliste AT framalistes.org> a écrit :
> 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+.