Civic Actions a récemment publié son Estimating Worksheet, un outil pour aider à produire des propositions de projet à partir de demandes de propositions (DP). C'est génial qu'ils partagent cet outil avec la communauté (sous licence CC Attribution – Partage dans les mêmes conditions 3.0) et je tiens à les en remercier.
L'outil est un tableur assez complexe, plutôt bien fait. La feuille de calcul aborde la préparation des propositions d'une façon semblable au processus que nous suivons ici chez Raincity Studios (RCS). Il n'est pas difficile d'imaginer qu'une méthode similaire soit utilisée dans d'autres boîtes de développement logiciel, Drupal ou non.
La feuille de calcul offre une structure pour décomposer l'information contenue dans une DP en tâches digestes. Il devient ainsi plus facile d'attribuer des valeurs à chacune des composantes du site, comme les domaines de travail (thématisation ou ingénierie, par exemple), et d'estimer le temps nécessaire pour réaliser les tâches. L'objectif final est de produire un ensemble d'information qui aide à définir la portée du projet, à lui attribuer une valeur monétaire et à produire la documentation à soumettre à votre client potentiel.
La suite de cet article suppose que vous connaissez un peu la préparation de propositions, la définition de la portée des projets et la gestion de production. De plus, certains des termes utilisés peuvent sembler obscurs si vous n'avez pas encore jeté un coup d'œil à l'Estimating Worksheet de Civic Actions.
En double
Deux aspects de cette feuille de calcul me semblent rafraîchissants et susceptibles d'apporter une perspective plus claire au processus :
- la préparation de deux propositions simultanées : l'une fondée uniquement sur la DP et l'autre qui tient compte de vos recommandations;
- le facteur de certitude.
Examinons chacun d'eux un peu plus en détail...
La feuille Recommendation Estimate permet de produire une proposition entièrement distincte, fondée sur les exigences de la DP et sur ce que vous, en tant qu'expert Drupal, estimez être une solution appropriée pour répondre aux besoins du client. Cela contraste avec la préparation traditionnelle de propositions liées à une DP, puisque cela permet d'associer des fonctionnalités à ce que Drupal offre d'emblée, afin de simplifier le développement et l'entretien et, potentiellement, de réduire les coûts du projet.
Par exemple : le projet exige une fonctionnalité X qui, si elle était mise en œuvre telle que formulée dans la DP, prendrait Y heures à réaliser. Vous pourriez toutefois suggérer un module contribué existant qui répond à la plupart des exigences, d'une façon légèrement différente, pour une fraction de Y.
Dans les propositions de RCS, il y a souvent un ensemble d'exigences associées à plus d'une estimation de coûts. Par conséquent, il est difficile d'arriver à un « chiffre final » qui tienne compte des variations possibles dans la façon de mettre en œuvre les fonctionnalités.
L'outil de Civic Actions offre une façon très intéressante de visualiser différents ensembles d'information (c.-à-d. deux propositions distinctes). Cela peut faciliter la discussion avec les clients sur les différentes façons dont un projet pourrait être construit. (Voyez comment la colonne « RPB » rend ce processus indolore!)
Voyons maintenant le facteur de certitude...
C'est toujours un défi d'attribuer une estimation satisfaisante du temps de réalisation à une fonctionnalité comportant beaucoup d'inconnues (p. ex., une fonctionnalité mal définie ou qui exige des technologies de pointe). C'est particulièrement vrai dans le contexte de projets au budget ou à l'échéancier serrés. Le tableur intègre le concept de facteur de certitude, qui évalue le degré d'incertitude que vous pourriez avoir pour une fonctionnalité donnée. Un facteur de certitude est aussi calculé pour l'ensemble du projet.
Disposer d'estimations haute et basse peut constituer un point de départ utile pour discuter avec votre client des fonctionnalités à conserver ou à retirer du projet, de celles qui peuvent être simplifiées ou améliorées, et de celles qui peuvent être reportées à des phases ultérieures du projet.
Je vois une autre utilisation potentiellement intéressante du facteur de certitude. Il pourrait aussi servir de bon indicateur des types de projets que votre entreprise souhaite entreprendre. Selon les ressources de votre équipe (disponibilité, compétences, expérience, etc.) et le type de clients et de contraintes avec lesquels vous travailleriez (budget, échéancier, attitude du client, etc.), vous pourriez conclure qu'un projet dont le facteur de certitude dépasse une valeur X présente un facteur de risque trop élevé pour votre organisation. Vous pouvez alors transmettre le contrat potentiel à d'autres agences Drupal mieux adaptées à ce type de projet.
De même, si vous aimez être à l'avant-garde et prendre des risques, ou si vos développeurs ont besoin de quelque chose de nouveau et d'emballant sur quoi travailler, vous voudrez peut-être examiner des projets au facteur d'incertitude plus élevé.
Donnez-lui du temps
L'un des aspects les plus faibles de cet outil concerne la durée du projet. À moins que quelque chose m'ait échappé, la durée du projet n'est pas une valeur calculée. Je suis certain qu'il est possible d'évaluer une durée d'après la taille du projet, les ressources disponibles et l'expérience. Toutefois, je pense qu'en combinant l'intuition avec une approche plus rationnelle, on peut s'attendre à une estimation plus précise.
Dans l'esprit de publier tôt et souvent, je suis heureux de contribuer à cet outil en y ajoutant un système qui peut vous aider à déterminer la durée du projet avec plus de précision. Trois feuilles ont été ajoutées à l'Estimating Worksheet pour créer la version 1.2 (?) du document.
Voici un aperçu des fonctionnalités ajoutées :
- La feuille Resources est l'endroit où vous entrez le nom des membres de votre équipe. Vous pourrez aussi associer à chacune de vos ressources un « temps de production » hebdomadaire.
- La feuille Assignments est l'endroit où vous associez une ressource à un domaine de travail (Area of Work).
- Les domaines (Areas) sont des regroupements de tâches de haut niveau. Ils existaient déjà dans la version 1.1 du document. Cependant, cette nouvelle feuille Areas les abstrait d'un cran supplémentaire. Les domaines peuvent être définis projet par projet, mais ils seront fort probablement toujours les mêmes d'un projet à l'autre. Cette feuille vous donne aussi un aperçu du temps que prendra chaque domaine, selon les ressources disponibles.
Autres fonctionnalités :
- Possibilité de déterminer le degré d'« implication » d'une ressource dans un projet.
- Possibilité d'affecter une ressource à plusieurs domaines.
- Dépendances entre domaines (simples) (c.-à-d. que le domaine C peut dépendre du domaine B, mais pas des domaines A et B).
- Héritage des durées des domaines (c.-à-d. que la date de début du domaine C dépend du domaine B, qui dépend du domaine C).
- Calcul d'une durée de projet basse, haute et moyenne.
- Date de début prévue et date de fin estimée.
Bien sûr, il y a des lacunes; après tout, c'est un tableur... En voici quelques-unes qui me viennent à l'esprit : les dépendances multiples, les exceptions aux horaires (p. ex., pour les vacances, les congés de maladie, etc.) et la possibilité de visualiser l'affectation des ressources sur plusieurs projets. Quoi qu'il en soit, j'estime que c'est globalement une amélioration par rapport à la version 1.1. Je serais heureux de continuer à collaborer pour améliorer cet outil.
Veuillez lire les notes intégrées au document. Merci de m'avoir lu!
Pièce jointe : CA Estimating Worksheet v1.2