Chaque fois que nous commençons à collaborer avec un nouveau client, notre société de développement de sites web et d’applications mobiles prépare deux documents complets qui révèlent tous les détails les plus fins liés aux coûts du projet de notre client.

Peut-être avez-vous déjà lu pourquoi et comment nous faisons des estimations approximatives (si non, vous devriez absolument le faire). Et maintenant, il est temps de découvrir tout ce que vous avez toujours voulu savoir sur les estimations détaillées dans MindK.

Qu’est-ce qu’une estimation détaillée ?

Une estimation détaillée est un document charnu qui vous fournit une ventilation complète des coûts de votre projet.

Il divise l’ensemble de la portée du travail en parties élémentaires – les fonctionnalités.

Chaque fonctionnalité est estimée séparément par nos équipes interfonctionnelles.

Le temps nécessaire pour terminer chaque fonctionnalité s’additionne pour former un budget détaillé pour votre application.

Estimation détaillée vs. estimation approximative

Si vous voulez que nous mettions une étiquette de prix sur une idée de base que vous venez de partager avec nous, nous vous enverrons volontiers une estimation approximative. Elle ne peut vous donner qu’une idée générale des coûts de votre projet.

Une estimation détaillée est un document beaucoup plus nuancé et étendu.

Dans les estimations approximatives, nous divisons votre application en énormes blocs de fonctionnalités appelés épopées.

Dans les estimations détaillées, nous allons un peu plus loin et nous divisons chaque épopée en fonctionnalités.

Avant de pouvoir rédiger l’estimation détaillée, nous devons rassembler et documenter toutes les exigences, éclaircir toutes les questions ouvertes et rédiger le cahier des charges (dans le cas d’un modèle d’engagement à prix fixe utilisé pour le projet).

De cette façon, nous sommes en mesure de trouver tous les détails nécessaires à l’avance et de fournir l’estimation la plus précise comme résultat.

Il ne peut y avoir aucune hypothèse à ce stade, seulement des affirmations.

Estimation détaillée vs. estimation précise

Voici pourquoi.

Des estimations vraiment précises ne sont possibles qu’après avoir terminé la phase de découverte, le prototypage de la solution, la rédaction du cahier des charges et l’approbation de l’étendue détaillée des travaux.

Pour les projets à prix fixe, nous établissons une estimation détaillée seulement après la fin de la phase de découverte. Nous facturons généralement cette phase comme un projet distinct.

Pour les projets Agile/Scrum, nous utilisons une approche différente.

Selon cette méthodologie, le développement de produits est un processus dynamique et très flexible. Son objectif principal est de produire une solution prête à l’emploi toutes les 2 à 4 semaines et de s’adapter aux retours des utilisateurs.

Faire une estimation définitive pour l’ensemble du projet ne convient pas vraiment à cette approche.

Dans la plupart des cas, vous ne pouvez pas vraiment prédire la forme que prendra votre application dans les mois et les années à venir. C’est pourquoi, pour les projets Agile, nous préférons utiliser ce que nous appelons Guesstimate.

Il nous permet de préparer des estimations approximatives, mais extrêmement détaillées, sans perdre une tonne de temps sur la phase de découverte.

Qu’est-ce qui constitue une estimation détaillée ?

Une estimation détaillée dans MindK a généralement trois sections : l’estimation elle-même, les coûts liés au logiciel et l’analyse des risques.

L’estimation

La section vous donne une ventilation caractéristique par caractéristique des coûts pour votre projet.

Pour les projets à prix fixe, nous écrivons juste le coût précis de chaque fonctionnalité, mais pour les projets Agile, nous ne pouvons fournir qu’une estimation approximative.

Dans cette section, nous n’incluons rien d’autre que les fonctionnalités qui sont confirmées à 100% par nos clients. S’ils décident à un moment donné d’ajouter une fonctionnalité, nous l’estimons séparément et mettons à jour le document.

Si un projet est complexe (c’est-à-dire que vous avez besoin à la fois d’une application web, d’une application iOS /Android, d’un chatbot, etc.), chacun de ces composants est estimé séparément.

Chaque fonctionnalité est écrite sous la forme d’une user story. Il s’agit d’une façon simpliste de rendre un élément de fonctionnalité du point de vue de l’utilisateur.

Elle se lit généralement comme suit : En tant que <rôle>, je veux <fonctionnalité> afin que <avantage> (c’est-à-dire qu’en tant que propriétaire d’un blog, je veux un formulaire d’abonnement, afin que je puisse obtenir des abonnés pour recevoir des mises à jour sur le nouvel article de blog.).

Les user stories sont courtes, concises et flexibles. Mais surtout, elles sont extrêmement faciles à comprendre, même si vous êtes un total novice dans le monde du développement logiciel.

L’estimation détaillée comprend la ventilation des coûts pour chaque type de travail :

• Analyse commerciale;
• Conception;
• Marquage (HTML);
• Développement;
• Assurance qualité;
• Gestion de projet (PM).

Le coût de la GP représente généralement environ 25% du résultat net. Le pourcentage exact dépend de nombreux facteurs :

• Plus un projet est complexe, plus il nécessite de communication et de gestion.
• Plus l’équipe est grande, plus sa gestion devient difficile, ce qui entraîne des heures de PM supplémentaires.
• Le nombre d’intégrations tierces peut également influencer les coûts de gestion. En plus d’être une fonctionnalité de plus à mettre en œuvre (et à gérer), les API tierces nécessitent souvent que nos PM contactent les fournisseurs de services.

Par exemple, la communication avec les grandes entreprises (grandes banques, grandes entreprises, etc.) en tant que fournisseurs d’API peut être un véritable casse-tête. Le haut niveau de bureaucratie et les structures hiérarchiques rigides peuvent transformer une tâche aussi simple en une corvée atroce.

Dans une sous-section séparée, nous listons toutes les fonctionnalités standard.

Notre expérience avec le développement mobile et web nous indique que certaines fonctionnalités et tâches sont présentes dans toutes les applications. Elles peuvent, par exemple, inclure la configuration des serveurs et de l’environnement de développement, la gestion de projet, la publication sur Google Play (pour les applications Android) et ainsi de suite.

Le coût des solutions tierces

Lorsqu’il s’agit du développement de logiciels, réinventer la roue est une entreprise coûteuse et souvent inutile. Heureusement, chaque tâche standard ou problème fréquent dans le monde informatique a au moins une solution toute faite. Parfois, elles sont gratuites, mais dans la plupart des cas, vous devez les payer.

Si pour réaliser un projet, nous devons acheter un logiciel, un service ou une bibliothèque tiers, nous estimons leur coût et incluons le chiffre dans le document.

Si votre projet, par exemple, prend en charge la messagerie SMS, alors nous devrons payer une passerelle SMS.

Si la conception de votre site web est basée sur un modèle spécifique prêt à l’emploi que vous souhaitez utiliser, alors nous ajouterons son coût à l’estimation.

Or si nos clients veulent que nous les aidions avec l’hébergement, nous leur suggérons les meilleures options (comme Amazon Web Services, DigitalOcean, ou d’autres services éprouvés). Ainsi, les coûts associés à l’hébergement et à la maintenance du serveur apparaîtront dans cette section.

Analyse des risques

Tout projet comporte certains risques inhérents. Le travail du gestionnaire de projet est de les identifier et de développer les stratégies pour y faire face.

Vous devez payer la somme spécifiée seulement si un risque particulier se transforme en un problème réel. Sinon, vous gardez l’argent.

Ces estimations nous serviront alors d’assurance contre une grande variété de dangers qui menacent le développement de votre projet.

Voici des exemples de catégories de risques qui se présentent dans le développement d’un produit :

• Qualité/Technique/Performance (i.utilisation d’une nouvelle technologie ou d’une technologie exceptionnellement complexe, modification de la technologie, objectifs de production impossibles);
• Gestion de projet (i.e. allocation défectueuse des fonds et du temps, planification insuffisante du projet);
• Organisationnel (i.e. manque de cohérence entre les objectifs de coût, de temps et de portée, mauvaise hiérarchisation, soutien irrégulier);
• Externes (c’est-à-dire changements de législation, problèmes avec les fournisseurs et les parties sous-traitantes, climat).

Après avoir identifié les risques, le GP les hiérarchise et effectue une analyse des risques.

Son objectif est de connaître la probabilité (c’est-à-dire les chances de sa matérialisation) et l’impact (les conséquences de sa matérialisation) de chaque risque particulier.

Un exemple ?

Comme je l’ai déjà mentionné, les fournisseurs d’API peuvent être lents à répondre. Ils peuvent tarder à envoyer la documentation nécessaire ou offrir un support de qualité inférieure. Il s’agit d’un risque réel dont nous devrions vous avertir à l’avance. Nous le plaçons donc dans la section des risques et développons en même temps une stratégie efficace de gestion des risques pour minimiser la probabilité de la menace et son impact.

Wrapping Up

Maintenant vous savez à quoi vous attendre de l’estimation détaillée dans MindK. Ce document vous apportera une réponse exhaustive à la question du prix de votre projet et vous aidera également à établir votre budget. Enfin, il vous donnera une idée claire de ce que vous allez payer.

Y a-t-il autre chose que je pourrais vous dire à propos des devis détaillés dans MindK ? Laissez-nous une ligne et je vous donnerai une réponse détaillée!

.