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?
Dies ist einer der vielen Nachteile einer Festpreisregelung. Jedes Mal, wenn sich die geschäftlichen Anforderungen oder Prioritäten ändern oder wenn es auch nur ein Missverständnis gibt, führt dies zu einer unangenehmen Situation wie dieser oder dazu, dass ein Anwalt eingeschaltet wird. Wenn Sie eine Vereinbarung haben, bei der Sie für die Entwicklungszeit bezahlt werden, können Sie immer auf jede Änderung reagieren und werden für die Zeit bezahlt, die Sie für die Änderung benötigen. Außerdem schließt eine Vereinbarung, bei der nach Stunden bezahlt wird, nicht aus, dass man einen Plan hat oder einen Kostenvoranschlag macht.
Wenn Sie sich jedoch in einer Situation befinden, in der Sie ein festes Gebot abgeben müssen, haben Sie folgende Möglichkeiten: 1) Sie machen es zu zusätzlichen Kosten. 2) Sie machen es kostenlos. 3) Tun Sie es nicht.
Option 3 ist die schlechteste, und Option 1 ist die beste. Wenn Sie ein gutes Vertrauensverhältnis und eine gute Kommunikation mit dem Kunden haben, ist es in der Regel einfach, zu Option 1 zu gelangen. Wenn die Beziehung schlecht ist, dann haben Sie größere Probleme. In diesem Fall sollten Sie versuchen, Laien zu vermeiden.
Ein letzter Punkt - jedes Projekt, das einen so genannten "Liefertermin" hat, stößt unweigerlich auf das beschriebene Problem. Bei Projekten mit diesem Termin zieht man sich in der Regel für mehrere Monate in eine Höhle zurück, um im Verborgenen zu entwickeln, und stellt dann das Produkt auf einmal vor den Beteiligten vor. Das ist abrupt und lässt viel Zeit, damit die Erwartungen der Kunden und das tatsächliche Produkt auseinanderdriften. Wenn Sie stattdessen Zwischenversionen des Produkts zeigen und alle paar Wochen Feedback einholen, geschehen zwei Dinge. Erstens erhalten Sie besseres Feedback, minimieren Missverständnisse und stellen ein besseres Produkt her. Zweitens gibt es keinen einzigen Zeitpunkt, an dem eine große Menge an Erwartungen gestellt wird. Der potenzielle Unterschied zwischen den Vorstellungen des Kunden und dem, was tatsächlich existiert, ist viel geringer. Keine Überraschungen.
Viel Glück!
Nun, sie wurde nicht erfolgreich zugestellt. Irgendwo auf der Strecke gab es eine Fehlkommunikation. Ohne die Einzelheiten zu kennen, würde ich vermuten, dass es sich hierbei nicht um ein vom Entwickler verursachtes Problem handelt und dass die Schuld dafür wahrscheinlich nicht beim Kunden liegt - die Anforderungserhebung war unzureichend. Dies ist ein klassisches Beispiel dafür, was passiert, wenn auf der Softwareseite keine Domänenexperten vorhanden sind oder der Anforderungserfassungsprozess nicht alles tut, was er tun könnte...
Wenn ich es wäre, würde ich das Problem beheben und herausfinden, wie man ähnliche Probleme in Zukunft vermeiden kann.
Wie Sie damit umgehen, kann sehr wohl über die Zukunft dieses Vertrags/Geschäfts mit dem Kunden entscheiden. Die Übernahme von Verantwortung und die Behebung des Problems sind eine große Chance für Ihr Unternehmen.
EDIT: Dies ist ein guter Zeitpunkt, um zu bewerten, wie es dazu gekommen ist, um es zu korrigieren. Einige Unternehmen entscheiden sich dafür, alles, was sie tun, völlig neu zu gestalten, was meiner Meinung nach ein Fehler ist. Es zu ignorieren auch. Den Menschen die Schuld an dem Problem zu geben, ist ebenfalls ein Fehler.
Es ist ein guter Zeitpunkt, um zu erläutern, wie es dazu gekommen ist, wie der Vorgang abläuft und wie er vielleicht hätte verhindert werden können. Ich würde keine großen Änderungen an den Regeln oder Verfahren vornehmen - aber es ist eine gute Sache, Leitlinien für die künftige Arbeit aufzustellen. Ihr Unternehmen hat eine klare Lektion über einen Mangel erhalten. Wenn Sie die Gelegenheit verpassen, dieses Problem zu beheben und Ihren Prozess zu korrigieren, haben Sie eine gute Chance vertan.
"Wie reagieren Sie?"
Frage 1 - Wollen Sie die Beziehung zu diesem Kunden fortsetzen? Ganz im Ernst. Wenn der Kunde behauptet, dass nicht spezifizierte Funktionen "gesunder Menschenverstand" sind, ist dies vielleicht keine gute Beziehung, die man aufrechterhalten oder ausbauen sollte.
Wenn Sie sich ausklinken wollen, dann ist das einfach. Bitten Sie sie, jeden Teil der Spezifikation zu markieren, den Sie nicht erfüllt haben, und spielen Sie dieses Spiel mit. Fordern Sie spezifische Testkriterien für jede fehlende Funktion. Ziehen Sie die Zähne. Seien Sie konfrontativ, wenn Sie feststellen, was fehlt. Fragen Sie nicht nach dem Warum. Fragen Sie einfach nach allen Details. Das ist langsam und unangenehm. Aber Sie wollen es sowieso nicht.
Wenn Sie sich engagieren wollen, dann müssen Sie die Beziehung ändern. Derzeit haben Sie einen passiv-aggressiven Kunden. Er wird nicht sagen, was er will, aber er wird sagen, was er nicht will.
Vielleicht ist das eine Gewohnheit von ihnen; vielleicht gewinnen sie auf diese Weise Zugeständnisse. Oder es handelt sich einfach um eine schlampige Spezifizierung ihrerseits.
Wenn Sie die Beziehung wollen, hat Ihre Reaktion zwei Seiten.
Kurzfristig. Besorgen Sie etwas, mit dem sie zufrieden sind. Sie müssen spezifische Änderungen identifizieren. Sie müssen jede Änderung mit den "Kosten" und der "Übereinstimmung mit der Spezifikation" bewerten.
ZiG, mit diesem Problem hatte ich an meiner derzeitigen Arbeitsstelle schon mehrmals zu tun. Meine Gruppe (3 Entwickler) versucht, die Dinge auf agile Weise anzugehen. Wir sind daran gewöhnt, dass wir mitten im Prozess und sogar in letzter Sekunde Anfragen erhalten (die wir dann von Fall zu Fall behandeln).
Wir machen jedoch deutlich, dass die Ressourcen (insbesondere die Zeit) begrenzt sind, und wenn es nicht in der Spezifikation steht, können wir keine Versprechungen machen. Wenn es als wichtig erachtet wird und nicht in die aktuelle Version passt, planen wir in der Regel eine Nachfolgeversion. Wenn es nicht wichtig ist, kommt es auf eine Liste.
Eine Sache, die ich festgestellt habe, ist, dass man Benutzer dazu bringen kann, Spec S zum Zeitpunkt T zuzustimmen. Zum Zeitpunkt T + N kann es jedoch schwieriger sein, sie dazu zu bringen, sich daran zu erinnern, dass sie Spec S zugestimmt haben, oder sie dazu zu bringen, zu bestätigen, dass sie es getan haben (mit der Dokumentation, die Sie aufbewahrt haben, hoffe ich!).
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.
