Viele Teammitglieder bei descript sind begeisterte Leser:innen. Ob Roman, Sachbuch oder Biografie – häufig drehen sie unsere Gespräche am Mittagstisch um das zuletzt gelesene Buch. Neuerdings etablieren wir einen Lesezirkel, in welchem wir uns gegenseitig und regelmäßig neue Bücher vorstellen. Warum also nicht auch euch daran teilhaben lassen? So soll es sein und deshalb führen wir in unserem Blog die neue Rubrik „Lesezirkel“ ein. Los geht es mit einem Sachbuch.
In unseren Softwareprojekten ist die Analysephase der Grundstein für eine erfolgreiche Entwicklung. Zu verstehen, was Kund:innen und Nutzer:innen mit einer Anwendung erreichen wollen, formt das Bild der späteren Lösung. Dies merken wir nicht nur, wenn wir bei Mataono ein komplett neues Produkt entwickeln, sondern auch in den vielen Projektanfragen unserer Kund:innen, die wir regelmäßig bekommen. Die Anforderungsanalyse, oder neudeutsch User Research, richtig zu betreiben, ist nicht immer einfach. Zum Glück gibt es tolle Lektüre zu diesem Thema. Unser Buch des Monats ist deshalb Demand-Side Sales von Bob Moesta.
Über das Buch
Der klassische Vertrieb hat wenig mit der Anforderungsanalyse zu tun. Deshalb schlägt Moesta einen neuen Weg vor, denn nur wer die Anforderungen versteht, kann ein Produkt bedarfsgerecht verkaufen. Nicht umsonst lautet der Untertitel des Buchs „Stop selling and help your customers make progress“. Dieser gewünschte Fortschritt muss erst einmal herausgearbeitet werden – nichts anderes tun wir, wenn wir für ein Softwareprojekt mit dem Shaping beginnen.
Aufbauend auf dem Jobs-to-be-done-Ansatz von Clayton Christensen gibt Moesta den Leser:innen konkrete Methoden an die Hand, die dabei unterstützen, das Kund:innen-Verständnis zu erhöhen (von den 5 Whys bis hin zu konkreten Interviewleitfäden ist alles dabei). All das wird innerhalb seines Frameworks zu einem großen Bild über den gewünschten Fortschritt zusammengesetzt.
Drei Aspekte des Buches haben wir beim Lesen verinnerlicht:
Erstens – Es ist wichtig, Push- und Pull-Effekte zu erkennen
Push- und Pull-Effekte gibt es in so vielen Bereichen unseres Lebens und natürlich auch bei der Anschaffung neuer Softwareanwendungen (wenn du einmal ein Digitalisierungsprojekt begleitet hast, weißt du was ich meine). Bei der Einführung neuer Software gibt es zwei unterschiedliche Arten der Push- und Pull-Effekte zu beobachten. Immer, wenn wir uns für eine neue (Software)Lösung entscheiden wollen, gibt es Kräfte, die uns dabei bestätigen. Zum einen könnte unser aktuelles Problem so zeitaufwändig sein, dass wir uns nach einer einfacheren Software-Anwendung sehnen (Push-Effekt). Wenn diese dann auch noch attraktiv ist, weil sie viele unserer Probleme löst (Pull-Effekt), fällt uns eine Entscheidung leichter. Entgegengesetzt gibt es aber auch Faktoren, die einen Wandel blockieren. Angst vor einer neuen Lösung (Push-Effekt) und bestehende Gewohnheiten (Pull-Effekt) lassen Nutzer:innen am Ende doch wieder business-as-usual betreiben.
Push- und Pull Faktoren in der Einführung von Software (s. Seite 68)
Zweitens – Hinter jedem Wunsch stehen drei Quellen der Motivation
Alle Anforderungen von Kund:innen können durch die 5 Whys bis zu des Pudels Kern analysiert werden. Dabei unterscheiden sich die gewünschten Fortschritte oder Motivationen jeder Anforderung: Es gibt die funktionale Motivation, dass etwas einfach funktionieren soll. Es gibt die emotionale Motivation, die auf das Wohlbefinden von Nutzer:innen abzielt. Und es gibt die soziale Motivation, die darauf gerichtet ist, das Image der Nutzer:innen zu verbessern. Es ist wichtig die unterschiedlichen Motivationen zu verstehen, um während der Konzeption der Anwendung die richtigen Entscheidungen zu treffen.
Beispiel für ein Web of Abstraction, um die unterschiedlichen Motivationen zu ermitteln.
Drittens – Es geht darum, den Point of Struggle zu identifizieren
An welcher Stelle wird die zu entwickelnde Anwendung eingesetzt? In welcher Situation befinden sich Nutzer:innen, wenn sie mit der Anwendung in Kontakt kommen. Was ist die genaue Timeline dahinter? Was passiert vorher? Was passiert nachher? Je genauer der Point of Struggle bestimmt werden kann, umso besser löst die Anwendung am Ende das Problem.
Wie machen wir das bei descript
Natürlich haben auch wir in unserer früheren Vergangenheit Software entwickelt, die am Ende nicht ganz den Vorstellungen der Kund:innen entsprach. Obwohl wir unser Handwerk ausgezeichnet anwendeten und auch die Kund:innen früh in die Entwicklung einbezogen haben (was nicht immer gut funktioniert), haben wir den Nagel nicht immer genau auf den Kopf getroffen. Eine Ursache dafür war, dass wir Annahmen über die Realität der Nutzer:innen getroffen haben, die der wirklichen Realität nicht standhielten.
Angeregt durch das Buch haben wir unseren Prozess verfeinern können. Gerüstet mit den Interviewmethoden haben wir Gespräche mit den späteren Anwender:innen gesucht und wesentlich strukturierter aufgebaut. Wir haben nicht nur die funktionale Anforderung erfasst, sondern auch die jeweilige Motivation dahinter. Daraus resultierte nicht nur eine Software zur Zufriedenheit der Nutzer:innen, es verhalf uns auch zu einer effizienteren und schnelleren Umsetzung. Nicht immer muss es ein Hydrodynamischer Pfannenwender mit Steuer- und Backbordaufsätzen und Turboantrieb sein, sondern manchmal reicht auch ein Spatel – was uns auch die Arbeit erleichtert.
Vor allem bei unserem Produkt Mataono – wo wir komplett freien Spielraum haben – ist es wichtig, die Zielgruppe zu verstehen und das Projekt für die Anforderungen dieser Gruppe zu entwickeln, und nicht für unsere Vorstellung. Daher haben wir vor der Programmierung erst einmal ausgiebig mit Nutzer:innen und Entscheider:innen gesprochen. In 23 Interviews stellten wir die gleichen vier Fragen:
- Welche ist die anstrengendste Aktivität im Rahmen der Kund:innenberatung? Warum?
- Wann und in welchem Kontext sind die Herausforderungen zuletzt aufgetreten?
- Was haben Sie bisher versucht, um Ihre Herausforderung zu lösen?
- Was stört Sie an den bisherigen Lösungen?
Aus diesen Fragen entstanden tolle Gespräche, manchmal bis zu einer Stunde, die uns einen tiefen Einblick in die Gedanken- und Lebenswelt der befragten Personen gegeben haben. Die ersten beiden Fragen halfen uns, den Point of Struggle zu bestimmen. Zudem konnten wir viel über die Motivation der einzelnen Personen erfahren. Die letzten beiden Fragen zeigten uns, ob unsere Zielgruppe bereit ist, die Herausforderung überhaupt zu lösen (oder stehen irgendwelche Verhaltensweisen und Ängste im Weg?). Allein durch diesen kurzen Interview-Leitfaden konnten wir unzählige Ideen für Mataono generieren.
Ich empfehle das Buch allen, die in irgendeiner Weise mit Kund:innen und deren Anforderungen zu tun haben: VertrieblerInnen, PMs und POs, User Researchers.
Was haben wir sonst so diesen Monat gelesen?
Dieses Jahr habe ich mir den Vorsatz gemacht, jede Woche ein Buch zu lesen. Das klappt zwar nicht immer, aber einige Titel habe ich schon durch. Wenn du wissen möchtest, was ich im Februar gelesen habe, dann schau einfach hier rein: Buchliste Februar (auf Englisch).
Tom hat im Januar Code kaputt – Macht und Dekadenz im Silicon Valley von Anna Wiener gelesen. In dem Buch berichtet die Autorin von ihren Erfahrungen als Mitarbeiterin in diversen Start-Ups im Silicon Valley. Es geht um Machtstrukturen, Sexismus und die Dekadenz der vermeintlichen Eliten an jungen Unternehmer:innen, die unseren Alltag mit ihren digitalen Services massiv beeinflussen. Das Buch ist aber auch das Porträt einer Generation, die sich den goldenen Versprechungen des digitalen Start-Up Kapitalismus hingibt und am Ende erkennen muss, dass sprichwörtlich nicht alles Gold ist, was glänzt.
Thomas nimmt zurzeit an einen Kurs für das CKA-Zertifikat (Certified Kubernetes Administrator) teil. In dem Zuge liest er zurzeit Production Kubernetes von Josh Rosso, Rich Lander, Alex Brand und John Harris. Kubernetes hat sich zum vorherrschenden Container-Orchestrator entwickelt, aber viele Unternehmen, die dieses System erst kürzlich eingeführt haben, haben immer noch Schwierigkeiten, die tatsächlichen Produktionslasten auszuführen. Bei descript nutzen wir zwar noch nicht Kubernetes, aber was ist nicht ist, kann ja noch werden.
Steffen hat sich in diesem Monat viel mit der Beschleunigung unserer Server-Abfragen bei Mataono beschäftigt. Passenderweise ist ihm dabei folgender Artikel untergekommen: How we optimized Python API server code 100x.