Vorgehen
Wie ein Projekt bei mir konkret abläuft, von der ersten Nachricht bis zur laufenden Lösung. Ohne Buzzwords, ohne Foliensalat.
Der Grundgedanke
Ich arbeite nach einem simplen Prinzip: du sollst zu jedem Zeitpunkt wissen, was passiert, was es kostet und was du am Ende bekommst. Keine Überraschungen, kein Small Print, keine Sachen, die “im Kleingedruckten noch extra” verrechnet werden.
Das klingt banal. In der Softwareentwicklung ist es leider eher die Ausnahme. Ich habe in den letzten Jahren genug Projekte gesehen, bei denen der Kunde nach sechs Monaten nicht mehr wusste, wofür er eigentlich wieviel bezahlt. Dagegen kann man etwas tun: transparent arbeiten und in kleinen, überschaubaren Schritten liefern.
Schritt 1, Erstkontakt
Du schreibst mir eine kurze Nachricht über das Kontaktformular oder per Mail. Idealerweise mit drei Informationen:
- Was ist das Problem? In deinen Worten. Nicht “wir brauchen eine Schnittstelle”, sondern “wir tippen jeden Tag 40 Bestellungen aus der Mail manuell ins Abacus, weil der Shop es nicht kann”.
- Welche Systeme sind im Spiel? Namen, Versionen, wer es betreibt.
- Was ist dir wichtig? Schnelligkeit, tiefes Budget, maximale Stabilität, einfache Wartung, Datenschutz-Konformität, alles legitime Prioritäten, aber sie führen zu unterschiedlichen Lösungen.
Ich melde mich innert 24 Stunden, meist schneller.
Schritt 2, Erstgespräch (30 bis 60 Minuten, kostenlos)
Wir telefonieren oder treffen uns. Ich höre zu, frage nach, und du kriegst am Ende des Gesprächs eine ehrliche Einschätzung:
- Ja, ich kann dir helfen. Dann sagt mir der Rahmen (Wochen, nicht Monate) und wir vereinbaren die nächste Stufe.
- Ja, aber das ist ein grösseres Projekt. Dann skizziere ich dir die wahrscheinlichen Phasen und ein grobes Budget.
- Nein, das ist nichts für mich. Dann sage ich dir, warum, und empfehle dir, wenn ich jemanden kenne, einen anderen Dienstleister.
Der letzte Punkt ist wichtig: ich nehme nicht jedes Projekt an, auch wenn ich Zeit hätte. Wenn ich spüre, dass meine Erfahrung für dich nicht passt, sage ich das lieber früh. Das ist besser für dich, und ich habe keine schlechten Nächte.
Schritt 3, Konzept und Fixpreis-Angebot
Wenn wir weitermachen, schreibe ich dir ein Konzept. Nicht 50 Seiten, sondern so ausführlich wie nötig:
- Ausgangslage. Was du heute hast und was nicht funktioniert.
- Zielbild. Wie es nach dem Projekt ausschauen soll, in klaren Worten.
- Lösungsweg. Welche Komponenten gebaut werden, welche Schnittstellen angesprochen werden, welche Technologien ich einsetze und warum.
- Meilensteine. In welchen Etappen die Lösung wächst und was du nach jedem Meilenstein in der Hand hast.
- Fixpreis pro Meilenstein. Kein Zeitbudget, das sich auflöst, sondern klare Beträge pro Teilergebnis.
- Was nicht enthalten ist. Oft wichtiger als das, was enthalten ist. Hier stehen die Annahmen, die Schnittstellen, die deine Mitwirkung voraussetzen, die Lizenzkosten, die nicht in meinem Angebot sind.
Dieses Dokument ist deine Grundlage für die Entscheidung. Wenn du es unterschreibst, haben wir einen Vertrag. Wenn nicht, ist das auch ok, du hast ein klares Dokument für den nächsten Dienstleister, falls du einen vergleichen willst.
Schritt 4, Umsetzung in kleinen Etappen
Ich bin kein Freund von Monolithen. Jedes Projekt wird in Teilstücken gebaut, die einzeln abgenommen werden können. Ein typischer Rhythmus:
- Woche 1, Setup. Entwicklungsumgebung, Zugriffe, Grundgerüst. Meistens noch nichts, was du sehen kannst, aber das Fundament wird gelegt.
- Wochen 2 bis 4, Kernfunktion. Das Hauptfeature wird gebaut. Nach dieser Phase hast du einen ersten lauffähigen Stand, den du in einer Testumgebung ausprobieren kannst.
- Danach, Ausbau und Veredelung. Rand-Features, Fehlerbehandlung, Dokumentation, Feinschliff.
Nach jedem Etappenziel gibt es eine kurze Demo (live oder per Video) und eine Abnahme. Wenn wir feststellen, dass eine Annahme falsch war, können wir jetzt gegensteuern, bevor sich der Fehler durch den Rest der Arbeit zieht. Das ist der Hauptgrund für das stückweise Vorgehen: Kurskorrekturen sind billig, solange sie früh passieren.
Schritt 5, Abnahme und Übergabe
Wenn die Lösung steht, bekommst du ein Paket:
- Lauffähiges System auf deiner Infrastruktur (oder auf einer von mir, wenn wir das vereinbart haben)
- Quellcode in einem Git-Repository, zu dem du vollen Zugriff hast. Dein Eigentum.
- Dokumentation in zwei Varianten: eine kurze für Nutzer (was tue ich wann), eine technische für IT (Architektur, Deployment, Datenmodell, bekannte Eigenheiten).
- Eine Schulung für die Leute, die das System benutzen werden. Live, nicht nur schriftlich.
- Eine Liste der verwendeten Drittsoftware mit Lizenzart und Kostenrelevanz.
- Eine Schlussrechnung, die dem Angebot entspricht. Keine “aufgetauchten Zusatzaufwände”.
Ab diesem Moment gehört dir alles, und du kannst mit der Lösung weiterarbeiten, mit mir, mit einem anderen Dienstleister, oder mit jemandem aus deinem eigenen Team.
Schritt 6, Laufender Betrieb (optional)
Wenn du willst, bleibe ich dran. Drei Varianten, je nach Bedarf:
- Auf Zuruf. Du meldest dich, wenn etwas ist. Ich verrechne die geleistete Arbeit nach Aufwand. Für kleinere Änderungen und Support-Fälle ideal.
- Schlanker Wartungsvertrag. Ein fester Monatsbeitrag deckt Monitoring, Security-Updates und eine definierte Anzahl Stunden für Anpassungen ab. Kein Knebel, monatlich kündbar.
- Weiterentwicklungs-Projekt. Wenn sich herausstellt, dass ein zweiter oder dritter Ausbauschritt sinnvoll wird, gehen wir wieder in ein Projekt nach demselben Schema wie oben.
Ich mag es, wenn Kunden mich nach dem Projekt einfach kontaktieren können, ohne dass gleich ein Vertrag dahinter stehen muss. Die meisten tun das nicht oft, aber wenn, dann ist es gut zu wissen, dass jemand antwortet.
Was ich nicht mache
- Keine Projekte, bei denen ich nicht verstehe, worum es geht. Wenn dein Anwendungsfeld so speziell ist, dass ich die Fachlichkeit nicht packe, sage ich das. Halbverstandene Software hilft niemandem.
- Keine Abhängigkeit von mir. Du musst nach dem Projekt nicht bei mir bleiben. Alles, was ich baue, wird so dokumentiert und so gebaut, dass auch jemand anderes damit weiterarbeiten kann.
- Kein Code ohne Tests an kritischen Stellen. An den Stellen, an denen ein Fehler weh tut (Buchhaltung, Zahlungsverkehr, Datenübertragung), gibt es automatische Tests, die laufen, bevor eine Änderung produktiv geht.
- Keine Versprechen, die ich nicht halten kann. Wenn ich einen Termin nicht schaffe, sage ich es vorher, nicht nachher.