Les développeurs doivent-ils comprendre le domaine commercial ou la spécification doit-elle être suffisante?

Je travaille pour une entreprise dont le domaine est vraiment difficile à comprendre car il s'agit d'une technologie de pointe en électronique, mais cela s'applique à tout développement logiciel dans un domaine complexe.

L'application sur laquelle je travaille affiche beaucoup d'informations, de graphiques et de mesures difficiles à comprendre sans expérience du domaine. Le développeur utilise une spécification pour décrire ce que le logiciel doit faire, par exemple en spécifiant qu'un graphique particulier doit afficher ce type de métrique et que cette métrique correspond à la formule arithmétique suivante.

De cette façon, le développeur ne comprend pas vraiment le métier et pourquoi / pourquoi il accomplit cette tâche. Cela peut convenir si la spécification est vraiment détaillée, mais lorsque ce n'est pas le cas ou lorsque l'auteur a oublié un cas d'utilisation, le développeur a beaucoup de difficulté à trouver une solution.

D'autre part, former chaque développeur à tous les aspects métier peut être très long et difficile.

Devrions-nous accorder plus d'importance aux spécifications détaillées (mais comme nous le savons, la spécification parfaite n'existe pas) ou devrions-nous former tous les développeurs à comprendre le domaine métier?

EDIT: n'oubliez pas dans votre réponse que la société peut utiliser des développeurs externes et qu'une formation sur tout le domaine peut durer environ 2 semaines.

La spécification n'est pratiquement jamais suffisante. Les développeurs qui ne possèdent pas de connaissances sur le domaine ne peuvent pas indiquer quand la spécification est erronée (une occurrence fréquente dans la plupart des endroits) et faire de mauvais choix de conception.

D'après mon expérience, après avoir travaillé dans 3 industries très différentes maintenant, vous pouvez commencer par ne pas en savoir beaucoup sur le domaine, mais vous aurez besoin de l'apprendre un jour et quelqu'un devra le comprendre de manière détaillée.

Le problème essentiel réside dans l'impédance client-développeur: ils veulent quelque chose mais ne le savent que lorsqu'ils le voient et que vous voulez résoudre leur problème, mais vous ne pouvez pas toujours avoir une idée claire de ce qu'est ce problème. Plus vous apportez de connaissances sur le domaine de l'industrie (du client) que vous (le développeur) pouvez apporter, plus vous pourrez facilement traduire de vagues "désirs" en "problèmes" concrets et les résoudre.

À titre d'exemple anecdotique, mon travail précédent était dans l'industrie chimique impliquant un logiciel de gestion d'usine. J'ai commencé avec pratiquement aucune connaissance du domaine, mais j'ai pu implémenter le code nécessaire pour résoudre les problèmes secondaires présentés par le développeur principal et les clients. Au fil du temps, j'ai fait l'effort d'apprendre l'industrie afin de pouvoir communiquer plus facilement au niveau du client. Ayant compris leur industrie, j'ai commencé à comprendre quels étaient les problèmes réels. Quand ils disent des choses comme "nous devons suivre toutes les valeurs de données de ce module", je peux traduire cela en ce qu'elles signifient vraiment, ce qui est "nous devons conserver un enregistrement historique de chaque valeur générée par ce capteur, stockée pendant X jours rétention, mais toujours évaluée en fonction de la lecture la plus récente de ce capteur ".

Donc, oui, quelqu'un a besoin d'une connaissance du domaine, et de préférence d'un développeur, car les problèmes de domaine ne sont pas des problèmes de code et la traduction entre les deux n'est pas anodine. En fin de compte, tout développeur intéressant à garder sur votre équipe devrait choisir le domaine afin de pouvoir faire des choix plus éclairés sur les nuances de son code.

QUELQU'UN sur le projet doit avoir une connaissance assez complète du domaine. Cette personne peut être ou non le développeur.

Dans les projets Agile, le propriétaire du projet client est cette personne et ils travaillent en étroite collaboration avec l'équipe. Dans les projets non-agiles, un membre de l'équipe doit acquérir ces connaissances, mais ce n'est généralement pas le cas, ce qui explique en partie pourquoi les projets non-agiles sont aussi sujets à l'échec.

Il y a beaucoup d'excellentes réponses. J'ajoute le mien car, après les avoir lues et recherchées, j'ai constaté que personne ne mentionnait un problème clé: les bugs .

Si l'équipe ne dispose pas de suffisamment de personnes disposant de suffisamment d'autorité et d'expertise sur le domaine, des bogues vont inévitablement se manifester tôt ou tard. Avec une connaissance du domaine, il existe des valeurs / résultats / relations / sens / sens impossibles ou non sensuels. On peut espérer qu’une spécification les indique explicitement, mais en réalité, le mieux que vous puissiez faire est d’éviter les plus évidentes (alertez-moi si les taux d’intérêt deviennent négatifs, ou des choses comme ça, cela pourrait être ou ne pas être une erreur, mais plutôt une erreur. assez étrange pour être remarquable).

Ceci est fortement lié à la compréhension des raisons des choix, et dans le meilleur des cas, cela conduit également à de meilleurs logiciels (parce que si on connaît réellement la raison d’une demande, on peut y penser, plutôt que de l’accepter comme une donnée. ).

Rappelez-vous qu'Einstein avait déclaré "Mais la pensée et les idées, et non les formules, sont le début de toute théorie physique" , c'est-à-dire que l'on ne pense pas en termes de formules abstraites, mais d'idées ...

Si vous mettez une personne qui ne connaît que l'anglais et une personne qui ne connaît que le japonais dans une pièce, ils ne pourront pas traduire du japonais en anglais, bien qu'ils soient des experts de leurs langues respectives. Pour la même raison, même les programmeurs experts n'ayant aucune connaissance du domaine sont impuissants à déterminer ce qu'ils doivent construire, même lorsqu'ils ont un accès 24 heures sur 24, 7 jours sur 7, au meilleur expert de domaine qui n'est pas également un expert en développement de logiciels.

Une spécification est une tentative de traduction du "japonais" des exigences du domaine en "anglais" des exigences de la programmation. Lorsque vous obtenez une qualité de traduction comparable à celle de Google Translate, c’est votre jour de chance; la plupart du temps, la qualité n’est tout simplement pas au rendez-vous, vous n’avez donc aucun moyen d’acquérir au moins une connaissance du domaine. Avec un peu de persistance, cela fait de vous un "traducteur" décent à la fin du projet, de sorte que votre valeur pour votre entreprise augmente considérablement. La plupart du temps, vous vous amusez également beaucoup dans le processus. Il s'agit donc d'une situation gagnant-gagnant.

Sans certaines connaissances en affaires, vous vous retrouvez avec des développeurs qui ne posent pas de questions et codent stupidement ce que disent les spécifications. Je pense qu'il faut des "penseurs" pour créer de bons logiciels, pas seulement des personnes capables de frapper sur un clavier. Comprendre non seulement "Ce que" vous faites mais "Pourquoi" et la façon dont cela s'inscrit dans le tableau contribue à une plus grande satisfaction de l'équipe de développement.

Je pense que vous devriez essayer d'obtenir la connaissance du domaine. Les spécifications sont une liste de contrôle indiquant ce que le produit final doit faire et qui est requis pour la validation de votre produit. En tant que développeur, vous devez toujours essayer de comprendre quel est le véritable problème que vous essayez de résoudre. Obtenir la connaissance du domaine vous aidera à comprendre cela.

Cela vous aidera à concevoir et à coder facilement car vous comprendrez quelles sont les parties qui changent (par exemple, les règles) et les mettez séparément. Vous n'avez pas besoin d'être un expert, mais vous pouvez parler à un utilisateur final dans sa langue .

Vous pouvez conduire une voiture avec des connaissances de base; mais si vous voulez profiter de la balade, vous devez en apprendre davantage sur son utilisation. Comme pour d’autres métiers, il n’est pas obligatoire de comprendre le domaine, mais c’est amusant de le faire .

Je pense qu'un développeur qui connaît l'entreprise vaut son pesant d'or.

Dans un scénario "traditionnel" où l'entreprise a des exigences et que certains analystes traduisent en exigences techniques, le développeur s'appuie sur ceux qui ont inévitablement deux choses à faire:

1. Vous avez plusieurs points d'échec. Il se peut que l’analyste commercial n’ait pas parfaitement traduit toutes les exigences de l’entreprise et / ou que le développeur n’en traduise pas parfaitement les spécifications techniques. Une variante du scénario "secret autour de la salle". Juste les exigences de la communication.

2. Un ou tous les propriétaires, analystes ou développeurs d’entreprises sont suffisamment nouveaux pour que l’organisation manque des éléments clés auxquels ils ne penseraient pas normalement. Le développeur expérimenté qui connaît bien l'entreprise peut aider à éduquer les personnes occupant ces autres rôles pour rendre le produit plus complet.

Il y a presque toujours des compromis à faire entre la valeur de chaque caractéristique de la spécification, la précision avec laquelle la spécification doit être implémentée et sa valeur, et le coût de toute combinaison de caractéristiques spécifiées. Souvent, de bons compromis ne peuvent être faits que lorsque les connaissances nécessaires pour faire tout ce qui précède existent dans une seule personne ou dans une équipe travaillant étroitement, y compris le véritable architecte de logiciel et / ou le codeur.

Sans ces connaissances extrêmement localisées et peut-être même des sentiments instinctifs, le résultat peut facilement devenir un produit très coûteux, presque inutile, qui répond de très près aux spécifications écrites.

Le coût de la création d’une spécification qui n’a pas les problèmes ci-dessus peut souvent être supérieur à celui de former l’architecte et / ou les codeurs à avoir suffisamment de connaissances du domaine pour travailler avec une spécification moins impénétrable (en supposant que la légalité et les contrats commerciaux le permettent).

Oui, les développeurs doivent connaître l'entreprise dans une certaine mesure. Ils n'ont pas besoin de connaître chaque détail à la minute près, mais ils doivent avoir une compréhension de base du rapport utilisé et de son utilisation dans le processus métier. Plus vos développeurs comprennent le métier, meilleure est la solution qu'ils peuvent offrir.

D'après mon expérience *, une seule personne possédant une bonne connaissance du domaine problématique et une bonne connaissance du développement logiciel est plus susceptible de trouver la solution optimale à un problème que deux personnes, l'une avec une excellente connaissance du domaine problématique et l'autre avec une excellente connaissance de développement de logiciels, travailler ensemble.

Je pense que cela se résume au simple fait que la communication dans le cerveau d'un seul individu est plusieurs fois plus rapide et meilleure que la communication entre des individus.

* L'expérience principale sur laquelle je m'appuie pour répondre à cette question est plus de 10 ans consacrés au développement d'un logiciel de comptabilité (du débutant au «mode maintenance»). Bien que mes connaissances en développement de logiciels soient plutôt bonnes par rapport à mes collègues, je me sentais souvent handicapé par un manque de compréhension du domaine problématique.

Je voudrais répondre en tant que personne issue du monde des affaires, qui travaille avec des développeurs qui manifestent peu d'intérêt pour apprendre les bases du métier, semblent parfois même être fiers de ne pas avoir à connaître ces bases: le problème est que le Les développeurs ne seront pas en mesure de déceler à première vue les erreurs dans les résultats (résultats non plausibles, signes erronés, etc.), ce qui nécessite soit des tests détaillés (que nous n'avons pas encore développés), soit une surveillance constante des résultats. En ce qui concerne autant que je souhaite apprendre les bases du développement logiciel pour faciliter la communication, je voudrais exhorter les développeurs à faire de même.

Vous n'êtes pas obligé, mais pourquoi ne voudriez-vous pas?

Je m'inquiéterais de tout programmeur qui était réticent et surtout incapable d'apprendre le domaine dans une certaine mesure. Il est important de sortir de la "tour de code de l'ivoire" une fois de temps en temps.

Écrire du code sans avoir la moindre idée de son utilisation et de sa fonction n’est pas une tâche facile. Qui veut simplement casser des briques alors que vous pourriez construire des cathédrales?

Plus un développeur est impliqué et plus expérimenté dans l'entreprise, plus il est important de posséder au moins une connaissance du domaine de niveau intermédiaire ou des zones plus nuancées de ce secteur pouvant être critiques ne seront pas comprises par l'équipe de développeurs.

Cependant, une spécification devrait suffire pour les tâches de niveau inférieur. En bref, il est préférable de former votre main-d’œuvre à un niveau inférieur. Ils sont peut-être le meilleur programmeur polyglotte du monde, mais s’ils ne peuvent pas comprendre le problème de manière assez approfondie, ils sont toujours voués à une programmation en échec ou à la mort.

Il devrait toujours y avoir une spécification - vous ne pouvez pas vous attendre à ce que tous les développeurs deviennent des experts de domaine. En même temps, si les développeurs suivent aveuglément une spécification sans comprendre vraiment à quoi elle sert, le résultat ne sera peut-être pas vraiment ce que les clients veulent. Il arrive souvent que lorsqu'un développeur a un niveau de compréhension même assez décent (mais non expert), il peut détecter les erreurs et les omissions dans les spécifications. Ils peuvent également contribuer au processus et donner un retour d’information qui peut améliorer considérablement le produit final.

Il serait peut-être intéressant de faire appel à des experts de domaine dont le travail consiste à assurer la liaison entre les clients et les développeurs pour aider les développeurs à mieux comprendre et également pour aider à la rédaction des spécifications.

Je pense que c'est difficile de donner une réponse de toute façon.

Il est difficile de voir comment, par exemple, un développeur indépendant peut comprendre le métier (ou la science) à l'origine de chaque application qu'il développe. Dans cette situation, je pense qu'il est plus important que le développeur sache poser les bonnes questions sur la spécification ou le modèle commercial que pour bien comprendre le métier lui-même.

Un développeur d’entreprise en revanche, supposant qu’ils exercent les mêmes activités depuis un certain temps, aurait vraiment dû savoir comment l’entreprise fonctionnait après quelques mois (ou peut-être même quelques années). En grande équipe, vous pouvez également avoir un architecte qui comprend l'entreprise plus clairement que les développeurs.

Dans les PME avec des développeurs isolés, il est important que les développeurs discutent fréquemment avec les propriétaires / gestionnaires afin d'éviter de se lancer dans une mauvaise opération.

Il y a donc beaucoup de façons possibles de penser à cela, mais la clé est la même dans tous les cas: la communication .

Le développement de logiciels est la seule profession que je connaisse qui vous oblige non seulement à maîtriser votre propre profession, mais également à avoir une compréhension de base de la profession dans laquelle vous travaillez. Il est important de connaître suffisamment le domaine pour communiquer avec les autres développeurs dans la langue du client. En tant que développeur, vous ne pouvez pas toujours compter sur les autres pour vous former. Parfois, vous devez vous débrouiller seul avec des recherches personnelles, souvent en dehors des heures de travail habituelles.

Je comprends vraiment ce que vous voulez dire ici car nous, en tant qu’entreprise dans une industrie du tourisme, sommes confrontés au même problème. Lorsque j'étais développeur junior, j'étudiais également le tourisme dans un collège. Donc, vous pouvez deviner que je ne viens pas d’informatique, mais que ma connaissance du tourisme est élevée.

À l'époque, nous construisions des produits en relation avec d'autres éditeurs de logiciels, mais les connaissances spécifiques à un domaine manquaient beaucoup. Comme vous l'avez décrit, il est vraiment difficile de bien faire les choses si vous construisez un produit dans l'industrie du tourisme, car il existe de nombreuses préoccupations transversales, etc.

Donc, ce mouvement a donné beaucoup de mauvais résultats à long terme. Ensuite, nous avons fait un énorme pas en avant et je me suis concentré uniquement sur le développement plutôt que sur la partie commerciale du projet. Ayant les connaissances industrielles et les connaissances en programmation, le projet devient plus efficace que jamais. Sans oublier que nous pouvons alors prendre des décisions plus rapidement, car j'ai l'expérience des deux côtés de la médaille.

Pour répondre concrètement à votre question, c’est bien oui, à mon avis personnel. Si le projet sur lequel votre équipe travaille est un projet à long terme, prenez le chemin difficile et formez votre personnel aux bases et aux détails spécifiques à un domaine.

Si un développeur reste dans une entreprise / un secteur pendant une longue période, il apprendra lentement mais sûrement "l'entreprise".

Certaines entreprises reconnaissent et dispensent une formation dans "l'entreprise". Les sociétés financières en sont un bon exemple.

Plus vous en apprendrez sur l'entreprise, plus il sera facile de parler à vos utilisateurs. Ils auront plus confiance en vous. Vous comprendrez mieux les inconvénients d'un système qui pourrait mal tourner s'il ne fonctionne pas exactement comme prévu pour l'utilisateur.

Pour répondre à votre question, le cahier des charges n’est JAMAIS suffisant. Le problème commun est qu'ils ne contiennent souvent pas assez d'informations et sont rapidement obsolètes.

L'expérience du domaine commercial peut être obligatoire pour certaines entreprises. Ils recherchent des développeurs ayant une expérience dans le domaine lors de l'embauche. Certaines entreprises ont même mis cela plus haut que les compétences techniques réelles. (Aucune expérience financière, aucune interview n'est très courante, certainement ici au Royaume-Uni).

D'expérience personnelle, la spécification est suffisante tant que vous avez un membre de l'équipe qui travaille avec vous et qui possède la connaissance du domaine.

Je travaille dans un secteur très spécialisé: nous fabriquons des logiciels pour les médias audiovisuels. Je connais à peine une chose en ce qui concerne la radiodiffusion, mais je connais le code et les données, et l’équipe de gestion de projet comprend des personnes compétentes qui comprennent la radiodiffusion. Depuis quelques années, cette formule me permet de proposer de bonnes fonctionnalités qui plaisent aux clients.