Als wir am Sonntag in die Eifel fuhren, stand für mich fest: Am Dienstag (07.10.) werden wir wenigstens eine kleine Zahl an externen Leuten einladen, um einen Blick auf What’s up Team zu werfen. Eine Frage der Ehre, wir haben ordentlich Gas gegeben und und kaum eine Pause gegönnt. Und grundsätzlich haben wir unser Ziel erreicht: Nach gut zwei Tagen standen das Grundsystem, die Anmeldung und auch in die Nutzerführung hatten wir bereits etwas Zeit investiert. Das erste Feedback im Facebook-”Freundeskreis” fiel auch positiv aus und außerdem gab es kaum Fehler, über die unsere Tester gestolpert sind.
Um unserem eigenen Anspruch gerecht zu werden, haben wir auch nach den 48h noch Zeit in What’s up Team gesteckt. Mittlerweile sind wir aber zunächst zufrieden und arbeiten schon wieder an anderen Dingen. Wir werden WuT jetzt erst einmal einige Wochen nutzen wie es ist und dann gucken, wo wir noch feinjustieren. Außerdem sind wir natürlich offen für Feedback der anderen Nutzer.
Mein Fazit zu einer solchen Herausforderung fällt bislang durchweg positiv aus. Das Ausbrechen aus der alltäglichen Umgebung ist immer klasse, im ganzen Team aber umso besser. Hätten wir uns der Aufgabe im Büro gestellt, wäre es vielleicht ähnlich produktiv gewesen, hätte sich aber viel mehr nach Arbeit angefühlt.
Wie zu erwarten, waren die 48 Stunden und die 1-2 Tage danach aber voll mit Arbeit. Wir alle waren deutlich länger am Rechner, als an normalen Tagen und haben mit vereinten Kräften und immer an mehreren Baustellen gewerkelt. Das Teamwork war das Beste der 48-Stunden-Challenge.
Und was bleibt ist eine Software? Auch, aber nicht nur. Sven beispielsweise (nicht-Entwickler) hat natürlich noch nie eine Software gebaut oder die Entwicklung von Tag 1 an mitbekommen. Auch in unser Team kam er erst, als unsere beiden großen Produkte bereits aus dem Beta-Stadium raus waren. Auf unserer Rückfahrt aus der Eifel sagte er, dass die Erfahrung ihm einen neuen Blickwinkel gegeben hat.
Vermeintlich liegt der Fokus einer solchen Challenge ja auf der Entwicklung und klar: Ohne Entwickler geht es nicht. Für den Erfolg eines Produktes ist es aber umso wichtiger, dass der rote Faden stimmt. Dass die Idee an sich und natürlich die Funktionen im einzelnen klar und verständlich für den Anwender sind. Und gerade hier leisten nicht-Entwickler einen Beitrag UND können Software-Entwicklung live erleben. Sven sagte, was die Struktur und die Grundlagen einer solchen Lösung angeht, habe er sich nie zuvor so detailliert Gedanken gemacht. Zu verstehen, worauf ein solches System fußt und was wie zusammenhängt, ist aber durchaus hilfreich, wenn es um Vorschläge zur Nutzerführung und deren (technische) Machbarkeit und Sinnhaftigkeit geht.
Was hätten wir besser machen können? Einige Dinge hätte ich jetzt technisch anders umgesetzt, allerdings eher, weil es sich aus heutiger Sicht als klassisches Overengineering herausgestellt hat. Wir haben einige Funktionen flexibler (und damit komplizierter) gebaut, als sie sein müssten. Wir haben zum Beispiel eine Bitmap genutzt, um die Kombinationsmöglichkeiten der Wochentage abzubilden. In WuT kann man auswählen, an welchen Tagen die Frage zum Status Bericht verschickt werden soll. Das kann also jeden Tag, nur Mittwoch, Dienstag und Donnerstag usw. sein. In jeder Kombinationsmöglichkeit. Mit einer Bitmap-Berechnung bilden wir diese Kombinationsmöglichkeiten jetzt zwar sauber ab, für unseren Fall mit der immer gleich bleibenden Zahl an Wochentagen wär es aber auch einfacher gegangen. Das Bitmap Konzept ist zwar schön erweiterbar und sinnvoll für verschiedene Rechte (um ein Beispiel zu nennen), aber wie wahrscheinlich ist es, dass wir bald 8 Wochentage haben?
Außerdem hätten wir uns einiges an Arbeit sparen können, wenn wir beim Design auf Standard-Vorlagen wie Twitters bootstrap verlassen hätten. Dann sähe WuT jetzt aber auch so aus, das bedeutet 0815.
Zudem wollten wir eigentlich „english-only“ gehen, aber in Anbetracht der vielen kleinen deutschen Unternehmen, die wir zu unseren Kunden zählen, haben wir das System von Beginn an mehrsprachig entwickelt. Das macht es ebenfalls weder leichter, noch schneller.
Der Vorteil der begrenzten Zeit liegt ganz klar in der zwangsläufigen Priorisierung. Es ist schlicht zu wenig Zeit für unwichtige Funktionen, die irgendwann mal ganz nett wären. Und anstatt die Zeit in unnötige Funktionen zu stecken, haben wir uns lieber auf die wichtigen Ansichten konzentriert (Anmeldung, Einrichtung des Berichtes, E-Mails, Eingabe der Berichtsdaten und die Ansicht des fertigen Berichtes). Diese Schärfung des Fokus ist Gold wert und bleibt hängen.
Mich würde interessieren, wer ähnliche Erfahrungen gemacht hat im Rahmen von Hackathons oder eigenen Challenges.
