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.

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

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.

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.

ProjectDE

Hallo agile Gemeinde,

es ist ein bischen ruhig geworden auf meinem Blog, hm. Aus guten Grund.

Ich arbeite gerade neben meinem eigentlichen Job bei Namics mit einem Freund an dessen Internet-Idee: ProjectDE. Irgendwann muss ich mal was darüber schreiben, ich weiss. Kommt noch, ganz sicher.

Heute möchte ich nur kurz einen Vorgeschmack geben, was da so geht.Darf ich vorstellen, der Product Owner:

Hi Johnny,

Wollte dir noch sagen, dass ich noch nie erlebt habe, dass jemand ein Projekt so professionel, kreativ und weitsichtig lebt, wie du.

Du hast was großes geschaffen - kannst stolz sein!

Gruesse, Marc

Von meinem iPhone gesendet

Rapid Development Vortrag im Zug Zürich-Landquart

Zusammen mit David Nydegger, mein Arbeitskollege bei namics, haben wir an der Orbit 2009 einen Vortrag zum Thema "Rapid Development" gehalten. Die Vortrag war nicht gratis - 130 CHF Eintritt pro Person waren fällig. Immerhin hatten sich trotzdem 19 Teilnehmer eingefunden.

Als David und ich uns an diesem Tag auf den Weg machten, wurden wir von vielen namics Mitarbeitern gefragt, ob wir denn nicht noch ein paar Freikarten hätten - sie würden den Vortrag auch gern sehen. Nun, wir hatten leider keine. Also versprachen wir, den Vortrag intern nochmals zu halten.

Da bislang kein Termin gefunden werden konnte, sind David und ich kurzhand auf den Zug ausgewichen, denn namics reist am kommenden Donnerstag den 04. Juni nach Davos - namics camp09. Also nutzen wir die Zugfahrt und machen unseren Vortrag mobil ...

Wer unseren Vortag "Rapid Development" an der Orbit09 verpasst haben sollte und gern mit dem Zug durch die Schweiz reist ist hiermit eingeladen teilzunehmen.

Der Zug fährt ab 11.37 ab Zürich HB. Der Vortrag beginnt um 11.45. Besammlung vorher auf Gleis 8.

Rolle vs. Persona - Warum sind Personas wichtig?

Es gibt unterschiedliche Möglichkeiten Anforderung für eine Software zu erheben. Bei agilen Projekten wählt man häufig einen User Centered Ansatz und beschreibt Anforderungen aus Benutzersicht - so genannte User Stories. Soll man Benutzer mit Rollen verallgemeinern und zusammenfassen?

Geschäftsmodelle im Internet funktionieren, wenn man den Nerv der Benutzer trifft und dessen Erwartung erfüllt. Ein Internetauftritt, eine Anwendung oder ein spezielles Angebot - es soll eine ganz bestimmte Zielgruppe angesprochen werden. Kennt man die Zielgruppe, weiss wie man sie anspricht oder was gar abschreckende Wirkung hat - kann man das Angebot entsprechend ausrichten.

Am Beispiel einer Kampagne der PostFinance möchte ich zeigen, dass es durchaus wichtig ist, sich mit den realen Benutzern und deren Erwartungen auseinander zu setzen.

Zahle CHF 50 an 24-9779-8

Um nicht die gesamte Kampagne zu erzählen würde ich die Ausgangslage als User Story so formulieren:

Ein Kunde möchte mit seinem Mobiltelefon per SMS Überweisungen tätigen können.

Ein Kunde. Ein Kunde ist in diesem Fall eine Aggregation, eine Rolle in die der Benutzer schlüft. Jungendliche, Berufstätige, Schüler, Studenten - das könnten alles Kunden sein. Mit dieser Verfeinerung hat man die Rolle bereits etwas geschäft. Man kann noch ein Schritt weitergehen und Personas konzipieren, die einer realen Person entsprechen.

Angenommen Andreas ist Kunde der PostFinance. Er ist Mitte dreissig, Handelsreisender, keine Familie, sportlicher Typ.
Andreas wird es sicher begrüssen, wenn er irgendwo auf der Welt von unterwegs per SMS Überweisungen tätigen kann. Er hat praktisch keine Zeit für Hausbesuche bei seiner Bank und Internetzugang gibts auch nur beschränkt. Würde man Andreas zu SMS Überweisungen befragen, würde er sicher begeistert sein - ein Exciter, ein WOW Feature.

Nimmt man hingegen Peter, kann das ganz anders aussehen.
Peter ist IT-Sicherheitsbeauftragter, 44 Jahre alt, Familie mit 2 Kindern, ebenfalls sportlicher Typ. Würde man Peter zu SMS Überweisungen befragen, hätte er sicher etwas gegen ein solches Feature, denn er weiss, dass SMS in Klartext verschickt werden und ein gewisses Risiko der Manipulation besteht. Ein absolutes No Go! Er würde das Online-Banking Angebot nicht nutzen, wenn man dieses Feature anbietet.

Das Beispiel zeigt fiktiv, wie man auf ganz unterschiedliche Empfindungen trifft, von WOW bis hin zur abschreckenden Wirkung. Es ist also wichtig, dass man sich ein Bild vom realen Benutzer macht. Darüber hinaus ist ebenso wichtig, dass man sich neben den Befürwortern auch Personas konzipiert, die das Angabot nicht gut finden oder es gar versuchen zu sabotieren.

Lean Agile Scrum Conference in Zürich am 4.Juni 09

Nach dem ScrumDay München 2009 gibt es nun am 04.Juni die "Lean Agile Scrum Conference" in Zürich, bei der ebenfalls Ken Schwaber anwesend ist und referiert - und das gleich mehrfach.

Das eintägige Programm der Lean Agile Scrum Conference am 04. Juni 09 in Zürich sieht gleichermassen wertvolle Vorträge vom Fachbeitrag bis hin zu Erfahrungsberichten zu den Themen Lean, Agile und Scrum vor.

Ken Schwaber beginnt mit der Keynote "Done and undone" und tritt am Mittag nochmals mit dem Vortrag "State of Scrum" vors Mikrofon. Anschliessend hat man die Möglichkeit am Ken Schwaber Seminar "ScrumBut Workshop" teilzunehmen (# Teilnehmer begrenzt).

Von der Software-Entwicklung bei der Zahnärztekasse AG über Projekte mit einer Agile-Wasserfall-Mischform bis hin zu Management-Praxis Tracks in Grossunternehmen - es ist sicher für jeden Teilnehmer etwas dabei.

Veranstaltungsinformationen:

4. Juni 2009
Von 8:00 bis 17:30 Uhr
ETH Zürich, Gloriastrasse 35, 8006 Zürich
http://www.swissict.ch/vomhypezurpraxis

3-2-1 Live - Rapid Development à la carte

seeflu.com - eine Webapplikation bauen in weniger als 48h Dank Rapid Development.

Wie seeflu.com vormacht, kann man innerhalb von 48h von einer Idee zur lauffähigen Applikation kommen. Ich möchte kurz erläutern, wie das geht ...

Zu Beginn gab es eine einfache Idee. Dem Vater des Gedanken folgten recht schnell ein paar fixe Köpfe die meinten, da müssen wir was machen und ich mach' mit.
So fanden sich 4 Personen unterschiedlicher Kompetenzen:

• ein Konzepter und Designer
• ein Experte für Online-Kommunikation
• zwei Entwickler

Schnell wurde die Idee manifestiert und ein Mission Statement erarbeitet. Hilfestellung dafür waren folgende Fragen:

• Was wollen wir machen?
• Für wen wollen wir das machen?
• Warum wollen wir das machen?

Nach kleinen Diskussionen und viel Brainstorming wurde folgendes Mission Statement definiert:

"Covering everything there is to know about swine flu"

Davon ausgehend liess sich die Menge der möglichen Domains einschränken und so wurde schlussendlich seeflu.com reserviert.

Das Team hat den Funktionsumfang umrissen - Brainstorming. Dabei wurden gute und wichtige Funktionen entwickelt. Angesichts der kurzen Zeit wurde der Umfang für den ersten Release extrem heruntergefahren.

Kurzerhand wurde eine Informationsarchitektur entwickelt, ein Logo kreiert und ein einfaches Design entworfen. Die beiden Entwickler haben dies umgesetzt und ...

... nach 48h ist die Applikation heute live gegangen! seeflu.com

Scrum Day 2009 mit Ken Schwaber in München

Ken Schwaber macht auf seiner Scrum Tour durch Europa auch in München halt - SCRUMDAY 2009.

Am 06. Mai 2009 findet in München ein eintägiger SCRUMDAY statt. Eingeleitet wird der interessante Tag mit der Keynote "Scrum, but ..." von Ken Schwaber, Mitbegründer von Scrum. Das Tagesprogramm sieht weiter Vorträge in parallelen Slots a 1h vor - Erfahrungsberichte, etwa der Allianz Deutschland AG, ImmobilienScout24 und AutosScout24, werden ebenso angeboten wie fachliche Vorträge rund um das Thema Scrum. Zwischen den Vorträgen wird Freiraum für Fragen, Antworten und spannenden Diskussionen geboten.

Vor dem Scrum Day 2009 in München kann man am 04. und 05. Mai den Certified ScrumMaster Kurs direkt mit Ken Schwaber belegen, sicher spannend.

Sie haben Interesse an agilem Projektvorgehen oder haben bereits nach Scrum gearbeitet und haben viele, viele Fragen? Dann empfehle ich beim Scrum Day 2009 in München vobeizuschauen:

Veranstaltungsort:
NH München Dornach - München
Einsteinring 20
85609 Aschheim-Dornach
Telefon: +49 89 / 940096 0
Fax: +49 89 / 940096 100
Internet: http://www.scrum-day.de

Wann sollte man NICHT agil arbeiten?

Immer wieder stellt sich bei einen neuen Projekt die Frage, wie man vorgehen soll/möchte. Scrum und agil um jeden Preis - ich habe viel Lehrgeld bezahlt :), Heute würde ich mich intensiver mit dem Projekt-Ökosystem auseinandersetzen, bevor ich agil arbeiten möchte.

Kelly Waters fasst das auf seinem Blog so zusammen: "... 3 reasons why I wouldn't do agile software development:

1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.

2. If I was working for an organisation where the relevant product owners couldn't - or wouldn't - commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.

3. If I was working with a team that I didn't believe could cope with ambiguity, or didn't have sufficient communication skills to collaborate effectively with business colleagues or customers.

In these circumstances (particularly if combined), adopting agile could be very difficult indeed, because in my experience these 3 agile principles are critical success factors! " Kelly Waters

Die Punkte 1 und 3 finden fast immer positive Zustimmung, Punkt 2 allerdings ist bei meinen Projekten oft das Zünglein an der Waage ...

namics ist an der Orbit mit dem Thema: Rapid Development

Rapid Development - Wie Sie mit agiler Softwarentwicklung Ihr Webprojekt schnell zum Erfolg bringen können.

Erfolgreiche Start-Up Firmen im Web-Umfeld haben schlicht keine andere Wahl: Mit begrenzten Ressourcen einen frühen Time-to-Market zu erreichen, ist für sie der kritische Erfolgsfaktor, um mit einer neuen Webapplikation im harten Wettbewerb bestehen zu können. Dabei nutzen Start-Ups oft Methoden und Prozesse aus der agilen Softwareentwicklung. Diese können auch Sie für Ihr Webprojekt nutzen.

Jean-Pierre König und David Nydegger zeigen Ihnen mit der Präsentation "Rapid Development", wie Sie selber eine Idee schnell in eine laufende Webapplikation umsetzen können, ohne sich in endlosen Konzeptions- und Spezifikationszyklen zu verlieren. Anhand eines konkreten Fallbeispiels erfahren Sie,

• wie man von einer Idee zu einer Vision kommt
• wie man effizient benutzerzentrierte Anforderungen sammelt und bewertet
• wie man bestimmen kann, was für Funktionen und Inhalte im Release enthalten sein sollen
• wie man während der Umsetzung stets Herr des Prozesses bleibt
• und wie man erfolgreich live geht.

Die Präsentation "Rapid Development" hält sowohl für ein technisches als auch für ein businessorientiertes Publikum interessante Erfahrungen und Beispiele aus der Praxis bereit.

Jean-Pierre König ist Senior Software Engineer bei namics und beschäftigt sich seit längerem mit agiler Softwareentwicklung. David Nydegger ist Consultant bei namics und konnte vorher Erfahrungen in mehreren Start-Ups im Internetumfeld sammeln. Bei namics treibt er das Thema Rapid Development aktiv voran.

Orbit:
Messezentrum Zürich
12. - 15. Mai 2009

Scrum Breakfast in Zürich, im März 09

Am 04. März 2009 findet erneut ein Scrum Breakfast in Zürich statt. Thema:

"Agile Methoden und Krisenmanagement in der Informationstechnologie"

Veranstalter:
SwissICT Fachgruppe Lean, Agile & Scrum

Daten:
Mittwoch, 4. März 2009
8:00 bis 10:00 Uhr, Vortrag 8:35 bis ca. 9:00 Uhr
namics ag, Konradstrasse 12, 8005 Zürich

Die Veranstaltung ist bereits ausgebucht, aber Teilnahme via Webinar ist möglich.

Scrum Breakfast in Zürich, im Februar 09

Am 04. Februar 2009 findet erneut ein Scrum Breakfast statt. Thema:

"Teambuilding" fürr agile Teams - OHNE etwas von "Teamdynamiken" verstehen zu wollen

Veranstalter:
SwissICT Fachgruppe Lean, Agile & Scrum

Daten:
Mittwoch, 4. Februar 2009
ab 08:00 Uhr
namics ag, Konradstrasse 12, 8005 Zürich

Details und Anmeldung

Wie würde ich agil meinen Eltern erklären?

Ich begebe mich an einem schönen Samstag morgen ins Autohaus mit der Absicht, einen Wagen zu kaufen. Im Verkaufsraum werden mir verschiedene Modelle gezeigt, der Verkäufer ist nett und nimmt sich viel Zeit. Jene vergeht und ich weiss, hier gefällt mir kein Wagen. Bei der Konkurrenz ist das ähnlich, da war ich bereits. Irgendwie sind das alles Standartprodukte, das möchte ich nicht.

Ich habe eine Vision von meinem Wagen und wenn ich mich umsehe, gibt es den nicht. Also bau' ich mir ihn selbst. Hinter dem Verkaufsraum, in der Entwicklung, Konzeption und Produktion werden sich meine Träume erfüllen!

Auf der Suche nach einem kompetenten Partner werde ich schnell fündig. Mir steht nun ein Team von Designern, Konstrukteuren, Modellbauern, Ingenieuren, Sattler, Qualitätsbeauftragten, Entwicklungsleitern und vielen anderen zur Verfügung. Alles Profies, versteht sich.

Ich treffe das Team zum ersten Mal, ich freu mich schon, denn sicher werden sie meine Vision vom perfekten Auto mögen. Ich bring den Elevator-Pitch hinter mich und ... wie ich vermutet hatte, MEIN Team ist begeistert! Es schauen ca. 20 Augen auf mich: Wo fangen wir an?

Nun, ich bin ein passionierter Autofahrer, weiss was ich möchte und wie mein Wagen in etwa aussehen soll. Wie man vorgeht weiss ich nicht. Ich habe keine Ahnung, also spiel' ich den Ball zurück und frage: Wie würden Sie vorgehen?

Wenig überrascht (ich hatte es ja erwartet) breitet sich die geballte Kompetenz der Anwesenden vor mir aus - he, die Jungs wissen, wie sie es geht. Also lehne ich mich zurück und verschaffe mir ein Überblick.

Jetzt hab' auch ich einen Plan, sehr gut! Ich treff' mich nun regelmässig mit meinem Team und sie zeigen mir den Fortschritt. Ich kann dann jeweils meine Meinung dazu geben und auch Veränderugen vornehmen lassen, z.B. beim Heck. Da bin ich mir sicher, dass es einige Designänderungen geben wird. Ich weiss nämlich noch nicht recht, wie es aussehen soll ...

In der Zwischenzeit ist ein Jahr vergangen und das Team hat hart gearbeitet, wir haben uns regelmässig getroffen und ich konnte bereits nach einem Monat ein Knetmodell in den Händen halten. Heute, nach 12 Monaten steige ich zum ersten mal in dem fahrbaren Prototyp. Ich freu' mich.

Wie machen die das? Nach 12 Monaten weiss ich immer noch nix darüber, wie man ein Auto baut, brauch ich auch nicht, denn mein Team weiss das. Ich vertaue dem Team, bekomme früh Feedback zu meinen Wünschen, weiss immer genau, wie lange man für die Umsetzung brauchen wird. Das Team berät' mich sogar.