Teil 3 – Zusammenfassung: GETTING REAL von 37signals – Tipps/Ideen/Trends

Teil 1 der Zusammenfassung – Teil 2 der Zusammenfassung

Nachdem ich im Teil 1 die Themen „Die Startlinie“, „Schlank bleiben“ und „Prioritäten“ und Teil 2 die Themen „Selektion der Funktionalitäten“, „Prozesse“, „Organisation“ und die „Stellenbesetzung“ zusammengefasst und ergänzt habe, geht es nun im Teil 3 um „Interface Design“, „Code“, „Worte“, „Preise und Anmeldungen“, „Promotion“, „Support“ und die „Nach der Einführung“. Somit bin ich tatsächlich in 3 Teilen mit der Zusammenfassung durchgekommen.

Eventuell werde ich dann noch einen weiteren Artikel bloggen, der die 3 Teile wieder zusammenfasst – die Zusammenfassung, der Zusammenfassung.

Inzwischen hatte ich etliche Diskussionen zum Thema „Getting Real“ – vor allem wie realistisch die Konzepte in diversen Situation anwendbar sind. Vielleicht erstelle ich Präsentation der Highlights – wäre doch ein spannender Vortrag!?

IF YOU WOULD LIKE AN ENGLISH TRANSLATED VERSION OF THIS SUMMARY – LET ME KNOW

Also, auf ein letztes Mal zum Thema „Getting Real“. Wiederum möglichst kurz & knapp und doch anregend genug, um auch wirklich auszuprobieren und/oder anzuwenden.

Interface Design

• INTERFACE FIRST – Designe zuerst das Benutzerinterface, bevor du mit dem Programmieren startest. Das Programmieren ist nicht die schwierigste Aufgabe, jedoch die teuerste und am schwierigsten zu ändern. Zudem ist das Benutzerinterface das Produkt – das was du dem Benutzer verkaufst. Ein bestehendes Benutzerinterface motiviert auch die Mitarbeiter, weil sie sehen wohin die Reise geht. Dabei hilft dies auch zur Aufwandschätzung und beim Entscheid der geeigneten Architektur und den zu verwendenden Technologien.
• EPICENTER DESIGN – Starte mit dem Herz des Benutzerinterfaces – ignoriere die Extremitäten wie Navigation, Kopf- und Fusszeile, Logo, etc und fokussieren dich auf den eigentlichen Inhalt. Dies hilft auch den Dialog zwischen Designer und Programmierer zu fördern und diese auf den Hauptteil zu fokussieren.
• THREE STATE SOLUTION – Beachte nicht nur den Normalbetrieb, sondern achte auf das Verhalten der Applikation im Falle eines Fehlers und vor allem auch wie die Applikation aussieht, wenn sie noch keine Daten enthält. Am Anfang hat die Applikation keine Daten und so wird der Benutzer seine ersten Erfahrungen sammeln – also wenn deine Applikation „leer“ nicht toll aussieht, dann wird der Benutzer diese auch nicht toll finden. Am Anfang können dabei auch Wizards, Tutorials, Hilfstexte, Beispiel Screenshots, Erklärungen oder vorabgefüllte Beispieldaten helfen. Überleg dir welche Fragen der Benutzer am Anfang hat und beantworte diese.
• GET DEFENSIVE – Baue deine Applikation auch für den Fall das Etwas schief geht – wenn etwas schief gehen kann, dann geht es schief 😉
• CONTEXT OVER CONSISTENCY – Es ist wichtiger im richtigen Kontext zu sein, als „nur“ konsistent zu sein. Das heisst sich zu überlegen, was für Elemente, Texte, etc. in den verschiedenen Situationen Sinn machen und nicht nur aus Prinzip überall das Gleiche zu machen. Gib und zeig dem Benutzer was er gerade braucht.
• COPYWRITING IS INTERFACE DESIGN – Es kommt auf jeden Buchstaben an. Sprich die Sprache deiner Benutzer. Formuliere dich kurz und präzise. Gutes Schreiben ist gutes Design.
• ONE INTERFACE – Baue administrative Funktionen ins allgemeine Benutzerinterface ein. Kein separater Administrationsbereich. Zwei Benutzerinterfaces zu warten ist aufwendig und das Eine oder Andere wird darunter leiden. So weniger Screens, umso besser. Nicht zu viele Aktionen auf einer Seite. Verstecke Funktionen (wie Administrationsaufgaben) oder mach diese kleiner. Stell in den Vordergrund, was der Benutzer regelmässig braucht.

Code

• LESS SOFTWARE – Weniger Software ist mehr. Halte deinen Code so einfach als möglich. Die Komplexität steigt mit der Menge Code exponentiell. Jede Änderung hat kaskadierende Folgen. Wiederum gilt 80/20 mit 20% Aufwand 80% des Problems lösen. Versuche nicht die Zukunft zu lesen, sondern löse die Probleme von heute – etwas philosophisch, doch durchaus anwendbar im Falle von Softwareentwicklung. Vorausschauen kann nicht Schaden, doch sich einfach nicht verrückt machen lassen. Eine Gute Idee ist auch die Programmierer ein Gegenangebot machen zu lassen – die Umsetzung deines Vorschlags dauert 3 Tage und ich hätte eine Idee das Problem in einem Tag zu lösen (80/20).
• OPTIMIZE FOR HAPPINESS – Wähle Werkzeuge, die dein Team motivieren und mit denen sie gerne arbeiten. Glückliche Mitarbeiter machen die richtigen Sachen.
• CODE SPEAKS – Wenn es zu lange dauert etwas zu implementieren, dann gibt es wahrscheinlich einen Weg es einfacher zu lösen. Vielleicht entspricht die einfachere und kürzere Lösung nicht 100% der Originalanforderung, doch wiederum gilt 80/20. Höre auf deine Programmierer und nimm ihre Bedenken ernst (gilt nicht nur für Programmierer!). Gib Ihnen Zeit ein „wirkliches“ Problem zu lösen.
• OPEN DOORS – Verteile Informationen in die weite Welt und „öffne“ den Zugang zu deiner Applikation – Stichwort RSS, API. RSS Feeds eignen sich Kunden zu informieren, ohne dass diese deine Seite besuchen müssen. APIs geben Anderen die Gelegenheit deine Applikation zu erweitern – oft sind diese Add-ons sehr wertvoll.
• MANAGE DEPT – Obwohl du schnell zu einer Umsetzung kommen solltest darfst du deine Altlasten/Schulden nicht vergessen. Von Zeit zu Zeit muss der Code gewartet werden und Schulden abgebaut werden. Plane für diese Aktivitäten auch Zeit ein.

Words / „Worte“

• THERE’S NOTHING FUNCTIONAL ABOUT A FUNCTIONAL SPEC – Schreibe keine funktionale Spezifikation, denn es sind Fantasien. Alle fühlen sich mit einbezogen, doch helfen tut es nicht. Bin nicht ganz gleicher Meinung. Einverstanden, dass dies für ein „kleines“ Team funktioniert und solange kein Auftragsverhältnis besteht. In grösseren Firmen müssen unbedingt diverse Teams/Einheiten miteinbezogen werden – und wenn die Spec an sich nicht viel bringt, dann hilft es wenigstens den Dialog zu fördern – ein grosse Herausforderung für viele grossen Firmen. Oft wird sich diese durch diesen Prozess bewusst, wie uneinig sich die verschiedenen Einheiten sind und die grossen Differenzen können angegangen werden. Ebenfalls bin ich der Meinung das komplexe Anforderungen spezifiziert werden sollen. Zudem wird anhand der Spec der Testplan erstellt. Ohne dokumentierte Anforderungen, kein vernünftiges Testkonzept. Funktionale Specs zwingen uns Entscheidungen zu treffen, die in diesem frühen Stadium Mangels Informationen noch gar nicht getroffen werden können. Auch hier bin ich nicht gleicher Meinung. Spezifiziere was sich spezifizieren lässt – unklare Punkte oder solche die mehr Informationen brauchen einfach offen lassen und zu gegebener Zeit entscheiden (oder in SCRUM-Sprache: in einem nächsten Sprint). Klar gibt es bei Specs immer wieder Änderungen, doch diese können mit einem Änderungsprozess definiert werden, der garantiert, dass das Ganze nicht aus dem Ruder läuft. Ich glaube bei diesem Punkte sehen die 37signalers das Leben ein bisschen zu einfach… Hingegen finde ich die Idee mit der „Ein-Seiten Spec“ sehr gut – eine Seite die kurz und bündig das Projekt umschreibt.
• DON’T DO DEAD DOCUMENTS – Eliminiere unnötige Papierarbeit – eigentlich klar, denn eigentlich sollte ja gar nix unnötiges kreiert werden – somit muss auch nix eliminiert werden 😉
• TELL ME A QUICK STORY – Schreibe eine Geschichte und verliere dich nicht in Details
• USE REAL WORDS – Arbeite immer mit „echten“ Texten und nicht mit Platzhalter. Echte Texte zeigen dir wie gross ein Feld sein muss, wie Tabellen sich verändern und wie deine Applikation wirklich aussieht.
• PERSONIFY YOUR PRODUCT – Personifiziere dein Produkt und stell dir vor es sei eine Person, die 24 Stunden am Tag mit dem Benutzer spricht.

Pricing and Signup / „Bepreisung und Registration“

• FREE SAMPLES – Gib etwas gratis ab. Zum Beispiel ein Teil deiner Software – eine Light Version.
• EASY ON, EASY OFF – Der Registrationsprozess sollte möglichst einfach sein (evtl. Demoversion ohne Kreditkarten Informationen). Falls sich ein Benutzer abmelden möchte, dann mach ihm/ihr das Leben nicht unnötig schwer, sondern gestalte auch diesen Prozess möglichst einfach. Erlaube es solchen Benutzern auch ihre Daten mitzunehmen.
• SILLY RABBIT, TRICKS ARE FOR KIDS – Vermeide längere und/oder bindende Verträge. Versuche nicht durch einen Trick mehr Geld zu bekommen, sondern verdiene dein Geld.
• A SOFTER BULLET – Vorab über schlechte Nachrichten für den Nutzer informieren (z.B. Preiserhöhung) und Gnadenfrist einplanen.

Promotion / „Werbung“

• HOLLYWOOD LAUNCH – Lanciere deine Applikationen mit einem Hype. Erst ein Teaser (ein paar Hinweise, Logo und E-Mail Adressen sammeln), dann eine Vorabversion (erster Einblick in Funktionalitäten, ein Blick hinter die Bühne, Betatesters identifizieren) und dann die offizielle Lancierung. Und dann vor allem Momentum beibehalten – immer wieder etwas Neues.
• A POWERFUL PROMO SITE – Baue eine Werbeseite, die das Produkt den Benutzern präsentiert – Guided Tour, Screenshot, Case Studies, Testimonial, Forum, Blog (siehe auch nächster Punkt), etc.
• RIDE THE BLOG WAVE- Bloggen kann effektiver sein als Werbung und es ist vor allem günstiger!
• SOLICIT EARLY – Früh anfangen E-Mail Adressen von Interessierten sammeln, die dann bei der Lancierung gleich informiert werden können.
• PROMOTE THROUGH EDUCATION – Teile dein Wissen mit der Welt. Leute die du ausbildest werden deine Evangelisten. Tipps & Tricks aufschalten und an Konferenzen teilnehmen. Interviews geben und Artikel für Magazine oder ein Buch schreiben. Lehren erhöht Karma und zahlt sich für die Zukunft aus. „Talking leads to Passion“ – Kathy Sierra
• FEATURE FOOD – Neue Funktionen sind eine gute Gelegenheit um Begeisterung und/oder Aufmerksamkeit zu erzeugen. Interessensgruppen lieben es über neue Funktionen zu debattieren und schreiben.
• TRACK YOUR LOGS – Du musst deine Benutzer kennen und solltest Wissen wer wie über dich und deine Applikation spricht. Kommentiere Blogeinträge und Bedanke dich für Kommentare in deinem Blog. Auch auf negative Kritik reagieren ist wertvoll.
• INLINE UPSELL – Mach Werbung in deiner Applikation für Upgrades und mache es dem Benutzer möglichst einfach auf eine teurere Version deiner Applikation umzuschalten. Existierende Kunden eignen sich sehr gut um weitere Verkäufe zu machen – nicht scheu sein.
• NAME HOOK – Gib deiner Applikation einen Namen, der sich einfach merken lässt. Nicht ewig suchen und überlegen, sondern einen einfachen, kurzen, einprägsamen Namen wählen und loslassen.

Support

• FEEL THE PAIN – Mauern/Hürden zwischen Support und Entwicklung entfernen. Diese sollen voneinander Wissen und Lernen. Kundensupport nicht auslagern. Und falls trotzdem nötig, möglichst für einen regen Austausch sorgen.
• ZERO TRAINING – Baue die Hilfe und Fragen und Antworten gerade in das Produkt mit ein. Die Applikation sollte falls möglich kein Benutzerhandbuch und keine Schulung brauchen (ausser du willst mit Schulung Geld verdienen ;-)).
• ANSWER QUICK – Supportanfragen sofort beantworten. Somit kannst du dich von Mitbewerbern differenzieren. Auch wenn die Antwort noch nicht perfekt ist – sag etwas.
• TOUGH LOVE – Sei bereit Nein zu sagen. Nein zu neuen Anforderungen. Als Entwicklungsfirma muss man sein Produkt mögen und wenn man etwas mag füllt man es nicht mit Müll 🙂
• IN FINE FORUM – Stelle ein Forum und/oder einen Chat zur Verfügung, damit sich die Benutzer gegenseitig helfen können.
• PUBLICIZE YOUR SCREWUPS – Schlechte Nachrichten sofort mitteilen. Gute Nachrichten dürfen sich hingegen gerne in die Länge ziehen. Eine gute Stimmung kann man künstlich verlängern.

POST-LAUNCH / „Nach der Lancierung“

• ONE MONTH TUNEUP – 30 Tage nach der Lancierung am Besten einen grösseren Update machen. Dies zeigt Momentum und dass du deinen Benutzern zuhören kannst. Diese Strategie erlaubt es auch, sich bei der Lancierung um das Wesentlichste zu kümmern und das weniger Wichtige dann im Update nachzuschieben.
• KEEP THE POST COMING – Zeig das dein Produkt lebt z.B. mit einem Entwicklerblog. Zudem erlaubt ein Blog sich menschlich zu zeigen – die Köpfe hinter der Applikation und ihre Meinungen. Im Blog können auch Fragen & Antworten, Tipps & Tricks, usw. gepostet werden.
• BETTER, NOT BETA – Lass das „Beta“ sein. Beta sagt, dass du eigentlich noch nicht bereit bist und entschuldigt im Vornherein für alle Fehler – will das der Benutzer? Private Betas sind ok, öffentliche Unsinn. Zeige Verantwortung für das was du lancierst. Google ist schuld 😉
• ALL BUGS ARE NOT CREATED EQUAL – Priorisiere Fehler und ignoriere vor allem auch Unkritische. Jede Software hat Fehler. Sei jedoch ehrlich betreffend den Fehlern.
• RIDE OUT THE STORM – „When you rock the boat, there will be waves“. Wo man sich bewegt gibt es auch Wellen. Nach einer Lancierung braucht es Geduld, ruhig sitzen bleiben, zuschauen, die Wellen etwas glätten lassen und dann agieren. Negative Reaktionen sind oft lauter als positive – das heisst aber nicht, dass du gleich reagieren musst. Die Masse liebt vielleicht deine Änderung, bleibt aber ruhig…
• KEEP UP WITH THE JONESES – Informiere dich über deine Mitbewerber. In der Hitze des Gefechtes wird dieser Punkt oft vernachlässigt. Nicht nur du musst Wissen was deine Mitbewerber macht, sondern deine Partner/Kunden wollen es auch Wissen.
• BEWARE THE BLOAT MONSTER  – Durchdachter und reifer heisst nicht nur Wachstum und komplizierter. Nicht nur wachsen um des Wachsens willen. Desktop Software muss immer wieder neue Funktionen haben, damit sich neue Versionen verkaufen lassen – nicht so bei Web-Applikationen. Ausser Desktop Software wird mit einem anderen Lizenzmodel vertrieben (z.B. wiederkehrende Lizenzgebühren).
• GO WITH THE FLOW – Sei offen für Veränderungen und bereit neue Pfade zu verfolgen. Halte Ausblick nach den grössten Wellen und reite diese. Ja, Lance – ride the wave 😉

Also los, es war noch nie so einfach & günstig Ideen umzusetzen. Mit der richtigen Idee, der Leidenschaft, etwas Zeit, den richtigen Fähigkeiten und vor allem den richtigen Leuten steht dir nichts mehr im Wege! Nutze die Chance – lass mich Wissen, falls du etwas auf die Beine stellen willst – helfe gerne wo ich kann… Der Erfolg wird abhängig von einer exzellenten Umsetzung sein – die Idee ist das Eine, die richtige Umsetzung das Andere (und noch viel Wichtigere!). Such dazu Leute die die Leidenschaft mit dir teilen. Die richtigen Leute werden den Erfolg ausmachen!!!

Teil 1 der Zusammenfassung – Teil 2 der Zusammenfassung

Werbung