IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Actualités Discussion :

Comment garantir le succès d’un projet IT

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 875
    Points : 86 930
    Points
    86 930
    Billets dans le blog
    2
    Par défaut Comment garantir le succès d’un projet IT
    Comment garantir le succès d’un projet IT
    Top 5 des raisons pour lesquelles les projets informatiques échouent

    Il est plus facile de démarrer un projet informatique, mais garantir son succès est une chose moins évidente. Pour réussir, 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. Dans la pratique, il est difficile de voir un projet respecter ces 3 critères, et les meilleurs projets sont ceux qui arrivent à terme avec un écart relativement faible par rapport à ces critères.

    Plusieurs études menées sur la réussite des projets informatiques montrent en effet que dans la majorité des cas, les projets aboutissent avec un non-respect des charges ou des délais. On note également que parfois, plus de 20% des projets sont abandonnés.

    Les raisons qui justifient ces taux d’échec sont multiples et peuvent dépendre des ressources financières de l’entreprise, de l’implication des employés, des compétences déployées sur le projet et bien d’autres.

    Partho Bhattacharya, président d’Invenio Business Solutions a expliqué les 5 principales raisons pour lesquelles les projets IT échouent selon sa propre expérience au sein de son entreprise. Invenio Business Solutions un Gold Partner de SAP qui fournit des solutions, des services et un support SAP aux entreprises.

    Selon Partho, le principal facteur de succès ou d’échec d’un projet est l’implication de la haute direction. Il fait partie de ceux qui partagent l’avis selon lequel « il n’y a pas de projets informatiques, mais seulement des projets d’entreprise ». autrement dit, les projets IT doivent impliquer et rassembler l’entreprise dans son ensemble et pas seulement le service informatique. La haute direction qui doit avoir un intérêt particulier dans la réussite du projet doit veiller à cela.

    Il est donc important, avant tout, de faire une cartographie des personnes qui sont impliquées dans le processus et de s’assurer qu’elles en fassent partie depuis le début et que leurs besoins et fonctions ont bien été considérés.

    Une autre raison qui mine les projets IT serait la mauvaise planification. Partho note que très souvent, les calendriers manquent de réalisme. Les responsables doivent définir des délais plus réalistes dès le départ et éviter de se précipiter dans les projets.

    Il explique encore qu’un projet a des chances d’échouer si les données et l’interface avec le système sont ignorées dès le départ. Les données des systèmes en place sont souvent incohérentes et incomplètes et rendent parfois le système inutilisable. Ce problème doit être avant tout traité par le nettoyage des données qui est susceptible de prendre beaucoup de temps dans la réalisation du projet. Les interfaces, qui constituent les points de contact avec le système doivent être également testées, car une interface défectueuse peut mettre en mal une bonne implémentation du système.

    Un autre facteur d’échec ou de succès, non des moindres, est la gestion du projet, les compétences et expériences. Partho explique qu’un de chef de projet approprié et le soutien de l’équipe PMO sont primordiaux pour le succès du projet. Il faut également éviter trop de gestionnaires au risque de créer des conflits et priorités contradictoires. Ces derniers doivent encore avoir de très bonnes compétences, être capables de réunir la bonne équipe de personnes qualifiées et également être en mesure de les motiver et inspirer même quand la pression monte.

    Le président d’Invenio Business Solutions note par-dessus tout qu’on doit maintenir le projet réel. Par cela, il explique que lors de la planification et du déploiement, certaines attentes autour de ce qui doit être livré, quand, par qui et pourquoi, sont irréalistes. Il y a des exigences confuses ou changeantes tout au long du processus. Partho pense qu’elles doivent plutôt être fixées et les objectifs réévalués au cours du projet pour éviter les surprises. Pour cela, le choix du partenaire est vraiment crucial. Ce dernier doit être en mesure d’accompagner l’entreprise dans tout le processus afin d’assurer le succès du projet.


    Source

    Et vous ?

    Qu’en pensez-vous ?

    Quels sont les facteurs qui pourraient compromettre la réussite d’un projet informatique ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Monsieur est, pour le moins, un enfonceur de portes ouvertes.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  3. #3
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Une autre raison qui mine les projets IT serait la mauvaise planification. Partho note que très souvent, les calendriers manquent de réalisme. Les responsables doivent définir des délais plus réalistes dès le départ et éviter de se précipiter dans les projets.
    Client : Une réduction de xxxM€ ? Uniquement si vous nous livrez pour hier.
    Commercial : Marché conclu !


    Faut pas penser qu'aux responsables, les commerciaux sont souvent en première ligne pour ce genre de c*nneries...

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  4. #4
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    Novembre 2002
    Messages
    8 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2002
    Messages : 8 964
    Points : 28 430
    Points
    28 430
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Qu’en pensez-vous ?
    je pense que plus d'un projet aurait été un succès logiciel si la direction avait moins mis son nez dedans.

    https://youtu.be/BKorP55Aqvg

    Citation Envoyé par Michael Guilloux Voir le message
    Quels sont les facteurs qui pourraient compromettre la réussite d’un projet informatique ?
    tout dépend du point de vue. Pour le développeur, on peux très bien mesurer le succès d'un projet au nombre de zéros sur la facture, du point de vue client c'est plutôt l'inverse

    Après, dire que quand tout le monde y mets du siens, le projet a plus de change d'aboutir, faut pas être président de quoi que ce soit pour s'en rendre compte.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  5. #5
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    Avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 476
    Points : 4 805
    Points
    4 805
    Billets dans le blog
    6
    Par défaut
    le coup des specs changeantes c'est la principale raison d’échec
    et le plus souvent c'est à cause du commercial qui n'est pas fichus de situer le besoin
    Rien, je n'ai plus rien de pertinent à ajouter

  6. #6
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    Novembre 2002
    Messages
    8 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2002
    Messages : 8 964
    Points : 28 430
    Points
    28 430
    Par défaut
    Citation Envoyé par TiranusKBX Voir le message
    le coup des specs changeantes c'est la principale raison d’échec
    et le plus souvent c'est à cause du commercial qui n'est pas fichus de situer le besoin
    ce n'est pas son rôle.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  7. #7
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    Avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 476
    Points : 4 805
    Points
    4 805
    Billets dans le blog
    6
    Par défaut
    c'est lui qui vend le service il est censé savoir si c'est possible ou non à faire
    Rien, je n'ai plus rien de pertinent à ajouter

  8. #8
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Paul TOTH Voir le message
    je pense que plus d'un projet aurait été un succès logiciel si la direction avait moins mis son nez dedans.
    (.../...)
    Mon expérience personnelle va dans ce sens-là. La meilleure direction, c'est celle qui dit "bon, c'est important, demerdez-vous pour que ça marche", et qui vient vérifier tous les 3 mois qu'on avance.

    Après, évidemment, je suis un échantillon limité. Mais quelques exemples vécus :

    _Un remplacement complet de SI, en passant du COBOL à JAVA, parce que c'est moderne. 100M$ foutus à la benne parce que les traitements comptables de fin d'année mettent une semaine à tourner. Sur 5% de la clientèle.
    _Un remplacement complet de gestion des référentiels tiers. Projet à 60 personnes et prévu sur 18 mois. Les specs ont deux ans d'âge, et sont devenues fausses. 6 ans de retard parce que le vice-président(coté client) qui a signé les specs refuse de se dédire. Soit ça marche, mais ce n'est pas conforme, soit c'est conforme, mais ça ne marche pas. Et un redémarrage sur de nouvelles bases au bout de 6 ans.
    _Une refonte complète des courriers envoyés au client. La direction fait savoir que c'est prioritaire. Les prestataires(moi et un quasi-débutant) sommes lâchés avec pour seule consigne de "faire comme l'existant, mais en lisible et maintenable". Au milieu du projet, je m'aperçois que j'ai fait fausse route. Je ne sais pas faire de tests unitaires. "Je dois créer un comparateur avec l'ancien système, pour vérifier que tout est bon. Y'en a pour 4-5 semaines, facile". Réponse : "gloups, bon, ben si il le faut... La direction insiste sur la date de livraison, tiens-en compte". Il m'a fallu 6 semaines, mais à la fin, les tests unitaires étaient aussi terminés. Sur 170 jours de planifiés, un total de 172 de consommés. Livré le jour prévu. Zéro anomalies lors de la mise en prod, un cout de maintenance divisé par deux par rapport à l'ancien système.
    _Plus anecdotique,
    "_el-slapper on a un problème. Il y a un programme qu'on a oublié de faire. On avait budgetisé 10 jours. Tu en as deux."
    "_C'est quoi?"
    "_Passer les 18 flux du nouveau format vers l'ancien format. C'est pour les DOMTOM - leur SI est indépendant. Tiens, regarde les specs."
    "_mmmmh, les 18 flux se ressemblent beaucoup..."
    "_Bon, si on a juste Bourse France, Bourse étrangère, et OPCVM, on fera avec, les 15 autres peuvent attendre."
    "_Vu les specs, faire 3 flux en 2 jours, je n'y arriverais pas. Mais faire une moulinette qui me fait les 18 en dynamique, je peux faire.
    "_Glps....Euh, tu est sur de ton coup?"
    "_on y arrivera pas autrement"

    Et ça a marché. Si il avait insisté pour que je fasse les flux un par un, j'y serais encore. En plus, vu que les specs elles aussi avaient été faites en catastrophe(mais avec une structure impeccable, ce qui m'a sauvé), elles étaient pleines d'erreurs, et il valait mieux que j'ai à faire les corrections à un seul endroit, plutôt qu'à 18...



    Après, un bon chef sait donner aux gens les moyens de bosser. J'ai connu une DP, par ailleurs très moyenne(elle ne connaissait que COBOL, et ne comprenait pas pourquoi les JAVAistes avaient besoin d'un accès à internet, genre "vous ne connaissez pas votre langage"), qui a remué ciel et terre pour nous avoir des environnements de tests fonctionnels. On a perdu 3 semaines, mais sans elle, c'était 3 mois. Sur un projet de 6 mois. C'est le bon niveau d'intervention. Apprendre aux JAVAistes comment programmer sans internet, c'est idiot. C'est beaucoup trop terre-à-terre pour quelqu'un à son niveau(et, de toutes façons, c'est idiot). Fouetter l'équipe qui avait vraqué les environnements, par contre, c'était son job.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #9
    lpa
    lpa est déconnecté
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Août 2004
    Messages
    39
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 39
    Points : 54
    Points
    54
    Par défaut Quels sont les facteurs qui pourraient compromettre la réussite d’un projet informatique ?
    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 ...

    - Comme l’analyse et les spécification en amont sont bâclées voir inexistante

  10. #10
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    Citation Envoyé par transgohan Voir le message
    Client : Une réduction de xxxM€ ? Uniquement si vous nous livrez pour hier.
    Commercial : Marché conclu !


    Faut pas penser qu'aux responsables, les commerciaux sont souvent en première ligne pour ce genre de c*nneries...
    D'où la notion ridicule de "rétro-planning". Un rétro-planning, c'est quand on t'indique d'entrée quel délai tu as et qu'on te demande de faire un truc qui ressemble à un planning et qui doit tomber pile-poil dans ce délai. Sachant que de base, une des missions les plus importantes du planning est de déterminer le délai, et que donc, là, on a fixé un délai sans avoir de planning (au pif, quoi), ça veut simplement dire qu'on a envie que le gars qui est chargé de faire le fameux "rétro-planning" partage la responsabilité de l'échec. Ou alors qu'il fouette son équipe pour qu'ils travaillent nuits et jours.

    Personnellement, je veux bien faire des projets en mode "best effort", c'est à dire avec un délai qui ne me parait pas réaliste mais j'essaye quand même de faire au mieux, mais je refuse de perdre mon temps dans ce genre d'exercice fumeux dont le but n'est que de me manipuler. Si je ne décide pas du délai, que le gars qui a décidé porte la responsabilité si ce délai n'est pas respecté. Et si on insiste pour que je fasse un planning, je ne me sens pas obligé de tomber comme par hasard sur la deadline qu'on a décidé sans moi.

  11. #11
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    Juillet 2010
    Messages
    423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : C#,PHP,MySQL,Android...

    Informations forums :
    Inscription : Juillet 2010
    Messages : 423
    Points : 1 059
    Points
    1 059
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    D'où la notion ridicule de "rétro-planning". Un rétro-planning, c'est quand on t'indique d'entrée quel délai tu as et qu'on te demande de faire un truc qui ressemble à un planning et qui doit tomber pile-poil dans ce délai. Sachant que de base, une des missions les plus importantes du planning est de déterminer le délai, et que donc, là, on a fixé un délai sans avoir de planning
    Et surtout sans même avoir une idée de la complexité du travail.
    C'est bien beau de donner les délais de façon précipitée aux clients surtout quand on n'a pas conscience des contraintes auxquelles peuvent être confrontés l'équipe de développement.

  12. #12
    MikeRowSoft
    Invité(e)
    Par défaut
    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.

  13. #13
    Membre à l'essai
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2015
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 54
    Localisation : Hong-Kong

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Avril 2015
    Messages : 4
    Points : 12
    Points
    12
    Par défaut
    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.

  14. #14
    Expert confirmé Avatar de psychadelic
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    2 529
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 2 529
    Points : 4 739
    Points
    4 739
    Par défaut
    Citation Envoyé par transgohan Voir le message
    Client : Une réduction de xxxM€ ? Uniquement si vous nous livrez pour hier.
    Commercial : Marché conclu !


    Faut pas penser qu'aux responsables, les commerciaux sont souvent en première ligne pour ce genre de c*nneries...
    Oui, c'est le premier problème.
    Le commercial est la pour "vendre" des projets, et non pour les réaliser.
    Sa rémunération est directement liée à la signature, et pour lui, trop souvent, mieux vaut un mauvais contrat signé, que pas de contrat du tout.

    Au pire le contrat capote, et sa "prime" sera nulle; il aura au moins tenté sa "chance"...
    Si le contrat échoue ce seront les équipes de Dev qui en feront les frais, le responsable signataire client se fera lui aussi taper sur les doigts.

    Mais au bout du compte, et bien trop souvent, les équipes de dev sont loin de travailler dans la sérénité d'un contrat bien bordé.

    Après ,pour ce qui en est du travail d'équipe, je suis plutôt catastrophé de voir combien peu nombreux sont ceux qui connaissent l'usage d'un simple Kanban (et les méthodes agiles et Scrumb, n'en parlons même pas...)
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  15. #15
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    Avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 476
    Points : 4 805
    Points
    4 805
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par psychadelic Voir le message
    Oui, c'est le premier problème.
    Le commercial est la pour "vendre" des projets, et non pour les réaliser.
    Sa rémunération est directement liée à la signature, et pour lui, trop souvent, mieux vaut un mauvais contrat signé, que pas de contrat du tout.

    Au pire le contrat capote, et sa "prime" sera nulle; il aura au moins tenté sa "chance"...
    Si le contrat échoue ce seront les équipes de Dev qui en feront les frais, le responsable signataire client se fera lui aussi taper sur les doigts.

    Mais au bout du compte, et bien trop souvent, les équipes de dev sont loin de travailler dans la sérénité d'un contrat bien bordé.

    Après ,pour ce qui en est du travail d'équipe, je suis plutôt catastrophé de voir combien peu nombreux sont ceux qui connaissent l'usage d'un simple Kanban (et les méthodes agiles et Scrumb, n'en parlons même pas...)
    moi tout les jours à mon bureau l'on fait une réunion de 15 à 30 minutes pour faire le points sur les projets et la répartition des taches et tout ce passe bien ^^
    Rien, je n'ai plus rien de pertinent à ajouter

  16. #16
    Expert confirmé Avatar de psychadelic
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    2 529
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 2 529
    Points : 4 739
    Points
    4 739
    Par défaut
    Citation Envoyé par TiranusKBX Voir le message
    moi tout les jours à mon bureau l'on fait une réunion de 15 à 30 minutes pour faire le points sur les projets et la répartition des taches et tout ce passe bien ^^
    a oui? etvous avez bien sur un kanban ?
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  17. #17
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    Avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 476
    Points : 4 805
    Points
    4 805
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par psychadelic Voir le message
    a oui? etvous avez bien sur un kanban ?
    pas à proprement parler mais un grand tableau blanc on on note les taches
    Rien, je n'ai plus rien de pertinent à ajouter

  18. #18
    Membre à l'essai
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2015
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 54
    Localisation : Hong-Kong

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Avril 2015
    Messages : 4
    Points : 12
    Points
    12
    Par défaut
    Citation Envoyé par psychadelic Voir le message
    Après ,pour ce qui en est du travail d'équipe, je suis plutôt catastrophé de voir combien peu nombreux sont ceux qui connaissent l'usage d'un simple Kanban (et les méthodes agiles et Scrumb, n'en parlons même pas...)
    Ce sont des méthodologies, pas des garanties de réussites. Kanban et Scrum permettent de plus vite réaliser où l'on se situe dans l'avancée d'un projet et du coup d'être plus agile face à un changement et de voir le plantage arriver avant qu'il n'arrive. Ce ne sont absolument pas des outils miracles et pour qu'ils fonctionnent c'est comme dans tout projet, il faut un bon manager et une bonne implication du client et de la direction. Même une bonne vieille méthode de développement Waterfall a plus de chance de réussir a partir du moment ou tout le monde s'implique.

    Sur ce point un petit truc: peut importe la méthode choisie il faut toujours faire une réunion feedback en fin de projet ou de release. Que celui-ci soit une réussite ou non. De mon expérience c'est un critère de réussite de projet sur le long terme. Scrum s'est construit à partir de réunions feedback. Et moi je suis catastrophé de voir combien sont ceux qui ne font jamais de réunion feedback. Comment est ce que ces sociétés espèrent améliorer leur fonctionnement du coup.

  19. #19
    Membre à l'essai
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2015
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 54
    Localisation : Hong-Kong

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Avril 2015
    Messages : 4
    Points : 12
    Points
    12
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Mon expérience personnelle va dans ce sens-là. La meilleure direction, c'est celle qui dit "bon, c'est important, demerdez-vous pour que ça marche", et qui vient vérifier tous les 3 mois qu'on avance.
    Je reviens sur cette phrase qui m'a un peut choqué la première fois que je l'ai lue parce que je l'ai vécu. Je me suis déjà exprimé plus tôt mais je veut vraiment insister parce que c'est un piège. Une direction qui dit "bon, c'est important, demerdez-vous pour que ça marche", et qui vient vérifier tous les 3 mois qu'on avance, c'est une direction qui cherche à se déresponsabiliser des risques d'un échec. Maintenant c'est dans doute vrai pour une grosse société avec des gros moyen et un projet de plusieurs années mais pour une plus petite structure cette attitude est, selon moi, irresponsable. Je trouve aussi que ça manque d’ailleurs de respect pour ses développeurs. La direction lance un projet, elle s'y intéresse.

    Un autre critère de réussite d'un projet est, selon moi, le position du service IT dans l'entreprise. Il y a des entreprise ou l'IT est vue comme un service, elle n'a pas de pouvoir, elle fait le bon petit soldat pour citer mon responsable de l'époque. Et il y a des entreprise ou l'IT façonne le business. l'IT est au coeur de l'entreprise et elle a un réel pouvoir de modifier les procédures et la manière de fonctionner de l'entreprise. Si vous faite partie d'une équipe IT qui a du pouvoir il se peut que votre projet ai des conséquences au delà de votre secteur IT. Surtout quand votre solution informatique a des conséquences sur les emplois de certains travailleurs. Croyez moi, sur des projets à conséquence vous avez besoin de l'implication de votre direction et du reste de l'entreprise aussi d'ailleurs.

  20. #20
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Citation Envoyé par alksddfh Voir le message
    Maintenant c'est dans doute vrai pour une grosse société avec des gros moyen et un projet de plusieurs années mais pour une plus petite structure cette attitude est, selon moi, irresponsable. Je trouve aussi que ça manque d’ailleurs de respect pour ses développeurs. La direction lance un projet, elle s'y intéresse.
    Pourquoi cela serais-ce moins irresponsable pour une grande société ?

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

Discussions similaires

  1. comment structurer une modél. UML - projet J2EE avec pattern
    Par RocketArena dans le forum Architecture
    Réponses: 18
    Dernier message: 20/07/2007, 20h20
  2. Comment organiser les fichiers de projet ?
    Par Zen_Fou dans le forum Général Conception Web
    Réponses: 4
    Dernier message: 03/05/2006, 18h21
  3. [Outils][InstallWIz.Net]Comment l'utiliser pour mon projet?
    Par fantomchris dans le forum EDI/Outils
    Réponses: 30
    Dernier message: 19/04/2006, 19h35
  4. [Droits] Comment garantir au mieux la confidentialité ?
    Par mencaglia dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 06/02/2006, 10h39
  5. Réponses: 13
    Dernier message: 22/07/2005, 19h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo