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

Teil 1 der Zusammenfassung – Teil 3 der Zusammenfassung

Nachdem im Teil 1 die Themen „Die Startlinie“, „Schlank bleiben“ und „Prioritäten“ zusammengefasst und ergänzt habe, geht es nun im Teil 2 um „Selektion der Funktionalitäten“, „Prozesse“, „Organisation“ und die „Stellenbesetzung“. Das Buch gibt soviel her, dass ich wahrscheinlich nicht mit 3 Teilen fertig werde, sondern häufiger meine Gedanken dazu niederschreiben möchte. Habe übrigens öfters den Begriff „Systeme“ benutzt – ich denke einiges gilt nämlich für Software, sowie auch Prozesse.

Los geht’s. Wiederum möglichst kurz & knapp und doch anregend genug, um auch wirklich auszuprobieren und/oder anzuwenden.

Feature Selection / „Selektion der Funktionalitäten“

• HALF, NOT HALF-ASSES – Mach genau das was nötig ist. Nimm was du denkst ist nötig und halbiere es noch einmal. Starte mit einer kleinen, einfachen und schlauen Applikation (oder auch Prozess…) und baue somit ein solides Fundament, das sich erweitern lässt.
• IT JUST DOESN’T MATTER – Oft wird man gefragt, warum man dies und das nicht gemacht hat. Warum? Weil es nicht wichtig ist. Wichtiges von Unwichtigem zu unterscheiden machen den guten Designer und/oder Programmierer aus. Wir verbringen viel Zeit mit Unwichtigem und wenn wir diese Zeit halbieren werden wir enorm produktiv.
• START WITH NO – Jedes Mal wenn wir Ja zu einer Funktionalität sagen, machen wir unser System komplexer und müssen alles durchmachen – Design, Code, Test. Und wenn die Funktionalität einmal da ist, dann darf man diese dem Nutzer nie mehr nehmen. Wichtige Anforderungen werden wiederholt von diversen Seiten formuliert. Erst dann sind sie wichtig. Steve Jobs once said in a session after people kept asking for new features: „Wait wait – put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes *could* have. So do we. But we don’t want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.“
• HIDDEN COSTS – Hier möchte ich dem Leser nicht die spannende Liste von Checkpunkten vorenthalten, die jedes Mal bei der Frage nach der Umsetzung einer neuen Funktionalität gebraucht werden kann:
  • „Nein“ sagen
  • Bringt die Funktionalität wirklich einen Mehrwert?
  • Falls „Nein“, dann ist hier fertig. Falls „Ja“ dann weiter
  • Skizziere die Bildschirmmaske
  • Designe die Bildschirmmaske
  • Kodiere
  • Testen, anpassen, testen, anpassen, testen, anpassen, …
  • Muss die Hilfe angepasst werden?
  • Muss das Marketingmaterial angepasst werden?
  • Müssen die Benutzungsbedingungen angepasst werden?
  • Wurden irgendwelche Versprechungen nicht eingehalten?
  • Ändert die Preisstruktur?
  • Starten
  • Luft anhalten
• CAN YOU HANDLE IT? – Baue Systeme, die du warten kannst. Ein Versprechen zu machen ist leicht, es zu halten schon schwieriger.
• HUMAN SOLUTIONS – Mach einen guten Job, um eine Lösung für ein Problem anzubieten, dann steh bei Seite und lass den Benutzer mit deiner Lösung arbeiten wie er will – motiviere den Benutzer sogar seine eigenen Weg zu finden.
• FORGET FEATURE REQUESTS – Lies Anfragen zu neuen Anforderungen, aber vergesse sie gleich wieder. Aber wie erwähnt, die guten Vorschläge werden immer wieder kommen und diese musst du dir dann merken.
• HOLD THE MAYO – Warum die Leute nicht einmal Fragen, welche Funktionalitäten sie nicht möchten? Manchmal ist das Auslassen einer gewissen Funktion der grösste Gefallen, den man den Benutzer machen kann. Indem man sich auf das Wesentliche konzentriert, kann man diesem entsprechendes Gewicht geben.

Process / „Prozesse“

• RACE TO RUNNING SOFTWARE – Laufende Software ist der beste Weg um Bewegung in das Vorhaben zu bringen. Also raus damit! Die schnelle Inbetriebnahme sollte das wichtigste überhaupt sein. Wie viele Softwaresysteme erblicken nie das Licht der Welt? Schade, diese gehen kaputt oder werden wegrationalisiert bevor diese im Betrieb waren und entsprechende Erfahrungen damit gesammelt werden konnten. Reale Dinge führen zu realem Feedback und so erfahren wir die Wahrheit. Durch reale Umsetzung kann man sich auch meist erst einigen – der Mensch muss eine Sache sehen und/oder spüren. Umgesetzte Softwaremodule können auch getestet werden, da diese von den Entwicklern auch tatsächlich gebraucht werden.
• RINSE AND REPEAT – Arbeiten in Iterationen ist wichtig. Erwarte nicht es im ersten Anlauf hinzukriegen. Nur bei umgesetzten Ideen sieht man, ob diese auch tatsächlich fliegen – ich glaube hier passt auch ganz schön der Spruch „Probieren, geht über studieren“.
• FROM IDEA TO IMPLEMENTATION – Brainstormen -> Skizzieren -> HTML Seiten -> Codieren (ich denk im Falle von Prozessen, könnte man anstelle von „HTML Seiten“ auch „Simulieren“ nehmen).
• AVOID PREFERENCES – Entscheide für den Benutzer über Details, somit erparst du ihm diese Entscheidung und die damit verbundene Arbeit. Preferences/Einstellungen bedeuten auch mehr Software, so mehr Optionen, so mehr Code und somit mehr Design und Testing.
• „DONE!“ – Entscheidungen sind temporär, also fälle sie und mach weiter. Im Buch wird der nette Spruch verwendet „this isn’t brain surgery, it’s a web app“ – es handelt sich um keine Hirnoperation, sondern nur um eine Webapplikation :-). Entscheiden und Vorwärtsmachen ist wichtig. Gewöhne dich an einen hohen Entscheidungsrythmus und lerne Fehler zu akzeptieren. Fehler passieren und Fehler zu machen ist nicht schlimm, solange man diese auch schnell wieder korrigieren kann.
  Ideen sind nur wertvoll, wenn diese auch umgesetzt werden. Andernfalls sind Ideen nur Multiplikatoren. Derek Sivers (CD Baby) hat dazu folgende Erklärung zusammengestellt und um Geschäft zu machen müssen die beiden Werte multipliziert werden – aus diesem Grund möchte er von Leuten nicht nur deren Ideen hören, sondern auch eine entsprechende Umsetzung:
  • Ideenbewertung: Miserabel = -1, Schwach = 1, Geht so = 5, Gut = 10, Grossartig = 15, Brillant = 20
  • Ausführungsbewertung: Nicht = $1, Schlecht = $1’000, Geht so = $10’000, Gut = $100’000, Grossartig = $1’000’000, Brillant = $10’000’000
  • Das heisst eine brillante Idee (20), die schlecht ausgeführt wird ($1’000) hat einen Wert von $20’000 (20*1’000). Hingegen hat eine „Geht so“ Idee (5), die grossartig ausgeführt wird ($1’000’000) einen entsprechend viel höheren Wert von $5’000’000 (50*1’000’000) – alles klar?
• TEST IN THE WILD – Gib Beta-Funktionalitäten für einen kleinen Benutzerkreis früh in der Live-Applikation frei – nur hier bekommst du reale Resultate. OK, Beta ist Trend und wir haben glaube ich schon fast ein bisschen genug davon. Doch das Prinzip macht absolut Sinn. Neulich habe ich auch erste Bücher gesehen, die erst als Beta zur Verfügung stehen und somit von den Betalesern noch korrigiert werden können oder zu denen der Leser noch Feedback und Input geben kann.
• SHRINK YOUR TIME – Teile Zeiten in kleine Einheiten. Einverstanden, dass dies je nach Seniorität Sinn macht. Doch ich wäre auch äusserst vorsichtig damit, denn bricht man Aufgaben in zu kleine Einheiten werden Aufwandsschätzungen entsprechend gross. Der gleiche Effekt, wenn ich mir am Abend überlege, was ich alles gemacht habe, dann hat man doch oft das Gefühl, dass dies gar nicht alles in einen Tag passt. Durch die Vielzahl der kleinen Einheiten erhöht sich das Gesamte. Wichtig ist auch ein Verständnis des Gesamten zu haben. Daher machen sicher beide Ansichten Sinn (à la bottom-up und top-down Schätzung/Planung – die goldene Mitte wird es wohl sein).

The Organization / „Die Organisation“

• UNITY – Aufteilung in Silos macht keinen Sinn, sondern integriere deine Teams damit ein vernünftiger Austausch stattfinden kann. Nicht alle Designer, alle Programmierer, das ganze Marketing, etc. zusammen, sondern Teams bilden, die durch den gemeinsamen Dialog effektiver werden. Am Besten rekrutiert man gleich Leute, die Fähigkeiten in mehren der Fachgebiete haben, respektive Personen die verschiedene Hüte tragen können.
• ALONE TIME – Um produktiv zu sein, müssen Personen ungestört arbeiten können. In der Zeit, wo die Leute für sich arbeiten wird realer Fortschritt macht. Wir allen kennen (oder sollten wenigstens) den Zustand des „Flows„.
• MEETINGS ARE TOXIC – Viele Meetings sind nicht unbedingt nötig. Falls diese nötig sind müssen diese entsprechend vor- (Agenda und richtige/wenige Teilnehmer) und nachbereitet (dokumentiert und nächste Schritte) werden.
• SEEK AND CELEBRATE SMALL VICTORIES – Das wichtigste in der Softwareentwicklung ist die Motivation. Quick Wins zu feiern motiviert. Das Buch hat ein paar gute Ideen zu einer Art Übung. Es geht darum einen kleinen Release in 4 Stunden zu machen und dann zu feiern. Beispiele dazu, die ich mir merken werde:
  • Eine kleine, neue und einfache Funktionalität
  • Eine nette Erweiterung zu einer bestehenden Funktionalität
  • Neuschreiben eines Hilfetextes, damit weniger Supportaufwand entsteht
  • Entfernen von ein paar Feldern auf der Eingabemaske, die du wirklich nicht brauchst

Staffing / „Stellenbesetzung“

• HIRE LESS AND LATER – Du musst nicht von Anfang an (oder gar nie) gross sein. Frage dich lieber ob dein Unternehmen eine Tätigkeit nicht machen muss, anstatt gleich neue Leute anzustellen. Meist braucht man weniger Leute als man denkt.
• KICK THE TIRES – Teste deine neuen Mitarbeiter falls möglich. Gib ihnen eine kleine Aufgabe oder ein kleines Projekt und beurteile dann, ob du mit dieser Person zusammenarbeiten kannst und ob diese in dein Unternehmen passt.
• ACTIONS, NOT WORDS – Beurteile technische Kandidaten anhand deren Beitrag zur Open Source Community. Na ja, dieser Tipp ist vielleicht etwas sehr subjektiv von den Autoren des Buches. Ich kenne viele gute Leute, die würden nie etwas für Open Source machen und ich würde sie trotzdem sofort anstellen. Aber ich bin mit den Autoren einverstanden, dass Leute die das Programmieren lieben und dies auch in ihrer Freizeit (und teilweise sogar gratis) machen, sicher gute Kandidaten für den Programmierjob sind – Leute mit Leidenschaft sind sicher sehr gesucht.
• GET WELL ROUNDED INDIVIDUALS – Schnell lernende Generalisten sind verwurzelten Spezialisten vorzuziehen. Gerade kleine Teams sind auf Personen angewiesen, die die verschiedenen Hüte tragen können.
• YOU CAN’T FAKE ETHUSIASM – Glückliche und durchschnittliche Leute sind frustrierten Genies vorzuziehen. Leute die Fragen stellen, sind interessiert und oft lösungsorientiert.
• WORDSMITHS – Wenn du die Auswahl hast dann zieh gute Schreiberlinge vor. Effektives und präzises Schreiben und Bearbeiten führt zu effektivem und präzisen Code, Design, und Kommunikation.

Das nächste Mal geht es um „Interface Design“, „Code“, „Words“, „Pricing and Signup“, „Promotion“ und „Support“. Bin gespannt auf jegliches Feedback zur heutigen Ausgabe!!

Teil 1 der Zusammenfassung – Teil 3 der Zusammenfassung

Werbung