Der Leitfaden für nicht-technische Gründer zur Bewertung der Arbeit eines Entwicklers

Du hast einen Entwickler oder eine Agentur beauftragt. Rechnungen kommen rein, Demos finden statt, die App sieht aus, als würde sie vorankommen. Was du nicht erkennen kannst: ob das, was darunterliegt, solide ist oder ob du für ein Haus ohne Fundament bezahlst.

Das ist die Position, in der sich die meisten nicht-technischen Gründer befinden, und sie ist strukturell bedingt. Die Person, die die Arbeit macht, weiß weit mehr über ihre Qualität als die Person, die dafür bezahlt. Programmieren zu lernen wird diese Lücke in keinem sinnvollen Zeitrahmen schließen. Was sie zumindest teilweise schließt, ist zu wissen, wie man die Arbeit eines Entwicklers anhand der Artefakte rund um den Code bewertet, statt am Code selbst.

Ich mache Code-Audits und technische Due Diligence für Gründer, die genau in dieser Situation sind, und dabei tauchen immer wieder dieselbe Handvoll Prüfungen auf. Keine davon erfordert, dass du eine Quelldatei öffnest.

Verlange Ergebnisse, die schwer zu fälschen sind

Die günstigste Form der Kontrolle ist, im Voraus festzulegen, was du in jeder Phase sehen willst, und dann nicht weiterzugehen, bevor du es gesehen hast.

Bevor Code geschrieben wird, verlange eine Architekturskizze. Sie muss nicht schön sein. Ein einseitiges Diagramm, das die Hauptbestandteile zeigt (die Web-App, die Datenbank, den Zahlungsanbieter, den E-Mail-Dienst, Hintergrundjobs) und wie sie miteinander sprechen, reicht aus. Wenn dein Entwickler das nicht liefern kann, hat er noch nicht über das System als Ganzes nachgedacht. Wenn er es in zehn Minuten erstellt und es für dich Sinn ergibt, wenn er es dir erklärt, ist das ein gutes Zeichen.

Bevor du für einen Meilenstein bezahlst, verlange eine funktionierende Demo auf einem Server, der nicht der Laptop des Entwicklers ist. „Bei mir läuft es" ist aus gutem Grund der älteste Witz der Softwarebranche. Eine Staging-Umgebung, die du in deinem eigenen Browser öffnen kannst, auf deinem eigenen Handy, ohne dass der Entwickler dabei ist, zeigt dir, dass ein Deployment-Prozess existiert und die App irgendwo real läuft.

Vor dem Launch verlange dokumentierte Testergebnisse. Nicht ein mündliches „Ja, das ist getestet." Eine kurze schriftliche Zusammenfassung: was durch automatisierte Tests abgedeckt ist, was manuell getestet wurde und was bekanntermaßen ungetestet ist. Ein Entwickler mit Tests kann das an einem Nachmittag liefern. Ein Entwickler ohne Tests wird zögern, und dieses Zögern ist die Antwort.

Verlange außerdem in jeder Phase Zugang. Du solltest einen eigenen Login für das Code-Repository, das Hosting-Konto, die Domain-Registrierung und alle Drittanbieterdienste haben, von denen die App abhängt. Zugang auf Owner-Ebene, auf deinen Namen, bezahlt mit deiner Karte. Das klingt nach einer administrativen Kleinigkeit. Es ist die eine Sache, die Gründer am häufigsten wünschen, früher geregelt zu haben.

Wie du die Arbeit eines Entwicklers mit Fragen statt mit Code bewertest

Du kannst viel über eine Codebasis lernen, indem du Fragen stellst, deren Antworten nur dann gut sind, wenn die zugrunde liegende Arbeit gut ist. Hier sind die, die ich am nützlichsten finde.

Wie lange braucht deine Testsuite, um zu laufen? Eine echte Antwort klingt wie „ungefähr vier Minuten" oder „die Unit-Tests brauchen dreißig Sekunden, der vollständige Durchlauf zwanzig Minuten." Eine besorgniserregende Antwort ist jede Version von „wir testen manuell" oder „wir fügen Tests hinzu, sobald sich der Funktionsumfang stabilisiert hat." Funktionsumfänge stabilisieren sich nie.

Wie deployst du in Produktion? Du willst etwas hören wie „wir pushen in den Main-Branch, die Pipeline führt die Tests aus, und wenn sie bestehen, wird deployt." Das bedeutet, der Prozess ist wiederholbar und hängt nicht davon ab, dass sich eine Person Schritte merkt. Wenn die Antwort das manuelle Kopieren von Dateien oder das Ausführen von Befehlen aus dem Gedächtnis beinhaltet, ist jedes Deployment ein kleines Glücksspiel.

Was passiert, wenn eine deiner Abhängigkeiten eine Sicherheitslücke hat? Moderne Apps ziehen Hunderte Open-Source-Pakete ein. Ein guter Entwickler kann dir sagen, wie er davon erfährt (automatisierte Benachrichtigungen von GitHub oder einem ähnlichen Tool) und ungefähr wie oft er aktualisiert. Wenn die Antwort ein leerer Blick ist, achtet niemand darauf.

Wenn du morgen aufhören würdest zu arbeiten, wie lange würde ein neuer Entwickler brauchen, um produktiv zu werden? Ein ehrlicher Entwickler gibt dir eine Zahl und erklärt, was sie verkürzen würde. Achte auf diejenigen, die „nicht lange" sagen, ohne begründen zu können, warum. Die tatsächliche Antwort hängt von Dokumentation, Testabdeckung und davon ab, wie konventionell der Code ist, und ein Entwickler, dem das wichtig ist, wird das unaufgefordert erwähnen.

Wo werden die Geheimnisse gespeichert? API-Schlüssel, Datenbankpasswörter, Zahlungsdaten. Die Antwort sollte „in Umgebungsvariablen" oder „in einem Secrets-Manager" lauten, niemals „im Code." Wenn sie im Code stehen, stehen sie für immer in der Repository-Historie, und jeder, der jemals Zugang hatte, hat sie.

Du musst den technischen Wert der Antworten nicht im Detail beurteilen. Du hörst darauf, ob der Entwickler überhaupt eine durchdachte Antwort hat, ob er sie klar erklärt und ob sie mit dem übereinstimmt, was du beobachten kannst.

Warnzeichen, die du sehen kannst, ohne eine Quelldatei zu öffnen

Auch ohne Code zu lesen, erzählen die Artefakte drumherum eine Geschichte.

Schau dir die Commit-Historie in deinem Repository an. GitHub und GitLab zeigen sie als Zeitleiste. Stetige, kleine Commits mit beschreibenden Nachrichten über den Verlauf einer Woche sehen nach professioneller Arbeit aus. Ein einziger riesiger Commit in der Nacht vor der Deadline mit der Nachricht „finale Änderungen" sagt dir, dass die Arbeit entweder in Eile erledigt oder in letzter Minute von irgendwoher kopiert wurde. Keines von beidem ist gut.

Prüfe dann, ob es einen Ordner namens tests, spec oder ähnlich gibt. Du musst nicht lesen, was darin steht. Wenn er nicht existiert oder mit zwei Dateien darin existiert, gibt es keine nennenswerten automatisierten Tests, egal was dir gesagt wurde.

Die README-Datei ganz oben im Repository ist eine weitere schnelle Prüfung. Kann ein Fremder ihr folgen, um die App lokal zum Laufen zu bringen? Bitte einen technisch versierten Freund, es fünfzehn Minuten lang ohne Hilfe zu versuchen. Wenn er es nicht schafft, wird dein nächster Entwickler es auch nicht schaffen.

Achte darauf, wer deine Fragen beantwortet. Wenn in einem Agenturprojekt jede Frage zum Backend an eine Person geht und jede Frage zum Frontend an eine andere, und keiner den anderen vertreten kann, hast du eine Codebasis, bei der jeder Bereich nur in einem Kopf lebt. Das ist ein Risiko, das du trägst, nicht sie.

Und achte darauf, wie sich Schätzungen verhalten. Jeder verpasst gelegentlich Schätzungen. Das Muster, auf das du achten solltest, sind Schätzungen, die mit der Zeit schlechter statt besser werden. In einer gesunden Codebasis ist das Hinzufügen des zehnten Features etwa so schwer wie das des fünften. In einer ungesunden dauert jedes neue Feature länger, weil es um alles Vorherige herumarbeiten muss. Wenn „kleine Änderungen" immer wieder Wochen dauern, ist der Code nicht mehr günstig zu ändern, und das ist ein Codequalitätsproblem, das sich in deinem Kalender zeigt.

Einen externen Prüfer hinzuziehen, ohne einen Streit anzufangen

Irgendwann willst du vielleicht eine zweite Meinung. Das ist in jeder anderen Branche normal. Niemand kauft ein Haus ohne Gutachten. Entwickler können das trotzdem persönlich nehmen, deshalb ist wichtig, wie du es einführst.

Formuliere es als Due Diligence für das Unternehmen, nicht als Prüfung der Person. „Wir sammeln Geld ein und Investoren wollen eine unabhängige Einschätzung der Technik" ist ein Satz, den die meisten Entwickler verstehen und wenige übelnehmen. Genauso „Ich will sicherstellen, dass wir keine Probleme aufbauen, die ich nicht sehen kann."

Sag dem Entwickler im Voraus Bescheid, teile den Umfang der Prüfung mit und lass sie direkt miteinander sprechen. Ein Prüfer, der eine Stunde mit dem Entwickler verbringt, bevor er etwas schreibt, erstellt einen faireren Bericht als einer, der nur mit dem Repository arbeitet. Gute Entwickler sind meist erleichtert, jemanden Technisches auf deiner Seite des Tisches zu haben, weil sie dann nicht mehr erklären müssen, warum ein Refactoring wichtig ist, jemandem gegenüber, der das Problem nicht sehen kann.

Was du von der Prüfung willst, ist kein Urteil „gut" oder „schlecht." Du willst eine kurze Liste, in klarer Sprache, was in Ordnung ist, was vor dem Launch behoben werden sollte und was warten kann. Diese Liste wird zu etwas, das du und der Entwickler gemeinsam durcharbeiten, statt zu einer Waffe.

Und sei darauf vorbereitet, dass die Prüfung ergibt, die Arbeit sei ordentlich. Das passiert häufiger, als Gründer erwarten, und es lohnt sich für sich genommen: Es erlaubt dir, aufzuhören, dir Sorgen zu machen, und zurück zum Führen des Unternehmens zu gehen.

Vertragsklauseln, die einen nicht-technischen Käufer schützen

Die meisten Streitigkeiten, die ich sehe, hätten mit vier Absätzen im ursprünglichen Vertrag vermieden werden können.

Die erste ist das Eigentum am Quellcode. Der Vertrag sollte festlegen, dass sämtlicher Code, alle Designs und Dokumentationen, die im Rahmen des Vertrags erstellt werden, dir gehören und dass der Entwickler das vollständige Repository einschließlich Historie auf Anfrage übergibt. Ohne das gehört in vielen Rechtsordnungen standardmäßig der Person der Code, die ihn geschrieben hat, was viele Gründer überrascht, wenn ein Anwalt es ihnen zum ersten Mal erklärt.

Die zweite ist eine Dokumentationspflicht. Etwa: „Das Ergebnis umfasst eine README, die einem kompetenten Entwickler ausreicht, um die Anwendung ohne Hilfe des ursprünglichen Autors einzurichten, auszuführen und zu deployen." Das ist schwer zu bestreiten und leicht zu prüfen.

Die dritte ist eine Abnahmedefinition, die an die Ergebnisse aus dem vorherigen Abschnitt gekoppelt ist. Ein Meilenstein ist abgeschlossen, wenn das Feature auf dem Staging-Server läuft, die automatisierten Tests bestehen und die Testzusammenfassung geliefert wurde. Das macht aus „ist es fertig?" statt einer Meinungsfrage eine Tatsachenfrage.

Die vierte ist Zugang. Der Vertrag sollte verlangen, dass alle Konten, Domains, Hosting- und Drittanbieterdienste auf den Namen des Unternehmens registriert sind, wobei der Gründer von Tag eins an Zugang auf Owner-Ebene hat. Ein Entwickler, der sich dagegen sträubt, sagt dir damit etwas.

Halte die Sprache einfach. Lange Listen von Coding-Standards in einem Anhang helfen selten, weil niemand sie durchsetzt und alle darüber streiten. Kurze, überprüfbare Bedingungen tun das.

Wie sich das in der Praxis zeigt

Nichts davon erfordert, dass du eine Zeile Code verstehst. Zu lernen, wie man die Arbeit eines Entwicklers auf diese Weise bewertet, bedeutet größtenteils, zu bestimmten Zeitpunkten nach bestimmten Dingen zu fragen, genau zuzuhören, wie Fragen beantwortet werden, und ein paar Artefakte anzusehen, die du in deinen eigenen Konten bereits sehen kannst. Die meisten Gründer, die damit anfangen, sind überrascht, wie viel klarer das Bild innerhalb weniger Wochen wird.

Wenn du lieber jemanden Technisches auf deiner Seite des Tisches hättest, während gebaut wird, ist das Teil dessen, was Wolf-Tech macht. Ich arbeite als technischer Berater für nicht-technische Gründer: Ich prüfe Ergebnisse, sitze bei Entwicklergesprächen dabei und lese den Code, damit du es nicht musst. Wenn du darüber sprechen willst, schreib an hello@wolf-tech.io oder schau dich auf wolf-tech.io um.