Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Dans une petite structure 3 ou 6 mois de développements à mettre à la poubelle ça peut être fatal. Une grosse société a certainement plus de budget pour se sortir de ce genre de situation. Aussi une grosse société peut posséder de haut niveaux de hiérarchie et il est plus 'normal' que la toute haute direction ne soie pas au courant de l'évolution du projet au jours le jour.Envoyé par transgohan
Pourquoi cela serais-ce moins irresponsable pour une grande société ?
en fait c'est en effet un peu plus compliqué que cela, ce qu'il faut c'est que chacun joue son rôle. c'est une évidence mais c'est rarement le cas.
la direction peux très bien être moteur innovant avec des projets fous qui sont des projections vers ce que serait le projet idéal. Mais elle doit accepté que la réalisation soit plus réaliste ou moins ambitieuse que cela en fonction des compétences, de la charge de travail ou du temps accordé au projet. Mais dans ce cas c'est un société qui produit, et non une prestataire qui répond à la demande d'un client.
une direction exigeante qui pousse à l'excellence tout en reconnaissant la qualité et la compétence de ses développeurs et les respectant tant humainement que financièrement pourra probablement aller très loin.
En fait en relisant la news je me rends compte qu'elle est très mal rédigée:
l'introduction commence par "un projet doit se plier à des contraintes de coût, de délai et de respect des exigences définies par le cahier de charges[...]les meilleurs projets sont ceux qui arrivent à terme avec un écart relativement faible par rapport à ces critères." Ce qui balaie toute notion de relation humaine.
Finalement Partho ne parle ni de coût, ni de délai ni d'exigences du CdC mais au contraire invite à plus de considération et de réalisme
NB: je n'ai pas lu la source mais que l'article de DVP.
C'est ça que je voulais dire : l'implication d'une direction peut être positif - si il se limite aux compétences de ladite direction. La plupart des implications que j'ai vue étaient bien trop ciblées, et empêchaient les équipes de faire ce qu'il y avait à faire. Après, l'inverse est vrai aussi. Une direction qui abandonne ses équipes peut être fautive. Mais ça fait souvent moins de dégâts qu'un choix de technologie inspiré par un article des échos, sans considérations pour l'existant ou le savoir-faire des équipes.
Quels sont les facteurs qui pourraient compromettre la réussite d’un projet informatique ?
- Comme dit plus haut que le commercial ne vende pas des projets infaisable en terme de délais ...Quels sont les facteurs qui pourraient compromettre la réussite d’un projet informatique ?
- Comme l’analyse et les spécification en amont sont bâclées voir inexistante
Il y a le faire parce que c'est un besoin interne ou le faire parce que c'est une demande.
Dans ces deux cas, c'est le degrés de besoin qui régit. Ensuite la présentation du produit.
Les interfaces conformes aux cahiers des charges et intuitives tout en ayant des designs de qualités pour les milieux d'usages sont souvent les annonces de réussites.
Au niveau de l'implication de la direction dans le projet je crois que certain ne comprennent pas ce que Partho Bhattacharya veut dire.
Si votre direction vient vous mettre la pression ou changer les priorités de vos tâches ils montrent autant peut de respect pour vous et le projet qu'une direction totalement absente. Quand je parle de direction absente c'est la direction qui ne tient pas compte de vos retours, des vos demandes et de vos points bloquants. Qui s'implique veut dire qui répond aux besoin de l'équipe et du projet quand l'équipe a besoin d'elle.
Bien sur si tout se passe bien la direction n'a aucune raison d'intervenir. Mais si vous avez besoin de ressource elle doit intervenir. Elle ne peut pas dire "ah non on vous a dit qu’on vous faisait totalement confiance du coup vous réglez vos point bloquants tout seuls". Le fait que le direction soie présente et suive votre projet ne veut pas dire non plus qu'elle s'implique forcément. J'ai vu des direction très proche dans le suivit du projet mais incapable de prendre une décision avec responsabilité ou de se mouiller quand il le fallait.
Echec... Succès
Bref, à l'Est, rien de nouveau.
On raconte la même chose depuis plus de 30 ans et on fait toujours les mêmes constats, ce qui ravit les cabinets de conseil et les intégrateurs.
Maintenant, succès ou échec, tout dépend du point de vue. Un succès d'aujourd'hui sera un échec demain, et vice-versa.
Il serait certainement plus intéressant de s'intéresser aux raisons de fond, notamment d'un point de vue sociologique.
Mais tout le monde sait que sciences humaines et sociales (SHS) et finances ne font pas bon ménage
sujet intéressant.
C'est exact mais lorsqu'on se lance dans un projet informatique il faut vraiment savoir..où l'on va
Ecrit comme ça c'est une banalité, le faire c'est autre chose.
Démarrer un projet informatique c'est une entreprise relativement périlleuse parce qu'il faut souvent tout recréer et surtout bien comprendre les besoins clients,la partie au final la plus difficile.
Or le traitement de l'information l'informatique donc n'est pas forcément la panacée c.a.d que tout vouloir informatiser n'a pas toujours un sens.
Ensuite lorsque je mentionne le fait de tout recréer c'est que chaque projet informatique est différent en informatique de gestion.
Si on prend exemple sur un jeu vidéo commercial , le studio va capitaliser sur son savoir faire et il aura une idée assez précise de là où il veut aller.
Dans le cas d'un projet d'informatique de gestion le classique une entreprise A demande des prestations à une société de service B ( SSII ) de lui réaliser un projet informatique là c'est différent.
Il faut que la SSII B comprenne bien le métier du client A , effectue une analyse assez pointue...
Bref pour les chefs de projets et directeurs de projets qui vont me lire si je me permets quelque vision des chose ( après plusieurs années d'expérience ),pour réussir un projet
Ce qui risque de faire couler un projet c'est d'ajouter de manière incessante des fonctionnalités ce qui fait augmenter le coût.
Le gros problème du logiciel c'est que le client A il s'attend à avoir un clone de Google ou Microsoft Word , la majorité des logiciels sont faciles à utiliser.
Par contre ça cache une terrible complexité ( "code behind") et qui dit complexité dit coûts importants à engager.
bref il y en a beaucoup à écrire à ce sujet
c'est exact mais trop de hiérarchie c'est un aspect des choses qui risque de mener un projet à sa faillite
On le sait déjà tout ça.
c'est trop général. Du concret svp.
Que la direction sache que...
le SEUL truc qui marche c'est:
LAISSE FAIRE LE PROFESSIONNEL QUI SAIT !
Donc --> que la direction s'implique pour que tous les gêneurs, les emmerdeurs, les fouineurs, les sculpteurs de nuages soient tenus le plus loin possible de ceux qui bossent...
Et qu'une fois les specs bien définies, on s'y tienne !
Pour réussir le succès d'un projet je rajouterai: ne pas mélanger Why, What et How
Why: Pourquoi on veux ce projet?
Quel est le sens du projet?
Quel est le problème qui incite à réaliser ce projet?
Qu'est ce que cela doit rapporter au "client" demandeur?
What: Qu'est ce que l'on veux que le "système" (au sens large) face ?
Là, on va parler de fonctionnalité et de besoins utilisateurs.
Attention à bien identifier tout les utilisateurs (opérateur "neuneu", administrateur système qui déploie, commercial qui fait une démo, ...).
How: Comment on veux le faire?
Quel est l'équipe qui va le réaliser?
Quelles technologies on va utiliser?
Délai, suivi, feet-back avec les utilisateurs, ...
Le risque, dans un projet IT, et de mélanger le Why, What et le How
Imaginons un client exprimer un besoin du genre "je veux que la gestion de tel et tel truc via Oracle DB, me sorte un état, comme sur le logiciel Machin, via export Excel mais mieux pour que je puisse gagner plein de temps sur mon travail"
Visiblement, dans cette demande le why, c'est pouvoir gagner du temps sur une tache actuellement répétitive.
Le what n'est pas très clair (comme Machin), ce qui nous donne un grosse difficulté.
Et en plus le client impose le how (oracle + excel) sans étudier si ces technologie pourront au mieux correspondre au deux premier point.
Et parfois, en creusant, on s’aperçoit que notre client parle d'Excel, mais lui s'en fou: mais le logiciel Machin lui sortait un export Excel ce qui lui permettait de réalisé sa belle courbe des états avec les données.
Finalement, si on lui propose un affichage directement de la courbe des états ce sera encore mieux:
- Notre client gagnera encore plus de temps
- Le besoin est déjà plus claire (bien qu'il reste encore a affiner "comme Machin")
- La technologie sera choisi au mieux par l'équipe IT au mieux (pas d'Excel et pourquoi Oracle DB).
Autrement dit, impossible de changer d'avis ou de rectifier une trajectoire ????
Sur un mini projet de quelques semaines, ça va
Mais que fait on sur un projet de plusieurs mois ?
Que se passe t'il s'il y a des cas non prévus dans la spec ?
Il est indispensable d'éviter les effets tunnels car c'est le meilleurs moyen de "perdre" les utilisateurs et d'avoir une levée de boucliers lors de la livraison
Il est indispensable d'impliquer les utilisateurs que se soit à la qualif du besoin, à la conception, aux dev et à la recette
C'est ainsi qu'on les implique et qu'on obtient leur adhésion
Tu auras beau faire la plus merveilleuse des appli sur le plan IT, si les utilisateurs n'en veulent pas, elle finira dans un carton et ça sera un échec retentissant
Bien pire qu'une appli bugguée
Tu veux parler de "Accueillez positivement les changements de besoins, même tard dans le projet." (2ème principe - http://agilemanifesto.org/iso/fr/principles.html)
Il faudrait alors parler des besoins réels à des utilisateurs tout au long du développement de ton projet pour voir s'ils évoluent.
Et puis, ça voudrait dire avoir du feed-back de leur part sur ce que tu fais et donc leur proposer régulièrement une "version de démo".
Mais qui dit proposer une telle version, voudrait dire d'avoir régulièrement un produit qui marche, qui est fonctionnel, qui est testé ...
Attention, on est à deux doigts de basculer dans le monde de l'Agilité
Tu m'as percé à jourTu veux parler de "Accueillez positivement les changements de besoins, même tard dans le projet." (2ème principe - http://agilemanifesto.org/iso/fr/principles.html)
Il faudrait alors parler des besoins réels à des utilisateurs tout au long du développement de ton projet pour voir s'ils évoluent.
Et puis, ça voudrait dire avoir du feed-back de leur part sur ce que tu fais et donc leur proposer régulièrement une "version de démo".
Mais qui dit proposer une telle version, voudrait dire d'avoir régulièrement un produit qui marche, qui est fonctionnel, qui est testé ...
Attention, on est à deux doigts de basculer dans le monde de l'Agilité
Moi qui pensais avancer masquer
Ca fait maintenant longtemps que je déploie des réseaux et mon expérience me permet de conclure que tout pendant que :
- le big boss s'amuse avec PowerPoint,en théorie, chacun est à sa place et les choses restent potentiellement contrôlables
- le Directeur de projets avec Excel,
- les Chefs de Projets avec Word,
- les Ingés avec Visio et Notepad,
Il suffit de reprendre les 4 assertions plus haut et mélanger un peu les cartes
Par exemple, lorsque :
- le boss commence à manipuler des spreadsheet Excel,
- les Ingés font du PowerPoint,
- les Chefs de Projets commencent à faire des copier/coller dans Notepad pour rectifier des scripts de config
généralement, ça part à la catastrophe.
Je vous invite à essayer d'autres combinaisons, je suis sûr que vous en trouverez au moins une qui vous rappellera des choses
Bon, vous avez compris, le succès d'un projet IT, c'est déjà que les bonnes personnes soient à la bonne place. Notamment, quand je dis "bonnes personnes", ça sous-entend la compétence et l'expertise attendues pour l'objectif du projet. Inutile de m'étendre davantage sur cet aspect du succès d'un projet IT.
Le 2ème point-clé dans un projet, c'est la communication.
Si pas de communication, pas de fil conducteur. Et sans fil conducteur, difficile de mobiliser et de coordonner des "îlots isolés".
Ca doit aller du haut vers le bas et ça doit être continu dans le temps. J'ai horreur des Boss/Directeur/Chefs de Projets qui essaient de passer pour des super Boss/Directeur/Chefs de Projets le vendredi entre 14 et 18h au moment du comité de pilotage hebdomadaire, surtout quand t'arrives pas à leur faire prendre une décision entre lundi et jeudi
Et la communication, c'est pas que des mails... Perso, et c'est peut-être lié à mon ADN de souche bretonne et vendéenne, j'aime bien célébrer les "quick wins"
Et là, j'avoue, je suis comme un gamin
Dès que j'arrive à pinguer un truc qui se trouve dans un autre fuseau horaire, même si c'est une simple machine à café, je dis, "woua, mais c'est un pas de géant qu'on a fait là, ça mérite bien quelques bières", et puis on va célébrer ça dans le troquet du coin en sortant du bureau. Je suis très sensible à la reconnaissance parce que c'est quelque chose qui se perd, il faut donc instaurer ces moments de communion entre techos
Bon, j'y vais, j'ai un copil dans une demi-heure et j'ai pas fini ce f*****g dashboard qu'on m'a imposé et que je suis le seul à comprendre
Steph
Réussite d'un projet IT
Pour la majorité des propos, je suis d'accord, de plus il y a un autre facteur qui est l'audite des procédures et leurs l'égalité, pour ne pas avoir a tout refaire. Un projet réussi c'est un projet qui ne pose pas des problèmes lors de sa mise en production que se soit technique, procédural ou législatif.
Répondre avec citation
Partager