Die meisten Auswahlverfahren vergleichen Preis und Referenzen. Beides sagt wenig über das Ergebnis aus. Dies sind die Prüfungen, die es tun — einschließlich der Vertragsklauseln, die darüber entscheiden, ob Sie gehen können.
Einen Entwicklungspartner auszuwählen ist gerade deshalb schwierig, weil das, was Sie beurteilen, genau das ist, worin Ihnen die Fachkenntnis fehlt. Das übliche Verfahren — drei Angebote einholen, Referenzen ansehen, eine Zahl wählen, mit der man sich wohlfühlt — wählt nach Verkaufsstärke aus und nicht nach Lieferfähigkeit. Folgendes sagt tatsächlich etwas über das Ergebnis aus.
Klären Sie, wer die Arbeit macht
Fragen Sie es direkt: Werden die Menschen in diesem Termin das System bauen? Bei einem erheblichen Teil der Projekte sind die Senioren, die präsentieren, nicht die, die liefern, und die Arbeit geht an ein jüngeres Team oder wird ganz weitergegeben. Das disqualifiziert nicht automatisch, aber Sie sollten es vor der Unterschrift wissen und nicht beim ersten Statustermin.
- Wer genau schreibt den Code, und welche Erfahrung hat diese Person mit Systemen dieser Art?
- Wird die Arbeit ganz oder teilweise weitervergeben?
- Wer ist mein Ansprechpartner, wenn etwas schiefgeht, und welche Befugnis hat er, es zu beheben?
- Was passiert, wenn der leitende Entwickler mitten im Projekt geht?
Prüfen Sie Referenzen statt Portfolios
Ein Portfolio zeigt, was ausgeliefert wurde. Es zeigt nicht, ob es zu spät kam, ob sich das Budget verdoppelte, oder ob der Kunde sie wieder beauftragen würde. Bitten Sie um zwei Referenzen: eine aktuelle und eine zu einem Projekt, das mindestens ein Jahr abgeschlossen ist. Die zweite sagt mehr — sie verrät Ihnen, ob die Software noch lief und betreut wurde, nachdem die Rechnungen aufhörten.
Achten Sie darauf, was bei einer schwierigen Frage passiert
Beschreiben Sie eine Anforderung, die wirklich schwierig oder mehrdeutig ist, und sehen Sie, was zurückkommt. Ein fähiger Anbieter stellt klärende Fragen, benennt die Risiken und sagt Ihnen womöglich, dass die Anforderung so, wie formuliert, eine schlechte Idee ist. Ein weniger fähiger stimmt begeistert zu und bietet sofort an.
Die Bereitschaft, Ihnen im Verkaufsgespräch zu widersprechen, gehört zu den verlässlicheren Anzeichen, die es gibt. Wer zu allem Ja sagt, bevor ein Vertrag existiert, entwickelt nicht plötzlich Urteilskraft, sobald es einen gibt.
Die Vertragsklauseln, die zählen
| Klausel | Was Sie wollen | Warum |
|---|---|---|
| Rechte am Ergebnis | Sie besitzen mit der Zahlung allen Code und alle Dateien | Ohne das lizenzieren Sie womöglich Ihr eigenes System |
| Zugang zum Repository | Im Konto Ihrer Organisation, ab dem ersten Tag | Sie sehen den Fortschritt und werden im Streitfall nicht ausgesperrt |
| Hosting und Domains | Auf Ihren Namen registriert | Die häufigste Form der Bindung und die am leichtesten zu vermeidende |
| Änderungsverfahren | Schriftlich, mit vorab vereinbarten Preisen | Verhindert, dass jede Anpassung neu verhandelt wird |
| Abnahmekriterien | Je Phase vor deren Beginn festgelegt | Gibt „fertig“ eine objektive Bedeutung |
| Ausstiegsregelung | Dokumentierte Übergabe inbegriffen | Irgendwann trennen Sie sich, im Guten oder nicht |
Die mit Abstand nützlichste Klausel ist der Zugang zum Repository ab dem ersten Commit. Einen fähigen und selbstsicheren Anbieter kostet die Zusage nichts, und Zurückhaltung dabei sagt Ihnen etwas Wichtiges.
Signale, die Sie als Warnung behandeln sollten
- Ein Festpreisangebot ohne nennenswerte Analysephase. Entweder ist die Schätzung geraten, oder der Umfang ist so lose definiert, dass man später darüber streiten kann.
- Garantierte Suchpositionen oder garantierter Verkehr. Niemand kontrolliert Googles Ergebnisse, und das Gegenteil zu behaupten, zeugt von Unverständnis oder Täuschung.
- Zurückhaltung, Ihnen Zugang zum Repository zu geben, oder Hosting auf den Namen des Anbieters.
- Ein Angebot, das ausschließlich aus Technologienamen besteht, ohne Bezug auf Ihr geschäftliches Problem.
- Druck, schnell zu unterschreiben, für einen Rabatt, der ausläuft.
- Kein Gespräch über Wartung. Ein Anbieter, der laufende Kosten nicht anspricht, ist unerfahren oder überlässt es Ihnen, sie zu entdecken.
- Referenzen ohne zuordenbare Namen oder Unternehmen.
Ein vernünftiges Auswahlverfahren
- Schreiben Sie das geschäftliche Problem auf, in geschäftlichen Begriffen. Nicht die Lösung, die Sie sich vorgestellt haben — das Problem, und wie Erfolg als Messgröße aussähe.
- Sprechen Sie drei oder vier Anbieter an, deren Erfahrung plausibel passt. Mehr verwässert die Aufmerksamkeit, die Sie jedem Gespräch geben können.
- Bezahlen Sie bei Ihrem Favoriten oder Ihren zwei Favoriten eine Analysephase. Eine bezahlte Analyse erzeugt einen echten Umfang und zeigt Ihnen die Arbeitsweise vor der großen Festlegung.
- Vergleichen Sie Angebote nach Umfang und Ausschlüssen, nicht nach der Zahl oben.
- Holen Sie Referenzen ein, darunter ein älteres Projekt.
- Beginnen Sie nach Möglichkeit mit einem kleinen, echten Stück Arbeit. Eine erste Phase mit echtem Wert ist eine weit bessere Prüfung als jedes Gespräch.
- Lesen Sie den Vertrag gründlich, mit besonderem Blick auf Rechte, Änderungssteuerung und Ausstieg.
Zu Offshore, Nearshore und lokal
Fähige und schwache Entwickler gibt es überall, und der Standort sagt über Qualität weit weniger aus, als man annimmt. Was der Standort sehr wohl beeinflusst, sind die Kommunikationskosten. Ein großer Zeitzonenabstand funktioniert gut bei klar dokumentierten Anforderungen und jemandem auf Ihrer Seite, der die Beziehung aktiv steuert; er funktioniert schlecht bei einer sich entwickelnden Aufgabenstellung, die tägliche Abstimmung braucht.
Gehen Sie schlicht praktisch damit um: Sind Ihre Anforderungen noch in Bewegung, hat überlappende Arbeitszeit Vorrang. Sind sie gut dokumentiert und stabil, ist ein größerer Abstand beherrschbar und der Kostenunterschied möglicherweise real. Fragen Sie, wo das Team tatsächlich sitzt, und nicht, wo das Unternehmen eingetragen ist.
Die Frage, die am meisten zählt
Fragen Sie, was sie täten, wenn das Projekt in Schwierigkeiten geriete — ein verpasster Termin, eine Anforderung, die sich als unmöglich erweist, ein Budget unter Druck. Die Antwort zeigt, wie sie über Risiko denken und über Sie. Anbieter, die seit Jahren liefern, haben gute Antworten, weil sie es erlebt haben. Wer es nicht erlebt hat, wird Ihnen sagen, dass ihm das nicht passiert.
Das ist die Art Arbeit, die wir machen. Wenn es zu etwas passt, das Sie planen, beschreibt unsere Seite zu Individualsoftware, wie wir dabei vorgehen, oder Sie können das Projekt beschreiben und wir sagen Ihnen, was wir davon halten.