Denkfallen im Digital Business - Teil 1

Leider ist das Wesen des menschlichen Denkens nicht unbedingt rational und oftmals schleichen sich bei uns Denkfallen ein, welche wir lieber vermeiden möchten. Auch im Kontext der Softwareentwicklung gibt es etliche Denkfallen, welche zu falschen Annahmen und teilweise ziemlich kostspieligen Entscheidungen führen können. In diesem Beitrag geben wir Tipps, wie man diese Denkfehler erkennt und im besten Fall vermeidet. 

Die Idee, über das Thema von Denkfehler in der Softwareentwicklung einen Blog zu schreiben, kam mir aufgrund des Buches von Rolf Dobelli mit dem Titel “Die Kunst des klaren Denkens”. In diesem Buch finden sich 52 Denkfehler, welche mir unterhaltsam und verständlich einige spannende Erkenntnisse lieferten. 

Weil es ziemlich viele solcher Denkfallen im „digital Business“ gibt, haben wir den Blog in zwei Teile aufgeteilt. Hier also nun die ersten 6 - Teil 2 folgt dann in naher Zukunft.

1. Der Fallstrick der Selbstüberschätzung: Overconfidence-Bias

Sich selbst überschätzen ist ein Denkfehler, den wir in der App Entwicklung genauso wie im Alltag oft antreffen. Man nutzt eine App oder sonstige bekannte Software und denkt “das kann ich doch viel besser!” Dieser Fehleinschätzung passiert nicht nur unseren Kund*innen sondern genauso uns selbst, gerade wenn es um die genaue Einschätzung von Projektkosten, Dauer oder dem potenziellen Erfolg von digitalen Produkten und Services geht. 

Beispiele der Selbstüberschätzung in Software Projekten

Nicht selten erhalten wir Anfragen für die App Entwicklung mit Statements wie: “Ich weiss wie man z.B. Facebook oder Instagram viel besser machen könnte, man müsste nur dies oder jenes anfügen und keine Daten sammeln. Bitte geben sie mir doch einen Preis an wie teuer diese bessere Version von Facebook sein wird”.

Dass Facebook mehr als 60 Millionen Zeilen Code geschrieben hat und man für eine funktionierende Plattform eine sehr hohe Anzahl an User*innen braucht, um überhaupt einen Mehrwert im Kontext der Community zu bieten, ist vielen wohl nicht klar. 

Nicht nur unsere Kund*innen überschätzen ihr Wissen und ihre Fähigkeiten, sondern auch wir als Projektmanager*innen, Software Entwickler*innen und Design-Spezialist*innen leiden hin und wieder unter diesem Phänomen. Gerade wenn es darum geht, die Entwicklungszeit für ein neues Softwareprojekt realistisch einzuschätzen, verfallen wir nicht selten der Annahme, dass alle Arbeiten effizient und effektiv erledigt werden können, anstatt vom realistischen Fall auszugehen, dass quasi in jedem Projekt unvorhersehbare Herausforderungen auftauchen, welche dann mehr Zeit als angenommen benötigen. 

Im Falle der Aufwandschätzung kommt nebst dem Overconfidence-Effekt auch noch die “Incentive-Superresponse-Tendenz” dazu, also die Tendenz, auf Anreizsysteme zu reagieren und dabei den persönlichen Nutzen zu maximieren. Die Chancen auf einen neuen Auftrag liegen bei einer knapperen Schätzung gefühlt höher, als wenn wir eine grosse Reserve für Unvorhergesehenes einrechnen. Dies kann im schlechtesten Fall zu einer Enttäuschung auf beiden Seiten führen. Für das Entwicklungsteam wird es zu Planungsänderungen und Diskussionen führen, aus Kundensicht kann dies zu Verzögerungen und Mehrkosten, also einem schlechten Kundenerlebnis führen.

Möglichkeiten zur Reduktion des Overconfidence-Effektes: 

• Eher vom pessimistischen als vom optimistischen Szenario ausgehen

• Diversität: Unterschiedliche Menschen schätzen Dinge unterschiedlich ein. Der Denkfehler kann oft vermieden werden, wenn man die eigenen Annahmen durch weitere Personen validieren lässt. Im besten Fall, ohne dass die eigene Konklusion bereits im vorab kommuniziert wird. 

• Hypothesen, auf denen die Annahmen basieren, explizit machen und durch klare quantitative und qualitative Ziele und Messgrössen seriös testen. 

• Als Kund*in sollte man keinen Druck auf eine seriös erstellte Aufwandschätzung des Entwicklungsteams ausüben. Wieso sollte jemand viel höher schätzen als nötig? Die Konkurrenz im Markt ist zu gross, als dass sich jemand unrealistisch hohe Schätzungen leisten kann. Unsere Erfahrung zeigt, dass stark verhandelte Preise/Schätzungen am Ende des Projektes in der Regel trotzdem wieder beim Ursprungspreis landen.

• Eine Reserve für Unvorhergesehenes fix ins Budget einrechnen, um ein realistisches Bild der Kosten zu erhalten.  

2. Fallstrick der versunkenen Kosten: Sunk Cost Fallacy 

So unangenehm es tönen mag, aber oftmals wäre es das Beste, wenn wir es hinkriegen würden, die Vergangenheit zu vergessen und ohne diese ganzen vergangenen Aufwände im Kopf nur die Zukunftsaussichten in Betracht zu ziehen. 

Wir Menschen möchten konsistent erscheinen, weshalb wir uns irrational verhalten, wenn sich ein „Ausreisser“ oder ein Widerspruch anbahnt. Durch ein konsistentes Verhalten möchten wir Glaubwürdigkeit und Vertrauen schaffen. Ein Softwareprojekt in der Mitte des Vorhabens abzubrechen, weil man selbst gesetzte Ziele nicht erreicht hat, ist ein klarer Widerspruch zu einer ansonsten konsistenten Leistung. Ein sinnloses Projekt weiter zu führen zögert jedoch lediglich den Schmerz heraus. Der Spruch: „Lieber ein Ende mit Schrecken als Schrecken ohne Ende“ sollte man sich also definitiv zu Herzen nehmen. 

Allzu oft geben wir den vergangenen Kosten einen Wert bei der Entscheidung über die Zukunft eines Vorhabens. Obwohl Ziele bei Weitem nicht erreicht wurden, sagt man sich: „Nun sind wir schon so weit gekommen und haben so viel Zeit in dieses Projekt investiert, dass wir nicht einfach abbrechen können.” Der Misserfolg wird hierbei in den allermeisten Fällen jedoch nur herausgezögert und verteuert. 

Tipps für die Vermeidung der Sunk Cost Fallacy:

• Von Beginn an klare, realistische und messbare Ziele setzen und anhand deren Erreichung entscheiden

• Lieber früher als später in den sauren Apfel beissen

• Neutrale Personen, welche Objektivität mitbringen, in die Entscheidung involvieren

• Jeweils überlegen, welche Alternativen möglich wären, wenn das geplante Budget in andere Projekte / Produkte investiert würde

3. Die Bestätigungs-Denkfalle: Confirmation Bias

Ein allgegenwärtiger Denkfehler den wir wohl alle kennen - und trotzdem regelmässig davon erwischt werden. 

Beispiel aus dem öffentlichen Diskurs

Natürlich gibt es immer verschiedene Meinungen und Positionen. Spannend ist in der öffentlichen Diskussion aber oft zu sehen, wie sich alle Positionen mit “Beweisen” und “Fakten” bewaffnet, ihrer eigenen Meinung sehr sicher sind. Jede Seite findet im Netz genügend Material, welches Argumente für die eine oder andere Seite bietet. Wir lieben es, Videos, Blogs und Posts zu finden, welche unsere eigene Meinung bestätigen und ignorieren in aller Regel die gegenteiligen Fakten und Meinungen. Wenn es dann mal was gibt, das wir selbst nicht “wegleugnen” können, dann nennen wir es Spezial- oder Einzelfall. 

Beispiel aus der Softwareentwicklung

Auf allen Ebenen der Softwaretests haben wir das Ziel, den Code vollumfänglich zu testen, um Softwarefehler zu entdecken und dadurch die Qualität der Software zu verbessern. Softwareentwickler*innen und -tester*innen neigen jedoch dazu, eher positive als negative Tests durchzuführen, weil ein negativer Test keine Bestätigung, sondern eben eine Widerlegung ist. Dies ist auf das als Confirmation Bias bekannte Phänomen zurückzuführen, welches bei den Menschen zur Tendenz führt, die eigenen Hypothesen lieber zu bestätigen, anstatt zu versuchen, sie zu widerlegen. Unter anderem deshalb legen wir so viel Wert darauf, ein so weit als möglich unabhängiges QA-Team zu haben.

Beispiel des Confirmation Bias bei App-preneurs

Viele App Anbieter*innen, welche eine Produkt- oder Marketing-Verantwortlichkeit innehaben, sind viel offener für Hinweise, welche ihren Annahmen, Strategien und Massnahmen recht geben. Die Disconfirming-Evidence (Dinge, die gegen meine Annahmen sprechen), wird in der Regel nicht gesucht, oder falls vorhanden lieber nicht beachtet. Konkret heisst dies, dass ich als App Manager*in alle möglichen Hinweise, die für den Erfolg der App oder meine Massnahmen sprechen, viel lieber sammle und breit kommuniziere als alle Hinweise, die gegen meinen Erfolg sprechen. 

Ein guter Lösungsansatz von Albert Einstein

Auch Albert Einstein kannte dieses Phänomen respektive diesen Denkfehler gut und hatte ein ziemlich pragmatisches Rezept dafür: Er verbrachte möglichst viel Zeit damit, genau diese “Disconfirming-Evidences” (widerlegende Beweise) zu finden und jeden einzelnen von ihnen sehr ernst zu nehmen, um damit allenfalls die eigenen Thesen zu widerlegen, bevor dies jemand anderes tun konnte. Genauso sollten wir auch denken.

4. Authority Bias: die Autoritäts-Befangenheit

Gemäss Stanley Milgrams Experiment in 1961 tendieren Menschen dazu, der Meinung von “Expert*innen oder Spezialist*innen” oder einer “autoritär” eingeschätzten Person einen höheren Wert zuzuschreiben. Gerade im Digitalbusiness oder rund um die digitale Transformation von Gesellschaft und Wirtschaft, gibt es extrem viele sogenannte “Expert*innen und Spezialist*innen”, welche dann für viel Geld ihr Halbwissen an unwissende Marktteilnehmende in Form von Beratungsmandaten oder Publikationen verkaufen. 

Vielleicht kann sich jemand an die Aussage von Mark Zuckerberg in 2016 erinnern, welche das Ende von nativen Apps und dafür den rasanten Aufstieg von smarten Chatbots voraussagte. Sehr viele Marktteilnehmer*innen glaubten dies sofort und starteten mit der Entwicklung von Chatbots oder gründeten Firmen, welche solche Chatbots für andere entwickeln. Rund sechs Jahre danach kann man wohl sagen, dass dieses Szenario nicht Realität wurde. Der App Markt wächst immer noch stark und die Anzahl an wirklich nützlichen und weit verbreiteten Chatbots ist doch sehr überschaubar. Auch wir haben damals das Thema in unserem Blog aufgenommen und über Chatbots geschrieben - hier gehts zum Beitrag.  

Ich glaube, dass wir diesen Blog ohne die Statements von Mr. Facebook nicht geschrieben hätten.  

Die Autoritäts-Befangenheit wird häufig durch den Glauben verschärft, dass Gehorsam ein korrektes Verhalten darstellt. Um dieser Befangenheit entgegenzuwirken, sollte man eigene Annahmen überprüfen und sich fragen, ob eine dieser Annahmen aufgrund einer Befangenheit gegenüber einer Autorität getroffen wurde. Diese Autorität kann die eigene Organisation, ein anerkannter Player wie Google oder vielleicht sogar das eigene frühere ich sein. In jedem Fall sollte man die Autorität hinterfragen, anstatt sich blind auf eine möglicherweise voreingenommene Meinung zu verlassen.

Gerade auch bei neuen trendigen und gehypten Themen, wie zum Beispiel der Blockchain und Kryptowährungen, beobachten wir dieser Authority Bias oft. In vielen Fällen stützen wir unsere eigenen Meinungen auf Aussagen und Meinungen von anderen, aus unserer Sicht grösseren Autoritäten in diesen Themen. Natürlich ist es wichtig, sich verschiedene Meinungen und Ansichten von sogenannten Expert*innen anzuhören und zu lesen, jedoch ist es genauso wichtig, diese immer zu hinterfragen und selbst zu überlegen, inwiefern diese Aussagen wirklich auf Fakten und Zahlen basieren und Gültigkeit im eigenen Kontext haben.

5. Der Survivorship Bias

Weil erfolgreiche Apps eine viel grössere Bekanntheit, Sichtbarkeit und Nutzung erfahren als all die Tausenden von Apps, welche weniger erfolgreich sind, überschätzen wir systematisch die eigene Chance, selbst eine erfolgreiche App oder digitalen Service auf den Markt zu bringen. Die Menge an gescheiterten Projekten und nicht-erfolgreichen Apps ist unglaublich gross, jedoch geniesst diese “Verlierer-Liste” absolut keine Aufmerksamkeit, wenn uns der Gedanke an eine eigens entwickelte, sehr erfolgreiche App in Euphorie versetzt. 

Beispiel aus der Gaming Industrie: Die Rovio Geschichte

Rovio, das weltberühmte Game-Studio aus Finnland, mag vielen wie ein Erfolg über Nacht erscheinen, aber es war alles andere als das. Im Jahr 2009 war Rovio ein kleines Spielestudio in Finnland, das am Rande des Bankrotts stand. Es hatte die meisten seiner Mitarbeitenden entlassen und beschäftigte nur noch 12 Angestellte. Das Unternehmen wurde 2003 von Studierenden gegründet, die einen Wettbewerb für Videospiele gewonnen hatten und dachten, dass es Spass machen würde, ihr eigenes Studio zu gründen. Sie entdeckten, dass sie in der Lage waren, einige coole Spiele zu entwickeln, aber der Vertrieb war schwierig. Vor Angry Birds hatten sie 51 Games entwickelt, welche jedoch nicht den gewünschten Erfolg mit sich brachten. Dass heute kaum jemand die 51 Misserfolge beachtet, sondern nur das extrem erfolgreiche Beispiel von Angry Birds als Inspiration und Ausgangspunkt für eigene Game-Projekte betrachtet, ist ein klares Beispiel des Survivorship Bias. Mehr zur Geschichte von Rovio findet man hier.

Möglichkeiten, diesen Denkfehler zu vermeiden:

• Nicht nur erfolgreiche Projekte oder Produkte beachten, sondern auch die gescheiterten Projekte analysieren.

• Die Wahrscheinlichkeiten auf einen Erfolg möglichst objektiv errechnen und die eigenen Annahmen, welche zu diesem Erfolg führen sollten, explizit ausformulieren und auf dem Weg zum Erfolg regelmässig überprüfen.

• Es ist wichtig, aus den einst vielversprechenden Marken und Produkten, welche dann gescheitert sind zu lernen. Gerade in der Tech-Branche gibt es unzählige davon wie z.B. Nokia, Blackberry, Microsoft's Windows Phone, MySpace, Xing, 3D-TVs uvm.

• Da wir notorisch die eigenen Erfolgschancen zu hoch einschätzen, wäre es wohl hilfreich, jeweils vom worst-case Szenario auszugehen. Dies würde dann eher der Realität entsprechen.

6. The Swimmer's Body Illusion

Oftmals haben wir Mühe, den Grund für den Erfolg von etwas richtig zu deuten und verwechseln in vielen Fällen sogar die Voraussetzung für etwas mit dem Resultat. Wir sehen zum Beispiel erfolgreiche und körperlich sehr ansprechende Schwimmer*innen, was uns glauben lässt, dass wir mit genügend Schwimmtraining auch so aussehen werden. Dass dieser Körperbau eventuell bereits die Voraussetzung war, dass der oder die Schwimmer*in so erfolgreich wurde, vergessen wir allzu oft: Voilà, die Swimmer’s Body Illusion.

In Bezug auf den App Markt, der digitalen Transformation und neuen Technologien ist es wichtig, immer dann sehr kritisch zu sein, wenn jemand behauptet, er oder sie hätte das eine Erfolgsrezept gefunden. Es gibt so viele Bücher, die beschreiben, mit welchen Mittel eine App oder ein digitales Angebot zum Erfolg geführt wurde. À la “in sieben Schritten zum Erfolg” oder “das Google Prinzip”. Dass es bereits vorher und definitiv auch nach diesem Erfolg sehr viele Unternehmen gab, die genau diese Prinzipien 1:1 bei sich anwandten und trotzdem nicht so erfolgreich wurden, bleibt oftmals unbemerkt. Dass bei einem Projekt durch eine sehr wasserfall-mässige Projektmethode ein erfolgreiches Produkt entstehen konnte und bei anderen mit agilen Methoden genauso erfolgreiche Apps entstanden, wird oftmals vergessen. Häufig sind es ganz viele andere Faktoren, welche eine Marke oder ein Produkt zum Erfolg geführt haben als diejenigen, welche offensichtlich und für alle verständlich erscheinen. Oft ist es reiner Zufall, ein unvorsehbares Ereignis, äussere Umstände oder pures Glück / Pech, welches jemanden zum Erfolg oder auch zum Misserfolg führt. Aufgepasst also bei Ratschlägen, welche mit einfachen Rezepten den Erfolg versprechen. Erfolg ist in vielen Fällen auch einfach sehr harte Arbeit.

Zusammenfassung von Teil 1 unserer Denkfehler-Blog-Mini-Serie

• Viele Denkfehler, welche wir im Alltag erleben, kommen auch in der Softwarebranche vor.

• Egal wer was sagt oder schreibt: Man sollte Aussagen und Zukunftsvorhersagen genau prüfen, selbst nachdenken und sich auch nach gegenteiligen Meinungen umsehen.

• Sich nicht vom Erfolg der besten Apps und digitalen Produkte blenden lassen, sondern auf den Friedhof der Misserfolge gehen, hinter die Kulissen schauen und sich dort schlau machen, wieso viele andere Projekte nicht zum Erfolg geführt werden konnten. 

• Die eigenen Chancen auf Erfolg realistisch oder sogar eher pessimistisch einschätzen und durch klar messbare Ziele und Messungen auf echten Zahlen und Fakten basieren. 

• Diversität in Teams und eine offene Fehlerkultur sowie 360° Feedback Loops erhöhen die Chance, dass wichtige Entscheidungen und Strategien weniger Denkfehler beinhalten. 

Hast Du eventuell eigene gute Beispiele, bei denen Du dich oder jemand anderes bei einem Denkfehler in der Softwareentwicklung ertappt hast? Wir freuen uns auf jeden Input, Kritik oder weiterführende Informationen zu diesem Thema. Und dann darf man gespannt sein auf Teil 2!