Die Jibble-Geschichte
Es ist schwierig, eine Software zu entwickeln, die sich von anderen abhebt, stabil ist und einen echten Unterschied bewirkt. Viele Teams können eines davon, einige können zwei davon, aber selten sehen wir, dass ein Team gemeinsam alle drei Punkte umsetzt.
Genau das habe ich bei Jibble erlebt.
Eine kurze Google-Suche bestätigt meine Aussage: Die Software des Unternehmens wurde auf GetApp und Capterra mit beeindruckenden 4,8 und im Apple App Store mit 4,7 bewertet. Ich bin mir sicher, dass es viele Dinge gibt, die das Unternehmen verbessern kann, aber wenn das unsere Bewertungen sind, macht das Team etwas richtig.
Ich wollte verstehen, was das Unternehmen genau macht, also beschloss ich, herauszufinden, wie und warum Jibble diese beeindruckenden Ergebnisse erzielt. Mir ist klar, dass Softwarelösungen für Stundenzettel und Zeiterfassung nicht wirklich verlockend sind; es ist definitiv nicht dasselbe wie die Arbeit für ein Spielunternehmen wie Activision, das das neue Spider-Man-Spiel entwickelt.
Jibble rühmt sich jedoch, „der neue Standard in der Zeiterfassung“ zu sein, eine kühne Behauptung, die sich jedoch in der Praxis als zutreffend erwies. Dies ist das Ergebnis harter Bemühungen, aus etwas Alltäglichem, aber Bedeutendem etwas Interessantes zu machen.
Du siehst, dass die meisten Start-ups die etablierten Branchen verändern werden, da die meisten unmittelbaren, greifbaren Innovationen bereits erreicht wurden. Deshalb glaube ich, dass Jibble sich in einer einzigartigen Position befindet, um einen Markt zu erobern, der lange Zeit von jungen Gründern und erfahrenen Risikokapitalgebern vernachlässigt wurde.
Auf den ersten Blick mag Jibble wie ein 08/15-Konzept aussehen, das nach dem Motto „OK, du hast ein Problem gefunden, lass uns etwas Code zusammenschustern, eine Benutzeroberfläche erstellen, ein Zahlungsgateway anhängen und es in die Welt hinauswerfen“ funktioniert.
Das war zumindest mein Verständnis am Anfang, bevor ich dem Team beitrat, aber wie ich schnell lernte, arbeiten SaaS-Unternehmen, die komplexe Produkte wie Softwarellösungen für Stundenzettel entwickeln, anders. Es gibt eine MENGE Prozesse, die befolgt werden müssen, und obwohl Jibble kein zweites Google ist, verfügt das Unternehmen über ein sehr beeindruckendes Team von Einzelpersonen, die die Entwicklung leiten. Diese Helden bleiben oft unbemerkt.
Du hast vielleicht schon gehört, dass Software-Ingenieure keine großartigen Kommunikatoren sind – sie sind in der Regel introvertiert, Meister ihres Fachs und wollen nur selten durch menschliche Interaktion gestört werden. Dieses Klischee ist bis zu einem gewissen Grad wahr.
Die meisten Ingenieure müssen unzählige Stunden vor ihren schwach beleuchteten Bildschirmen verbringen, um ihre Fähigkeiten zu verbessern, und unser Team ist da nicht anders.
Da ich sowohl auf der Unternehmensseite als auch auf der Kundenseite tätig war, befinde ich mich in einer einzigartigen Position, um zu erklären, warum die Dinge hier einfach funktionieren und warum es sich lohnt, dieses Start-up im Auge zu behalten.
Unser Entwicklungsprozess
Unser Team verbringt unzählige Stunden damit, jeden einzelnen Schritt des Entwicklungsprozesses zu verfeinern, der wie folgt aussieht:
1. Ideenfindung: Identifizierung von Schmerzpunkten
Unser Team verbringt unendlich viel Zeit damit, sicherzustellen, dass wir nicht doppelt so viel Zeit aufwenden, wenn wir erst einmal mit der Arbeit begonnen haben, bevor die erste Codezeile geschrieben wird. Wie Abraham Lincoln sagte:
„Gib mir sechs Stunden, um einen Baum zu fällen, und ich werde die ersten vier Stunden damit verbringen, meine Axt zu schärfen.“
2. Externe Recherche
Nachdem ein Schwachpunkt im Bereich unserer Zeiterfassungssoftware identifiziert wurde, vergleicht das Team schnell das vorhandene Kundenfeedback, aktuelle und prognostizierte Markttrends und relevante Technologien, um Gemeinsamkeiten zu finden, die bei der Vorbereitung der für eine fundierte Entscheidung erforderlichen Daten helfen.
3. Interne Recherche: Besprechungen mit dem Team
Sobald die Daten gesammelt wurden, werden relevante Anteilseigner einbezogen, darunter Product Owner, Produktmanager, CTOs, leitende Designer und Teamleiter aus allen Bereichen. Nachdem das Team eine interne Diskussion über die Vor- und Nachteile, Ressourcen vs. Zeit und den erwarteten ROI der Entscheidung, die wir treffen werden, geführt hat, werden alle gebeten, sich Zeit zu nehmen, um ihre Bedenken zu äußern und zu sagen, welche Richtung wir ihrer Meinung nach einschlagen sollten bzw. warum oder warum nicht.
4. Entscheidungsfindung: Jetzt oder später – wie wirkt sich diese Sache auf das Unternehmen aus?
Nachdem sich alle ihre Gedanken gemacht haben und eine Entscheidung getroffen wurde, wählt das Team die Entscheidung aus, die mit der Unternehmensvision und den unmittelbaren oder erwarteten Zielen übereinstimmt. Wenn die Entscheidung diese Kriterien nicht erfüllt, wird sie nicht berücksichtigt.
Entscheidungen beziehen sich oft (aber nicht immer) auf Verbesserungen bestehender Funktionen oder die Entwicklung brandneuer Funktionen. Nachdem für eine dieser Optionen grünes Licht gegeben wurde, stellt sich die Frage, wo die Funktion in der Roadmap eingeordnet werden soll: Setzen wir sie jetzt, nächsten Monat, nächstes Quartal um oder verschieben wir sie auf unbestimmte Zeit?
An dieser Stelle betrachten wir, welche Auswirkungen unsere Entscheidung auf bestehende Kunden, zukünftige Interessenten und die aktuelle Kapazität haben wird, und treffen dann eine Entscheidung.
5. Designrecherchen
Sobald die Zeitachse der Funktionen festgelegt wurde, müssen wir uns überlegen, wie diese aussehen soll. Das ist etwas, was viele neue Unternehmer und Software Product Owner vermasseln. Sie konzentrieren sich zu sehr darauf, wie die Software funktionieren sollte, obwohl sie sich auch darum kümmern müssen, dass alle Funktionen in das visuelle Puzzle passen.
6. Spezifikation
Der nächste Schritt ist der Fluch der Software-Entwickler: die Dokumentation. In der Spezifikation schreiben wir den Umfang des Projekts, das wir entwickeln. Hier wird die Idee in ein Dokument geschrieben und entwickelt, das als Quelle der Wahrheit für Entwicklung, Tests und Fehlerbehebungen dient.
Darin wird festgelegt, wie die gesamte Funktion aussehen wird, wie sie aussehen wird und wie das Endziel aussieht (im Moment betrachten wir die Metriken nicht sehr genau). Es gibt auch eine technische Dokumentation, die von unseren Entwicklern erstellt wird. So gehen wir derzeit beim Schreiben von Spezifikationen vor:
- Erster Entwurf vom PM
- Die Teamleiter gehen die ersten Spezifikationen durch und hinterlassen Kommentare zur technischen Machbarkeit oder alternative Vorschläge
- Änderungen durch den PM
- Weitere Diskussion (Schritte 2–3 können je nach Komplexität des Projekts einige Male wiederholt werden)
Das Team stellt sicher, dass in dieser Zeit auch alle Grenzfälle berücksichtigt werden. Wenn das Design jedoch fertiggestellt ist, setzen wir den Diskussionen über die Spezifikationen ein Ende. Bis dahin sind noch Iterationen möglich.
7. Produktdesign
Unsere brillanten Designer erstellen verschiedene Modelle mit einer Reihe von Darstellungsoptionen. Bei der Erstellung wird die Farbpalette von Jibble berücksichtigt.
Jedes erdenkliche Display – mobil, Web, Tablet – und eine Vielzahl von Bildschirmgrößen, einfach alles wird in dieser Phase berücksichtigt.
8. Back-End-Implementierung und Unit-Tests
Die meisten Funktionen beginnen im Backend. Unser Backend muss die Funktion unterstützen, bevor wir die Benutzeroberfläche und Logik auf der Client-Seite hinzufügen und unsere API erweitern. Die Pflege der Sessions erfolgt also mit dem BE-Team, um Tickets und Aufgaben auf der Grundlage von Spezifikationen zu verfeinern, und dann erfolgt die Zuweisung der Tickets während der Backend-Sprintplanung.
Das BE-Team ist außerdem für die Entwicklung von Unit-Tests für den von ihm geschriebenen Code verantwortlich, um sicherzustellen, dass alle Funktionen wie erwartet funktionieren. Zu diesem Zeitpunkt wird die Architektur der Funktion erstellt. Ein gutes Funktionsmodell erleichtert den Entwicklungsprozess für die Kunden.
9. Client-Implementierung und Unit-Tests
Nachdem unser BE nun implementiert wurde, werden die Teams für die Entwicklung von Mobil- und Webanwendungen mit der jeweiligen FR-Implementierung beginnen. Der Prozess ist in etwa derselbe wie beim BE, allerdings erfolgt die Verfeinerung der Tickets hauptsächlich außerhalb der Planungsgespräche.
Kunden beziehen sich bei der Implementierung ihres Codes hauptsächlich auf Spezifikationen, Designs sowie die BE-Modellstruktur der Funktion. Im Bereich Mobile verfügen wir über zwei verschiedene Teams für die Benutzeroberfläche, die einer gemeinsamen Logik folgen. Dies trägt zur Optimierung der Bereitstellung und zur Reduzierung von Redundanzen bei. Die ersten Tests werden vom Entwicklerteam durchgeführt und dann zur manuellen Überprüfung an die Qualitätssicherung weitergeleitet.
10. QA-Abnahmetests
Sobald neue Funktionen entwickelt wurden, werden sie in unseren Testumgebungen bereitgestellt, in denen das Qualitätssicherungsteam strenge Abnahmetests durchführt. Das ist eine ausgefallene Art zu sagen, dass wir die entwickelten Funktionen der Zeiterfassungssoftware testen, um sicherzustellen, dass diese den Erwartungen entsprechend funktionieren. Wenn Probleme gefunden werden, geht es zurück in die Werkstatt, um Überarbeitungen und Verbesserungen vorzunehmen.
11. QA-Regressionstests
Wenn alle Funktionen wie vorgesehen funktionieren, werden die Funktionen an die Produktion gesendet, wo sie erneut getestet werden, um sicherzustellen, dass vorhandene Korrekturen nicht die zuvor funktionierenden Funktionen beeinträchtigen.
Regressionstests sind eine Art von Software-Tests, mit denen bestätigt werden soll, dass eine kürzlich vorgenommene Programm- oder Codeänderung keine negativen Auswirkungen auf vorhandene Funktionen hat. Bei Jibble führen wir zwei Arten von Regressionstests durch: Einmal handelt es sich um informelle oder geringfügige Regressionstests, die im Rahmen von Akzeptanztest-Tickets durchgeführt werden, bei denen Probleme auftreten und die erneut behoben werden müssen. Bei der anderen Art handelt es sich um Regressionstests mit vollständiger Zyklusiteration, die gegen Ende des Sprints durchgeführt werden, der als Zyklus mit größerer Abdeckung bekannt ist und sich auf den kritischen Pfad der ausgewählten Funktionen konzentriert.
Im Moment führen wir diese Tests noch manuell durch, bevor die Automatisierungsskripte vollständig fertig sind.
12. Explorative Tests
Da das Team bei der Entwicklung dieser Stundenzettel-Software sehr agil ist, wird all dies in Zyklen von zwei Wochen erledigt. Außerhalb dieser Zyklen oder in Zeiten mit relativ geringer Arbeitsbelastung führen die Teammitglieder explorative Tests durch, was einfach bedeutet, dass sie alles im Auge behalten und alle Verbesserungen melden, die Hotfixes erfordern.
Wir führen außerdem explorative Tests durch, während wir die Akzeptanztest-Tickets testen, die den erweiterten Umfang des Tickets selbst abdecken.
13. Veröffentlichung
Endlich, nach all dieser harten Arbeit, wird unser Werk in die Welt entlassen. Ihr habt doch nicht erwartet, dass es so lange dauert, eine Stundenzettel-Software zu entwickeln, oder?
Meine Erkenntnis
Um ein hervorragendes Produkt zu schaffen, muss man eine herausragende Vision haben und darf nicht davon abweichen, wenn sich die Dinge ändern. Das für die Zeiterfassung zuständige Team von Jibble weiß, dass es klug ist, nicht zu schnell auf Trends zu reagieren. Die Teammitglieder sind zielstrebig, aber dennoch ständig auf der Suche nach Verbesserungen. Gleichzeitig setzen sie Strategien um, um ihrer Vision dessen, was „Der neue Standard im Bereich der Zeiterfassung“ sein sollte, treu zu bleiben. Und genau DIESE VORGEHENSWEISE– so denke ich jedenfalls – spielt eine große Rolle für ihren jüngsten Erfolg.
Das Fazit für Teams, die den Erfolg von Jibble bei der Entwicklung einer zuverlässigen Softwarelösung zu Zeiterfassung wiederholen möchten, lautet: Bildet schnelle, starke und flexible Teams, die sich die Zeit nehmen, datengestützte Recherchen durchzuführen, bevor sie Entscheidungen treffen, und stellt brillante Ingenieure ein, die Best Practices und globale Methoden der Zusammenarbeit nutzen, um Funktionen wie am Schnürchen zu entwickeln, zu testen, zu verbessern und auszuliefern. Dann lehnt euch zurück und schaut zu, wie das Wunder geschieht.
