Bauchschmerzen:
Hast Du einen Überblick, was Du alles kannst und was der Kunde darüber hinaus haben will?
Gibt es "dunkle" Ecken, also unbekannte/schlecht dokumentierte Schnittstellen zu Programmen oder Daten?
Arbeitest Du mit einem Framework, das Du beherrschst?
Welchen Bereich betrifft die Entwicklung? (
DB, Maschinensteuerung, Grafik, Web ..)
M.E. kannst Du ohne Feinspezifikation nur auf Stundenbasis arbeiten, die Variante "nach Aufwand plus Prämie" scheint mir wenigstens eine faire Alternative.
Probe (Wenn Du das noch nie gemacht hast):
Nimm Dir die Zeit, einen xbeliebigen Teil der zu erwartenden Anforderung und schreib die Spezifikation, Feinspezifikation für eine Maske. Schätze die Zeit, die Du benötigen wirst. Dann setz es um und überrasche Dich selbst.
Schätzungen:
Schätzungen sind beliebig schlecht, ohne entsprechende Erfahrungswerte, Werkzeugkenntnis (selbst mit offiziellen Methoden) und vor allem ohne definierten Rahmen. Hilfreich, realistisch, notwendig ist:
- Trennung von
GUI und Funktion
- Klassen von Bedienmasken (Datenmasken: Grid, Detail, Master/Detail, Reports: Grid, Detail, Master/Detail, Maschinen/Interface Calls, usw)
- Zu diesen Klassen jeweils festgelegte Standard
GUI
- bestimmte Dinge nicht zu schätzen, sondern nach Aufwand zu machen:
- Import, besonders von "weichen" Formaten und Daten, die manuell erstellt wurden (Excel, ..)
- Datenmigration
- Komfort/Luxus
- usw
Komfort/Luxus
Es gibt immer wieder den Wunsch, nach Masken, die wie ein Pilotencockpit aussehen.
Das ist toll, wenn es funktioniert. Aber es steckt dermaßen voller Fallstricke, dass man ohne Expertise zu Themen wie Eventhandling, Windows Messaging, Threading, Datenabhängigkeiten,
Gui Konzeption, Nutzerverhalten usw. meist Schiffbruch erleidet.
Solche Programmteile sollten immer der 2. Schritt nach der Standardfunktion/-Maske sein.
Umfang:
Es gibt zahllose Modelle und Beispiele aus dem echten Leben, wie man ein Projekt zum scheitern bringt (was nicht notwendiger Weise Dein Ruin sein muss, aber eine gute Voraussetzung).
Ein wichtiger Punkt (gerade für "kleine Teams">Du) sollte sein, überschaubare Teilprojekte zu definieren. Das gilt für Zeitraum, Funktionsumfang und Preis. Bei einem ordentlichen Ansatz leitet das zu klaren Abgrenzungen, Interfaces und klarer Funktionalität. Die Funktionalität ist letztlich das einzige, was den Kunden interessiert und Ihn wohl auch am ehesten bewegt, viele weitere Dinge umzusetzen.
Wenn Du es also schaffst, in kleinteiligen Projekten sauber funktionierende Programmmodule zu schaffen, die für sich genommen auch nutzbringend einzusetzen sind, ist das der beste Weg.