Faire comprendre aux non-programmeurs le processus de développement
Lorsque vous démarrez un projet pour une entreprise qui n'est pas principalement une entreprise de programmation, l'une des attentes est qu'il y ait un produit fini à la fin exempt de tout bogue et fasse tout le nécessaire immédiatement. Cependant, c'est rarement le cas.
Comment gérer les attentes et expliquer aux non-programmeurs en quoi le développement logiciel diffère des autres types de développement de produits?
Presque tout le monde avec un ordinateur a rencontré le concept de "bugs" ces jours-ci, vous pouvez donc commencer par là. "Quelle est la façon la plus ennuyeuse qu'une application vous ait jamais échoué? Multipliez cela par dix, et vous aurez l'expérience de nos utilisateurs si nous ne consacrons pas suffisamment de ressources aux tests et à la maintenance."
Et ne sous-estimez pas la valeur de l'établissement d'une bonne relation de travail avec les non-programmeurs. Si vous pouvez établir que votre jugement est digne de confiance, ils vous prendront au sérieux lorsque vous sonnerez l'alarme que X va échouer de façon spectaculaire si vous ne faites pas Y pronto, même s'ils ne comprennent pas complètement votre raisonnement.
Une approche que j'ai trouvée réussie est la suivante:
Nous savons tous qu'un ordinateur fait seulement et exactement ce qu'on lui dit de faire.
La programmation est la façon dont nous disons à un ordinateur maintenant ce que nous devons faire plus tard .
Cela signifie que la façon dont votre comportement se comporte maintenant est due aux intentions combinées de tous ceux qui ont écrit le code qui s'exécute sur votre machine. Lorsque vous considérez la complexité du système d'exploitation, des pilotes, de l'environnement de programmation, des bibliothèques, etc., il est facile de voir que dans la plupart des systèmes, il doit y avoir plus de 20 000 personnes impliquées et qu'il peut y en avoir plus de 100 000.
Le code écrit par chaque personne reflète sa propre compréhension, motivation, intention et capacité. Étant donné que le fonctionnement sans faille du système nécessite que tout du code écrit par ces 20 000 personnes interagisse sans erreur - que tout du code doit s'accorder sur la signification et l'interprétation du comportement requis, le fait surprenant n'est pas que nous avons des bugs, mais que nous en avons si peu.
OMI, j'ai trouvé que la transparence offerte par les processus agiles (par exemple Scrum, Crystal, etc.) contribue grandement à montrer comment le développement fonctionne pour la partie prenante moyenne.
L'explication par métaphore est une abstraction qui fuit, mais voici quelques idées qui fonctionnent souvent pour moi:
Notez qu'aucune de ces explications n'excuse un travail bâclé.
Considérez un programme informatique comme une machine, où chaque variable est une pièce mobile. Cela fait même d'un programme trivial une machine composée de centaines de pièces mobiles.
Lorsque cela échoue, je retombe sur le fait que, même s'il est mathématiquement possible de prouver qu'un programme ne comporte aucune erreur, il prend énormément de temps et n'en vaut pas la peine.
Enfin, je demande si Intel et Microsoft ne parviennent pas à éviter les bugs, comment attendent-ils de nous?
La manière traditionnelle de l'énoncer est le triangle de gestion de projet: les trois critères concurrents de portée, de coût et de calendrier; généralement exprimé comme "bon marché, rapide, bon - choisissez deux".
À la fin d'un processus de conception, de développement et de déploiement, l'attente qu'un produit soit relativement exempt de défauts de conception et fonctionne avec une fonctionnalité spécifiée est parfaitement raisonnable. La même attente est totalement déraisonnable à l'égard d'un projet, d'un processus ou d'une profession.
Quel professionnel basé sur les sciences, dur ou mou, ne passe pas par un processus d'exploration, formant des conceptualisations inexactes et imprécises, suivant des tactiques moins qu'optimales (ou tout simplement fausses), découvrant ce qui fonctionne par essais et erreurs, et répétant le processus encore et encore jusqu'à ce que les ressources soient épuisées ou qu'un niveau de performance suffisant soit atteint?
Aucun processus n'est jamais exempt de défauts, bien qu'il puisse s'approcher asymptotiquement de niveaux de qualité supérieurs.
Cela est vrai de la profession médicale où les tactiques impliquent souvent des conjectures et des protocoles, et une grande partie de l'activité consiste essentiellement à déboguer une machine principalement sur Internet. C'est le cas du génie civil et de l'architecture où les applications de nouveaux matériaux d'ingénierie doivent être validées sur le terrain et peuvent échouer brusquement après des années de service malgré le strict respect des normes. C'est le cas dans le domaine automobile où l'âge et les changements des conditions de fonctionnement affectent généralement les performances jusqu'au point de défaillance, sans aucune faute des services d'ingénierie ou de réparation appliqués. Le développement de logiciels est pas fondamentalement différent de ces professions à de tels égards, il a juste une plus grande partie de son objectif impliqué dans la conception de nouvelles machines utiles.
J'ai répondu à une question similaire plus en détail , mais l'essentiel est, "La programmation, c'est comme construire une usine ou une chaîne de montage."
Vous pouvez le comparer à quelque chose qu'ils peuvent voir et, si possible, utiliser tous les jours.
Par exemple, l'automobile. Les voitures ont commencé avec des appareils beaucoup moins raffinés et fiables qu'aujourd'hui. Certes, les voitures sont fabriquées depuis plus de 100 ans, mais les logiciels ont probablement environ la moitié de cette durée. Les voitures sont disponibles avec une personnalisation importante, certaines incluses dans le prix (comme le choix de la couleur), d'autres comme la taille du moteur, le type de transmission, la roue/le pneu, le niveau de finition sont des facteurs de coût importants.
Il existe de nombreux facteurs de fonctionnalité, de qualité et de coût pour les voitures et les logiciels. Ensuite, vous pouvez discuter de la façon dont la technologie logicielle, la disponibilité de l'expertise, peut-être même où elle est construite, feront une grande différence. Les cycles de développement appropriés (par exemple, les modèles annuels avec de petits changements, les changements de carrosserie/moteur/plate-forme environ tous les trois ans) sont guidés par une combinaison des besoins des clients et un processus de conception complexe. Certains produits commencent à paraître petits et volumineux (pensez à la Honda Accord), mais s'améliorent chaque année jusqu'à ce qu'ils soient les mieux notés.
Les voitures ont des rappels (souvent beaucoup plus coûteux que les mises à niveau logicielles) et des améliorations incrémentielles sous la forme de modifications apportées à leurs listes de pièces (pensez à des corrections de bugs), et elles ont souvent besoin d'une assistance à long terme (pensez à la compatibilité ascendante/descendante). Une grande partie du coût de votre voiture vient après l'avoir ramenée chez vous. Une grande partie du coût du logiciel vient après la version initiale du produit lorsque vous mettez à jour et mettez à niveau les clients.
Dans certains cas, vous pouvez référencer des produits bien connus qui incluent des logiciels ou d'autres produits logiciels. Par exemple, les téléphones ont un cycle de publication et des mises à jour et des méthodes d'ajout de fonctionnalités après la vente initiale pour générer plus de revenus. Les téléphones sont une excellente illustration de la compatibilité avant/arrière. Trop, et les gens ne jetteront pas l'ancien pour en acheter un nouveau. Trop peu, et les clients désespèrent d'avoir un téléphone qu'ils ne détesteront pas avant la fin de son contrat.
Des produits comme Windows, Microsoft Office, les navigateurs Web et les pages Web sont tous des logiciels qui peuvent être utilisés dans les discussions. Ils ont été mis à jour sur des cycles annuels ou triennaux, mais peuvent avoir des mises à jour automatiques plus fréquemment. Ils ont des bogues et des failles de sécurité qui affectent les clients à des degrés divers, mais font partie du paysage malgré nos meilleurs efforts. Les clients peuvent obtenir des correctifs gratuitement, mais généralement payer pour des améliorations, souvent sous forme de bundle, parfois sous forme de module individuel ou via une clé de licence.
Les leaders de l'industrie comme Microsoft, Apple, Google et Amazon proposent tous des clients relativement peu coûteux aux utilisateurs. Mais ils ont d'énormes dépenses qui ont permis ces produits. Leur expérience montre que les logiciels sont chers, mais précieux et rentables. Ils font souvent des compromis entre la qualité, avoir toutes les fonctionnalités qu'ils veulent et entrer sur les marchés au bon moment. Tous les produits qu'ils fabriquent ne sont pas un succès, et ils transforment parfois les chiens en gagnants en renommant, en améliorant le marketing et les ventes, ou en réduisant leurs pertes et en utilisant ce qu'ils ont appris dans des produits ultérieurs.
Si vous êtes familiarisé avec le développement de logiciels à haute fiabilité, comme pour le contrôle des réacteurs nucléaires, les communications dans l'espace lointain ou les dispositifs d'implants médicaux (etc.), vous pourriez expliquer comment le coût et la structure des délais de livraison pour ce niveau de gestion des projets et d'assurance qualité pourrait être d'une ampleur supérieure à ce que les entreprises typiques peuvent se permettre pour leurs projets logiciels.
Essayez peut-être de les parcourir, individuellement ou en petits groupes, idéalement, utilisez des cas de logiciels que vous devez développer. Pendant qu'ils décrivent les cas d'utilisation, identifiez les points dans le cas où différentes choses pourraient se produire (cas inattendus mais pas déraisonnables). Commencez à les énumérer, à demander des éclaircissements et à illustrer toutes les décisions et orientations qui doivent être prises ou réglées, ainsi que les compromis à faire. Continuez jusqu'à ce qu'ils soient perplexes et ne puissent pas vous donner de réponse. Faites-leur comprendre que ce que vous faites maintenant avec eux est exactement ce que vous faites toute la journée, probablement de votre propre chef, probablement avec une direction beaucoup moins claire, à la fois pour décider du cours et pour écrire le code, pour des centaines ou des milliers de utiliser des cas qui peuvent ou non être présentés par quiconque. Et quand il y a un cas auquel vous n'aviez pas pensé, vous ne pouvez pas garantir ce que fera le programme. Peut-être qu'il fait la "bonne" chose, peut-être notez. Et c'est ce qu'est un bug. Et c'est pourquoi écrire un logiciel prend du temps. Le moins de temps dont vous disposez, le moins de cas que vous avez eu la chance d'examiner et d'accommoder, et le plus probable que le programme ne fera pas la "bonne" chose dans une circonstance inconnue.
Coût et temps.
Heure
Définissez les attentes selon lesquelles vous fourniriez X dans Y quantité de temps. Il n'aura rien de plus, rien de moins. Dites-leur ensuite ce que la prochaine version aura à quelle heure. Au début, ils pourraient être surpris de croire que la construction de X prend du temps - c'est là que vous expliquez le temps et la complexité de la construction d'un logiciel. S'ils ne sont pas surpris, soit vous avez estimé très peu de temps, soit ils savaient mieux que vous ne pensez à la création de logiciels.
Coût
Ceci est tiré du livre Code Compete de Steve McConnel (citant de mémoire, alors pardonnez-moi si je ne pouvais pas le transmettre avec le même effet) - Il est facile pour les clients de demander de nouvelles fonctionnalités. En tant que chef de produit, vous ne devez pas dire à ce que le client demande. Vous devez estimer les efforts et les coûts nécessaires pour créer cette nouvelle fonctionnalité. Ils comprendront lentement que la nouvelle fonctionnalité ne vaut pas vraiment le temps/l'argent ou peut-être qu'ils n'en ont même pas besoin. Je ne suggère pas que vous utilisiez cette arme pour les effrayer, mais utilisez-la honnêtement et cela pourrait aider à ramener le point à la maison.