Ein neuer Entwickler kann Ihre Software möglicherweise fertigstellen, wenn er prüfen kann, was bereits funktioniert, die nötigen Zugriffsrechte erhält und einen gangbaren Weg für einen wichtigen fehlenden Schritt aufzeigt. Beauftragen Sie zuerst eine kurze Prüfung. Eine Oberfläche kann fertig aussehen und trotzdem kein Ergebnis speichern. In einer Kopie des Codes können Anleitungen oder Dienste fehlen, die zum Start nötig sind.
Wenn Menschen eine laufende Version bereits nutzen, vereinbaren Sie, wer sie während der Prüfung in Betrieb hält. Sie können die Betreuung dieser Version jetzt regeln und über einen Ersatz später entscheiden.
Was können Sie einem neuen Entwickler übergeben?
Bitten Sie um den zuletzt verwendeten oder getesteten Stand des Quellcodes, eine Anleitung zum Erstellen der Software und die dafür nötigen Komponenten. Klären Sie, wer die Konten für die Bereitstellung und die Anbindung externer Dienste verwaltet. Finden Sie heraus, wo Geschäftsdaten und Sicherungen liegen und was Sie laut Vertrag weitergeben oder ändern dürfen. Der Zugriff auf die Codeablage allein belegt diese Rechte nicht.
Prüfen Sie diese Punkte getrennt. Ein Team kann eine Kopie starten und trotzdem keinen Zugriff auf die laufende Version haben, um sie zu aktualisieren. Oder es kann das Hosting-Konto nutzen, aber mit den übergebenen Unterlagen die Software nicht neu erstellen. Wenn Daten umziehen müssen, testen Sie getrennt, ob das neue System einen Export tatsächlich verwenden kann.
Was soll das neue Team vorführen?
Wählen Sie einen Vorgang, der für den Betrieb wichtig ist. Stellen Sie sich eine unfertige Anwendung für die Servicekoordination vor: Ein Mitarbeiter reicht einen Antrag ein. Bislang hat niemand gezeigt, dass eine Führungskraft ihn genehmigen und die Entscheidung später wiederfinden kann. Bitten Sie das Team, eine bekannte Version zu erstellen und den Ablauf in einer getrennten, dafür freigegebenen Umgebung zu testen. Verwenden Sie erfundene Datensätze und deaktivieren Sie echte Benachrichtigungen, Zahlungen und andere Aktionen im laufenden Betrieb. Lassen Sie das Produktivsystem aus dem Test heraus.
Verfolgen Sie, wie weit der Antrag kommt, und halten Sie fest, wo es nicht weitergeht. Kann die Führungskraft ihn genehmigen, sieht die Entscheidung beim erneuten Öffnen aber nicht mehr, hat das Team einen konkreten Fehler, dem es nachgehen kann. Verhindert eine fehlende Komponente bereits den Start, vermerken Sie, dass der Ablauf noch nicht vorgeführt werden konnte, und nennen Sie den fehlenden Teil. Daraus folgt ein anderer nächster Schritt als aus einem nachgewiesenen Fehler bei der Genehmigung.
Ein erfolgreicher Build zeigt, dass das Team diese Version unter den Testbedingungen erstellen konnte. Er belegt weder die Sicherheit oder Wartbarkeit des ganzen Systems noch das Recht zur Bereitstellung oder die Eignung für den Produktivbetrieb. Googles Beschreibung der Übergabe von Betriebsverantwortung verdeutlicht diese separate Entscheidung: Dort prüft man Abhängigkeiten und Betriebsbereitschaft und sieht bei Bedarf Verbesserungen und Schulung vor.
Sollten Sie die Software weiterentwickeln, einen Teil reparieren oder sie ersetzen?
Vergleichen Sie die Optionen anhand desselben Arbeitsablaufs und des Aufwands für dessen spätere Betreuung. Die Beschaffungsleitlinien der britischen Regierung zeigen beispielhaft, wie man eine Anpassung und eine Neuentwicklung nach Bedarf, Kosten und Fähigkeit zum späteren Betrieb beurteilt.
Weiterentwickeln
Das Team kann eine bekannte Version erstellen. Der vorhandene Ablauf funktioniert in der Testumgebung, und der fehlende Schritt lässt sich ergänzen, ohne die Funktionsweise des übrigen Systems zu ändern.
Einen Teil reparieren
Der zentrale Ablauf ist nutzbar, aber ein Bereich wie die Bereitstellung oder eine Schnittstelle braucht eine gezielte Reparatur. Fragen Sie, wie das Team sie testet, bevor Sie den betreffenden Teil wieder einsetzen.
Ersetzen
Die Lösungen, bei denen die Software erhalten bleibt, erfüllen eine wesentliche Anforderung nicht zu vertretbaren Kosten oder Risiken. Planen Sie vor dem Wechsel, wie Daten und laufende Vorgänge übernommen werden.
Scheint ein Ersatz sinnvoll, entscheiden Sie gesondert, wie laufende Vorgänge weitergehen. Beide Systeme eine Zeit lang parallel zu betreiben ist eine mögliche Übergangslösung. Sie bringt eigene Kosten mit sich, und jemand muss die Verantwortung für die Daten übernehmen.
Was sollte die Prüfung schriftlich festhalten?
Bitten Sie um eine kurze Übersicht, die Sie mit den Nutzern der Software durchgehen können. Sie sollte nennen, was das Team vorgeführt hat, was gescheitert ist oder sich nicht testen ließ, welche Zugriffe oder Rechte fehlen und was laufende Arbeit beeinträchtigen könnte. Legen Sie bei jeder tragfähigen Option fest, was als Nächstes passiert, wer handeln muss und was Sie vor der Freigabe weiterer Arbeit überprüfen.
Bei der Beispielanwendung könnte das Team zuerst untersuchen, warum die gespeicherte Genehmigung verschwindet, und dann zeigen, dass die Führungskraft sie im Testsystem wieder aufrufen kann. Wenn Sie Teams für diese Aufgabe vergleichen, lesen Sie, was Sie einen Entwickler für Individualsoftware vor der Auswahl fragen sollten.
Fragen zur Übernahme unfertiger Software
Reicht es, den Quellcode zu haben?
Damit hat das neue Team etwas, das es prüfen kann. Klären Sie, zu welcher Version der Code gehört und ob Sie alle nötigen Zugriffe gewähren dürfen. Lassen Sie das Team die Version erstellen und einen wichtigen Arbeitsablauf außerhalb des laufenden Betriebs erproben.
Wann genügt eine gezielte Reparatur?
Wenn der Kernablauf funktioniert und das Team die Reparatur in einem Bereich eingrenzen und testen kann, kommt sie infrage. Fragen Sie, welche Probleme offenbleiben und wer die Software danach pflegen kann.
Was soll bei der Prüfung herauskommen?
Eine kurze Übersicht darüber, was im Test funktioniert hat, was ungeprüft blieb, was fehlt und was die einzelnen Optionen erfordern. Halten Sie fest, wer eine bereits genutzte Version weiterbetreibt und welchen nächsten Schritt Sie freigeben würden.
