Ein Softwareunternehmen, das einen Leitfaden zur Auswahl eines Softwareunternehmens schreibt, hat einen offensichtlichen Interessenkonflikt — beginnen wir deshalb mit dem Nachweis, auf den es ankommt: Ein erheblicher Teil unserer Arbeit besteht darin, Projekte zu übernehmen, die anderswo schiefgelaufen sind. Rettungen, Neuaufbauten, Modernisierungen von Systemen, die drei Jahre alt und schon Legacy sind. Wir sehen von innen, wie die falsche Wahl aussieht, achtzehn Monate nach der Vertragsunterschrift — und das Muster ist bemerkenswert konsistent. Der Auftraggeber hat fast nie 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. Die Websites zeigen dieselben Fallstudien, dieselben Logos, dieselben Aussagen über Senior-Entwickler und agile Lieferung. Unsere eingeschlossen. Und die Werkzeuge, zu denen Auftraggeber greifen, um die Entscheidung herbeizuführen — Portfolios, Referenzen, Preislisten — sind genau die Werkzeuge, die jede Firma über Jahre poliert hat. Dies ist eine Checkliste, um an ihnen vorbeizusehen.
Warum Referenzen und Portfolios in die Irre führen
Ein Portfolio ist eine Bestenauswahl. Jede Firma zeigt ihre drei besten Projekte, und diese Auswahl sagt nichts über das mittlere Engagement aus — ein Portfolio ist Survivorship-Bias per Konstruktion. Die Projekte, 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 respektablen Grund für die Lücken. Wer ein Portfolio liest, erfährt die Obergrenze einer Firma. Leben werden Sie mit ihrem Median.
Referenzen haben denselben Fehler mit freundlicherem Gesicht: Die Firma sucht sie aus. Man gibt Ihnen die drei zufriedensten Kunden der letzten fünf Jahre — und niemals die Nummer desjenigen, dessen Projekt eingestellt wurde. Selbst eine aufrichtig begeisterte Referenz ist ein schwacher Beleg, denn das Ergebnis hing vom konkreten Team ab, das in jenem Jahr im Einsatz war — und die Leute, die die Vorzeige-Fallstudie gebaut haben, sind seitdem womöglich zweimal weitergezogen.
Anrufen lohnt sich trotzdem — Sie müssen nur andere Fragen stellen. Nicht „waren Sie zufrieden“, was zu einem einstudierten Ja einlädt, sondern „erzählen Sie mir vom schlechtesten Monat des Projekts, und was dagegen unternommen wurde“. Jedes Projekt von nennenswerter Größe hat einen schlechten Monat. Ob die Firma das Problem früh auf den Tisch gebracht, ehrlich neu kalkuliert und es behoben hat — oder verstummt ist und einfach weiter Rechnungen gestellt hat —, ist die aufschlussreichste Information, die eine Referenz Ihnen geben kann.
Vier Signale, die Ergebnisse wirklich vorhersagen
Das erste ist, wie geschätzt wird. Eine Firma, die Ihnen eine Zahl nennt, bevor sie Ihren Betrieb verstanden hat, sagt Ihnen damit, wie sie arbeitet. Eine echte Aufwandsschätzung entsteht aus echten Fragen — zu Ihren Abläufen, Ihren Daten, den Systemen, die Sie bereits betreiben, den Ausnahmen, die Ihr Geschäft zu Ihrem machen. Kommt der Preis vor diesen Fragen, wurde er nicht aus Ihrem Projekt abgeleitet; er wurde gesetzt, um es zu gewinnen — und die Differenz zwischen diesen beiden Zahlen taucht später wieder auf, verkleidet als Änderungsaufträge.
Schätzverhalten sagt Lieferverhalten voraus. Eine Firma, die beim Preis rät, wird auch beim Bauen raten.
Das zweite ist, wozu Nein gesagt wird. Fragen Sie direkt: Welche Projekte haben Sie abgelehnt, und warum? Eine Firma, die keines nennen kann, nimmt entweder alles an, was bezahlt — dann wird Ihr Projekt von dem besetzt, der gerade frei ist, nicht von dem, der passt — oder hat nie ernsthaft darüber nachgedacht, worin sie wirklich gut ist. Die Form der Absagen einer Firma ist die ehrlichste Landkarte ihrer Kompetenz, die Sie in einem Vertriebsprozess bekommen werden.
Das dritte ist, wer den Code schreibt. Die Menschen in Ihren ersten drei Terminen sind meist nicht die, die Ihr System bauen werden. Bitten Sie darum, den Tech Lead kennenzulernen, der Ihr Projekt verantworten würde — den tatsächlichen Entwickler, nicht die Delivery-Leitung — und stellen Sie ihm technische Fragen zu Ihrem Problem. Eine Firma, die ihren Entwicklern 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 gehen die Interessen am weitesten auseinander: Alles davor gut zu machen, liegt im eigenen Interesse des Dienstleisters; Dokumentation, Übergabe und Ihre Unabhängigkeit sind die Teile, die ihn nur kosten. Bitten Sie also um Belege — eine geschwärzte Architekturdokumentation, ein Runbook oder ein Übergabepaket aus einem abgeschlossenen Projekt. Eine Firma, die so etwas vorlegen kann, hat das schon getan und erwartet, dass Sie ohne sie weiterlaufen können. Eine Firma, die von Partnerschaft spricht, statt ein Dokument vorzulegen, beschreibt höflich einen Lock-in.
Warnzeichen, bei denen Sie gehen sollten
Seniorität als Lockvogel ist das häufigste. Senior-Entwickler führen den Pitch und die Discovery; die Commit-Historie erzählt ab Monat zwei eine andere Geschichte. Schützen Sie sich strukturell, nicht über Vertrauen: namentlich benannte Personen im Vertrag, das Recht, jeden Ersatz vor dem Einsatz kennenzulernen, und ein Blick darauf, wer tatsächlich in den Standups auftaucht.
Stundenabrechnung ohne Scope-Disziplin.Nach Stunden abzurechnen ist nicht per se falsch — aber Stunden ohne Meilensteine, ohne schriftlich fixierten Umfang und ohne Definition von „fertig“ bedeuten: Der Dienstleister verdient umso mehr, je länger Ihr Projekt dauert, und nichts in der Struktur hält dagegen. Die richtige Frage lautet nicht „Stunden oder Festpreis“, sondern „wo liegt die Verantwortung für die Schätzung“. Lautet die Antwort: bei Ihnen — dann sind Sie die Scope-Disziplin.
„Wir können Montag anfangen.“ Eine Firma, deren gesamtes Team morgen verfügbar ist, sagt Ihnen damit etwas über die Nachfrage nach ihrer Arbeit. Echte Lücken kommen vor — ein Projekt endet, ein Starttermin verschiebt sich — aber ein komplettes Senior-Team auf der Bank ist bei jeder Firma, die man engagieren möchte, selten. Behandeln Sie sofortige Verfügbarkeit in großem Umfang so, wie Sie einen Chirurgen ohne Warteliste behandeln würden.
Keine Meinung zu den unglamourösen Teilen Ihrer Branche. Jede Domäne hat ihre unspektakuläre Maschinerie — Abstimmungen, regulatorische Sonderfälle, Preisausnahmen, Planungsregeln — und genau dort gehen Projekte tatsächlich unter. Ein Partner braucht keine Vorerfahrung in Ihrer Branche, aber bei den langweiligen Teilen müssen seine Augen leuchten, denn genau die wird er den Großteil des Projekts über bauen. Driftet das Gespräch immer wieder zur aufregenden Oberfläche des Produkts, werden die öden neun Zehntel auf Ihre Kosten gelernt.
Acht Fragen für das erste Gespräch
Signale lassen sich leichter lesen, wenn man direkt nach ihnen fragt. Diese Fragen lohnt es sich wörtlich zu stellen, ungefähr in dieser Reihenfolge.
- „Was müssten Sie über unseren Betrieb wissen, bevor Sie eine Zahl nennen würden?“
- „Welche Projekte haben Sie im letzten Jahr abgelehnt, und warum?“
- „Wer genau würde den Code schreiben — können wir diese Personen vor der Unterschrift kennenlernen?“
- „Erzählen Sie uns von einem Projekt, das schlecht gelaufen ist. Was haben Sie danach geändert?“
- „Wie sieht die Übergabe aus — können wir ein geschwärztes Beispiel aus einem echten Projekt sehen?“
- „Was würden Sie aus unserem Briefing streichen, um eine erste Version schneller live zu bringen?“
- „Was passiert, wenn wir nach drei Monaten aufhören wollen?“
- „Woran würden wir nach sechs Monaten erkennen, ob das Ganze funktioniert?“
Achten Sie auf Konkretion und leichtes Unbehagen. Gute Antworten nennen echte Projekte, echte Fehler und echte Zwänge; schlechte Antworten sind glatt, generisch und sofort gefällig. Frage sechs prüft das Scope-Urteil — der richtige Partner wird für eine fokussierte erste Version in 2–3 Monaten argumentieren statt für eine Plattform in einem Jahr, und Ihnen sagen, welche Teile Ihres Briefings warten können. Frage sieben ist der Lock-in-Test: Ein Partner, der sich die Verlängerung verdienen will, macht das Gehen günstig — Ihre Repositories, Ihre Infrastruktur, Dokumentation als Liefergegenstand —, während ein Anbieter, der Sie besitzen will, vage wird.
Das Risiko senken: kleiner anfangen als der Vertrag
Das tiefste Problem der Partnerwahl ist kein einzelnes Signal, sondern dass der übliche Prozess von Ihnen verlangt, alles auf einmal zu entscheiden — zwei Gespräche, ein Angebot, eine sechsstellige Verpflichtung. Sie können sich nicht zu Gewissheit darüber interviewen, wie sich eine Firma unter realen Bedingungen verhält — aber Sie können eine kleine Stichprobe davon 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 — egal, was danach passiert.
Eine Diagnose verwandelt jedes Signal aus diesem Beitrag von einer Behauptung in eine Beobachtung. Sie sehen zu, wie geschätzt wird, statt danach zu fragen. Sie lernen die Entwickler kennen, die tatsächlich bauen würden, denn eine Diagnose ist technische Arbeit, die das Account-Team nicht leisten kann. Und am Ende halten Sie ein Artefakt in der Hand, das Sie zu einer anderen Firma mitnehmen können — das ist der Lackmustest. Ist das Ergebnis nur nützlich, wenn Sie den Anbieter beauftragen, war es ein Vertriebsdokument im Gewand eines Liefergegenstands. Manche Firmen berechnen so etwas, manche bieten eine Variante kostenlos an — wir tun das, und es ist der Anfang jedes unserer Projekte — aber bezahlt oder kostenlos ist weniger wichtig als die Form: klein, begrenzt und mit einem Ergebnis, das die Zusammenarbeit überdauert.
Es ist außerdem der günstigste Weg, herauszufinden, dass eine Firma nicht zu Ihnen passt — unsere eingeschlossen. Wenden Sie diese Checkliste sauber an, und Sie kommen womöglich zu dem Schluss, dass ein anderer Partner besser zu Ihrem Projekt passt als wir. Das ist kein Versagen der Checkliste; das ist die Checkliste, die funktioniert. Der Sinn des kleinen Anfangs ist, dass die Erkenntnis — wie auch immer sie ausfällt — Sie zwei Wochen kostet statt zwei Quartale.
Die Kurzfassung: Ignorieren Sie die Bestenauswahl und lesen Sie die Firma an ihrem Verhalten ab. Der Partner, den Sie wollen, nennt einen Preis erst nach dem Verstehen, kann Ihnen sagen, was er ablehnt, stellt Ihnen Entwickler vor, zeigt Ihnen ein echtes Übergabedokument und strukturiert das Projekt so, dass Gehen leicht ist. Denn wie sich eine Firma vor dem Vertrag verhält — während sie noch um Sie wirbt —, ist die Obergrenze dessen, wie sie sich danach verhalten wird.