internal
/
itsonus-blog
4
0
Fork 0
Code Issues 7 Pull Requests Releases Activity

feat: correction article

pull/13/head
margauxEscande 2023-01-05 14:35:33 +00:00
parent 82a6d3751e
commit 7956b5f392
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/_pages/blog/article/ecoconception_et_datawarehousing.md
View File

@ -13,7 +13,7 @@ draft: true
layout: article.njk layout: article.njk
--- ---
*Pour y répondre, nous avons interviewé Damien Marzlin, membre du collectif IT's on us. Damien est architecte d'entreprise, il accompagne les organisations dans la réduction des impacts environnementaux du numérique et forme à l'écoconception de services numériques. Il est actuellement en mission chez Auchan.* *Pour y répondre, nous avons interviewé Damien Marzlin, membre du collectif IT's on us. Damien est architecte d'entreprise, il accompagne les organisations dans la réduction des impacts environnementaux du numérique et forme à l'écoconception de services numériques.*
## Pour commencer Damien, peux-tu nous expliquer ce qu'est la datawarehouse ? ## Pour commencer Damien, peux-tu nous expliquer ce qu'est la datawarehouse ?
@ -36,7 +36,7 @@ Ces applications peuvent et je dirais même doivent être écoconçues.
La datawarehouse produit des reporting, des kpis ... qui vont être utilisés par des gens. Il est important de questionner le besoin. Comme pour tous les projets informatiques, il faut donc s'assurer que ce qui est produit répond à un réel besoin utilisateur. La datawarehouse produit des reporting, des kpis ... qui vont être utilisés par des gens. Il est important de questionner le besoin. Comme pour tous les projets informatiques, il faut donc s'assurer que ce qui est produit répond à un réel besoin utilisateur.
Bien souvent, je constate lors dans mes missions, que ce qui est produit n'est pas utile pour les équipes. Soit parce que dès le départ le projet est mal cadré, soit parce que le projet a pris trop de temps et l'information n'est plus nécessaire. Parfois aussi, on produit des rapports journalier alors qu'un rapport hebdomadaire aurait suffit. Bien souvent, je constate lors dans mes missions, que ce qui est produit n'est pas utile pour les équipes. Soit parce que dès le départ le projet est mal cadré, soit parce que le projet a pris trop de temps et l'information n'est plus nécessaire. Parfois aussi, on produit des rapports journaliers alors qu'un rapport hebdomadaire aurait suffit.
**Correctement requêter** **Correctement requêter**
@ -48,8 +48,8 @@ De plus, comme nous perdons la maîtrise de ce qui est fait par ces différents
## Comment éviter la dérive ? ## Comment éviter la dérive ?
**Un projet de datawarehousing, n'est pas un projet technique, il faut intégrer dans l'équipe, et dès le début, une personne responsable de l’expérience utilisateur.** Son rôle sera de comprendre ce que vivent les utilisateurs (via des interviews, de l'observation par exemple) et d'identifier la problématique à laquelle il faut répondre. Simplement demander le besoin des utilisateurs peut mener à un projet qui finalement ne sera pas utile. **Un projet de datawarehousing, n'est pas qu'un projet technique, il faut intégrer dans l'équipe, et dès le début, une personne responsable de l’expérience utilisateur.** Son rôle sera de comprendre ce que vivent les utilisateurs (via des interviews, de l'observation par exemple) et d'identifier la problématique à laquelle il faut répondre. Simplement demander le besoin des utilisateurs peut mener à un projet qui finalement ne sera pas utile.
Si le projet est terminé, ce qui a été produit lui doit continuer à vivre. Il faut donc penser à mettre en place des points de contrôle après la mise en production, pour s'assurer de l'utilité réelle. Vous pouvez-vous appuyer sur les équipes support de l'utilisation du datawarehouse. Quels sont les échanges qu'ils ont avec les utilisateurs, sont-ils satisfaits ou non ? Vous pouvez également aller sur le terrain pour échanger et observer l'usage qui est fait ou encore envoyer une enquête de satisfaction à intervalle régulier. Si le projet est terminé, ce qui a été produit lui doit continuer à vivre. Il faut donc penser à mettre en place des points de contrôle après la mise en production, pour s'assurer de l'utilité réelle. Vous pouvez vous appuyer sur les équipes support de l'utilisation du datawarehouse. Quels sont les échanges qu'ils ont avec les utilisateurs, sont-ils satisfaits ou non ? Vous pouvez également aller sur le terrain pour échanger et observer l'usage qui est fait ou encore envoyer une enquête de satisfaction à intervalle régulier.
Un autre point clés c'est d’**avoir un spécialiste en modélisation de données et en requêtage et de la faire intervenir le plus tôt possible.** C'est un savoir qui se perd, car cela attire moins les développeurs et développeuses, il est important d'entretenir cette compétence. Si ce profil n'existe pas dans votre équipe, rien que le fait de faire des revues de code peut déjà apporter des bénéfices. Dans une équipe agile, on peut, par exemple, ajouter à la Definition Of Done (DOD) un critère comme "les requêtes SQL ne font pas de produit cartésien" ou encore "la manipulation de données parait nominale". Finalement, on parle ici de qualité de code. Un autre point clés c'est d’**avoir un spécialiste en modélisation de données et en requêtage et de la faire intervenir le plus tôt possible.** C'est un savoir qui se perd, car cela attire moins les développeurs et développeuses, il est important d'entretenir cette compétence. Si ce profil n'existe pas dans votre équipe, rien que le fait de faire des revues de code peut déjà apporter des bénéfices. Dans une équipe agile, on peut, par exemple, ajouter à la Definition Of Done (DOD) un critère comme "les requêtes SQL ne font pas de produit cartésien" ou encore "la manipulation de données parait nominale". Finalement, on parle ici de qualité de code.