So wählen Sie den richtigen Software-Entwicklungspartner

Ein Softwareunternehmen, das einen Leitfaden zur Auswahl eines Softwareunternehmens schreibt, hat einen offensichtlichen Interessenkonflikt. Deshalb zuerst der Nachweis, auf den es hier ankommt: Ein erheblicher Teil unserer Arbeit besteht darin, Projekte zu übernehmen, die anderswo schiefgegangen sind - Rettungen, Neuaufbauten, Modernisierungen von Systemen, die drei Jahre alt und schon Legacy sind. Wir sehen die falsche Entscheidung also von innen, 18 Monate nach der Unterschrift, und das Muster wiederholt sich mit bemerkenswerter Regelmäßigkeit. Fast nie hat der Auftraggeber aus Nachlässigkeit falsch gewählt. Er hat falsch gewählt, weil der übliche Auswahlprozess die falschen Dinge misst.

Von außen sind Entwicklungsfirmen kaum zu unterscheiden: dieselben Fallstudien, dieselben Logos, dieselben Sätze über Senior-Entwickler und agile Lieferung, unsere eingeschlossen. Und die Werkzeuge, mit denen Auftraggeber die Entscheidung herbeiführen wollen, also Portfolio, Referenzen und Tagessätze, sind genau die Werkzeuge, an denen jede Firma jahrelang gefeilt hat. Diese Checkliste hilft Ihnen, an ihnen vorbeizusehen.

Warum Referenzen und Portfolios in die Irre führen

Ein Portfolio ist eine Auswahl der Höhepunkte. Jede Firma zeigt ihre drei besten Projekte, und diese Auswahl sagt nichts über das durchschnittliche Projekt, weil ein Portfolio schon von seiner Konstruktion her ein Survivorship-Bias ist. Die Vorhaben, die ein Jahr über Plan liefen, ausgeliefert und still beerdigt wurden oder im Streit endeten, stehen nicht auf der Website, und die Vertraulichkeit liefert jeder Firma einen ehrbaren Grund für diese Lücken. Ein Portfolio zeigt Ihnen, wozu eine Firma im besten Fall fähig ist. Arbeiten werden Sie mit ihrem Normalfall.

Referenzen haben denselben Fehler, nur ein freundlicheres Gesicht: Die Firma sucht sie aus. Sie bekommen die drei zufriedensten Kunden der letzten fünf Jahre und nie die Nummer desjenigen, dessen Projekt eingestellt wurde. Selbst eine ehrlich begeisterte Referenz ist ein schwacher Beleg, weil das Ergebnis an dem Team hing, das damals besetzt war; die Entwickler hinter der Vorzeige-Fallstudie sind seitdem womöglich zweimal weitergezogen.

Anrufen sollten Sie trotzdem, nur mit anderen Fragen. Nicht „waren Sie zufrieden“, denn darauf folgt ein einstudiertes Ja, sondern: „Erzählen Sie mir vom schlechtesten Monat des Projekts und davon, was die Firma daraufhin getan hat.“ Jedes Projekt von nennenswerter Größe hat einen schlechten Monat. Ob die Firma das Problem früh auf den Tisch gelegt, ehrlich neu kalkuliert und behoben hat oder ob sie verstummt ist und weiter Rechnungen geschrieben hat, ist die aufschlussreichste Auskunft, die eine Referenz überhaupt geben kann.

Was einen guten Software-Engineering-Partner ausmacht: vier Signale

Das erste ist, wie geschätzt wird. Wer Ihnen eine Zahl nennt, bevor er Ihren Betrieb kennt, hat Ihnen damit bereits erklärt, wie er arbeitet. Eine belastbare Aufwandsschätzung entsteht aus Fragen: nach Ihren Abläufen, Ihren Daten, den Systemen, die Sie ohnehin betreiben, und den Ausnahmen, die Ihr Geschäft zu Ihrem machen. Kommt der Preis vor diesen Fragen, ist er nicht aus Ihrem Projekt abgeleitet, sondern gesetzt worden, um es zu gewinnen. Die Differenz zwischen beiden Zahlen taucht später wieder auf, verkleidet als Nachtrag. Wenn Sie vor dem ersten Gespräch einen Anhaltspunkt möchten: Hier steht, was die Kosten individueller Software wirklich bestimmt.

Wie eine Firma schätzt, so liefert sie auch. Wer beim Preis rät, rät später bei der Umsetzung.

Das zweite ist, wozu die Firma Nein sagt. Fragen Sie direkt, welche Projekte sie abgelehnt hat und warum. Wer kein einziges nennen kann, nimmt entweder alles an, was bezahlt wird - dann besetzt er Ihr Projekt mit dem, der gerade frei ist, und nicht mit dem, der passt -, oder er hat nie ernsthaft geprüft, worin er wirklich gut ist. Die Absagen einer Firma sind die ehrlichste Landkarte ihrer Kompetenz, die Sie in einem Vertriebsprozess bekommen.

Das dritte ist, wer den Code schreibt. Die Menschen in Ihren ersten drei Terminen sind meistens nicht die, die Ihr System später entwickeln. Verlangen Sie den Tech Lead, der Ihr Projekt verantworten würde: den Entwickler selbst, nicht die Delivery-Leitung. Stellen Sie ihm technische Fragen zu Ihrem Problem. Eine Firma, die ihren Leuten vertraut, stellt sie Ihnen ohne Zögern vor; eine Firma, die Sie auf der Account-Ebene hält, pflegt einen Eindruck.

Das vierte ist, wie die Übergabe aussieht. Am Ende eines Projekts laufen die Interessen am weitesten auseinander: Alles davor gut zu machen, zahlt sich für den Dienstleister aus, während Dokumentation, Übergabe und Ihre Unabhängigkeit ihn nur kosten. Verlangen Sie deshalb einen Beleg - eine geschwärzte Architekturdokumentation, ein Runbook oder ein Übergabepaket aus einem abgeschlossenen Projekt. Wer so etwas vorlegen kann, hat es schon einmal getan und rechnet damit, dass Sie ohne ihn weiterarbeiten. Wer stattdessen von Partnerschaft spricht, statt ein Dokument zu zeigen, beschreibt höflich eine Abhängigkeit.

Diese vier Signale unterscheiden einen Software-Engineering-Partner von einem Anbieter, der Stunden verkauft: Der eine steht für das Ergebnis ein, der andere für den Stundenzettel.

Warnzeichen, die eine Absage rechtfertigen

Seniorität als Lockvogel kommt am häufigsten vor. Senior-Entwickler führen den Pitch und die Discovery; ab dem zweiten Monat erzählt die Commit-Historie eine andere Geschichte. Dagegen schützt kein Vertrauen, sondern nur die Struktur: namentlich benannte Personen im Vertrag, das Recht, jeden Ersatz vor dem Einsatz kennenzulernen, und ein Blick darauf, wer tatsächlich in den Standups sitzt.

Stundenabrechnung ohne festen Umfang. Nach Stunden abzurechnen ist nicht per se falsch. Stunden ohne Meilensteine, ohne schriftlich fixierten Umfang und ohne Definition von „fertig“ bedeuten allerdings, dass der Dienstleister umso mehr verdient, je länger Ihr Projekt dauert, und nichts in der Struktur hält dagegen. Die richtige Frage lautet nicht „Stunden oder Festpreis“, sondern: Wer trägt die Verantwortung für die Schätzung? Lautet die Antwort „Sie“, dann sind Sie selbst die einzige Bremse. (Die Alternative haben wir in Warum Festpreisprojekte scheitern - und wie die Abrechnung nach Meilensteinen das löst beschrieben.)

„Wir können Montag anfangen.“ Eine Firma, deren gesamtes Team morgen frei ist, sagt Ihnen damit etwas über die Nachfrage nach ihrer Arbeit. Echte Lücken gibt es, weil ein Projekt endet oder ein Starttermin sich verschiebt; ein komplettes Senior-Team ohne Auslastung ist bei einer Firma, die man engagieren möchte, dagegen selten. Behandeln Sie sofortige Verfügbarkeit in dieser Größenordnung mit derselben Skepsis wie einen Chirurgen ohne Warteliste.

Keine Meinung zu den unspektakulären Teilen Ihrer Branche. Jede Branche hat ihre unscheinbare Maschinerie: Abstimmungen, regulatorische Sonderfälle, Preisausnahmen, Planungsregeln. Genau dort gehen Projekte unter. Vorerfahrung in Ihrer Branche braucht ein Partner nicht, aber bei den langweiligen Teilen muss er hellhörig werden, weil er den Großteil des Projekts mit ihnen verbringen wird. Driftet das Gespräch immer wieder zur aufregenden Oberfläche des Produkts, lernt er die öden neun Zehntel auf Ihre Kosten.

Acht Fragen für das erste Gespräch

Signale lassen sich leichter lesen, wenn Sie direkt nach ihnen fragen. Diese acht Fragen lohnen sich wörtlich, ungefähr in dieser Reihenfolge.

Achten Sie auf Konkretion und auf leichtes Unbehagen. Gute Antworten nennen echte Projekte, echte Fehler und echte Zwänge; schlechte Antworten sind glatt, allgemein und sofort gefällig. Frage sechs prüft das Urteil über den Umfang: Der richtige Partner argumentiert für eine fokussierte erste Version in 2-3 Monaten statt für eine Plattform in einem Jahr und sagt Ihnen, welche Teile Ihres Briefings warten können. Frage sieben ist die Probe auf die Abhängigkeit. Wer sich die Verlängerung verdienen will, macht Ihnen das Gehen billig: Ihre Repositories, Ihre Infrastruktur, Dokumentation als Liefergegenstand. Wer Sie dagegen binden will, wird an dieser Stelle vage.

Wann Sie Ihren Software-Entwicklungspartner wechseln sollten

Viele Leser dieser Checkliste wählen nicht ihren ersten Partner, sondern überlegen, ob sie den jetzigen ersetzen sollen. Die Warnzeichen sind selten eine einzelne Katastrophe, sondern eine schleichende Entwicklung: verpasste Termine, für die es irgendwann keine Erklärungen mehr gibt, ein System, das nur der Dienstleister deployen kann, Änderungswünsche, die jedes Quartal teurer werden, und ein Team, das schneller wechselt, als es dokumentiert. Treffen zwei davon zu, wenden Sie die Checkliste oben auf Ihren jetzigen Partner an, als würden Sie ihn zum ersten Mal treffen.

Entscheiden Sie sich für einen Wechsel, zählt die Reihenfolge mehr als der neue Dienstleister. Sichern Sie zuerst die Repositories, die Infrastrukturkonten und die Zugangsdaten, holen Sie sich die vorhandene Dokumentation, so dünn sie auch sein mag, und übergeben Sie in Stufen statt mit einem harten Schnitt. Systeme auf diese Weise zu übernehmen, ist ein großer Teil unserer Arbeit - mehr dazu in So wechseln Sie Ihren Software-Entwicklungspartner, ohne das Projekt zu verlieren und in Altsysteme modernisieren, ohne alles neu zu schreiben.

Klein anfangen, statt alles auf einmal zu entscheiden

Das eigentliche Problem der Partnerwahl ist kein einzelnes Signal, sondern der Zuschnitt des Verfahrens: zwei Gespräche, ein Angebot, eine sechsstellige Verpflichtung, und Sie sollen alles auf einmal entscheiden. Zu Gewissheit darüber, wie sich eine Firma unter realen Bedingungen verhält, können Sie sich nicht durchfragen; eine kleine Stichprobe davon können Sie aber kaufen. Statt den großen Vertrag zu unterschreiben, beginnen Sie mit einem kurzen diagnostischen Einsatz: ein bis zwei Wochen in einem einzigen Workflow, am Ende eine Aufwandsschätzung, eine Architekturskizze und eine Amortisationsrechnung, die Ihnen gehören, gleich wie es danach weitergeht.

Eine Diagnose macht aus jedem Signal dieses Beitrags eine Beobachtung statt einer Behauptung. Sie sehen, wie geschätzt wird, statt danach zu fragen. Sie lernen die Entwickler kennen, die tatsächlich arbeiten würden, weil eine Diagnose technische Arbeit ist, die kein Account-Team leisten kann. Und Sie halten am Ende ein Ergebnis in der Hand, das Sie zu einer anderen Firma mitnehmen können; genau das ist die Probe aufs Exempel. Nützt das Ergebnis nur, wenn Sie den Anbieter beauftragen, war es ein Vertriebsdokument mit dem Etikett eines Liefergegenstands. Manche Firmen berechnen so etwas, manche bieten eine Variante kostenlos an - wir tun das, und sie ist der Anfang jedes unserer Projekte. Ob bezahlt oder kostenlos, zählt dabei weniger als der Zuschnitt: klein, begrenzt und mit einem Ergebnis, das die Zusammenarbeit überdauert.

Es ist zugleich der günstigste Weg, herauszufinden, dass eine Firma nicht zu Ihnen passt, unsere eingeschlossen. Wenden Sie diese Checkliste sauber an, kann durchaus herauskommen, dass ein anderer Partner besser zu Ihrem Projekt passt als wir. Das ist kein Versagen der Checkliste, sondern genau ihr Zweck. Wer klein anfängt, bezahlt für diese Erkenntnis zwei Wochen statt zwei Quartale.

Kurz gefasst: Lassen Sie die Auswahl der Höhepunkte liegen und lesen Sie die Firma an ihrem Verhalten. Der Partner, den Sie suchen, nennt einen Preis erst, wenn er den Betrieb verstanden hat, kann Ihnen sagen, was er ablehnt, stellt Ihnen seine Entwickler vor, zeigt ein echtes Übergabedokument und richtet das Projekt so ein, dass Ihnen das Gehen leichtfällt. Denn wie sich eine Firma verhält, solange sie noch um Sie wirbt, ist die Obergrenze dessen, was danach kommt.

Häufige Fragen