Eine Checkliste, bevor du einen Entwickler für dein Projekt engagierst
Den richtigen Entwickler einzustellen beginnt lange vor dem ersten Gespräch — mit Vorbereitung, die dieses Gespräch tatsächlich produktiv macht.
Bevor du mit irgendjemandem sprichst: kläre das Problem, nicht die Lösung
"Ich brauche eine App, die X macht" ist eine Lösung, keine Problembeschreibung. "Mein Team macht X aktuell manuell, es dauert N Stunden pro Woche und verursacht Y Fehler" ist eine Problembeschreibung — und sie erlaubt einem guten Entwickler, die richtige Lösung vorzuschlagen, die vielleicht nicht das ist, was du dir ursprünglich vorgestellt hast.
Was tatsächlich vorzubereiten ist
- Der echte Arbeitsablauf, in einfacher Sprache — geh Schritt für Schritt durch, was heute passiert, auch wenn es manuell oder unordentlich ist. Das ist für einen Entwickler nützlicher als eine polierte Feature-Liste.
- Deine tatsächlichen Einschränkungen — Budgetrahmen, Zeitplan, und alle nicht verhandelbaren technischen Anforderungen (muss sich in ein bestehendes System integrieren, muss auf einer bestimmten Plattform laufen).
- Wie "fertig" für eine erste Version aussieht — nicht die vollständige Vision, sondern die kleinste Version, die wirklich nützlich ist.
- Wer die endgültige Entscheidungsbefugnis hat — ein ins Stocken geratenes Projekt geht oft auf unklare Freigabeprozesse auf Kundenseite zurück, nicht auf die Entwicklung selbst.
Fragen, die es wert sind, einem potenziellen Entwickler gestellt zu werden
- Wie gehst du mit Umfangsänderungen mitten im Projekt um? (Es sollte eine klare Antwort geben, keine Vagheit.)
- Kann ich Beispiele ähnlicher Arbeiten sehen, und kann ich mit einem früheren Kunden sprechen?
- Wie sieht dein Kommunikationsrhythmus während des Projekts aus?
- Was passiert nach dem Launch — gibt es einen Wartungsplan, oder ist das separat?
Warnsignale, die ernst zu nehmen sind
Ein Entwickler, der allem zustimmt, ohne klärende Fragen zu stellen oder je zurückzufragen, ist ein Warnsignal, keine Beruhigung — ein guter Entwickler wird unklare Anforderungen hinterfragen und dir manchmal sagen, dass ein gewünschtes Feature eine schlechte Idee ist, bevor du dafür bezahlt hast.
- Keine Fragen zu deinen tatsächlichen Nutzern oder Arbeitsabläufen, bevor ein Preis genannt wird.
- Zurückhaltung, darüber zu sprechen, was passiert, wenn sich der Umfang ändern muss.
- Keine Bereitschaft, frühere Arbeiten oder Referenzen zu teilen.
Eine einfache Checkliste vor der Einstellung
| Punkt | Warum es wichtig ist |
|---|---|
| Klare Problembeschreibung (nicht nur eine Feature-Wunschliste) | Erlaubt dem Entwickler, die richtige Lösung vorzuschlagen |
| Realistischer Budget-/Zeitrahmen von Anfang an geteilt | Vermeidet verschwendete Zeit bei einer unpassenden Zusammenarbeit |
| Ein definiertes "fertig" für Version eins | Verhindert, dass sich der Umfang stillschweigend ausweitet |
| Klarheit darüber, wer Entscheidungen freigibt | Vermeidet Stillstand durch unklaren internen Prozess |
Bereitest du dich auf eine Einstellung vor und willst eine zweite Meinung zu deinem Umfang oder dem Vorschlag eines potenziellen Entwicklers, bevor du dich festlegst? Melde dich.
Häufige Fragen
Brauche ich eine vollständige Spezifikation, bevor ich mit einem Entwickler spreche?
Nein — ein guter Entwickler hilft dir, den Umfang zu klären, und eine zu starre Spezifikation ohne technischen Input kann schlechte Annahmen festschreiben. Du brauchst ein klares Verständnis des tatsächlichen Problems, das du lösen willst, was etwas anderes ist als eine detaillierte technische Spezifikation.
Sollte ich einen Festpreis oder einen Stundensatz anfragen?
Hängt davon ab, wie gut definiert der Umfang ist — Festpreis funktioniert gut für klar abgegrenzte Arbeit, Stundensatz (oder ein phasenweiser Ansatz) funktioniert besser für wirklich explorative Arbeit, bei der sich der Umfang ändern kann, während man mehr lernt.
Was ist ein Warnsignal im Gespräch mit einem potenziellen Entwickler?
Jemand, der jeder Anfrage zustimmt, ohne je zurückzufragen oder klärende Fragen zu stellen — ein guter Entwickler fragt nach Grenzfällen, hinterfragt unklare Anforderungen und sagt dir manchmal, dass ein gewünschtes Feature eine schlechte Idee ist. Unkritische Zustimmung ist ein Warnsignal, kein guter Service.