Anforderungen von Geschäftsleuten locken?

Welche Methoden scheinen am besten zu funktionieren, um Anforderungen von Nicht-Tech-Geschäftsleuten zu entlocken? Ich arbeite mit einem Team zusammen, das versucht, eine Spezifikation für ein Projekt zusammenzustellen. Jedes Mal, wenn wir uns getroffen haben und die Erwartungen für das nächste Meeting erfüllt sind, bitten wir die Geschäftsleute, ihre Anforderungen zurückzubringen. Normalerweise antworten sie wie folgt: „Glaubst du, ihr könntet einen Prototypen entwickeln, damit wir nächste Woche sehen können, was uns gefällt… du weißt, nicht mit irgendwelchen Daten oder irgendetwas, da es sich um einen Prototyp handelt, sondern nur um die Funktionalität.“ ist ein mehr als 6-monatiges Projekt, das offensichtlich nicht realisierbar ist (wir müssten das Ganze entwickeln!), und wir wissen nicht einmal, was wir ohne irgendeine Spezifikation prototypisieren sollen. Ehrlich gesagt denke ich, dass die meisten Menschen eine Vorstellung davon haben, was sie wollen, sie denken einfach nicht so konzentriert darüber nach, wie es notwendig ist, um die wahren Anforderungen zu erfüllen. Als Alternative zum einfachen Erzählen, „Gib uns, was du willst oder wir können / werden keine Arbeit machen“ (wir möchten, dass sie mit den Ergebnissen zufrieden sind), gibt es Möglichkeiten, ihnen bei der Entscheidung zu helfen, was sie wollen? Zum Beispiel könnten wir ihnen sagen:

„Zeichnen Sie einige Bildschirme (in Powerpoint, auf einer Serviette, was auch immer), in denen die gewünschte Benutzeroberfläche mit allen gewünschten Daten und eine Beschreibung der Funktionen an den Rändern angezeigt wird. Darauf aufbauend werden wir das Backend aufbauen und auf diesen Verhaltensanforderungen aufbauen. “

ODER

„Mach dir keine Sorgen, wie es jetzt aussehen wird (die Nummer 1 legt auf). Geben Sie uns einfach eine Liste aller Daten, die Sie über jede Sache, die das Programm verfolgt, benötigen. Für "Kunde" können Sie also Folgendes auflisten: Name, Adresse, Telefonnummer, Bestellungen usw. Es muss keine perfekte Datenbankstruktur sein, aber wir können daraus etwas herausarbeiten und eine Vorstellung davon bekommen, wonach Sie suchen.

Ist einer dieser alternativen Ansätze sinnvoll, um Geschäftsleute auf das zu konzentrieren, was sie wollen? Gibt es Alternativen, die Sie in Aktion gesehen haben?

Ich habe die letzten drei Monate in einer erschöpfenden - und anstrengenden - Phase verbracht, in der die Anforderungen eines Großprojekts gesammelt wurden, und vor allem festgestellt, dass es keine einheitliche Lösung gibt . Es gibt keinen Prozess, kein Geheimnis, das in jedem Fall funktionieren wird. Die Anforderungsanalyse ist eine echte Fähigkeit, und wenn Sie glauben, endlich alles herausgefunden zu haben, werden Sie einer völlig anderen Gruppe von Menschen ausgesetzt und müssen alles, was Sie wissen, aus dem Fenster werfen.

Einige Lektionen, die ich gelernt habe:

• Unterschiedliche Stakeholder denken auf unterschiedlichen Abstraktionsebenen.

  Es ist leicht zu sagen, "auf geschäftlicher Ebene zu sprechen, nicht technisch", aber es ist nicht unbedingt so einfach zu tun . Das System, das Sie entwerfen, ist ein Elefant, und Ihre Interessengruppen sind die Blinden, die es untersuchen . Manche Menschen sind so tief in der Prozess- und Routine eingetaucht , dass sie nicht einmal erkennen , dass es ist ein Geschäft. Andere mögen auf der von Ihnen gewünschten Abstraktionsebene arbeiten, neigen jedoch dazu, übertriebene oder sogar falsche Behauptungen aufzustellen oder sich auf Wunschdenken einzulassen.

  Leider muss man einfach alle Individuen als Individuen kennenlernen und verstehen, wie sie denken, wie sie die Dinge interpretieren, die sie sagen, und sogar entscheiden, was zu ignorieren ist.

• Teilen und Erobern

  Wenn Sie nicht möchten, dass etwas erledigt wird, senden Sie es an ein Komitee.

  Treffen Sie sich nicht mit Komitees. Halten Sie diese Besprechungen so klein wie möglich. YMMV, aber meiner Erfahrung nach ist die ideale Größe 3-4 Personen (einschließlich Sie selbst) für offene Sitzungen und 2-3 Personen für geschlossene Sitzungen (dh wenn Sie eine bestimmte Frage beantwortet haben müssen).

  Ich versuche, Leute zu treffen, die ähnliche Funktionen im Geschäft haben. Es gibt wirklich sehr wenig zu gewinnen und sehr viel zu verlieren, wenn man die Marketing-Leute mit den Bohnenzählern in den Raum wirft. Suchen Sie die Experten auf, die sich mit einem Thema auskennen, und lassen Sie sie über dieses Thema sprechen.

• Ein Meeting ohne Vorbereitung ist ein Meeting ohne Zweck.

  In einigen anderen Antworten / Kommentaren wurde auf die Strohmann-Technik verwiesen, die sich hervorragend für diejenigen eignet, die Probleme haben und auf die man scheinbar keine Antworten hat. Aber verlassen Sie sich nicht zu sehr auf Strohmänner, sonst fühlen sich die Leute, als würden Sie sie beschimpfen. Man muss die Leute sanft in die richtige Richtung schubsen und sie sich die Einzelheiten selbst überlegen lassen, damit sie das Gefühl haben, sie zu besitzen (und in gewissem Sinne besitzen sie sie auch).

  Was Sie brauchen, ist eine Art mentales Modell dafür, wie das Geschäft funktioniert und wie das System funktionieren sollte . Sie müssen Domain-Experte werden , auch wenn Sie kein Experte für das betreffende Unternehmen sind. Informieren Sie sich so ausführlich wie möglich über Ihr Unternehmen, seine Konkurrenten, die auf dem Markt befindlichen Systeme und alles andere, was möglicherweise auch nur aus der Ferne in Zusammenhang steht.

  Zu diesem Zeitpunkt fand ich es am effektivsten, mit Konstrukten auf hoher Ebene wie Use Cases zu arbeiten, die in der Regel für jedermann akzeptabel sind, aber es ist immer noch wichtig, bestimmte Fragen zu stellen. Wenn Sie mit "Wie rechnen Sie Ihren Kunden ab?" Sie sind in einem sehr langen Treffen. Stellen Sie Fragen, die einen Prozess implizieren , anstatt den Prozess beim Loslegen zu beenden: Was sind die Werbebuchungen? Wie werden sie berechnet? Wie oft wechseln sie? Wie viele verschiedene Arten von Verkäufen oder Verträgen gibt es? Wo werden sie gedruckt? Du hast die Idee.

  Wenn Sie einen Schritt verpassen, werden Sie normalerweise von jemandem darüber informiert. Wenn sich niemand beschwert, klopfen Sie sich auf den Rücken, weil Sie den Vorgang nur implizit bestätigt haben.

• Verschieben Sie Diskussionen außerhalb des Themas .

  Als Anforderungsanalyst spielen Sie auch die Rolle des Moderators. Wenn Sie nicht wirklich Spaß daran haben, Ihre gesamte Zeit in Meetings zu verbringen, müssen Sie einen Weg finden, die Dinge im Griff zu behalten. Ironischerweise wird dieses Problem am verderblichsten, wenn man die Leute endlich zum Reden bringt. Wenn Sie nicht aufpassen, kann der Zug, für den Sie so viel Zeit aufgewendet haben, entgleisen.

  Aber - und das habe ich vor langer Zeit auf die harte Tour gelernt - man kann den Leuten nicht einfach sagen, dass ein Thema irrelevant ist . Es ist offensichtlich relevant für sie , sonst würden sie nicht darüber reden. Ihre Aufgabe ist es, die Leute dazu zu bringen, so oft wie möglich "Ja" zu sagen, und eine solche Barriere zu errichten, bringt Sie einfach auf "Nein".

  Dies ist ein heikles Gleichgewicht, das viele Menschen mit "Aktionselementen" aufrechterhalten können - im Grunde genommen eine allgemeine Warteschlange von Diskussionen, zu denen Sie versprochen haben, irgendwann zurückzukehren , normalerweise gekennzeichnet mit den Namen der Stakeholder, die es für wirklich wichtig hielten. Dies dient nicht nur der Diplomatie, sondern ist auch ein wertvolles Hilfsmittel, um sich zu erinnern, was während der Meetings passiert ist und mit wem Sie sprechen können, wenn Sie später Abklärungen benötigen.

  Verschiedene Analysten gehen unterschiedlich damit um. Einige mögen das sehr öffentliche Whiteboard oder Flipchart-Protokoll, andere tippen es leise auf ihren Laptops an und gehen vorsichtig zu anderen Themen über. Was auch immer Sie sich wohl fühlen.

• Du brauchst eine Agenda

  Dies gilt wahrscheinlich für nahezu jede Art von Besprechung, aber auch für Anforderungsbesprechungen. Während sich die Diskussionen hinziehen, verlieren sich die Gedanken der Menschen und sie fragen sich, wann Sie zu den Dingen kommen, die ihnen wirklich am Herzen liegen. Eine Agenda bietet eine gewisse Struktur und hilft Ihnen, wie oben erwähnt, festzustellen, wann Sie eine Diskussion verschieben müssen, die vom Thema abweicht.

  Gehen Sie nicht hinein, ohne genau zu wissen, was und wann Sie abdecken möchten . Ohne das haben Sie keine Möglichkeit, Ihren eigenen Fortschritt zu bewerten, und die Benutzer hassen Sie dafür, dass Sie immer lange laufen (vorausgesetzt, sie hassen Sie nicht bereits aus anderen Gründen).

• Verspotte es

  Wenn Sie PowerPoint oder Visio als Mock-up-Tool verwenden, leidet das Problem, dass es zu poliert aussieht . Es ist fast ein unheimliches Tal von Benutzeroberflächen; Menschen fühlen sich wohl mit Serviettenzeichnungen (oder computergenerierten Zeichnungen, die wie Serviettenzeichnungen aussehen, wenn sie ein Werkzeug wie Balsamiq oder Sketchflow verwenden ), weil sie wissen, dass es nicht das Richtige ist - der gleiche Grund, warum Menschen Zeichentrickfiguren sehen können. Aber je mehr es aussieht wie eine echte Benutzeroberfläche, desto mehr Menschen werden daran interessiert sein, und desto mehr Zeit werden sie damit verbringen, über Details zu streiten, die letztendlich bedeutungslos sind.

  Machen Sie auf jeden Fall Mock-ups, um Ihr Verständnis der Anforderungen zu testen ( nach den anfänglichen Analysephasen). Auf diese Weise erhalten Sie sehr schnell und ausführlich Feedback. Sie sind sich ziemlich sicher, dass Sie Ihren Nutzern auf Augenhöhe begegnen.

  Denken Sie daran, dass ein Mock-up kein Ergebnis ist , sondern ein Hilfsmittel zum besseren Verständnis. So wie Sie beim UI-Design nicht erwarten würden, dass Sie an Ihrem Mock festhalten, können Sie nicht davon ausgehen, dass das Design in Ordnung ist, nur weil sie Ihrem Mock-up die Daumen hoch gaben. Ich habe Mocks gesehen, die als Krücke oder schlimmer noch als Ausrede benutzt wurden, um die Anforderungen gänzlich zu umgehen. Stellen Sie sicher, dass Sie das nicht tun. Gehen Sie zurück und verwandeln Sie diesen Schein in eine Reihe realer Anforderungen.

• Sei geduldig.

  Dies ist für viele Programmierer schwer zu glauben, aber für die meisten nicht-trivialen Projekte kann man sich nicht einfach einmal hinsetzen und eine komplette Funktionsspezifikation ausarbeiten. Ich spreche nicht nur von Geduld während eines einzigen Meetings. Die Anforderungsanalyse ist genauso iterativ wie der Code. Gruppe A sagt etwas und Gruppe B sagt etwas, das völlig im Widerspruch zu dem steht, was Sie von Gruppe A gehört haben. Dann erklärt Gruppe A die Inkonsistenz und es stellt sich heraus, dass Gruppe C vergessen hat, es zu erwähnen. Wiederholen Sie 500 Mal und Sie haben etwas, das ungefähr der Wahrheit ähnelt .

  Wenn Sie keine winzige CRUD-App entwickeln (in welchem ​​Fall, warum sollten Sie sich überhaupt um die Anforderungen kümmern?), Können Sie nicht erwarten, dass Sie in einem oder zwei oder fünf Meetings alles bekommen, was Sie brauchen. Sie werden viel zuhören, viel reden und sich viel wiederholen. Was wohlgemerkt keine schreckliche Sache ist; Es ist eine Chance, eine gewisse Beziehung zu den Menschen aufzubauen, die sich zwangsläufig von Ihrem Ergebnis verabschieden werden.

• Hab keine Angst davor, deine Technik zu ändern oder zu improvisieren.

  Unterschiedliche Aspekte eines Projekts erfordern möglicherweise unterschiedliche Analysetechniken. In einigen Fällen funktioniert die klassische UML (Use Case / Activity Diagram) hervorragend. In anderen Fällen könnten Sie mit KSIs für Unternehmen beginnen oder ein Brainstorming mit einer Mind Map durchführen oder sich trotz meiner früheren Warnung direkt in Mockups vertiefen.

  Das Fazit ist, dass Sie die Domäne selbst verstehen und Ihre Hausaufgaben machen müssen, bevor Sie die Zeit anderer verschwenden. Wenn Sie wissen, dass eine bestimmte Abteilung oder Komponente nur einen Anwendungsfall hat, dieser jedoch wahnsinnig kompliziert ist, überspringen Sie die Anwendungsfallanalyse und sprechen Sie über Workflows oder Datenflüsse. Wenn Sie nicht für jeden Teil einer App-Implementierung dasselbe Tool verwenden würden, warum würden Sie dann für jeden Teil der Anforderungen dasselbe Tool verwenden?

• Halte dein Ohr am Boden.

  Von allen Hinweisen und Tipps, die ich für die Anforderungsanalyse gelesen habe, ist dies wahrscheinlich derjenige, der am häufigsten übersehen wird. Ich glaube ehrlich, ich habe mehr über das Abhören und gelegentliche Abstürzen von Gesprächen mit Wasserkühlern gelernt als über geplante Meetings.

  Wenn Sie es gewohnt sind, isoliert zu arbeiten, versuchen Sie, einen Ort zu finden, an dem die Aktion stattfindet, damit Sie das Geschwätz hören können. Wenn Sie nicht können, dann machen Sie einfach häufige Runden, in die Küche oder ins Badezimmer oder wo auch immer. Sie werden alle möglichen interessanten Dinge darüber herausfinden, wie das Geschäft wirklich funktioniert, wenn Sie hören, was die Leute während ihrer Kaffee- und Rauchpausen prahlen oder sich darüber beschweren.

• Zuletzt lesen Sie zwischen den Zeilen .

  Einer meiner größten Fehler in der Vergangenheit war es, mich so auf das Endergebnis zu konzentrieren, dass ich mir nicht die Zeit nahm, zu hören, was die Leute sagten . Manchmal - die meiste Zeit - hört es sich so an, als würden die Leute über nichts quasseln oder über ein Verfahren harpen, das für Sie völlig sinnlos klingt, aber wenn Sie sich wirklich auf das konzentrieren, was sie sagen, werden Sie feststellen, dass es wirklich etwas gibt eine Anforderung darin begraben - oder mehrere.

  So kitschig und fade es klingt, die Five Whys sind hier eine wirklich nützliche Technik. Wann immer du diese dumme Reaktion hast (nicht, dass du es jemals laut sagen würdest), halte dich zurück und verwandle sie in eine Frage: Warum? Warum werden diese Informationen viermal neu eingegeben, dann gedruckt, fotokopiert, gescannt, erneut gedruckt, auf eine Spanplatte gesteckt, mit einer Digitalkamera aufgenommen und schließlich per E-Mail an den Verkaufsleiter gesendet? Es gibt einen Grund , und sie wissen vielleicht nicht, was es ist, aber es ist Ihre Aufgabe, es herauszufinden. Viel Glück damit. ;)

Wenn Sie etwas nicht herausholen können, schreiben Sie etwas auf und lassen Sie es genehmigen. Es ist viel einfacher für Nicht-Techniker, "Nein, das mag ich nicht" zu sagen, als "das ist, wie Sie es tun sollten".

Oft sind das, was sie wollen und was sie Ihnen sagen, zwei sehr unterschiedliche Dinge. Nehmen Sie sich etwas Zeit, um einen ersten Entwurf der Spezifikation mit den Ihnen derzeit bekannten Informationen zu verfassen. Bitten Sie die Stakeholder, es zu lesen und zu genehmigen. Wenn sie es lesen, werden sie höchstwahrscheinlich Dinge sehen, die ihnen nicht gefallen oder denen sie nicht zustimmen. Holen Sie sich ihr Feedback und überarbeiten Sie es dann.

Wenn es etwas gibt, das Sie auf die eine oder andere Weise tun können, stellen Sie beide Optionen online und lassen Sie den Entscheider eine Entscheidung treffen. Lass sie nicht alleine, bis sie es tun.

Erstellen Sie für Prototypen Bildschirmmodelle, und erklären Sie, wie die Dinge stattdessen funktionieren würden. Wieder hilft es ihnen, etwas zu sehen, um zu visualisieren, was vor sich geht. Nehmen Sie neue Bildschirmmodelle zu Besprechungen mit und erhalten Sie Antworten.

In der Vergangenheit habe ich FireBug tatsächlich geöffnet und die Änderung hinzugefügt, die der Kunde direkt vor ihnen angefordert hatte, damit sie sehen konnten, wie sie aussehen würde. Sie gaben ihr Feedback, ich machte einen Screenshot und implementierte die Änderungen. Sie mochten es wirklich zu sehen, wie die Veränderung aussehen würde, und ich mochte es, weil es schnell ging und ich meine Antwort in dieser Besprechung bekam ... nicht in der nächsten.

Lassen Sie sie mehr über ihr Geschäft und weniger über Anwendungen sprechen. Finden Sie heraus, was die eigentlichen Probleme sind: Die Berichterstellung zum Monatsende dauert zu lange, Dateneingabefehler, sie sind aus ihrer aktuellen Anwendung herausgewachsen, das Unternehmenswachstum gerät außer Kontrolle.

Ich vermute, dass diese Besprechungen mit den Leuten stattfinden, die den Einkauf erledigen, aber nicht mit den Leuten, die die Arbeit mit der Anwendung tatsächlich erledigen. Fragen Sie, ob Sie einige dieser Leute treffen können. Sie können Ihnen zeigen, wie die Dinge wirklich gemacht werden. Stellen Sie sicher, dass Sie mit Kunden zu tun haben, die ihre Zeit und die Kosten budgetiert haben.

Überprüfen Sie, ob sie Berichte haben, die sie aktuell verwenden oder verwenden möchten. Offensichtlich können Sie den Bericht nicht erstellen, wenn Sie die Daten nicht ordnungsgemäß erfassen. Sie müssen etwas tun, es sei denn, dies ist ein Geschäftsbereich, den sie noch nicht begonnen haben.

Viele haben diese allgemeinen Vorstellungen, dass Sie der Programmierer sind, sodass Sie wissen, wie alle Programme erstellt werden. E-Commerce-Sites sind alle gleich, oder?

Fangen Sie klein an. Leider wird der Vorgang erst registriert, wenn Sie etwas vor sich haben. Wenn Sie nichts zu verpassen haben, dann täuschen Sie es einfach vor.

Ein Großteil davon hängt mit allgemeinen zwischenmenschlichen Fähigkeiten und der Art und Weise zusammen, wie Sie in erster Linie mit dem Kunden kommunizieren. Darüber hinaus kann ich nicht viel sagen - stellen Sie sicher, dass Sie den Prozess als interaktiven Prozess beschreiben, bei dem Sie auch von den Kunden Feedback und Anstrengungen erwarten.

Speziell für das von Ihnen beschriebene Szenario sind hier einige weitere Ratschläge: Beschreiben Sie zunächst, was Sie für nützlich halten, und stellen Sie Fahrzeuge bereit, um die Informationen in Begriffen zu beschreiben, die keine technische Spezialisierung oder Know-how erfordern:

• Anwenderberichte / Anwendungsfälle Bitten Sie um detaillierte Beschreibungen dessen, was die Anwender erwarten, welche Informationen sie benötigen, und was Sie von den Anwendern erwarten sollten und können, dass sie sich selbst eingeben. Wenn Sie diese Informationen haben, gehen Sie sie durch und stellen Sie sicher, dass alles mit Geschichten bedeckt ist - es sollte nichts geben, das in die Anwendung eingeht, wo Sie keine Geschichten haben, die beschreiben, was der Benutzer dort tun wird.

• Überzeugende Vorführungen Was ist wichtiger, um Kunden zu gewinnen? Welche Teile des Programms oder der Funktionalität müssen hervorstechen und vollständig poliert werden? Können Sie mir eine Modelldemo zur Verfügung stellen, indem Sie Haftnotizen, Pappkartons oder andere Stellvertreter verwenden, an denen Sie gerne arbeiten würden?

• Markt- / Wettbewerbsinformationen Was machen wir für jede User Story ähnlich wie unsere Wettbewerber? Anders? Welche Geschichte erzählen unsere Konkurrenten und versuchen wir zu kopieren / zu emulieren / zu verbessern / zu innovieren / absichtlich anders zu sein?

• Offene Fragen Was sind von den Anforderungen und dem Design Informationen, von denen Sie sicher sind, und was ist ein Experiment? Wo werden wir Alternativen ausprobieren, um zu sehen, welche funktioniert? Wenn Sie mehrere Alternativen in Betracht ziehen und uns nur eine mitgeteilt haben, welche anderen erwägen Sie?

Dann ziehen Sie einige Grenzen heraus:

• Bitte schränken Sie mich nicht technisch ein . Ein Geschäftsmann sollte Ihnen nicht sagen, dass Sie "Windows verwenden, weil es besser ist als Linux". Sie können jedoch Anweisungen im Sinne von "Alle in unserem Zielmarkt verwendeten Fenster, unsere Anwendung muss auf Fenstern ausgeführt werden, um erfolgreich zu sein" bereitstellen.

• Machen Sie sich keine Sorgen um das Design. Insbesondere wenn Sie mit vertriebs- oder marketingorientierten Mitarbeitern zu tun haben, sind diese in der Regel mit Designproblemen konfrontiert. Auch hier beschränken Sie den Informationsumfang auf das, worauf sie sich spezialisiert haben - "Blau ist hier schöner" ist wahrscheinlich nicht angebracht. "Unser Konkurrent verwendet ein blaues Farbthema und es gibt es schon seit den 80er Jahren. Für Teile unseres Programms, in denen wir keine Innovationen entwickeln, sollten wir ein blaues Schema verwenden, um zu kommunizieren, dass wir nicht neu sind", ist dies wahrscheinlich angemessen. "Der Name sollte oben auf dem Bildschirm stehen" ist wahrscheinlich nicht angebracht, aber "die wichtigste Information auf dieser Seite ist der Name des Benutzers und der Kontostand" ist wahrscheinlich. Stellen Sie sicher, dass ein Designer an der Übersetzung dieser Anforderungen in eine Benutzeroberfläche beteiligt ist.

• Schreiben Sie Entscheidungen auf. Bauen Sie diese vorzugsweise in Verträge oder andere Verpflichtungen ein, die Sie eingehen. Denken Sie jedoch daran, dass eine Entscheidung, die der Kunde nicht versteht, das Papier nicht wert ist, auf das er geschrieben hat. Ein Kunde, der sich bei "Die Anwendung wird auf Port 1521 ausgeführt" abmeldet, ist nicht so viel wert wie der Kunde, der sich bei "Die Anwendung wird auf einem benutzerdefinierten, konfigurierbaren Port ausgeführt", für den bei der Bereitstellung möglicherweise eine spezielle Konfiguration für Firewall und Sicherheit erforderlich ist "

Aus Ihrer Sicht, um den Prozess weiter voranzutreiben:

• Feedback auf der gleichen Abstraktionsebene bereitstellen Dies ist allgemein üblich, z. B. für Einheiten. Wenn der Kunde über ein monatliches Benutzervolumen spricht, antworten Sie nicht in Gigabit Bandbreite. Oder für Anwendungsfälle: Beschreiben Sie die Funktionalität anhand der Anwendungsfälle und nicht anhand von Modulen oder Fehlerkorrekturen oder Features.

• Stellen Sie aussagekräftige Kommunikationsphrasen bereit. Geben Sie die Fragen an, die Sie haben, und zusätzliche Informationen, die Sie entdeckt haben oder die Sie suchen, in Bezug auf die Informationen, die Ihnen bereitgestellt wurden. "Wir gehen mit Linux" ist wahrscheinlich schlecht geschriebenes Feedback, während "unsere Tests zeigen, dass die Anwendung reibungsloser läuft, wenn sie auf Linux-Rechnern gehostet wird und mit IE unter Windows zugegriffen wird" angemessener sein könnte.

• Schnelle Iteration Um den Client auf dem Laufenden zu halten, stellen Sie schnelle, aussagekräftige Aktualisierungen und Iterationen bereit. Spezifikationen und Informationen, die zu Beginn des Prozesses nicht verfügbar oder nicht einfach zu erhalten waren, können Ihren Kunden viel Arbeit abverlangen, der Sie wahrscheinlich bezahlt, während Sie ihn nicht für seine Arbeit bezahlen. Es kann hilfreich sein, den Kunden einzubeziehen und in den Prozess zu investieren, wenn die Arbeit etwas ist, für das er Zeit und Mühe aufwenden muss.

Ihre Kunden, die Geschäftsleute, haben möglicherweise ein Problem, wünschen sich eine technische Lösung, haben aber keine Ahnung, wie die Lösung funktionieren könnte, und haben daher auch keine Ahnung, wie eine mögliche Lösung angegeben werden kann. In diesem Fall fehlt die Rolle eines Analysten für Geschäftslösungen, der den Kunden, seine Probleme, seine Arbeitsabläufe usw. untersuchen und untersuchen kann, wie mögliche Lösungen zu seinen Unternehmensabläufen, seiner Unternehmenskultur usw. passen und ob dies der Fall ist Möglicherweise kann eine bestimmte Lösung zeitlich, im Rahmen des Budgets usw. implementiert werden. Dies kann eine äußerst interdisziplinäre Aufgabe sein, die Kenntnisse der Geschäftspraktiken (Recht, Buchhaltung, Logistik usw.), der Benutzerpsychologie sowie der Softwaretechnologie erfordert.

Klingt so, als ob Sie den Kunden zwingen möchten, sein eigener Analyst für Geschäftslösungen zu sein. Dies ist möglicherweise keine Rolle, für die sie über ausreichende Fachkenntnisse verfügen, um eine angemessene Spezifikation zu gewährleisten. Und es hört sich so an, als ob Sie diese Rolle auch nicht übernehmen möchten. Wenn weder Sie noch Ihr Kunde das Fachwissen haben, um diese Rolle zu besetzen, verfügen Sie möglicherweise nicht über alle für ein erfolgreiches Projekt erforderlichen Mitarbeiter.

Manchmal ist ein Haufen schneller Prototypen, mit denen der Kunde spielen kann, die einzige Möglichkeit, experimentell eine brauchbare Lösung für die (stimmhaften und stimmlosen) Bedürfnisse des Kunden zu finden und zu konvergieren. Dies kann für jede Art von unbefristetem Vertrag geeignet sein oder nicht.

HINZUGEFÜGT: Wenn Sie versuchen, ein Anforderungsdokument von Kunden zu erzwingen, die nicht über das erforderliche Fachwissen verfügen, kann dies möglicherweise eine große rote Flagge sein, die auf eine bevorstehende Katastrophe hinweist.

Fragen Sie nicht nach UI- oder Datenanforderungen, sondern nach Funktionalitätsanforderungen.

Fragen Sie sie, was die Anwendung tun soll. Lassen Sie sie durchgehen, wie sie die Anwendung verwenden möchten. Lassen Sie Details wie Benutzeroberfläche, Daten usw. für den Anfang unberücksichtigt.

Ich habe festgestellt, dass Benutzer oft nicht wissen, was sie in Bezug auf Benutzeroberfläche oder Daten wollen, aber sie wissen, was sie wollen, was Funktionalität betrifft. Sie sagen mir zum Beispiel: "Ich möchte mich anmelden und alle Kundeninformationen sehen." Machen Sie sich keine Gedanken darüber, wie die Bildschirme aussehen oder welche Daten sie benötigen, sondern holen Sie sich nur die Funktionalität von ihnen.

Sobald Sie das haben, machen Sie ein kurzes Modell (ich mag Balsamiq ). Nehmen Sie einfach an, wie die Benutzeroberfläche / Daten aussehen werden, und verbringen Sie nicht viel Zeit damit. Bringen Sie das Modell dann zum Kunden zurück. Von dort können sie Ihnen sagen, "wir brauchen diese Felder nicht" oder "Wir wollen tatsächlich eine Liste von Telefonnummern, nicht nur eine", oder "dies sollte ein Dropdown-Menü sein, keine Listbox".

Sobald Sie den Ausgangspunkt gefunden haben, ist es viel einfacher, Daten und Benutzeroberfläche zu verfeinern, und ich finde, dass die Ermittlung der Funktionalität der beste Ausgangspunkt ist.

Ich schlage vor, dass Sie versuchen, sie in erster Linie auf Geschäftsprozesse zu konzentrieren. Lassen Sie sie entweder in einem Dokument oder in einer Diskussion definieren, wie sie derzeit die Aufgaben ausführen, die von Ihrer Software ausgeführt werden. Konzentrieren Sie sich dann darauf, welche Teile des Prozesses geändert werden sollen (der Grund, warum Ihre Software gewünscht wird). Verwenden Sie dies als Ausgangspunkt, um zu diskutieren, welche anderen Teile des Prozesses mithilfe Ihrer Software verbessert oder sogar ganz entfernt werden könnten.

Wenn Ihr Kunde nicht daran gewöhnt ist, Softwareanforderungen bereitzustellen, sollte Ihr Team die Anforderungen für sie erstellen. Erwarten Sie, dass Sie mehrere Revisionen durchlaufen, aber Sie sollten ihnen zumindest ein erstes Dokument zur Verfügung stellen, um zu kommunizieren, wonach Sie suchen.

Sobald Sie eine gute Vorstellung von den funktionalen Anforderungen des erwarteten Endergebnisprozesses erhalten haben, der Ihre Software enthält, können Sie anfangen, Modelle der Schnittstellen zu entwerfen. Wenn Sie möchten, dass sie es zuerst versuchen, können Sie es, aber normalerweise ist es besser, die ersten Ideen zu liefern und sie herumfeilen zu lassen. Sie benötigen dafür keinen Funktionscode. Screenshots von in der Entwicklung befindlichen Benutzeroberflächen, HTML-Darstellungen der Layouts mit statischem Fülltext oder sogar Zeichnungen (wenn Sie einen anständigen Mitarbeiter haben) könnten für die ersten Diskussionen über die Benutzeroberfläche verwendet werden.

Wenn Sie ein paar Revisionen durchlaufen haben und alle mit dem, was präsentiert wird, einverstanden sind, holen Sie sich die schriftliche Zustimmung des Kunden ein! Egal wie sehr sie sich widersetzen, dieser Schritt ist entscheidend. Möglicherweise müssen Sie ihnen versichern, dass das Abzeichnen der Anforderungen nicht bedeutet, dass sie keine weiteren Eingaben in das Projekt haben können (abhängig von der Art Ihrer Beziehung zum Kunden). In diesem Fall sollten Sie darlegen, wie Änderungen an den Anforderungen vorgenommen werden werden behandelt (z. B. vorbehaltlich Überprüfung und Genehmigung, Weitergabe an eine nachfolgende Version, gesonderte Preisgestaltung als Verbesserung usw.).

Ich würde ihnen sagen, dass Sie das Programm Feature für Feature entwickeln werden. Nehmen wir an, dass Sie bis zu einem nächsten Meeting in 1-2 Wochen eine Vielzahl von Funktionen nutzen werden. Dies kann 1, 2, 3 oder mehr sein.

Angenommen, Sie werden zuerst die wichtigste Funktionalität entwickeln. Sie müssen mit den Kernfunktionen beginnen. Angenommen, Sie stellen einen Geldautomaten her (aus Gründen der Argumentation). Sagen Sie es ihnen, ok. Das erste (oder nächste) Element in der Liste der wichtigsten Funktionen ist die Abfrage des Geburtsdatums des Benutzers als Bestätigung für eine große Auszahlung (als Ersatz für eine Funktion in Ihrem Projekt, von der Sie wissen, dass es nicht zu den Hauptfunktionen gehört) würde als nächstes implementiert werden).

Diese naive Behauptung sollte eine Reaktion des Kunden hervorrufen. Wenn sie gefragt werden, was würden sie als nächstes tun? Was ist das wichtigste Feature, das für das Projekt noch nicht durchgeführt wurde und das besser ist als das von Ihnen erwähnte?

Wenn Sie das vorherige Beispiel erneut verwenden, werden Sie vom Kunden möglicherweise aufgefordert, die Karte des Benutzers zu validieren oder Einzahlungen usw. vorzunehmen. Bitten Sie ihn dann, sie für Sie zu definieren. Haben Sie keine Angst, viele Fragen zu stellen, wenn nötig auch naive.

Nachdem Sie dies mit dem Kunden besprochen haben, sollten Sie einige Anforderungen für diese Funktionalität haben. Sie könnten mehr als ein Stück Funktionalität definieren, aber ich würde die Anzahl sehr niedrig halten.

In 1-2 Wochen treffen Sie sich wieder mit dem Kunden, um ihm zu präsentieren, was Sie getan haben, und um seinen Input dazu zu bekommen. Präsentieren Sie es dem Kunden und holen Sie sich dessen Input, wenn etwas geändert oder hinzugefügt werden muss.

Wiederholen Sie dann die vorherige Übung für die nächsten Funktionen. Setzen Sie diesen Prozess für den Rest des Projekts iterativ fort, und stellen Sie sicher, dass Sie mit dem Kunden in Kontakt bleiben und sich in regelmäßigen Abständen treffen, um Ihre Arbeit zu zeigen und zu planen, was als nächstes getan wird (immer mit kleinen Stücken).

Sie reden über Technik und das interessiert sie meiner Erfahrung nach nicht. Sie wollen sich auch nicht dazu verpflichten, irgendetwas zu tun (besonders nicht schriftlich), und sie wollen eigentlich keine Arbeit tun, obwohl dies nicht speziell für Geschäftstypen ist - niemand möchte eine Menge Arbeit in einer Domäne erledigen, die sie haben Weiß nicht und will es nicht wissen. Das ist deine Aufgabe (in ihren Köpfen).

Was ich tue, ist Folgendes: Sprechen Sie mit ihnen über das, was sie wollen, in ihrer Domänensprache. Sie sind nicht in der Lage oder gewillt, genau zu sein, wie Sie es sich erhofft haben (Anwendungsfälle, vertragliches Design usw.), aber Sie können ihre vage und luftige Liste von Desideraten präzise in tatsächliches Design umsetzen und ein Designdokument. Wenn sie Ihnen die Zeit dafür einplanen, umso besser. Wenn nicht, erstellen Sie eine spontane, informelle, auf der Sie iterieren können.

Ich weiß, das ist keine sehr fröhliche Antwort, aber ich fand das Leben einfacher, als ich aufhörte, Kunden (oder wirklich irgendjemanden) dazu zu bringen, in mein Universum einzutreten und meine Sprache zu sprechen. Auch wenn ich immer wieder die gleichen Fragen stelle, während ich mich mit der Domäne und den Anforderungen auseinandersetze (die vom Kunden oft nur vage verstanden werden), ist die eingängige Sache, dass die Diskussionen nicht frustrierend sind. Tatsächlich werden die Beziehungen zu den Kunden tendenziell enger, vermutlich, weil die Leute gerne über das reden, was sie wissen, und Sie das POV runder verstehen, als Sie es vielleicht tun würden, wenn Sie einen strengeren Designansatz verfolgen.

Ohne einen Manager, der etwas von Programmierung versteht, hatte ich noch nie ein bisschen Erfolg. Der einzige Ansatz, den ich gefunden habe, besteht darin, zu beobachten, was tatsächlich vor sich geht.

Ich denke, Programmierer können sich besser vorstellen, wie ein Programm aussehen wird, bevor es erstellt wird. Papier-Prototyping kann eine effektive Technik sein , um dies zu überwinden. Papierprototypen sind relativ "billig" zu bauen. Indem Sie Ihre Kunden durch einen einfachen Papier-Prototyp führen, zeigen Sie, dass Sie "auf die fokussierte Weise denken müssen, die erforderlich ist, um die tatsächlichen Anforderungen zu erfüllen". Und es gibt eine spezielle Möglichkeit, sich zu konzentrieren: Versuchen Sie tatsächlich, die Anwendung zu verwenden, die sich in Ihrem Kopf befindet!

Außerdem können Sie sehr schnell iterieren, wenn Sie genau erraten, was der Client für die Anwendung wünscht, die der Client wirklich wünscht, aber Schwierigkeiten beim Übertragen hat. Es ist einfacher, sich einen Prototyp anzusehen und zu entscheiden, warum er nicht zur idealen Anwendung in Ihrem Kopf passt, als alle Anforderungen dieser Anwendung aufzulisten.

Ich habe auf einer Website gearbeitet, auf der die anderen Partner eher geschäftlich ausgerichtet waren. Ich habe auf viele verschiedene Arten nach spezifischen Anforderungen gefragt. Ihre Antwort lautete im Grunde: "Sie sind der Computertyp, wir erwarten, dass Sie dieses Zeug herausfinden. Wir ziehen es vor, das Geschäftliche zu erledigen." Sie waren nicht mit den spezifischen Details beschäftigt ... bis die erste Version veröffentlicht wurde! Sie zeigten sich viel begeisterter über die Anforderungen nach der Veröffentlichung und gaben mir alle möglichen Rückmeldungen, die mir im Vorfeld viel Zeit gespart hätten, als ich anfänglich gefragt hatte.

Daher entschied ich, dass Iteration der Schlüssel ist: Erstellen Sie die minimal brauchbare Version und verbessern Sie sie basierend auf dem Feedback. Wenn die Anforderungen zu vage und allgemein sind, treffen Sie Entscheidungen auf der Grundlage von "Was ist die einfachste und schnellste Implementierung?". (Vorbehaltlich grundlegender Systemdesign / Architektur). Wägen Sie nicht zu viel auf Annahmen ab, die auf dem beruhen, was Sie für "richtig" halten. Es wird nur Zeit verschwenden, weil es sehr wahrscheinlich ist, dass sich Ihr Denkprozess von Ihren Kunden unterscheidet.

Beispiel: Der Client fragt nach der Funktion zum Hochladen von Bildern. Ich werde nicht näher auf die spezifischen Anforderungen eingehen. Baue es so naiv wie möglich. Auch wenn Sie der Meinung sind, dass der Client dies wünscht, sollten Sie keine automatischen Funktionen zum Zuschneiden, Ändern der Größe und zum Miniaturansichten hinzufügen. Lassen Sie den Client die minimal funktionsfähige Version sehen (die Sie viel schneller als die nicht-naive Version entwickeln können), und die Anforderungen werden wie folgt eingehen: "Dies ist das, was mit der aktuellen Version nicht stimmt." Protokollieren Sie jede dieser neuen Anforderungen als "Fehler". Sie können priorisieren, welche am einfachsten / vorteilhaftesten sind.

Eigentlich ist mir passiert: Anmeldeformular mit speziellem Einladungscode anfordern. Die Idee war, einen viralen Registrierungsprozess zu erstellen, bei dem jeder neue Benutzer einige Einladungen erhielt. Ich habe viel Zeit darauf verwendet, sicherzustellen, dass die Codes eindeutig sind und nur einmal verwendet werden können. Ich habe mich auch sehr bemüht, den Prozess so reibungslos wie möglich zu gestalten, indem ich die Felder für Vor- und Nachnamen optional gemacht habe. Am Ende fragten die Partner nach diesen Änderungen: Vor- und Nachname sind obligatorisch, Anmeldecode ist gültig, wenn überhaupt etwas in das Feld eingegeben wurde ... seufz ~