Die Frage landet ungefähr zweimal im Monat in meinem Postfach. Eine Variante von: “Wir evaluieren Symfony-Agenturen für [Migration / Skalierung / Audit / Neuentwicklung]. Was sollten wir fragen?” Die Unternehmen, die anfragen, sind meist in der Wachstumsphase, das Budget ist real und der Einsatz hoch genug, dass die falsche Vendor-Wahl sechsstellig kostet.
Die meisten Buyer’s Guides zu diesem Thema sind von Anbietern geschrieben. Sie betonen also genau das, worin der eigene Laden zufällig stark ist, und lassen die Fragen weg, die die eigenen Schwächen offenlegen würden. Dieser Essay macht das Gegenteil. Es ist die Liste an Fragen, die ich stellen würde, wenn ich der Käufer wäre, mit dem Wissen aus zwölf Jahren in Symfony-Engagements als Contributor und Anbieter.
Das Framework ist weniger wichtig als Sie denken; das Team ist wichtiger. Das häufigste Versagensmuster ist nicht “sie haben den falschen Stack gewählt”, sondern “sie haben einen respektablen Vendor gewählt, dessen Senior-Leute nach dem Sales-Call nie wieder aufgetaucht sind”. Unten sind die Fragen, die diese Lücke aufdecken, bevor Sie unterschreiben.
Frage 1: wer sitzt an der Tastatur, und sind diese Personen am Call?
Jede Symfony-Agentur hat eine Pyramide. Senior-Partner machen den Pitch, mittlere Engineers führen das Engagement, und der eigentliche Code wird von Leuten geschrieben, die Sie nie kennengelernt haben. Manchmal ist die Pyramide ehrlich: die Seniors reviewen Architektur-Entscheidungen, die Juniors setzen um. Manchmal ist sie eine Sales-Taktik: die Seniors verschwinden in dem Moment, in dem der SOW unterschrieben ist.
Sie können die Pyramide nicht verhindern. Sie können fragen, welche Personen namentlich den produktiven Code schreiben werden. Holen Sie diese auf einen 30-minütigen Technical Call, bevor Sie zusagen. Fragen Sie jede einzelne:
- “Erzählen Sie mir vom letzten Symfony-Bug, den Sie in Produktion gedebuggt haben.”
- “Was ist Ihre Meinung zu API Platform vs. handgeschriebenen Controllern?”
- “Wenn Sie eine neue Codebasis übernehmen, welchen PR öffnen Sie zuerst?”
Die Antworten müssen nicht mit meinen oder Ihren übereinstimmen. Sie müssen spezifisch sein, verteidigt werden können und an realen Systemen verankert sein. Wenn der namentlich genannte Engineer in Framework-Slogans spricht und sich an keinen konkreten Vorfall der letzten sechs Monate erinnern kann, ist die Pyramide hohl. Gehen Sie weiter.
Frage 2: können sie Ihnen eine Codebasis zeigen, kein Slide-Deck?
Sales-Decks sind in jeder Agentur ein Stück Belletristik. Sie zeigen Case-Studies, die zu 80 Prozent stimmen, nacherzählt von jemandem, der den Code nicht geschrieben hat. Das Signal ist nicht die Case-Study. Das Signal ist, ob die Agentur Ihnen eine echte, anonymisierte Commit-Historie auf den Tisch legen kann.
Fragen Sie nach einem repräsentativen Pull Request aus einem aktuellen Engagement. Eine Symfony-7-Migration. Ein Messenger-Handler-Rewrite. Ein Test-Coverage-Push von 12 auf 70 Prozent. Irgendein nicht-trivialer PR. Lesen Sie das Diff. Lesen Sie die Review-Kommentare. Lesen Sie, was gemerged wurde und was zurückgewiesen wurde.
Sie lernen drei Dinge aus einem PR:
- Wie das Team unter Deadline-Druck Code schreibt. Naming, Error-Handling, Test-Coverage, Tiefe des Refactors. Diese Dinge lügen nicht.
- Wie das Team auf Reviews reagiert. “Gefixt” ohne Erklärung ist ein anderes Signal als “gefixt, und Test für den in Zeile 47 angesprochenen Edge-Case ergänzt”.
- Wie die interne Messlatte aussieht. Wenn ein Senior aus der Agentur unsauberen Code reviewt und approved hat, dann ist das die Messlatte, die Sie kaufen.
Agenturen, die Ihnen keinen PR zeigen können, sind keine Agenturen. Es sind Sales-Orgs mit Subunternehmern.
Frage 3: wie widersprechen sie Ihnen?
Die teuren Fehler in Consulting-Engagements sind keine Bugs. Es sind die Momente, in denen der Kunde das Falsche fordert und die Agentur es fröhlich ausliefert. Ein schlechtes Rewrite, das das Team hätte stoppen müssen (siehe Was ich CTOs sage, die neu schreiben wollen). Ein Skalierungsmuster, das nicht zum Last-Profil passt. Eine Komplexitätsebene, die das Team nach dem Abgang der Agentur nicht halten kann.
Der Schutz davor ist eine Agentur, die widerspricht. So testen Sie es: schlagen Sie im Discovery Call etwas vor, von dem Sie ahnen, dass es leicht falsch ist. Eine verfrühte Microservice-Aufspaltung. Synchrones Messaging, wo async offensichtlich passen würde. Integration-Tests überspringen. Schauen Sie, was sie tun.
Eine gute Agentur sagt “Das halte ich hier nicht für die richtige Entscheidung, und hier ist warum”. Eine schlechte sagt “Ja, das können wir umsetzen”. Die höfliche Mitte, “Das können wir umsetzen, hier ein paar Punkte zum Bedenken”, ist akzeptabel, aber beobachten Sie sie genau. Wenn jede schwierige Entscheidung mit “Sie entscheiden” zu Ihnen zurückgespielt wird, kaufen Sie keine Expertise. Sie kaufen Staff-Augmentation zu Beratungsmargen.
Frage 4: was richtet das Preismodell wirklich aus?
Es gibt drei gängige Preisformen im Symfony-Consulting, jede mit ihrem eigenen Versagensmuster.
Time and Materials. Die Agentur stellt Stunden in Rechnung. Versagensmuster: Gold-Plating. Engagements ziehen sich. Das Team hat keinen ökonomischen Anreiz, pünktlich fertig zu werden, weil pünktlich fertig werden Umsatzverlust bedeutet. Gut für Engagements mit ehrlich unbekanntem Scope (Audits, Archäologie). Schlecht für Engagements mit klarem Scope und vorwiegend ausführender Arbeit.
Festpreis. Die Agentur committet sich auf ein Deliverable zu einem festen Honorar. Versagensmuster: Qualität wird gekürzt, sobald das Budget weh tut. Der Anreiz ist es, etwas auszuliefern, das die Abnahme besteht, nicht etwas, das zwei Jahre Feature-Arbeit überlebt. Gut für sehr sauber abgegrenzte Stücke mit klaren Abnahmekriterien. Schlecht für alles mit Unbekannten.
Outcome-orientierter Retainer. Monatlicher Retainer, Scope wird laufend ausgehandelt, beide Seiten können mit 30 Tagen Frist kündigen. Versagensmuster: bequeme Retainer, in denen das Team mitsegelt. Gut für lange Engagements, in denen der Kunde eingebettete Expertise statt eines Deliverables möchte. Die “30-Tage-raus”-Klausel zählt, weil sie die Agentur ehrlich zum gelieferten Wert hält.
Es gibt kein “richtiges” Modell. Es gibt ein Modell, das zur Arbeit passt. Wenn eine Agentur unabhängig von der Arbeit nur eine Form vorschlägt, fahren sie ihr eigenes Playbook, nicht Ihres.
Red Flags, die ich persönlich gesehen habe
- Das Proposal hat mehr Seiten zu den eigenen Credentials der Agentur als zum tatsächlichen Engagement-Plan.
- Der namentlich genannte Senior-Engineer steht auf jedem Proposal. Es gibt nicht genug Stunden in der Woche, damit das ehrlich ist.
- Das Team will weder Cloud-Provider, noch Queue-Broker, noch PHP-Versionen nennen, die es bevorzugt. Sie behaupten, “Stack-agnostisch” zu sein. Echte Engineers haben Vorlieben.
- Die Agentur weigert sich, überhaupt einen Junior auf das Engagement zu setzen. Entweder gibt es keine Juniors, oder die Bank wird versteckt.
- Der Retainer verlängert sich automatisch. Eine Agentur, die den nächsten Monat gewinnen muss, ist eine Agentur, die im aktuellen Monat Arbeit liefert.
Green Flags, die meist Erfolg vorhersagen
- Sie nennen von sich aus die Namen und Daten von Engagements, die nicht gut liefen, und was sie daraus gelernt haben.
- Sie wollen Ihre Codebasis sehen, bevor sie ein Angebot machen. Nicht nur das README. Das echte Repo.
- Das erste vorgeschlagene Deliverable ist klein, endlich und verwerfbar. Ein zweiwöchiges Audit. Ein Spike auf den Flaschenhals. Etwas, das Sie ohne verlorenes Asset abbrechen können.
- Sie schicken Ihnen ihre internen Coding-Standards ungefragt zu, bevor das Engagement startet.
Wo Devtide tendenziell hineinpasst
Ich sage es direkt: Devtide ist eine kleine, senior-lastige Agentur. Ich bin per Design auf jedem Engagement. Wir führen keine Junior-Bank, weil wir keine Engagements besetzen, die eine bräuchten. Wenn Ihr Projekt eine sechsmonatige Team-Erweiterung mit fünf Engineers ist, sind wir die falsche Wahl. Wenn es ein sechswöchiges Monolith-Audit ist, ein Symfony-Major-Upgrade oder eine Strangler-Fig-Migration auf einem System, das keinen Downtime verträgt, sind wir wahrscheinlich die richtige Wahl.
Schauen Sie sich die Arbeitsmuster in Strangler-Fig-Pattern für Symfony-Monolithen und Das ehrliche Architektur-Review an, um zu sehen, wie ein Engagement aussieht, bevor Sie einen Call buchen.
Referenzen
- Joel Spolsky, Things You Should Never Do, Part I: zu den Risiken vollständiger Rewrites, dem häufigsten Kauf-Versagensmuster in diesem Markt.
- Martin Fowler, StranglerFigApplication: die kanonische Alternative zum Rewrite, den die meisten Agenturen pitchen.
- Symfony Certified Developer Programm: ein Credential-Filter, keine Garantie.
