Sollten Sie versprechen, eine Funktion bereitzustellen, bei der Sie sich nicht sicher sind, ob sie implementiert werden kann?

In einem Artikel von HN bin ich auf folgenden Rat gestoßen:

Sagen Sie Ihrem Kunden / Benutzer immer "Ja", auch wenn Sie sich nicht sicher sind. In 90% der Fälle werden Sie einen Weg finden, dies zu tun. In 10% der Fälle gehen Sie zurück und entschuldigen sich. Kleiner Preis für großes persönliches Wachstum

Aber ich habe immer gedacht, dass man eine Machbarkeitsanalyse machen sollte, bevor man einem Kunden / Benutzer irgendwelche Versprechungen macht, damit er zu keinem Zeitpunkt in die Irre geführt wird. Unter welchen Umständen sollte der obige Hinweis dann anwendbar sein?

Dies ist die zweite Frage in kurzer Folge, die von diesem Artikel ausgelöst wird.

• Guter Programmierer: Ich optimiere Code. Besserer Programmierer: Ich strukturiere Daten. Bester Programmierer: Was ist der Unterschied?
  Hierfür gibt es einen anderen Namen: vorzeitige Optimierung.

• Verwenden Sie niemals frühe Ausfahrten.
  Das ist die Regel "Single Point of Entry / Single Point of Exit". Es ist ein Patch über das eigentliche Problem, das darin besteht, dass ein vorzeitiges Beenden ein Chaos hinterlassen kann. Die richtige Regel lautet "Aufräumen". Eine noch bessere Regel ist die Verwendung von Datenkonstrukten, die nacheinander bereinigt werden, damit sich der Programmierer keine Sorgen mehr über die Bereinigung seines Schmutzes machen muss.

• Und jetzt sagen Sie Ihrem Kunden / Benutzer immer "Ja", auch wenn Sie sich nicht sicher sind. In 90% der Fälle werden Sie einen Weg finden, dies zu tun.
  Auch das ist ein unglaublich schlechter Rat.

Manchmal muss Ihrem Kunden nein gesagt werden, oder "In welchem ​​Jahrtausend möchten Sie das?" Versprechen Sie nichts, was Ihre Architektur zerstört, das weitaus mehr kostet, als der Kunde bereit ist, es auszugeben, oder dass Sie keine Ahnung haben, wie Sie es erreichen können. Sie kennen die Technologie, nicht den Kunden. Wenn Sie nicht wissen, wie es geht, sagen Sie nicht, dass Sie es können. Wenn Sie sich nicht sicher sind, sagen Sie, Sie brauchen Zeit, um zu untersuchen, ob dies möglich ist. Es ist besser, ehrlich zu sein, und es wird Sie von Ärger fernhalten.

Kunden werden schnell zu Ex-Kunden, wenn Sie Ihre Versprechen nicht einhalten können. Eine Ausfallrate von 10% mag klein klingen, aber es sind 10%, auf die sich Ihre Kunden konzentrieren werden. Manchmal klagen sie, wenn Sie nicht halten, was Sie versprochen haben. Das willst du wirklich nicht. Ein anderes Mal können Sie, wenn Sie sicherstellen, dass Sie ein Versprechen einhalten, bankrott gehen, verrückt werden oder Ihren Ehepartner verlieren, weil Sie 18-Stunden-Tage arbeiten. Das willst du auch nicht.

Stellen Sie sich das so vor: Was würde Ihrer Meinung nach der Luftfahrtindustrie passieren, wenn 90% aller Flugzeuglandungen erfolgreich wären? Denken Sie, dass ein Zurückgehen und sich für die 10% entschuldigen, die abgestürzt sind, alles regeln würde?

Es wäre besser zu sagen "Ich denke, das kann getan werden". oder "Ich werde nachsehen und mich bei Ihnen melden". Ich hatte mal wo ich gesagt habe nein oder gegen etwas vorgeschlagen. Wenn der Kunde "eine browserbasierte Anwendung möchte, die funktioniert, ohne jemals mit dem Internet verbunden zu sein und taktiles Feedback verwendet", ist dies wahrscheinlich möglich. Aber es ist teuer und es wäre sinnvoller zu diskutieren, was die tatsächlichen Bedürfnisse sind.

Der Kunde wird Sie respektieren, wenn Sie ehrlich sind. In den Ratschlägen in der Frage liegt die Person in 10% der Fälle falsch. Wenn ich mit jemandem zusammenarbeite, der jedes zehnte Mal routinemäßig Unrecht hat, werde ich ihm / ihr überhaupt nicht vertrauen. Das ist eine schreckliche Bilanz.

Den Mond zu versprechen und einen Stein zu liefern, ist eine Art Verkäufer-Ansatz, der nicht toleriert werden sollte. Wenn Sie nicht wissen, ob es möglich ist, recherchieren Sie es. Oder geben Sie ihnen ein Angebot über die Zeit, die Sie benötigen, um es zu untersuchen. Auf diese Weise versprechen Sie nichts, was Sie nicht liefern können, und werden dennoch für die Zeit bezahlt, die Sie für die Prüfung benötigen.

Diese Frage wurde formal untersucht und wird von der gemeinsam erstellten IEEE Computer Society / dem ACM Code of Ethics behandelt .

2.01. Bieten Sie Service in ihren Kompetenzbereichen an und gehen Sie ehrlich und offen mit Einschränkungen in Bezug auf Erfahrung und Ausbildung um.

3.04. Stellen Sie sicher, dass sie für jedes Projekt qualifiziert sind, an dem sie arbeiten, oder schlagen Sie vor, mit einer geeigneten Kombination aus Ausbildung, Training und Erfahrung zu arbeiten.

3,09. Gewährleistung realistischer quantitativer Schätzungen von Kosten, Zeitplanung, Personal, Qualität und Ergebnissen für jedes Projekt, an dem sie arbeiten oder das sie arbeiten möchten, und Bereitstellung einer Unsicherheitsbewertung dieser Schätzungen.

5,05. Gewährleistung realistischer quantitativer Schätzungen von Kosten, Zeitplanung, Personal, Qualität und Ergebnissen für jedes Projekt, an dem sie arbeiten oder das sie arbeiten möchten, und Bereitstellung einer Unsicherheitsbewertung dieser Schätzungen.

Es gibt sicherlich geschäftliche und rechtliche Konsequenzen, wenn Sie etwas versprechen, das Sie nicht einhalten können. In der Regel kommen diese vom Kunden, der an einen anderen Ort geht, die Zahlung verweigert oder Ihr Unternehmen verklagt. Wenn Sie mit anderen in einer Partnerschaft stehen, können diese Schadensersatzklagen erheben, wenn Ihr Teil nicht geliefert wird. Klagen können sogar von Wettbewerbern kommen.

Es gibt eine Geschichte aus der Anfangszeit von Supercomputern, in der Seymour Cray und ein Team von Control Data Corporation kurz vor der Markteinführung eines Produkts standen, und ein anderes sehr großes Computerunternehmen teilte seinen Kunden mit, dass es kurz vor der Markteinführung stehe. Die Lüge kostete CDC viel Geld und wurde zu einer Klage, in der die große Firma keine glaubwürdigen Beweise für ihre Behauptungen vorlegen konnte. Das Ergebnis war eine damals große Siedlung im Wert von 80 Millionen Dollar (1970: 223 Millionen Dollar, 2012 inflationsbereinigt). Hier können Sie darüber lesen:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

Bei genügend Zeit, Ressourcen und Flexibilität rund um die Definition von Erfolg ist alles möglich. Das weiße x-mass Beispiel ist einfach, wenn Sie nur eine Genauigkeit von mehr als 50% und den geografischen Standort des Benutzers sowie ein wenig statistische Daten wünschen.

Die eigentliche erste Frage in den meisten Projekten ist nicht, ob etwas möglich ist, sondern ob es unter bestimmten Umständen sinnvoll ist.

Fügt die Funktion genug Wert hinzu, um die Kosten des Versuchs zu rechtfertigen?

Selbst wenn die Idee ziemlich großartig wäre, wenn sie eine lange Entwicklungszeit oder den Erwerb exotischerer Hardware erfordert, ist es für den Kunden in den meisten Fällen besser, dies im Voraus zu wissen und die Konversation dann auf vernünftigere Ziele zurückzulenken.

Wenn jemand verrückt genug ist, Ihnen einen Blankoscheck und keine Frist zu geben, dann sagen Sie ihm auf jeden Fall, dass alles möglich ist, lassen Sie ihn einfach wissen, dass Sie mehrere der Technologien erfinden und verbreiten müssen, die zur Erreichung des Ziels auf dem Weg erforderlich sind.

Auf der anderen Seite gibt es beim Umgang mit vernünftigen Kunden mit vernünftigen Ressourcen manchmal nichts Schlimmeres, als dem Kunden mitzuteilen, dass einige Funktionen gekürzt werden müssen, nachdem Sie dem zugestimmt haben, da sie möglicherweise bereits abgelaufen sind und Zeit / Geld / Ressourcen für Werbung oder Marketing aufgewendet haben Es zu dokumentieren und dass 10% die Sache gewesen sein könnten, die das Projekt in erster Linie grünes Licht gegeben hat. Wenn Sie in eine dieser Situationen geraten und gerade einen Kunden verloren haben, haben Sie höchstwahrscheinlich in einem ganzen Markt einen sehr schlechten Ruf erlangt.

Devil's Advocate spielen

Aufgrund ihrer analytischen Denkweise können Techniker davon ausgehen, dass ihre Leistung in erster Linie anhand einer Scorecard aus abgeschlossenen und zugesagten Anforderungen beurteilt wird. In der Praxis ist diese jedoch nicht so ausgeprägt und trocken.

Noch bevor die Entwicklung beginnt, fangen Kunden an, sich auf der Grundlage ihres Vertrauens und ihrer Bereitschaft, sich zu engagieren, eine Meinung über die Leistung eines Teams zu bilden.

Ein Grund dafür ist, dass es für Kunden schwierig sein kann, zu beurteilen, ob das Zögern eines Auftragnehmers darauf zurückzuführen ist, dass die Anfrage schwierig ist oder die Fähigkeiten des Auftragnehmers unzureichend sind.

Da es keine absoluten Kriterien für die Messung der Schwierigkeit einer Anfrage gibt, ist es für den Kunden oft wichtiger, dass der Auftragnehmer 100% seines Aufwands unternimmt und nicht, ob 90% oder 100% der Anfragen erfüllt werden.

Angenommen, der Kunde muss zwischen zwei Szenarien wählen:

Auftragnehmer A :

• Sicher können sie auf alle Anfragen liefern
• Ergebnis: 90% der Anfragen zugestellt
• Der Kunde ist erfreut, dass der Auftragnehmer sich zu 100% bemüht hat
• Der Kunde nimmt zur Kenntnis, dass die unvollständigen Anfragen auf unvorhergesehene Probleme zurückzuführen sind, die möglicherweise außerhalb der Kontrolle des Auftragnehmers liegen

Auftragnehmer B :

• Verpflichtet sich, 90% der Anfragen zu erfüllen. Nicht zuversichtlich, dass sie die restlichen 10% liefern können
• Ergebnis: 90% der Anfragen zugestellt
• Der Kunde ist enttäuscht, dass der Auftragnehmer nicht versucht hat , die anderen 10% seiner Anfragen zu bearbeiten
• Der Kunde geht davon aus, dass die nicht erledigten 10% der Anfragen auf mangelnden Aufwand oder mangelnde Fähigkeiten des Auftragnehmers zurückzuführen sind

In beiden Szenarien wurde die gleiche Anzahl von Anforderungen zugestellt. Der Kunde war jedoch der Ansicht, dass der "übertriebene" Auftragnehmer A sich zu 100% anstrengte, und bestätigte damit, dass die verbleibenden Anforderungen wirklich schwierig waren, was dem Auftragnehmer A zu Gute kommt.

Auf der anderen Seite hatte der Kunde das Gefühl, dass Auftragnehmer B keine 100% igen Anstrengungen unternahm und seine Unfähigkeit, alle Anforderungen zu erfüllen, entweder auf mangelnden Aufwand oder mangelnde Fähigkeiten von Auftragnehmer B zurückzuführen war.

Haftungsausschluss: Ich befürworte keine Überbindung als Strategie. Dies ist nur eine Beobachtung einer möglichen realen Situation, in der Überbindung positive Ergebnisse haben könnte.

Sie sollten sie bitten, Ihnen Zeit zu geben, um eine "Spike-Lösung" zu erstellen .

Bei einer Spike-Lösung handelt es sich um ein kleines Programm, mit dessen Hilfe Sie herausfinden können, wie oder ob dies überhaupt möglich ist, was in einem Projekt zu Unsicherheiten führt.

Angenommen, Sie haben noch nie programmgesteuert SMS gesendet, aber irgendwie wissen Sie, dass dies möglich ist. Eine Spitzenlösung wäre, ein kleines Programm zu erstellen, das eine SMS sendet. Auf diese Weise ist es keine Unsicherheit mehr und Sie können weitere Schätzungen zur Machbarkeit vornehmen.

In der Dokumentation zu eXtreme Programming heißt es dazu:

Erstellen Sie Spitzenlösungen, um Antworten auf schwierige technische oder gestalterische Probleme zu finden. Eine Spike-Lösung ist ein sehr einfaches Programm, um nach möglichen Lösungen zu suchen. Erstellen Sie den Spike, um nur das zu untersuchende Problem zu beheben, und ignorieren Sie alle anderen Bedenken. Die meisten Spikes sind nicht gut genug, um sie aufzubewahren. Erwarten Sie also, sie wegzuwerfen. Ziel ist es, das Risiko eines technischen Problems zu verringern oder die Zuverlässigkeit der Schätzung einer User Story zu erhöhen. Wenn eine technische Schwierigkeit die Entwicklung des Systems aufzuhalten droht, setzen Sie ein oder zwei Wochen lang zwei Entwickler für das Problem ein und verringern Sie das potenzielle Risiko.

Wenn ein Benutzer etwas anfordert, sollten Sie ihn meiner Erfahrung nach nach einer detaillierten Spezifikation fragen, was der Benutzer wirklich möchte oder braucht. Meistens werden Sie nie wieder von der Anfrage erfahren.