Müssen Entwickler den Geschäftsbereich verstehen oder sollte die Spezifikation ausreichen?

Ich arbeite für ein Unternehmen, für das die Domäne schwer zu verstehen ist, weil es sich um Hochtechnologie in der Elektronik handelt. Dies gilt jedoch für jede Softwareentwicklung in einer komplexen Domäne.

Die Anwendung, an der ich arbeite, zeigt viele Informationen, Diagramme und Metriken an, die ohne Erfahrung in der Domäne schwer zu verstehen sind. Der Entwickler verwendet eine Spezifikation, um zu beschreiben, was die Software tun muss, z. B. die Angabe, dass ein bestimmtes Diagramm diese Art von Metriken anzeigen muss und diese Metrik die folgende arithmetische Formel ist.

Auf diese Weise versteht der Entwickler das Geschäft nicht wirklich und was / warum er diese Aufgabe tut. Dies kann in Ordnung sein, wenn die Spezifikation wirklich detailliert ist. Wenn dies jedoch nicht der Fall ist oder wenn der Autor einen Anwendungsfall vergessen hat, kann der Entwickler nur schwer eine Lösung finden.

Andererseits kann es sehr langwierig und schwierig sein, jeden Entwickler in alle geschäftlichen Aspekte einzuarbeiten.

Sollten wir der detaillierten Spezifikation mehr Bedeutung beimessen (aber wie wir wissen, gibt es keine perfekte Spezifikation) oder sollten wir alle Entwickler darin schulen, den Geschäftsbereich zu verstehen?

BEARBEITEN: Denken Sie in Ihrer Antwort daran, dass das Unternehmen externe Entwickler einsetzen könnte und dass eine Formation für die gesamte Domain ungefähr 2 Wochen dauern kann

Die Spezifikation ist so gut wie nie ausreichend. Entwickler, die keine Domänenkenntnisse haben, können nicht darauf hinweisen, wenn die Spezifikation fehlerhaft ist (ein häufiges Vorkommen an den meisten Orten), und treffen schlechte Entwurfsentscheidungen.

Nach meiner Erfahrung, nachdem Sie in drei sehr unterschiedlichen Branchen gearbeitet haben, können Sie anfangen, nicht viel über die Domäne zu wissen, aber Sie müssen sie irgendwann lernen und jemand muss sie bis ins Detail verstehen.

Das wesentliche Problem liegt in der Client-Entwickler-Impedanz: Sie möchten etwas, wissen es aber nur, wenn sie es sehen und Sie möchten das Problem lösen, können sich aber nicht immer ein klares Bild davon machen, was dieses Problem ist. Je mehr Fachwissen über die Branche (des Kunden) Sie (der Entwickler) mitbringen können, desto einfacher können Sie vage "Wünsche" in konkrete "Probleme" übersetzen und diese lösen.

Als Anekdotenbeispiel war ich zuvor in der chemischen Industrie mit Anlagenverwaltungssoftware beschäftigt. Ich begann mit praktisch null Wissen über die Domäne, konnte aber den Code implementieren, den ich benötigte, um Teilprobleme zu lösen, die mir vom Senior-Entwickler und den Kunden vorgelegt wurden. Im Laufe der Zeit habe ich mich bemüht, die Branche kennenzulernen, damit ich auf der Ebene des Kunden besser kommunizieren kann. Als ich ihre Branche verstand, begann ich zu verstehen, was die tatsächlichen Probleme waren. Wenn sie Dinge wie "Wir müssen alle Datenwerte auf diesem Modul verfolgen" sagen, kann ich das in das übersetzen, was sie wirklich bedeuten: "Wir müssen eine historische Aufzeichnung jedes Wertes, den dieser Sensor erzeugt, für X Tage speichern Beibehaltung, aber immer basierend auf dem neuesten Messwert von diesem Sensor ausgewertet. "

Ja, jemand benötigt Domain-Kenntnisse und vorzugsweise einen Entwickler, da Domain-Probleme keine Code-Probleme sind und das Übersetzen zwischen beiden nicht trivial ist. Entwickler, die es wert sind, in Ihrem Team zu bleiben, sollten sich die Domain aussuchen, damit sie fundiertere Entscheidungen über die Nuancen ihres Codes treffen können.

JEMAND in dem Projekt muss ziemlich vollständige Domänenkenntnisse haben. Diese Person kann der Entwickler sein oder nicht.

In Agile-Projekten ist der Auftraggeber diese Person, die eng mit dem Team zusammenarbeitet. In nicht-agilen Projekten muss sich jemand im Team dieses Wissen aneignen, dies ist jedoch normalerweise nicht der Fall. Dies ist einer der Gründe, warum nicht-agile Projekte so fehleranfällig sind.

Es gibt viele hervorragende Antworten. Ich füge mein eigenes hinzu, weil ich nach dem Lesen und Suchen herausgefunden habe, dass niemand ein Schlüsselproblem erwähnt: Bugs .

Wenn dem Team nicht genügend Personen mit ausreichender Autorität und Domänenexpertise zur Verfügung stehen, werden sich früher oder später unvermeidlich Fehler einschleichen. Bei Kenntnis der Domäne gibt es unmögliche oder unsinnige Werte / Ergebnisse / Beziehungen. Man könnte hoffen, dass eine Spezifikation ausdrücklich darauf hinweist, aber in Wirklichkeit ist das Beste, was Sie erreichen können, die naheliegendsten zu vermeiden (benachrichtigen Sie mich, wenn die Zinssätze negativ werden, oder ähnliches - dies könnte ein Fehler sein oder könnte es nicht sein, ist es aber seltsam genug, um bemerkenswert zu sein).

Dies hängt stark mit dem Verständnis der Gründe für die Auswahl zusammen und führt im besten Fall auch zu einer besseren Software (denn wenn man den Grund für eine Anfrage kennt, kann man darüber nachdenken, anstatt sie als gegeben akzeptieren zu müssen ).

Denken Sie daran, dass Einstein sagte: "Aber Gedanken und Ideen, nicht Formeln, sind der Anfang jeder physikalischen Theorie." Das heißt, man denkt nicht in abstrakten Formeln, sondern in Ideen ...

Wenn Sie eine Person, die nur Englisch spricht, und eine Person, die nur Japanisch spricht, in einen Raum setzen, kann diese Person nicht vom Japanischen ins Englische übersetzen, obwohl sie Experten für ihre jeweiligen Sprachen ist. Aus dem gleichen Grund sind selbst erfahrene Programmierer ohne Domänenkenntnisse nicht in der Lage, herauszufinden, was sie erstellen müssen, selbst wenn sie rund um die Uhr Zugriff auf den besten Domänenexperten haben, der nicht auch Experte für Softwareentwicklung ist.

Eine Spezifikation ist ein Versuch, "Japanisch" der Domänenanforderungen in "Englisch" der Programmieranforderungen zu übersetzen. Wenn Sie eine Übersetzungsqualität erhalten, die mit der von Google Übersetzer vergleichbar ist, ist dies Ihr Glückstag. In den meisten Fällen ist die Qualität einfach nicht vorhanden, sodass Sie nicht daran vorbei kommen, sich zumindest ein wenig Domänenwissen anzueignen. Mit etwas Beharrlichkeit werden Sie am Ende des Projekts zu einem anständigen "Übersetzer", sodass Ihr Wert für Ihr Unternehmen erheblich steigt. Die meiste Zeit hat man auch viel Spaß dabei, es ist also eine Win-Win-Situation.

Ohne einen Aspekt des Geschäftswissens landen Sie bei Entwicklern, die keine Fragen stellen und gedankenlos codieren, was die Spezifikationen aussagen. Ich glaube, man braucht "Denker", um gute Software zu entwickeln, nicht nur Leute, die auf eine Tastatur schlagen können. Das Verständnis nicht nur dessen, was Sie tun, sondern auch dessen, warum und wie es in das Gesamtbild passt, trägt zu einer höheren Zufriedenheit des Entwicklungsteams bei.

Ich denke, Sie sollten versuchen, das Gebietswissen zu erhalten. Spezifikationen sind Checklisten, die angeben, was das Endprodukt tun soll und für die Validierung Ihres Produkts erforderlich ist. Als Entwickler sollten Sie immer versuchen, das eigentliche Problem zu verstehen, das Sie lösen möchten. Wenn Sie sich die Domain-Kenntnisse aneignen, können Sie das besser verstehen.

Es wird Ihnen helfen, einfach zu entwerfen und zu codieren, da Sie verstehen, was Teile ändern (sagen wir Regelsatz) und sie separat platzieren. Sie müssen kein Meister sein, können aber mit einem Endbenutzer in dessen Sprache sprechen .

Sie können ein Auto mit Grundkenntnissen fahren; aber wenn Sie die Fahrt genießen möchten, müssen Sie mehr darüber lernen, wie man sie genau benutzt. Wie bei anderen Trades ist es nicht zwingend erforderlich, die Domain zu verstehen, aber es macht Spaß, wenn Sie es tun .

Ich denke, ein Entwickler, der das Geschäft kennt, ist Gold wert.

In einem "traditionellen" Szenario, in dem das Unternehmen einige Anforderungen hat und einige Geschäftsanalysten diese in technische Anforderungen umsetzen, arbeitet der Entwickler an denjenigen, für die Sie unvermeidlich zwei Dinge haben:

1. Sie haben mehrere Fehlerquellen. Der Geschäftsanalyst hat möglicherweise nicht alle Geschäftsanforderungen perfekt übersetzt, und / oder der Entwickler übersetzt diese möglicherweise nicht perfekt in eine technische Spezifikation. Eine Variante des Szenarios "Geheimnis um den Raum". Nur die Anforderungen der Kommunikation.

2. Einer oder alle Geschäftsinhaber, Geschäftsanalysten oder Entwickler sind neu genug in der Organisation, um wichtige Dinge zu übersehen, an die sie normalerweise nicht denken würden. Der erfahrene Entwickler, der das Geschäft gut kennt, kann die Mitarbeiter in diesen anderen Rollen schulen, um das Produkt vollständiger zu machen.

Es müssen fast immer Kompromisse zwischen dem Wert jedes Merkmals in der Spezifikation, dem Grad der Implementierung der Spezifikation und den Kosten für die Erfüllung einer Kombination von Spezifikationsmerkmalen geschlossen werden. Oft können gute Kompromisse nur dann geschlossen werden, wenn das Wissen, um all das oben Genannte zu tun, in einer Person oder einem eng zusammenarbeitenden Team, einschließlich des eigentlichen Softwarearchitekten und / oder Programmierers, vorhanden ist.

Ohne dieses extrem lokalisierte Wissen und möglicherweise auch ohne Bauchgefühl kann das Ergebnis leicht zu einem sehr kostspieligen, fast unbrauchbaren Produkt werden, das der schriftlichen Spezifikation sehr nahe kommt.

Die Kosten für die Erstellung einer Spezifikation, die die oben genannten Probleme nicht aufweist, können häufig höher sein als die Schulung des Architekten und / oder der Programmierer, um über ausreichende Domänenkenntnisse zu verfügen, um mit einer weniger detaillierten Spezifikation zu arbeiten (vorausgesetzt, die Gesetzmäßigkeiten und Geschäftsverträge lassen dies zu).

Ja, Entwickler müssen das Geschäft bis zu einem gewissen Grad kennen. Sie müssen nicht jedes kleinste Detail kennen, aber sie sollten ein grundlegendes Verständnis dafür haben, wofür Bericht X verwendet wird und wie er im Geschäftsprozess verwendet wird. Je mehr Ihre Entwickler über das Geschäft wissen, desto besser ist die Lösung, die sie liefern können.

Basierend auf meiner Erfahrung * ist es wahrscheinlicher, dass eine einzelne Person mit guten Kenntnissen des Problembereichs und guten Kenntnissen der Softwareentwicklung die optimale Lösung für ein Problem findet als zwei Personen, eine Person mit hervorragenden Kenntnissen des Problembereichs und eine Person mit hervorragenden Kenntnissen der Software-Entwicklung, zusammenarbeiten.

Ich denke, es liegt an der einfachen Tatsache, dass die Kommunikation, die im Gehirn eines einzelnen Individuums stattfindet, um ein Vielfaches schneller und besser ist als die Kommunikation zwischen Individuen.

* Die wichtigste Erfahrung, auf die ich bei der Beantwortung dieser Frage zurückgreifen kann, sind mehr als 10 Jahre für die Entwicklung eines Buchhaltungssoftwarepakets (von der Einführung bis zum Wartungsmodus). Obwohl ich im Vergleich zu meinen Kollegen ziemlich gute Kenntnisse in der Softwareentwicklung hatte, fühlte ich mich oft durch das mangelnde Verständnis der Problemdomäne behindert.

Ich möchte antworten, dass jemand von der Geschäftsseite, der mit Entwicklern zusammenarbeitet, die wenig Interesse daran haben, die Grundlagen des Handels zu lernen, manchmal sogar stolz darauf zu sein scheint, diese Grundlagen nicht kennen zu müssen: Das Problem ist, dass die Entwickler werden auf den ersten Blick keine Fehler im Ergebnis sehen können (unplausible Ergebnisse, falsche Vorzeichen usw.), was entweder detaillierte Testfälle (die wir erst kürzlich entwickelt haben) oder eine ständige Überwachung der Ergebnisse erfordert. Soweit ich bereit bin, die Grundlagen der Softwareentwicklung zu erlernen, um die Kommunikation zu vereinfachen, möchte ich die Entwickler auffordern, dasselbe zu tun.

Musst du nicht, aber warum willst du nicht?

Ich wäre besorgt über jeden Programmierer, der zögerte und vor allem nicht in der Lage war, die Domäne bis zu einem gewissen Grad zu erlernen. Es ist wichtig, ab und zu aus dem "Elfenbein-Code-Turm" herauszukommen.

Code schreiben, ohne eine Ahnung zu haben, wie er verwendet wird und zu welchem ​​Zweck er sich einfach wie ein schrecklicher Job anhört. Wer möchte nur Steine ​​zerbrechen, wenn Sie Kathedralen bauen könnten?

Je mehr ein Entwickler involviert ist und je älter er im Geschäft ist, desto wichtiger wird es, mindestens über mittlere Domänenkenntnisse zu verfügen, oder die differenzierteren Bereiche dieser Branche, die möglicherweise kritisch sind, werden vom Entwicklerteam nicht verstanden.

Eine Spezifikation sollte jedoch für Aufgaben auf niedrigerer Ebene ausreichen. Kurz gesagt, es ist am besten, Ihre Belegschaft auf eine niedrigere Ebene auszubilden. Sie mögen die besten polyglotten Programmierer der Welt sein, aber wenn sie das Problem nicht richtig verstehen können, sind sie immer zum Scheitern oder zum Tod verurteilt.

Es sollte immer einige Spezifikation - Sie alle Entwickler nicht erwarten können, Domain - Experten werden. Wenn die Entwickler einer Spezifikation blind folgen, ohne wirklich zu verstehen, wofür sie gedacht ist, ist das Ergebnis möglicherweise nicht das, was die Kunden wirklich wollen. Es kommt oft vor, dass ein Entwickler, der sogar ein etwas anständiges (aber kein Experten-) Verständnis hat, Fehler und Auslassungen in den Spezifikationen feststellen kann. Sie können auch einen Beitrag leisten und Feedback zum Prozess geben, wodurch das Endprodukt viel besser wird.

Es könnte sich lohnen, einige Domain-Experten einzustellen, deren Aufgabe es ist, sich zwischen den Kunden und Entwicklern auszutauschen, um den Entwicklern ein besseres Verständnis zu vermitteln und die Erstellung der Spezifikation zu unterstützen.

Ich finde es schwer, so oder so eine Antwort zu geben.

Es ist schwer zu verstehen, wie beispielsweise ein freiberuflicher Entwickler das Geschäft (oder die Wissenschaft) hinter jeder einzelnen von ihm entwickelten Anwendung verstehen kann. In dieser Situation ist es meiner Meinung nach wichtiger, dass der Entwickler die richtigen Fragen zur Spezifikation oder zum Geschäftsmodell stellt, als das Geschäft selbst wirklich zu verstehen.

Ein Unternehmensentwickler hingegen hätte nach ein paar Monaten (oder vielleicht Jahren) wirklich lernen müssen, wie das Geschäft funktioniert, vorausgesetzt, er ist schon eine Weile im selben Unternehmen. In einem großen Team haben Sie möglicherweise auch einen Architekten, der das Geschäft besser versteht als die Entwickler.

In KMUs mit Einzelentwicklern ist es wichtig, dass der Entwickler häufige Gespräche mit den Eigentümern / Managern führt, um zu vermeiden, dass etwas schief geht und das Falsche implementiert wird.

Es gibt also viele Möglichkeiten, darüber nachzudenken, aber der Schlüssel ist in allen Fällen der gleiche: Kommunikation .

Softwareentwicklung ist der einzige Beruf, von dem ich weiß, dass Sie nicht nur in Ihrem eigenen Beruf kompetent sind, sondern auch ein grundlegendes Verständnis für den Beruf haben, in dem Sie arbeiten. Es ist wichtig, dass Sie über ausreichende Kenntnisse der Domäne verfügen, um mit Kunden und Mitarbeitern kommunizieren zu können andere Entwickler in der Sprache des Kunden. Als Entwickler können Sie sich nicht immer darauf verlassen, dass andere Sie schulen. Manchmal muss man sich mit persönlichen Nachforschungen beschäftigen, oftmals außerhalb der üblichen Arbeitszeiten.

Ich verstehe wirklich, was Sie hier meinen, weil wir als Unternehmen in einer Tourismusbranche vor dem gleichen Problem standen. Als Juniorentwickler habe ich auch Tourismus an einer Hochschule studiert. Sie können also vermuten, dass ich nicht aus der Informatik komme, aber meine Tourismuskenntnisse sind hoch.

Wir haben damals Produkte in Verbindung mit anderen Softwareunternehmen entwickelt, aber es fehlte an fachspezifischem Wissen. Wie Sie beschrieben haben, ist es wirklich schwierig, es richtig zu machen, wenn Sie ein Produkt in der Tourismusbranche entwickeln, da es viele Querschnittsthemen usw. gibt.

Diese Bewegung hat also auf lange Sicht viele schlechte Ergebnisse gebracht. Dann haben wir einen großen Schritt nach vorne gemacht, und ich habe angefangen, mich nur auf die Entwicklung und nicht auf den geschäftlichen Teil des Projekts zu konzentrieren. Da ich über industrielle Kenntnisse und Programmierkenntnisse verfüge, wächst das Projekt effizienter als je zuvor. Ganz zu schweigen davon, dass wir dann schneller Entscheidungen treffen können, da ich die Erfahrung auf beiden Seiten der Medaille habe.

Als konkrete Antwort auf Ihre Frage ist es meiner persönlichen Meinung nach sicherlich ja. Wenn es sich bei dem Projekt, an dem Ihr Team arbeitet, um ein langfristiges Projekt handelt, gehen Sie den harten Weg und schulen Sie Ihre Mitarbeiter in domänenspezifischen Grundlagen und Details.

Wenn ein Entwickler über einen längeren Zeitraum in einem Unternehmen / einer Branche bleibt, lernt er langsam, aber sicher "das Geschäft".

Einige Unternehmen bestätigen und bieten Schulungen in "the business" an. Finanzunternehmen sind ein gutes Beispiel dafür.

Je mehr Sie über das Geschäft lernen, desto einfacher wird es, mit Ihren Benutzern zu sprechen. Sie werden mehr Vertrauen in dich haben. Sie werden leichter verstehen, wo ein System schief gehen könnte, wenn es nicht so funktioniert, wie es vom Benutzer erwartet wird.

Um Ihre Frage zu beantworten, ist die Spezifikation meiner Erfahrung nach NIE ausreichend. Das häufigste Problem ist, dass sie häufig nicht genügend Informationen enthalten und schnell veraltet sind.

Für einige Unternehmen kann die Kenntnis des Geschäftsbereichs obligatorisch sein. Sie suchen Entwickler mit Erfahrung in der Domäne bei der Einstellung. Einige Unternehmen setzen dies sogar höher als die tatsächlichen technischen Fähigkeiten. (Keine finanziellen Erfahrungen, kein Interview ist sehr verbreitet, sicherlich hier in Großbritannien).

Aus persönlicher Erfahrung ist die Spezifikation ausreichend, solange Sie jemanden im Team haben, der mit Ihnen zusammenarbeitet und über Domänenkenntnisse verfügt.

Ich arbeite in einer sehr spezialisierten Branche: Wir machen Software für Rundfunkmedien. Ich weiß kaum etwas über Rundfunk, aber ich kenne Code und Daten, und ich habe gute Leute im Projektmanagement, die sich mit Rundfunk auskennen. Diese Formel war in den letzten Jahren gut genug für mich, um eine gute Funktionalität zu entwickeln, die den Kunden gefällt.