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


52

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.


Les bons développeurs vont surtout s'entraîner.
kevin cline

20
@kevincline: Tous les domaines ne se prêtent pas à un auto-apprentissage facile.
FrustratedWithFormsDesigner

Dans quelle mesure est-il réaliste d’avoir une spécification détaillée qui ne possède pas une connaissance du domaine? Il faut également compenser le fait de spécifier plus en détail dans la spécification que cela peut prendre plus de temps et ne vaut donc pas la peine dans certains cas.
JB King

22
Je pense que plus le domaine est complexe, plus il est essentiel que les développeurs le comprennent et plus il ne faut pas externaliser le développement.
HLGEM

3
Remarque: s / developers / testers / dans cette question et cela reste pertinent.
joshin4colours

Réponses:


114

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.


52
+1 Parce que j'ai vu cela se produire dans la vraie vie. Le développeur principal a demandé à plusieurs reprises à l’entreprise de vérifier une exigence, l’entreprise a assuré à l’équipe que l’exigence était correcte, puis le développement a été contraint de s’embrouiller le lendemain du lancement parce que l’entreprise enfreignait la loi en vigueur dans deux États.
Joshua Drake le

9
ou, pour le regarder autrement, une spécification suffisamment détaillée est le code source et nécessite donc un développeur possédant des connaissances de domaine pour l'écrire
jk.

@ Josué - n'est-ce pas un cas où il était inutile d'avoir une connaissance du domaine? - les développeurs devaient implémenter les spécifications indépendamment (au moins jusqu'au jour de la panique).
Steve314

3
@ Steve314 assez bien. Et dans l’intérêt de l’honnêteté intellectuelle, le développeur a principalement rappelé la discussion sur l’implémentation de la fonctionnalité d’origine, et a même émis un commentaire de code sur le fait de ne pas supprimer cette information, conformément à jk. J'ai constaté que la connaissance du domaine aide souvent le développeur à localiser les lacunes dans la spécification, ou du moins à le faire, ce qui permet d'améliorer la qualité et de répondre plus rapidement aux besoins de l'entreprise.
Joshua Drake le

2
Un propriétaire d’entreprise peut engager un développeur, mais au final, la spécification tient à ce que celui-ci reste seul. Lorsque vous vous présentez devant les assemblées législatives des États, vous ne pouvez pas dire "Mais on m'a dit de le faire" ou "le courage intellectuel ne me convenait pas". Cela ne suffira pas. Souviens-toi de ça.
Ben DeMott

63

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.


7
Règles cachées - Je trouve qu'elles sont la norme plutôt que l'exception.
Preet Sangha

16

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.


+1, les développeurs (comme dans les architectes non système) ne devraient pas avoir besoin de connaissances du domaine. Dans une organisation parfaite, le codage doit être effectué par petits morceaux ne nécessitant aucune connaissance du produit final. Maintenant, combien d’organisations "parfaites" existent dans le monde ... Cela ressemble généralement à ceci: Ajoutez une fonctionnalité expliquée par une ligne contenant des phrases: vous savez, en quelque sorte, comme dans cette page Web, ...
Juha

1
Je ne pense pas que le seul propriétaire du produit ayant connaissance du domaine soit la recette du succès.
Casey

11

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 ...


1
Oui, et bon nombre d’entre eux (comme votre exemple d’intérêt négatif) sont aussi fondamentaux pour le domaine des affaires, il ne leur est jamais venu de les spécifier, car «tout le monde» le sait.
HLGEM

10

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.


"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." - Non. Les programmeurs acquièrent (en partie) la connaissance du domaine en interrogeant l'expert du domaine. L'expert du domaine peut dire aux programmeurs ce qu'il veut construire. Les programmeurs doivent en apprendre suffisamment sur le domaine pour pouvoir discuter des fonctionnalités avec l'expert du domaine.
Marnen Laibow-Koser

@ MarnenLaibow-Koser La deuxième partie de ma réponse est la nécessité pour les développeurs d’obtenir une connaissance du domaine. La "connaissance" peut provenir d'un expert, d'un livre, d'Internet, etc. avoir accès à un expert est utile, mais non déterminant.
dasblinkenlight

Ce n'est pas mon principal point de désaccord. Mon principal point de désaccord est votre affirmation selon laquelle l'accès à un expert du domaine n'aidera pas les programmeurs à déterminer ce qu'ils doivent créer. En fait, c’est précisément cet accès qui aidera le plus les programmeurs - et je le sais parce que j’ai fait la même chose pour différents projets.
Marnen Laibow-Koser

8

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.


6

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 .


5

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.


D'accord. Si rien d'autre, l'entreprise est beaucoup plus susceptible de faire appel à ce développeur à nouveau, tout simplement parce que le développeur "sait les ficelles du métier" et que l'entreprise n'a pas à perdre son temps à former un nouveau programmeur chaque fois que le service informatique choisit d'envoyer leur dernier programmeur générique, polyvalent et polyvalent, afin de travailler sur le dernier ensemble d’exigences.
Phill W.

3

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).


2

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.


2

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.


J'ai l'habitude de constater que lorsqu'un individu résout lui-même un problème sans consulter les autres, il en résulte un taux de désabonnement élevé. Vous ne pouvez pas oublier d'inclure d'autres personnes dans votre architecture logicielle ... Vous connaissez peut-être bien le domaine, mais les logiciels ne sont pas un casse-tête que vous devriez mettre en page plusieurs fois.
visc

2

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.


2

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?


2

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.


++ 1 "programmation de la marche de la mort". C'est comme aux États-Unis l'histoire du bébé au goudron .
Mike Dunlavey

1

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.


1

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 .


1
En tant que pigiste, je vous assure que je dois au moins comprendre suffisamment les entreprises de mes clients pour leur parler intelligemment des fonctionnalités qu’ils souhaitent. L’idée que vous puissiez rédiger une spécification sans comprendre l’entreprise est une chimère. L'idée est donc que vous pouvez écrire une spécification parfaite et la jeter "par-dessus le mur" à un développeur.
Marnen Laibow-Koser

1

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.


3
Les ingénieurs industriels ont besoin de cette double connaissance, comme pratiquement tous les analystes. Cela ne se limite pas au développement de logiciels.
HLGEM

4
Un rédacteur technique a la même situation.
Jennifer S

1

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.


1

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).


Le dernier paragraphe est particulièrement vrai dans les domaines commerciaux où vous pouvez avoir des ennuis juridiques si le système n'est pas correctement construit.
HLGEM

Je ne suis pas d'accord: rien ne garantit qu'un développeur compétent à long terme puisse apprendre «l'entreprise». Cela nécessite toujours une certaine organisation de la compagnie, et c'est particulièrement grave avec les équipes satellites.
Darien

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.