Wie Sie Domänenexperten dazu bringen, Fragen richtig, vollständig und prägnant zu beantworten

Du stellst keine offenen Fragen. Sie stellen prägnante, gezielte Fragen nach spezifischen relevanten Informationen zu einer Aufgabe oder einem Projekt, das ihnen wichtig ist oder an dem sie beteiligt sind.

Die Leute sind nicht da, um dich zu unterrichten.

Helfen Sie ihnen (indem Sie die Frage beantworten), Ihnen zu helfen.

Erwarten Sie nicht, ich wiederhole, nicht, dass die Leute glücklich sind (oder darauf warten), Ihnen zu helfen (selbst wenn sie es sagen). Jeder hat seine eigenen Verantwortlichkeiten, um die er sich kümmern muss, und Ihnen zu helfen steht möglicherweise nicht auf seiner Prioritätenliste (in den meisten Fällen).

Wenn Sie Fragen stellen, die durch ein Tutorial / Googeln beantwortet werden sollten oder eine Brainstorming-Sitzung benötigen, ist es sehr wahrscheinlich, dass Ihre Frage ignoriert / unbeantwortet bleibt. Stellen Sie objektive, direkte und relevante Fragen und fügen Sie alle relevanten Informationen in die Frage selbst ein. Senden Sie bei der schriftlichen Kommunikation auch nicht eine E-Mail an mehrere Empfänger, sondern halten Sie sie sehr zielgerichtet – höchstens ein oder zwei. Wenn Sie ein Problem haben, das von mehreren Personen beantwortet werden muss, teilen Sie es in einzelne Fragen auf und richten Sie jede einzelne an die entsprechende Person.

Einige schnelle Tipps, um eine bessere Frage zu stellen und die Chance zu erhöhen, eine Antwort zu erhalten:

• Frag nicht

„Wie mache ich das“ ?

Zeigen Sie Ihre Bemühungen bis zur Zeit. Sagen:

„Ich habe versucht, X zu machen, also habe ich P und Q bewertet, und hier ist die Liste der Vor- und Nachteile. Meiner Meinung nach/Analyse wird uns P besser helfen, sehen Sie dasselbe? Irgendeine bessere Alternative, die ich übersehen habe ?"

• Frag nicht

"Das funktioniert nicht, wie soll es funktionieren?" .

Fragen:

"Ich habe versucht, es zum Laufen zu bringen, indem ich P konfiguriert, Q eingerichtet und R durchlaufen habe, aber am Ende zeigte es einen Fehler mit der Aufschrift "hubaa dubba do!". Schnelles Googeln zeigt, dass ich G und H importieren muss, um das Problem zu lösen, versucht aber die Nachricht änderte sich in „Ho Ho Ho!". Im Anhang sind Beispielkonfigurationen, die ich verwendet habe, und die Umgebungsdetails für den Betrieb. Alle schnellen Gedanken sind willkommen, und wenn Sie der Meinung sind, dass eine Debugging-Sitzung erforderlich wäre, lassen Sie es mich wissen, ich werde es tun einen einrichten"

Fazit: Je mehr Sie es ihnen leicht machen, zu antworten, desto wahrscheinlicher erhalten Sie eine Antwort. Speichern Sie die offenen Fragen für eine Trainings-/Lernsitzung.

Last but not least, hier ist eine nette Referenz , wie man gute Fragen stellt. Ich zitiere den Autor

„Der Einfachheit halber – und da Stack Overflow so beliebt ist – gehe ich davon aus, dass die Frage auf Stack Overflow oder einer ähnlichen Stack Exchange-Site gestellt wird. Die meisten Posts hängen nicht wirklich davon ab, aber wenn Sie woanders fragen, müssen Sie den Rat vielleicht ein wenig anpassen."

Das wird meiner Meinung nach unbeliebt sein....

Für Software bei meiner Arbeit stellen wir FIRST für Fachwissen ein, es ist einfacher, C und Assembly (ja, und die Grundlagen von Small-Core-Embedded-Entwicklung) zu lehren, als Live-TV-Workflow und die knorrigen Probleme zu lehren, die Ops-Leute haben mal damit umgehen.

Ein OK-Programmierer, der versteht, wie die Domäne funktioniert, ist unserer Erfahrung nach VIEL nützlicher als ein brillanter Programmierer, der nur einer Spezifikation folgen kann und nicht weiß, welche Bits wahrscheinlich zerrissen werden (Und wer erkennt in der Spezifikation keinen Dummheit, da ist im Allgemeinen etwas).

Ähnliches gilt für die Entwicklung von Geschäftsprozessen und den Umgang mit Dingen wie CRM-Systemen. Machen Sie sich zuerst mit dem Geschäft vertraut, wenn Sie den Stapelüberlauf überfallen müssen, um es zu codieren, ist das weniger ein Problem, als nicht auf einer ziemlich tiefen Ebene zu verstehen, was das Ding tatsächlich erreichen muss.

Unser Produktmanager ist ein Fachexperte, aber wissen Sie was? Einige Mitglieder unseres Entwicklungsteams auch (Und das Thema ist NICHT Softwareentwicklung).

Dies hat einen ziemlich netten Vorteil, die Experten sprechen die gleiche Sprache und obwohl sie anderer Meinung sein mögen, erhält dieser Kampf normalerweise eine Lösung, die BESSER ist als das, was einer von beiden ursprünglich hatte.

Der Experte des Entwicklerteams verbreitet Wissen an den Rest des Teams und stoppt viele dumme Fragen, sodass der externe Typ nur nach Dingen gefragt wird, auf die es keine klare Antwort gibt, und er wird in seiner Sprache gefragt . Der Typ im Entwicklungsteam ist auch stark in Architektur involviert, da ein KMU normalerweise zumindest eine Vorstellung davon hat, wohin ein bestimmtes Produkt führen könnte.

Selbst für einen 'Code-Affen' ist Kontextverständnis viel wichtiger als technische Fähigkeiten, sonst wähle ich eine höhere Sprache und lasse den Compiler meinen Code für mich affen (billiger, weniger Bugs und keine Rente zu zahlen)!

Wenn Ihr einziges KMU weit oben im Unternehmen steht, haben Sie ein Problem, weil ihre Zeit verschwendet wird, das KMU verärgert ist und die Leute nach Vorgaben arbeiten, die sie NICHT verstehen, was dahinter steckt, führt dies nicht zu guten oder sogar sehr nützlichen Ergebnissen.

Stellen Sie jemanden in das Entwicklerteam ein, der die Sprache der jeweiligen Domäne spricht und sich ein wenig mit Softwareentwicklung auskennt, es lohnt sich.

Wenn ich in meinem derzeitigen Job als Softwareentwickler mit Fachexperten zusammenarbeite, bereite ich in der Regel Ja/Nein-Fragen vor, die ich zu stellen beabsichtige, indem ich den Kontext dafür angebe, warum ich mir eine Frage stelle, z fragen, ob mein Verständnis richtig ist oder welches meiner beiden Szenarien das richtige ist.

Wenn ich Klärungen für eine Anforderung benötige, bevorzuge ich wahrscheinlich ein Gespräch im Chat, per Telefon oder persönlich, damit ich Feedback dazu geben kann, ob die Klarstellung den Punkt trifft oder nicht, und wenn nicht, klären Sie selbst, was ich gefragt oder gefragt habe weitere Fragen.

Wenn Sie Schulungen benötigen, um Domänenexperten zu verstehen, ist das ein ganz anderes Problem. Wissen sollte in Ihr Unternehmen fließen, damit Sie verstehen, was Ihr Arbeitsgebiet ist, und das ist meist Aufgabe Ihrer Geschäftsführung, dass Sie aktuelles Wissen über Abkürzungen, Akronyme etc. haben und ich würde sogar sagen idealerweise sogar aufnehmen einige der Domänenkenntnisse, damit Sie direkt verstehen, wenn Ihnen eine Spezifikation präsentiert wird.

Es ist verlockend zu glauben, dass eine offenere Frage den Fachgebietsexperten mehr Raum geben würde, um direkt auf ihre Anforderung einzugehen, aber normalerweise führt dies nur dazu, dass sie Zeit damit verschwenden, das zu erklären, was Sie bereits wissen, ohne zu klären, umformulieren oder sogar den Punkt völlig verfehlen.

Ich würde sowieso offene Formulierungen über "Gedanken" oder "Eingaben" zu einem vagen Thema vermeiden, da sie unbefriedigend sind, da Sie bestimmte Informationen benötigen, um einen funktionierenden Code zu schreiben.

Offene Fragen eignen sich hervorragend für Vorstellungsgespräche. Sie sind nicht das richtige Werkzeug, um Anforderungen zu erheben.

Wenn Sie fragen: „Was denken Sie über X?“, ist das beste Szenario, dass der Experte denkt: „Oh, wow, ich mache X seit 20 Jahren und diese Person fragt nach meinen Gedanken? Wo fange ich an? ". Im schlimmsten Fall gehen sie entweder davon aus, dass Sie fast so viel wissen wie sie, oder dass Sie möglicherweise nicht genug lernen können, um das Nötige zu tun.

Bitten Sie stattdessen um Bestätigung. "Ich denke, X funktioniert wie Y, ist das richtig?". Oder "Zeig mir, wie du Z machst". Dies wird unweigerlich Lücken hinterlassen, da es Dinge gibt, von denen Sie nicht wissen, dass Sie sie fragen müssen. Aus diesem Grund müssen Sie die erste Iteration der Software so schnell wie möglich in die Hände bekommen (auch in Prototypform) und schnell auf die nächste Iteration hinarbeiten, die auf das Feedback der ersten reagiert. Bereiten Sie Ihre Experten darauf vor, dies zu erwarten.

Ich habe festgestellt, dass der einfachste Weg, nützliche Informationen von Domänenexperten zu erhalten, darin besteht, die Software zu entwickeln, die das tut, was Sie für richtig halten, und dann zu sehen, was sie davon halten. Um deine Beispiele zu nehmen:

Anstatt das zu sagen:

Sie haben erwähnt, dass Sie möchten, dass die PGA-Rezeptoren in einer Liste angezeigt werden - jeder PGA enthält viele Daten, also denke ich an die Anzeige. Sieht das für dich ok aus?

mach das:

Da Sie letzte Woche gesagt haben, dass Sie möchten, dass die PGA-Rezeptoren in einer Liste angezeigt werden, hier ist ein Modell dessen, woran ich arbeite. [Screenshot einfügen] Die Idee ist, dass es Ihnen das Mondo Bongo der PGA in der Liste zeigt, aber Sie können auf das kleine Symbol klicken, um mehr Details zu öffnen. Das wird ab nächster Woche fertig sein, wenn Steve die Figuren von Scooby Doo hochlädt.

Das bedeutet, dass sie, wenn es tatsächlich Probleme gibt, etwas Konkretes haben, auf dem sie aufbauen können: „Oh hey, das ist in Ordnung, aber können Sie sicherstellen, dass die PGA irgendwie hervorgehoben wird, wenn der Rauchfaktor größer als 74 % ist? Außerdem sollten wir das sehen R-Wert auch in der Liste und wir müssen in der Lage sein zu filtern, wo R < 4 oder R > 4 ist."

Ich habe Software übergeben und gesagt, dass es sich um eine Testversion handelt, eine experimentelle Sache, also traue ihrem Ergebnis nicht. Und dann wurden die Benutzer eingeladen, es auszuprobieren. Wenn sie dies tun, kann ihr erfahrenes Auge oft sehen, wo etwas ein bisschen daneben aussieht, und in der Lage sein, das Problem zu diagnostizieren. Und sagen Sie: Es tut nicht das Richtige, wenn X gilt, weil dies dann passiert und wir den Blegbod berücksichtigen müssen.

Verwenden Sie also keine E-Mails und Konversationen, um über Softwareanforderungen zu kommunizieren. Verwenden Sie dazu die Software. Verwenden Sie Dinge wie Demonstrationen, UAT-Skripte, Mockups usw. Auf diese Weise können Sie viel einfacher sagen: "Ist das das, was Sie meinen?". Auch für KMU ist es so viel einfacher zu sagen „das stimmt“ oder „nein das ist falsch, weil X“.

Endbenutzer können mit Ihnen nützliche Informationen über „richtig und falsch“ hinaus teilen. Sie sind möglicherweise nicht in der Lage, ihre Probleme zu sehen und sagen: „Sehen Sie, es dauert sieben Klicks, um zu dem Bildschirm zu gelangen, den ich am häufigsten verwende, und dann muss ich dieselben Informationen erneut eingeben und dann warten, bis sie geladen ist. während der Kunde am Telefon ungeduldig wird". Aber wenn Sie die Gelegenheit haben, mit ihnen zusammenzusitzen und sie zu beschatten, wird Ihnen so etwas klar sein. Wenn dies nicht möglich ist, sollten Sie darüber nachdenken, so etwas wie User Stories und Process Maps zu verwenden.

• Wenn Sie eine User Story hätten, könnte diese etwa so lauten: „Als PGA-Klempner muss ich die Rezeptoren getrennt für niedrige und hohe R-Werte auflisten, damit ich auf einen Blick sehen kann, wo der Rauchfaktor den gesetzlichen Schwellenwert überschreitet.“ . Dann hättest du vorher gewusst, was du umsetzen musst, weil du wüsstest, warum du es machst.

• Wenn Sie eine Prozesskarte hätten, wäre klar, was der PGA-Klempner zu erreichen versucht und wie er dazu befähigt werden kann.

Ein guter Ausgangspunkt ist zu verstehen, dass Ihre „Experten“ in erster Linie aufgrund ihrer Kompetenz bei der Durchführung ihrer eigenen Aufgaben ausgewählt werden, nicht bei der Erklärung oder expliziten Übermittlung des Inhalts dieser Aufgaben an andere.

Menschen (die vielleicht als „Studenten“ bezeichnet werden, und so werde ich Ihre Rolle hier charakterisieren), die die Bildung, Ausbildung oder stillschweigende Erfahrung, die die Experten haben, nicht weitgehend teilen, werden natürlich dazu neigen, explizite Kommunikation zu schätzen von den Experten darüber, was ihre Arbeit in allen Belangen beinhaltet. Aber solch explizites Verständnis und Kommunikationsfähigkeiten als Experte zu besitzen , um dieses Fachwissen zu reproduzieren, ist die Domäne des professionellen Pädagogen.

Diese „Experten“ von Ihnen sind keine Erzieher von Beruf und werden normalerweise keine Akademiker oder Intellektuellen von Natur aus sein, daher sollten sie nicht a priori als Personen behandelt werden, denen nur Fragen gestellt werden können und von denen eine gute zusammenhängende Antwort erwartet werden kann.

Die übliche Art und Weise, wie Wirtschaftsexperten aus Laien reproduziert werden, besteht erstens darin, die Laien zu Studenten von Berufspädagogen zu machen (dh sie in einen formalen Studiengang zu bringen), zweitens, indem die Laien neben erfahrene Experten gestellt werden, wo dies der Fall ist Informationen werden langsam durch Osmose übertragen (normalerweise über Jahre) und drittens, indem man Laien einfach erlaubt, eine Expertenarbeit zu verrichten, bis sie es selbst herausfinden (was möglicherweise zulässt, dass Fehler auf dem Weg gemacht werden, wiederum normalerweise über Jahre).

Was Sie tun, ist, dass Sie von Ihren Geschäftsexperten erwarten, dass sie die Rolle eines professionellen Ausbilders übernehmen, um der Rolle zu entsprechen, die Sie als Student angenommen haben.

Aber Sie versetzen die Wirtschaftsexperten implizit in diesen dritten Lernmodus, in dem sie (jetzt als Nicht-Experten selbst) lernen müssen, wie man professionelle Pädagogen ist, indem sie es so gut wie möglich für sich selbst durchwursteln. In der Regel geschieht dies, ohne sie von ihrer täglichen Arbeit zu entbinden.

Wenn Sie feststellen, dass dieser Ansatz wehtut, dann wissen Sie, dass der Arzt sagen wird: „Tu es dann nicht“. Ihre anderen Alternativen, um sich Kenntnisse über diese Rollen anzueignen, könnten ein formales Studium bei einem echten Pädagogen umfassen, oder Ihr Arbeitgeber könnte Sie dazu bringen, diese Arbeit eine Weile zu erledigen, um Erfahrungen damit zu sammeln (was Ihnen zumindest helfen kann). ein gemeinsames Vokabular und ein gemeinsamer gesunder Menschenverstand mit den Experten, deren Köpfe Sie zu knacken versuchen).

Wenn Sie mit Ihrer bisherigen Methode fortfahren, einfach Fragen aus der Ferne zu stellen, müssen Sie einfach akzeptieren, dass dies von Natur aus oft etwas willkürlich und frustrierend ist, da die Rolle, in die Sie den Experten besetzen, nicht zusammenpasst - die Rolle des Erziehers - und ihrer tatsächlichen geschäftlichen Rolle, die normalerweise nichts dergleichen ist.

Das habe ich festgestellt, als ich unterbreche und um Klärung bitte

Vermeiden Sie Unterbrechungen. Es ist normalerweise unhöflich und sie reden nur "zu viel", weil Sie die falsche Frage gestellt haben. Stellen Sie bessere Fragen.

Sie sollten dem KMU niemals offene Fragen stellen, es sei denn, Sie knüpfen Kontakte. In der Regel gibt es Experten auf unterschiedlichen Ebenen zu einem Thema, die von Personen in Ihrer eigenen Abteilung über Personen in anderen Abteilungen/externen Unternehmen bis hin zum Top-Level-Experten reichen, mit dem Sie es zu tun haben. Vermeiden Sie es, dem Top-Level-Experten viele Fragen zu stellen. Lassen Sie zuerst so viele Fragen von den Leuten der unteren Ebene beantworten, bevor Sie die Fragen, die sonst niemand beantworten kann, an die Person der obersten Ebene weiterleiten. Nehmen Sie auch niemandes Zeit als selbstverständlich hin. Manchmal sind sie so beschäftigt, dass sie dich nur alle paar Wochen einmal treffen können. Gehen Sie niemals davon aus, dass Sie die Freiheit haben, eine weitere Stunde ihrer Zeit in Anspruch zu nehmen. Aber sie werden umso empfänglicher sein, je respektvoller Sie ihrer Zeit gegenüber sind, wenn Sie mit ihnen umgehen.

Denken Sie daran: Sie sind Domänenexperten, und Sie (!) sind ein Experte für die Software, die Sie entwerfen oder erstellen. (Die möglicherweise darauf ausgelegt ist, Benutzern in diesem Fachgebiet [das Sie auch nicht haben] zu dienen.)

Außerdem – „der ganze Grund dafür, selbstverständlich von beiden Seiten gleichermaßen geteilt“, sei ganz konkret zielführend. Ihr gemeinsames(!) Ziel ist die „zeitgerechte Erstellung einer exzellenten Software“. Allerdings sind nur Sie (sagen wir ...) der "Domänenexperte" für die spezifische Aufgabe der Softwareerstellung.

"Und so, hier seid ihr beide."

Formulieren Sie die meisten Fragen so spezifisch wie möglich in Bezug darauf, was Ihre Software tun und/oder bereitstellen muss. Bereiten Sie vielleicht einige Anwendungsfall-Szenarien („User Stories“, wie sie heutzutage oft genannt werden) für Kommentare und Beiträge vor.

Ich war auf beiden Seiten dieser besonderen Situation, und hier sind ein paar Dinge, die ich gelernt habe.

Meine grundlegende Faustregel ist, dass spezifische Fragen spezifische Antworten erhalten und offene, allgemeine Fragen offene, allgemeine Antworten erhalten . Das Problem bei offenen Fragen ist, dass es nicht offensichtlich ist, wann Sie tatsächlich die gesamte Frage beantwortet haben. Es gibt immer mehr, was man könntezu dem Thema sagen, aber irgendwann hat man das Gefühl, es reicht und man hört auf zu schreiben. Dies ist in einem persönlichen Gespräch nicht wirklich ein Problem, da Sie Folgefragen stellen können, um weitere Informationen zu erhalten. Asynchrone Kommunikation wie E-Mail erschwert dies erheblich. Wenn Sie allgemeine, offene Fragen stellen müssen, ist es besser, dies persönlich oder am Telefon zu tun. Abschweifende Antworten sind normalerweise ein Zeichen dafür, dass die Frage von Anfang an nicht sehr spezifisch war. Das Stack Exchange-Netzwerk ist eigentlich ein anständiges Beispiel dafür. Denken Sie an die Art von spezifischen, fokussierten Fragen, die schnell qualitativ hochwertige Antworten hervorrufen, im Vergleich zu der Art von Fragen, die als „zu weit gefasst“ oder „unsicher, was Sie fragen“ geschlossen werden.

Jargon, branchenspezifische Abkürzungen und interne Codenamen sind immer ein Problem. Ihr KMU arbeitet fast ausschließlich mit einer Gruppe von Menschen zusammen, die über eine gemeinsame Wissensbasis verfügen, die Sie nicht haben. Ihr KMU ist sich möglicherweise auch gar nicht bewusst, dass Ihnen diese Begriffe und Konzepte fremd sind oder dass ein Begriff in anderen Kontexten etwas ganz anderes bedeuten könnte. Normalerweise antworte ich mit einer Nachricht wie „Ich bin ein bisschen neu in Ihrem Team/Unternehmen/Ihrer Branche und bin mit einigen dieser Begriffe nicht vertraut. Können Sie definieren, was der Begriff ‚BFG‘ in diesem Zusammenhang bedeutet?“ Dies ist eine spezifische Frage, die in ein oder zwei kurzen Sätzen beantwortet werden sollte. Es macht den Leser auch darauf aufmerksam, dass Sie möglicherweise nicht den gesamten Jargon verstehen und dass er mit zukünftigen Nachrichten etwas vorsichtiger sein sollte.

Denken Sie auch daran, dass dieser gesamte Prozess symmetrisch ist. Sie sind beide KMU mit umfangreichen Kenntnissen in Ihrem eigenen Interessensgebiet und nur einer flüchtigen Vertrautheit mit dem Fachgebiet der anderen Seite. Wenn Sie Fragen zu Implementierungsdetails stellen (wie Ihr Beispiel „Hier sind einige Möglichkeiten, wie ich darüber nachgedacht habe, es zu lösen“), wird die andere Person Ihre Frage wahrscheinlich genauso verwirrend und schwer verständlich finden, wie Sie ihre Antwort finden. Menschen, die keine Programmierer sind, antworten in der Regel am besten, wenn Sie Ihre Frage in Form einer Skizze oder eines GUI-Modells stellen (wie in "welche dieser beiden Schnittstellen sieht einfacher zu bedienen aus"). Wenn Sie anfangen, zu weit unterhalb der GUI-Ebenen über Dinge zu sprechen, neigen Nicht-Programmierer dazu, Sie entweder nicht vollständig zu verstehen oder sich nicht darum zu kümmern. Wenn ein Aspekt Ihrer Interna wirklich SME-Input benötigt, um richtig zu funktionieren, versuchen Sie, die Frage so zu formulieren, dass alles, was mit Software zu tun hat, entweder minimiert oder eliminiert wird. Versuchen Sie nicht, sie dazu zu bringen, „über das Problem und/oder die Lösung nachzudenken“; sie haben das schon einmal gemacht, und ihre Lösung war, Sie einzustellen. Sie wollen so viel Denken wie möglich auslagern.

Das Beispiel, das Sie bereitgestellt haben, gefällt mir sehr gut, und ich denke, es "beantwortet" die Frage. Es ist nicht das, was Sie erwartet haben, aber sie kennen die "richtige und prägnante Antwort" selbst nicht. Vielleicht habe ich bei Gelegenheit etwas Ähnliches wie Ihre Experten getan.

Sie haben erwähnt, dass Sie möchten, dass die PGA-Rezeptoren in einer Liste angezeigt werden - jeder PGA enthält viele Daten, also denke ich an die Anzeige. Sieht das für dich ok aus?

Sie fragen nach einer Schnittstellensteuerung. Dies kann wie eine einfache, abgegrenzte Frage aussehen. In der Tat, wenn sie ein klares Design im Kopf haben, wie die Software funktionieren soll, kann es so sein. Jedoch...

Wir wollen eine Möglichkeit, die eingehenden PGA-Rezeptoren in Echtzeit zu zeigen.

Sie brauchen keine "Liste". Ihr eigentliches Erfordernis ist, irgendwie die PGA-Rezeptoren in Echtzeit anzuzeigen.

Wir wissen derzeit nicht, woher sie kommen, also wäre es schön, wenn wir eine Liste mit jeder ihrer Nummern und Informationen haben könnten.

Obwohl eine Art Liste wahrscheinlich gerechtfertigt ist.

Dann kommt der QXT2 herein und knirscht diese Zahlen

Hier erwähnen sie ihren Fluss

Können wir dafür einen Bildschirm haben?

was eine weitere Voraussetzung hinzufügt. Es ist jedoch wichtig zu berücksichtigen, dass es einen sekundären Bildschirm aus dieser Liste geben sollte.

Im Moment dauert es lange, alle P-Werte für die Daten einzugeben, aber ich bin mir nicht sicher, wie ich das am besten mache.

Das aktuelle System wurde vor langer Zeit erstellt und wir haben seitdem viele verschiedene Arten von LFG hinzugefügt, jede mit ihrem eigenen Bongo-System, das in eine separate Tabelle eingegeben und geladen werden muss, bevor die App ausgeführt wird.

Historische Daten.

Ich denke, die Liste der PGAs sollte auf dem Hauptbildschirm angezeigt werden und so viele Elemente enthalten, wie aus der Datei geladen wurden.

Eine Idee, die klug sein kann oder nicht.

Dies ist vielleicht nicht der beste Weg, es zu tun, aber es wird vorerst funktionieren. Beachten Sie nur, dass das Bongo-System für die PGAs im .xml-Format vorliegen muss, daher weiß ich nicht, wie viele Informationen Sie für jedes einzelne anzeigen möchten.

Einige hilfreiche Ratschläge mischten sich ein.

Wir brauchen jeden, um die T-Werte über die Zeit zu berechnen.

Plus eine Erklärung der Daten, die Sie von den Bongos verarbeiten müssen

Ich finde du hast es eigentlich ganz gut erklärt:

Es hat die Frage irgendwie beantwortet, aber es hat auch viele andere Fragen aufgeworfen, die relevant sein können oder nicht

Sie haben ein Designproblem. Wenn dies eine Wasserfallentwicklung war. Ein Design würde früh entworfen und dann in Stein gemeißelt. "Hier gibt es einen Bildschirm 2.6.4 mit einer Listenansicht voller PGAs und drei Schaltflächen."

Ich denke, Sie arbeiten mit einer Reihe unvollständiger Anforderungen. Ich bin mir nicht sicher, was Ihre genaue Rolle in diesem Projekt ist, wer dafür verantwortlich wäre, alle Erfordernisse zu sammeln und zu formalisieren. Wenn es jemand anderes ist, müssen Sie das möglicherweise an ihn weitergeben, damit er (mit Hilfe Ihres Teams?) herausfindet, was zu tun ist.

Die Expertenantwort wirft eine Reihe von Fragen auf (sofern diese nicht bereits bekannt waren). Bevor eine Codezeile eingegeben wird, sollte ein Design vorhanden sein . Dies kann ein hübsches grafisches Designprogramm, Bleistift und Papier verwenden oder sogar vollständig in Ihrem Kopf sein, aber es ist notwendig zu verstehen, was benötigt wird und (grob) wie das geht. Es ist möglich, dass sich unter all diesen Worten einige Dinge von selbst regeln, andere die Hilfe des Entwicklungsteams oder der Experten erfordern. Ich würde mich wahrscheinlich mit dem Domänenexperten treffen, um diesen Bildschirm und seine Gestaltung zu überprüfen. Nicht selten kommt es auch vor, dass das Entwicklungsteam aus den dort eingegangenen Inputs einen Vorschlag erstellt, der dann zurückgeht...

Kurz gesagt, bei diesem gefälschten Beispiel haben Sie sich auf einen sehr spezifischen Teil konzentriert, während es viele wichtige Teile um ihn herum gibt, die schlecht definiert sind und die zuerst fokussiert werden müssen.

(Beachten Sie, dass Sie schließlich in der Lage sein sollten, auf eine solche E-Mail zu antworten und zu erklären, wie PGA, Bongos und LFG auf diesen Bildschirm passen.)

Hier gibt es viele großartige Antworten, daher mache ich diese Kurzfassung, um etwas hinzuzufügen, das noch nicht behandelt wurde. Es ist eine Strategie, die ich im Allgemeinen als letzten Ausweg verwende, wenn andere Methoden versagen.

Bereiten Sie etwas vor, von dem Sie wissen, dass es falsch ist. Vorzugsweise auf offensichtliche Weise falsch, spezifisch für das, worüber Sie fragen möchten. Dann lass das überprüfen. Höchstwahrscheinlich erhalten Sie eine konkrete Kritik, die Ihnen weiterhilft.

Probieren Sie auch hier zuerst andere Methoden aus. Aber ich habe festgestellt, dass einige Experten und verschrobene Lead-Typen auf diesen Ansatz viel hilfreicher reagieren als auf jeden anderen, und er kann ein Einstieg in eine konstruktivere Beziehung sein. Ja, vielleicht musst du dich für eine Weile mit dem Gefühl auseinandersetzen, dass du wie ein Idiot rüberkommst, aber ziemlich bald wirst du ihr Wissen haben und sie werden sich zurückziehen oder anderweitig weitermachen, und dann wirst du selbst wissen, was Es ist, als würde man diese Art von Fragen stellen.

Kurze Antwort: Wenn Sie herausfinden können, wie das geht, lassen Sie es uns bitte alle wissen, denn Softwareentwickler haben seit den frühesten Tagen des Berufs damit zu kämpfen.

Aber das heißt, einige hilfreiche Hinweise, die ich vielleicht weitergeben kann:

Die meisten Fachexperten, mit denen ich zusammengearbeitet habe, LIEBEN die Gelegenheit, ihre Arbeit zu erklären. Du triffst einige, die die Einstellung einnehmen: "Das sollte jeder wissen. Wenn du es nicht weißt, musst du eine Art sabbernder Idiot sein." Aber die meisten halten sich selbst für Genies, weil sie dieses schwierige Gebiet gemeistert haben, das sonst niemand versteht, und sie sind glücklich, all die Weisheit, die sie durch jahrelange Erfahrung gewonnen haben, jedem zu erklären, der ihnen zuhört.

Und wenn Sie gerade in eine neue Domain einsteigen, kann dies großartig für Sie sein. Sie können Leute finden, die Ihnen ausführlich alles über die Domain erklären.

Aber – und hier ist das große „aber“ – sie wissen wahrscheinlich nichts über Softwareentwicklung. Sie wissen nicht das Geringste darüber, wie Computer tatsächlich funktionieren. Daher ist der Versuch, ihr Wissen in Softwareanforderungen umzusetzen, ein schwieriger Prozess.

Ein Beispiel, das ich immer wieder sehe: Ich sage dem KMU: "Okay, Sie haben erklärt, was in den Fällen X und Y zu tun ist. Was soll der Computer in Fall Z tun."

Und er wird sagen: "Oh, mach dir darüber keine Sorgen, das passiert fast nie."

Und ich sage: "Wenn es FAST nie passiert, bedeutet das dann, dass es manchmal passiert?"

Und er sagt: "Oh, sicher, gelegentlich. Aber wenn es passiert, tun Sie einfach etwas Vernünftiges."

Diese Art von Anweisungen funktionieren gut, wenn Sie mit Menschen zu tun haben. Natürlich könnten Sie einer einigermaßen intelligenten Person sagen: „Wenn das Teil falsch geschnitten aus der Maschine kommt, legen Sie es in den Ausschussbehälter. Wenn es Brandspuren aufweist, reinigen Sie sie mit dieser Chemikalie. Alle anderen Probleme, tun Sie es was du kannst, um sie zu reparieren." Und das wäre für einen Menschen in Ordnung. Aber wie Sie sicher wissen, wenn Sie ein Softwareentwickler sind, können Sie einem Computer nicht einfach sagen, „tue etwas Vernünftiges“ oder „tue, was du kannst, um es zu reparieren“. Sie müssen konkrete Anweisungen geben.

Ich habe viele Gespräche geführt, in denen sich die KMU deutlich über mich geärgert haben, weil ich sie immer wieder nach detaillierten Anweisungen dazu drängte, was der Computer in seltsamen Fällen tun sollte, obwohl sie mir BEREITS GESAGT hatten, dass diese Situationen selten vorkommen und der Computer nur was tun sollte es kann richtig damit umgehen.

Fragen Sie in ähnlicher Weise einen Automechaniker, wie er vorgeht, um ein Problem mit einem Auto zu diagnostizieren. Sehr wenige werden sagen, dass sie Test 1 durchführen und dann, abhängig von den Ergebnissen, entweder Test 2 oder Test 3 usw. durchführen. Stattdessen sagen sie so etwas wie: „Ich öffne die Motorhaube und suche nach etwas, das es nicht ist Rechts." Und ja, für einen Menschen, wenn Sie die Motorhaube öffnen und Dampf aus einem undichten Schlauch strömen sehen, sagen Sie nicht: "Okay, Test Nr. 1, prüfen Sie, ob Zylinder 1 einen Funken bekommt. " Sie kommen direkt zum offensichtlichen Problem. Aber natürlich funktioniert ein Computer nicht so.

Mein Punkt ist also, dass die Aufgabe des Entwicklers oft darin besteht, die vagen „Nutzen Sie Ihre Intelligenz“-Aussagen der KMUs in konkrete Schritte umzusetzen. Bis zu einem gewissen Grad versuche ich das den KMU zu erklären, und manchmal verstehen sie es und manchmal nicht. Aber normalerweise verbringe ich die meiste Zeit damit, ihre unscharfen Konzepte festzunageln. Zum Beispiel: „Du sagst: ‚Sehen Sie, was falsch ist‘. Okay. Können Sie mir sagen, was falsch sein könnte? Nennen Sie mir einige Beispiele. Woher wissen Sie, dass es A und nicht B ist?“ Usw.

Sobald Sie anfangen, sie festzunageln, finden Sie oft Lücken. Wie ich mich erinnere, als ich einmal die Anforderungen durchgegangen bin und festgestellt habe, dass sie gesagt haben, was für lokale Expresssendungen zu tun ist; für Standardsendungen (keine Expresssendungen) über große Entfernungen; und für lange Strecken Expresssendungen. Aber sie hatten nie gesagt, was sie für lokale Standardsendungen tun sollten – was meiner Meinung nach wahrscheinlich die größte Gruppe sein würde. Anscheinend haben die KMU den Normalfall einfach übersprungen und sind gleich zu den Sonderfällen übergegangen. Es ist Ihre Aufgabe als Entwickler, herauszufinden, wo die Lücken sind, und Fragen zu stellen, um sie zu füllen.

Wie jemand anderes erwähnte, ist es normalerweise produktiver, einen Lösungsvorschlag zusammenzustellen und die KMUs zu bitten, die Fehler zu identifizieren, als einfach offene Fragen zu stellen: "Wie löse ich das?" Denn wenn sie wüssten, wie man es auf dem Computer umsetzt, bräuchten sie dich nicht. Wenn Sie ihnen etwas Konkretes geben, können sie sagen: "Oh, warte, das funktioniert nicht richtig, wenn die fwacbar nicht aktiv ist" oder was auch immer. Wenn Sie nur eine offene Frage stellen, werden sie wahrscheinlich überall herumwandern.

Formulieren Sie eine Liste mit schriftlichen, kurzen und prägnanten Fragen

Ich beschäftige mich mit Anforderungen von Personen, die im Allgemeinen nicht einmal Domänenexperten sind, und oft ist es so, dass der Kunde nicht weiß, was er will . Selbst bei Experten kann es zu Missverständnissen und Verwirrung kommen, daher sollten die Fragen prägnant und so eng wie möglich gehalten werden.

Zum Beispiel:

Ich habe gesehen, dass X A tut, aber die Anforderungen besagen, dass X B tun muss. Ziehen Sie es vor, wenn es A oder B tut?

Mir ist aufgefallen, dass C einen Fehler aufweist, ich kann es mit U oder J beheben. Ich bevorzuge U, aber ich frage mich, was Sie denken könnten.

Wenn Sie eine Antwort von „Ich weiß nicht“ oder einen Ausdruck von Verwirrung erhalten, können Sie dies so interpretieren, dass sie es nicht wissen. Sie können versuchen, jemand anderen zu finden, oder sich nach bestem Wissen und Gewissen Notizen darüber machen, warum Sie sich für diese Vorgehensweise entschieden haben.

Experten haben große Schwierigkeiten, ihr Wissen in ein computerisiertes Softwareformat zu übersetzen, daher ist es ihnen oft nicht möglich, softwarebezogene Fragen direkt zu beantworten, es sei denn, Sie reduzieren es.

Geschlossene Fragen übersetzen sich oft besser in die binäre Auswahl, die Computer treffen. Open-ended sind nützlicher, um sich einen Überblick zu verschaffen.

Wenn sie es immer noch nicht verstehen, müssen Sie es vielleicht tun

Verwenden Sie Analogien

Im Umgang mit Leuten, die nicht technisch versiert sind, versuche ich daher oft, die Abfrage zu einer Analogie zu vereinfachen.

Ich habe ein Szenario entdeckt, in dem Person H aufgrund eines Softwarefehlers XYZ nicht im System registriert wird

Was ist Glitch XYZ?

Nehmen wir an, Person H tritt in das System ein, und gerade als sie auf „Senden“ klickt, fällt die Stromversorgung sofort aus. Ist Person H noch registriert oder sind alle Daten verloren gegangen?

Selbst wenn sie die Analogie missverstehen, können Sie sie einfach anpassen:

Nun, Stromausfälle sind selten.

Stromausfall kann hier vieles bedeuten, wie jemand das Kabel herauszieht, Wind das Kabel umwirft, Feuer ausbricht. Ist Patient H noch registriert oder brauchen wir ein System, das das handhabt?

Anstatt zu sagen, dass das Formular aufgrund eines Softwarefehlers möglicherweise Daten verliert, was für technisch nicht versierte Köpfe unverständlich ist, habe ich es in ein reales Beispiel umgewandelt, das zeigt, wie die Daten auf ähnliche Weise physisch verloren gehen können, was normalerweise der Fall ist fordert einen ausreichend nahen Kommentar oder Vorschlag auf, der an die Software angepasst werden kann.

Ihre Fragen und Methoden sollten sich an die jeweilige Person anpassen. Das Stellen offener Fragen wird diejenigen, die unsicher sind, noch unsicherer machen, und so greifen sie oft auf Dinge zurück, die sie Ihnen bereits gesagt haben.

Um Unsicherheiten zu vermeiden, geben Sie ihnen also die kleinste Menge an Informationen, die für die Arbeit erforderlich sind.

Das übergeordnete Problem hier ist, dass Sie gebeten werden, ein Business Analyst zu sein.

Die Unterscheidung zwischen einem Entwickler und einem Analysten besteht aus einem bestimmten Grund. KMUs zu befragen und ihre Antworten in verständliche und vollständige Anforderungen umzuwandeln, ist eine Aufgabe der Geschäftsanalyse, keine Aufgabe der Softwareentwicklung. Sie haben nicht die gleichen Fähigkeiten und verwenden nicht die gleichen Methoden.

Wenn der Kunde dem Entwickler einen Stundensatz zahlt, damit Sie Antworten suchen, die von einem (weniger teuren) Business-Analysten hätten dokumentiert werden sollen, bevor Sie überhaupt damit begonnen haben, die Zeit für das Projekt in Rechnung zu stellen, wird der Kunde schlecht bedient und das Projekt wird schlecht bedient schlecht gemanagt auf der Seite Ihres Teams.

Wenn in das Projekt keine Rolle als Business Analyst integriert ist – vielleicht, weil es nominell ein Scrum-Projekt ist und Sie es im Laufe der Zeit ausarbeiten sollten – dann sollten Sie eng genug mit den KMU zusammenarbeiten, damit diese umständlich, zeitweise und mehrdeutiger E-Mail-Austausch ist kein Problem; Sie sollten in ständigem Kontakt mit ihnen stehen und reichlich Gelegenheit haben, sich schrittweise Klarheit zu verschaffen.

Es hört sich so an, als ob Ihrem Beratungsunternehmen mindestens eine Kommunikationsebene fehlt.

Haben Sie einen Team-/Projektleiter oder Projektmanager? So soll der Ablauf funktionieren:

1. Der Kunde erstellt Anforderungen für das gesamte Projekt in großem Maßstab und Umfang.
2. Der Kunde teilte die Projektanforderungen dem Projektmanager/-leiter mit, der normalerweise, aber nicht immer, der Teamleiter des Entwicklungsteams ist.
3. Der Projektmanager erstellt eine Entwicklungsspezifikation basierend auf diesen Anforderungen und arbeitet mit dem Scrum Master des Teams zusammen (wenn Sie Agile verwenden; sie müssen nicht immer mit jemand anderem zusammenarbeiten, um dies zu tun, aber es ist normalerweise gut, die Perspektive eines Entwicklers einzuholen). Brechen Sie die Dev-Spezifikation in Tickets auf, die für sich genommen vollständige, gültige und lieferbare Arbeitsstücke sind.
4. Jedes Ticket wird von einem Entwickler ausgefüllt. Der Entwickler muss sich nicht mit Problemen außerhalb der Domäne seines Tickets befassen (und Bedenken außerhalb der spezifischen Domäne des Tickets, die jedoch beim Ausfüllen des Tickets berücksichtigt werden müssen, sollten im Ticket vorhanden sein).

Nun, wenn Sie diesen Arbeitsablauf haben, ist die Person, die der Experte für das Projekt ist, nicht der Kunde; es ist der Projektleiter. Der Projektmanager sollte eine Vorstellung davon haben, wie das Endprodukt aussehen sollte, und auch, wie jeder Zwischenteil des Projekts aussehen sollte, wenn es an den Kunden geliefert wird, denn sie waren diejenigen, die die Aufteilung des Projekts in kleine, zustellbare Eintrittskarten. Daher sollten sie das beste Bild haben; Sie sollten sie fragen, was auch immer die Frage ist. Wenn sie es dann nicht wissen, gehen sie zum Kunden und bitten um Klärung; Es wird erwartet, dass das kundenseitige KMU in der Lage sein wird, alle sekundären Überlegungen, wie die von Ihnen beschriebenen, viel einfacher an den Projektmanager weiterzugeben als an einen Entwickler wie Sie.