Wie Sie als Nicht-Techniker einen Entwickler finden und richtig briefen

Einen Entwickler zu engagieren, wenn man den Code nicht selbst beurteilen kann, fühlt sich riskant an, und ehrlich gesagt ist es das auch, nur nicht so, wie die meisten denken. Sie müssen die technische Arbeit nicht verstehen, um gut auszuwählen. Sie müssen wissen, was Sie vorbereiten, welche Fragen einen guten Entwickler tatsächlich erkennen lassen und wie gesunde Kommunikation aussieht, sobald die Arbeit beginnt.

Ich habe Hunderte solcher Gespräche mit Gründern geführt, und die, die gut laufen, folgen einem Muster. So stellen Sie sich auf, damit Sie kein Glücksspiel eingehen.

Das geschäftliche Problem: Sie beurteilen etwas, das Sie nicht lesen können

Ein nicht-technischer Gründer kann keinen Pull Request prüfen und keine wackelige Architekturentscheidung erkennen. Sie müssen einen Entwickler also anhand von Ersatzmerkmalen beurteilen: wie er kommuniziert, wie er den Umfang einschätzt, wie ehrlich er mit Zielkonflikten umgeht. Die gute Nachricht: Diese Merkmale sind erstaunlich zuverlässig. Ein Entwickler, der klar kommuniziert und den Umfang sorgfältig absteckt, liefert fast immer bessere Arbeit als einer, der einfach zu allem „Ja“ sagt.

Das Risiko ist nicht, dass Sie jemanden wählen, dessen Code Sie nicht lesen können. Sondern dass Sie jemanden wählen, der Ihnen erzählt, was Sie hören wollen, zwei Wochen abtaucht und mit etwas wieder auftaucht, das am Ziel vorbeigeht.

Was Sie vorbereiten sollten, bevor Sie jemanden kontaktieren

Sie brauchen keine technische Spezifikation. Sie brauchen Klarheit über das Problem, nicht über die Lösung. Bevor Sie jemanden kontaktieren, versuchen Sie Folgendes aufzuschreiben:

• Das Problem, das Sie lösen, und für wen, in einfachen Worten.
• Das Wichtigste, was das Produkt können muss: das eine Feature, ohne das es sinnlos wäre.
• Beispiele: Apps oder Websites, die etwas Ähnliches tun, auch wenn nur entfernt.
• Ihre Rahmenbedingungen: grobes Budget, grober Zeitplan, feste Fristen.
• Wie Erfolg aussieht für eine erste Version.

Das muss nicht ausgefeilt sein. Eine klare halbe Seite über das Problem ist mehr wert als eine vage Wunschliste mit fünfzig Features, und sie hilft einem guten Entwickler, die Arbeit ehrlich einzuschätzen. (Wenn Sie noch in der Ideenphase sind, ist wie man ein MVP definiert eine nützliche Ergänzung.)

Gute Zeichen und Warnsignale

Nach genügend Projekten lassen sich die Signale leicht lesen.

Gute Zeichen:

• Sie stellen Fragen, bevor sie ein Angebot machen, besonders zum Problem und nicht nur zu den Features.
• Sie hinterfragen den Umfang und schlagen vor, was für eine erste Version wegfallen kann.
• Sie erklären Zielkonflikte in einfachen Worten, statt sich hinter Fachjargon zu verstecken.
• Sie nennen Ihnen ehrliche Zeitpläne, inklusive dessen, was unsicher ist.

Warnsignale:

• Sie sagen zu allem Ja und nennen sofort einen Preis, ohne Fragen zu stellen.
• Sie können ihren Plan nicht ohne Fachjargon erklären, oder wollen es nicht.
• Sie sind lange Zeit nicht erreichbar und tauchen mit Überraschungen wieder auf.
• Der Preis wirkt zu gut, um wahr zu sein, was meist bedeutet, dass Sie doppelt zahlen.

Wie gute Kommunikation aussieht, sobald die Arbeit beginnt

Der beste Indikator für ein gelingendes Projekt ist nicht reines Können, sondern Kommunikation. Was Sie sehen wollen, ist ein stetiger Rhythmus: regelmäßige Updates, ehrlicher Fortschritt (auch was langsamer läuft als erwartet), kleine, überprüfbare Arbeitspakete statt einer großen Enthüllung am Ende und ein echtes Gespräch, wenn eine Entscheidung ansteht.

Genau so versuche ich zu arbeiten: klare wöchentliche Updates, Hindernisse am selben Tag melden, an dem ich sie sehe, und Zielkonflikte offen benennen, statt sie zu verstecken. Mehr dazu lesen Sie darüber, wie ich mit Kunden arbeite. Entscheidend ist, dass Sie als nicht-technischer Gründer das beurteilen können. Sie müssen keinen Code lesen, um zu erkennen, ob jemand Sie auf dem Laufenden hält und ehrlich zu Ihnen ist.

Ein realistisches Beispiel

Viele meiner Aufträge kommen von Gründern, die eine holprige erste Erfahrung hinter sich hatten: ein Entwickler, der verschwunden ist, oder eine Entwicklung, die sich von dem entfernt hat, was sie tatsächlich brauchten. Die Lösung ist selten mehr technische Brillanz, sondern engere Kommunikation und ehrliche Umfangsplanung. Wenn die Zusammenarbeit zwischen Gründern und mir gut funktioniert, dann deshalb, weil wir uns zuerst auf das Kernproblem geeinigt, die Feedbackschleife kurz gehalten und Entscheidungen offen getroffen haben, statt zu hoffen. Das ist der Teil, den Sie vollständig in der Hand haben, ob technisch oder nicht.

Typische Fehler nicht-technischer Gründer

• Features briefen statt des Problems, sodass der Entwickler auf das Falsche optimiert.
• Nur nach Preis auswählen und doppelt zahlen, wenn die billige Arbeit neu gemacht werden muss.
• Die Fragen auslassen, weil sie sich zu technisch anfühlen, obwohl Kommunikation genau das ist, was Sie beurteilen können.
• Eine große Enthüllung am Ende akzeptieren statt kleiner, regelmäßiger Fortschritte, auf die Sie reagieren können.
• Selbstsicherheit mit Kompetenz verwechseln: Wer Ihren Umfang hinterfragt, dient Ihnen oft besser als jemand, der allem zustimmt.

Wie ich mit nicht-technischen Gründern arbeite

1. Mit dem Problem beginnen, nicht mit einer Feature-Liste, und die wichtigen Fragen früh stellen.
2. Den Umfang ehrlich einschätzen, inklusive dessen, was für eine schlankere, schnellere erste Version wegfallen kann.
3. In einfachen Worten kommunizieren: Zielkonflikte und Fortschritt, keine Wände aus Fachjargon.
4. Die Schleife kurz halten mit regelmäßigen Updates und kleinen, überprüfbaren Arbeitspaketen.
5. Hindernisse sofort melden, damit es am Projektende keine Überraschungen gibt.

Sie sollten nicht technisch werden müssen, um gute Software bauen zu lassen. Sie sollten der Person vertrauen können, die sie baut, und dieses Vertrauen können Sie sehr wohl beurteilen.

Sie suchen einen Entwickler, mit dem Sie wirklich kommunizieren können?

Wenn Sie als nicht-technischer Gründer jemanden suchen, der Ihr Projekt wie sein eigenes behandelt (klare Updates, ehrliche Zielkonflikte, kein spurloses Verschwinden), dann ist das genau meine Arbeitsweise.

Lesen Sie ein wenig darüber, wie ich arbeite, sehen Sie sich an, was ich gebaut habe, und nehmen Sie Kontakt auf, um mir von Ihrem Projekt zu erzählen. Ich stelle die richtigen Fragen, bevor wir loslegen.