Dienstag, 27. Oktober 2009

Der nächste Schritt - Personas

Während mir schon recht lang klar war, wie wir in so einem Fall vorgehen werden, versuchte ich meinen Schulfreund nach und nach in die Materie einzuführen. Im nachhinein hat sich das als sehr nützlich erwiesen. Er kommt aus der Medizintechnik und hatte bislang kaum Berührungspunkte mit Software-Entwicklung, erst recht nicht für Internetanwendungen. Wir näherten uns also Schrittweise meiner Vorstellung, wie das Projekt abgewickelt werden soll.

Mein erster Schritt sollte es sein, Personas zu erarbeiten. Für mich ein unerlässliches Arbeitsmittel über den gesamten Zeitraum der Entwicklung habe ich ihm dieses Arbeitsmittel clever verkauft. Quasi als Anbieter der Software habe ich nicht vorgeben, dass wir mit Personas arbeiten, dass wir damit arbeiten, warum bla bla bla...

Mir war es wichtig, auch ein bischen reiner Selbstschutz, dass mein Schulfreund eine Vorstellung hat, wer an die Software verwenden wird, warum er dies tut und was für Aufgaben eine Person über die Software erledigen würde. Bis hierher hatte ich oft das Gefühl, dass wir recht visionär unterwegs waren. Mein Ziel war es, die Dinge mal auf den Boden zu holen. Wir haben gemeinsam den Blickwinkel stark verändert, von der Sicht des Produktherstellers mit starkem Vertriebsinteresse hin zur Sicht der Benutzer.

Wir entwickelten also Personas.

Bis hierher wurde Emails ausgetauscht. Über kurz oder lang verlor sowohl er als auch ich den Überblick. Kurzerhand habe ich alles auf Google Documents verschoben, unser erstes Arbeitsmittel mit Unterstützung verteilten Arbeitens.

Donnerstag, 22. Oktober 2009

In 3 Tagen lauffähige Software entwickeln - geht das, wie funktioniert das?

Beim letzten Scrum Breakfast Zürich konnte ich der agilen Community ein interessantes Projekt vorstellen.

3-2-1 Live! Rapid Development.

Namics hat im August 2009 gemeinsam mit der Adhoco GmbH, Winterthur ein Projekt der besonderen Art abwickelt. Ein interdisziplinäres Team, dass sich nicht kannte und so noch nie zusammengearbeitet, hat sich das ambitionierte Ziel gesteckt, lauffähige Software in 3 Tagen zu realisieren, wobei zu Beginn nur ein Idee im Raum stand!

Das Team, bestehend aus dem CEO/Adhoco als Product Owner, 1 Entwicker/Adhoco, 2 Entwicklern/Namics, einem ScrumMaster/Namics und einer UI Designerin/Meyer-Hayoz Design Engineering, führe in der gegebenen Zeit Interviews durch, erarbeite Personas und User Stories, entwarf UI Prototypen, Wireframes und realisierte letztendlich ein Web Applikation, die für das iPhone optimiert wurde.

Im Vortrag wurden fünf Fragen beantwortet:

  • Wie kommt man von einer Idee zur Vision?
  • Wie sammelt man benutzerorientierte Anforderungen?
  • Wie stellt man den ersten Release zusammen?
  • Wie geht man bei der Umsetzung vor?
  • Wie geht man erfolgreich live?

... und natürlich wurde das Ergebnis gezeigt. Eine spannende Diskussion folgte auf den Fuss.

Klingt spannend? Dann studieren Sie die Unterlagen zum Vortrag ...

NAM-3-2-1-Live-RapidDevelopment-20091006-v1-1.pdf

Montag, 19. Oktober 2009

Pay Per Use

Im letzten Beitrag habe ich die derzeitigen Marktgegebenheiten erläutert und das Geschäftsmodell kurz angerissen. An dieser Stelle sei erwähnt, dass neben der Software eine komplett neue Hardware entwickelt wird, ein digitales Endoscop - EOSCOPE. Wie in der Medizintechnik so üblich wurde die Idee mit vielen Patenten geschützt und über Partner und eigenen Mitteln finanziert. Ich nenn' das mal StartUp.

Quasi mit leeren Taschen stand mein Schulfreund dann vor mir und fragte mich:
Was kostet dass, wenn man so eine Anwendung baut?
Bis zu diesem Zeitpunkt war ich meiner Wahrnehmung nach nicht als Software Entwickler angesprochen, sondern eher als guter Zuhörer, als Partei zum challangen der Idee und Vision, als Berater - wie auch immer. Es war recht abstrakt, wenig greifbar und hatte irgend wie auch nichts mit mir zu tun. Als er danach fragte, ob ich ihm helfen könnte und wie ich mir eine Bezahlung vorstellte, änderte sich alles.

Wie einen Schalter, den man umlegt - ich wusste wie es geht, wie man vorgeht, welche Schritte man macht, in welcher Reihenfolge, wie es funktionieren wird und wann es nicht funktioniert. Ich hatte für jede Frage eine Antwort, ausser was es kostet und wie lange ich brauchen werde.

Mein Schulfreund, leicht irritiert, meinte, dass kann doch nicht so viel Arbeit sei, er stelle sich das recht einfach vor. Mein Gedanke war, und ich erinnere mich recht gut daran: Kein fixer Scope und keine fixe Zeitvorgaben - Aufwandschätzung unmöglich.

Wie im Vaakuum kam ich mir vor, als ich meinem Schulfreund versuchte zu erklären, dass Software Entwicklung nicht auf ein paar netten Gesprächen basieren kann. Man müsse schon etwas mehr in der Hand haben. Ausserdem kann das schnell recht teuer werden, den Standartsoftware kommt wohl nicht in Frage ;-)

Nach einer Weile und etwas mehr Verständnis für meine Situation kam er mit einem recht attraktiven Model. Letztendlich ist die Investitionssumme für die Software nicht wichtig. Wichtig ist, dass sie ein integraler Bestandteil der Pay Per Use Philosophie ist das man auch über Beteiligungen regeln kann. Pssst .....

Viel mehr möchte ich hierzu nicht erörtern -nur soviel: Wir haben ein Agreement gefunden. Eine Dimension des magischen Dreieck ist damit fixiert, oder relativiert: Budget.

Bleiben Scope und Time.

Freitag, 2. Oktober 2009

Ein neues Projekt - ProjekDE

Ein guter Schulfreund arbeitet schon seit Jahren an einer Idee, die die Medizintechnik revolutionieren soll, ein Markt, in dem ich mich bisher nur begrenzt auskannte. Hin und wieder trafen wir uns eher im privaten Umfeld, tranken ein paar Bier, sprachen von alten Zeit und mehr und mehr kam von seiner Seite Fragen zu meinem Beruf, was ich genau mache und ob ich mir vorstellen könnte, etwas für ihn zu entwickeln.

Im Herbst 2008 habe mich erstmalig genauer mit seiner Idee auseinandergesetzt. Warum soll es gehen?

Er hat mir an recht einfachen Beispiel erklärt, wohin die Reise geht - sagen wir mal das Business Konzept hatte ich begriffen, vorerst. Soweit ich das heute noch nachvollziehen kann, war sein Wunsch eine Anwendung im Internet zu haben, bei der man sich Anwendungscodes freischalten kann. Was das bedeutet und wozu man das braucht werde ich versuchen zum Besten zu geben.

Heute ist es in der Medizintechnik so, dass Geräte inventarisiert werden. Ein Krankenhaus kauft diverse Geräte, die für den Betrieb erforderlich sind. Da diese Geräte recht teuer sind, kann man mit entsprechend langer Lebzeit rechnen. Wie skaliert das Geschäft für die Gerätehersteller? Gar nicht. Man hat dennoch einen Weg gefunden, das Geschäft mit den Krankenhäusern aufrecht zu erhalten, denn die Menge der Krankhäuser ist endlich und schrumpft. Eines der Wundermittel sind sogenannte "Disposables", Wegwerfprodukte, die stehen. Andererseits gibt es auch Austauschkompononten die bei den teuren Gerätschaften zum Einsatz kommen. Zusammenfassend kann man feststellen, dass einerseits Krankenhäuser über die Motivation des Substanzerhalts selten neue Geräte anschaffen, die die sie bereits besitzen recht teuer Instand halten(müssen) und währenddessen viel Geld für Disposables ausgeben - andererseits verschafft diese Situation den Herstellern ein recht angenehmes Dasein. Krankenhäuser sind heute vielerorts in fester Hand von Herstellern. In Amerika geht man soger soweit, dass der Hersteller dem Krankenhaus nicht nur Gerätschaften, sondern ganze OP-Säle vermietet, sogar mit Personal - wenn gewünscht.

Als mein Schulfreund mir diese Geschichte erzählt hatte, war ich der Meinung ich hätte alles Verstanden - alles klar! Und was bauen wir nun genau? Er hat mit folgender Metapher seine Vison vorgestellt.
"Du kennst doch Prepaid Handies?"
Ja klar, und?
"Und Leasing-Modell bei Autos ist Dir auch bekannt?"
Im Kern stützt sich die Idee auf die Annahme, dass Krankenhäuser nicht länger teure Geräte kaufen, diese Inventarisieren und damit Kapital langfristig binden. Der Budget-Druck in den Krankenhäusern ist gross und wird steigen. Daher werden Krankenhäuser ein Interesse haben Investitionskosten zu reduzieren, wenn nicht gar abzuschaffen. Wie wäre es also, wenn man ein Gerät ähnlich einem Prepaid-Handy leihen könnte und nur für die Anwendung selbst zahlt? Und wie wäre es, wenn man zusätzlich das gesamte Serviceportfolio des Herstellers beanspruchen könnten, z.B. Rückgabe, Umtausch, Garantie, Services, etc. - ohne aber ein Grundbetrag zu bezahlen? Spielt man ein bischen mit dieser Idee wir schnell das Mischkonzept von Prepaid, quasi abzahlen auf Raten mit anschliessendem Übergang in Besitz, und Leasing klar - Pay Per Use!

Meine Aufgabe sollte es sein, eine Internetanwendung zu entwickeln, die den Geschäftsprozess für Pay Per Use unterstützt.