Problèmatiques de la Gestion de Projet Décisionnel

MVP Data Platform - Fan inconditionnel de la coopérative INSIDERS.COOP,j'ai hâte de partager mes expériences avec vous !

14 Comments

  1. Djeepy1

    Je te rassure Charly, ce problème n’est pas que dans le décisionnel mais dans beaucoup de projets.
    Tu as bien identifié quelques « pistes » mais personnellement, je pointerai le problème des compétences comme un point important.
    En BI, on trouve énormément de « techniciens ». Rien de péjoratif là dedans mais on a des ressources qui savent faire exactement ce qu’on leur dit…et pas plus. Il est difficile donc de sortir du cadre, anticiper, gérer, amender, etc. correctement un « projet » BI.

    PS : oublie la « tendance idéale » à-la SCRUM dans un projet BI; l’important c’est les utilisateurs et leur adoption (à combiner avec le wow-effect)
    Ca rejoint ce que tu dis sur l’architecture et la gestion de projet mais ma conviction est que ce ne sont pas des rôles réservés… Une personne bien câblée saura prendre ces activités naturellement car il faut juste être pragmatique, organisé, ingénieux et savoir traiter (parler, comprendre, convaincre) avec des utilisateurs.

    Re-PS : On se fait un Afterwork sur le sujet ?

  2. scharly3

    Hello Djeepy,
    Tu dis ça parce que tu projettes ton cas personnel de warior de la B.I. sur toutes ses facettes (Dev, Gestion de projet, R&D, …), Hors parfois des personnes tout à fait bien cablées n’ont juste pas envie de prendre en charge ces tâches qui ne les interessent tout simplement pas, ne penses-tu pas ?

    Un afterwork sur ce sujet me semble une excellente idée !

  3. Djeepy1

    On ne fait pas toujours ce qu’on veut dans la vie et l’inverse est vrai.
    S’il n’y a pas de leadership sur le projet, il doit être pris par quelqu’un et comme il y a pénurie en la matière, ce sera peut-être la personne qui est « en capacité de » mais qui n’aura pas forcément envie.

  4. Fleid

    Charly je ne suis pas certain de bien cerner ton argument.
    Tu dis qu’en BI on a besoin de plus de gestion de projet que pour les autres domaines du développement, et que ça manque? Mais ça manque parce que les clients ne veulent pas acheter ce genre de prestation, ou parce que les consultants ne sont pas formés, ou pour une autre raison?

      1. Fleid

        Alors je suis un peu comme JP sur le fait que cela ne soit spécifique au décisionnel. Ok nos clients sont en général plus exigeants (métiers, VIP), mais en dehors de ça ce sont les mêmes débats pour tous les projets informatiques.

        Et si je peux me permettre, méfie du toi du filtre d’être dans une société reconnue sur son expertise technique, dans une équipe constituée des meilleurs experts techniques, alimentée par un pipeline où très souvent les problèmatiques sont techniques, pour ensuite venir dire que tu constates des lacunes dans la gestion de projet autour de toi 😉

        Là où par contre je te rejoins à 100%, c’est sur le fait qu’en décisionnel, et en particulier en décisionnel Microsoft, on en est vraiment à l’age de pierre en terme de méthodologie clef en main. On est des tanches en patterns et industrialisation des développements, livraison continue ou tests automatisés. A nous de nous améliorer sur le sujet: on se fait une session Agilité aux prochains JSS? 🙂

  5. Fabrice

    Je rejoins tout à fait Florian sur le constat suivant :
    Côté méthodologie et testing, en BI nous en sommes encore à l’age de pierre sur la stack MS…

    Alors évidement les consultants doivent se remettre en cause, sur la partie gestion de projet…. mais comment parler d’agilité si le tooling n’existe pas? Et c’est la que le bas blesse :
    Qui peut me citer un serveur d’intégration continue qui permet de déployer des DTSX, du XMLA?
    Y a-t-il un framework qui permet de faire des tests unitaires sur les règles métiers implémentées dans vos proc strock (c’est le mal), vos dtsx, votre MDX????
    Connaissez vous des outils de test d’intégrations qui valident un dev de bout en bout (ex : de la lecture d’un fichier csv au browsing d’une dimension procésée).

    Alors comment en vouloir aux consultants ou aux chefs de projet, s’il n’existe pas de tooling qui permet de les accompagner sur les aspects d’agilité ??? Tout faire à la main par script sql, commandlet powershell etc…., c’est faisable…. mais c’est long, et donc non applicable sur de petit projet.

    Charles Henri parlait également de volumétrie ralentissant les cycles de dev en BI; Effectivement si l’on est obligé de traiter à chaque petite évolution des gigas de données, on a tendance à passer notre temps a attendre que la machine ai finit de travailler…. on l’a tous vécu; ça à l’avantage de nous laisser le temps d’aller prendre des cafés ou fumer des clopes…. mais bon niveau productivité, une nouvelle feature par jour quand tout va bien, c’est pas le top…
    Et pourtant la solution existe, adaptons le concept des mock [ http://fr.wikipedia.org/wiki/Mock_(programmation_orient%C3%A9e_objet) ] pour abstraire les dépendances de chaque composant que l’on développé. Ex : Pour constituer, une dimension nous avons besoin d’un table dans le DataWarehouse. Un Mock de table de dimension peut-être, tout simplement une autre table, une fonction, une vue qui ne ramène que 10 lignes. Amélioration du temps de process garanti.

    Vous l’aurez compris, je défend ardemment l’idée que l’amélioration de la qualité de notre travaille, que notre agilité ne peut venir que par l’émergence d’un toolset intégré à notre IDE Visual Studio; Et je viendrais la défendre lors de l’afterwork du 17.

    1. Sauget Charles-Henri

      Absolument d’accord avec toi, j’ai pas détaillé ce point (certainement à tord) mais c’est en effet très important d’avancer aussi sur les méthodes de tests !

Leave a Reply to Fabrice Cancel Reply

Your email address will not be published. Required fields are marked *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.