Archive for May, 2013

Epen und Rollen

Posted on: May 27th, 2013 by Lukas Wandzioch No Comments

Schließlich müssen wir aber von der schönen realen Welt Williams und seinen Szenarien Abschied nehmen, und uns der kalten Welt der Informatik zuwenden. Wir müssen Laurin und seinen Entwicklern etwas geben, woraus sie Software bauen können. Ein Epos ist eine sehr große Geschichte, zu groß um in einem Sprint umgesetzt zu werden. Nur deswegen brauchen wir Epen. Stell dir eine Reihe von zusammenhängenden User Stories vor. Was ist eine User Story? Das werde ich in einem späteren Post erklären. Ok, ich fange doch jetzt schon an. Eine User Story ist die logische Beschreibung einer Funktion. Und jede User Story muss dem Nutzer einen realen Mehrwert liefern. Einfach. Ein Epos ist dementsprechend eine Aneinanderreihung von kleinen wertvollen Funktionen, die am Ende einen großen Mehrwert für den Nutzer bieten. Aber warum gerade User Stories, eine Grafik würde doch sicher auch funktionieren. Schon, aber für die logisch denkenden Entwickler ist die abstrakte Beschreibung anhand der Stories am einfachsten zu verstehen. Außerdem ist die Reihenfolge der User Stories wichtig, um die Sequenz der Tests festzulegen. Cool. End-to-end Tests mit Epen. Melde dich hier an! Und Rollen? Also William ist keine Rolle, sondern ein Lehrer (namens William). Eine Rolle ist abstrakter. Zum Beispiel haben wir die Rolle des ‚Lehrers’. William ist ein Lehrer, genau wie seine Kollegen in Berlin, Deutschland, Europa und überall sonst auf der Welt. Eine Rolle ist eine Sammlung von Verhaltensweisen die nur bei einer Gruppe von Nutzern auftreten. Eine weitere Rolle ist der ‚Schüler’. Lehrer stellen Hausaufgaben, Schüler beantworten Hausaufgaben. Das ist alles. Einfach.

Unsere Wettbewerber

Posted on: May 13th, 2013 by Oliver Wilken No Comments

Vor einem Jahr haben wir zum ersten Mal systematisch unseren Markt und unsere Wettbewerber analysiert. Ziel war damals einen groben Gesamtüberblick für den gesamten Bildungsmarkt auszuarbeiten. Dabei kam heraus, dass im Bereich Schulen eine Reihe etablierter Anbieter agieren. Große Namen sind Itslearning, Fronter und Moodle. Sie verfolgen ein top-down Modell bei dem sie ihre Lösungen explizit an Schulen vertreiben. Deswegen sind sie nur indirekte Konkurrenten.

Darüber hinaus gibt es eine Reihe weiterer Unternehmen, die ein scolibri-ähnliches Produkt anbieten und die wie wir mit einem bottom-up Ansatz individuelle Lehrer der Sekundarstufe ansprechen. Die vielversprechendsten Wettbewerber habe ich nun genauer unter die Lupe genommen. Um nicht betriebsblind an die Analyse heranzugehen wurde ich von Peter Merrick unterstützt. Er lehrt an der Berliner Nelson-Mandela-Schule und hat die Wettbewerber aus der Perspektive des Lehrers unter die Lupe genommen.

Systematik

Im ersten Schritt haben wir die Analysekriterien festgelegt. Dafür haben wir eine Liste mit verschiedenen Funktionen aus dem realen Schulleben aufgestellt, die Peter von einer Softwarelösung mindestens erwartet. Dabei haben wir bewusst nicht an einem Poweruser orientiert, sondern an einem durchschnittlichen Lehrer. Der minimale Funktionsumfang beinhaltet:

– Einen Lehrer-Account erstellen.

– Einen Kurs erstellen.

– 100% der Schüler zu dem Kurs hinzufügen.

– Hausaufgaben stellen.

– Hausaufgaben bewerten.

– Usw.

Im zweiten Schritt haben wir die Bewerber ausgewählt. Edmodo.com und Schoology.com sind von den Nutzerzahlen her die größten Anbieter in diesem Bereich. Dazu haben wir das Startup Lore.com einer näheren Betrachtung unterzogen, da es ein sehr ansprechendes User-Interface bietet.

Im dritten Schritt haben wir geprüft ob die einzelnen Funktionen unserer Liste bei den Konkurrenzprodukten angeboten werden, ob sie von unserem Lehrer Peter gefunden und auch benutzt werden können.

Im vierten Schritt haben wir die Ergebnisse zusammengefasst und bewertet. Ziel war es die Schwächen der Wettbewerber aufzuspüren und mögliche Stärken in unsere Produktentwicklung mit einfließen zu lassen. Im Anschluss haben wir unsere Analyse vor dem gesamten Team präsentiert um sie für den letzten Feature-Sprint vor dem Minimum Viable Product (MVP) zu motivieren. Denn die Ergebnisse waren äußerst erfreulich.

Edmodo

Edmodo ist ein US-Amerikanisches Unternehmen das nach eigenen Angaben rund 15 Millionen Nutzer in 120.000 Schulen aufweist. Zuerst fällt die starke Ähnlichkeit mit Facebook auf. Die Farben, das Layout, die Icons – kurz, die Gemeinsamkeiten sind groß. Da viele Lehrer skeptisch sind wenn es um Facebook geht, ist die große Ähnlichkeit nicht unbedingt förderlich für die Verbreitung. Ein noch größeres Problem bei der Nutzung Edmodos war die missverständliche Benennung der Funktionalitäten. Kurse werden dort Gruppen genannt, was Peter anfangs verwirrte und letztlich frustrierte. Er erwartet eine eindeutige und auf Lehrer abgestimmte Benennung, sonst fühlt er sich überfordert und dumm. An dem Punkt würde er die Software schon nicht mehr weiter nutzen. Weitere negative Punkte waren die generelle Unübersichtlichkeit (wichtige Funktionen sind nur schwer zu finden) und der unlogische Definitionsspielraum bei der Benotung (es ist möglich 900 von 100 möglichen Punkten zu vergeben) die Peter ebenfalls verunsicherten. Letztlich gab er Edmodo ein schlechtes Zeugnis und würde die Software auf keinen Fall benutzen.

Schoology

Schoology kommt ebenfalls aus den Vereinigten Staaten und wird von rund 1 Millionen User an 18.000 Schulen genutzt. Von der Funktionalität her ähnelt die Anwendung stark Edmodo. Die Benennung der Funktionen ist hier zwar gelungen, allerdings schwächelt auch Schoology im Bereich Übersichtlichkeit und die Benotung funktioniert nicht einwandfrei. Aufgrund der Mängel würde Peter auch diese Anwendung nicht nutzen.

Lore

Über den letzten Wettbewerber Lore wird laut eigener Aussage an 600 Institutionen eingesetzt. Als erstes fällt die Schlichtheit und das aufgeräumte Interface auf, was nach den beiden vorherigen Anwendungen eine Wohltat für die Augen war. Dementsprechend freudig fing Peter an, mit dem Produkt zu spielen. Beinahe alle Funktionen sind an dem erwarteten Patz zu finden und lassen sich intuitiv bedienen. Aber dann fangen die Probleme an. Die Funktionen sind teilweise fehlerhaft, verhalten sich unerwartet oder sind schlicht falsch konzipiert. Darüber hinaus besteht nicht die Möglichkeit Noten zu vergeben. Wir hatten das Gefühl, dass wir mit der Fassade einer Software arbeiten. Von außen schön anzusehen, aber dahinter verbirgt sich nichts. Letztlich ist Lore ein schönes Werkzeug, das aber nicht viel kann. Deswegen würde Peter auch dieses Produkt nicht verwenden.

Fazit

Abschließend lässt sich sagen, dass Edmodo und Schoology zwar funktionieren, allerdings sind sie frustrierend unübersichtlich und die Funktionen sind nicht auf den Lehrer zugeschnitten. Lore bietet ein aufgeräumtes und eingängiges Interface-Design. Allerdings sind wichtige Funktionen nicht durchdacht oder fehlen komplett. Unser Lehrer Peter würde keines der Produkte nutzen, da sie ihm nicht die nötige Sicherheit geben, die er braucht um sich für ein System zu entscheiden. Am Anfang muss ein Lehrer Zeit investieren um seine Daten einzupflegen. Das wird nur geschehen, wenn er sich absolut sicher fühlt und die Software ihn nicht verwirrt oder das Gefühl gibt, dass er dumm ist.

Das Fazit aus der Analyse lautet deshalb wie folgt:

Alles ist möglich – Es gibt kein Produkt am Markt das sich komplett an den Bedürfnissen der Lehrer ausrichtet. Deshalb bietet der Markt noch enormes Potenzial.

Größer als Deutschland – Die weltweit größten Wettbewerber haben noch keine passenden Lösungen für Lehrer entwickelt. Deswegen entwickeln wir ein internationales Produkt.

Verkaufe den Nutzer nicht für dumm – Der Nutzer muss im Mittelpunkt unserer Bemühungen um ein gutes Interface Design stehen. Anstatt überfordert und dumm soll er sich verstanden und sicher fühlen. Nur so wird er den Schritt von Stift und Zettel zu einem Online-Tool wagen.

Entwickle etwas Wertvolles – Nur wenn wir dem Lehrer einen Mehrwert bieten, haben wir eine Daseinsberechtigung. Deswegen müssen wir alle unsere Aktivitäten darauf ausrichten, den Nutzern ein hervorragendes Produkt zu liefern.

Um diese Ziele zu erreichen werden wir Peter in Zukunft stark in die Produktentwicklung mit einbeziehen und auch in der kommenden Betaphase das Feedback der Lehrer aufnehmen und umsetzen. So werden wir erfolgreich die Zukunft der Schule mitgestalten.

Personen und Szenarien

Posted on: May 12th, 2013 by Peter Merrick No Comments

Eine Person ist in der Softwareentwicklung eine Art Melange aus realen Personen. In unserem Fall ist es ‚William’ der einen normalen hart arbeitenden Lehrer repräsentiert, der Hausaufgaben stellt. Einige Schüler reichen sie online ein und einige auf Papier. Andere reichen gar nichts ein. Einige sagen sie werden was einreichen und machen es dann nicht, einige sagen sie werden es nicht machen und reichen dann doch was ein. Manche Schüler waren krank als die Aufgabe gestellt wurde und manche Schüler sind krank wenn die Aufgabe eingereicht werden soll. Wieder andere Schüler fragen nach einer Verlängerung der Frist. Die Liste der Einzelfälle ist endlos. Und all das passiert bevor der arme William auch nur eine Hausaufgabe benotet hat. Aber dies ist die Welt in der Scolibri funktionieren muss. Deswegen müssen wir diese Welt verstehen. Wofür brauchen wir die Personen? Wir nutzen sie um eine Geschichte über ihr Arbeitsleben zu erzählen. Diese Geschichte nennen wir sein Szenario. Dieses Szenario nutzen wir um zu prüfen ob wir alle User Stories vorbereitet haben, sodass das fertige Produkt William bei seinem Job unterstützt. Das ist alles? Nein. Zusätzlich testen wir mit dem Szenario die Funktionalität unserer Wettbewerber. Wir können keine Aussage über unsere Konkurrenz treffen, wenn wir keine standardisierte und realistische Testmethodik haben. Das funktioniert super und wir haben einiges gelernt. Dafür sind also Personen und Szenarien da? Nicht ganz. Sie spielen auch in die Produktdemos mit rein. Wir fragen Laurin nicht ob er uns diese oder jene User Story vorführen kann. Basierend auf dem Szenario entwickeln wir Softwaretests und simulieren einen Lehrer, der genervt ist und die Software mit realistischen Daten testet. Dadurch wird die Demo für uns viel plastischer. Diese Daten sind auch Teil des letzten Tests, bevor wir die Betaversion veröffentlichen. Unser Ziel ist es alle Tester zufriedenzustellen. Wir wollen alle möglichen Blickwinkel aufs Produkt mit einbeziehen. Und es muss schnell gehen. Mit der Szenario-Methode sind wir unglaublich schnell. Möglich, dass Williams Story nicht real ist aber sie ist sehr nah an einer wirklichen Geschichte. Denn William ist im realen Leben ein Lehrerkollege von Peter an der Nelson Mandela Schule. Er weiß aber nichts davon. Vielleicht wird er berühmt.