Mise en place de l’organisation

Avant de démarrer un cycle en V pour la fabrication à proprement parler du système de télémarketing, il a fallu réaliser quelques travaux nécessaires à l’organisation du projet en vue de le mener à bien.

4.1.1. Planification

Le système devant être livré pour la version majeure 13.3.0, le premier travail a consisté à s’informer du planning mise en place (tel que défini à la rubrique 1.2.5 « Cycle de vie des versions ») pour en extraire les différentes parties et les différentes périodes de réalisation allouées à chaque phase de ces parties.

La version 13.3.0 est divisée en 4 Package :  Package 1 (P1) :

o Du 24/05 au 14/06 : spécifications ;

o Du 17/06 au 05/07 : développements et tests unitaires ; o Du 09/07 au 02/08 : tests de validation ;

o Du 22/07 au 16/08 : tests de recette.  Package 2 (P2) :

o Du 21/06 au 19/07 : spécifications ;

o Du 22/07 au 09/08 : développements et tests unitaires ; o Du 12/08 au 30/08 : tests de validation ;

o Du 19/08 au 13/09 : tests de recette.  Package 3 (P3) :

o Du 02/08 au 23/08 : spécifications ;

o Du 26/08 au 06/09 : développements et tests unitaires ; o Du 09/09 au 27/09 : tests de validation ;

o Du 16/09 au 04/10 : tests de recette.  Package 4 (P4) :

PARTIE II : CADRAGE ET MISE EN OEUVRE

Implémentation de la solution

o Du 23/09 au 27/09 : développements et tests unitaires ; o Du 30/09 au 11/10 : tests de validation ;

o Du 07/10 au 18/10 : tests de recette.  Go / No go : 08/11 ;

 Mise en production : 23/11.

Le planning complet est disponible en annexe. Ce planning est intéressant sur plusieurs points :

 Il permet de connaître le nombre de jours ouvré disponible à la réalisation des spécifications et à la réalisation des développements pour chaque partie;

 On remarque que la période allouée aux spécifications du P3 se chevauche avec la période de développement du P1, cela se répète également avec le P4 vis-à-vis du P3, il va donc falloir optimiser au mieux le champ d’action des intervenants sur le projet;

 Corrélé aux ressources disponibles, cela va permettre de réaliser un découpage du projet en plusieurs étapes pour que la charge de travail totale (évaluée à 117 JH) soit répartie sur ces quatre parties, chaque étape étant finalisée par un livrable.

Mon travail a alors consisté en l’établissement des dépendances entre les fonctionnalités du système afin d’établir un ordre de réalisation.

Pour ce faire, j’ai utilisé le principe de Work Breakdown Structure (WBS) décrit dans le PMBOK (Project Management Body Of Knowledge) qui me permet de découper le projet en livrable en prenant en compte les aspects temps, ressources, dépendances.

Ce dernier point est important car j’ai identifié des composants à développer dépendant d’autres composants, rendant la phase de développement complexe par rapport aux délais accordés : mieux vaut - il travailler en parallèle sur deux périmètres différents quitte à développer des « bouchons » pour simuler les composants manquants en cours de développement lorsqu’il y en a besoin ou bien est-il plus simple de réaliser les éléments dans l’ordre et ainsi risquer de sous-exploiter les ressources disponibles?

PARTIE II : CADRAGE ET MISE EN OEUVRE

Implémentation de la solution

C’est en cela que la WBS est utile : elle permet un découpage en activités et tâches, plus facile à affecter pour optimiser au mieux les ressources dans le temps imparti et sans risquer de se retrouver en attente d’un autre composant du projet.

Le système télémarketing n’étant pas la seule évolution à embarquer dans la version majeure 13.3.0, ceci permet au responsable de projet de pouvoir réaffecter des ressources sur d’autres sujets en optimisant au mieux le planning (les ressources et les durées sont partagées pour l’ensemble des évolutions de l’application).

Le projet de télémarketing est le plus important de la version 13.3.0, cela signifie que les ressources disponibles sont mobilisables en priorité pour ce projet et pourront travailler sur d’autres évolutions lorsqu’elles auront terminé les tâches qui leurs sont confiées.

Voici les chiffres que j’ai relevés et qui m’ont été utiles :

 Charge de travail : 85 jour / homme pour la spécification et les développements. o Spécifications : 32 jour / homme ;

o Développements : 53 jour / homme ;

o La charge de travail estimé pour les tests concerne l’équipe de validation et ne fait donc pas parti du périmètre.

 Durée du P1 : 30 jours. o Spécifications : 15 jours ; o Développements : 15 jours.  Durée du P2 : 40 jours. o Spécifications : 20 jours ; o Développements : 15 jours.  Durée du P3 : 25 jours. o Spécifications : 15 jours ; o Développements : 10 jours.  Durée du P4 : 20 jours. o Spécifications : 15 jours ; o Développements : 5 jours.  Ressources disponibles : o Analyste fonctionnel : 1 ;

PARTIE II : CADRAGE ET MISE EN OEUVRE

Implémentation de la solution

o Développeurs : 2.

J’ai ensuite repris le découpage par cas d’utilisations que j’avais réalisé lors de la phase d’étude (3.5.3 « Estimations des développements spécifiques »), chaque cas d’utilisation correspondant à un composant livrable, afin de déterminer d’éventuelles dépendances pour définir les priorités de réalisation.

Le travail de définition des priorités figure dans le tableau suivant :

Tableau XI. Dépendances et priorités de réalisation des cas d’utilisations.

Cas

d’utilisation Description Remarques Dépendance Priorité

Paramétrage Paramétrage des rôles et profils

1

UC-001 Créer un utilisateur télémarketing

Paramétrage 2

UC-002 Créer une équipe télémarketing

Paramétrage 2

UC-003 Définir les paramètres de l’application

- 4

UC-004 Créer une campagne télémarketing

Nécessite d’être utilisateur (UC-001).

UC-001 3

UC-005 Gérer les prospects de la campagne

Nécessite d’avoir des utilisateurs (UC-001). Nécessite d’avoir des équipes (UC-002).

UC-001 UC-002

3

UC-006 Marquer un compte dans une campagne

Nécessite d’avoir une campagne (UC-004).

UC-004 6

UC-007 Visualiser les prospects à appeler

Nécessite d’avoir une campagne (UC-004). Nécessite d’avoir des prospects (UC-005).

UC-004 UC-005

PARTIE II : CADRAGE ET MISE EN OEUVRE

Implémentation de la solution

UC-008 Gérer un appel Nécessite de visualiser la liste d’appel (UC- 007). Nécessite d’interroger les paramètres de l’application (UC-003). UC-007 UC-003 5

UC-009 Convertir un prospect Nécessite d’avoir un appel en succès (UC- 008).

UC-008 6

J’ai ensuite communiqué ces résultats au responsable du projet qui a pu établir un planning de réalisation.

Il a été décidé de découper la RFC originale en quatre RFC, correspondant chacune à un ensemble de cas d’utilisations pour un package afin d’avoir un suivi dans l’outil de gestion des changements (HP ALM).

Ainsi :

 RFC principale : RFC 42234 Telemarketing in Copernicus ;  RFC livrée en Package 2 : n° 43595 ;

 RFC livrée en Package 3 : n° 43596 ;  RFC livrée en Package 4 : n° 43597.

Tableau XII. Répartition des cas d’utilisations en RFC.

Cas d’utilisation Description Package RFC _livraison Date de

Paramétrage Paramétrage des rôles et profils P2 43595 09/08 UC-001 Créer un utilisateur télémarketing P2 43595 09/08 UC-002 Créer une équipe télémarketing P2 43595 09/08 UC-003 Définir les paramètres de l’application P2 43595 09/08 UC-004 Créer une campagne télémarketing P2 43595 09/08 UC-005 Gérer les prospects de la campagne P2 43595 09/08 UC-006 Marquer un compte dans une campagne P3 43596 06/09 UC-007 Visualiser les prospects à appeler P3 43596 06/09

PARTIE II : CADRAGE ET MISE EN OEUVRE

Implémentation de la solution

UC-008 Gérer un appel P3 43596 06/09

UC-009 Convertir un prospect P4 43597 27/09

4.1.2. Répartition des tâches

Le responsable de projet a pu définir un planning de réalisation par rapport à la charge de travail, au temps alloué et aux ressources disponibles.

J’ai été désigné Analyste Fonctionnel du projet, c’est donc à moi qu’incombe le travail de réalisation de spécification fonctionnelle qui consiste à rencontrer l’équipe métier sur des sujets précis, collecter les besoins, rédiger les spécifications, réaliser les revues et assurer le suivi.

J’ai également été désigné Développeur pour le périmètre suivant : UC-001, UC-002, UC-003, UC-004, UC-006 et UC-007.

Le développeur Andry Ramarijaona a été désigné pour le périmètre suivant : UC-005, UC-008 et UC-009.

Le travail de Développeur consiste à implémenter des fonctionnalités spécifiées, réaliser des tests unitaires et assurer le suivi des anomalies qui pourraient apparaître sur son périmètre.