Hallo,
heute bei der Arbeit:
In einer Besprechung hat einer meiner Kollegen zum Thema Projektmanagement und Methoden die Frage eingeworfen, aus welchem Grund so viele mit modernsten Projektmethoden aufgesetzte Software- und IT-Projekte in vielen Unternehmen scheitern, "Open Source" Projekte hingegen mit simpelsten Methoden daher kämen, dazu kaotisch abliefen, jedoch einfach funktionierten?
Ich selbst habe nicht in diese Diskussion eingegriffen, obwohl es mich schon gereizt hat die Begrifflichkeiten wie beispielsweise "Open Source" richtig zu stellen. Nun, die Frage wurde von jemand anderem aufgegriffen und beantwortet... Das ganze lief dann auf die Projektleitung und setzen der korrekten Prioritäten hinaus. Alles in allem empfand ich selbst, diese Beantwortung als unzureichend, daher habe ich heute abend einmal näher darüber nachgedacht...
Ich selbst denke das Punkte wie "persönliche Interessen", "Identifizierung der eigenen Person mit der jeweiligen Tätigkeit" und evtl. "Selbstverwirklichung" in einem "Freie Software" Projekt eine große Rolle spielen. Zumindest ist das bei mir in etwa so, wenn ich das mal hinterfrage. Motivation, Verantwortungs- und Wirgefühl für das jeweilige Ding kommen dann von selbst.
In sehr vielen Unternehmensprojekten hingegen wird das Personal unabhängig von deren Interessen für irgendetwas eingesetzt, was die jeweiligen Personen vielleicht gar nicht interessiert. Dadurch baut sich meiner Meinung nach schnell eine Stimmung auf, die ein solches Projekt negativ beeinflussen kann. Evtl. fühlen sich nur wenige für irgendetwas verantwortlich und letztendlich scheitert das Ganze.
Kommentare? Mich würde interessieren, wie Ihr das seht?
Gruß, Volker
Hi Volker, hi alle,
Volker Dormeyer wrote:
In einer Besprechung hat einer meiner Kollegen zum Thema Projektmanagement und Methoden die Frage eingeworfen, aus welchem Grund so viele mit modernsten Projektmethoden aufgesetzte Software- und IT-Projekte in vielen Unternehmen scheitern, "Open Source" Projekte hingegen mit simpelsten Methoden daher kämen, dazu kaotisch abliefen, jedoch einfach funktionierten?
Nun, dazu gibt es tausend mögliche Gründe, die einem dazu einfallen können. Ich werde es mit einer Erklärungsmöglichkeit versuchen, die mir in den letzten Jahren meiner jungen beruflichen Tätigkeit begegnet ist.
Viele Firmen haben zuviel Geld.
Das klingt jetzt reduktionistisch, ist aber nicht der Fall.
Die meisten IT-Projekte werden mit Methoden durchgezogen, die vielleicht
für die Konstruktion eines Space-Shuttles angebracht sind, aber nicht für Software. Ich habe nichts gegen eine umfassende Analyse, meinetwegen mit Pflichtenheft und Design. Manche GNU-Subprojekte (z.B. GNU Enterprise) gehen einen halb-halb-Weg zwischen überdachtem Design und "einfach gutem" Coding. Wenn jedoch vier Wochen lang die komplette Software in UML von Leuten designt wird, die mit dem zu modellierenden Prozess aufgrund fehlender fachlicher (z.B. betriebswirtschaftlicher oder technischer) Kentnisse nicht vertraut sind und so die Software nach Fertigstellung nochmal redesignt werden muss, dann fließen Unmengen Ressourcen in eine Entwicklungsmaschinerie, die die gängigen Methoden der Softwareentwicklung als Vorwand für verzögerte Releases benutzt. Mit den Fachtermini erschlägt man dann den ahnungslosen Kunden, und er zahlt auch gerne die 200.000 Euros für Regressionstests, obwohl er nicht weiß, was das ist. Schließlich hat man ja bald eine (In-house-Software), die die Konkurrenz nicht hat!
Außerdem werden manchmal Leute IT-Projektleiter, die weder Ahnung von der Technik haben noch den Mut, ihre Ahnungslosigkeit zuzugeben und somit die Fachleute zu befragen. Dazu eine kleine Geschichte, stark vereinfacht, ohne Namen, weil ich das laut Vertrag nicht darf :-) Ein Kooperationspartner von einer Firma, für die ich gelegentlich Kleinigkeiten unternehme, hatte Angst, ein Rechner könne keine 10.000 Datensätze pro Sekunde (zu etwa 40 Byte) auf eine Festplatte ablegen und im Speicher in einen B-Tree sortieren. Desweiteren wurden A/D-Wandlerkarten für mehrere Tausend Mark eingekauft (schlecht dokumentiert noch dazu!), obwohl ein aufgebohrtes, selbstgelötetes Soundkarten-HW-Design nicht nur billiger, sondern auch wesentlich einfacher zu programmieren gewesen wäre.
Was will man da noch sagen?
In der Freien Software existiert einfach ein zu starker Ressourcenmangel, als das so etwas passieren könnte. Die Zeit mangelt einfach zu sehr für Kommittee-Designs. Wenn der Code dann zu fragil oder zu avantgarde für den eingesetzten Zweck ist, sortiert ihn die Evolution von alleine aus. Solche Projekte sterben entweder an ihrer mangelnden Wartbarkeit und/oder an ihrer Unverständlichkeit für potentielle Mitentwickler. Beispiele für ersteres sind BIND oder IIRC sendmail, für zweiteres so manches Stück GNOME-Software (ORB für simples Projektmanagement? Ts, ts ...)
Ich selbst denke das Punkte wie "persönliche Interessen", "Identifizierung der eigenen Person mit der jeweiligen Tätigkeit" und evtl. "Selbstverwirklichung" in einem "Freie Software" Projekt eine große Rolle spielen. Zumindest ist das bei mir in etwa so, wenn ich das mal hinterfrage. Motivation, Verantwortungs- und Wirgefühl für das jeweilige Ding kommen dann von selbst.
In sehr vielen Unternehmensprojekten hingegen wird das Personal unabhängig von deren Interessen für irgendetwas eingesetzt, was die jeweiligen Personen vielleicht gar nicht interessiert. Dadurch baut sich meiner Meinung nach schnell eine Stimmung auf, die ein solches Projekt negativ beeinflussen kann. Evtl. fühlen sich nur wenige für irgendetwas verantwortlich und letztendlich scheitert das Ganze.
Ja, das ist sicher ein weiterer ganz wichtiger Faktor. Allerdings ist FS-Projektmanagement auch nicht einfach: Große Projekte brauchen eine kritische Masse an ähnlich "gepolten" konstruktivisch befähigten Entwicklern, sonst wird nichts draus. Eine hilfreiche Statistik hierzu wäre auch eine Anzahl der die letzten Jahre gestarteten FS-Projekte, die diese kritische Masse nicht erreicht haben und somit eingegangen sind...
Wenn aber eine FS-Projekt mal abhebt, ist es schwer zu stoppen. Bei einem FS-Projekt ab einem gewissen Punkt irgend etwas anderes als ein exponentielles Wachstum zu prognostizieren, ist idiotisch ... Und wenn es zu viele Entwickler für das Hauptprojekt gibt, werden eben Plugins, Bindings und Nebenprojekte geschrieben. Siehe z.B. KDE, Gnome, Apache.
Letztenendes hilft ein bisschen "der alte" Raymond (d.h. ausschließlich "Cathedral and the Bazaar"), der Abschnitt "Worse is Better" aus einem Papier über LISPs Design, ein bisschen angewandte Systemtheorie (Dörner, "Die Logik des Mißlingens"), konstruktives anstelle "kritisches" Denken, ein guter Überblick und eine kräftige Portion gesunder Menschenverstand weiter.
Ciao, Christian
In einer Besprechung hat einer meiner Kollegen zum Thema Projektmanagement und Methoden die Frage eingeworfen, aus welchem Grund so viele mit modernsten Projektmethoden aufgesetzte Software- und IT-Projekte in vielen Unternehmen scheitern, "Open Source" Projekte hingegen mit simpelsten Methoden daher kämen, dazu kaotisch abliefen, jedoch einfach funktionierten?
Ich denke, wesentliche Punkte hier sind
* Freie Software wird von Leuten programmiert, die etwas von der Sache selbst verstehen. Proprietäre Software wird oft von Firmen erstellt, bei denen kein Mitarbeiter von der eigentlichen Materie eine Ahnung hat. (Beispiel: Beim bereits erwähnten GNU Enterprise-Projekt arbeiten echte Buchhalter mit, bei manchen proprietären Programmen hat man das Gefühl, der Programmierer hat den Unterschied zwischen Soll und Haben noch nicht ganz kapiert)
* Programmierer der Freien Software unterliegen fast nie einer Hierarchische Struktur, daher geht praktisch immer die Sache vor der Person.
* Freie Software wird meistens von "Idealisten" erstellt, denen auch persönlich etwas an der Sache liegt. Es ist ganz einfache: Da es kein "Gehalt" als Motivation gibt, muß die Motivation eine andere sein: ein möglichst gutes Stück Software zu schreiben.
Ciao,
On Thu, May 09, 2002 at 01:29:35PM +0200, Reinhard Müller wrote:
- Freie Software wird von Leuten programmiert, die etwas von der Sache
selbst verstehen.
Halte ich auch für einen guten Punkt. Am besten wird das Design von den Leuten gemacht, die was von der zu lösenden Aufgabe verstehen.
Die kürzeren Kommunikationswege von Freier Software, welche die Nutzer oft als Entwickler ernstnehmen, brint hier aber uach Vorteile, wenn die Entwickler keine Experten der Aufgabe sind.
- Programmierer der Freien Software unterliegen fast nie einer
Hierarchische Struktur, daher geht praktisch immer die Sache vor der Person.
Die Organisation von Unternehmen ist in den letzten Jahren von verschiedener Seite "neu erfunden" worden. Jeder Entwickler Freier Software in einem Unternehmen unterliegt jedoch irgendwie einer Hierachie. Die Frage ist, welche Bereiche diese umfasst. Beispielseweise: Muss jede Quelltextarbeitsstunde abgesprochen sein, oder nicht?
Insofern müsste dieser Punkt genauer argumentiert werden. Eine Hierachie allein sehe ich nicht als hinterlich an.
- Freie Software wird meistens von "Idealisten" erstellt, denen auch
persönlich etwas an der Sache liegt. Es ist ganz einfache: Da es kein "Gehalt" als Motivation gibt, muß die Motivation eine andere sein: ein möglichst gutes Stück Software zu schreiben.
Das möchte ich bestreiten. Ein grosser Anteil entwickelt Freie Software auch für Geld oder geldwerten Vorteil. Bezahlt dafür werden wahrscheinlich über ein Drittel. Das heisst nicht, dass dort nicht andere wichtige Motivationsfaktoren vorhanden sind. Geld wird auch nicht der hauptsächliche Motivationsfaktor sein.
Es ist schwierig hier aussagekräftige Belege zu finden. Die methodisch problematischen floss1 und widi Umfragen stützen eher meine Ausage.
Am Don, 2002-05-09 um 17.25 schrieb Bernhard Reiter:
On Thu, May 09, 2002 at 01:29:35PM +0200, Reinhard Müller wrote:
- Programmierer der Freien Software unterliegen fast nie einer
Hierarchische Struktur, daher geht praktisch immer die Sache vor der Person.
Die Organisation von Unternehmen ist in den letzten Jahren von verschiedener Seite "neu erfunden" worden. Jeder Entwickler Freier Software in einem Unternehmen unterliegt jedoch irgendwie einer Hierachie. Die Frage ist, welche Bereiche diese umfasst. Beispielseweise: Muss jede Quelltextarbeitsstunde abgesprochen sein, oder nicht?
Da habe ich mich wirklich schlecht ausgedrückt. Das was ich hier geschrieben habe, stimmt eigentlich nur für das "richtig chaotische" Entwicklungsmodell mit weltweit verstreuten "Freiwilligen".
Für Freie Software, die von Unternehmen erstellt wird (und natürlich wird dieser Teil immer mehr), ist es dann eher eine Frage der Unternehmenskultur - wie stark z.B. die Hierarchie Einfluss auf technische Entscheidungen hat. Möglicherweise ist die Unternehmenskultur bei Unternehmen, die sich mit Freier Software beschäftigen, "besser".
- Freie Software wird meistens von "Idealisten" erstellt, denen auch
persönlich etwas an der Sache liegt. Es ist ganz einfache: Da es kein "Gehalt" als Motivation gibt, muß die Motivation eine andere sein: ein möglichst gutes Stück Software zu schreiben.
Das möchte ich bestreiten. Ein grosser Anteil entwickelt Freie Software auch für Geld oder geldwerten Vorteil. Bezahlt dafür werden wahrscheinlich über ein Drittel. Das heisst nicht, dass dort nicht andere wichtige Motivationsfaktoren vorhanden sind. Geld wird auch nicht der hauptsächliche Motivationsfaktor sein.
So habe ich es eigentlich gemeint. Ein Programmierer, der richtig fett reich werden will, wird wahrscheinlich derzeit mit proprietärer Software dieses Ziel schneller erreichen als mit Freier. Das Geld ist sehr wohl auch in Freier Software dabe, die Motivation liegt aber zum größeren Teil woanders.
Ich denke, dass sich Entwickler von Freier Software wesentlich stärker mit ihrem Produkt identifizieren als Entwickler von proprietärer Software.
Reinhard
On Thu, May 09, 2002 at 12:01:48AM +0200, Volker Dormeyer wrote:
In einer Besprechung hat einer meiner Kollegen zum Thema Projektmanagement und Methoden die Frage eingeworfen, aus welchem Grund so viele mit modernsten Projektmethoden aufgesetzte Software- und IT-Projekte in vielen Unternehmen scheitern, "Open Source" Projekte hingegen mit simpelsten Methoden daher kämen, dazu kaotisch abliefen, jedoch einfach funktionierten?
Es läßt sich schwer darauf antworten, ohne zu wissen, welche "modernste" Projektmethoden gemeint sind. Das wissenschaftliche Ende vom Software-Engineering hat da durchaus verschiedene Ansätze zu bieten.
Zwischen "test a little -- code a little" und "UML-Modelling CASE Tools" ist da ein himmelweiter Unterschied.
In sehr vielen Unternehmensprojekten hingegen wird das Personal unabhängig von deren Interessen für irgendetwas eingesetzt, was die jeweiligen Personen vielleicht gar nicht interessiert. Dadurch baut sich meiner Meinung nach schnell eine Stimmung auf, die ein solches Projekt negativ beeinflussen kann. Evtl. fühlen sich nur wenige für irgendetwas verantwortlich und letztendlich scheitert das Ganze.
Das ist ein Punkt, aber auch nur einer. Es gibt durchaus sehr motivierte Mitarbeiter in propietären Unternehmen. Richtig ist aber auch eine Motivations fördernde Wirkung von Freier Software anzunehmen.
Für mich ist ein weiterer Schlüsselpunkt meine verkürzte These: "Software ist ein Kommunikationsproblem" Freie Software ermöglich eine andere Kommunikationsstruktur und das kann einiges an verwaltendem Wasserkopf verhindern.
Im Gegensatz zu Freier Software wird bei proprietärer oft in grossen Schritten Innovation betrieben, das fordert ab einer gewissen Aufgabengröße viel Verwaltungsanteil zur Koordination. Das bekannte Buch "The Mythical Man Month" erklärt das Problem gut.
Bei Freier Software gibt es eine Tendenz zu kleinen Innovationsschritten. Die können dann auch verteilt stattfinden. Für viele klassische Projektleiter sieht ein solcher Prozess chaotisch aus, da ervöllig anders verläuft.