Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

projet

  • Evaluer son projet

    Principe : "On ne peut gérer que ce qui se mesure."

    projet1.jpgIl y a quelques semaines je vous parlais du Kanban sur lequel j'affiche des "fiches projets". Ces fiches projets d'une format A4, se veulent synthétiques et résumer pour tous les acteurs du projet l'objectif. Elle se compose de plusieurs paragraphes :

    • Les contacts (emails et téléphones)
    • Le résumé du projet (concept)
    • Les users story (développements spécifiques)

    J'ai organisé la fiche projet en 3 étapes :

    1. Avant le projet : la période de "conception" qui récolte toutes les données (maquettes graphique, ...)
    2. Pendant le projet : la période d'intégration et développement pour le montage du projet
    3. Après le projet : récolte du feedback

    La fiche projet n'est jamais figée. Elle est remplie au fur et à mesure en fonction des nouveaux éléments.

    Les temps d'intégration sont conciliés sur cette fiche ce qui permet de calculer le ROI de chaque projet. Depuis 2 mois que j'ai installé ce système (20 projets environs), il me permet de consulter l'historique pour évaluer les temps d'un nouveau projet par similarité.

    Au final, il devient possible de mettre en évidence l'équilibre Coût / Délais / Qualité / Satisfaction-client.

    D'ici quelques semaines, à la lumière de notre tableau papier, nous pourront développer un ERP sur mesure.

  • Ca se passe de commentaire

    gestion-projet-web-humour.gif

    C'est comme cela que ça se passe chez ... tout le monde !

  • L'histoire du con qui dit "non"

    Dominique84124605287775_gros.jpg

    - Vous connaissez l'histoire du con qui dit "non" ?

    - Non !

    Et voilà le piège s'est refermé.

    Attention : l'humour de cette introduction est là pour présenter le côté délicat de certaine situation de gestion de projet pour lequel il est nécessaire de flairer le chausse trappe... pour ne pas passer pour un con. Quant à l'illustration, j'aime beaucoup Geluck et son chat !

    En tand que fournisseur de service web, vous avez déjà travaillé comme prestataire d'une webagency elle-même missionnée par une agence de communication sous-traitante d'une agence de relation publique qui répond à l'appel d'offre du client final ?

    Ca aussi c'est un peu une histoire à la con, mais quand on gère un tel projet, il y a plusieurs dificultés :

    1. L'accès au besoin du client final est difficile. Au moins un des acteurs de la chaîne doit trancher pour le client car il a pas l'info, ou qu'elle n'est pas remontée jusqu'à lui. Bref la communication avec autant d'intervenants c'est pas simple.
    2. Le client remonte des infos, mais il a l'impression de ne pas être entendu. Le prestataire final ne reçoit aucun signal, il a l'impression d'avoir des fourmies dans les jambes, juqu'à ce que le client se mette à râler à force de ne pas se faire entendre.
    3. Il est difficile de voir le périmètre de la webagency et celui du prestataire, fournisseur de service. En général, le fournisseur de service réalise peu de travaux spécifiques mais est tributaire de la réalisation de la webagency qui elle s'occupe du projet spécifique. Si la webagency ou le fournisseur de service se "plante", le client ne sera pas content.
    4. C'est un projet qui prendra plus de temps qu'un projet où le client est en contact direct. La récolte des "entrées" nécessaires au démarage du projet doit passer et être validée par toutes les mains. Les conf call avec la webagency qui ne maîtrise pas le produit que vous commercialisez gaspillera du temps à l'équipe technique qui devra assurer le débug de l'application de la webagncy.
    5. Si un maillon de la chaine coule, c'est tout le monde qui plonge, chacun rejetant la faute sur l'autre.

    Pour maîtriser un tel projet :

    1. Essayer d'avoir accès à un contact chez le client final pour recueillir son sentiment tout au long de la mise en place du projet.
    2. Travailler avec une webagency avec qui on a déjà travaillé est un plus. On a pas toujours le choix, mais parfois il peut être orienté par "copinage", pourquoi s'en privé.
    3. Une attention partculière doit être fourni par le chef de projet qui doit analyser le moindre signal. Un chef de projet sénior n'est pas un luxe.
    4. Le prestataire de service maîtrisant son produit se doit d'apporter un conseil en intégration irréprochable auprès de la webagency. Mieux vaut se froisser avec l'équipe technique de votre partenaire, en la bousculant un peu, plutôt que gérer un client mécontent. Mais il faut être filou pour ne pas se faire taxer d'ingérence !
    5. Une documentation complète, des procédures claires et un formalisme rigoureux assureront vos arrières ! En pratique, valider les conf call par un compte rendu envoyé par mail ou la rédaction d'un rétroplanning avec les éléments attendus montrera que vous maîtrisez le projet et les délais, que vous êtes sérieux et irréprochable.

    Ne le regrettons pas, ce sont ces situations périlleuses qui font la joies de l'entreprise et du web !

  • La solution à bascule

    shadok-probleme-solution.jpgCette solution, je l'ai déjà un peu abordé. Vous savez, la solution a bascule, c'est la fausse bonne solution, celle dont on croit que l'on penche d'un côté alors qu'un petit vous a fait basculer de l'autre côté.

    Exemple :

    Vous avez développé votre service web et avez besoin de mettre en place une solution d'authentification centralisée car d'autres clients utilisent votre service. Comme votre projet doit être livré hier (ce n'est pas une faute de français), vous montez en vitesse une solution opensource qui existe et pas trop mal documenté. Vous tombez sur SAML avec un truc tout fait en java, alors que le reste est en PHP, mais bon, c'est déjà fait alors vous croyez gagner du temps. Mais là, catastrophe, c'est trop lourd, mal adapté, vos clients galèrent pour mettre en place votre système ... Alors vous décidez d'assouplir quelques règles de sécurité, ou "bidouiller" dans le coeur de l'outil pour simplifier ce que vous n'avez pas le temps de comprendre.

    C'est un exemple flagrant où détourner un outil ou un soft qui n'est pas prévu pour être utilisé comme on a l'intention de le faire répond toujours de manière bancale au besoin. Ça vous le saviez déjà car je vous l'avais dit !

    Mais alors comment s'en sortir car on a tous envie de ne pas réinventer la roue à chaque fois. J'ai deux exemples qui me viennent naturellement en tête qui soutiennent activement des projets open source en participant à leur développement.

    1°) Synfony reprend Swift Mailer et intègre des éléments développés pour dailymotion dans sa version 2.0.

    On pourrait dire que l'on a à faire à du partage de connaissances Open Source. Finalement là où les compétences sont rares, se serrer les coudes en mutualisant ses développements peut être d'un vrai intérêt. Pour éviter l'écatombe de l'exemple précedent, Synfony a décidé d'adosser synfony sur un autre projet tel que Swift Mailer, Doctrine, ... Il intègre la communauté de développeurs légèrement démotivé (sic), devient maître de la road map sans tout redévelopper de zéro. Belle opération pour la communauté.

    2°) CNet développe le moteur de recherche Sol'R

    CNet a choisi Lucene / Sol'R et enrichi le projet Open Source de moteur de recherche Sol'R pour en faire un des meilleurs ! Sa technologie de "facet" permet de faire des affinages par fitre, ...

    3°) J'étais récement en contact avec une entreprise qui utilise aujourd'hui Piwik comme solution de statistique web via des API. Le problème, c'est que passé un certain trafic, Piwik ne tient pas la charge. Plusieurs hypothèses :

    • Développer son propre outil, mais ce peut-etre long.
    • Utiliser un autre outil, mais cela peut couter chère.
    • Contribuer / investir dans un projet open source.

     

  • Nouveaux projets

    Pour la plupart des projets web informatiques, les développements sont relativement courts, par contre le "client" (ou client interne) veut voir rapidement le résultat.

    Voilà le tableau d'un nouveau projet classique qui tourne mal :

    • Un besoin pas clairement défini, par exemple, parce que le chef de produit inclus des supposés difficultés techniques.
    • Un déficite de spécifications fonctionnels parce que le délais est serré.
    • Des spécifications technique à côté du besoin.
    • Le développeur est livré à lui même et développe ce qu'il à compris du projet.
    • On s'aperçoit que ce n'est pas ce que veut le client et les développements deviennent un puits sans fond.
    • Comme le temps passe, le chef de produit propose de couper des étapes de développements non fonctionnelles (tests unitaires, qualité)

    Voilà le contre exemple de ce qu'il faut faire. Les délais ne sont pas respectés, la qualité n'est pas au rendez-vous, la maintenance sera délicate, ...

    Si lutter contre le manque "matériel" (spécifications, ...) est aisé, il est beaucoup plus difficile de lutter contre les penchants humains (brouillon, hyperactivité, ...).