Analyse de vos besoins

 

Cette phase cruciale permet de cerner avec vous la problématique à résoudre. Elle nous permet également de comprendre votre contexte de travail pour que la solution que nous proposerons s'y intègre parfaitement.

Lors des échanges pour cette phase, nous sommes guidés par les objectifs suivants:

• Comprendre avec précision ce que l'outil à développer doit résoudre pour vous et améliorer dans votre quotidien.
• Cerner la place de ce nouvel outil dans vos processus, sans tabou quand aux processus eux-mêmes : par exemple, un petit changement organisationnel peut parfois décupler l'efficacité de outil informatique. Détecter et proposer ce changement fait alors partie intégrante de notre analyse et de notre proposition.
• Evaluer avec vous l'impact attendu du projet, ses limitations et risques éventuels, ainsi que ses éventuelles futures extensions.
• Entendre un ou plusieurs utilisateurs finaux de l'outil :  Cela nous permet d'affiner l'analyse des contraintes, d'adapter l'ergonomie de l'outil aux goûts de ceux qui l'utiliseront, tout en s'assurant de l'adoption de celui-ci dès le début.
• Formaliser l'ensemble des informations recueillies dans un document reprenant le contexte, le besoin d'affaires, l'objectif et les contraintes. Ce document doit être facilement intelligible pour toute personne familiarisée avec le fonctionnement de votre entreprise, et ne dois pas nécessiter de compétences informatiques. L'utilisation de "story-boards" est par exemple une pratique qui permet à tout les intervenants de s'entendre facilement sur les différents écrans, leur contenu, et la dynamique de passage d'un écran à l'autre.

 

Conception et proposition

 

Dans la seconde phase, nous nous attacherons à décrire très clairement la solution que nous proposons :

• son architecture technique : elle doit être puissante, évolutive, cohérente et simple (KISS). 
• ses contraintes et coûts de maintenance : Les minimiser c'est  pérenniser le produit fini.
• son interaction avec les utilisateurs : l'utilisation quotidienne du produit doit être un plaisir.
• son interaction avec d'autres systèmes informatiques en place ou a venir : fluide et exempte d'interventions humaines.
• son "look & feel" pour les aspects d'ergonomie et graphiques : Le produit doit être beau et intuitif.

 

Ensuite: de la flexibilité et de la constance

 

Lorsque le document d'analyse récolte l'aval de tous les acteurs de votre équipe concernés, la phase de développement va pouvoir débuter.

Autrefois, il était d'usage pour cette phase, de s'en tenir strictement au cahier des charges ainsi établi, et de n'interagir qu'un minimum avec les utilisateurs pendant cette période, pour finalement livrer un produit fini. 

Cette approche, très "administrative" suscite de nombreuses difficultés et frustrations par son manque évident de souplesse dans des environnements qui changent de plus en plus vite. Elle a donc été balayée ces dernières années par toute une série de méthodologies centrées autour d'une flexibilité accrue pendant le développement.

Chez Nicsys, l'expérience à montré que ce type d'approche, si elle trop prise au pied de la lettre, peut également amener son lot de difficultés. Elle peut en effet mettre en danger la stabilité ou la cohérence du produit, voire mettre en opposition les souhaits "immédiats" des utilisateurs avec la vision globale et long-terme du management.

Nicsys accorde dès lors une grande importance dans la gestion de projet à combiner le meilleur de ces deux approches, en évitant toute orthodoxie.