Freelancer ohne Ausbildung

[schöni]

Schwierig würde ich sagen. Ohne Ausbildung aussichtslos.

Ich hatte in den Achtzigern die AUfgabe erhalten, ein Wareneingangsprogramm zu scheriben, mit damals Dbas I (in der DDR Redabas I <(Re)lationales (Da)ten(ba)nk (S)ystem.

Problemstellung war:

- Erfassung Wareneingang (das geleiferte Material zur Produktion)
- Erfassung Leihgut (die Behälter, in denen geliefert wurde)

Dieses Leihgut musste innerhalb von 4 Wochen an den Lieferanten zurück geschickt werden.

Die Software sollte den Überblick über das noch im Betrieb befindliche Leihgut verbessern und nachweisen können, was bereits korrekt zurückgegeben wurde.

War für mich eine Art Bewährung die ich nicht bestanden habe, obwohl das Programm termingerecht geliefert wurde.

Mein Problem war die Kenntnis der Gesamtabläufe in der Abteilung, das Programm war dann speziell auf diese Aufgabe zugeschnitten, was nicht genug war, da es Leihgut auch in anderen Abteilungen als der Materielwirtschaft gab, für die ich das Programm geschrieben habe.

Was daraus folgend hier wichtig ist, ist der Umstand, das meine Prozesskenntnis damals nicht ausreichend war, obwohl ich das Programm innerhalb desjenigen Betriebes geschrieben habe, der es dann auch eingesetzt hat. Für mich ist somit Freelancer wohl Utopie, denn so außerhalb der Prozessabläufe dann zu sehen, welcher Ablauf modelliert werden muss, dürfte ungleich schwieriger sein, als direkt am Ort des Geschehens. Der Kunde erzählt erfahrungsgemäß nur das allernötigste und daraus ergeben sich dann ständig Änderungen und Erweiterungen, die vorher nicht so geplant waren. Pflichtenheft gab es keines dazu. Das Projekt wurde als Gerüst von einer Mitarbeiterin im Rechenzentrum entwickelt, war aber in keinster Weise praxistauglich. Ich hatte das dann mit einer Kollegin in Teamwork praxistauglich gemacht. 6 Momate Arbeit, voll ausgelastet gewesen mit der Programmierung. Keine Zeit, hinter die Gesamtabläufe zu schauen.

Aber egal, die Prozesskenntnis reichte nicht aus, um da dauerhaft bleiben zu können. Freelancer braucht wohl auch einen Instinkt für die Abläufe dahinter. Ohne diesen Instinkt -> Freelancer vergessen.

[Perlsau]

Zitat von schöni:

Mein Problem war die Kenntnis der Gesamtabläufe in der Abteilung, das Programm war dann speziell auf diese Aufgabe zugeschnitten, was nicht genug war, da es Leihgut auch in anderen Abteilungen als der Materielwirtschaft gab, für die ich das Programm geschrieben habe.

Nun sehe ich in der von dir behaupteten Unmöglichkeit, als Außenstehender alle zur Erstellung einer Software wichtigen Betriebsabläufe zu erkennen, nicht wirklich ein Hindernis im Bemühen, sich als Freelancer um Aufträge zu bemühen. Denn erstens gibt es die sog. Pflichtenhefte, in denen der Auftraggeber – nicht selten auch gemeinsam mit dem Entwickler – ganz genau spezifiziert, was die zu entwickelnde Software leisten muß. Wurden bestimmte Betriebsabläufe dabei nicht erfaßt, kann man das wohl kaum dem Programmierer anlasten. Und zweitens kann ein Auftraggeber, sobald er feststellt, beim Festhalten der Soll-Vorgaben etwas übersehen zu haben, den Auftrag jederzeit erweitern und dem Pflichtenheft gemeinsam mit dem Auftragnehmer weitere Punkte hinzufügen.

[implementation]

Was vielleicht auch noch ganz hilfreich sein könnte, wäre der Google Summer Of Code. Dieses Jahr ist es wohl zu spät zum Teilnehmen, aber dennoch kannst du mal durch die Projektvorschläge stöbern, und vielleicht einen davon umsetzen. Eigentlich alle dort teilnehmenden Projekte veröffentlichen eine Liste an Vorschlägen, die sie gern umgesetzt hätten, sowie einen möglichen Mentor.
Schau dich mal um, wenn du dort etwas vernünftiges zustandebringst, ist das auch etwas zum Vorzeigen, es muss ja nicht immer ein komplett eigenes Programm sein. Natürlich muss man sich dort erst einmal in die Codebasis des Projekts einarbeiten, aber du hast dann ja einen Mentor, der dir dabei hilft.
Ich schaue selbst derzeit, was ich bei GNU Hurd vielleicht umsetzen könnte, damit das Ding in akzeptabler Zeit endlich mal produktiv benutzbar werden kann und GNU auch eine eigene stabile Basis hat, satt immer von Torvalds & Co. abhängig zu sein. Aber das ist nur ein teilnehmendes Projekt von vielen, such dir eins aus. Hier ist eine Liste, was dieses Jahr alles zugelassen wurde.
Ich an deiner Stelle würde allerdings nicht auf nächsten Sommer warten, sondern gleich beginnen, auch wenn dir das kein Stipendium bringt - du sammelst Erfahrung, auch mit größeren Teams zu kollaborieren, und hast etwas ordentliches zum Vorzeigen, das - je nach Projekt - vielleicht sogar bald von vielen Menschen genutzt wird.
Wie wäre es mit einem verbreiteten Office-Paket? Audio/Video-Dekodern? Einer universellen IDE? Einer Compilersammlung? Einem Anonymisierer? Einem Vektor-/Pixelgrafikprogramm? Einem Betriebssystem-Kernel? Oder gar ein IM-Protokoll? Eine Internet-Suite?
Man findet so ziemlich alles, an was auch immer du gern üben würdest

[DanielJ]

Zitat von Perlsau:

Denn erstens gibt es die sog. Pflichtenhefte, in denen der Auftraggeber – nicht selten auch gemeinsam mit dem Entwickler – ganz genau spezifiziert, was die zu entwickelnde Software leisten muß. Wurden bestimmte Betriebsabläufe dabei nicht erfaßt, kann man das wohl kaum dem Programmierer anlasten.

Vorsicht! Für diesen Trugschluß habe schon einige kräftig draufgezahlt. Sollte es vor Gericht gehen sind die wenigsten Pflichtenheft das Papier wert, auf dem sie gedruckt sind. Und der Entwickler ist schließlich der "Profi" in der Geschäftsbeziehung, hätte also Schwächen des Plans erkennen müssen.

Also ich kann dem Threadsteller (und allen die Denken ein Pflichtenheft schützt sie) in diesem Sinne nur raten sich mit den Theman AGB/Haftung/Absicherung und Dienstleistung vs Werkvertrag mal auseinaderzusetzen.

LG,
Daniel

PS: Eine UG/GmbH schützt leider auch nicht vor Zahlungsausfällen

[Furtbichler]

Zitat von DanielJ:

Vorsicht! Für diesen Trugschluß habe schon einige kräftig draufgezahlt. Sollte es vor Gericht gehen sind die wenigsten Pflichtenheft das Papier wert, auf dem sie gedruckt sind. Und der Entwickler ist schließlich der "Profi" in der Geschäftsbeziehung, hätte also Schwächen des Plans erkennen müssen.

Entschuldigung, das ist nicht ganz korrekt ausgedrückt. Das Pflichtenheft definiert das, was der Dienstleister umsetzen soll. Es ist Bestandteil eines Vertrages.
Stehen Teile des Pflichtenheftes im Widerspruch zum gesunden Menschenverstand, ist letzterer verbindlich. Das hat aber nichts mit 'Profi' zu tun, sondern mit dem Umstand, das man vertraglich nicht festhalten kann, was nicht umzusetzen ist. Der Dienstleister ist hier kein 'Profi', sondern Ausführender und hat sich an die (vielleicht hirnrissigen) Vorgaben zu halten.

Ein Softwareentwickler ist kein Gott, der alles besser wissen müsste.

Bei einer Beratung ist das etwas anderes, hier muss nach dem aktuellen Wissenstand beraten werden. Aber hier gibt es selten Pflichtenhefte.

[vagtler]

Und ergänzend sei hinzugefügt, dass (sehr) oft Lasten- und Pflichtenhefte verwechselt werden und die Unterschiede oft nicht klar sind.

[Bernhard Geyer]

Zitat von Furtbichler:

..., das man vertraglich nicht festhalten kann, was nicht umzusetzen ist. ...

Doch, kann man. Steht auch in Wikipedia im Bereich Pflichtenheft unter 1.4.

Zitat:

1.4 Abgrenzungskriterien: diese Kriterien sollen bewusst nicht erreicht werden

Damit kann man sich viel Stress ersparen wenn man das explizit schriftlich festhält.

[Furtbichler]

Das war von mir falsch formuliert. Natürlich sollte man vertraglich auch das festhalten, was nicht umgesetzt werden *soll*.

Ich meinte, das man z.B. in einem Pflichtenheft nicht (verbindlich) vereinbaren kann, das die Suche in der Datenbank über einen Fluxkompensator zeitlich so optimiert wird, das das Ergebnis stehts 1/10s vor dem Klick auf den 'Search' Button erscheint.

Ich hätte also schreiben sollen, das nicht vereinbart werden kann, was nicht umsetzbar ist.

[DanielJ]

Zitat von Furtbichler:

Ich meinte, das man z.B. in einem Pflichtenheft nicht (verbindlich) vereinbaren kann, das die Suche in der Datenbank über einen Fluxkompensator zeitlich so optimiert wird, das das Ergebnis stehts 1/10s vor dem Klick auf den 'Search' Button erscheint.

Aber genau sowas meint der Kunde unter Umständen, wenn er sagt "..und die Adressen sollen durchsuchbar sein!"

Der Unbedarfe und wie in diesem Beispiel vieleicht noch nicht besonderst SQL-Erfahrene Freiberufler sagt "Kein Problem, ich hab da mal was gelesen über SQL und LIKE ... "

Der Richter hält PC´s sowiso für magisch Kisten und stimmt dem Kunden zu das diese blöden Dinger eben das machen sollen was man von ihnene erwartet!

... und ruck-zuck sitzt man da und Programmiert Monatelang den blöden Fluxkompensator ohne einen einzigen Cent dafür zu sehen - und am Ende freut sich der Kunde zwar insgeheim über das tolle Programm, zahlt aber nie, weil 1/10 vor Klick eben nicht gelifert werden konnte.

Sowas in der Art ist mir tatsächlich aus Praxisbeispielen bekannt und zum Glück (oder gerade deshalb) noch nicht selber passiert. Darum ist Kundenkommunikation für mich auch die wichtigste Fähigkeit für einen der sich in dem Bereich selbständig machen will. Fehlendes Wissen kann man sich nämlich notfalls über ein paar Nachtschichten aneignen und der Kunde merkt nichts davon.
Versteht man sich mit seinem Kunden nicht, hilft einem ein Stapel Papier mit Funktionsbeschreibungen auch nicht weiter!

LG,
Daniel