Ein sehr lesenswerter Beitrag von einem erstaunlichen Team: 37signals: Getting Real, the book.
37Signals ist eine kleine Agentur zwischen Kopenhagen (1 Person) und Chicago (4 Personen, Stand Ende 2005), die sich -- nach ein paar Jahren "Webdesign" -- Erstellung und Betrieb von kleinen, simplen und extrem fokussierte Anwendungen auf die Fahne schreibt. Oder wie deren Tagline sagt: "Join us and say goodbye to bloated software". So nebenbei schuffen sie als Grundlage für ihre Arbeit noch das trendige Framework Ruby on Rails. Beispiele für solche minimalistische Anwendungen sind Basecamp, Backpack oder Ta-da List. Allesamt extrem sehenswert.
Nun zum aktuellen Buch (Erstlingswerk war Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points). Damals wurde das Buch noch mit einem Verlag produziert und physisch verkauft. Und nun Getting Real, the book.
Erstens: Distribution und Verkauf. Das Ding gibt es nur als PDF und nur Online zu kaufen. Nach 75 Tagen wurde das Buch online über 10'000 mal verkauft (eins davon bei mir). Preis mindestens 19 USD. Schöner Businesscase (wenn auch nur möglich mit einer extrem technologie-affinen Zielgruppe).
Zweitens: Inhalt. Kurze, prägnante und witzig formulierte Aussagen dazu, wie die Agentur geführt und gelebt wird, zum Entstehungsprozess der Produkte, deren Marketing und vor allem dazu, wie Software-Projekte (und deren Projekte) schlank bleiben. Ein paar Muster.
"There's a myth that goes like this: we can launch on time, on budget, and on scope." Der Tipp: Termin und Kosten einhalten und wenn es eng wird, den ursprünglichen Umfang reduzieren. Kann ich voll unterschreiben. Das Ding auf den Markt bringen (daher der Titel: Getting Real) und damit echte Gegebenheiten in die Weiterentwicklung einbeziehen.
Tipp: "Lower Your Cost of Change". Da sich sowieso alles dauernd verändert, Flexibilität wahren. Hier ist natürlich auch ein Votum für ihren Ansatz mit der Skriptsprache Ruby zu arbeiten drin. Auch hier bin ich bei den Autoren. Sehr nobel wenn die Kosten damit auch tief bleiben. Ich finde es schon sehr gut, die Anwendung dauernd zu releasen (Skripting) oder mindestens jede Nacht die vollständige Anwendung automatisiert zu erstellen (Compiling).
Tipp: "Don't waste time on problems you don't have yet". Ja (endlich hat es noch jemand öffentlich geschrieen). Auch dazu passend ist: "Scale Later...If you've got a huge number of people overloading your system then huzzah! That's one swell problem to have.". Und ganz in der Nähe der nächste Tipp.
"People often spend too much time up front trying to solve problems they don't even have yet.". Bei uns heisst das Pragmatismus. Das genutzte Beispiel ist sehr schön. Die Anwendung Ta-da List wurde öffentlich verkauft, bevor es ein Abrechungssystem gab. Es bleibt somit ja noch fast ein Monat Zeit zum entwicklen.
Tipp: "Actions, Not Words". Hier gibt es nicht mehr dazu zu sagen. Noch krasser formuliert also "There's Nothing Functional about a Functional Spec. Functional specs force you to make the most important decisions when you have the least information". Ja, hat aber sicher mit Projektgrösse und Entscheidungsprozesses zu tun. Da bei 37 Signals alles durch drei Leute gemacht wird, tut das auch gut.
Tipp: "Make signup and cancellation a painless process". Das hätte ich mit bei meinem (verflossenen) Cablecom-Anschluss auch gewünscht ;-)
Und hier noch mein Liebling:
Tipp: "Don't be a yes-man... Make each feature work hard to be implemented...That's why you start with no. Every new feature request that
comes to us - or from us - meets a no.... If a request for a feature keeps coming back, that's when we know it's time to take a deeper look." Somit ergibt sich die folgenden "Vorgehensmethodik":
1. Say no.
2. Force the feature to prove its value.
3. If "no�? again, end here. If "yes,�? continue...
4. Sketch the screen(s)/ui.
5. Design the screen(s)/ui.
6. Code it.
7-15. Test, tweak, test, tweak, test, tweak, test, tweak...
16. Check to see if help text needs to be modified.
17. Update the product tour (if necessary).
18. Update the marketing copy (if necessary).
19. Update the terms of service (if necessary).
20. Check to see if any promises were broken.
21. Check to see if pricing structure is affected.
22. Launch.
23. Hold breath.
>> Wirklich lesenswert. Hier kaufen und auch lesen.
