Développement logiciel Lean en 2017 ou Régime-Santé TI

Le Développement logiciel Lean est l’extension des principes Lean au Développement et à la Gestion de Produits et Services TI; plus particulièrement, on voudra éliminer tout travail qui n’apporte pas de valeur audit produit ou service TI.[1]

Lean Six Sigma est une méthodologie qui s’appuie sur un effort collaboratif d’équipe pour améliorer la performance en éradiquant de façon systématique le gaspillage (pertes )[1]et ce, sur huit plans : Transport, Inventaire, Mouvement, Attente, Surproduction, Sur-processus, Défectuosités et Talents (abréviation : ‘TIMWOODS’).

On ne saurait sous-estimer le rôle de plus en plus crucial de la fonction TI dans un contexte eBusiness et eCommerce où livrer de la qualité et de la valeur aux consommateurs est devenue la principale activité des entreprises. Les services et produits TI permettent souvent aux consommateurs de découvrir, commander et payer ainsi qu’aux employés et fournisseurs de communiquer, collaborer, gérer et exécuter / produire, etc.

(suite…)

La vraie nature du développement sur mesure en TI

Lorsqu’Analystik aborde un nouveau mandat de développement avec un client; l’objectif en est presque toujours d’automatiser un processus d’affaire et la méthodologie en est somme toute fort simple :

  • Analyse du processus existant
  • Étude des améliorations possibles au processus lui-même
  • Élaboration / schématisation d’une solution logicielle qui automatise le processus
  • Intégration aux technologies et processus connexes
  • Implantation

 

 

(suite…)

Analystik – 25 ans déjà et pourtant… toujours la même valeur

L’histoire d’Analystik ressemble sûrement à celle de milliers d’autres entreprises. Trois copains d’universités décident de partir en affaires avec l’insouciance de la jeunesse en tête et la passion au cœur.  Pour nous, c’était la passion de l’informatique et notre entreprise fut une firme de services-conseils TI, ce qui signifiait en fait « intégration et développement logiciel »; et bien sûr, nous étions convaincu de développer les meilleures applications au monde pour nos clients. Le passé n’est jamais garant de l’avenir mais…

Il y a tout de même des leçons à tirer du passage du temps; en ce sens, que si vous survivez, c’est que vous devez faire quelque chose de bien.  Et pour Analystik, la recette fut assez simple : nos valeurs.  Je sais, je sais, vous me direz : « Michel, ça fait très cliché »; et vous avez raison mais que dire, c’est tout simplement la vérité !

(suite…)

Projets TI : objectifs, portée, ressources, budgets, délais, livrables, etc.

L’augmentation de la productivité, la capitalisation sur l’avantage concurrentiel. Les réponses aux nouveaux besoins d’affaires passent souvent par les TI, ou peut-être devrais-je dire, un projet TIC, non ?

La traduction de ces modifications ou ajouts dans les systèmes de l’entreprise se fera à l’interne ou à l’externe. Mais, dans les deux cas, on rencontre encore bien souvent deux problèmes de base :

  • La portée des objectifs (et donc du projet) est mal définie et l’impact des modifications encourues est imprévisible
  • Le budget est mal attribué et parfois aussi, carrément irréaliste ou fortement sous-estimé

Ces deux facteurs sont responsables de la mauvaise tournure de la très grande majorité des projets informatiques. Ils dépassent les budgets et échéances ou encore n’atteignent pas leurs objectifs, quand ce n’est pas les deux; ces deux cas de figure sont le lot de 83% des projets informatiques selon les dernières études des références en la matière : Gartner, IDC, Forrester, etc.

 

Projets TIC… tac…

(suite…)

La Gestion des Attentes Client : réflexions d’un entrepreneur TI (14)

On ne compte plus le nombre de projets TI qui se sont soldés par un échec relatif : échec sur le plan des budgets et / ou des échéances, cela est assez commun au point où cela semble être presque perçu comme normal aujourd’hui, même si ça ne devrait pas être le cas.  Ce dont on parle moins souvent toutefois, c’est des échecs sur le plan des attentes du Client.

La raison en est fort simple; lorsqu‘il y a divergence sur ce plan entre le Client et le développeur TI, le processus de développement logiciel amène presque toujours les deux parties à conclure que des besoins nouveaux sont apparus en cours de projet ou que des besoins initiaux n’ont tout simplement pas été identifiés à l’origine du projet.

Ces deux hypothèses de travail couvrent une large partie des cas. Mais, pas tous, et la réalité est parfois toute autre et aussi toute simple !

(suite…)

Réflexions d’un entrepreneur TI (6) : variations du coût de développement d’une application

C’est la question à cent mille balles, comme disent nos amis Français : combien cela coûtera-t-il à développer cette application ?   Malheureusement, la réponse n’est jamais simple et jamais unique car il y a mille et un facteurs qui en feront varier le coût de développement… dont la méthodologie de travail et la notoriété de l’entreprise soumissionnaire ne sont pas les moindres !

Le client saisit-il bien toutes les subtilités et les implications sur le plan du développement logiciel de ses objectifs d’affaires ?  Veut-il une couche importante d’Intelligence d’Affaires ?  Quelle est la nature et l’état de son environnement TI actuel ?  Y a-t-il conflit en perspective ou incompatibilité entre l’application souhaitée et les systèmes / applications en place ?  Faudra-t-il développer d’autres applications ou mettre en place d’autres systèmes afin d’arrimer cette application ?   Dans quelle mesure, cette application est-elle critique à l’atteinte des objectifs d’affaires  de l’entreprise du client et si c’est le cas, devrons-nous remplacer certains systèmes en place ou en implanter d’autres ?  Devrons-nous optimiser certains processus des applications en place afin d’harmoniser l’interaction avec l’application développée ?  Quelle méthodologie le développeur utilisera-t-il ?  Quelle est l’architecture retenue ?

S’agit-il d’un billet sur la Gestion de Projets ?  Loin de là.  Et Dieu sait que la gestion de Projets a fait couler beaucoup d’encre en TI depuis une décennie et que cela mériterait toute une série de billets en soi… que nous ferons peut-être en 2010.  Mais pour les besoins de ce billet, nous prendrons pour acquis que tous les développeurs appliquent de bonne pratique en matière de Gestion de Projets.

(suite…)