XING Handzeichen – jetzt haben auch wir Menschen unser Erkennungszeichen

Vulkanier	Menschen
		Nachdem wir von Mister Spock Wissen, welches das Handzeichen der Vulkanier ist (\ || || – siehe Foto links), haben wir Menschen nun auch endlich unser eigenes Erkennungszeichen (X). Gratuliere Lars, tolles Video!! Are you XING?

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

ResizR – eine Erfolgsgeschichte!

Lord Lance hat am 09.09.06 eine kleine, nette Applikation ins Netz gestellt, die es erlaubt ein lokales Bild oder ein Bild aus dem Internet zu verkleinern oder zu vergrössern – der ResizR. Die Software an sich ist sehr sehr sehr klein und überhaupt nicht aufwendig – der grösste Aufwand war das Design des Benutzerinterfaces. In ein paar Nachtschichten als Betatester und Ideen-Challenger habe ich die (kurze!) Entwicklung hautnah miterlebt. Die Idee war dem Benutzer eine einfache und alltägliche Funktion zur Verfügung zu stellen und siehe da – das Teil geht ab wie blöd – über 8’000 Visits im Tag – auf der Titelseite von Digg - in den Topeinträgen von Delicous und Technorati. Lance hat den Besucheransturm dokumentiert [1] [2]. Gratulation! Eine Paradebeispiel für Web 2.0 und den viralen Effekt - Wahnsinn! Faszinierend wie einfach es eigentlich ist eine grosse Masse zu begeistern und die entsprechende Aufmerksamkeit zu generieren. Eine gute Idee und eine entsprechende Disziplin und Effizienz beim Ausführen – siehe auch Getting Real (Prozesse – Done).

Microsoft Profitabilität – Das sollte man sich leisten können ;-)

Jemanden von seiner Idee überzeugen – Vorsprechen bei Venture Capitalists

Heidi Rozen (Mobius Venture Capital) erklärt in 3 min. 39 sec. auf was man achten soll, wenn man jemanden (in ihrem Beispiel ein Venture Capitalist) von seiner Idee überzeugen will:

• Glaubwürdigkeit aufbauen – früher hatte ich und heute tue ich. Der Zuhörer muss einen logischen Zusammenhang sehen zwischen dem was man gemacht hat und wo man Erfahrungen gesammelt hat und dem was man heute verkaufen will.
• Die Idee verständlich rüberbringen - ein Mehrwert muss klar ersichtlich und für alle verständlich sein (Achtung: Wer sind meine Zuhörer?).
• In Kürze die Idee auf den Punkt bringen – Oft bleibt nicht viel Zeit. Üben die Idee innert kürzester Zeit klar zu formulieren (elevator pitch). Falls mehr Zeit bleibt, kann man immer noch ausholen.
• Meeting kontrollieren – klare Struktur, Vorbereitung und Agenda hilft stehts die Kontrolle zu haben. Nicht dass das Meeting vorbei ist und die Idee noch gar nicht rübergekommen ist. Freundlich aber bestimmt.

Did you know und Net Neutrality

Bin heute auf folgendes Video gestossen: Did you know?. Es passt hervorragend zu meinen aktuellen Tätigkeiten und zeigt ein paar eindrückliche Zahlen und Fakten zu Themen wie Technologie, China, Klassenzimmer, etc. – Now you know!

Und wenn wir doch gleich bei China, Internet, Technologie sind, hier der Aufruf von Tim Berners-Lee zur Netzneutralität.

Games – die Faszination von Spielewelten

Unter dem Namen “Dream Machines” hat das Wired Magazin im April 2006 einen Artikel rund ums Games und deren Faszination publiziert. Spiele (und dazu gehören auch Computerspiele – Games) sind doch etwas wunderbares – nachdenken, wagen, knobeln, unterhalten, kooperieren, ausprobieren, kommunizieren, erleben, helfen, etc.

Macht Spielen Sinn? Jeder muss selbst entscheiden, ob er einen Teil seiner Freizeit mit dem Spielen und/oder Gamen verbringen möchte (jawohl, auch Erwachsene!!). Dabei gibt es eine einfache Testmethode (funktioniert bei fast allem ): Wie fühle ich mich nach dem Spielen? Wenn es sich gut anfühlt und da es niemandem schadet -> los! Dann muss es doch etwas Gutes sein!

Meine persönliche Rangliste der Unterhaltungsmedien: 1) Spielen (z.B. Brettspiele) 2) Gamen (Computerspiele) 3) Buch lesen 4) Fernsehen. Auffallend ist dabei der absteigende Anteil der Interaktion… Zufall?

Im Zusammenhang mit meiner Arbeit interessiert mich vor allem die Kombination aus Spielen und Lernen – ein magisches Duo!

Nachfolgend ein paar Stichworte/Zitate aus dem oben erwähnten Artikel:

• Schon als kleine Kinder spielen wir – dabei lernen wir!
• Spiele ermöglichen die Fantasie auszuleben.
• Je grösser die Kindern werden, desto komplizierter werden die Spiele und werden mit neuen Regeln und Zielen erweitert.
• Die neue Generation von Kindern wächst heute oft mit Games auf – dabei lesen sie keine Anleitungen, sondern probieren einfach aus – trial and error.
• Bei Spielen stellen wir Hypothesen aus, wir experimentieren und analysieren – dies im Gegensatz zur linearen Lernweise der vorherigen Generationen
• Durch diese andere Denkweise sollte sich auch die Art und Weise ändern, wie wir in der Schule lernen. z.B. sinnvolle Einbindung von Technologie im Klassenzimmer!
• Nicht nur zu sehen – selber Spielen! Es ist etwas ganz anderes zu zuschauen oder selber zu spielen – die Faszination ist oft nur nachvollzienbar, wenn man selber probiert und mitfiebert.
• Spiele erlauben uns gefahrlos Optionen auszuprobieren – jeder kann seinen eigenen Weg gehen.
• Aktuelle Spiele erlauben es uns eigene Welten zu kreieren und mit diesen zu interagieren – wir schreiben eine eigene Geschichte
• Games vereinen sämtliche Aspekte der Unterhaltungsmedien – Geschichten erzählen – Musik hören – Video schauen – Herausforderungen suchen und annehmen – Kommunkation und vor allem Interaktion mit anderen Menschen!

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

Pisa und der Einfluss vom Einsatz von Computern im Klassenzimmer und zu Hause

Vor ein paar Wochen habe ich wieder einmal ein paar aktuelle Berichte zum Thema Einsatz von Computern im Klassenzimmer gelesen. Ganz spontan hätte ich vermutet, dass der Erfolg oder Misserfolg des Einsatzes von Computern im Unterricht und zum Lernen von zu Hause doch alles eine Frage des Masses ist und ohne Einsatz von Technologie wahrscheinlich ebenso wenig erreicht wird, wie durch den übermässigen Einsatz.

Die Regierung und die Eltern investieren dabei viel Geld in der Hoffnung, die Bildungschancen der Schülerinnen und Schüler zu verbessern. Und nun deutet eine Analyse der Pisa-Studien darauf hin, dass diese Hoffnung weitgehend vergebens ist. Je grösser die Verfügbarkeit von Computer, desto schlechter die Schülerleistungen…

Die Kritik am Einsatz von Computern weist dabei auf drei Ursachen hin, die ich kurz (es gäbe dazu Bücher zu schreiben…) aus meiner (subjektiven) Sicht kommentieren möchte:

1. Die Interaktion zwischen Lehrer und Schüler werde eingeschränkt und das kreative Denken werde zu wenig stark gefördert
   –> Wenn ich mich noch richtig an einige Lektionen meiner Schulzeit erinnern kann, dann hätte die Interaktion kaum kleiner sein können, als wenn ich eine Stunde vor dem Fernseher gesessen hätte. Ein geschickter Einbezug des Computers in den Unterreicht kann die Interaktion sogar immens erhöhen (Stichwort Wiki, Podcast, Weblog/Blogs). Dass Computer das kreative Denken fördern, können die meisten Eltern bestätigen, die schon einmal Kinder am Computer arbeiten gesehen haben – es sprudelt nur so von Faszination, Analysen, Interaktion, Ideen, usw.
   
2. Durch die Anschaffung von teuren Computern muss an anderen Ecken (z.B. Lehrbücher) gespart werden
   -> Daran lässt sich wohl nicht rütteln. Klar geht das Eine auf die Kosten des Anderen. Doch durch den Einbezug des Internets wird enorm viel Material frei zugänglich ist für alle (z.B. Wikipedia), ohne dass man entsprechend teure Bücher und oder CD-Roms kauft. Idealerweise werden bei der Anschaffung von Computern Lerninhalte gleich mit einbezogen. D.h. es werden Gesamtlösungen angeschafft und nicht einfach Technologie ins Klassenzimmer gestopft. Der Einsatz von Technologie muss von Anfang an in den Lehrplan mit einbezogen werden.
   
3. Das Ablenkungspotential gerade durch das Internet und Computerspiele ist enorm gross
   -> Richtig. Wichtig ist daher, Regeln für die Benutzung von Computern zu definieren. Gespielt wird grundsätzlich in der Freizeit und nicht während dem Unterricht. Ausser das Spielen wird mit dem Lernen verbunden, was übrigens eine höchst spannende und effiziente Art des Lernens darstellen kann. Der Zugriff auf das Internet muss gezielt gesteuert werden, d.h. der Lehrer sollte die Möglichkeiten haben, das Internet zu sperren oder noch besser vordefinierte Seiten freizuschalten oder zu sperren. Ebenfalls wäre es gut, wenn der Lehrer die Benutzung entsprechend überwachen kann. Gerade für diese Problematik der Ablenkung bieten wir bei GenevaLogic mit Vision (Begleitung und Überwachung) und Surf-Lock (Internet sperren und gezielt freigeben) und App-Control (Applikationen exklusiv freischalten) gezielte Lösungen an.

Dabei scheinen Computer auf den ersten Blick einen positiven Einfluss auf die Resultate der Pisa-Studie zu haben. Bei dieser voreiligen Analyse wurde jedoch der wirtschaftliche und soziale Hintergrund der Schüler und der Schule nicht berücksichtigt. Unter Beizug dieser Variablen wird der Zusammenhang zwischen Computern und PISA-Leistungen sehr klein und statistisch insignifikant. Ein Hauptgrund für den teilweise sogar negativen Effekt ist, dass Computer zu Hause nicht in erster Linie zum Lernen genutzt werden. Wenn erstaunt dies?

Die Schlussfolgerung aus den diversen Berichten zeigt, dass ein vernünftiger Einsatz von Computern durchaus zu positiven Ergebnissen führen kann – sofern diese richtig und im Mass eingesetzt werden. Wie sagten schon unsere Eltern? Alles ist gesund – es ist nur eine Frage des Masses