Temporärer Webentwickler für eine geschäftskritische Anwendung: Was Sie vor der Unterschrift prüfen sollten

#temporärer webentwickler

Gründer & Lead Developer

Experte für Softwareentwicklung und Legacy-Code-Optimierung

LinkedIn

Ein Produktionsausfall Ihrer Kernanwendung wartet nicht auf einen normalen Einstellungszyklus. Ebenso wenig wartet der plötzliche Weggang eines Entwicklers, ein Anstieg der Support-Tickets nach einem schwachen Quartal oder ein Projekt, das stockte, sobald die Person, die es verstand, gegangen ist. In all diesen Situationen landen Unternehmer bei derselben Suche: schnell einen temporären Webentwickler einstellen, ihm Zugang zu einem System geben, auf das sich das Unternehmen verlässt, und hoffen, dass die ersten dreißig Tage gut laufen.

Diese Hoffnung ist kein Plan. Ein Vertragsentwickler, der einige Wochen oder Monate an Ihrer geschäftskritischen Anwendung arbeitet, kann echten Schaden anrichten, wenn die falschen Dinge vor der Vertragsunterschrift ungeprüft bleiben, und der meiste dieser Schaden bleibt unsichtbar, bis Monate später ein Bug auf eine Änderung zurückgeht, die niemand überprüft hat, oder auf ein Codestück, das außer dem ausgeschiedenen Vertragsentwickler niemand je verstanden hat. Dieser Text richtet sich an Unternehmer, die noch nie einen freiberuflichen Entwickler eingestellt haben und diese Lektionen lieber nicht auf die harte Art lernen möchten.

Fragen Sie nach Stack-Erfahrung, die zu Ihrem tatsächlichen System passt, nicht nach einem Lebenslauf

Ein Entwickler, der stark in React und Node.js ist, passt nicht automatisch zu einer PHP-Anwendung auf einem älteren Framework, und ein allgemeines Full-Stack-Profil sagt Ihnen wenig darüber, ob jemand schon an einer Codebasis wie der Ihren gearbeitet hat. Fragen Sie konkret, mit welchen Framework-Versionen die Person zuletzt gearbeitet hat, ob sie eine Anwendung ähnlichen Alters und ähnlicher Größe gewartet hat, und was sie in einem System wie dem Ihren erwartet, noch bevor sie es gesehen hat.

Ein Kandidat, der bisher nur neue Projekte von Grund auf gebaut hat, kann darin ausgezeichnet sein und trotzdem in einer Anwendung mit jahrelang angesammelten Entscheidungen Mühe haben. Die beiden Fähigkeiten überlappen sich weniger, als man annimmt. Wenn Ihr System älter ist oder technische Schulden trägt, bitten Sie den Kandidaten, durchzugehen, wie er die erste Woche verbringen würde, bevor er irgendeinen Code berührt. Manche Entwickler sagen offen, dass Legacy-Arbeit nicht ihre Stärke ist, und diese Antwort ist mehr wert als ein vages Ja, weil Sie es erfahren, bevor Sie für eine Fehlpassung bezahlt haben, statt danach.

Fragen Sie nach Referenzen, die zu Arbeit wie der Ihren passen, nicht nach allgemeinen Bewertungen

Ein Portfolio abgeschlossener Nebenprojekte zeigt, dass jemand Dinge bauen kann. Es zeigt nicht, dass die Person sorgfältig innerhalb eines Live-Systems arbeiten kann, auf das Kunden sich verlassen. Fragen Sie nach mindestens einer Referenz von einem Kunden, deren Anwendung bereits in Produktion lief, als der Vertragsentwickler anfing, und stellen Sie dieser Referenz eine direkte Frage: Ist etwas kaputtgegangen, und wenn ja, wie wurde es gehandhabt?

Die Antwort ist wichtiger als die Tatsache, dass etwas schiefging. Systeme versagen manchmal, auch bei sorgfältigen Entwicklern. Was Sie eigentlich prüfen, ist, ob die Person ein Problem meldet, sobald sie es sieht, oder es liegen lässt, bis es zum Problem Ihres Kunden wird.

Bestätigen Sie die Berufshaftpflichtversicherung, bevor jemand Zugang erhält

Das ist der Punkt, den nicht-technische Unternehmer am häufigsten überspringen, und er ist einer der folgenreichsten. Wenn die Änderung eines Vertragsentwicklers Ausfallzeit, Datenverlust oder einen Sicherheitsvorfall verursacht, steht eine Berufshaftpflichtversicherung zwischen diesen Kosten und Ihrem Unternehmen, das sie allein tragen müsste. Verlangen Sie einen Nachweis der Versicherung statt einer mündlichen Zusicherung, dass eine besteht, und prüfen Sie, ob die Deckungssumme für die Größe des Systems angemessen ist, an dem gearbeitet wird.

Ein Freelancer ohne Versicherung ist nicht automatisch eine schlechte Wahl, aber es verschiebt das gesamte finanzielle Risiko eines Fehlers auf Sie. Das sollte eine bewusste Entscheidung sein, nicht eine, die einfach so passiert.

Halten Sie NDA und Code-Eigentumsrechte schriftlich fest, bevor die Arbeit beginnt

Hier stecken zwei getrennte Fragen, und Verträge verwischen sie manchmal. Die erste ist Vertraulichkeit: Verpflichtet sich der Entwickler schriftlich, Ihre Geschäftslogik, Kundendaten oder internen Prozesse nicht offenzulegen. Die zweite ist Eigentum: Gehört Ihrem Unternehmen der Code, den die Person schreibt, vollständig und sofort bei Lieferung, oder behält der Vertragsentwickler Rechte, ihn anderswo wiederzuverwenden.

Klären Sie beides, bevor die Arbeit beginnt, nicht nachträglich, wenn sich die Verhandlungsposition schon verschoben hat. Eine kurze, klar formulierte Vereinbarung zu beiden Punkten schützt Sie weit mehr als eine mündliche Abmachung, egal wie vertrauenswürdig der Entwickler im Gespräch wirkt.

Kennen Sie die Kündigungsfrist, bevor Sie sie brauchen

Fragen Sie, wie viel Vorlaufzeit der Vertragsentwickler gibt, falls er das Engagement vorzeitig beenden muss, sei es wegen einer anderen Stelle, Krankheit oder weil das Projekt sich einfach nicht als passend herausstellt. Eine Kündigungsfrist von ein bis zwei Wochen gibt Ihnen Raum, eine Übergabe zu organisieren oder Ersatz zu finden. Keine Kündigungsfrist bedeutet, dass Sie Ihren einzigen Entwickler an einem kritischen System ohne Vorwarnung verlieren könnten, zum ungünstigsten Zeitpunkt.

Diese Frage kann sich im Interview unangenehm anfühlen, aber ein Entwickler, der diese Art von Arbeit schon gemacht hat, wird davon nicht überrascht sein. Eine klare, konkrete Antwort ist selbst ein gutes Signal, dass Sie es mit jemandem Professionellem zu tun haben.

Richten Sie Reporting ein, bevor die erste Woche endet

Ein temporärer Entwickler, der an einer geschäftskritischen Anwendung arbeitet, sollte keine Blackbox sein. Vereinbaren Sie vorab, wie oft Fortschritt berichtet wird, was dieser Bericht enthält und wer die Änderungen überprüft, bevor sie Ihr Live-System erreichen. Eine wöchentliche Zusammenfassung dessen, was erledigt wurde, was als nächstes geplant ist und welche Risiken aufgefallen sind, ist für die meisten Engagements ein vernünftiges Minimum. Bei allem, was Zahlungen, Kundendaten oder Kerngeschäftslogik betrifft, sollte eine Überprüfung des Codes durch jemand anderen als den Vertragsentwickler keine Option sein, sondern Pflicht.

Unternehmer, die diesen Schritt überspringen, erfahren oft erst nach Projektende, wie es tatsächlich gelaufen ist, was zu spät ist, um ein Problem zu erkennen, als es noch klein war. Es hilft auch, vor Vertragsbeginn zu fragen, was passiert, wenn das Engagement vorzeitig endet: Erhalten Sie eine Dokumentation, was geändert wurde und warum, oder fängt die nächste Person, die den Code berührt, bei null an?

Wo diese Checkliste in eine größere Einstellungsentscheidung passt

Diese sechs Prüfungen (Stack-Erfahrung, Referenzen aus Produktionsarbeit, Versicherung, ein NDA mit klarem Code-Eigentum, eine bekannte Kündigungsfrist und ein Reporting-Rhythmus) beseitigen nicht jedes Risiko, einen temporären Webentwickler auf ein System zu lassen, auf das sich Ihr Unternehmen verlässt. Sie fangen aber die Fehler ab, die am häufigsten vorkommen: eine Fehlpassung zwischen dem Hintergrund des Entwicklers und Ihrem tatsächlichen System, keinen finanziellen Schutz, falls etwas schiefgeht, unklares Eigentum an dem Code, für den Sie bezahlt haben, und keine Transparenz darüber, was Woche für Woche tatsächlich passiert.

Wenn Sie weiter vorne im Prozess stehen und noch Entwicklungspartner vergleichen statt eines einzelnen Vertragsentwicklers, behandelt unser Beitrag zu den Fragen, die echte Qualität bei der Wahl eines Softwareentwicklungsunternehmens in Deutschland offenbaren ein verwandtes, aber breiteres Set an Fragen, die sich vor einer Entscheidung lohnen.

Wenn Sie einen temporären Webentwickler für eine geschäftskritische Anwendung brauchen und eine zweite Meinung zu Umfang, Risiko oder der Struktur des Engagements möchten, spricht unser Team für Webanwendungsentwicklung gerne mit Ihnen darüber. Erreichen Sie uns unter hello@wolf-tech.io oder finden Sie mehr Details auf wolf-tech.io, und wir sagen Ihnen offen, ob eine temporäre Einstellung der richtige Schritt ist oder ob es einen einfacheren Weg gibt.