Cet article s’adresse surtout aux membres prestataires de Progonline.

Prestataires, vous êtes nombreux à critiquer le faible taux de concrétisation des projets. Tout d’abord, il est important de discuter sur des chifres réels. Ce taux de concrétisation a toujours été constant chez Progonline, autour de 1/3, ce qui est plutôt positif : 1 projet publié sur 3 est payé par le donneur d’ordres. De plus, les améliorations dans l’ergonomie de Progonline - coté client - laissent présager une augmentation de ce taux dans les mois à venir.

Par contre, de plus en plus de clients annulent les projets parce que les offres sont superficielles, copiées-collées, sans rien à voir avec les projets, non-pertinentes. Il n’est pas rare d’observer certains prestataires faire la même offre copiée-collée sur tous les projets, ce qui n’a que des effets néfastes : le prestataire fautif n’a AUCUNE CHANCE de gagner des appels d’offres, et se décourage. Le client est déçu, et annule le projet. Pour finir, la plateforme Progonline est discréditée, parce qu’elle hebèrge des prestataires peu professionnels.

Alors, si vous voulez réellement vous donner les moyens de gagner des projets sur Progonline, un conseil : lisez bien les projets, et faites des offres adaptées aux projets pour lesquels vous postulez. Faites sentir au client que vous avez compris son projet, et que vous êtes un professionnel !

Afin de partager avec toute la communauté Progonline notre savoir faire accumulé depuis la création de notre plateforme Internet, nous mettons en libre service notre méthodologie de travail à distance.

Ce wiki est consacré au travail à distance dans le cadre du développement informatique. L’expérience montre que le travail avec une équipe multilocalisée (ex. un développeur à Madagascar, un en France, et un en Roumanie, travaillant sur des tâches précises pour le même projet) est très économique, mais très difficile à organiser pour être efficace. Cet espace représente la capitalisation de notre experience de plus de 3 ans dans ce domaine, consultable gratuitement. Vous retrouverez probablement vos problèmes et certaines solutions que nous avons expérimenté. N’hésitez pas à le compléter avec vos remarques !

http://wiki.progonline.com

J’observe avec la plus grande attention et depuis longtemps les tarifs proposés par les divers prestataires sur les projets publiés sur Progonline. Un statistique rapide montre que dans approximativement 50% des cas, ces tarifs ne sont pas pertinenents, soit parce qu’ils sont trop bas, soit parce qu’ils sont trop élevés. Prestataires, voici quelques idées qui devraient vous guider vers une meilleure évaluation de votre offre. Cet article est également valable pour les clients, qui pourront mieux piloter leur processus de séléction d’un prestataire.

Prestataires, comment fixer le tarif pour un projet ?

Progonline est une plateforme qui facilite la réalisation de projets au forfait. Pour chaque projet, ce qui compte est le résultat final livré à la date finale, et non le nombre d’heures que le prestataire a passé pour le faire réaliser. Cela ne veut cependant pas dire que le prix des projets “sort du chapeau”. Cela ne veut pas dire non plus qu’il suffit de reproduire le tarif des autres prestataires pour faire une offre gagnante.

Voici UNE possibilité, pour fixer vos tarifs : posez des questions au client jusqu’à ce que le travail à réaliser est suffisamment précis et détaillé. Grâce à votre expérience, établissez le nombre d’heures approximatif que vous allez mettre pour réaliser le projet. Multipliez ce nombre par votre taux horaire, et vous arrivez au projet en cours. C’est la modalité la plus fiable. Les prestataires qui ont de l’expérience devraient uniquement travailler comme cela : avoir un tarif horaire élevé, mais travailler efficacement, ce qui fait un tarif global intéressant pour le client.

Voici UNE autre possibilité pour fixer vos tarifs (si vous avez moins d’expérience, et pour des prestations standard) : renseignez-vous sur des acteurs économiques fiables et connus qui font le même genre de prestation, et voyez le tarif. Par exemple, allez voir le prix d’une charte graphique sur templatemonster.com, et vous verrez le prix approximatif d’une telle prestation. Allez sur wilogo.com, et vous verrez les tarifs pour un logo. etc…Prenez leur tarif comme base, et augmentez-le ou diminuez-le en fonction des demandes du client/votre réputation sur Progonline/votre expérience, etc… Pour avoir de telles références de prix, prenez des exemples d’acteurs économiques solides, qui savent ce qu’ils font et qui gagnent de l’argent sur leurs prestations, et non des prestataires qui, comme vous, n’ont pas d’idée des prix à proposer.

Et le positionnement des prestataires français et offshore les uns par rapport aux autres ?

Ce paragraphe fait l’objet d’une refléxion marketing/stratégique, et non technique. Il est néanmoins essentiel de comprendre la distinction présentée, car elle explique le comportement d’un donneur d’ordres face à la sélection d’un prestataire sur Progonline.

L’idée, qui peut frapper à premier abord, est la suivante : à compétences et réputations égales, les prestataires offshore DOIVENT être moins chers que les prestataires français, d’au moins 30% - 40%.

Prestataires français : n’oubliez pas que vous pouvez appliquer un surplus tarifaire parce que vous assurez une proximité géographique et culturelle avec le client, qui lui facilitera le travail, qui lui permettra de communiquer plus vite son besoin. Ceci constitue un argument de vente important pour vous, que vous devez mettre en valeur. C’est un réel avantage au cours du déroulement du projet.

Prestataires offshore : n’oubliez pas que lorsque le client français fait appel à vous, il mettre plus de temps à vous expliquer son projet, il ne pourra probablement pas vous appeller, il devra vous faire des cahiers de charges plus précis/détaillés. Il est normal que ces difficultés soient compensées par une économie d’argent plus importante de sa part.

Dans ces conditions, et à compétences égales, inutile pour les prestataires offshore de proposer des tarifs aussi élevés que ceux des prestataires français. Il ne s’agit pas d’exploitation ni d’injustice, mais tout simplement de la facilité du client à travailler avec vous.

Recommandations aux clients, pour la sélection d’un prestataire

Les tarifs trop faibles, à moins que le prestataire puisse faire preuve de références solides dans le domaine, sont à écarter, pour éviter de vous retrouver avec des prestataires peu professionnels.

A tarifs, réputation et compétences égales, préférez le prestataire français, si possible près de votre lieu de résidence.

Pour résumer, voici les recommandations :

• prestataires offshore et français, faites attention à vos tarifs, et ne proposez pas des tarifs “juste parce que les autres l’ont fait”
• prestataires offshore, soyez 30% moins chers que vos homologues français
• clients, ayez conscience qu’à compétences égales, un prestataire français communiquera avec vous plus facilement qu’un prestataire offshore (même parfaitement francophone - marocain, malgache, tunisien, etc…).

Le problème

Suite à de nombreux incidents de fin de projet, sur Progonline, nous avons pu sélectionner un certain nombre de points qu’il est important d’établir dès le début pour votre projet web. Cela vaut pour le client, mais également pour le prestataire. A la fin du projet, quand ces problèmes apparaissent, c’est trop tard, et le projet prend du retard. Prestataire et client entrent souvent en conflit pour cette raison.

La solution

• Définissez pour quels navigateurs et quelles versions le site web doit-il être compatible. Les clients ont le reflexe de demander ou de sous-entendre “compatibilité toutes versions, tous navigateurs (MAC, PC, IE toutes versions, FF toutes versions, Conqueror, Mozilla, etc.)”. Bien évidemment, ce n’est pas possible. Si on peut obtenir une compatibilité pour 95% des utilisateurs (il suffit de prendre les 2 dernières versions de Internet Explorer et Firefox), aller au delà est très difficile et onéreux. Sauf cas spécifiques, l’intérêt de tout le monde est de s’arrêter à ce niveau. Précisez explicitement dans votre cahier de charges les navigateurs pour lesquels il faut assurer la compatibilité, cela vous servira à la fin.
• Définissez la/les résolutions pour lesquelles le site web doit être compatible/optimisé. Même remarque que précédemment, peu de sites offrent une compatibilité toutes résolutions. Ils ont de surcroît un graphisme minimaliste et un template particulier (tout est concentré en haut à gauche). Mentionnez clairement les résolutions pour la réalisation du projet web.
  
• Faites attention aux problèmes liés à la différence d’environnement entre le serveur de test/développement et le serveur de production. Très souvent, le prestataire développe le projet sur son propre serveur, sur lequel il a un certain environnement, avec certaines versions, avec des droits le plus souvent absolus. Le site fonctionne parfaitement chez lui, mais lors du déploiement sur le serveur du client, le prestataire rencontre de sérieux problèmes :
  • la version PHP et MySQL n’est pas la même que chez lui;
  • il n’a pas accès aux crontab;
  • il n’a pas accès root à la machine;
  • il ne peut modifier le fichier php.ini;
  • il n’y a pas d’accès https;
  • etc…

Dans ce genre de cas, le mieux est de s’y préparer à l’avance, soit en développant directement sur le serveur du client, soit en synchronisant systématiquement, soit en lui spécifiant clairement qu’il devra acheter un serveur avec des droits absolus pour le déploiement de son site sur l’environnement de production. Sinon, il devra vous indiquer ce qu’il va acheter, et vous devrez vous y adapter.
Recommandation

Dans le cahier de charges, introduisez une clause : Limites du projet. Dedans, mettez toutes les limitations “sensibles”, telles que les 3 points évoqués plus haut. Pour prévenir dans une certaine mesure les sous-entendus, introduises aussi la limite suivante :

“la réalisation de ce projet ne comprend que les modules/fonctionnalités explicitement mentionnées dans ce cahier de charges. Tout module supplémentaire fera l’objet d’un cahier de charges et d’un budget supplémentaires”.

Dans le cas d’un arbitrage, cette mention n’aura de valeur que dans le cadre de fonctionnalités supplémentaires majeures, hors des us et coutumes de la typologie de projet que vous réalisez. Néanmoins, elle peut faire refléchir le client plus attentivement avant de valider le cahier de charges initial.

Le problème

Vous venez de tomber sur un projet intéressant sur Progonline, pile-poil dans votre domaine de compétences. Vous avez déjà réalisé un projet semblable, vous avez un peu de temps la semaine prochaine, et vous voulez le gagner. Mais manque de bol, le client n’a pas de spécifications précises, il ne les a pas rédigées (soit parce qu’il ne sait pas, ou il n’a pas le temps, ou il ne veut pas). En prestataire sérieux et professionnel que vous êtes, vous ne pouvez vous engager sur un forfait sans un cahier de charges précis.

Qu’est-ce que vous devez faire ?

La solution

Nous vous rappellons que le cahier de charges est LE document qui représente la pierre angulaire de tout le système de fonctionnement Progonline : délais de réalisation, coût, arbitrage/médiation, tout découle de ce document !

Voici une recommandation pour vous :

1. Tout d’abord, demandez expressément au client s’il dispose d’un cahier de charges, ou d’une description plus précise du projet.
   1. soit il dit OUI, et vous lui demandez de vous le communiquer
   2. soit il dit NON. Dans ce cas, attention ! Ne pas lui demander sèchement de cahier de charges, car très probablement il dira ‘OK’, et vous ne le reverrez plus jamais : pour un non professionnel informaticient, un cahier de charges est généralement quelque chose d’obscur et rébarbatif. Donc, s’il n’a pas de cahier de charges, demandez-lui s’il peut vous en fournir un OU s’il prefère que vous le fassiez pour lui (option importante)!
      
2. Si c’est vous qui rédigez son cahier de charges, faites-le en 2 temps :
   1. tout d’abord, AVANT d’avoir gagné l’appel d’offres, vous en faites un sommaire (les fonctionnalités principales). Cela vous permet de comprendre ce qu’il souhaite dans les grandes lignes, et de proposer un tarif.
   2. APRES avoir gagné le projet, discutez plus en détail sur le cahier de charges, définissez-le et rédigez-le, de commun accord avec le client. Postez-le sur le rapport du projet, et obtenez un accord formel écrit également sur le rapport du projet par le client (”OUI, je suis à 100% d’accord avec le cahier de charges proposé”)

Vous avez suivi cette recommandation ? Bravo, vous avez gagné le projet, vous avez un cahier de charges précis, c’est bon, maintenant vous pouvez commencer à travailler en toute sécurité !

Une petite remarque : en tant que prestataire, si vous pensez que cela vous fait plus de travail, que de rédiger un cahier de charges, pensez à 2 choses :

1. la rédaction du cahier de charges est une prestation comme toutes les autres, indispensable dans le processus de réalisation d’un projet. Si le client ne l’a pas fait, vous devez l’inclure de manière intrinsèque et statistique dans vos tarifs.
2. si c’est vous qui rédigez le cahier de charges, vous avez la garantie d’avoir parfaitement compris ce qu’il y a dedans, et de maîtriser le projet (normal, c’est vous qui le rédigez). Vous pourrez ainsi être très précis sur certains points qui vous paraissent sensibles, de poser les limites du projet à votre convenance.

Le problème

Très souvent, sur Progonline et ailleurs, les prestataires reçoivent des réclamations de la part des clients pour avoir fourni des applications “truffées de bugs”.

Le client a souvent l’impression que l’application n’est pas testée, et que le prestataire fournit un travail de mauvaise qualité, et/ou qu’il est de mauvaise foi.

A l’inverse, le prestataire a l’impression d’avoir bien testé l’application, et se plaint que le client n’explicite pas les problèmes qu’il rencontre : “ça marche pas”, “il y a des bugs”, “j’ai une erreur”, etc… ne permettent pas de résoudre les problèmes rencontrés.

La vérité sur les bugs

Tout projet informatique, qui dépasse le cadre élémentaire (qui est dépassé dans 99% des cas usuels) contient des bugs.

Il est vrai que :

• certains prestataires ne testent pas du tout leurs applications

Cependant :

• le développeur qui a conçu l’application s’est construit des schémas mentaux de son utilisation, et ne verra pas certains bugs. Il n’utilisera jamais l’application qu’il a conçue comme un réel “utilisateur ordinaire”.
• les applications sont très sensibles à l’environnement technique dans lequel elles roulent. Il est donc tout à fait possible que l’application tourne bien sur l’environnement de test du prestataire, mais pas sur celui du client.

La solution

Voici comment il faut gérer la problématique des bugs, autant du coté client que prestataires. Si les conseils suivants sont suivis, le nombre de bugs apparus diminuera rapidement, selon une courbe asymptotique vers 0.

Pour les prestataires :

• décomposer tout projet en fonctionnalités élémentaires, testables une à une. Prévoyez un temps important pour tester (vous ou vos collaborateurs) l’application.
• avant la livraison finale du projet, prendre toutes les fonctionnalités et les tester
• demander si possible à d’autres personnes de tester à votre place, elles détecterons plusieurs bugs, et seront plus efficace que le concepteur de l’application

Pour les clients :

• allouez un temps important au test de votre application en développement. Ne vous imaginez pas qu’un projet informatique est livré “clé en main”, sans aucun effort de votre part.
• soyez explicite dans le signalement de vos bugs. Détaillez au maximum, quitte à faire des copier-coller d’écrans (screenshot), pour illustrer votre propos.

Pour les clients et les prestataires :

• utilisez des outils de gestion de bugs. Il s’agit d’outils web qui permettent de signaler les bugs rencontrés, et de les classer selon leur gravité, priorité et état (résolu, en attente, fermé, etc…) De cette manière, plus rien ne vous échappe. Les outils web les plus connus sont Bugzilla et Mantis, mais il en existe beaucoup d’autres sur Internet (gratuits, en open source, en plus). Progonline utilise Mantis.

Le problème

Ce point de méthode donne quelques solutions autant préventives (faire en sorte que cela n’arrive pas) que curatives (gérer une telle situation de crise) au prestataire qui se trouverait face à une situation comme celle-ci : un cahier de charges a été rédigé, et lie le prestataire et le client dans le cadre de la réalisation du projet. Cependant, le client change d’avis sur ce qui doit être réalisé en cours de route, soit par un rajout de fonctionnalités soi-disant “sous-entendues” dans le cahier de charges, soit directement par l’annulation des spécifications du cahier de charges, pour les remplacer par d’autres.

La plupart du temps, ceci intervient pour plusieurs raisons :

• le client n’est pas assez associé au processus de développement, i.e. il prend vraiment connaissance de ce qui a été réalisé quand c’est malheureusement trop tard. Très souvent, l’expérience montre que le client “se réveille” au moment où le projet doit être finalisé, et qu’il doit payer le solde pour finalisation.
• le client a l’impression que sa demande est juste un “petit détail rapide”, alors qu’en réalité cela remet en cause la structure même du projet
• le client est perfectionniste et retarde potentiellement à l’infini la finalisation du projet pour se donner du temps de faire corriger au prestataires tous les petits détails de style, couleur, etc…
• mais aussi, dans un nombre restreint de cas, par … mauvaise foi.

Ce qu’il ne faut surtout pas faire dans cette situation

Le prestataire de bonne foi est fortement tenté d’obtempérer à la demande du client, et de réaliser ce qu’il souhaite. Seulement, comme c’est du travail supplémentaire, cela boulverse le développement et le timing. De surcroît, le projet tend à se perdre dans les détails, ce qui le complique au delà du raisonnable. Le projet prend du retard, sa complexité augmente, et le prestataire n’arrive plus à le gérer. Il est à ce moment-là responsable.

Ce qu’il faut faire dans cette situation

Bien évidemment, il n’y a pas une solution miracle, mais plusieurs réponses possibles, qu’il faut combiner :

• solutions préventives - faire en sorte que cela n’arrive pas :
  • dès le début, lors de la rédaction du cahier de charges, communiquer clairement au client que ce cahier de charges représente le document sur lequel vous vous êtes basé autant pour le tarif et pour l’echéancier, que pour la structure interne du développement. Il ne sera pas possible de le changer en cours de route.
  • faire valider systématiquement au client les étapes intermédiaires dans la réalisation du projet, et faire en sorte qu’il donne son accord formel (signature, email explicite), à chaque étape.
• solutions curatives - c’est arrivé, qu’est-ce que je dois faire :
  • laisser la modification à la toute fin du projet. Cela vous permettra de tenir vos délais de développement, et gagner la confiance du client, car vous avez tenu votre engagement. Il investira un montant supplémentaire pour les modifications plus volontiers s’il est assuré.
  • pour les détails de fin de projet qui n’en finissent plus, proposez contractuellement avec le client un délai pendant lequel il a le droit de signaler ce genre de détails. Quand ce délai est dépassé, toute modification supplémentaire sera payante.

Voilà comment il faut définir un cahier de charges pour une charte graphique de site Internet, pour avoir le maximum de chances de succès. Il faut se poser plusieurs questions et définir son besoin de la manière suivante :

• HTML pur, HTML/Flash mixte, ou Flash pur ?
• à qui s’adresse le site ?
• quelles couleurs/nuances faut-il appliquer ?
• présentez plusieurs sites internet existants, ou templates qui ressemblent plus ou moins, ou “sont dans le genre” de ce que vous cherchez (par exemple, sur templatemonster.com, il y a des dizaines de milliers de templates, certains ressemblent à ce que vous cherchez). Présentez éventuellement plusieurs templates, dont chaqun a une partie qui ressemble à ce que vous cherchez (ex, la bannière d’en haut semblable à celle du template 1, les nuances semblables à celles du template 2, et les photos dans le même style que celles du template 3, etc.).
• si vous avez une idée plus ou moins précise de ce que vous voulez, faites un croquis de ce que vous cherchez sur papier, scannez-le et fournissez-le

Avec ces éléments fournis, client et prestataire peuvent se mettre plus facilement d’accord, et éviter les malentendus liés à la subjectivité (j’aime/j’aime pas), qui interviennent souvent dans le cadre de la réalisation de travaux artistiques.

Progonline vous livre les secrets de la gestion de projet offshore

Cet article représente le premier d’une longue liste de points de méthodologie que Progonline publiera sur ce blog.

Depuis la création de notre société, nous avons suivi de près plus de 300 projets publics réalisés, et un nombre très importants de projets privés. Parallèlement à notre place de marché déjà bien connue, nous avons également participé à la réalisation de projets de grande envergure, représentant plusieurs années-hommes, comme par exemple un progiciel de veille stratégique sur Internet, qui aujourd’hui dessert plus de 200 sociétés, et qui . Ce projet a été intégralement réalisé en offshore, avec une équipe de 5 développeurs roumains pendant plus de 6 mois.

Nous avons donc acquis de solides connaissances en matière de gestion de projet offshore, que nous souhaitons partager avec vous, clients ET prestataires. Nous souhaitons procéder ainsi, car très souvent, les projets avortés ne proviennent pas (que) de mauvaise foi ou manque de compétence, mais surtout à cause d’incompréhensions qui pourraient être évités certaines techniques étaient utilisées.

Ces articles seront mentionnés à chaque fois avec “Point de méthodologie : …”. Nous vous recommandons fortement de les lire, pour une réalisation de projets à distance toujours plus performante, rapide, et de bonne qualité.

Point de méthodologie : comment assurer un suivi de projet performant ?

La méthode itérative et en cascade

La théorie du génie logiciel propose 2 modalités principales de développement informatique : la méthode itérative et la méthode en cascade. La méthode itérative suppose des itérations (cycles de développement, ç’est à dire versions progressives fonctionnelles du projet) courtes et fréquentes. La méthode en cascade suppose au contraire des itérations majeures et rares.

Pour simplifier, on dira que la méthode itérative suppose une application fonctionnelle (de manière limitée immédiatement), donc “on voit” l’application se développer au fur et à mesure, alors que la méthode en cascade suppose un développement de l’application qui sera uniquement visible à la toute fin.

La méthode itérative est un peu plus lente, car elle suppose la réecriture du code source sans cesse, pour y greffer les nouelles fonctionnalités. Par contre, elle a l’avantage de permettre au client une observation continue de l’avancement. La méthode en cascade a l’avantage d’être mieux écrite, plus performante, car tout est pris en compte dès le début. Par contre, l’application n’est présentable qu’à la fin du développement, n’étant pas fonctionnelle avant.

Le travail à distance : appliquer toujours la méthode itérative !

Lors de la réalisation des projets à distance pour de nombreuses raisons, vous devez systématiquement utiliser la méthode itérative :

• le travail à distance suppose une communication plus pauvre entre client et prestataire. De surcroît, le prestataire n’a probablement pas les même références culturelles et linguistiques que vous (même s’il est francophone). De nombreux de ce fait se créer, dûs tout simplement au fait que le prestataire ne comprend pas la même chose que le client. Une application que le client voit avancer au fur et à mesure réduit les risques de malentendus, car si le prestataire a mal compris une requête, le client le verra tout de suite et le réorientera. A l’opposé, si le client ne peut pas voir l’application, il se rendra compte du malentendu à la fin du projet, quand ce sera trop tard (ou en tout cas quand le coût de la correction sera bien plus grand).
• le travail à distance suppose très souvent une attitude exploratoire dans les relations entre client et prestataire. Un client qui travaille la première fois avec un prestataire souhaite être rassuré au fur et à mesure du développement, et non pas attendre “dans le noir” le résultat d’une expérience risquée. Ceci sera bénéfique pour le client autant que pour le prestataire, qui sera sur la même longueur d’onde que le client. Si le projet n’avance pas pour des raisons de compétence du prestataire, le client le verra rapidement, durant les premiers jours.
• les applications informatiques sont toujours plus difficiles et longues à réaliser qu’initialement prévu. Ceci est une réalité statistiquement prouvée (pas à 100%, mais pas loin ). Systématiquement, clients et prestataires la sous-estiment. Une obligation de réaliser à des intervalles très courts des fonctionnalités supplémentaires oblige le prestataire à prendre en compte la compléxité du développement, et avoir un indicateur fiable de l’avancement du travail. Trop souvent des prestataires, même très bons, ont l’impression qu’ils vont réaliser tel projet en 3 jours, et s’y mettent pendant le week-end qui precède la date de livraison. Même s’ils mettent toute la bonne volonté du monde, ils seront en retard, et le client sera lésé.

Aspects pratiques : comment travailler avec la méthode itérative ?

Décomposez votre application en de nombreuses petites ou très petites fonctionnalités, de manière à ce que chaque fonctionnalité prenne un jour ou moins de développement. Le prestataire doit alors vous tenir au courant, par écrit, mais également par l’application qu’il a réalisé et qui doit être fonctionnelle, tous les jours ou tous les 2-3 jours, de ce qui a été réalisé durant ce laps de temps. Il ne doit pas seulement vous dire que c’est fait, vous devez pouvoir vous en rendre compte vous même par test de l’application.

Sur un graphique sur lequel vous avez le temps en abscisse et le nombre de fonctionnalités en ordonnée, la courbe représentant les fonctionnalités réalisées en fonction du temps doit être approximativement une droite (et non pas une exponentielle ou une parabole). Vous n’êtes pas obligé d’aller jusqu’à ce niveau de détail, mais vous pouvez faire des petits calculs par vous même (ex. on est arrivé à la moitié du délai prévu, combien de fonctionnalités restent à implémenter) ?

Grâce à un suivi régulier et pratiquement en temps réel du projet, ce dernier aura plus de chances de se solder par un succès.

Pour en savoir plus : http://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement

Grâce à sa visibilité de plus en plus importante sur Internet, Progonline reçoit de plus en plus de demandes de devis de la part de donneurs d’ordres intéressés. Il commence à se dégager 2 grandes catégories de projets :

• les projets fournis par des professionnels, informaticiens, développeurs, disposant de cahiers de charges précis,  avec des attentes réalistes en termes de rendu, délais, solutions techniques. Ces donneurs d’ordres sont les candidats idéaux à la soustraitance en télétravail, offshore éventuellement. Ils cherchent des prestataires qui soient à la fois professionnels et qui pratiquent des tarifs très compétitifs. Les montants pour ce genre de projets va jusqu’à 3000 euros.
• les projets à budgets plus importants fournis par des clients finaux. Ces projets sont de plus en plus nombreux sur Progonline et font l’objet de cet article. Ils sont caractérisés par les éléments suivants :
  • budgets entre 5000 et 50 000 €.
  • expression des besoins sommaire, voire inexistante. Pas de cahier de charges, au mieux une expression fonctionnelle peu détaillée.
  • fort besoin d’accompagnement, de conseil, et d’orientation vers de solutions techniques adaptées.

Comment Progonline traite les projets à gros budget

Ces projets sont caractérisés par une forte nécessité d’accompagnement, de définition du besoin, et de conseil. Nous sommes fortement attachés à une satisfaction du client complète, raison pour laquelle nous l’accompagnons de la prise de contact initiale, jusqu’à la signature du contrat avec un prestataire, français ou offshore.

1. Tout d’abord, un premier contact est établi avec le client, pour avoir un premier aperçu de son projet et pour faire connaissance.
2. Nous rédigeons le cahier de charges fonctionnel de l’application, et conseillons le client sur les solutions techniques possibles. Notre intérêt est le même que le votre : vous faire disposer de la meilleure solution pour votre projet, selon vos impératifs (budget, urgence, performance, etc…). Nous n’essayons pas de vous vendre des solutions toutes faites, ou une technologie plutôt qu’une autre, ou encore un développeur seulement parce qu’il est disponible au moment où vous souhaitez faire réaliser votre projet.
3. L’appel d’offres est ensuite lancé, pour séléctionner les sociétés ou freelances compétents, dans notre base de données de prestataires qualifiés et évalués par les donneurs d’ordres sur les projets déjà réalisés (plus de 3500 prestataires à l’heure actuelle, plus de 30 pays, 50% en France). Progonline dispose d’une base de données très larges de prestataires informatiques, français, offshore, offshore avec front-office en France, sociétés, freelance, etc…
4. A l’issue de cet appel d’offres, Progonline prend contact avec le client, et présente les prestataires et leurs propositions, dégage les possibilités de négociation, toujours en accord avec l’historique des prestataires, et au vu de l’éxpérience que Progonline a pu accumuler dans la relation avec eux. Les options sont discutées, Progonline peut émettre un avis, mais la décision finale est prise par le client.
5. Une fois le contrat signé, Progonline s’intéresse à votre relation avec le prestataire, pour s’assurer que tout avance comme prévu. Cette expérience servira à qualifier encore plus le prestataire, et apprendre encore plus sur sa capacité à gérer la relation client, à respecter les délais, à assurer une communication efficace, etc… Nous évaluons les prestataires selon des critères objectifs de performance.

Cette prestation est entièrement gratuite pour le client, et sans engagement. Nous nous rémunérons directement à partir du prestataire, à partir du moment où il y a accord entre ce dernier et le client (à hauteur de 15% également).