Sie haben sich auf den Umfang geeinigt, den Vertrag unterschrieben, und das Entwicklungsteam hat mit der Arbeit begonnen. Zu diesem Zeitpunkt fragen sich viele Unternehmer etwas, womit sie nicht gerechnet haben: Was soll ich jetzt eigentlich tun?
Manche Kunden ziehen sich völlig zurück — vertrauen dem Team vollständig, nur um Wochen später aufzutauchen und festzustellen, dass das Projekt vom Kurs abgekommen ist. Andere tun das Gegenteil: Sie schicken täglich Nachrichten, hinterfragen jede Designentscheidung und führen mitten im Sprint neue Anforderungen ein. Keiner der beiden Ansätze funktioniert.
Es gibt einen mittleren Weg — und es lohnt sich, ihn zu kennen, bevor die Entwicklung beginnt, nicht erst wenn die erste Reibung entsteht.
Warum Ihre Beteiligung wichtiger ist als Sie denken
Softwareentwicklungsunternehmen sind Experten für das Entwickeln von Software. Sie sind keine Experten für Ihr Unternehmen. Die Lücke zwischen diesen beiden Dingen ist der Ort, an dem die meisten Projekte in Schwierigkeiten geraten.
Ihre Entwickler können Code schreiben, der technisch einwandfrei funktioniert, und trotzdem etwas bauen, das das falsche Problem löst — wenn niemand mit Fachkenntnissen aktiv die Entscheidungen lenkt. Diese Person sind Sie. Sie können diese Verantwortung nicht delegieren, denn das Domänenwissen liegt bei Ihnen.
Das bedeutet nicht, dass Sie eine technische Person sein müssen. Es bedeutet, dass Sie ein verfügbarer, informierter und entscheidungsfreudiger Geschäftspartner während des gesamten Projekts sein müssen.
Entscheidungen, die nur Sie treffen können
Manche Entscheidungen sehen technisch aus, sind aber im Kern Fragen Ihres Unternehmens. Hier ist Ihr Beitrag gefragt, nicht das Urteil des Entwicklers.
Priorität. Wenn der Umfang angepasst werden muss — weil etwas länger gedauert hat als erwartet oder eine neue Anforderung auftaucht — muss jemand entscheiden, was am wichtigsten ist. Das ist eine unternehmerische Entscheidung, keine technische. Wenn Ihr Entwicklungsteam nach Prioritätsführung fragt und keine erhält, wird das Projekt entweder stagnieren oder auf Annahmen fortschreiten, mit denen Sie möglicherweise nicht einverstanden sind.
Geschäftslogik. Wie funktioniert Ihre Preisgestaltung? Was sind die Ausnahmen von Ihrem Standardprozess? Wann wird ein Kunde für die manuelle Überprüfung markiert? Diese Regeln leben in Ihrem Unternehmen — oft in den Köpfen der Mitarbeiter und nicht in einem Dokument. Entwicklungsteams müssen sie explizit kennen, und der einzige Weg, sie herauszuarbeiten, besteht darin, die Personen einzubeziehen, die sie kennen.
Abnahme. Wenn das Team Ihnen eine abgeschlossene Funktion zeigt, sind Sie die einzige Person, die sagen kann, ob sie tatsächlich das tut, was das Unternehmen braucht. Technische Korrektheit liegt in der Verantwortung des Teams. Fachliche Korrektheit liegt bei Ihnen. Das ist nicht dasselbe.
Risikotoleranz. In jedem Projekt gibt es Kompromisse — zwischen Geschwindigkeit und Robustheit, zwischen Funktionen und Kosten, zwischen idealer Architektur und funktionierendem Produkt. Ihr Team kann die Optionen vorstellen, aber die Entscheidung liegt bei Ihnen.
Wie Sie eingebunden bleiben, ohne die Arbeit zu verlangsamen
Effektive Kundenbeteiligung ist eine Frage von Timing und Struktur, nicht von Volumen. Ein Kunde, der reaktionsschnell und klar ist, verursacht weit weniger Verzögerungen als einer, der sich vollständig zurückzieht.
Nehmen Sie an Sprint-Reviews teil. Wenn Ihr Team in Sprints arbeitet (typischerweise Zweiwochenzyklen), gibt es regelmäßige Demonstrationen abgeschlossener Arbeit. Nehmen Sie daran teil. Das ist der schnellste Weg, um Missverständnisse früh zu erkennen — wenn sie günstig zu beheben sind — statt spät, wenn das nicht mehr der Fall ist.
Beantworten Sie Fragen schnell. Entwicklungsteams werden durch unbeantwortete Fragen blockiert. Eine Entscheidung, die eine Woche zu Ihnen unterwegs ist, kann eine Woche verlorene Zeit verursachen. Die meisten Fragen sind nicht schwierig — sie brauchen nur jemanden mit Autorität, der eine klare Antwort gibt. Eine schnelle, unvollkommene Antwort ist fast immer besser als eine langsame, perfekte.
Bestimmen Sie einen einzigen Ansprechpartner. Wenn mehrere Personen in Ihrer Organisation Meinungen zum Projekt haben — was normal und gesund ist — entscheiden Sie im Voraus, wer befugt ist, endgültige Entscheidungen zu treffen. Widersprüchliche Anweisungen von verschiedenen Stakeholdern sind eine wesentliche Quelle von Verzögerungen und Nacharbeiten.
Unterscheiden Sie Feedback von Anweisungen. Bei der Überprüfung abgeschlossener Arbeiten gibt es einen Unterschied zwischen „Ich habe ein Problem damit bemerkt" (Feedback) und „Bitte ändern Sie das so, dass es X tut" (Anweisung). Beides ist legitim, sollte aber klar kommuniziert werden, damit das Team angemessen reagieren kann.
Was Sie getrost dem Team überlassen können
Teil der optimalen Nutzung einer Entwicklungspartnerschaft ist es, dem Team bei Dingen zu vertrauen, die wirklich in dessen Kompetenzbereich liegen.
Technologiewahl. Welches Framework, welche Datenbank oder welche Deployment-Infrastruktur für Ihr System am besten geeignet ist, ist eine technische Frage. Ihr Team sollte die Begründung auf Anfrage erklären, aber Sie müssen diese Entscheidungen nicht im Detail genehmigen. Das Eingreifen in Technologiewahlen auf der Grundlage dessen, was Sie anderswo gehört haben, ist ein häufiger Weg, unbeabsichtigt Probleme einzuführen.
Wie Aufgaben aufgeteilt und sequenziert werden. Die Reihenfolge, in der Funktionen entwickelt werden, und wie die Arbeit auf Entwickler aufgeteilt wird, ist eine Frage des Projektmanagements und des Engineerings. Das Team weiß, was wovon abhängt und was am effizientesten auf dem bereits Geleisteten aufbaut.
Codequalität und Testing. Wie der Code intern strukturiert ist, wie er getestet wird und welchen Standards er folgt, liegt in der Verantwortung des Teams. Sie sollten gute Praktiken erwarten — und das Team zur Rechenschaft ziehen, wenn es Anzeichen systematischer Qualitätsprobleme gibt — aber Codes Zeile für Zeile durchzugehen ist keine sinnvolle Kundenaktivität.
Designdetails innerhalb vereinbarter Richtlinien. Wenn Sie ein Brand-Guide oder eine Designrichtung bereitgestellt haben, kann das Team Entscheidungen innerhalb dieses Rahmens treffen, ohne Ihre Genehmigung für jede kleine Auswahl zu benötigen. Übermäßige Designgenehmigungen schaffen Engpässe, ohne die Ergebnisse zu verbessern.
Die häufigsten kundenseitigen Verzögerungen
Es gibt einige wiederkehrende Muster, die Projekte von Kundenseite verlangsamen. Sie im Voraus zu kennen ist der beste Weg, sie zu vermeiden.
Nichterreichbarkeit in kritischen Entscheidungsmomenten. Manche Entscheidungen erfordern wirklich ein Meeting oder ein detailliertes Gespräch, keine schnelle Antwort. Wenn der Kunde in diesen Momenten schwer erreichbar ist, stoppt die Arbeit entweder oder schreitet auf Basis von Annahmen fort. Beide Ergebnisse sind kostspielig.
Scope-Erweiterungen während der Entwicklung. Im Laufe der Entwicklung entstehen Ideen — das ist natürlich. Der Fehler ist, sie als sofortige Ergänzungen zum aktuellen Build zu behandeln statt als Ergänzungen zu einer zukünftigen Phase. Jede Scope-Änderung mitten im Build stört die Planung des Teams und kostet normalerweise mehr als dieselbe Änderung in der nächsten Phase.
Verzögertes Abnahmetesting. Abgeschlossene Funktionen müssen zeitnah überprüft und abgenommen (oder zur Korrektur markiert) werden. Wenn das Abnahmetesting wochenlang zurückbleibt, hat das Team möglicherweise weitere Arbeit auf etwas aufgebaut, das nicht genehmigt wurde — was zu Folgefehlern führt.
Änderungen der Anforderungen nach Unterzeichnung. Das passiert häufiger als es sollte. Unterzeichnete Anforderungen werden neu bewertet, genehmigte Designs neu gestaltet, bestätigte Entscheidungen rückgängig gemacht. Jede Umkehrung hat ihren Preis. Wenn Sie bei einer Anforderung wirklich unsicher sind, lohnt es sich, diese Unsicherheit in der Discovery-Phase zu klären statt mitten im Build.
Wie gute Zusammenarbeit in der Praxis aussieht
Die Kunden, die am Ende die besten Ergebnisse erzielen, sind nicht die, die Software verstehen — es sind diejenigen, die ihr eigenes Unternehmen verstehen und bereit sind, sich während des gesamten Projekts konsequent einzubringen.
Sie nehmen an Reviews teil, geben klares Feedback, treffen in angemessener Zeit Entscheidungen und vertrauen dem Team bei technischen Entscheidungen, während sie selbst nah an den geschäftlichen Ergebnissen bleiben. Sie sagen dem Team frühzeitig, wenn sich etwas geändert hat, anstatt zu hoffen, dass es keine Rolle spielt.
Die Beziehung zwischen einem Unternehmensinhaber und einem Entwicklungsteam funktioniert wie jede gute Arbeitsbeziehung: Sie braucht klare Kommunikation, gegenseitigen Respekt vor den Domänen des jeweils anderen und genug Struktur, um alles auf Kurs zu halten.
Wenn diese Elemente vorhanden sind, verlaufen Projekte in der Regel gut. Wenn nicht, haben selbst technisch hervorragende Teams Schwierigkeiten, das zu liefern, was das Unternehmen tatsächlich braucht.
Die Beziehung von Anfang an richtig aufzubauen lohnt sich. Die Investition, die Sie in das Verständnis Ihrer Rolle stecken — und darin, sie aktiv auszufüllen — zahlt sich in einem Projekt vielfach aus, das genau dort landet, wo Sie es gebraucht haben.