Ich bin ein junger Programmierer. Da mein Vorgesetzter mir sagte, ich solle mich mit dem Kunden zusammensetzen, ging ich mit. Ich sah das unzufriedene Gesicht des Kunden, obwohl das Projekt (aus der Sicht meines Programmierers) erfolgreich abgeschlossen wurde!
Kunde: Das hätten Sie einbauen können!
Wir: Das stand nicht in der Spezifikation!
Kunde: Gesunder Menschenverstand!
Wie reagieren Sie als Programmierer in dieser Situation?
Was Sie tun sollten, um diese Situation zu vermeiden:
Legen Sie explizit fest, was einbezogen wird und was nicht.
Das Problem liegt wahrscheinlich in den nicht spezifizierten Teilen der Spezifikation:
Für künftige Spezifikationen sollten Sie eine "catch all"-Erklärung vorsehen, die ausdrücklich besagt, dass etwas, das nicht in diesem Dokument aufgeführt ist, gegen zusätzliche Kosten auch nach der ursprünglichen Spezifikation ausgeführt werden kann.
Was Sie in der aktuellen Situation tun sollten:
Sie sollten nicht nur aus Ihren Erfahrungen lernen, sondern auch einen Kompromiss mit dem Kunden finden.
Beispiel: Ich werde diese Funktion, die Sie für vernünftig halten, übernehmen, aber für alle künftigen Ergänzungen/Änderungen muss sie ausdrücklich spezifiziert werden.
Das heißt, Sie müssen ein wenig mehr Arbeit leisten, aber das ist es wert, wenn Sie im Gegenzug eine explizit spezifizierte Vereinbarung mit Ihrem Kunden abschließen.
Schlechte Spezifikationen?
War es unbedingt eine schlechte Spezifikation? Nein.
Es ist unmöglich, alles zu erwähnen, was Ihre Kunden erwarten, daher ist es wichtig, dass die oben erwähnte "catch all"-Erklärung klar und deutlich in Ihren Spezifikationen/Verträgen enthalten ist.
Andere Möglichkeiten, das Problem zu verringern:
Dies ist einer der vielen Gründe, warum ich zu einer Agile Entwicklung Philosophie. Die einzige Möglichkeit, dieses Szenario erfolgreich zu vermeiden, besteht meiner Meinung nach darin, entweder allwissend zu sein oder den Kunden stark einzubeziehen und früh/oft zu veröffentlichen, um so schnell wie möglich Feedback zu erhalten. Auf diese Weise kann man die Software entwickeln, die der Kunde wirklich will, und nicht die Software, von der der Kunde sagt, dass er sie will.
Kunde: Das hätten Sie einbauen können!
Wir: Das stand nicht in der Spezifikation!
Kunde: Gesunder Menschenverstand!!
Wir: Wir versuchen nicht, über das hinauszugehen, was der Kunde angegeben hat - wir folgen der Spezifikation. Es ist genauso wichtig, nicht spezifizierte Funktionen NICHT zu implementieren, wie es wichtig ist, spezifizierte Funktionen zu implementieren. Unsere Kunden schätzen es, dass sie sich darauf verlassen können, dass wir die Spezifikation korrekt und vollständig, termingerecht und unter Einhaltung des Budgets umsetzen.
Wie andere sehr zu Recht betonen, ist die Situation fast immer komplexer als der einfache Austausch, den ich oben beschrieben habe.
Dies gilt jedoch nur, wenn der Implementierer über eine vom Kunden unterzeichnete Spezifikation verfügt, die im Wesentlichen eine Vereinbarung enthält, die besagt, dass die Software als vollständig gilt, sobald sie nachweislich alle in der Spezifikation genannten Merkmale implementiert, und dass alles, was darüber hinausgeht, außerhalb der Spezifikation und damit außerhalb des Vertrags liegt.
Auch der Vertrag selbst kann hier eine Rolle spielen - wenn Sie keinen unterzeichneten Vertrag haben, ist es egal, was in der Spezifikation steht - alles wurde bisher per Handschlag vereinbart, und das gesamte Geschäft (einschließlich der Bezahlung) kann bei Unzufriedenheit auf beiden Seiten den Bach runtergehen.
Aber wenn Sie einen Vertrag und eine Spezifikation haben und der Kunde beides gesehen und unterschrieben hat, dann hat er keinen Spielraum, Sie um weitere Schritte zu bitten.
Nun zu der Frage, ob Sie es umsetzen sollten:
GROSSARTIG! Sie haben ein Produkt geliefert und sie hatten nur eine Beschwerde. Implementieren Sie die Funktion, nennen Sie sie "kostenlos" (stellen Sie sicher, dass sie verstehen, dass Sie außerhalb der Spezifikation und des Vertrags arbeiten, und schicken Sie ihnen ausdrücklich eine Rechnung für die Arbeit, in der der Rabatt in Dollar ausgewiesen ist) und lassen Sie sie das Projekt als Ganzes abzeichnen.
Damit wird ausdrücklich nachgewiesen, dass das Projekt abgeschlossen ist, dass Sie mehr getan haben als Ihre Pflicht, und dass alle weiteren "Überraschungen" außerhalb des Vertrags/der Spezifikation liegen, was Ihnen ein gutes Gefühl gibt.
Wenn es sich um ein UI-Problem handelt, dann ist die Lage noch schwieriger.
Beschreibt die Spezifikation die Benutzeroberfläche hinreichend? Enthält sie Mockups? Ich würde es einem Kunden nicht übel nehmen, wenn er sich über die Benutzeroberfläche beschwert, wenn die Spezifikation das Layout und die Verwendung nicht sehr genau beschreibt und keine Modelle enthält.
Wie dem auch sei, ich denke, Sie können die Position des Kunden verstehen - wenn er nicht mit UI-Mockups gespielt hat, wird er vom Ergebnis enttäuscht sein - psychologisch gesehen gibt es keine Möglichkeit, dass Sie und Ihr Kunde dieselbe Idee im Kopf hatten (ganz zu schweigen von der Tatsache, dass der gesunde Menschenverstand das nicht tut!).
Wenn der Kunde zum ersten Mal darüber nachdenkt, die Benutzeroberfläche zu überprüfen, bevor die Arbeit abgeschlossen ist, dann ist es zumindest teilweise Ihre Schuld, weil Sie ihm nicht erklärt haben, wie man eine gute Benutzeroberfläche gestaltet. Es handelt sich um eine Schlüsselfunktion für ihre App, die sehr eng an ihre Vorstellungen gekoppelt ist - niemand kann in einer solchen Situation zufrieden sein, wenn sie ihre interne Darstellung nicht im Laufe der Zeit an die Realität angepasst haben.
Diese Diskrepanz lässt sich nur durch häufige Nutzer- und Kundentests beheben, an denen es offensichtlich mangelt. Dies ist ein Problem der Kundenaufklärung und -kommunikation, nicht der Erfüllung der Spezifikation.
-Adam
Rechnen Sie damit, dass sich der Umfang in letzter Minute ändert - das kommt immer vor, also seien Sie darauf vorbereitet.
Überprüfen Sie den Fortschritt regelmäßig mit dem Kunden, um Überraschungen zu vermeiden.
Vertrag: Funktionsspezifikation plus Zeit und Material mit anfänglicher Obergrenze (damit der Kunde das Gefühl hat, die Kontrolle zu haben). Wenn sich dann Änderungen ergeben, verhandeln Sie die Obergrenze bei Bedarf neu.
Niemals sagen, dass sie nicht haben können, was sie wollen. Sie können diese Antwort umsonst bekommen!
Immer Geben Sie ihnen ein wenig mehr, als sie verlangt haben, damit sie wissen, dass Sie eine positive Einstellung haben.
Sie sollten sich dem Kunden gegenüber so verhalten, als wären Sie im selben Team wie er. Lassen Sie es nicht zu, dass Sie juristisch als Gegner dargestellt werden.
Sie denken vielleicht, dass Auftragnehmer im Vergleich zu Arbeitnehmern nicht loyal sind. Zeigen Sie ihnen, dass Sie sich genauso für ihren Erfolg engagieren wie ihre Mitarbeiter, und Sie werden die Extrameile gehen.
Klassischer Fall...
Darauf gibt es keine eindeutige Antwort, aber es dreht sich alles um Kommunikation. Es hätten präventive Maßnahmen ergriffen werden müssen (z. B. wöchentliche Besprechungen oder ähnliches).
Sicherlich kann man nicht alles umsonst neu machen.
Es gibt zwei Möglichkeiten: Entweder man sagt ihnen, sie sollen sich verpissen, oder man kümmert sich um sie.
Wenn Sie sich entscheiden zu handeln:
Benutzen Sie Ihren gesunden Menschenverstand, es ist so üblich, dass es nicht einmal lustig ist.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
