Développement logiciel, les clés de la réussite (2020)
Tous les projets logiciels sont uniques, mais tous doivent obéir à des principes communs pour être couronnés de succès. Des phases préparatoires à la maintenance post-livraison, en passant par le choix du bon partenaire, nous vous proposons quelques points qu’il est important de garder en vue afin de vous assurer que votre projet de développement arrive à bon port, dans les coûts et délais prévus, et que le produit final réponde pleinement aux attentes de son donneur d’ordre et de ses utilisateurs.
Cerner les objectifs d’affaires
Améliorer la productivité, diminuer les coûts, satisfaire sa clientèle, augmenter les ventes, retenir des clients… La clarification des objectifs d’affaires permettra de correctement guider l’équipe de développement dans l’élaboration d’une stratégie de livraison, la hiérarchisation des requêtes, l’établissement des critères de succès et la définition d’une feuille de route sur le long terme. Elle permet aussi d’apprécier la valeur des composantes d’un projet et le retour sur investissement.
Déterminer le budget
Plus l’écart se creuse entre les ressources disponibles, toujours limitées, et les besoins exprimés dans un projet, plus les chances de réussite diminuent. De là l’importance de connaître en premier lieu son retour sur investissement et de déterminer par la suite le budget. Dans le cas de liquidités restreintes, une option à considérer, lorsque le ROI est positif, est de faire financer votre projet informatique par une institution bancaire. Calculer le ROI doit être un exercice automatique pour tout projet. Il est en effet indispensable aux décideurs pour juger de la qualité de l’investissement. Il faut aussi s’assurer de calculer en étant le plus réaliste possible.
Idéalement, lorsque vous contactez un partenaire technologique, il faut d’emblée que vous lui donniez un budget de départ ; il pourra ainsi très rapidement vous dire si vos attentes sont réalistes ou irréalistes en regard de votre capacité d’investissement. Il peut également vous suggérer des possibilités alternatives. Dans le cas d’un budget inflexible, le dirigeant devra faire des choix. Par exemple : est-ce qu’un logiciel qui répondrait à seulement 80 % des besoins, mais qui rentrerait dans le budget, serait acceptable ? Seul le dirigeant peut en décider.
Définir les attentes
L’expression des attentes est la phase la plus cruciale d’un projet informatique. Et c’est une étape pendant laquelle il faut se méfier des conclusions hâtives. Il faut discuter et analyser chaque point en profondeur avec les différents intervenants concernés. L’objectif est de réaliser un cahier des charges précis et détaillé de la future application. En mode “cascade”, la précision est absolument primordiale, alors qu’en mode “agile”, on parlera plutôt d’une vision détaillée du projet et on s’économisera le temps mis à définir trop méticuleusement des objectifs qui seront peut-être écartés en cours de route.
Cette étape est aussi celle où l’on sépare le superflu de l’indispensable, où l’on hiérarchise les attentes en fonction des objectifs d’affaires, ce qui permet de déterminer ce que serait un produit minimum viable (MVP).
Cette phase peut aussi être réalisée avec la collaboration de son partenaire technique. C’est même souvent recommandable, car cela permet d’établir au plus tôt une compréhension commune du projet, de définir ensemble une stratégie de réalisation et de fonder les assises d’une collaboration de qualité essentielle au bon déroulement du projet.
Choisir son partenaire
Le prix est un facteur important, mais la politique du choix de la plus basse offre est rarement conseillée. C’est un paramètre parmi d’autres dans le choix du bon partenaire. S'il y a des écarts excessifs entre différentes propositions pour un même projet, c'est souvent qu'au moins l'un des soumissionnaires n'a pas réellement compris les efforts de développement ou les défis techniques. Demandez à vos soumissionnaires que l’on vous explique les raisons d’une différence de coût. N’hésitez pas à les questionner sur des points précis afin de tester la crédibilité de leur offre et de s’assurer qu’ils comprennent tous correctement les caractéristiques de votre demande.
Aussi, veillez à ce que votre partenaire partage vos valeurs, que vos cultures d’entreprises soient compatibles. Une bonne affinité et une communauté de vues sont fondamentales pour une collaboration de qualité entre votre équipe et celle de votre partenaire. Cette compatibilité est même essentielle si vous souhaitez créer une équipe hybride, c’est à dire composée de développeurs de votre entreprise et de votre partenaire technique. À cet égard, travailler avec une équipe locale peut être un atout, notamment en ce qui concerne la bonne communication.
Enfin, dans bien des cas, il est recommandable de privilégier un partenaire “agnostique”, c’est-à-dire qui ne vous enferme pas dans un seul choix technologique et qui est en mesure de vous proposer différentes solutions.
Au forfait ou à l’heure
Les projets de développement informatique se font souvent sur une base horaire. Si vous souhaitez un prix forfaitaire, vous devez vous assurer que votre cahier de fonctionnalités est parfaitement détaillé et que vous prévoyez de faire que peu ou pas de changements en cours de mandat. Aussi, votre projet ne doit pas reposer sur des technologies trop nouvelles, plus ou moins expérimentales, les incertitudes devant être minimales. Une technologie solide et éprouvée autorise une bien meilleure visibilité.
Bâtir un logiciel s’apparente à la construction d’une maison. Si vous avez des plans d’architecte suffisamment détaillés, il est possible de déterminer au départ un coût précis. Si vous modifiez les plans en cours de chantier, vous paierez inévitablement des “extras”. Cependant, il faut bien savoir qu’en matière de développement logiciel, il est très rare que le projet n’évolue pas au cours du temps, et plus son envergure est large, plus il est susceptible de connaître des modifications. C’est pour cette raison que la facturation horaire est privilégiée. Celle-ci évite aussi d’éventuelles divergences de vues sur ce qui doit ou ne doit pas entrer dans le cadre du forfait, qui peuvent générer des tensions pendant la réalisation. Elle est particulièrement appropriée pour les projets qui adoptent un cycle de développement itératif, tant qu’elle est jumelée avec un suivi précis des coûts.
Une troisième voie est aussi envisageable : un projet peut comporter des phases bien encadrées qui entrent dans un forfait et d’autres qui seront facturées à l’heure. Cette approche permet de sécuriser une partie du budget tout en se laissant une certaine flexibilité pour laisser place aux besoins émergents.
Identifier les contraintes et gérer le risque
Lorsqu’on a été prévenu de ce qu’on doit craindre ou de ce qu’on doit éviter, on est doublement en état de prendre des précautions ou des mesures. Il faut avoir une bonne conscience des restrictions ou des limitations du projet, qui peuvent être d’origine humaine, matérielle, technologique, budgétaire ou encore temporelle. Les principales contraintes relèvent bien souvent de dépendances à des systèmes externes ; il faut correctement les identifier et s’assurer de n’en oublier aucune.
Tout projet comporte des risques inhérents. Les recenser dès la phase de définition de projet permet de préparer une stratégie pour les circonscrire. Aussi, le client est l’expert de son domaine d’affaires et sa présence à toutes les étapes clés du projet est la garantie d’éviter la plupart des obstacles.
Privilégier le développement itératif
La réalité est qu’un projet informatique d’envergure évolue constamment au cours de son développement et que pour bien réussir, le partenaire doit s’adapter en permanence aux changements de priorités. Ces derniers peuvent être de cause externe, par exemple une modification du marché ou des besoins émergents. Il faut donc une méthodologie qui laisse la place au pragmatisme et à la flexibilité. Les projets d’une certaine taille doivent idéalement être réalisés en mode itératif, c’est-à-dire d’avoir des livrables sur une périodicité fixe. Ces étapes de livraison doivent être l’occasion de rencontrer son partenaire, de constater l’avancement des travaux et de vérifier l’adéquation avec les attentes. Obtenir rapidement des livrables permet de diminuer considérablement le risque d’avoir en fin de parcours un logiciel qui ne répond pas réellement aux besoins. Cela vous autorise à faire sans délai des ajustements, voire à changer la direction de votre projet, en cas d’imprévu.
Adopter les meilleures pratiques
L’adoption par votre partenaire des meilleures pratiques a pour but de parer tout échec ou carence du projet logiciel. Il s’agit en quelque sorte d’une assurance contre les risques inhérents à l’industrie. Dysfonctionnements, interruptions des services et intrusions peuvent avoir de lourdes conséquences financières. Et améliorer la qualité est toujours un gage de performance.
Mettre l’utilisateur au centre. L’expérience vécue par les utilisateurs est primordiale au succès de votre application. Un design cohérent et des interfaces intuitives les aident à obtenir les résultats qu’ils souhaitent et suscitent un meilleur engagement, ce qui garantit une bonne adoption de l’outil et se traduit en augmentation de la productivité et de la satisfaction. Avoir en tête l’utilisateur final et ses besoins tout au long du projet fait partie des bonnes pratiques.
Endiguer la dette technique. Au début d’un projet, on peut avoir tendance à vouloir des fonctionnalités livrées au plus vite aux dépens d’une qualité irréprochable du code. On peut aussi avoir des dates de livraison non négociables qui obligent à prendre temporairement des raccourcis. On accumule ainsi une “dette” qui sera à rembourser tôt ou tard, et comme pour les finances, plus on attend, plus elle grossit. Sur les projets d’envergure, il est impératif de surveiller en continu l’accumulation de cette dette et d’avoir une stratégie de contrôle claire. Différentes méthodes peuvent être mises en pratique comme des sprints dédiés à la dette, une fraction du temps consacré à l’amélioration continue, etc.
Penser qualité… Tout le monde s’entend pour dire qu’un bogue qui est identifié pendant le processus de développement est infiniment moins coûteux que celui qui serait identifié plus tard, par exemple pendant les tests d’acceptation par l’utilisateur ou pire encore, à la mise en production. Les techniques d’intégration continue et une revue du code correctement menée aideront à identifier les problèmes qui, s’ils sont corrigés au bon moment, feront économiser énormément de temps, d’argent et d’énergie. À cet égard, vous devez vous assurer que votre partenaire est en mesure de déployer tous les outils standards de l’assurance qualité qui peuvent être nécessaires à la réussite de votre projet : tests unitaires, d’intégration, d’intégration continue, des interfaces, tests fonctionnels, etc.
Et sécurité. Enfin, il ne faut jamais perdre de vue les enjeux de sécurité et ne jamais tenter d’économiser sur ce chapitre. La prise en compte de la sécurité à toutes les phases du projet fait partie d’une démarche d’assurance qualité globale.
Prise en main
Le succès de l’implantation d’une nouvelle solution, sa bonne adoption par ses utilisateurs, passe souvent par la formation afin que la prise en main soit rapide et efficace. Il est important d’établir dès que possible le type de formation, le niveau de documentation utilisateur attendu et les responsabilités de l’équipe de réalisation ou l’implication d’autres intervenants. Votre partenaire doit être à même d’offrir ce service. De manière générale, plus la solution est complexe, plus ses utilisateurs doivent être accompagnés, autant par des intervenants maîtrisant le nouvel outil que par une documentation claire.
Maintenance
Un logiciel doit être maintenu tout au long de sa vie. Il est important d’avoir un partenaire qui peut vous proposer des services de support et maintenance en postproduction. Ce partenaire doit aussi se montrer proactif afin d’anticiper les problèmes prévisibles comme ceux induits par un changement de version de système d’exploitation. Il est raisonnable de prévoir dès le lancement d’un projet les coûts de maintenance qui s’additionnent à ceux du développement de la solution, et qui doivent être pris en compte dans le calcul du ROI.
Software development done right
No two software projects are alike, but all the successful ones share certain principles. Here are a few things to keep in mind at every step — from the preparation phase, to the choice of a development partner, to post-delivery maintenance — to ensure that your development project gets successfully completed on time and on budget, and fully meets the expectations of the software’s ordering customer and users.
Defining business goals
Do you seek to boost productivity? cut costs? improve customer satisfaction? increase sales? retain clients? Clearly defined business goals will guide the development team in formulating a delivery strategy, prioritizing requests, setting the criteria for success and creating a roadmap for the long-term. Defining your business goals will also make it possible to evaluate the worth of a project’s various components and assess the project’s return on investment (ROI).
Drawing up your budget
The wider the gap between what you want and what you can spend, the lower the chances of success – and we all know that resources are always scarce. That is why it is important to know a project’s ROI before setting the budget. When funds are scarce but the net ROI of your software project is positive, one option is to seek bank financing. ROI calculations should be automatic for every project: without it, it is impossible to decide whether an investment is worth it. Remember to be as realistic as possible when calculating the ROI.
Ideally, you should have a preliminary budget in hand when you contact your technology partner. Your partner will be able to tell you, very quickly, whether your expectations are realistic or not, based on how much you can invest. Your technology partner may also suggest alternative approaches. If the budget is set in stone, there will be choices to make. Is software that is within budget but only meets 80% of needs acceptable? Only you can decide that.
Spelling out your expectations
Stating your expectations is one of the most critical steps in a software project. There can be no glossing over or jumping to conclusions. Each point should be discussed and analyzed in detail with everyone involved. The goal here is to develop specific and detailed specifications for the application. In “Waterfall” mode, setting things out precisely is of the utmost importance. In “Agile” mode, it is the vision of the project that is detailed, which saves time, as goals are not meticulously defined in advance only to fall by the wayside later.
This is also the step at which you separate the “must have” from the “would be nice”. Expectations are also prioritized according to business goals, to determine what the minimum viable product (MVP) would be.
Expectations can be set with your technology partner. In fact, it’s a good idea to involve your technology partner at this step, to ensure you share a common understanding as early on in the process as possible, agree on a strategy, and lay the groundwork for the kind of high quality cooperation needed to ensure that the project goes smoothly.
Choosing your development partner
Price matters, but choosing the lowest bidder is rarely a good idea. Price is only one of the important factors involved in choosing the right technology partner. Major price gaps between different bids for a given project generally mean that at least one of the bidders does not truly grasp the technical challenges or development work involved. Ask bidders to explain price differences. Do not hesitate to ask specific questions to test the credibility of a bid and to make sure that all bidders really understand what you are asking for.
You should also make sure that your technology partner shares your values, and that your companies have compatible business cultures. Strong affinity and a common philosophy are the cornerstone of high quality cooperation between your team and your partner’s team. In fact, this compatibility is essential if you want to create a hybrid team that is made up of developers from your company and your technology partner’s company. In this scenario, working with a local team can be a real asset, especially when it comes to good communication.
Finally, unless you have very specific technical choices in mind, it is recommended that you lean toward an “agnostic” partner, one who will not lock you into a single technology and who will be able to suggest various different solutions.
Lump sum or hourly rate
Information technology development projects tend to be billed by the hour. If you want to pay a lump sum, your functionality specifications must be perfectly set out to the last detail, and you must plan on making few or no changes down the road. Since uncertainty must be kept to a minimum, make sure your project does not involve new or somewhat experimental technology. Proven, time-tested technology will give you a clearer picture of overall costs.
Building software is like building a house. If you have sufficiently detailed blueprints, you can make accurate cost estimates from the outset. If you change your mind along the way, you will inevitably incur ‘extra’ costs. However, when it comes to software development, rarely does a project not evolve over time. And the greater the scope of the project, the greater the chance of changes. That is why billing tends to be by the hour. This also prevents potential differences of opinion about what should and should not be covered by the lump sum, which can create tension during project execution. By-the-hour billing is particularly well suited to projects with iterative development cycles, as long as costs are monitored closely.
There is also a third possibility: a project can have some carefully defined stages that are covered by a lump sum, and other stages that are billed by the hour. This approach makes it possible to nail down part of the budget while leaving room to adapt to any needs that may arise along the way.
Identifying constraints and managing risk
It is easier to take precautions or choose the right approach when you know what pitfalls to avoid. It is important to have a healthy awareness of a project’s limitations, regardless of their source: be it the people, equipment or technology involved, or the available time and money. The biggest constraints are usually created by dependence on external systems, none of which should be overlooked, and all of which must be identified properly.
Every project has risks. Taking stock of those risks from the outset, as the project is being defined, will help you devise a strategy to mitigate them. Since clients are the experts when it comes to their business, having them present at all key stages of the project is a sure-fire way of avoiding most problems.
Choosing iterative development
It’s a fact: large-scale software projects evolve constantly during development. In order to carry out such projects successfully, your technology partner will have to keep adapting to changing priorities. Priorities can shift due to external causes such as a changing market or new needs. The project development method must therefore leave room for a pragmatic and flexible approach. Larger-scale projects should ideally be carried out in iterative mode, with deliverables at set intervals. Deliveries should be an opportunity to meet with your technology partner, see how the work is progressing, and check to make sure that your expectations are being met. Obtaining deliverables early on can considerably reduce the risk of ending up with software that does not really meet your needs. Short delivery cycles also enable you to make adjustments immediately, and even change the direction of your project to deal with unforeseen developments.
Using best practices
If your technological partner uses best practices, your software project will be less likely to fail or to be found lacking. Best practices are a kind of insurance against the inherent risks of the industry. Malfunctions, service interruptions and breaches can carry a heavy price. Higher quality always means better performance.
Putting users first. User experience is vital to the success of your application. Consistent design and intuitive interfaces will give users the results they want, generate greater commitment, and guarantee good uptake of the tool, which will in turn increase productivity and user satisfaction. Best practices include keeping the end user in mind throughout the development process.
Controlling technical debt. At the beginning of a project, it can be tempting to sacrifice ironclad code quality to obtain quick deliveries. Non-negotiable delivery deadlines can also force developers to take temporary shortcuts. This creates “debt” that will have to be repaid eventually. Like financial debt, the longer you wait to repay technical debt, the bigger it gets. With large-scale projects, it is of the utmost importance to continuously monitor technical debt, and to have a clear strategy to rein it in. A number of different methods can be used to control technical debt, such as having debt-specific Sprints, or devoting some project-development time to continuous improvement, for example.
Focusing on quality… Everyone agrees that identifying a bug during the development process is far less costly than having it appear later, during user acceptance testing or, even worse, at software launch. Continuous integration techniques and proper code review will help identify problems that, if corrected promptly, will save you huge amounts of time, money and energy. You must therefore make sure that your technology partner has all of the standard quality assurance tools required to ensure your project’s success: unit tests, integration tests, continuous integration tests, interface tests, function tests, etc.
And Security. Finally, always keep security considerations foremost in mind and never try to cheap out on security. Security onboarding at every step of the project is part of overall quality assurance.
Handover
The successful implementation of a new software solution, and its uptake by users, usually requires training to ensure that the handover goes quickly and smoothly. It is important to make decisions early on about the necessary training, expected user documentation and responsibilities on the part of the development team and everyone else involved. Your technology partner must be able to provide this service. As a rule of thumb, the greater the complexity of the software solution, the more support its users will need, both from people who master the new tool, and in the form of clear documentation.
Maintenance
Software must be maintained throughout its life. It is important to have a partner that can offer post-launch maintenance and support services. Your technology partner must also be proactive about foreseeable problems, like those caused by a new version of your operating system. It makes sense to plan for maintenance costs from the outset of a project, add them to the software-development costs, and factor them into the ROI calculation.