Ein-Mann-Projekt für Auftraggeber: Was beachten?

[Tubos]

Zitat:

Jedenfalls kann ich das folgende Buch wärmstens empfehlen! Denn das Teil hat den Vorteil, dass es sich nich nur auf große Projekte bezieht sondern explizit auch Ratschläge enthält, wie man das Ganze in kleinen bzw. auch Ein-Mann-Projekten sinnvoll (!) umsetzen kann

Klingt interessant.

Zitat:

Zum Thema... Ich weiss nicht, wie gut Du deinen Auftraggeber kennst. Ist es eine Vertrauensperson, hast Du im Prinzip nicht viel zu befürchten. Wenn nicht, wirst Du mit Lasten- und Pflichtenheften auch nicht genug auskennen, um Dich damit auf rechtlicher Ebene genügend abzudecken.

Ich kenne ihn überhaupt nicht.
Natürlich weiß ich um welche Firma es handelt, aber ich habe bisher nur übers Internet kommuniziert.

Zitat:

Lass das ganze Projekt erst mal auf dich niederprasseln. Das wird schon klappen

Das halte ich für keine gute Idee, da der Umfang von dem Ganzen nicht zu unterschätzen ist.

Zitat:

Falls du aber einen 3 - oder höher - stelligen Betrag für das Programm bekommst würde ich das vertraglich absichern und dann kommst du wohl über eine Gewerbeanmeldung nicht herum.

Ja, darauf wird es hinauslaufen.

Zitat:

Ich würde erstmal das Erstellen des Pflichtenheftes als ein eigenes kleines Projekt aufziehen und Pauschal abrechnen.

Gute Idee.

Zitat:

Gerade am Anfang bei den ersten Projekten wirst Du schnell feststellen, dass sich das geplante so nicht umsetzen lässt. Wenn Du parallel zur Planung schon Code produzierst kannst Du noch in der Planungsphase Dein Modell anpassen wenn der Prototyp schon Probleme aufwirft.

Klingt sinnvoll.

Zitat:

Wer gibt denn einen Schüler, der so was noch nie gemacht hat, denn ein dermaßen aufwendiges und "großes" Projekt?

Es handelt sich um eine kleine, dem Anschein nach seriöse Firma.
Wenn ich deine Frage als "Warum" umdeute: ich weiß es nicht.

[H4ndy]

Hi!

Ich stehe natürlich hinter dir, aber ich hoffe, dass du nicht nur
die in deinem Profil angegebene "Delphi 7 Personal" hast,
sondern zumindest irgendeine Professional-Version.

IMHO kann man mit der Personal nicht kommerziell arbeiten.

[Tubos]

Die Software wird nicht in Delphi geschrieben sein.

Warum ich deswegen in der DP frage: weil die Programmiersprache in diesem Thread keine Rolle spielt und weil ich weiß dass es einige hier gibt die beruflich programmieren.

[H4ndy]

Zitat von Tubos:

Die Software wird nicht in Delphi geschrieben sein.

OK, dann hab ich nix gesagt

Noch viel Erfolg!

[Der_Unwissende]

Hi.
Das imho Wichtigste, was hoffentlich in jedem Buch und Tutorial über Projektmanagment drin steht, ist es den Auftraggeber mit in die Verantwortung zu ziehen. Ich würde dir raten dir die Agilen Softwareprozesse genauer an zu schauen. Ich meine hier nicht eXtreme Programming, sondern vielmehr Scrum.
Für ein Einmannprojekt gilt natürlich nicht alles was für größere Projekte gilt. Aber die agilen Software Prozesse heißen ja nicht umsonst agil.
Nach einer Studie (hab nicht zur Hand welche), scheitern immer noch die meisten Projekte an den unterschiedlichen Vorstellungen zwischen Auftraggeber und Entwickler. Dass du schon Meilensteine eingeplant hast ist gut, aber wähle nicht zu wenige. Es ist natürlich ein "wenig" overhead (jeder Meilenstein kostet Vorbereitungszeit und muss präsentiert werden). Aber viel wichtiger ist, du bekommst Rückmeldung. Und genau diese solltest du dir zusichern lassen. Verpflichte deinen Kunden zur Abnahme von kleinen Meilensteinen, in denen er seine Prioritäten anpassen darf.

So funktioniert Scrum (und das recht gut). Ist eine Technik, die in anderen Industriezweigen schon ein paar Jahrzehnte mehr auf dem Buckel hat und einfach gut funktioniert.
Du erstellst einfach eine Liste von allen Punkten, die realisiert werden sollen (genauer gesagt erstellen Du + Kunde die Liste). Jede Funktion bekommt dann noch eine Priorität. Die legt der Kunde fest. Er sagt einfach wie wichtig ihm welche Funktion ist. Fakt ist, dass in sehr vielen Programmen nur 20% der Funktionalität zu 80% der Zeit benutzt werden. Sind diese 20% sehr gut (perfekt wird es nie geben) implementiert, wird der Kunde dein Projekt eher abnehmen, als umgekehrt.
Nun geht man beim Scrum ein wenig Bottom-Up vor. Du beginnst die wichtigste Grundfunktionalität zu implementieren. Wirklich nur dass was für eine erste Präsentation nötig ist. Schon hier kannst du den ersten Meilenstein ansetzen.
Ein Meilenstein besteht immer aus der Präsentation vor dem Kunden. Dieser hat die Pflicht den Meilenstein zu beurteilen. Er sagt dabei klar was ihm nicht gefällt, aber eben so wichtig (und motivierend) was ihm gefällt. Nach der Präsentation wird dann die Liste der abzuarbeitenden Punkte erneut durchgegangen und geschaut, ob neue Punkte hinzu kommen, bestehende entfernt werden oder Prioritäten sich ändern.
Abgearbeitet wird die Liste immer nach Priorität, es wird nie eine leichte (aber super unwichtige) Aufgabe vorgezogen.
In kurzen Abständen (max. 1 Monat, häufig 14 täglich) wird in der Regel der nächste Meilenstein auf die gleiche Art präsentiert. Ja, dass ist auch schon alles.

Klingt sicherlich etwas komisch/ungewohnt/umständlich, hat aber wirklich viele Vorteile. Dass was die Agilität hier ausmacht sind die kurzen Iterationen. Nach jeder Präsentation kann die Liste der Funktionen geändert werden. Was man auch nicht vergessen darf, es kann auch sehr einfach eine Einigung geben (dass das Projekt eingestellt wird). Das ist überhaupt nicht schlecht. Arbeitet man 2 Jahre an einem Projekt, dass dann zwar super seine Funktionalität erfüllt, dies sogar Verifiziert wurde, nur überhaupt nicht dem Kundenwunsch entspricht (falsche Spezifikation), so waren 2 Jahre für den ... .
Dann steckt also eine Menge Arbeit von einem drin (die man gerne bezahlt hätte), der Kunde hat aber keinen Nutzen davon (will also eher nicht zahlen). Nun ja, gerade als Schüler dürfte der Kunde dort eine bessere Position haben.
Geht bei einem Scrum (oder ähnlicher Technik) etwas schief, so verliert man i.d.R. nur eine Iteration (max 1 Monat). Arbeitet man über mehrere Meilensteine am eigentlichen Ziel vorbei, so kann man sich auch dort leichter einigen. Und da dürfte die Firma doch kulanter sein, als wenn es sich eine Woche vor Fertigstellung herausstellt, dass man unterschiedliche Ziele hat.

Vorallem kann man auch leicht an einem Punkt sagen, dass es schon komplett dem entspricht was die Firma gerne hätte. Es gibt ein paar Punkte, die gerne gefordert werden, die auch einiges an Entwicklungszeit in Anspruch nehmen, aber eben diese nicht Wert sind (schlechter Kosten/Nutzen Faktor). Stehen auf der Liste nur noch solche Punkte, kann es schonmal sein, dass der Kunde nicht auf sie besteht und zufriedener ist, dass Zeit (ein wenig Geld) spart. Natürlich könnte dir genau dieses Geld fehlen, aber viel häufiger ist die Aufwandsabschätzung gerade bei ersten Projekten nicht ganz scharf, so dass man hier und da noch Zeit bekommt etwas anderes zu ändern.
Das Hauptproblem dass du haben wirst (imho), ist die Kommunikation mit dem Kunden. Jeder hat so seine Ausdrucksweise und häufig sind Sachen gar nicht so klar wie sie scheinen. Das ist dann auch das Problem des Pflichtenheftes, vieles ist Interpretationssache. Ein Anwalt einzubinden dürfte wohl etwas teuer sein und ob Du da schon so von profitierst ist eher fraglich. Gut für dich ist, dass du Schüler bist, da wird die Firma nicht wirklich drauf beharren können/wollen, dass es vertragliche Zusicherungen gab. Aber gerade hier zahlt es sich aus, auch ein wenig unwissender zu wirken (also ohne Anwalt würde ich einem Schüler oder Ähnlichem mehr durchgehen lassen, weil ich mich da eher in dessen lage versetzen würde).
Aber auch das variiert eher mit der Firma und deshalb wie gesagt, zeige ihnen was du machst und lass es dir beurteilen!

Ich finde es gut, dass du dich schon so früh an einem Projekt versuchst. Egal wie es läuft, die Erfahrung ist unbezahlbar. Wünsch dir viel Erfolg!

Gruß Der Unwissende

[Tubos]

Sehr interessante Ausführungen, danke dafür!

Hab nochmal gründlich darüber nachgedacht, und denke jetzt, dass das Projekt für mich nicht möglich ist.
Man müsste sich doch mehrmals mit dem Auftraggeber persönlich treffen, um die Details zu klären. Das ist hier kaum möglich.
Weiters würde das Projekt aus einigen Teilbereichen bestehen, auf denen ich noch wenig Erfahrungen habe - es ist also alles andere als Routine.
Außerdem sind die ganzen rechtlichen Sachen furchtbar kompliziert - wer ist für die Wartung des Programmes zuständig? Was wenn etwas nicht so funktioniert wie erwartet? etc...
Da ich eigentlich kaum praktische Erfahrungen im Projektmanagement habe, denke ich nicht dass das eine gute Idee ist.
edit: Ganz abgesehen davon spricht es nicht für die Professionalität / Seriosität einer Firma, wenn die jemanden danach fragen von dem sie überhaupt keine Referenzen / Homepage / etc... haben

Was meint ihr dazu?

[Phoenix]

Wieso sind Treffen denn nicht möglich? Reisekosten und Spesen müsste natürlich der Auftraggeber übernehmen.

Ich würde zumindest mal den Anfang machen. Und sei es dem Auftraggeber anbieten, das Ding für ihn zu managen. Ein Pflichtenheft erstellen kannst Du sicher - und das braucht er auf jeden Fall egal wo er sein Projekt gemacht haben will. Es ist vielleicht sogar besser, wenn jemand anderes ein Pflichtenheft entwirft als derjenige, der das dann hinterher realisieren muss.

Du kannst dann mit dem Pflichtenheft von anderen Entwicklern Angebote einholen und Deinem Auftraggeber vorlegen. So bekommt er sein System und Du hast zumindest mal im Projektgeschäft erste Erfahrungen gemacht.

[Luckie]

Also bei meinem ersten Auftrag lief das so: Es hatte sich jemand gemeldet, der eines meiner Programme für sich geändert haben wollte und er hat auch gleich geagt, dass er auch bereit wäre dafür was zu zahlen. War natürlich nicht möglich, da er was ganz anderes wollte im Endeffekt. Ich habe ihm dann schnell mal eine Demo gemacht und gesagt, er solle mir das zahlen, was es ihm wert sei. Ich hatte so mit 20 Euro gerechnet. Letztendlich wollte er mir 150 Euro zahlen inklusive Quellcode. OK, da sage ich natürlich nicht nein und habe es noch etwas verbessert und optimiert. Das war dann mein erster Auftrag. Mit der Zeit habe ich für den dann noch ein paar Programme geschrieben, lief alles ähnlich: Er hat mit grob gesagt, was er wollte, ich habe ihm meinen Stundenlohn jeweils geannt, habe ich vom Aufwand und der Komplexibilität abhängig gemacht, dann habe ich ihm eine erste Version gemacht (Was ich mir natürlich auch habe bezahlen lassen.), dann hat er mir gesagt, was er gerne anders hätte und dann habe ich es ihm fertig gemacht. Wenn das Geld dann auf meinem Konto war, gab es dann noch den Quellcode. Das lief alles per Mail bzw. per Telefon, aber das eher selten. Ein Treffen wäre auch etwas schlecht gewesen, da er in Österreich wohnt. OK, das mag jetzt nicht die Regeln sein und ich habe wohl Glück, dass es ein sehr angenehmer und umgänglicher Kunde ist. Mit der Zeit wurden dann die Aufträge auch größer bishin in den mittleren dreistelligen Bereich bzw. alte Programme von mir für ihn wurden weiterentwickelt und verbessert usw. Einmal hat er mir sogar eine dreistelligen Summe als Vorschuss bezahlt, aber aus dem Programm wurde nichts und ich durfte das Geld behalten, so als Dankeschön für die bisherige gute Zusammenarbeit. Und jetzt Weihnachten gab es ca 100 Euro Weihgnachtsgeld, anders kann ich es mir nicht erklären, als ich das geld auf meinem Konto gesehen habe. Auf eine Mail von mir hatte er irgendwie nicht antworten können. Nun ja.

[ibp]

Zitat von Luckie:

Letztendlich wollte er mir 150 Euro zahlen inklusive Quellcode. OK, da sage ich natürlich nicht nein und habe es noch etwas verbessert und optimiert. Das war dann mein erster Auftrag.

...war der aufwand denn die 150 Euro wert? oder was war dein letztendlicher stundenlohn? für diesen einstieg und wie sieht es denn jetzt aus?

[Luckie]

Für inklusive dem Quellcode ja. Und jetzt mache ich bei ihm Stundenlöhne zwischen 25 und 40 Euro, je nach dem. Aber wie gesagt, bei Stammkunden nehme ich das nicht so genmau und lasse schon mal fünfe gerade sein.