R5.

01 Initiation Management
Rémi Cozot – remi.cozot@univ-littoral.fr

Version 2023-2024
Objectifs
Apporter les bases de la gestion d’une équipe en informatique.
Savoirs de référence étudiés : préparer et gérer une équipe
informatique
• Gestion prévisionnelle d’un projet
• Performance et auto-efficacité d’une équipe informatique
Compétences comportementales et transversales du manager
• Compétences managériales
• Compétences humaines et compétences comportementales
Plan
Introduction : Diversité des équipes et projets informatiques
Équipe informatique : environnement
Modèle de maturité
Gestion prévisionnelle
Compétences comportementales du manager
Nouvelles compétences
Conclusion
Introduction
Diversité équipes & projets
Diversité des Équipes informatiques
Métier principal de l’entreprise
• Faire du logiciel
• Sous-traitance logicielle

• Industrie
• Service
Autres éléments de diversité
• place du numérique, partenaires, etc.
• Taille
• Ancienneté, expérience, …
Écosystème → concurrence
Diversité des Équipes informatiques
Métier principal de l’entreprise Modèle économique
• Faire du logiciel
• Sous-traitance logicielle B2B / B2C
Vente / Location de licence
Vente d’un service
• Industrie
• Service Durée de vie
Support
Autres éléments de diversité
• place du numériques, partenaires, etc.
• Taille
• Ancienneté, expérience, …
Écosystème → concurrence
Diversité des Équipes informatiques :
élément clé Méthodes et outils de gestion de projet, de
communication, etc.

Culture de l’équipe Langage, Framework

Outils de développement

Culture de l’entreprise vis-à-vis du numérique

Équipe informatique :
environnement
 Équipe informatique : environnement
Proposition d’innovation de
Équipe R&D
valeur ajoutée

Marketing Équipe informatique Création de la valeur

Définition du produit
Direction Financière Définition du financement
Dimensionnement marché
Équipe informatique : environnement
un exemple
Domaine : logiciel embarqué d’édition d’images/vidéos
Équipe R&D : nouveau modèle de traitement
particulièrement performant pour la vidéo

Direction générale lance une étude pour un logiciel « lightroom ©

Adobe » spécialisé vidéo
Équipe informatique : environnement
un exemple
Direction marketing
• Étude de la concurrence

• Définition du produit
• Modèle économique : licence, location, …
• Caractéristiques clés

• Chiffre d’affaires potentiel : 1 000 000 €

• Quel budget pour le développement ?

Équipe informatique : environnement
un exemple
Direction financière
• Chiffre d’affaires potentiel : 1 000 000 €

• Quel budget pour le développement ?

marge communication homme jour

Chiffre d’affaires potentiel 20% 50% 400,00 € / homme jour

1 000 000,00 € 800 000,00 € 400 000,00 € 1000 hommes jour

Il faut prendre en compte la trésorerie et des sources de financement !

Équipe informatique : environnement
un exemple
Équipe informatique
• Estimation du coût de développement en homme jour

• Remarque : si le coût estimé/réel est supérieur à 1 000, la viabilité du projet est

compromise !

Hypothèse : après estimation le projet est lancé, la problématique devient :

COMMENT SAVOIR SI LE PROJET DE DÉVELOPPEMENT SE DÉROULE BIEN ?

Équipe informatique : environnement
un exemple
Deux questions clés !

Savoir estimer les coûts et/ou délais

Savoir évaluer si le projet avance correctement

Questions annexes
• Qualité
• Reproductibilité
Modèle de Maturité
Capability Maturity Model Integration (SM) Carnegie Mellon
Propos liminaires
Chaque gestion & management de projet est différent
• Environnement technique
• Environnement de gestion de projet
• Équipe

Modèle est une généralisation

• Simple, manipulable et compréhensible
• Approximation → toujours faux & globalement toujours précis
CMMI : Un objectif clé
Faire en sorte que le projet se déroule bien :
• Coûts et délais respectés
• Qualité atteinte Manageurs

➔ Bonnes pratiques : ce qu’il est souhaitable de faire !

Cibles
Chefs de projets
(mais pas comment)

développeurs
Logique de processus
Amélioration
CMMI : Projet de développement
Date de début et date de fin cible
Budget
Équipe avec un chef de projet

Livraison de produit
Exigences pour le produit

Cycle de vie
CMMI : Processus
Processus : façon de faire une activité (25 domaines de processus )
• Démarrer et planifier un projet
• Rapporter l’avancement
• Réagir en cas de modification
• Construire un composant
• Tester un composant
• Etc.
Processus : quoi, comment, dans quel ordre, avec qui, avec quoi, etc.
Gestion de processus
• Documentation, suivi (rapports), indicateurs, accessible
CMMI : mise en place
Evaluation de la maturité de l’équipe
• Capacité à livrer, des bons produits, de bonne qualité, au moment convenu,
dans le budget

Échelle de maturité de 1 à 5
• En fonction de la maturité de processus clés

Création en 2006
• Études de milliers de projets (Oracle, Boeing, Google, etc.)
• Créé par Carnegie Mellon
Compagnon indispensable
• Intégré dans ISO15504, compatible avec ISO 9001
Personal Software Process
(SM)
Personal Software Process (SM) : 1er Exemple
Développeur junior
• 1 bug toutes les 4 lignes de code
Développeur expérimenté
• 1 bug toutes les 4 lignes de code

Quelles différences alors ?

• Temps mis pour la détecter : immédiat à détecter en tests
• Temps mis pour la corriger
Personal Software Process (SM) : 2ème Exemple
Les bugs les plus dangereux sont introduits lors de la correction de bug !

« j’essaie de trouver une solution pour que ça marche (tests unitaires),

sans penser au reste, aux conséquences »

Importance des tests de non-régression !

 CMMI : niveaux de maturité

Structuration Standardisation Mesure et Prévision Maîtrise du changement

2 4
1 3 5
Géré Géré
Qualitativement Quantitativement
Initial Défini En optimisation
Reproductible Contrôlé
CMMI : Niveau 1
Réussite dépend de quelques personnes clés, pas de formalisation

• Estimations non fiables

• Pilotage par les délais
• Succession de crises
• Pas de retour d’expérience
• Savoir-faire informel
CMMI : Niveau 2 « reproductible »
Gestion de projet élémentaire, assure le suivi des coûts et délais
Gestion de projet vérifie la fonctionnalité du projet
Des processus sont en place

• Succès
• Estimation plus fiable
• Actions correctives
• Qualité obtenue
• Vie du projet « facile » Niveau classique des Entreprise de Service du Numérique

« niveau artisanal »
CMMI : Niveau 2 « reproductible »
Processus mis en œuvre
• Exigences : recueil, suivi, mise à jour
• Planification
• Suivi de projet
• Gestion de configuration
• Assurance Qualité : tests
• Mesures
• mise en place systématique de premières mesures : distance par rapport aux exigences
CMMI : Niveau 3 « défini »
Processus sont documentés, normalisés et intégrés
Les processus sont adaptés en fonction du projet

• Réussite équivalente entre projets

• Risques maîtrisé et décroissants
• Capitalisation systématique
• Réutilisation savoir-faire, code, …
• Culture et compréhension communes
• Retour d’expérience, enseignements tirés
Processus mis en œuvre Découpe classique des exigences en
• Spécification 2parties :
• Solutions techniques • exigences & besoins
• solutions techniques
• Risques : identification, gestion des risques, suivi
• Gestion projet intégrée
• Décision : transparence
• Formation : recueil des besoins de formation et formation
• Vérification À mettre en parallèle avec :
• Validation • Solution technique : vérification
• Spécification : validation
CMMI : Niveau 4 « contrôle quantitatif »
Les processus sont mesurés (indicateurs)
Les processus sont contrôlés quantitativement

• Métriques et indicateurs
• Consolidation entre les retours d’expérience
• Programme (processus) de qualité
• Évaluation des impacts liés aux évolutions
CMMI : Niveau 4 « contrôle quantitatif »
Métriques et indicateurs : défi technique et humain

Question : « comment avance le projet? »

• Sociologie : un développeur ne sait pas répondre !

• Solution quantitative

Évolution du nombre de lignes de code entre deux « compilations/tests »

CMMI : Niveau 4 « contrôle quantitatif »
Évolution du nombre de lignes de code entre deux « compilations/tests »

ΔX > ΔXref ➔ Perte de qualité à prévoir

ΔX ≈ ΔXref ➔ Avancement en ligne avec les délais

ΔX ≈ 0 ➔ Correction de bugs (sans remise en cause)

ΔX < 0 ➔ Remise en cause

CMMI : Niveau 4 « contrôle quantitatif »
Pourquoi un défi humain ?

Sentiment d’être « fliqué »

Risque de faire de la gestion de projet « Excel »

➔ Expliquer le processus de gestion de projet

CMMI : Niveau 4 « contrôle quantitatif »
Le choix des outils
• Système de gestion de projet intégré
• Édition
• Test : unitaire, intégration, non régression, validation, etc.
• Documentation
• Version
En fonction des métriques et indicateurs
L’instrumentation du projet fait partie du projet
CMMI : Niveau 5 « optimisation »
Les processus de développement sont systématiques donnant la
possibilité de son amélioration permanente

• Amélioration continue des processus

• Performance stable et prévisible
• Gestion du changement
CMMI en chiffres

Niv. 1 Niv. 2 Niv. 3 Niv. 4 Niv. 5

Précision
- 30 % à +100 % ± 20 % ±5% ±3% ±1%
estimation
Code réécrit en
40 % 20 % 10 % 6% 3%
cours de projet
Défauts inclus
dans la version X ½X ¼X 1/10 X 1/100 X
livrée
Réutilisation
Négligeable Faible Occasionnel > 30 % > 50 %
entre projets

Productivité Y 1.5 Y 2Y 3à4Y >4Y

CMMI en chiffres
Performance CMMI
1,2

0,8

0,6

0,4

0,2

0
Niv. 1 Niv. 2 Niv. 3 Niv. 4 Niv. 5

Code réécrit Défauts Productivité

CMMI : conclusion partielle
Guide général
• Ne donne pas d’exemple concret de comment faire
• Bien réfléchir à la pratique
Analyse réflexive nécessaire
• Prendre le temps de réfléchir à sa culture de gestion de projet
• Prendre en compte la sociologie de l’équipe
Mise en place très efficace
• Augmenter d’un niveau est « facile »
• 10% du budget en moyenne
Gestion prévisionnelle
Gestion prévisionnelle : organisation du projet
Agile Découpe fonctionnelle
Conception
Globale

Sprint 1

Sprint 2
Partie 1 Partie 2 Partie 3
Sprint 3

Sprint n
Intégration
Gestion prévisionnelle : organisation du projet
À même niveau de maturité, pas de meilleure méthode
• Dépend de la nature du projet, de l’organisation de l’entreprise

Prévision : avoir de l’expérience pour estimer

• On n’a jamais fait ça, comment estimer ?

Prévision : 2 approches
• Demander aux développeurs qui auront la partie en charge (CMMI Niv. 1, 2)
• Base de connaissances (CMMI Niv. 3, 4, 5), n’exclue pas l’avis humain
Gestion prévisionnelle
Demander aux développeurs
• Quel temps pour développer X ? X
• Première version de X
• Version finale de X
• Tests de X
• Optimisation de X
Sociologie des développeurs

½ C(X) C(X) mesuré 2 C(X)

50% 50%
Gestion prévisionnelle

Cout réel

Estimation non possible !

Gestion prévisionnelle

Cout réel

Impossibilité de demander à un grand nombre de personnes !

Gestion prévisionnelle

Autre axe d’analyse et de gestion, planification ?

Sprint 1 Conception
Globale
Sprint 2
Partie 1 Partie 2
Sprint 3

Intégration
Gestion prévisionnelle : par les risques !
Découper en fonctions des risques

Analyse des risques

Différentes natures de risques
• Exigences opérationnelles
• Exigences performances

• Technique / technologique

Spécifier une solution de repli

 Gestion prévisionnelle : par les risques !
Intégration des risques Évaluation risque (A)
• Tâche à risque commencent le plus tôt
• Solution de repli correctement estimée
• Solution fausse « Fake » A Solution de repli
Risque (A)

Livraison du projet
Lancement du projet

Sprint n
Real A
Risque (A)

Sprint 1 Sprint 2 Sprint 3

Fake A Fake A Fake A

temps
Gestion prévisionnelle
Ne pas oublier
• GANTT
• PERT
• Cours de gestion de
projet, génie logiciel, etc.
Compétences comportementales
du manager
Préambule
Société internationale dans le jeu vidéo : test comparatif sur l’origine
du chef de projet
• Chef de projet : ancien Lead Game Designer
Le jeu est le cœur du projet de développement d’un jeu vidéo, le
chef de projet connait parfaitement les exigences.

• Chef de projet : ancien Lead Dev

Le jeu est principalement du code, les risques sont logiciels.

• Chef de projet : ancien chef de projet chez Danone

Chef de projet est un métier, il n’est pas nécessaire de connaitre le
jeu.
Préambule : verdict
Société internationale dans le jeu vidéo : test comparatif sur l’origine
du chef de projet
• Chef de projet : ancien Lead Game Designer
Le jeu est le cœur du projet de développement d’un jeu vidéo, le
chef de projet connait parfaitement les exigences.

• Chef de projet : ancien Lead Dev

Le jeu est principalement du code, les risques sont logiciels.

• Chef de projet : ancien chef de projet chez Danone

Seulest
Chef de projet jeuunrendu dans
métier, les délais
il n’est pas nécessaire de connaitre le
jeu. avec la qualité exigée !
Préambule : analyse
Un expert technique (Game design ou dev) CROIT savoir A un biais
• Manque d’écoute, de jugement critique
• Pense ses décisions naturelles, ne les expliquent pas
• Se trompe dans l’analyse coût bénéfice
Game Designer a tendance à valider les améliorations dans la
logique du jeu, sans bénéfice perçu consistant avec des coûts parfois
important.
Le chef de projet Danone
• Écoute et questionne pour comprendre
• Soumet à approbation ses décisions
• N’a pas de biais de préférences
Compétences non techniques du manager
Écouter, arbitrer, expliquer
• Pour toute demande, questionner afin de comprendre la motivation
• Organiser un débat pour la prise de décision, et savoir trancher
• Expliquer les prises de décision, savoir répondre à la question « pourquoi »
Accompagner, motiver, inclure
• Entendre les difficultés, montrer quelles sont prises en compte, assurer le suivi
• Montrer de l’intérêt, de la fierté par rapport au produit, …
• Animer, faire parler (même le timide), organiser des temps de repos, prévoir
l’arrivée de nouvelle personne

Remarque : le départ d’une personne est plus difficile à gérer

Compétences non techniques du manager
Quelle distance ?

Être toujours accessible

malgré le rôle d’interface avec la

« direction »
Compétences non techniques du manager
Rôle d’interface
Toujours intégrer les contraintes
• Budget, délais, qualités, exigences, partenaires
• Marketing : estimation de marché, concurrence, définition du produit
• Communication : démos à produire
• Ressources humaines :
• Embauches, changements, départs, promotions …
• Culture de l’équipe de développement doit être partagée !
• Commercial
• Direction technique, R&D : changement coconstruit

• Direction générale
Nouvelles compétences
Nouvelles compétences
Responsabilité sociale des entreprises
• Impact social et sociétal
• Éthique : non-discrimination, transparence, explicabilité
• Bilan/empreinte carbone
• Scope 1 : les émissions directes de GES produits par l'entreprise
• Scope 2 : correspond aux émissions indirectes liées à l'énergie, mais qui ne se
produisent pas directement sur le site de l'entreprise
• Scope 3 : lié aux émissions indirectes qui ne sont pas sous le contrôle de
l'entreprise
Aspect règlementaire et juridique
• Règlement général sur la protection des données (RGPD)
• Loi IA
Conclusion
Conclusion
Un bon développeur n’est pas forcément un bon chef de projet

Gestion de projet est un métier avec des compétences propres

• Comme tout métier il s’apprend

Chef de projet n’est pas l’évolution majoritaire des développeurs

• 10 % des développeurs deviennent chef de projet

C’est un métier humainement passionnant !