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

13

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?

TCSGrad
quelle
20
Bei der Programmierung ist alles möglich. Denken Sie daran, dass "Ja" keine Antwort auf "Wie lange wird es dauern?" Ist.
Steven Evers
9
@ SnOrfus: Einige Probleme können einfach nicht gelöst werden. Wenn Sie anders denken, programmieren Sie eine Wettervorhersage, die Ihnen sagt, ob wir eine weiße Weihnacht haben werden.
Loren Pechtel
5
@Earlz: Das setzt voraus, dass das Universum deterministisch ist, was nicht unbedingt wahr ist.
Whatsisname
4
Entschuldigung, unmöglich. Das Wetter wird nach sieben bis zehn Tagen chaotisch. Es gibt eine sehr berühmte Zeitung zum Thema: „Berechenbarkeit: Löst die Flügelklappe eines Schmetterlings in Brasilien einen Tornado in Texas aus? von Edward Lorenz.
David Hammen
26
Wenn die Programmierer Versprechungen machen, die sie nicht einhalten können, was werden dann die Verkäufer tun?
JeffO

Antworten:

20

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?

David Hammen
quelle
2
+1 Ich habe diese Liste, die bereits verlinkt wurde, nicht durchgesehen. Gute Arbeit, um darauf hinzuweisen, dass es wirklich schreckliche Ratschläge gibt. Der Typ mag ein guter Entwickler sein, von dem ich keine Ahnung habe, aber er ist sich sicher, dass er das nicht ist. Dies ist im Allgemeinen kein gutes Zeichen.
Jimmy Hoffa
+1 - Ich sage Kunden niemals "Nein" (es sei denn, ich möchte sie nicht wiedersehen) "Nein" schließt die Ausgabe tot. Verwenden Sie Antworten, die es für weitere Diskussionen öffnen. zB "... aber ich könnte dir 90% von dem geben, was du willst, für 10% der Kosten" oder "... aber ich könnte es auf diese Weise implementieren und dir eine Lösung geben, die auf diese Weise funktioniert ..."
Mattnz
1
@mattnz - Es ist schwer "Nein" zu sagen, aber manchmal ist es nötig. "Können Sie diese Änderung bis morgen erledigen?" Nun, nein. Aber ich kann es bis Ende der Woche bekommen. "Könnten Sie eine Monte-Carlo-Analyse durchführen, bei der jede dieser mehreren hundert Kontrollvariablen zufällig pro Lauf variiert wurde?" Das ist derjenige, der die Antwort "In welchem ​​Jahrtausend willst du das Ergebnis" erhalten hat. Ich diskutierte den Fluch der Dimensionalität und schlug vor, diese Liste auf etwas Vernünftiges zu reduzieren. Wie Sie Nein sagen, ist wichtig, aber manchmal müssen Sie Nein sagen. Diplomatisch natürlich.
David Hammen
Eine Fehlerquote von 10% wäre eine MASSIVE Verbesserung gegenüber der derzeitigen durchschnittlichen Erfolgsquote bei der Softwarebereitstellung.
Graham
In Bezug auf die Analogie zur Flugzeuglandung - Flugzeuge werden jeden Tag sicher gelandet. Wenn ich Pilot bin und auf die Frage, ob ich mein Flugzeug sicher landen kann, antworte "Lassen Sie mich darauf zurückkommen", dann bringt mir das kein Karma für die Passagiere. Auch wenn ich weiß, dass die Wahrscheinlichkeit eines Landeunfalls gering ist, ist dies ein gutes Beispiel dafür, dass es wichtiger ist, Vertrauen in die Fähigkeiten eines Piloten zu haben, als sich auf die geringe Wahrscheinlichkeit eines Misserfolgs zu konzentrieren.
Cliff
24

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.

Jeanne Boyarsky
quelle
17
Oft ist es besser, sich von einem Kunden sagen zu lassen, welches Problem er lösen möchte, als sich mit der gewünschten Lösung auseinanderzusetzen . Holen Sie sich das Problem .. und teilen Sie ihnen die Lösung.
Simon Whitehead
+1 und mehr - zwei sehr gute Punkte, die Sie machen - Sagen Sie niemals "Nein" und verlieren Sie nicht die Glaubwürdigkeit bei Ihrem Kunden.
Mattnz
+1 "Der Kunde wird Sie respektieren, wenn Sie ehrlich sind". Diese Aussage ist so wahr und Gold wert. Seien Sie ehrlich, wenn Sie dem Kunden Optionen präsentieren. Sagen Sie ihnen einfach, dass es sich bei dem, wonach sie fragen, nicht um ein vorgefertigtes Widget handelt, das Sie kaufen und einbinden können. Lassen Sie sie wissen, dass sie nach einer maßgeschneiderten Lösung fragen und dass maßgeschneiderte Software sehr teuer ist. Dies führt normalerweise dazu, dass eine von zwei Situationen eintritt. 1.) Sie wollen eine kostengünstige Alternative. 2.) Sie sind bereit, für die kundenspezifische Lösung zu bezahlen. In jedem Fall ist es ein Gewinn / Gewinn.
Michael Riley - AKA Gunny
6

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.

Joshua Burns
quelle
6

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

DeveloperDon
quelle
+1 für die Bezugnahme auf einen Ethikkodex zur Beantwortung einer Ethikfrage.
Jay Elston
5

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.

Rechnung
quelle
4

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.

Cliff
quelle
3

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.

Tulains Córdova
quelle
1

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.

Ronin
quelle
1
Das ist der beste Weg, um ... Benutzer unglücklich zu machen. In den
meisten
3
Ehrlich gesagt, für einige In-House-Entwickler ist dies keine schreckliche Idee. In-House-Arbeiten werden in der Regel nicht direkt abgerechnet (IT ist nur ein Teil des allgemeinen Budgets), und Sie können mit Mistanfragen überfordert sein, weil die Anfragenden kein Geld haben, wenn sie Sie mit Arbeit spammen.
Graham