Wie Sie erkennen, ob ein externer Entwickler gute Arbeit leistet, wenn Sie keinen Code lesen können

Gute Einstellungsentscheidungen lösen das Problem nicht dauerhaft. Sie können externe Entwicklerkandidaten sorgfältig bewerten, jemanden mit starkem Portfolio und einer überzeugenden ersten Demo auswählen, und stehen sechs Monate später trotzdem ohne Ahnung da, ob die Arbeit wirklich hält. Die übliche Empfehlung behandelt, was Sie vor Vertragsunterschrift prüfen sollten: Leistungen, Fragen, Zugänge. Dies ist die Version für danach, die fortlaufende Einschätzung, die Sie jeden Monat vornehmen können, ohne eine einzige Datei zu öffnen.

Die vier folgenden Prüfungen erfordern kein technisches Wissen. Sie erfordern Mustererkennung über einige Monate – eine Fähigkeit, die jeder Manager bereits aus der Beobachtung anderer Unternehmensbereiche besitzt. Sie suchen nach derselben Art von Drift, die Sie auch in einer Vertriebspipeline oder einer Support-Warteschlange bemerken würden: Wird es besser, bleibt es gleich, oder wird es leise schlechter?

Vier Wege, die Arbeit eines externen Entwicklers zu bewerten, ohne eine einzige Datei zu öffnen

Jede dieser Prüfungen nutzt etwas, das Sie bereits erhalten: Release Notes, Vorfallsberichte, Status-Reports und die Termine, die versprochen wurden, verglichen mit den Terminen, zu denen tatsächlich geliefert wurde. Keine davon erfordert technische Schulung zum Lesen. Sie erfordern, dass Sie den Trend über Monate betrachten, statt ein einzelnes Update isoliert zu beurteilen.

Release-Frequenz sagt mehr aus als Release-Geschwindigkeit

Fragen Sie, wie oft Änderungen tatsächlich in Produktion gehen, nicht wie oft das Team sagt, es sei „fast fertig". Ein gesundes externes Team liefert kleine, häufige Änderungen, oft wöchentlich oder öfter. Ein Team, das zu kämpfen hat, tendiert dazu, alles in große, seltene Releases zu packen, weil jedes einzelne riskant ist und niemand es zweimal machen will.

Verfolgen Sie den Abstand zwischen Releases über drei oder vier Monate. Wird er kleiner, gewinnt das Team zunehmend Vertrauen in seinen eigenen Prozess. Wird er größer, oder verschieben sich Releases immer wieder um eine Woche „um sicher zu sein", dann sagt Ihnen die Codebasis etwas, das der Entwickler vielleicht nicht laut ausspricht: Es ist schwieriger geworden, etwas zu ändern, ohne es zu zerbrechen.

Sie brauchen keine Release Notes, die für Entwickler geschrieben sind. Bitten Sie um ein Einzeiler-Log: Datum, was geändert wurde, wen es betrifft. Wenn dieses Log Lücken von einem Monat oder mehr ohne Erklärung aufweist, fragen Sie nach, warum. Eine gute Antwort benennt ein konkretes Hindernis. Eine vage Antwort ist das, worüber Sie sich Sorgen machen sollten – nicht die Lücke selbst.

Vorfälle zählen, und dann lesen, wie sie erklärt werden

Jedes System hat irgendwann Vorfälle. Was einen Entwickler, der gute Arbeit leistet, von einem unterscheidet, der das nicht tut, ist nicht allein die Anzahl der Vorfälle. Es ist, ob dieselbe Art von Vorfall immer wieder auftritt, und wie die Erklärung nach dem dritten Mal klingt.

Bitten Sie nach jedem Produktionsausfall um eine kurze Notiz: was passiert ist, wie lange es gedauert hat, bis Nutzer es bemerkt haben, wie lange die Behebung gedauert hat, und was verhindern wird, dass es auf dieselbe Weise wieder passiert. Bewahren Sie diese Notizen irgendwo auf, wo Sie zurückblättern können. Lesen Sie sie nach ein paar Monaten zusammen, statt einzeln.

Wenn sich die Zeile „was wird verhindern, dass es wieder passiert" zwischen den Vorfällen immer wieder ändert, lernt der Entwickler dazu. Wenn sich bei unabhängigen Vorfällen immer wieder derselbe vage Satz wiederholt, etwas wie „wir werden es genauer beobachten", dann hat der Entwickler die Ursache nicht wirklich gefunden und hofft, dass es nicht wieder vorkommt. Das ist eines der klarsten nicht-technischen Signale, das es gibt, und es funktioniert unabhängig davon, womit das System gebaut ist.

Klarheit in Reports schlägt Selbstbewusstsein in Reports

Ein monatlicher oder zweiwöchentlicher Report ist der Ort, an dem die eigentliche Bewertung stattfindet, und worauf Sie achten sollten, ist nicht, ob der Report selbstbewusst klingt. Selbstbewusstsein ist billig und leicht in Schriftform zu fälschen. Klarheit ist schwerer zu fälschen, weil sie erfordert, dass der Autor tatsächlich versteht, was er beschreibt.

Ein klarer Report benennt konkrete Dinge: welches Feature ausgeliefert wurde, welcher Bug welche Nutzer betroffen hat, welche Abhängigkeit aktualisiert wurde und warum das wichtig war. Ein Report, der sich auf allgemeine Aussagen stützt, „der Fortschritt bleibt stark" oder „das Team konzentriert sich weiterhin auf Qualität", ohne ein einziges konkretes Beispiel, bedeutet meist, dass es nichts Konkretes Gutes zu berichten gibt, oder dass die Person, die ihn schreibt, den Zustand des Projekts nicht vollständig versteht.

Achten Sie besonders darauf, wie Risiko beschrieben wird. Ein Entwickler, der gute Arbeit leistet, wird Sie über ein Risiko informieren, bevor es zum Problem wird: eine Bibliothek, deren Support ausläuft, ein Teil des Systems, den seit einem Jahr niemand berührt hat, eine Abhängigkeit von einem Drittanbieter-Dienst, der unzuverlässig war. Ein Entwickler, der Risiken erst meldet, nachdem sie bereits einen Vorfall verursacht haben, sucht entweder nicht danach oder möchte nicht derjenige sein, der es anspricht. Beides ist kein gutes Zeichen, und beides ist allein aus den Reports erkennbar.

Beobachten, wie Schätzungen sich über Zeit halten, nicht ob eine einzelne richtig war

Eine einzelne falsche Schätzung bedeutet nichts. Software-Arbeit zu schätzen ist wirklich schwer, und selbst erfahrene Entwickler liegen bei einzelnen Aufgaben weit daneben. Was zählt, ist das Muster über mehrere Schätzungen hinweg über einige Monate, das Sie mit nichts weiter als einer Tabelle und den versprochenen gegenüber den tatsächlichen Lieferterminen verfolgen können.

Achten Sie speziell auf zwei Muster. Das erste ist ein Entwickler, dessen Schätzungen konsequent und vorhersehbar in eine Richtung abweichen, sagen wir doppelt so lang wie versprochen, jedes Mal. Das ist kein Pech. Das ist entweder Selbstüberschätzung, die nie korrigiert wird, oder die Zurückhaltung, Ihnen eine Zahl zu geben, die Ihnen nicht gefallen wird. Das zweite ist ein Entwickler, dessen Schätzungen wild schwanken, mal früher, mal Monate später, ohne erkennbaren Grund. Das deutet meist auf eine Codebasis hin, bei der niemand, auch nicht die Person, die daran arbeitet, sagen kann, wie schwer eine Änderung wird, bevor man nicht schon mitten drin ist.

Ein Entwickler, der Ihr System kennenlernt, wird die Abweichung über die Zeit verkleinern. Einer, der Schätzungen immer wieder auf dieselbe Weise verfehlt, oder mit wachsender Abweichung, lernt das System entweder nicht, oder ist nicht ehrlich zu Ihnen darüber, was er vorfindet. In beiden Fällen sehen Sie es in den Zahlen, die Sie bereits haben, ohne eine Zeile Code zu lesen.

Wenn die Signale in die falsche Richtung zeigen

Wenn mehr als eine dieser vier Prüfungen gleichzeitig schlecht tendiert – Releases werden langsamer, dieselben Vorfallserklärungen wiederholen sich, Reports werden vager, Schätzungen weichen weiter ab –, lohnt es sich, jemanden hinzuzuziehen, der sich den tatsächlichen Zustand der Codebasis ansieht, bevor sich die Beziehung weiter verschlechtert. Das muss nicht bedeuten, den Entwickler zu ersetzen. Oft bedeutet es ein externes Code-Qualitäts-Review, das Ihnen in klaren Worten sagt, was unter der Oberfläche tatsächlich nicht stimmt und ob es sich um ein Personen-, ein Prozess- oder eine Codebasis handelt, die leise schwieriger zu bearbeiten geworden ist, als irgendjemand laut zugegeben hat.

Das ist die Art von Bewertung, die wir für Gründer und fachfremde Inhaber durchführen, die die oben genannten Symptome sehen, aber nicht sagen können, was sie verursacht. Auch hierfür müssen Sie den Code nicht verstehen. Sie erhalten eine schriftliche Antwort: in welchem Zustand sich das System tatsächlich befindet, was die Behebung kosten wird, und was als Nächstes zu tun ist.

Wenn Ihnen eines der vier oben genannten Muster bekannt vorkommt, melden Sie sich unter hello@wolf-tech.io oder schauen Sie sich an, was wir bei wolf-tech.io machen. Ein externer Blick auf die tatsächliche Codebasis beantwortet oft in einer Woche, was Monate an Reports nicht konnten.