Quelles que soient les raisons, vous pouvez être amené à changer d'équipe de prestataire de développement Drupal.
Retrouvez ici le support ayant servi lors de la conférence Drupagora (Reprise d'un projet Drupal).
Pour plus d'information retrouvez également la video de la conférence à cette adresse : http://www.youtube.com/watch?v=7qIZuBl7vcc#t=22
2. Au programme
> Introduction
> Anatomie d’un projet Drupal
> Etablir l’état des lieux
> Définir une stratégie de reprise
> Appliquer le plan de reprise
4. Project recovery
Un
projet
est
en
difficulté
et
nécessite
la
mise
en
place
d’une
stratégie
de
reprise
(project
recovery)
si
:
• Le
budget,
le
périmètre
ou
le
planning
ne
sont
plus
tenables
• La
qualité
globale
n’est
pas
sa)sfaisante
• Les
aKentes
client
(ou
u)lisateur)
ne
peuvent
être
sa)sfaites
5. Chiffres clés
Terminated
Failed
Recovered
6%
12%
Zone
de
risque
25%
Successful
37%
des
projets
nécessitent
la
mise
en
place
d’un
stratégie
de
recovery
47%
7. Approche classique en « V »
• Chef
de
projet
• Lead
technique
• Lead
technique
• Développeur
• Chef
de
projet
• Spécifica)ons
fonc)onnelles
• Graphisme
• Planning
• Code
source
• Documenta)on
technique
• Forma)on
• Applica)on
en
produc)on
8. La phase de conception
Définir
le
périmètre
fonc1onnel
et
technique
du
projet
Prototype
• Circuits
de
naviga)on
• Ergonomie
Chef
de
projet
• Produit
les
livrables
de
concep)on
en
collabora)on
avec
le
client
• Planifie
le
développement
Spécifica1ons
fonc1onnelles
• Modèle
• Règles
de
ges)on
Lead
technique
• Evalue
les
impacts
techniques
• Evalue
la
charge
• Planifie
le
développement
Créa1on
graphique
• Iden)té
visuelle
• Ergonomie
9. Les indispensables spécifications
fonctionnelles
• décrivent
exhaus)vement
le
périmètre
fonc)onnel
• d’elles
découlent
:
• Le
découpage
projet
• Les
scénarios
de
test
• Le
cadre
contractuel
• deviennent
la
bible
des
développeurs
Chef
de
projet
Lead
technique
(support)
10. La phase de développement
Implémenter
les
documents
de
concep1on
Lead
technique
• Affecte
les
tâches
• Suit
l’avancement
et
les
temps
des
développeurs
• Est
responsable
des
points
client
Chef
de
projet
• Effectue
les
receKes
internes
• Est
responsable
de
la
rentabilité
Développeur
• Réalise
les
développements
• Remonte
ses
temps
par
tâche
11. La phase de développement
Le
document
d’architecture
• Documente
la
structure
technique
du
développement
• Explique
let
liste
les
modules
u)lisés
• Sert
de
base
de
connaissance
au
desk
de
TMA
Lead
technique
12. La phase de développement
Le
respects
des
bonnes
pra1ques
de
développement
Drupal
•
Ne
jamais
modifier
le
cœur
de
Drupal
ni
les
modules
communautaires
•
Eviter
les
paramètres
«
harcodés
»
•
Packager
les
paramétrages
et
les
objets
du
site
avec
le
module
Features
•
Ne
pas
«
réinventer
la
roue
»
et
chercher
des
solu)ons
dans
la
communauté
•
Respecter
les
standards
de
qualité
de
code
13. La phase de réception
Accompagner
l’équipe
cliente
dans
la
mise
en
conformité
des
livrables
Chef
de
projet
• Organise
la
receKe
• Qualifie
les
anomalies
• Priorise
le
traitements
des
anomalies
Lead
technique
• Organise
le
transfert
de
compétence
de
l’équipe
de
développement
à
l’équipe
de
TMA
14. Nous
venons
de
décrire
le
meilleur
des
mondes…
Et
si
le
projet
déviait
de
sa
trajectoire
ini1ale?
16. Les causes les plus fréquentes
• Spécifica1ons
fonc1onnelles
:
pas
assez
claires,
manque
d’adhésion,
ne
définit
pas
les
priorités,
contradictoires,
ambiguës,
peu
précises
• Ressources
:
trop
peu
nombreuses,
conflits,
turnover
important,
mauvaise
planifica)on
• Plans
de
charge
:
trop
serrés,
irréalistes,
trop
op)mistes
• Planning
:
n’intègre
pas
toutes
les
contraintes,
éléments
manquants,
mauvaises
es)ma)ons
• Risques
:
non
iden)fiés
ou
non
adressés,
non
gérés
17. Mener un audit
• Fonc1onnel
:
Revue
du
périmètre
et
des
aKentes
de
l’équipe
cliente.
Analyse
de
la
qualité
des
documents
de
concep)on
• Technique
:
Revue
de
code.
Analyse
de
la
qualité
des
développements
et
du
respect
des
standards
Drupal
18. Ne pas négliger le facteur humain
• Difficulté
de
la
prise
de
responsabilité
par
les
acteurs
du
projet
:
jeu
de
«
ping
pong
»
• Mener
l’audit
de
façon
objec)ve
et
dépassionnée
en
évitant
la
recherche
systéma)que
de
responsabilités
• Sensibiliser
le
management
sur
la
nécessité
de
faire
face
à
la
réalité
et
de
rechercher
des
solu)ons
pragma)ques
et
réalistes
è
Sor)r
du
management
«
Débrouillez-‐vous
pour
que
cela
fonc)onne
»
Dans
un
contexte
de
project
recovery,
un
changement
de
chef
de
projet
est
souvent
préconisé
21. Améliorer la communication
• Interviewer
les
acteurs
du
projet
• Affirmer
le
leadership
du
chef
de
projet
• Désamorcer
les
conflits
personnels
ou
poli)ques
• Convaincre
de
la
faisabilité
de
la
reprise
22. Revoir les périmètres
Redéfinir
avec
les
acteurs
du
projet
de
nouveaux
périmètres
en
termes
de
:
• Planning
• Budget
• Fonc)onnalités
Dans
60%
des
cas,
une
diminuDon
du
périmètre
foncDonnel
du
projet
est
préconisée
23. Modifier le staffing des ressources
• Iden)fier
les
ressources
nécessaires
• Définir
des
plans
de
charge
réalistes
pour
chaque
ressource
• Planifier
les
interven)ons
24. Identifier l’urgent
• Iden)fier
et
prioriser
les
éléments
les
plus
bloquants
• Iden)fier
les
difficultés
techniques
majeures
25. Modifier le pilotage du projet
• Changer
le
chef
de
projet
ou
revoir
son
posiDonnement
• Impliquer
un
consultant
spécialisé
pour
accompagner
la
phase
de
recovery
Pas
important
du
tout
Pas
important
Important
Très
important
1%
Importance
du
chef
de
projet
quant
à
la
réussite
de
la
phase
de
recovery
7%
28%
64%
27. Faire acter l’adoption du plan de
reprise
Recueillir
l’approba)on
de
l’ensemble
des
acteurs
du
projet
sur
l’intégralité
du
plan
de
reprise
:
• Planning
• Budget
• Staffing
• Périmètre
fonc)onnel
28. Les facteurs clés du succès
• Posi)onner
un
chef
de
projet
expérimenté
et
sensibiliser
sur
les
aspects
de
project
recovery
• Augmenter
la
surface
budgétaire
(et/ou
le
staffing
du
projet)
• Communiquer
en
clarifiant
les
aKentes
des
différents
acteurs
et
en
reconstruisant
la
mo)va)on
des
acteurs
clés
du
projet
• Replanifier
intégralement
le
projet
29. Mettre en place des outils de suivi
• Définir
un
fréquence
de
réunion
de
suivi
physique
ou
téléphonique
• Tenir
un
tableau
de
bord
de
recovery
qui
informe
sur
:
• L’avancement
des
travaux
• La
tenue
des
objec)fs
• La
probabilité
de
réalisa)on
des
risques
iden)fiés
• Enrichir
le
référen)el
de
documenta)on
du
projet
30. Fin de la phase de recovery
• Analyser
si
les
nouveaux
objec)fs
sont
aKeints
• Garder
l’équipe
de
recovery
en
place
pendant
quelque
temps
pour
monitorer
le
projet
• Effectuer
une
analyse
rétrospec)ve
de
la
phase
de
recovery
afin
d’évaluer
l’impact
et
la
per)nence
des
ac)ons
menées.
31. Merci
Ques)ons?
Louis
Sicard
–
Core-‐Techs
lsicard@core-‐techs.fr