Bonjour,
En sus de certaines des réponses pertinentes ici, l'Open ERP n'est pas du tout du tout pour ce que vous voulez faire.
Vous êtes sur des logiques classiques Base de données (type MySQL) puis le back office, une couche PHP, le liant et un front (HTML avec des choses comme du Bootstrap).
Je m'excuse du jargon, mais je crois que vous avez besoin d'une vue plus claire voire d'aide.
Cordialement,
Thomas
www.mobix.fr
L'outil digital, coeur de mon entreprise : sur mesure ou open ERP ?
il y a 8 ans
par
GuillaumeISNARD
L'offre de mon entreprise en création se fera via l'outil WEB. Un outil d'évaluation et de certification de compétences, composé des éléments suivants :
Un évaluateur de compétences adaptatif géré par un algorithme
Un outil de formation interactif, des exercices en ligne
Une interface administrateur pour gérer les droits d'accès de chaque client
Une base de données qui stockera plusieurs dizaines de milliers de questions et des millions de réponses
Étant totalement néophyte, je cherche des conseils sur la meilleure démarche à mener pour limiter l'investissement et obtenir un outil fiable, pérenne, évolutif.
2
2
11 réponses
Bonjour,
Si vous êtes néophyte, je vous conseille de commencer par rédiger un document reprend le fonctionnement pas à pas de votre solution dans le détail (le volet technique ne doit pas être présent dans ce document).
Ce document, qu'on pourrait pompeusement appelé "Spécifications Fonctionnelles Détaillées" vous permettra de fixer un peu les choses sur ce que vous souhaitez, de mieux cadrer le chiffrage pour vos prestataire et de mieux valider la bonne réalisation. L'évaluation du CDC sera beaucoup plus facile et homogène d'une réponse à l'autre.
Il vous permettra d'anticiper sur des contraintes que vous n'auriez pas envisagé pour l'instant. L'avantage de rédiger des SFD sera de fixer la vision de ce que vous voulez come résultat en vous affranchissant des contraintes techniques (après tout elles ne vous regardent pas) et surtout dans un langage courant (pas de vocabulaire technique).
Au moment de la recette (et avant de payer le solde) il vous suffira de reprendre les chapitres pour obtenir une grille d'évaluation.
Même si vous vous faites accompagner par une AMOA, il vous faudra ces specifications.
Dernier conseil: ne rentrez jamais dans un débat technique avec les développeurs. Ce n'est pas à vous d'assumer les erreurs d'analyse ou les marottes techniques. Ils ont un besoin fonctionnel exprimé, ils l'ont compris et accepté, c'est donc leur art (et leur problème) de le réaliser.
Si vous êtes néophyte, je vous conseille de commencer par rédiger un document reprend le fonctionnement pas à pas de votre solution dans le détail (le volet technique ne doit pas être présent dans ce document).
Ce document, qu'on pourrait pompeusement appelé "Spécifications Fonctionnelles Détaillées" vous permettra de fixer un peu les choses sur ce que vous souhaitez, de mieux cadrer le chiffrage pour vos prestataire et de mieux valider la bonne réalisation. L'évaluation du CDC sera beaucoup plus facile et homogène d'une réponse à l'autre.
Il vous permettra d'anticiper sur des contraintes que vous n'auriez pas envisagé pour l'instant. L'avantage de rédiger des SFD sera de fixer la vision de ce que vous voulez come résultat en vous affranchissant des contraintes techniques (après tout elles ne vous regardent pas) et surtout dans un langage courant (pas de vocabulaire technique).
Au moment de la recette (et avant de payer le solde) il vous suffira de reprendre les chapitres pour obtenir une grille d'évaluation.
Même si vous vous faites accompagner par une AMOA, il vous faudra ces specifications.
Dernier conseil: ne rentrez jamais dans un débat technique avec les développeurs. Ce n'est pas à vous d'assumer les erreurs d'analyse ou les marottes techniques. Ils ont un besoin fonctionnel exprimé, ils l'ont compris et accepté, c'est donc leur art (et leur problème) de le réaliser.
Mais c'est la préhistoire !!!
Surtout, définissons à l'avance ce que nous ne savons pas, sans aucune flexibilité future.
Ne nous intéressons pas à la technique, après tout on achète un développement technique alors...
Laissons les développeurs assumer complètement le fait que cette définition ne fonctionne pas au final et engageons le plus vite possible une relation d'opposition en menaçant de ne pas les payer. C'est vrai : vous avez le savoir métier, gardez-le pour vous. Et puis comme ça, ils feront un code encore plus pourri comme ils sont en retard et pris à la gorge.
Parce que le document qui vous a permis de "fixer un peu les choses que vous souhaitez" est devenu un contrat, forcément incomplet tant qu'on aura pas inventé la boule de cristal.
Ne pas oublier : avoir un bon avocat dès le départ parce que ça finira de toute façon au tribunal avec un développement en retard et tout buggé !
Sinon, depuis l'an 2000, il y a l'agilité... Un mouvement créé par des gens qui ont compris qu'il faut communiquer tout du long, collaborer en confiance, partager, se donner le droit d'avoir oublié un détail, changer d'avis, pour au final faire plus vite et moins cher le bon produit, celui que vos utilisateurs attendent mais que vous ne pouvez définir aujourd'hui. Choisissez des gens qui vous sont recommandés, qui sont passionnés, que vous "sentez" bien et soyez au front sur le développement de votre projet, ne laissez personne le faire pour vous.
Surtout, définissons à l'avance ce que nous ne savons pas, sans aucune flexibilité future.
Ne nous intéressons pas à la technique, après tout on achète un développement technique alors...
Laissons les développeurs assumer complètement le fait que cette définition ne fonctionne pas au final et engageons le plus vite possible une relation d'opposition en menaçant de ne pas les payer. C'est vrai : vous avez le savoir métier, gardez-le pour vous. Et puis comme ça, ils feront un code encore plus pourri comme ils sont en retard et pris à la gorge.
Parce que le document qui vous a permis de "fixer un peu les choses que vous souhaitez" est devenu un contrat, forcément incomplet tant qu'on aura pas inventé la boule de cristal.
Ne pas oublier : avoir un bon avocat dès le départ parce que ça finira de toute façon au tribunal avec un développement en retard et tout buggé !
Sinon, depuis l'an 2000, il y a l'agilité... Un mouvement créé par des gens qui ont compris qu'il faut communiquer tout du long, collaborer en confiance, partager, se donner le droit d'avoir oublié un détail, changer d'avis, pour au final faire plus vite et moins cher le bon produit, celui que vos utilisateurs attendent mais que vous ne pouvez définir aujourd'hui. Choisissez des gens qui vous sont recommandés, qui sont passionnés, que vous "sentez" bien et soyez au front sur le développement de votre projet, ne laissez personne le faire pour vous.
@EtienneZulauf aurais tu quelque chose contre moi? c'est quoi ce dédain et cette agressivité ? Je te propose de discuté en Off à 3 avec @MissSkiller. Je pense que je ne mérite pas ce comportement.
Pour Agile est une méthode de développement, elle ne concerne pas le client. Et ce n'est surtout pas une oriflamme qu'on sort pour faire du vent
Pour Agile est une méthode de développement, elle ne concerne pas le client. Et ce n'est surtout pas une oriflamme qu'on sort pour faire du vent
Cher Etienne, la bienveillance n'est pas une option sur Skiller. Nous sommes tous des pros qui adorons les débats ce qui implique de respecter pleinement le point de vue de l'autre. Miss Skiller comprend votre enthousiasme et l'apprécie mais vous invite à des échanges qui ne laissent aucune place à la critique directe d'un autre membre de la communauté.
Cher Pascal, comment dire, le commentaire précédent vaut pour tout le monde ! En cas de soucis, Miss Skiller et Mr Skiller sont toujours là !
Désolé, j'ai conscience de m'être emporté. Pas emporté contre @PascalW qui défend ses idées, mais contre le façon de faire dans le développement qui consiste à traiter les développeurs comme des exécutants, responsables pour tout le monde des erreurs de chacun. Et, encore désolé de le dire, c'est une pensée qui commence sérieusement à dater.
Comme vous l'aurez compris, je dirige une société de développement, et ces pratiques sont catastrophiques pour notre profession. Je l'ai vécu et en ai souffert. Commercialement certes et physiquement.
On ne peut pas presser le kiki des développeurs pour réaliser le contenu d'un cahier des charges incomplet (par définition) au meilleur prix et penser récupérer de la qualité. 60% des projets informatiques dépassent de 50% les prix et les délais. Pourquoi ? Et combien n'aboutissent jamais ?
Mon message, c'est qu'on doit travailler main dans la main avec le prestataire qui réalise son projet de start'up. Parce qu'à ce stade, on pose tout sur la table et qu'on veut du durable en face. Le durable se construit avec de la confiance et de la collaboration, pas avec un chèque qui n'arrive pas. Sans parler du plaisir de collaborer, qui génère de l'empathie et donc l'envie de réaliser le bon produit pour le client, quelles que soient les circonstances. Les écarts de plan qui arrivent dans l'informatique ne peuvent être mis exclusivement sur le dos des développeurs. Il y a trop d'éléments extérieurs pour prétendre avoir le contrôle, et tout est fait dans l'intérêt du client au final alors soyons transparent. En partageant la vision, les choix, les contraintes et avantages, toute l'équipe, c'est-à-dire développeurs et client(s), est plus efficace.
Le développement, c'est un travail hautement intellectuel, complexe, jamais acquis, sans limite. Ce n'est pas pour rien que ce n'est pas un métier qui se délocalise si facilement et que les salaires flambent. Les clients qui sont inclus dans le processus apprennent beaucoup et font de meilleurs choix. Vous avez besoin d'avoir de bons développeurs motivés pour votre projet, ne vous les mettez pas à dos dès la signature du contrat ! Oui, l'agilité est une méthode de collaboration qui embarque le client au cœur du développement (ne pas confondre avec SCRUM) agilemanifesto.org/
Je m'excuse du ton qui, je l'admets, est ironique. Le conseil publié m'attaque personnellement (sans volonté bien sûr) et je me suis emballé. @PascalW, je ne te connais pas, je n'ai pas la capacité de t'en vouloir. Il ne me semble pas avoir manqué de bienveillance ou t'avoir critiqué personnellement. Je comprends que tu te sentes agressé, désolé. Je suis tout à fait ouvert au débat IRL et pourquoi pas t'inviter dans nos bureaux pour te montrer l'agilité en action.
Comme vous l'aurez compris, je dirige une société de développement, et ces pratiques sont catastrophiques pour notre profession. Je l'ai vécu et en ai souffert. Commercialement certes et physiquement.
On ne peut pas presser le kiki des développeurs pour réaliser le contenu d'un cahier des charges incomplet (par définition) au meilleur prix et penser récupérer de la qualité. 60% des projets informatiques dépassent de 50% les prix et les délais. Pourquoi ? Et combien n'aboutissent jamais ?
Mon message, c'est qu'on doit travailler main dans la main avec le prestataire qui réalise son projet de start'up. Parce qu'à ce stade, on pose tout sur la table et qu'on veut du durable en face. Le durable se construit avec de la confiance et de la collaboration, pas avec un chèque qui n'arrive pas. Sans parler du plaisir de collaborer, qui génère de l'empathie et donc l'envie de réaliser le bon produit pour le client, quelles que soient les circonstances. Les écarts de plan qui arrivent dans l'informatique ne peuvent être mis exclusivement sur le dos des développeurs. Il y a trop d'éléments extérieurs pour prétendre avoir le contrôle, et tout est fait dans l'intérêt du client au final alors soyons transparent. En partageant la vision, les choix, les contraintes et avantages, toute l'équipe, c'est-à-dire développeurs et client(s), est plus efficace.
Le développement, c'est un travail hautement intellectuel, complexe, jamais acquis, sans limite. Ce n'est pas pour rien que ce n'est pas un métier qui se délocalise si facilement et que les salaires flambent. Les clients qui sont inclus dans le processus apprennent beaucoup et font de meilleurs choix. Vous avez besoin d'avoir de bons développeurs motivés pour votre projet, ne vous les mettez pas à dos dès la signature du contrat ! Oui, l'agilité est une méthode de collaboration qui embarque le client au cœur du développement (ne pas confondre avec SCRUM) agilemanifesto.org/
Je m'excuse du ton qui, je l'admets, est ironique. Le conseil publié m'attaque personnellement (sans volonté bien sûr) et je me suis emballé. @PascalW, je ne te connais pas, je n'ai pas la capacité de t'en vouloir. Il ne me semble pas avoir manqué de bienveillance ou t'avoir critiqué personnellement. Je comprends que tu te sentes agressé, désolé. Je suis tout à fait ouvert au débat IRL et pourquoi pas t'inviter dans nos bureaux pour te montrer l'agilité en action.
Bonjour @EtienneZulauf
tu as commencé ton commentaire à ma réponse par "Mais c'est la préhistoire !!!" difficile de ne pas le prendre pour moi et je n'y trouve pas beaucoup de bienveillance.
Personnellement, je distingue client et utilisateur. Ce ne sont pas toujours les mêmes personnes.
Pour ce qui est d'Agile je ne confond avec rien, mon expérience m'a amené à devoir mettre et maintenir en production des projets d'inspiration "Agile" et je n'ai pas aimé les développeurs qui se refugient derrière une demarche pour masquer leurs erreurs. Oui, le dev est une fonction hautement intellectuelle, comme beaucoup d'autres quand on fait de la prestation IT ou pas. Je ne souhaite pas faire de généralité mais pour l'instant je rêve de voir un projet de ce type dans le run sans incident majeur dans les 2 ans qui suivent la VSR. C'est ce qui différentie une équipe de dev d'une équipe d'exploit : sans recette ou VSR, on ne peut pas prendre en charge la mise en support ou la TMA. Comment restaurer un service sans cela? Est ce que l'équipe de Dev doit rester sur le support tout au long du cycle de vie du produit? Ce n'est pas toujours possible.
Je considère tous les acteurs en prestation comme des exécutants, parce c'est ce que nous sommes. Il n'y a pas a en avoir honte.
Je ne sais pas d'où sortent les chiffres (60% des projets informatiques dépassent de 50% les prix et les délais) mais c'est le métier des gens comme moi de dire aux clients ou aux éditeurs quand leurs charges ou délais ne sont pas réalistes, ou (et c'est mon cas de figure préféré) de les aider à les rendre réaliste.
Je ne vais pas faire étalage des exemples de comportement approximatif que j'ai pu croiser jusqu'ici. Cela donnerai une image fausse des développeurs. Nous avons fini par travailler avec une très bonne synergie dans la majorité des cas.
Donc oui, je considère que tu m'as agressé gratuitement et cela me semble aller bien au delà d'une ironie mal dosée.
Dernier point, nous ne sommes visiblement pas sur le type d'entreprises clientes. Chacun de ces types a sa propre culture, ses impératifs et ses limites.
Mais cela ne veut pas dire que nous ayons le droit de mépriser l'autre publiquement.
tu as commencé ton commentaire à ma réponse par "Mais c'est la préhistoire !!!" difficile de ne pas le prendre pour moi et je n'y trouve pas beaucoup de bienveillance.
Personnellement, je distingue client et utilisateur. Ce ne sont pas toujours les mêmes personnes.
Pour ce qui est d'Agile je ne confond avec rien, mon expérience m'a amené à devoir mettre et maintenir en production des projets d'inspiration "Agile" et je n'ai pas aimé les développeurs qui se refugient derrière une demarche pour masquer leurs erreurs. Oui, le dev est une fonction hautement intellectuelle, comme beaucoup d'autres quand on fait de la prestation IT ou pas. Je ne souhaite pas faire de généralité mais pour l'instant je rêve de voir un projet de ce type dans le run sans incident majeur dans les 2 ans qui suivent la VSR. C'est ce qui différentie une équipe de dev d'une équipe d'exploit : sans recette ou VSR, on ne peut pas prendre en charge la mise en support ou la TMA. Comment restaurer un service sans cela? Est ce que l'équipe de Dev doit rester sur le support tout au long du cycle de vie du produit? Ce n'est pas toujours possible.
Je considère tous les acteurs en prestation comme des exécutants, parce c'est ce que nous sommes. Il n'y a pas a en avoir honte.
Je ne sais pas d'où sortent les chiffres (60% des projets informatiques dépassent de 50% les prix et les délais) mais c'est le métier des gens comme moi de dire aux clients ou aux éditeurs quand leurs charges ou délais ne sont pas réalistes, ou (et c'est mon cas de figure préféré) de les aider à les rendre réaliste.
Je ne vais pas faire étalage des exemples de comportement approximatif que j'ai pu croiser jusqu'ici. Cela donnerai une image fausse des développeurs. Nous avons fini par travailler avec une très bonne synergie dans la majorité des cas.
Donc oui, je considère que tu m'as agressé gratuitement et cela me semble aller bien au delà d'une ironie mal dosée.
Dernier point, nous ne sommes visiblement pas sur le type d'entreprises clientes. Chacun de ces types a sa propre culture, ses impératifs et ses limites.
Mais cela ne veut pas dire que nous ayons le droit de mépriser l'autre publiquement.
Dire les chose n'a rien à voir avec la bienveillance ... ne pas dire est de la Xyloglossie ! (de Xylo = bois et glossie = langue !!! si la langue de bois deviens la règle sur skiller, il va être difficile de partager nos expertises !!
Nous sommes là pour échanger et la richesse née de nos différences ...
Nous sommes là pour échanger et la richesse née de nos différences ...
@olivierChaillot il y a la façon de dire les choses. On peut exprimer son avis sans langue de bois et dans le respect de chacun parce que finalement nous n'avons pas la science infuse.
En l'occurrence ici, Etienne m'a ciblé dans plusieurs commentaires à différentes questions d'une manière qui m'a profondément heurté.
Entre langue de bois et agressivité gratuite, j'aurai aimé une alternative reposant sur l'écoute, l'intelligence et des arguments factuels. Nous sommes animé par notre passion mais cela ne peut pas être une excuse à tous.
je lui proposais de discuté off line et j'attendu au mail en privé mais il a préféré faire tribune ici.
Je n'ai pas son mail sinon j'aurai pris l'initiative de lui écrire.
Ceci étant, le spectacle donné ici est déplorable et, non je ne m'excuse pas mais vous présente mes excuses.
Peut être est il temps de mettre un terme à ce déplorable incident.
Soyez gentil: n'en parlons plus
Merci
En l'occurrence ici, Etienne m'a ciblé dans plusieurs commentaires à différentes questions d'une manière qui m'a profondément heurté.
Entre langue de bois et agressivité gratuite, j'aurai aimé une alternative reposant sur l'écoute, l'intelligence et des arguments factuels. Nous sommes animé par notre passion mais cela ne peut pas être une excuse à tous.
je lui proposais de discuté off line et j'attendu au mail en privé mais il a préféré faire tribune ici.
Je n'ai pas son mail sinon j'aurai pris l'initiative de lui écrire.
Ceci étant, le spectacle donné ici est déplorable et, non je ne m'excuse pas mais vous présente mes excuses.
Peut être est il temps de mettre un terme à ce déplorable incident.
Soyez gentil: n'en parlons plus
Merci
@PascalW, peut on avoir une lecture différente de l'échange sans être considéré comme agresseur ? Pour ma part je comprends "Mais c'est la préhistoire !!!" comme désignant la méthode que tu décrits et non toi, l'auteur du texte.
C'est toute la limite de l'échange épistolaire où il n'y a ni le ton, ni l'expression du visage de "l'émetteur" qui vient enrichir le message. L'état d'esprit du receveur, au moment où il lit le message, peut également influencer la compréhension du message.
Pour connaitre @EtienneZulauf il m'est difficile de le reconnaitre comme agresseur ... pas le genre du bonhomme ! Passionné certainement, franc c'est sûr, n'ayant pas peur de dire les chose d'accord, mais pas respectueux des humains là, désolé, ça ne colle pas !
Alors, au lieu de prendre toute idée différente comme une agression personnelle, n'est-il pas possible de considérer que l'apport de l'autre est une source d'enrichissement ? que c'est de la confrontation de nos certitudes avec d'autres vérités qui nous font progresser ? que le doute, la remise en cause de nos croyances, est le meilleur moyen d'avancer ?
Cordialement
C'est toute la limite de l'échange épistolaire où il n'y a ni le ton, ni l'expression du visage de "l'émetteur" qui vient enrichir le message. L'état d'esprit du receveur, au moment où il lit le message, peut également influencer la compréhension du message.
Pour connaitre @EtienneZulauf il m'est difficile de le reconnaitre comme agresseur ... pas le genre du bonhomme ! Passionné certainement, franc c'est sûr, n'ayant pas peur de dire les chose d'accord, mais pas respectueux des humains là, désolé, ça ne colle pas !
Alors, au lieu de prendre toute idée différente comme une agression personnelle, n'est-il pas possible de considérer que l'apport de l'autre est une source d'enrichissement ? que c'est de la confrontation de nos certitudes avec d'autres vérités qui nous font progresser ? que le doute, la remise en cause de nos croyances, est le meilleur moyen d'avancer ?
Cordialement
cher @olivierChaillot ,
Contrairement à toi je ne connais pas Etienne et peut être est-ce la cause de cet imbroglio.
C' est sûrement la difficulté de ne pas être toulousain.
Depuis il m'a écrit et nous allons échanger entre nous.
Je l'avais écrit, cet échange s'est inscrit dans un ensemble qui m'a semblé me cibler directement. C'est pour cela que j'ai vu une aggression dans les propos d'Etienne.. Depuis, je comprend qu'il s'agit d'une coincidence malheureuse.
Ce serait vraiment sympa à toi de ne plus en rajouter sur ce sujet.
Il y a sûrement des sujets plus intéressant à traiter ici.
Contrairement à toi je ne connais pas Etienne et peut être est-ce la cause de cet imbroglio.
C' est sûrement la difficulté de ne pas être toulousain.
Depuis il m'a écrit et nous allons échanger entre nous.
Je l'avais écrit, cet échange s'est inscrit dans un ensemble qui m'a semblé me cibler directement. C'est pour cela que j'ai vu une aggression dans les propos d'Etienne.. Depuis, je comprend qu'il s'agit d'une coincidence malheureuse.
Ce serait vraiment sympa à toi de ne plus en rajouter sur ce sujet.
Il y a sûrement des sujets plus intéressant à traiter ici.
Les deux mon capitaine ! :)
Je ne sais pas quel est votre plan d'affaire, vos finances.
Mais, ceci étant, je ne partirai pas du tout sur une approche classique avec cahier des charges - dev specifique sur mesure en totalité, et recette.
Désolé, je n'adhère pas. Trop risqué, pas assez agile, cher...
Même si les méthodologies évoquées précédemment sont valables sur le plan opérationnel, le tryptique investissement/risque/fiabilité n'est pas optimisé.
Rien ne vous empêche de partir sur une approche mixte, avec une plateforme web et des modules Open source pour faire un "produit minimum viable".
Le faire tourner auprès de vos clients et utilisateurs et ....
"lacher" du budget ensuite, pour bâtir sur mesure, en fonction des retours, des fonctionnalités comme nul part ailleurs, et vraiment adaptées à votre marché.
Je ne sais pas quel est votre plan d'affaire, vos finances.
Mais, ceci étant, je ne partirai pas du tout sur une approche classique avec cahier des charges - dev specifique sur mesure en totalité, et recette.
Désolé, je n'adhère pas. Trop risqué, pas assez agile, cher...
Même si les méthodologies évoquées précédemment sont valables sur le plan opérationnel, le tryptique investissement/risque/fiabilité n'est pas optimisé.
Rien ne vous empêche de partir sur une approche mixte, avec une plateforme web et des modules Open source pour faire un "produit minimum viable".
Le faire tourner auprès de vos clients et utilisateurs et ....
"lacher" du budget ensuite, pour bâtir sur mesure, en fonction des retours, des fonctionnalités comme nul part ailleurs, et vraiment adaptées à votre marché.
Bonjour,
Au vu des écarts dans les devis, effectivement le choix apparaît cornélien : la méthodologie que j'appliquerai: échanger et échanger encore avec les différents interlocuteurs pour:
1- s'assurer qu'ils comprennent bien le besoin actuel et votre façon de penser (remarque: cela permettra aussi d'affiner le CDC) : la méthodologie qui sera appliquée ensuite va en découler et est primordiale pour la réussite du projet
2- apprendre sur le tas le "lingo" informatique et se faire une idée du meilleur environnement (as in "best effort") pour développer l'outil voulu en rêve (cf le besoin émis d'un outil pérenne, évolutif = pas recommencer tous les 3 ans parce que dans une impasse technologique pour continuer de faire évoluer le produit + la lourde de peine de transférer les données) .
3- déterminer lequel des prestataires sera le mieux à même de transcrire les besoins et identifier les risques de malentendu qui pourrait ensuite coûter cher en temps et argent parce que développement fait sur de mauvaises bases.
Le tout pour se donner les outils pour une lecture critique des projets présentés, décider quel budget peut raisonnablement être investi, et à la fin donner un peu confiance à ses tripes pour sélectionner l'heureux prestataire. Enfin savoir qu'ensuite votre investissement en temps dans ce projet IT sera non négligeable.
Sinon bien être convaincu qu'un outil informatique voulu en rêve a toujours une version 1.0 qui a le mérite d'exister mais révélera rapidement qu'il faut une version 2.0 car des besoins ont été oubliés dans un cahier des charges pourtant bien pensé de A à Z, et parce que la technologie évolue toujours .
Retour d’expérience d'une non informaticienne qui a fait évoluer avec succès un ERP laissé sans développement pendant 5 ans, avec pleins de fonctionnalités non pensées, vécu comme une contrainte et non une aide par 5 utilisateurs temps plein + 2 experts comptable+le patron....
Au vu des écarts dans les devis, effectivement le choix apparaît cornélien : la méthodologie que j'appliquerai: échanger et échanger encore avec les différents interlocuteurs pour:
1- s'assurer qu'ils comprennent bien le besoin actuel et votre façon de penser (remarque: cela permettra aussi d'affiner le CDC) : la méthodologie qui sera appliquée ensuite va en découler et est primordiale pour la réussite du projet
2- apprendre sur le tas le "lingo" informatique et se faire une idée du meilleur environnement (as in "best effort") pour développer l'outil voulu en rêve (cf le besoin émis d'un outil pérenne, évolutif = pas recommencer tous les 3 ans parce que dans une impasse technologique pour continuer de faire évoluer le produit + la lourde de peine de transférer les données) .
3- déterminer lequel des prestataires sera le mieux à même de transcrire les besoins et identifier les risques de malentendu qui pourrait ensuite coûter cher en temps et argent parce que développement fait sur de mauvaises bases.
Le tout pour se donner les outils pour une lecture critique des projets présentés, décider quel budget peut raisonnablement être investi, et à la fin donner un peu confiance à ses tripes pour sélectionner l'heureux prestataire. Enfin savoir qu'ensuite votre investissement en temps dans ce projet IT sera non négligeable.
Sinon bien être convaincu qu'un outil informatique voulu en rêve a toujours une version 1.0 qui a le mérite d'exister mais révélera rapidement qu'il faut une version 2.0 car des besoins ont été oubliés dans un cahier des charges pourtant bien pensé de A à Z, et parce que la technologie évolue toujours .
Retour d’expérience d'une non informaticienne qui a fait évoluer avec succès un ERP laissé sans développement pendant 5 ans, avec pleins de fonctionnalités non pensées, vécu comme une contrainte et non une aide par 5 utilisateurs temps plein + 2 experts comptable+le patron....
Je viens de conclure un partenariat avec un gros client national pour la validation des SDF et la co-construction de l'outil...
Une approche de type MVP (Minimum Viable Product) pour reprendre le jargon consacré peut-être en effet une idée.
Cela n'empêchera de devoir contractualiser avec des éléments solides, si vous faites appel à un prestataire.
Frédéric Libaud, Expert en Numérique, Référent pour la région ouest de CINOV - IT
www.libaudfrederic.fr | blog.libaudfrederic.fr | www.cinov-it.fr
Cela n'empêchera de devoir contractualiser avec des éléments solides, si vous faites appel à un prestataire.
Frédéric Libaud, Expert en Numérique, Référent pour la région ouest de CINOV - IT
www.libaudfrederic.fr | blog.libaudfrederic.fr | www.cinov-it.fr
Bonjour,
Je vois mal ou Open ERP pourrait être une solution pertinente, face à l'exposé de vos besoins. Une solution spécifique sera certainement la plus adapté car il s'agit d'un outil de production, il doit donc être une des briques de la différenciation de votre structure.
Il faudra donc commencer par mettre en place les basiques (cahier des charges, planning, ...) afin d'en évaluer les coûts entre autres.
Frédéric Libaud, Expert en Numérique, Référent pour la région ouest de CINOV - IT
www.libaudfrederic.fr | blog.libaudfrederic.fr | www.cinov-it.fr
Je vois mal ou Open ERP pourrait être une solution pertinente, face à l'exposé de vos besoins. Une solution spécifique sera certainement la plus adapté car il s'agit d'un outil de production, il doit donc être une des briques de la différenciation de votre structure.
Il faudra donc commencer par mettre en place les basiques (cahier des charges, planning, ...) afin d'en évaluer les coûts entre autres.
Frédéric Libaud, Expert en Numérique, Référent pour la région ouest de CINOV - IT
www.libaudfrederic.fr | blog.libaudfrederic.fr | www.cinov-it.fr
Merci. Le CDC a été réalisé dans les grandes lignes et les devis vont de 70 k€ à 200 k€ pour le moment. C'est peut être un signe au çe CDC n'est pas assez détaillé... Comment peut on se faire aider à ce stade ?
Bonjour,
Je prêche pour ma paroisse mais, si vous n'avez pas de compétences dans le domaine du digital un accompagnement s'impose.
Frédéric Libaud, Expert en Numérique, Référent pour la région ouest de CINOV - IT
www.libaudfrederic.fr | blog.libaudfrederic.fr | www.cinov-it.fr
Je prêche pour ma paroisse mais, si vous n'avez pas de compétences dans le domaine du digital un accompagnement s'impose.
Frédéric Libaud, Expert en Numérique, Référent pour la région ouest de CINOV - IT
www.libaudfrederic.fr | blog.libaudfrederic.fr | www.cinov-it.fr
Bonjour,
Je te suggère de parcourir les deux pages suivantes:
fr.wikipedia.org/wiki/Moodle
fr.wikipedia.org/wiki/Liste_de_plateformes_p%C...
Tu pourrais voir dans ce qui existe si une des plateformes cités d'approche de près de ce que tu souhaites obtenir.
(et quoi ? Tout le monde dit "vous" sur cette discussion ? Pourtant je n'ai pas vu @MissSkiller par ici !)
Je te suggère de parcourir les deux pages suivantes:
fr.wikipedia.org/wiki/Moodle
fr.wikipedia.org/wiki/Liste_de_plateformes_p%C...
Tu pourrais voir dans ce qui existe si une des plateformes cités d'approche de près de ce que tu souhaites obtenir.
(et quoi ? Tout le monde dit "vous" sur cette discussion ? Pourtant je n'ai pas vu @MissSkiller par ici !)
Chère Joyce, il faut sans cesse le rappeler : sur Skiller, seule Miss Skiller dit "vous" :)
Merci pour ces liens très pertinents. Pour bien comprendre : nous avons un contenu, une BDD, un algorithme complexe et une IHM qui renferme une grande partie de notre valeur ajoutée. Avec ces éléments, il est possible d'intégrer notre offre sur une plateforme de diffusion existante en la customisant et en lui greffant nos données ?
> Avec ces éléments, il est possible d'intégrer notre offre sur une plateforme de diffusion existante en la customisant et en lui greffant nos données ?
En théorie oui, les développeurs peuvent faire tout ce qu'ils veulent du moment qu'ils ont les sources. Il y a quelques années lorsqu'une de nos ministres semblait confondre suite bureautique et pare-feu (de mémoire, la phrase était "on a des logiciels libres, on a des firewall ! on a OpenOffice !") alors un développeur s'était amusé à recoder OpenOffice pour lui ajouter une fonctionnalité firewall. (LOL).
Plus sérieusement, il doit y avoir ici des personnes sachant faire ce genre de chose, et si personne ne te propose d'étudier ton besoin spécifique, tu peux t'adresser à l'une ou l'autre des structures existantes en région, et répertoriées par le CNLL. Pour ta région: www.pole-aquinetic.fr/
Et peut-être que @FredericLibaud pourrait aussi t'aiguiller, même si vous n'êtes pas tout à fait dans le même coin ? :-)
En théorie oui, les développeurs peuvent faire tout ce qu'ils veulent du moment qu'ils ont les sources. Il y a quelques années lorsqu'une de nos ministres semblait confondre suite bureautique et pare-feu (de mémoire, la phrase était "on a des logiciels libres, on a des firewall ! on a OpenOffice !") alors un développeur s'était amusé à recoder OpenOffice pour lui ajouter une fonctionnalité firewall. (LOL).
Plus sérieusement, il doit y avoir ici des personnes sachant faire ce genre de chose, et si personne ne te propose d'étudier ton besoin spécifique, tu peux t'adresser à l'une ou l'autre des structures existantes en région, et répertoriées par le CNLL. Pour ta région: www.pole-aquinetic.fr/
Et peut-être que @FredericLibaud pourrait aussi t'aiguiller, même si vous n'êtes pas tout à fait dans le même coin ? :-)
Bonjour,
Ce sera avec plaisir, je reste à disposition.
Frédéric Libaud, Expert en Numérique, Référent pour la région ouest de CINOV - IT
www.libaudfrederic.fr | blog.libaudfrederic.fr | www.cinov-it.fr
Ce sera avec plaisir, je reste à disposition.
Frédéric Libaud, Expert en Numérique, Référent pour la région ouest de CINOV - IT
www.libaudfrederic.fr | blog.libaudfrederic.fr | www.cinov-it.fr
ça dépend ... c'est quoi le marché visé ? qu'y fait la concurrence ? Y a t il un cadre réglementaire ? est il contraignant ? Quels sont les comportements pré-existant chez les futurs clients ? ...
L'outil à développé sera pertinent s'il prend en compte ces différentes contraintes ...
L'outil à développé sera pertinent s'il prend en compte ces différentes contraintes ...
Merci à chacune et chacun d'entre vous. Je poursuis des consultations de chefs de projets et de diverses sociétés pour améliorer ma culture du sujet pendant que je formalise un nouveau CDC fonctionnel.
Si certains parmi vous sont intéressés et pas trop éloignés de Limoges, n'hésitez pas à me joindre : guillaumeisnard @hotmail.com
Bravo pour votre initiative et beaucoup de succès pour donner une nouvelle image à Limoges (d'une limougeaude ayant du "s'expatrier" il y a plus de 16 ans faute de travail) .
Pour éviter l'expat, passées certaines attentes, il faut ici créer son job :) !
Je vois que le débat est passionné et il m'apprend aussi par cet aspect bien des choses. J'ai déployé un projet digital pour mon entreprise précédente, avec un prestataire "agile". En ce qui le concernait, l'agilité était plus un habillage de son manque de travail plutôt qu'une méthode efficiente. Je crois que toute méthode est potentiellement efficace ou non en fonction des objectifs, de l'état d'esprit, des contraintes économiques ou temporelles...
Globalement, je rencontre des prestataires qui me conseillent de préciser mes demandes en commençant à avancer sur un noyau.
Bonne journée à tous.
Globalement, je rencontre des prestataires qui me conseillent de préciser mes demandes en commençant à avancer sur un noyau.
Bonne journée à tous.
Bonjour,
J'ai suivi l'échange avec intérêt. Je pense qu'il n'y a eu nulle part une envie de blesser ou d'être présomptueux, mais tout simplement l'enthousiasme de certains pour leurs méthodes et leurs convictions.
Je travaille depuis 20 ans dans l'informatique. J'ai commencé comme codeur, puis chef d'équipe, puis chef de projet, puis DSI et de nouveau codeur.
Dans toutes les méthodes de développement, il y a le mieux et le pire, et tout dépend des humains derrière (porte ouverte, s'il en est). J'ai connu des gens qui étaient en mesure de développer des solutions sur une base d'un cahier des charges défini, mais qui étaient incapables de faire partie d'une équipe en mode scrum/agile. Non pas par manque de talent ou de compétences, mais tout simplement parce qu'il s'agissait d'un mode de pensée antagonique au leur. Et dans ces cas-là. on peut avoir la meilleure équipe du monde, et obtenir des résutats catastrophiques.
Le contraire vaut aussi: des développeurs voire des concepteurs conditionnés scrum, et incapables de suivre une grande ligne d'un cahier des charges (re-porte ouverte).
Ce que je vous dis n'est pas d'une très grande utilité concrète. Ce que dit @prelude au sujet du développeur associé est d'une grande pertinence. Je vous souhaite d'avoir suivi son conseil, et je dis cela en me basant sur votre question initiale et les interrogations qui l'entourent. Écrire un document de référence est une bonne idée, Utilisez-vous un outil de représentation de fonctionnalités du logiciel, style éditeur UML (attention, jargon ;-)) à un haut niveau d'abstraction (donc qui recense les fonctionnalités logiques de votre application)? Si ce n'est pas le cas, ce serait peut-être une idée à creuser, parce que cela permettrait de vous faire gagner du temps dans l'évaluation des réponses à votre appel d'offre ainsi que dans la phase de test et de validation.
Je reste à votre disposition ;-)