Une gestion de projet adaptée aux très petites structures (1 à 3 pers)
le 29 mai 2008 à 11:10 par mrbooTous ceux qui ont eu l’occasion de travailler dans/avec des SSII (sociétés de service informatique: l’intérim de luxe de l’informatique) le savent les méthodes de pilotage des projets sont lourdes.
De mémoire, les étapes par lesquelles passe un projet dans ce type de structure :
- Analyse de l’existant (avec interviews): Power point, Word
- Spécifications fonctionnelles (en gros ce que le client veut voir à la sortie) : Power point, Word
- Spécifications techniques (comment mettre en œuvre le bouzin ci-dessus): Power point, Word
- De ces quelques kilos de feuilles découlent le fumeux fameux cahier des charges: Word
- Lancement de la réalisation
- Dialogue par email / réunions / pilotage via M$ Project / mises à jours du cahier des charges: Word
Parfois on coche dans un tableaur Excel une sorte de todo list qui permet de savoir où l’on en est… - Fin de la « V1″ (on aura pris soin de balancer tout ce qui est trop en retard dans une « V2″ qui ne sortira jamais
) - Recette: On vérifie que cela correspond grosso modo à ce que le client voulait (quand il s’en souvient encore tellement le projet a prit de retard )
- Livraison: on donne les clés + quelques kilos supplémentaires de documentation que personne ne lira jamais
- En parallèle il y a parfois une conduite du changement (souvent clé quand on voit les freins au changement développés par certaines personnes de la boite)
- bye bye mr le client et merci pour le chèque !
J’en oublie certainement et je suis peut être un peu dur mais vous l’aurez compris: mettre en place ce type de « process » pour une équipe de 2 ou 3 personnes n’est clairement pas envisageable.
Nous sommes petits ? tant mieux on va couper dans le gras.
Voici ce que j’ai gardé (on fait un essai avec Thomas dans le cadre du projet Cuicui) :
- Une réunion au café pour échanger sur le projet, griffonner quelques écrans, avoir la même « vision » du projet. (hier matin)
- Ce soir Thomas m’envoie les maquettes des pages (rédigées via Open Office), je lui retourne annotées demain matin, finalisation dans la journée.
- Avec les écrans il va produire une liste des fonctions/actions correspondantes (histoire de vérifier facilement que tout est là à la fin)
- On se met d’accord sur une date pour la réalisation, dès qu’il a une question / suggestion: Skype.
Surtout pas de réunion
- Comme nous utilisons un framework le socle technique n’a pas à être repensé: développement rapide et « agile ».
- A la fin de la réalisation on vérifie ensemble que tout est en place -> mise en ligne.
Sur le très bon blog de Stéphane on peut voir une liste des sites de gestion de projets.
D’expérience j’ai toujours eu du mal à m’imposer ce type d’outil, et je ne suis pas certain que cela nous apporterait plus que cela nous ralentirait.
Votre avis sur la question et vos retours d’expériences me serait précieux 
Tags: gestion de projet
29 mai 2008 à 11:28
Je travaille depuis quelques années avec ActiveCollab (mais tous ces outils sont sensiblements similaires, je pourrai faire la même chose avec Basecamp par exemple).
L’outil me permet de gérer des listes de tâche par projet que je rattache à des « points de passage » (version 1, version 1.1 …). Ceci permet de contrôler le bon avancement de chaque projet. Lorsqu’une tâche doit être reportée pour une raison X ou Y, elle passe d’une liste à l’autre.
Les listes ou les tâches sont attribuées directement à des personnes qui sont informées par email. Chaque projet a également son flux RSS qui regroupe tout ce qui se passe autour de ce projet.
La gestion des fichiers permet de stocker les différents documents relatifs (comme vos drafts d’interface) avec leurs différentes révisions. Si un graphiste intervient pour créer certains éléments de l’interface, il peut les déposer directement dans le système et nous pouvons commenter/discuter son travail directement sous forme de commentaire à son fichier.
En clair, ce genre d’outil, au même titre qu’un framework pour le développement, est structurant. Il a toutefois l’avantage d’être facile d’accès et agile (tu n’es pas obligé d’utiliser toutes les « briques »).
29 mai 2008 à 11:29
Alors nous on est une petite SSII donc ça marche un peu comme le 1 mis à part le fait que l’on travaille en général sur une suite de mini projet. L’avantage est que l’on arrive à tout mettre dans la V1
Par contre on a quasi la totalité des documents que tu cites sauf que ça fait pas des centaine de kilo…
En ce moment on est en phase d’analyse et l’on fait seulement 4 pages de synthèse par jour, donc ça n’est pas immense. Chaque matin le chef de projet me balance la todo list.
ça marche plutôt bien en plus le client est sympa donc pas mal de chance pour l’instant
29 mai 2008 à 11:31
J’ai oublié, on a aussi un socle pour nos developpement mais on en a pas pour le pôle BI car on fait pas vraiment de dev, quand même un peu car on fait de l’Open Source donc il faut modifier un peu pour bien adapter au client
29 mai 2008 à 11:35
L’art de monter des usines à gaz ou comment rester agiles… C’est le titre de ton prochain bouquin ?
29 mai 2008 à 11:54
Kilgore> je vais essayer ActiveCollab, merci pour l’info.
Lolive>ton histoire de « mini projets » ça s’apparenterait pas à de l’Extreme programming par hasard ?
Serge>
29 mai 2008 à 12:01
non, en fait on divise les projets en plusieurs tâches, que l’on regroupe pour former des projets de 3 mois max. Comme ça les équipes tournent. On a aussi des gros projets mais l’objectif est plus de bosser sur des courtes durées. De plus il faut dire que comme la BI open source ça se lance doucement on a pas des projets immense qui héritent de projest qui ont 20 ans.
29 mai 2008 à 12:03
Je passe mon tour, hein. Bah oui ^^
29 mai 2008 à 12:06
Et tu utilises quoi comme framework ?
29 mai 2008 à 12:08
@mrboo te focalise pas sur ActiveCollab, y’a surement des alternatives gratuites et libres tout aussi efficaces. J’utilise toujours la dernière release open (0.7.1).
29 mai 2008 à 12:09
Le Tribulateur> étonnant n’est-ce pas ?
Jean-Benoit> Framework maison basé sur un schéma MVC, adapté à la notion de sites multiples avec des droits d’accès.
Kilgore> à ~100$ par an avec la première année gratuite ce n’est pas une ruine. (j’ai la flemme d’installer un truc open source)
29 mai 2008 à 12:11
Un ptit billet bien marrant, je note cependant l’absence du « story-board » : étape au combien décisive du projet (sous Power-Point, dit : Pauvre-Point).
Toute les étapes cités ne sont absolument pas nécessaires pour des projets de 2-3 personnes (max), et sont même décommandés, pour des raisons évidentes de productivité!
PS. : j’adore la pelleteuse.
29 mai 2008 à 12:12
Je trouve ta version plus sympathique, plus pratique, moins couteuse, et surtout surtout beaucoup plus reactive, ce qui n’est pas le moindre de ses avantages.
29 mai 2008 à 12:15
Non tu n’es pas dur du tout : j’ai du subir tout ton descriptif SSII quand j’étais du bon côté de la barrière (cliente) et arg ! Je rêvais de ton mode de pilotage dont je retiens surtout :
- le café
- pas de réunions (autres qu’au café hihi)
- socle technique ne demandant pas à être repensé !
Cela dit, vu l’ampleur – à terme – du projet j’aurai tendance, comme Kilgore, à te conseiller de formaliser tout ça surtout si il existe un logiciel léger (parce que si c’est pour perdre plus de temps à saisir les briques du projet qu’à les faire avancer…. bref). A mon (humble) avis une des pistes les plus intéressantes est de pouvoir stocker (de manière organisée) les idées auxquelles on ne donne pas suite pour le moment et qu’elles ne se perdent pas en route.
Quand j’y pense c’est bizarre de vouloir formaliser ce que l’on ne va pas faire
Mais il me semble que c’est un des risques majeurs des démarrages de projet…
Good luck
29 mai 2008 à 12:19
Charles-Antoine> le “story-board” ne va pas dans les specs fonctionnelles ? (ça me semble déjà tellement loin tout ça)
Pangloss> thx
Isophe> J’ai pris pour habitude de ne pas noter mes idées, comme ça seules les meilleures passent le filtre du temps (et de ma mauvaise mémoire)
De toutes façons une bonne idée finira toujours par remonter au bon moment (c’est ce que j’ai remarqué)
29 mai 2008 à 12:23
mrboo > le « story-board » est préalable aux specs fonctionnelles et sert de base à leur élaboration. Cependant, il (le story-board) n’est pas contractuel !
29 mai 2008 à 12:45
C’est toujours compliqué comme question, on a beau être technicien à la base (et donc être dégouté de ce fonctionnement standard de l’industrie avec ses beaux chiffres du Standish Group sur les % incroyables de projets ratés ou non réussis) ou petite structure (donc se dire j’ai pas besoin de tout ça) il arrive un moment où si tu ne formalise pas un minimum tu finis dans la même situation que les « gros » qui formalisent trop.
Il faut trouver le juste milieu du coup, mais c’est très important (ne serait ce que parce qu’aujourd’hui l’énergie principale du dev vient de toi mais il arrivera certainement un jour où tu auras d’autres chats à fouetter) de faire une sorte de veille de la connaissance (aussi pour le moment où de nouveaux collaborateurs arrivent).
C’est un peu comme les commentaires dans le code « ouais hein bon ça va c’est pas compliqué » et puis on sait ce que ça donne 3 mois après…
Bref y’a pas de solution miracle de toute façon.
De notre côté on utilise Basecamp (un compte gratuit nous suffit actuellement) pour définir les « milestones » (pour le coup il s’agit plus d’un mix entre milestone et PBS) et pour ce qui n’est pas technique (la formulation « user friendly » de ce qu’il faudra faire techniquement par exemple, mais aussi des objectifs stratégiques, des idées notées rapidement).
Et on utilise Lighthouse (couplé à Github) pour le côté technique. Et la c’est plus difficile. On définit les « milestones » (mais les vraies ce coup la, cad les changements de version).
Et on tente de toujours lier nos commits (enfin dans la mesure du possible et du raisonnable) à des tickets. Le plus dur ici c’est de créer des tickets clairs (et clairs pour les autres) en respectant un formalisme minimum sur les titres, les tags etc…
Et sinon pas de réunions bien entendu, mais on est 3 ! Alors plein de café, de communication et surtout de choix rapides et efficaces.
(Un autre truc hyper pratique: on a un compte google apps pour studiomelipone.eu donc mail accessibles de partout sans pb et surtout google docs !)
29 mai 2008 à 13:55
Personnellement, dans mon entreprise, nous une utilisons une méthode agile décrite ici:
http://www.cafenware.org/la-rache/
29 mai 2008 à 14:11
Chui fan!
« D’autre part « L’extrême programming heuristique » est un concept assez prometteur. En effet l’heuristique est une technique consistant à apprendre petit à petit, en tenant compte de ce que l’on a fait précédemment pour tendre vers la solution d’un problème. Opposé à l’algorithmique l’heuristique ne garantit pas du tout qu’on arrive à une solution quelconque en un temps fini. Ceci sous entend d’une part une démarche pédagogique globale d’apprentissage et de capitalisation des acquis, mais aussi que les échéances annoncées le sont dans une pure otique de déconnade symbolique. Et c’est précisément le plus ‘produit’ de la méthode RACHE. »
… vers l’abandon du projet (et au delà !)
29 mai 2008 à 14:14
a quand le projet ploufplouf qui permettra d’importer ses images Flickr sur Hellotipi ?
29 mai 2008 à 14:33
Tu parle d’agile et je t’encourage au max dans cette voie. Meme à deux, ça peut payer j’en suis sur. Tu fais des sprints d’une semaine, avec une livraison tous les vendredi et des petits points quotidiens le matin via skype.
L’interet c’est que tout le monde sait ce qu’il se passe au jour le jour. T’as une livraison par semaine, ce qui alimente ton front ou ton bas niveau régulièrement. Si une feature ne tient pas sur 1 semaine, divise là ou agrandit ton sprint pour l’occasion.
Avec ça t’es en roulo compresseur
On en parle autour d’un verre ce soir si tu veux
29 mai 2008 à 14:38
Charles-Antoine> ok merci pour la précision
Jib> oula sacrée organisation ! il faut absolument que vous me fassiez une démo de votre projet j’ai l’impression que ça me plairait pas mal comme outil
kalahaine> Excellent
Daniel>
Ce projet s’appellera « Dany the troll »
Si je rajoute dans le profil un champ « Ma galerie Flickr » qui va lire le flux RSS de tes photos et qui ajoute au fur et à mesure dans la discusion de la page d’accueil de tes sites de familles est-ce que ça te semble une bonne solution (Flickr interdit l’import des photo dans les CGU de l’API)
stArk> tout les mardi tu veux dire ?
Pour le verre: toujours partant, ce soir soit très tôt (18h) soit beaucoup plus tard ~22h ?
29 mai 2008 à 14:40
22h au devant le fleuriste sur le carrefour ?
29 mai 2008 à 14:50
stArk> nickel, à tout à l’heure
29 mai 2008 à 15:01
Moi ça sera juste le café (pour le mal au crâne)
29 mai 2008 à 15:08
C’est open bar ?
Carrefour marseille, villier ?
A coté de conforama ou celui de Mr Bricolage ?
29 mai 2008 à 16:39
Super merci à Mrboo et à vous tous pour toutes ces infos:
C’est clair qu’étant peu nombreux, on peut profiter d’une flexibilité et d’une réctivité extrèmement forte. En revanche, tout doit se faire en étroit lien.
D’après notre experience perso, avec la création de notre société, tout doit se faire dans un certain ordre; si un personne responsable de telle ou telle activité prend du retard, tout le projet retarde et pénalise les autres dans leur avancement. Alors à 1 ou 2, c’est facile de le combler mais à 4-5 cela devient plus difficile.
29 mai 2008 à 20:07
Cela me parle ! Je pense que la rigueur est toujours importante quelque soit le nombre de personnes à participer à un projet. Le management de projet demande impérativement cette rigueur car il s’agit de prendre en compte plusieurs données qui s’interfacent : la gestion du temps, des moyens et des hommes avec compétences et limites. Le pb à la base est de savoir qui acceptent de rentrer dans la dynamique et pour y faire quoi ? Prendre le temps de l’échange pour s’assurer de l’assise avec reformulation par son interlocuteur est essentiel (et pourtant beaucoup en font l’impasse et s’en mordent les doigts : moi j’en ai plus d’ailleurs
la confiance ne suffit pas !
29 mai 2008 à 23:42
Ahah, j’ai piloté une fois dans ma vie un projet web, de A à Z, en suivant la méthode 1, étant la SSII pour un client « traditionnel ».
PLUS
JAMAIS
30 mai 2008 à 0:48
François, tu as oublié la TMA à la fin de la V1.
Une fois la V1 en place (avec un peu de retard et quelques avenants) le client a rarement envie de recommencer un mode projet avec une v2. C’est alors que la SSII se frotte les mains et place quelques consultants pendant plusieurs mois en régie chez le client histoire de fiabiliser le bouzin et d’implémenter les 10000 fonctionnalités oubliées (souvent par le client lui-même malheureusement) lors de la rédaction du cahier des charge initial…
30 mai 2008 à 9:28
@Daniel : Oui, oui… moi aussi, je suis assez fan de l’idée du projet PloufPlouf, mais je ne suis pas certain que celui des deux qui ne veut pas soit MrBoo
).
Ceci dit, un simple Uploader pour Hellotipi et le tour serait joué (Il y a vraiment que des trolls ici
@MrBoo : On est en train de tester BaseCamp, qui pour l’instant est plutôt pas mal… C’est un peu tôt pour être catégorique, mais c’est prometteur…
30 mai 2008 à 10:20
Le souci c’est que justement les photos Flickr que j’aimerais mettre sur Hellotipi c’est celles qui ne sont pas publiques sur Flickr…
Il faut que tu regardes de plus pres car Atafoto arrive a faire ce genre de manip pour du visionnage dans un album photo
peut etre un partenariat a monter avec eux pour creer et visionner ses album photos famille sur Hellotipi puis les faire imprimer…
bon mais j’arret de troller ton blog. Maintenant que j’ai decouvert le forum je vais continuer la discssion la bas
30 mai 2008 à 21:03
Après avoir vu nos limites en interne pour la V1, j’ai externalisé la V2.
On a bien défini les rôles respectifs.
On a mis en place un SVN. On travail sur du PHP/MysQL.
Ils font le squelette des pages, moi je modifie le contenu.
Au début du projet, on faisait une mise en PROD par semaine.
Pour le moment on a une version en beta privée et on fait quasiment une mise en PROD quotidienne.
On suit les bugs sur un forum.
Et je suis les tâches principales sur un google docs avec pour chaque tâche le responsable et la date prévu.
J’ai ajouté un compteur qui compte le nombre de jours de retard des tâches. Pour un jour de retard, c’est un Mars
L’avantage de google doc, c’est qu’on le partage, et tous les jours je reçois un mail avec ce qui a changé.
31 mai 2008 à 0:35
La grosse méthode de gestion de projet, ce n’est pas spécifique aux SSII, mais à tout gros projet informatique avec une distinction claire entre MOE et MOA (bref, entre informaticiens et utilisateurs). Toute boite un peu conséquente disposant d’une DSI suit ce genre de chose même en interne. C’est même limite plus important quand c’est en interne, parce que sinon les « clients », qui ne paient que d’une façon un peu abstraite sur leurs lignes de budget, se gêneraient encore moins pour changer totalement d’avis d’une réunion à l’autre (sans le reconnaître).
Donc c’est pas tant le nombre de personnes du projet qui compte, je pense, que la séparation plus ou moins claire entre demandeur et développeur (et le degré de confiance entre les deux, même s’il faut pas trop compter longtemps là dessus).
Bon, après on a aussi le projet avec 3 acteurs : SSII, DSI interne et MOA, et là tout se complique encore plus… la partie de patate chaude peut commencer
Sur les outils, le plus important pour moi est d’avoir un bon suivi des tâches en cours et restant à faire, simplement sous tableur. Qu’on se l’envoie par mail, qu’il soit sur Google docs, ou dans Lotus Notes… mais surtout que chacun n’hésite pas à le mettre à jour, et c’est là la vraie difficulté : celles des usages et non des outils ! Et essayer d’éliminer au max les réunions, sauf pour résoudre ensemble un problème. Les réunions d’information ne devraient pas exister !
6 juin 2008 à 15:51
Peut-être aller voir du côté de http://www.projectpier.org, une solution open source à héberger soit même dérivé des premières versions d’ActiveCollab je crois.
Il y a déjà pas mal de fonctionnalités, d’autres sont en cours de développement. Cela donne l’impression que le projet manque un peu de notoriété et de soutien pour vraiment décoller…
Il existe déjà des thèmes graphiques permettant de rendre l’interface plus conviviale http://www.projectpier.org/project/Themes