Projets sans spécifications détaillées
Peut-on réussir un projet qui démarre sans spécifications détaillées ? Et quand il s’agit de l’offshore ?
A travers mon expérience dans le domaine des services informatiques, j’ai constaté que les réalisations qui démarrent avec des spécifications définitives sont plutôt minoritaires. Mais en réunissant les bons ingrédients et en adoptant une bonne démarche on arrive très souvent à les réussir.
Ci dessous quelques facteurs qui permettent d’améliorer considrablement les chances de réussite d’un tel projet :
- impliquer fortement les utilisateurs au démarrage de la réalisation. Il est très bénifique de fournir un prototype le plutôt possible à l’utilisateur. Cette matérialisation des besoins, permet de concentrer les changements au début du projet et ainsi minimiser leur impact sur la charge de développement et ajuster les délais assez tôt.
- une architecture logicielle qui permet de une adaptation relativement facile aux besoins changeants des donneurs d’ordres. Par exemple, représenter les processus métiers dans des fichiers de configuration ou utiliser des mécanismes d’injection de dépendance.
- prévoir au moins une ressource, même à temps partiel sur le projet, dotée des qualités nécessaires pour communiquer avec les utilisateurs : bonne communication et une capacité de compréhension du métier.
- des livraisons partielles dans un processus itératif pour minimiser les écarts par rapport aux attentes du client.
Les clients potentiels de l’offshore sont souvent frileux à cause des contraintes relatives à la spécification des besoins. Chez IP-Tech on a réussi à plus qu’une fois à aider nos clients dans la rédaction des spécifications que ce soit en mode forfait ou régie délocalisée. L’expérience des développeurs et du management ont été des facteurs déterminants de cette réussite. En plus, la proximité géographique et linguistique ont facilité la communication avec les clients. Dans les grands projets, IP-Tech et ses clients, n’ont pas hésité à réunir leurs collaborateurs sur le meme site. Les coûts de déplacement se sont révélé un bon investissement qui a permis de maintenir la rentabilité de l’externalisation des développement.
Tags: Process, Projets, Spécifications
13 novembre 2009 à 16:10
Bonjour,
C’est qui l’auteur de cet artice?
A moins que j’ai pas bien lu , mais je ne trouve nul part le nom de l’auteur.
13 novembre 2009 à 16:15
Merci pour cet article.
Juste une question , est ce que vous connaissez pas une solution (un soft )qui permet d\’aider à écrire des specs ?
Je sais que écrire des specs peut être difficilement automatisée, mais on peut au moins décrire les workflows globaux , et les regles métiers, ce qui correspond à 80 % des specs..Je ne sais pas si vous etes d\’accord ?
4 décembre 2009 à 15:42
Bonjour,
Le rédacteur de cet article est l’un des chefs de projets de IP-Tech.
Honnêtement, on n’a jamais pensé à un générateur automatique de spécifications fonctionnelles. Et je n’ai pas compris ce que vous pourriez mettre en input à un éventuel outil tel que celui que vous recherchez.
Désolé, je ne peux pas aider. Mais si, depuis la rédaction de votre commentaire, vous avez trouvé un outil qui répond à votre besoin (même en parti) n’hésitez pas à partager l’information.
15 février 2010 à 13:16
Bonjour,
Dans nos jours, nous pouvons mieux gérer nos projets avec des méthodes qu’on utilise chaque jour. Il s’agit de la méthode Agile avec des scrum et backlogs qui peut vous ider à mettre des objectifs et des priorités.
Merci
–Adel
19 février 2010 à 14:19
@Adel
Je suis d’accord avec vous, parfois on n’a ni le temps ni les moyens de mettre en place des processus lourd. Donc les méthodes que vous avez citées, sont souvent un bon compromis pour réaliser des livrables de qualités, qui répondent aux besoins des clients sans beaucoup investir dans les spécifications. Bien évidemment, tout cela dépend aussi de la nature du projet, de son contexte et des engagements des différents intervenants.
14 septembre 2010 à 16:05
Dans votre article, vous avez mis en contraste les méthodes de développement classique (cycle en V, méthode en cascade, etc.) et les méthodes agiles. Les méthodes classiques sont caractérisées par une phase de spécification détaillée dès les phases précoces du développement logiciel. Petite problématique : la réalité est beaucoup plus complexe pour pouvoir tout spécifier et prévoir dès le début et la situation s’aggrave encore lorsque l’équipe technique se penche sur le développement sans une maitrise du domaine fonctionnel et sans être encadrée par un expert fonctionnel. En finit par construire non pas le logiciel demandé par le client mais un logiciel tel qu’il est imaginé par les développeurs logiciel.
Les méthodes modernes, dites agiles, impliquent aussi fort que possible le commanditaire/client dans un processus de développement itératif et incrémental pour créer une synergie entre l’expert métier et l’expert technique. Cette façon de procéder par itération (de courte durée) permet de construire des prototypes/versions de plus en plus évoluées du système à créer. De cette façon on évite le risque de dérives techniques (les développeurs codent le système tel qu’ils aiment voir au lieu du système que le client aime voir) et aussi aider le client à comprendre ce qu’il veut !!! N’oublions pas que généralement le client n’est pas un expert technique et les dizaines de lignes de spécifications abstraites n’ont pas le pouvoir d’expression d’un logiciel qui tourne devant le client.
Bien sûre il ne s’agit pas de développer dans l’obscurité, les méthodes agiles insistent sur la mise en place d’une architecture logicielle dès le départ, comme précisé dans votre article, flexible et qui s’adapte facilement au changement (dans une certaine mesure bien sûre et n’en pas dans l’absolu).
D’autre part, de mon expérience personnelle relativement courte (3 ans), j’ai remarqué que l’implication du client n’est pas du tout la même dans les différentes phases du projet : le client montre une implication forte et un enthousiasme au début du projet mais malheureusement au fur du temps et l’avancement du projet, comme si le client se lassait et ce n’est plus la même motivation comme au départ. Faut-il alors réviser les méthodes (agile), qui insistent sur le contact avec le client, pour donner plus de consigne/d’intérêt à la dimension humaine et les technique de communications ?