Während wir die Diskussion über objektorientierte Programmierung in WordPress weiter vorantreiben, ist es wichtig, dass wir sicherstellen, dass wir uns nicht selbst vorauseilen, wenn es darum geht, ein Produkt für jemand anderen zu entwickeln.

So oft ist es einfach:

1. hören, was ein Kunde sagt,
2. etwas aufbauen, basierend auf dem, was wir gehört haben,
3. übergeben Sie es dem Kunden.

Aber es steckt noch so viel mehr dahinter. Ich habe in früheren Beiträgen dieser Serie ein wenig darum herumgetanzt; Ich möchte jedoch anfangen, herauszufinden, was es bedeutet, zu hören:

1. Was ein Kunde sagt,
2. Entwickeln Sie eine Reihe von Anforderungen,
3. Und dann erstellen Sie Feedbackschleifen darum herum.

Letztendlich wollen wir sicherstellen, dass die Menschen, für die wir arbeiten, und die Lösungen, die wir entwickeln, wirklich Lösungen sind und keine Hindernisse oder Hürden, über die sie springen müssen.

Außerdem denke ich, dass es nicht ausreicht, dass ein Kunde einfach die Erfahrung seines Endprodukts genießt, sondern dass er auch mit demjenigen (oder denjenigen) zusammenarbeitet, der die Lösung entwickelt.

Lassen Sie uns einen Blick darauf werfen, was es bedeutet, zuzuhören, was sie sagen, und von dort aus weiterzugehen.

Kundenerwartungen verstehen

Wann immer Sie Bücher oder anderes Material über diese Art von Zeug lesen, macht es oft eine von zwei der Parteien zum „Bösen“. Nicht immer, aber manchmal macht es:

• der Kunde scheint nicht zu wissen, wovon er spricht,
• oder es lässt den Entwickler wie einen Idioten erscheinen, weil er sich wie jemand verhält, der mehr über das jeweilige Thema weiß.

Wie wäre es mit einer dritten Option, bei der der Kunde eine klare Vorstellung davon hat, was er will, der/die Entwickler bereit sind, zuzuhören und mit dem Kunden zusammenzuarbeiten, um etwas zu entwickeln?

Sicher, es wird auf dem Weg dorthin Klärungen geben, und es wird Begriffe geben, die definiert werden müssen, und eine gewisse „Neukalibrierung“ des Entwicklungskalenders kann sogar dazu gehören.

Aber die Quintessenz ist: Keine Partei sollte gegen die andere arbeiten. Stattdessen geht es darum, gemeinsam an der Lösung zu arbeiten. Sicher, es erfordert Kommunikation (was Entwickler meiner Erfahrung nach nicht immer gut können, aber es gibt keinen Grund, warum es nicht besser sein könnte).

Was sagt ein Kunde? (Was sagt der Entwickler?)

Wann immer Sie beide sich treffen, denken Sie wahrscheinlich dasselbe, weil Sie beide eine andere Sprache sprechen und jeder von Ihnen denkt, was der andere sagt, ist Fachjargon.

Und das ist nicht falsch.

Kunden haben eine Art, darüber zu sprechen, was sie wollen, und Entwickler haben eine Art, darüber zu sprechen, wie sie liefern werden.

Die von uns verwendeten Bedingungen

Aber es kann ein gemeinsames Ziel geben.

Streben Sie eine Beschreibung des Problems an, das gelöst werden soll. Versuchen Sie dies in Laiensprache zu tun, damit das Design mit dem Ziel und der Funktionalität der Lösung übereinstimmt.

Ich glaube nicht, dass dies für jeden funktioniert, aber ich empfehle dies als Erstes, wenn Sie sich mit Ihrem Kunden zusammensetzen.

Wie Sie später in diesen Posts sehen werden, ist es hilfreich, ein paar Sätze zu entwickeln, die Sie zu Beginn Ihrer Leistungsbeschreibung verwenden können und auf die Sie sich jedes Mal beziehen können, wenn Sie eine Entscheidung treffen müssen.

Mit anderen Worten, Sie (und sie) können fragen:

Trägt das, woran ich arbeite, zum gemeinsamen Ziel bei?

Und hier können Sie die Kernanforderungen bestimmen.

„Es muss …“

Wenn es darum geht, etwas zu kaufen, etwas zu bauen, etwas anzufordern, etwas zu wollen oder was auch immer, ist es ziemlich einfach, den Satz mit „Ich möchte, dass …“ beginnt.

Aber es gibt einen großen Unterschied zwischen „Ich möchte, dass es [etwas tut]“ und „Ich brauche es [um etwas zu tun]“, und wenn Sie mit Software arbeiten, können Sie im Allgemeinen mit Sicherheit sagen, dass die Dinge, die benötigt werden, Kern sind zur Bewerbung. Und die gewünschten Dinge sind das, was kommt, nachdem die Grundlage der Anwendung erstellt wurde.

Das heißt, es ist ein Gespräch über „Must-Have“ und „Want-To-Have“. Und es ist wichtig, Gespräche zu führen, um zu dieser abschließenden Aussage über das gemeinsame Ziel der Bewerbung zu gelangen.

Sobald dies eingerichtet ist, können Sie beginnen, Ihre Software um das Problem des Kunden herum zu planen. Und hier kommt das Sammeln von Anforderungen ins Spiel.

Anforderungen entwickeln

Was Sie und der Kunde haben ein solides Verständnis davon, was gebaut werden muss, dann ist es an der Zeit, Anforderungen zusammenzustellen.

Dieser Teil kann mehr Spaß machen, als es sich anhört. Ich weiß, ich weiß: Klingt wie eine Hausaufgabe oder eine Hausaufgabe, oder? Aber es ist nicht. Stattdessen nehmen sie, was sie wollen, was Sie verstanden haben, übersetzen es in eine gemeinsame Sprache und schreiben dann ein Dokument, das erklärt, was die Software tun wird.

Abhängig von Ihrer Erfahrung kann dies jedoch langweilig sein. Und mit langweilig meine ich einen der schlimmsten Teile Ihres Jobs. Außerdem ändern sich die Anforderungen immer, oder?

Nicht immer.

Wenn Sie sich von Anfang an Zeit nehmen, um zu verstehen, was sie wollen, müssen die Anforderungen kein 50-seitiges Dokument sein, in dem beschrieben wird, wie jedes einzelne Modul funktionieren muss.

Viele Bücher dokumentieren, dass es so sein muss. Aber in fast einem Jahrzehnt, in dem ich dies tue, hatte ich noch nie etwas so Langes und Kunden waren im Allgemeinen unglaublich dankbar, eine kurze Liste zu sehen, die per E-Mail oder Google Docs geändert, signiert und dann als Projektumzüge bezeichnet werden kann nach vorne.

Ich werde in Zukunft mehr darüber sprechen, aber was auch immer Sie für schlechte Erfahrungen, Ängste oder Beklemmungen haben, Sie müssen nicht sitzen bleiben. Und wir werden in dieser Serie weiter darüber sprechen.