Wie ein kleines Team Produkte baut (ohne den Verstand zu verlieren)

Beim Schreiben dieses Beitrags kamen keine Corporate-Buzzwords zu Schaden.

Wir sind vierzehn Leute. Das ist klein genug, dass jeder weiß, woran alle anderen arbeiten, aber groß genug, dass es ganz ohne Prozess nicht mehr geht.

Diese Größe ist seltsam. Zu groß für „Kurz alle in einen Call und das klären“, zu klein für Abteilungen, Manager und formale Hierarchien. Wir mussten herausfinden, wie man in dieser Größenordnung tatsächlich Produkte baut, und ehrlich gesagt sind wir immer noch dabei.

Was wir eigentlich bauen

Im Moment haben wir zwei große Baustellen:

1. Arheev - Unsere HR-Plattform für wachsende Unternehmen. Das Produkt, das wir für uns selbst bauen (und für andere, die es brauchen).
2. Kundenprojekte - Wir entwickeln Individualsoftware für Start-ups und Unternehmen, denen die technische Expertise im eigenen Haus fehlt.

Beides zu jonglieren ist manchmal Chaos. Wir stecken tief in der Feature-Arbeit an Arheev, dann schlägt in einem Kundenprojekt ein kritischer Bug ein, und das halbe Team schwenkt um. Oder wir planen einen Kunden-Sprint und merken dann, dass Arheev dringend etwas für eine Demo nächste Woche braucht.

Bei vierzehn Leuten gibt es keine Lösung namens „getrennte Teams“. Alle fassen alles an.

Wie wir wirklich Entscheidungen treffen

In einem großen Unternehmen gibt es Prozessdokumente und Genehmigungsketten. In unserer Größe ist das übertrieben.

Stattdessen haben wir eine Regel: Wer findet, dass etwas getan werden sollte, baut einen Prototyp.

Nicht „ein Meeting ansetzen, um das zu besprechen“. Nicht „einen Vorschlag zur Prüfung schreiben“. Einfach eine grobe Version bauen und dem Team zeigen.

Das klingt chaotisch. Manchmal ist es das auch. Aber es bedeutet auch, dass wir schnell vorankommen und schlechte Ideen schnell beerdigen. Deutlich besser, als zwei Wochen lang in Meetings über etwas zu debattieren, es dann zu bauen und festzustellen, dass es nicht funktioniert.

Marko (unser Head of Engineering) kam aus einem Umfeld, in dem jede Änderung drei Genehmigungsstufen brauchte. Er sagt, als ihm bei Norveon zum ersten Mal jemand sagte „einfach rausbringen und schauen, was passiert“, hielt er das für einen Test.

War es nicht. Wir trauen einander wirklich zu, selbst abzuwägen und zu entscheiden.

Der Freitags-Fehlerbericht

Jeden Freitag haben wir ein festes Meeting, in dem alle erzählen, was in dieser Woche nicht funktioniert hat.

Keine Erfolge. Fehlschläge.

Das Azure-Deployment, das den Produktivbetrieb lahmgelegt hat. Das Feature, das wir gebaut haben und das die Nutzer hassen. Der Refactor, der die Performance verschlechtert statt verbessert hat. Das Kundenmeeting, das aus dem Ruder lief.

Anfangs zögerten die Leute, Fehlschläge zu teilen. Heute ist es das nützlichste Meeting, das wir haben. Aus „Das habe ich kaputtgemacht, und so habe ich es repariert“ lernt man deutlich mehr als aus „Das ist gut gelaufen“.

Als der Junior-Entwickler recht hatte

Bei Arheev haben wir Wochen damit verbracht, das Dashboard-Layout zu entwerfen. Mehrere Iterationen, viele Diskussionen über Informationshierarchie und Nutzer-Workflows.

Dann pushte jemand, der noch neu im Team war (und in den meisten Meetings still geblieben war), einen Prototyp auf Staging, der unseren gesamten Navigationsansatz über den Haufen warf. Einfach … komplett anders.

Die erste Reaktion war: „Das widerspricht all unseren Design-Patterns.“ Die zweite Reaktion, nachdem wir es tatsächlich benutzt hatten: „Moment, das funktioniert ja wirklich besser.“

Am Ende haben wir diese Version ausgeliefert. Es brauchte noch etwa zwei Wochen Feinschliff, aber die Kernidee (von jemandem, der bei all unseren früheren Diskussionen und Annahmen nicht dabei gewesen war) löste das Problem besser als unser „Experten“-Ansatz.

Die Lektion: Manchmal bedeutet neu zu sein, dass man die falschen Muster noch nicht gelernt hat.

Die Dinge, die nicht skalieren (und die wir trotzdem tun)

Bei vierzehn Leuten können wir noch Dinge tun, die größere Unternehmen nicht können:

Alle reviewen den Code aller. Nicht nur Senior-Entwickler, die Juniors reviewen. Alle sehen die Arbeit aller. Das heißt, Code-Reviews dauern manchmal länger, aber es heißt auch, dass sich Wissen schnell verbreitet.

Wir deployen direkt in den Produktivbetrieb. Kein separates Deployment-Team, kein Change Approval Board. Sind die Tests grün, darf deployen, wer es gebaut hat. Leute aus größeren Unternehmen erschreckt das. Wir kommen gut damit klar.

Alle reden mit Kunden. Es gibt kein „Account-Management-Team“, das die Entwickler von den Nutzern abschirmt. Wer das Feature gebaut hat, demonstriert es vielleicht auch oder debuggt es gemeinsam mit dem Kunden. Das ist ineffizient. So lernt man aber, was wirklich zählt.

Was passiert, wenn das nicht funktioniert

Nicht alles ist perfekt. Manche Dinge in unserer Größe sind einfach … mies.

Wissenssilos bilden sich trotzdem. Selbst mit Code-Reviews und gemeinsamen Projekten wird am Ende jemand zur „Person, die weiß, wie das Deployment funktioniert“ oder zur „Person, die den Zahlungsablauf versteht“. Ist sie im Urlaub, wird alles langsamer.

Politik gibt es trotzdem. Ein kleineres Team heißt nicht, dass es keine Meinungsverschiedenheiten oder verletzten Gefühle gibt. Wir haben nur weniger Orte, an denen wir uns davor verstecken können.

Wachstum ist seltsam. Wir sind zu klein für spezialisierte Rollen, aber zu groß, als dass alle alles machen könnten. Stellen wir noch einen Generalisten ein oder suchen wir einen spezialisierten Designer? Entscheiden wir falsch, sind wir monatelang aus dem Gleichgewicht.

Für all das haben wir keine Lösungen. Wir wissen nur, dass es diese Probleme gibt, und versuchen, sie nicht schlimmer zu machen.

Warum das für Produkte wichtig ist

Wie wir arbeiten, wirkt sich direkt darauf aus, was wir bauen.

In Arheev (unserer HR-Plattform) lässt sich praktisch alles anpassen. Workflows, Berechtigungen, Datenfelder, Reporting: alles konfigurierbar. Nicht, weil wir geplant hätten, „das flexibelste HR-System“ zu bauen, sondern weil wir intern genau so arbeiten.

Wir hassen es, in starre Prozesse gezwängt zu werden, also haben wir ein Tool gebaut, das seine Nutzer nicht in starre Prozesse zwängt.

Hätte ein größeres, strukturierteres Team etwas Ähnliches bauen können? Vielleicht. Aber es hätte mehr Meetings gebraucht, mehr Planung, mehr Genehmigungsebenen. Bis zur Auslieferung hätte sich der Markt weiterbewegt.

Bei vierzehn Leuten können wir schnell sein, weil es keinen Ort gibt, an dem sich schlechte Ideen verstecken könnten. Sie fliegen im Code-Review auf, oder im Freitags-Fehlermeeting, oder wenn jemand das Feature tatsächlich benutzen will und merkt, dass es furchtbar ist.

Wo wir stehen

Wir haben nicht den perfekten Weg gefunden, Produkte zu bauen. Den hat niemand. Wir teilen nur, was für uns funktioniert, in dieser Größe, in dieser Phase.

Einiges davon wird kaputtgehen, wenn wir wachsen. Einiges funktioniert schon jetzt nicht mehr so gut wie damals, als wir kleiner waren. Wir werden uns anpassen, oder auch nicht, und auch darüber werden wir schreiben.

Fragen Sie uns in einem Jahr noch einmal, und die Antwort könnte anders ausfallen.