Archiv verlassen und diese Seite im Standarddesign anzeigen : Projekt in den Sand gesetzt
Ich muss hier einfach mal einen "Rant" abladen, den ich wohl auch ins Programmierungs-Forum hätte packen können. Und zwar anonym, damit mir aus meinem Versagen nicht noch ein Strick gedreht wird.
Also...es begab sich vor einiger Zeit, dass ich als Student ein Software-Projekt entwickeln sollte (nicht an der Hochschule, wohlgemerkt).
Anfangs klang das ganz interessant, aber nach einer Weile taten sich immer mehr Abgründe auf.
Die potentiellen Nutzer wussten nicht, was sie eigentlich wollten und statt halbwegs sinnvollen Forderungen kamen nur Unsinn und nebensächliche Diskussionen über das Interface.
Dazu wurden die Anforderungen so festgelegt, dass mir von vornherein klar war, dass das eine einzige Katastrophe würde, da man kaum bestehende Technologien nutzen konnte und das ganze Programm um einen großen Hack herum gezimmert wurde. Alle Diskussionsversuche, dass man das so einfach nicht machen kann, die Entwicklung x-mal länger dauert und das Ganze nie wirklich 100% funktionieren wird blieben erfolglos.
Dann entwickelte sich das Projekt zu einem klassischen "Death Sprint". Die erste Version war recht schnell erstellt und gefiel, aber dann würden Stück für Stück die Anforderungen ausgebaut und geändert, das Projekt ist "vergammelt", bis am Ende jede Änderung nur noch unter Schmerzen möglich war.
Nach einigen Monaten Pause konnte ich wieder an dem Projekt entwickeln. Ich hatte mir in der Zwischenzeit einige Gedanken gemacht und einiges an Freizeit geopfert um ein bisschen was prototypisch zu implementieren und habe dann quasi zum Großteil ein Refactoring begonnen, um das Problem halbwegs "ordentlich" zu lösen.
Aus einem geplanten Monat wurden dann schnell zwei, dann drei und schwupps waren es vier und die Arbeitszeit war um. Ich habe mich die ganze Zeit extrem festgefressen, bin an einigen Sachen fast verzweifelt und habe viel zu oft Dinge bis zum geht nicht mehr weggeforfen und wieder neu aufgezogen. Ich Grunde ging die ganze Zeit gar nicht voran, sondern immer nur ein Schritt vor, ein Schritt zurück etc. und die Frusttrationsgrenze war schon lange überschritten - im Grund ein klassischer "Death March".
Dazu kam noch, dass ich in besagter Pause meine Diplomarbeit geschrieben habe, bei der ich gerade im letzten Monat bis zum Umfallen geackert habe. Und dann bin ich ohne Pause (direkt unter der Woche) von der Diplomarbeit (also der Abgabe) wieder in den Vollzeitjob gewechselt, wobei ich mir ganz dringend ein paar Wochen Urlaub hätte gönnen sollen (ich brauchte aber das Geld).
Blöderweise hat sich mein "Betreuer" nie so großartig um das Projekt gekümmert. Keiner hat da je in den Code geschaut, obwohl von vornherein klar war, dass das auf jeden Fall weiter gewartet werden müsste.
Jetzt steht er natürlich dumm da, da unter seiner Aufsicht einiges an Geld sinnlos verpulvert wurde.
Und ich quäle mich seit geraumer Zeit mit dem Teil rum, weil ich es quasi in meiner Freizeit "noch schnell" fertig machen wollte. Aber die Frustgrenze ist so weit überschritten, dass es einfach nicht mehr wirklich voran geht, auch wenn ich weiss, dass vielleicht eine Woche richtige Arbeit das Ding halbwegs retten könnten.
Viele würden sagen "scheiss drauf", sich über das verdiente Geld freuen und die Sache abhaken. Aber an mir nagt das einfach extrem...
Wenn ich eins gelernt habe in den letzten Jahren dann ist es IMMER ein Pflichtenheft VORHER erstellen und absegnen zu lassen. Darauf dann eine Kalkulation aufbauen und dem Kunden vorlegen. Wenn er die abnickt, genau und wirklich genau das umsetzen. Will er plötzlich was anderes -> neu kalkulieren und dem Kunden die Zusatzkosten vor die Nase halten.
Du glaubst nicht wie einsichtig und genügsam die Leute werden wenn sie erst einmal sehen was das alles kostet und vor allem wenn sie dafür aufkommen müssen.
Auf so etwas was du gemacht hast würde ich mich nie mehr einlassen (den Fehler hab ich am Anfang auch gemacht, einfach mal grob loslegen und dann flexibel auf den Kunden reagieren wollen -> geht definitiv schief)
Und denke bitte realistisch. Sind die eine Woche, die du noch Arbeit reinstecken müsstest wirklich 40h oder 7x24h. Das ist ein großer Unterschied auch wenns beides ne Woche ist. ;) Rechne lieber in Manntagen, das ist in der Wirtschaft dann eh so üblich. (1 Manntag = 8 Stunden)
Gibt so ne Grundformel: Nimm die vermutliche Entwicklungszeit, verdoppel sie und du hast die ungefähr reell benötigte Entwicklungszeit.
Shink
2011-02-14, 08:49:05
Die potentiellen Nutzer wussten nicht, was sie eigentlich wollten und statt halbwegs sinnvollen Forderungen kamen nur Unsinn und nebensächliche Diskussionen über das Interface.
Willkommen in der Realität.:freak:
Dazu wurden die Anforderungen so festgelegt, dass mir von vornherein klar war, dass das eine einzige Katastrophe würde, da man kaum bestehende Technologien nutzen konnte und das ganze Programm um einen großen Hack herum gezimmert wurde. Alle Diskussionsversuche, dass man das so einfach nicht machen kann, die Entwicklung x-mal länger dauert und das Ganze nie wirklich 100% funktionieren wird blieben erfolglos.
Öhm... du hättest nicht deinen Segen dazu geben sollen?
Dann entwickelte sich das Projekt zu einem klassischen "Death Sprint". Die erste Version war recht schnell erstellt und gefiel, aber dann würden Stück für Stück die Anforderungen ausgebaut und geändert, das Projekt ist "vergammelt", bis am Ende jede Änderung nur noch unter Schmerzen möglich war.
Nach einigen Monaten Pause konnte ich wieder an dem Projekt entwickeln. Ich hatte mir in der Zwischenzeit einige Gedanken gemacht und einiges an Freizeit geopfert um ein bisschen was prototypisch zu implementieren und habe dann quasi zum Großteil ein Refactoring begonnen, um das Problem halbwegs "ordentlich" zu lösen.
Aus einem geplanten Monat wurden dann schnell zwei, dann drei und schwupps waren es vier und die Arbeitszeit war um. Ich habe mich die ganze Zeit extrem festgefressen, bin an einigen Sachen fast verzweifelt und habe viel zu oft Dinge bis zum geht nicht mehr weggeforfen und wieder neu aufgezogen. Ich Grunde ging die ganze Zeit gar nicht voran, sondern immer nur ein Schritt vor, ein Schritt zurück etc. und die Frusttrationsgrenze war schon lange überschritten - im Grund ein klassischer "Death March".
Du hast gelernt dass man es so nicht macht?
Blöderweise hat sich mein "Betreuer" nie so großartig um das Projekt gekümmert. Keiner hat da je in den Code geschaut, obwohl von vornherein klar war, dass das auf jeden Fall weiter gewartet werden müsste.
Jetzt steht er natürlich dumm da, da unter seiner Aufsicht einiges an Geld sinnlos verpulvert wurde.
Und ich quäle mich seit geraumer Zeit mit dem Teil rum, weil ich es quasi in meiner Freizeit "noch schnell" fertig machen wollte. Aber die Frustgrenze ist so weit überschritten, dass es einfach nicht mehr wirklich voran geht, auch wenn ich weiss, dass vielleicht eine Woche richtige Arbeit das Ding halbwegs retten könnten.
Viele würden sagen "scheiss drauf", sich über das verdiente Geld freuen und die Sache abhaken. Aber an mir nagt das einfach extrem...
Das ist normal. Studenten setzen sehr oft Softwareprojekte in den Sand. Unternehmen übrigens ebenfalls:
http://www.projectperfect.com.au/images/info/info_it-projects-fail.gif
Laut dieser (ziemlich alten, ich weiß) Studie der Standish Group werden ~20% der Softwareprojekte in den Sand gesetzt und über 50 weitere Prozent werden viel zu spät oder viel zu teuer fertig.
Bei Studentenprojekten sind es wohl wesentlich mehr - deshalb bezahlt für so etwas auch niemand 100€/Stunde. Und deshalb hätte auch dein Betreuer dahinter sein müssen.
Antworten wären die Ausarbeitung und Abnahme von genauen Spezifikationen oder ein iteratives Vorgehen das es erlaubt so früh wie möglich alle Probleme auf den Tisch zu legen. Dazu gehört dann z.B. ein tägliches Gespräch mit den anderen Projektbeteiligten (dein Betreuer?).
Vor allem aber: Nimm so etwas nicht persönlich. Wenn du was in deiner Freizeit machst und niemandem Bescheid gibst dass es viel mehr Aufwand ist als geplant dann war vielleicht auch nur die Planung Müll und nicht unbedingt deine Arbeit.
Das wichtigste ist aber alle Probleme so früh wie möglich anzusprechen.
Bla bla bla noch viel lernen du musst junger Padawan etc. :comfort2:
Haarmann
2011-02-14, 09:06:11
Gast
Und was hast daraus gelernt?
Genau - die User sind dumm und denen ist ein pinker Hintergrund und eine sprechende Büroklammer wichtiger, denn ein funktionierendes Produkt.
Und weil sehr viele Projektleiter überhaupt auf solche "Forderungen" eingehen, gehts dann schief...
Du wirst das noch sehr oft sehen - und ja, es ist normal, dass sie Dich zum fegen des Platzes schicken und Dir ne Zahnbürste als Werkzeug mitgeben ;).
Ich glaube auf so ein Projekt sieht jeder in der Branche früher oder später zurück (siehe verlinkte Studie). An deiner Stelle würde ich das positive daran sehen: Du weißt jetzt wie es nicht geht. In Zukunft wirst du vermutlich offensiver einfordern was du aus deiner Sicht für die erfolgreiche Durchführung eines Projekts benötigst.
Wichtig ist halt das du nicht den Kopf für die Fehler anderer hinhältst - das am besten wenn du so früh wie möglich auf die Probleme hinweist.
Freakazoid
2011-02-14, 12:28:59
Einmal und nie wieder. Hab an so ner ähnlichen Geschichte selbst viel über mich gelernt. Keine Erfahrung die gerne wieder machen würde, aber da muss wohl jeder mal durch.
Hayab
2011-02-15, 01:07:27
Mein erstes Projekt ging genau nach diesen Prinzip. Mach du was und ich sag ob es ok ist. Nerven hat es mich genug gekostet.
Danach hab ich nur anhand des Pflichtenhefts programmiert, obwohl die Anforderungen an das Prorgramm manchmal so ungenau spezifiziert waren, dass dieser Pflichtenheft nicht mal Papier wert war, auf dem er gedruckt wurde.
Mein letztes Projekt dauerte 16 Monate und in der Endphase habe ich oft von Codezeilen Nacht geträumt. Als ich gesehen habe, das noch so ein scheiß Projekt auf mich zu kommt, habe ich die Firma verlassen. Die haben zwar gut gezahlt aber mein Schlaf Nachts ist mir mehr wert.
Shink
2011-02-15, 08:06:49
Als ich gesehen habe, das noch so ein scheiß Projekt auf mich zu kommt, habe ich die Firma verlassen. Die haben zwar gut gezahlt aber mein Schlaf Nachts ist mir mehr wert.
Sehr vernünftig! Das ist wohl auch etwas dass man als junger Software Entwickler lernen muss. Hab mich für meine vorige Firma jahrelang ins Zeug gelegt aber ich muss zugeben den Konkurs hat sie sich redlich verdient.:rolleyes:
Das Patentrezept für Erfolg und langfristige Zufriedenheit lautet "Work smart, not hard".
Wenn ich eins gelernt habe in den letzten Jahren dann ist es IMMER ein Pflichtenheft VORHER erstellen und absegnen zu lassen. Darauf dann eine Kalkulation aufbauen und dem Kunden vorlegen. Wenn er die abnickt, genau und wirklich genau das umsetzen. Will er plötzlich was anderes -> neu kalkulieren und dem Kunden die Zusatzkosten vor die Nase halten.
Du glaubst nicht wie einsichtig und genügsam die Leute werden wenn sie erst einmal sehen was das alles kostet und vor allem wenn sie dafür aufkommen müssen.
Leider hat man als Student nunmal gar nichts zu melden und da kann man lange auf irgendwas bestehen, dafür bekommt man höchstens ein schiefes Lächeln. Das das alles länger dauert als nötig, wurde bewusst in Kauf genommen - da das deren Ansicht nach eben must-have Features waren, ohne die ja gar nichts ging (eine funktionierende Undo-Funktion brauchten sie aber nicht, lol).
Öhm... du hättest nicht deinen Segen dazu geben sollen?
Öhm...mich hat da nicht wirklich einer gefragt. Das lief dann eher nach dem Motto "geht nicht - gibts nicht".
Mich persönlich nervt dabei vorallem an den eigenen Ansprüchen gescheitert zu sein. Ich hätte das Ding auch fertig haben können - in Form einer unwartbaren Müllhalde, die kein Mensch jemals durchschaut.
Klar, jetzt ists zu spät. Und gelernt habe ich, bei sowas möglichst schnell den Job zu wechseln - denn Diskussionen sind eh aussichtslos.
Kenny1702
2011-02-16, 10:00:54
Mund abputzen und daraus lernen.
Selbst als Student hast du durchaus was zu sagen. Früh genug und schriftlich hilft i.d.R. Und das Geld wegen dir verschwendet wurde, sehe ich nicht so, da du selbst schreibst, dass sich dein Betreuer kaum um dich gekümmert hat.
Und nimm es nicht persönlich. Klar hast du Fehler gemacht, aber das machen wir alle. Lerne aus deinen Fehlern und gut ist. Und so einen Mist wie geschäftliche Arbeit unbezahlt in anscheinend grossem Umfang zu Hause zu machen, habe ich noch nie verstanden. So etwas ist bei mir ein grundsätzliches No go.
Monger
2011-02-16, 10:39:54
Es gibt manche Projekte, die sind besser dran wenn man sie in Würde sterben lässt. Manchmal ist es einfacher, alles abzubrennen und nochmal aufzubauen (oder seine Arbeitskraft in bessere Projekte zu investieren), statt ewig ein totes Pferd zu reiten.
Ein Softwareprojekt ist ja kein Selbstzweck: es soll einem bestimmten Kundenkreis einen bestimmten Service ermöglichen, und dafür Geld einspielen. Das funktioniert in aller Regel nur für einen ganz bestimmten Lebenszyklus: selbst die tollste Software ist oft in fünf Jahren schlicht überholt, und somit unnütz.
Wenn irgendwas davon nicht passt, sprich: wenn man nicht den Kundenkreis erreicht den man möchte, wenn die Software zu viel Pflegeaufwand braucht, oder einfach nicht genügend kann um sich von der Konkurrenz abzusetzen, dann ist sie den Aufwand schlicht nicht wert.
Wenn ein Projekt scheitert, ist das schlimm. Noch schlimmer ist es, wenn man sich das nicht eingestehen will.
Shink
2011-02-16, 10:55:35
Ein Softwareprojekt ist ja kein Selbstzweck: es soll einem bestimmten Kundenkreis einen bestimmten Service ermöglichen, und dafür Geld einspielen. Das funktioniert in aller Regel nur für einen ganz bestimmten Lebenszyklus: selbst die tollste Software ist oft in fünf Jahren schlicht überholt, und somit unnütz.
Naja, wenn ich das richtig verstehe geht es hier (wie beim quantitativen Großteil der Softwareentwicklung) wohl um eine Individualentwicklung. Das Zeug ist quasi nie überholt und oft Jahrzehnte ohne Pflege im Einsatz.
@TS: Wenn du nur Programmiersklave ohne Verantwortung warst dann hast du dir nichts vorzuwerfen.
Lokadamus - nixBock
2011-02-16, 14:09:31
Naja, wenn ich das richtig verstehe geht es hier (wie beim quantitativen Großteil der Softwareentwicklung) wohl um eine Individualentwicklung. Das Zeug ist quasi nie überholt und oft Jahrzehnte ohne Pflege im Einsatz.mmm...
Jahrzehnte wohl eher nicht, ansonsten müsste überall noch Software laufen, die Win 3.11, MS- DOS oder irgendwas davor benötigen ;).
Nach 5 Jahren dürfte die Software aber so weit sein, dass man sie generalüberholen könnte. Die meisten Firmen machen es aber nicht, wozu auch? Es funktioniert doch ...
Ich denke, nach ca. 10 Jahren gibt es in den meisten Fällen Alternativen, da sich die Software im allgemeinen immer weiterentwickelt und es andere Firmen gibt, die ähnliche Produkte auf den Markt gebracht haben. Ob sich der Wechsel allerdings wirklich lohnt, kann niemand sagen, da einige Firmen auch mit neuer Hard- und Softwareumgebung nur Mist bauen.
Es erinnert mich gerade an die eine Sache, die mir ein Entwickler mal gesagt hat. Die Leute wissen gar nicht, was sie eigentlich wollen. Dann erstellt man den Leuten erstmal die Grundseite ohne Funktionen und fragt nach, ob sie wirklich sowas wollen. Der eine Teil nervt damit, dass die Sachen nicht funktioneren, wenn man auf die Knöpfe drückt und der andere Teil, dass das so gar nicht besprochen war. Es sollte alles ganz anders sein, aber wie, wissen sie selber nicht. ;)
Shink
2011-02-16, 15:03:01
mmm...
Jahrzehnte wohl eher nicht, ansonsten müsste überall noch Software laufen, die Win 3.11, MS- DOS oder irgendwas davor benötigen ;).
Naja, meist läuft das Zeug eben nicht unter MS-DOS sondern unter HP-Unix, OS/400 o.ä. und man bedient unter Windows 7 eine Terminalemulation oder bastelt einen Webclient dafür.:freak:
Meist sind die Sachen ja durchaus produktiv da ausgereift - im wahrsten Sinne des Wortes.
Ein netter Artikel dazu:
http://www.theregister.co.uk/2007/01/05/developing_legacy_systems_part2/
90% der Bankentransaktionen laufen danach in Cobol - ich nehme mal an die hat man nicht innerhalb der letzten 5 Jahre neu entwickelt.:freak:
Ich denke, nach ca. 10 Jahren gibt es in den meisten Fällen Alternativen, da sich die Software im allgemeinen immer weiterentwickelt und es andere Firmen gibt, die ähnliche Produkte auf den Markt gebracht haben.
Individualentwicklungen bringt man nicht "auf den Markt".
Senior Sanchez
2011-02-16, 16:13:01
Es erinnert mich gerade an die eine Sache, die mir ein Entwickler mal gesagt hat. Die Leute wissen gar nicht, was sie eigentlich wollen. Dann erstellt man den Leuten erstmal die Grundseite ohne Funktionen und fragt nach, ob sie wirklich sowas wollen. Der eine Teil nervt damit, dass die Sachen nicht funktioneren, wenn man auf die Knöpfe drückt und der andere Teil, dass das so gar nicht besprochen war. Es sollte alles ganz anders sein, aber wie, wissen sie selber nicht. ;)
Das ist wirklich so und an dieser Stelle schreit es nach einem Klassiker: (ist sogar eine erweiterte Variante)
http://code.reduxo.de/media/2010/03/projekt-management-schaukel-baum-seil-gross.png
http://code.reduxo.de/media/2010/03/projekt-management-schaukel-baum-seil-gross.png
ymma - die iifizierte Version kannte ich noch gar gar nicht.
Hab gerade auch ein Projekt .... "zum Abschluss gebracht" bei dem ich mehr als einmal an genau das Bild gedacht habe. Herpderp-code vom Vorgänger =
:uexplode:
Lokadamus - nixBock
2011-02-16, 17:02:56
Ein netter Artikel dazu:
http://www.theregister.co.uk/2007/01/05/developing_legacy_systems_part2/
90% der Bankentransaktionen laufen danach in Cobol - ich nehme mal an die hat man nicht innerhalb der letzten 5 Jahre neu entwickelt.:freak:
Individualentwicklungen bringt man nicht "auf den Markt".mmm...
Läuft da die Version von 1980/ 1990 drauf oder die von 2000?
Die von 2000 ist gerade erst 10 Jahre alt ;).
Wieviele Firmen bieten eine Softwarelösung für den Bankensektor an?
Jein, demnach hätten wir heute nur 2 Softwarefirmen. Es gibt aber in Deutschland ein paar mehr Firmen, die für kleine Firmen/ Mittelstand Sachen wie Warenwirtschaft, Webseiten usw. programmieren. Hierbei werden auch individuelle Sachen benötigt, aber es gibt mehrere Firmen, die es anbieten. Vor allem ganz du hier auch wechseln, weil das Grundgerüst bieten ein paar Firmen an und wie teuer die Anpassungen an die eigene Struktur werden, ist eher die Frage.
Das wichtigste ist das solche Probleme konstruktiv diskutiert und resultierende Entscheidungen schriftlich und vertraglich festgehalten werden müssen. Lässt man so etwas einfach unförmlich abnicken hat man bereits verloren. Ich hatte wie viele Andere auch den Fehler gemacht das ich das wegen der anfänglich so freundlichen Arbeitsbeziehung dies für nicht wichtig erachtet habe.
Das wichtigste ist das solche Probleme konstruktiv diskutiert und resultierende Entscheidungen schriftlich und vertraglich festgehalten werden müssen.
Das ist leicht gesagt, aber in welcher (kleinen) Firma wird die Entwicklung (primär) interner Tools mit großem Pflichtenheft etc. aufgezogen?
mmm...
Läuft da die Version von 1980/ 1990 drauf oder die von 2000?
Die von 2000 ist gerade erst 10 Jahre alt ;).
Wieviele Firmen bieten eine Softwarelösung für den Bankensektor an?
Jein, demnach hätten wir heute nur 2 Softwarefirmen. Es gibt aber in Deutschland ein paar mehr Firmen, die für kleine Firmen/ Mittelstand Sachen wie Warenwirtschaft, Webseiten usw. programmieren. Hierbei werden auch individuelle Sachen benötigt, aber es gibt mehrere Firmen, die es anbieten. Vor allem ganz du hier auch wechseln, weil das Grundgerüst bieten ein paar Firmen an und wie teuer die Anpassungen an die eigene Struktur werden, ist eher die Frage.
ibm ist meiner einschätzung nach der größte dienstleister für banken.
die dienste für geschäftprozesse sind bei vielen banken etliche jahre alt (wir reden hier wirklich von 30+ jahren). wenn man in die job-börsen schaut sieht man auch einen erhöhten bedarf an cobol-programmieren was zeigt, dass der einsatz von solch alter software keinesfalls ein einzelfall ist.
Shink
2011-02-17, 08:54:43
Das wichtigste ist das solche Probleme konstruktiv diskutiert und resultierende Entscheidungen schriftlich und vertraglich festgehalten werden müssen. Lässt man so etwas einfach unförmlich abnicken hat man bereits verloren. Ich hatte wie viele Andere auch den Fehler gemacht das ich das wegen der anfänglich so freundlichen Arbeitsbeziehung dies für nicht wichtig erachtet habe.
Oldscool, Leutchens.:freak:
Agile Softwareentwicklung funktioniert durchaus. Wenn man ständig mit dem Kunden arbeitet weiß er woran er ist, was er verlangen kann und hat ein Gespür dafür ob es gerechtfertigt ist das Verlangte zu zahlen.
Das ist leicht gesagt, aber in welcher (kleinen) Firma wird die Entwicklung (primär) interner Tools mit großem Pflichtenheft etc. aufgezogen?Selbstverständlich ist das nur in bestimmten Relationen möglich. Jedoch ist es als Freiberufler dein Problem, dass wenn sich signifikante Planabweichungen abzeichnen, das vertraglich von der anderen Seite auch absegnen zu lassen.
Ohne dem kann dir der Auftraggeber problemlos (Teil-)Zahlung verweigern ohne das er irgendwelche ernsten Konsequenzen befürchten muss weil es ja dann ein typischer Streitfall ohne klare vertragliche Beweislage ist.
Oldscool, Leutchens.:freak:
Agile Softwareentwicklung funktioniert durchaus. Wenn man ständig mit dem Kunden arbeitet weiß er woran er ist, was er verlangen kann und hat ein Gespür dafür ob es gerechtfertigt ist das Verlangte zu zahlen.Leider kannst du das in der Realität vergessen. Der Auftragsgeber braucht nur den geringsten Anlass um bei dir Zahlungen einzusparen und schon bleibst du auf möglicherweise vielen Monaten Arbeitsleistung sitzen.
Was willst du dann schon machen? Auf vertragslose Arbeitsleistungen verklagen? HAHA!
creave
2011-02-17, 14:45:26
mmm...
Er hat trotzdem nicht unrecht. Es ist einfach unglaublich, wie oft man heute noch cobol und Co. vorfindet. Es läuft einfach und keiner traut es sich mehr anzufassen, man redet nicht umsonst von historisch gewachsenen Altlasten, und hier macht der Begriff monolitisch auch anschaulich mal Sinn.
Kenny1702
2011-02-17, 19:43:16
Oldscool, Leutchens.:freak:
Agile Softwareentwicklung funktioniert durchaus. Wenn man ständig mit dem Kunden arbeitet weiß er woran er ist, was er verlangen kann und hat ein Gespür dafür ob es gerechtfertigt ist das Verlangte zu zahlen.
Man muß vielleicht nicht alles vertraglich festhalten, aber schriftlich ist ein Muß. Es kann sonst schnell mal zu "Erinnerungslücken" kommen.
Außerdem setzt die agile Entwicklung voraus, daß der Kunde aktiv mitarbeitet. Wenn er es tut, kann es recht angenehm sein, wenn nicht, sollte man alles schriftlich haben.
PatkIllA
2011-02-17, 20:07:01
Am Ende ist ja auch keinem geholfen, wenn man das Pflichtenheft Wort für Wort genau nach Zeitplan erfüllt hat, aber der Kunde damit nichts anfangen kann.
Wenn man Kunden längere Zeit kennt, lernt man auch wie man mit wem umgehen muss.
Ich hoffe, dass es bei uns auch demnächst mal wieder etwas ruhiger wird, nachdem wir im letzten Jahr quasi unsere Basis komplett neu hochgezogen haben und jetzt die ganzen Produkte auf die neue Basis gebracht werden müssen.
Tja, dann schauen wir mal in die Realität, und was wirklich so läuft, weder vernünftige Projektplanung, Budgetierung noch Pflichtenhefte. Und in den Stellenauschreibungen für Entwickler steht oft was von agiler Softwareentwicklung drin. Ein Schelm, wer böses dabei denkt.
PatkIllA
2011-02-20, 07:54:43
http://tamingdata.com/wp-content/uploads/2010/07/tree-swing-project-management-large.png
Simon
2011-02-24, 10:26:01
Tja, dann schauen wir mal in die Realität, und was wirklich so läuft, weder vernünftige Projektplanung, Budgetierung noch Pflichtenhefte.
Dazu kommt, dass die jährlichen Performance Reviews dann davon abhängig gemacht werden, wie gut oder schlecht man sein Projekt ohne jegliche Planung vom Projektmanager oder Pflichtenheft. Ist auch alles auf Zuruf, beim Review will sich dann keiner mehr erinnern :mad: :mad: :mad:
Dem Vorgesetzten gesagt, dass dies und jenes Projekt weder Pflichtenheft noch Planung hat - und was passiert? nix.
Hätte ich nach dem Studium nicht geglaubt, dass es sowas echt noch gibt. Gibt es leider noch viel viel viel zu häufig. Auch bei Firmen/Leuten, die es eigentlich besser wissen müssten...
Dazu wurden die Anforderungen so festgelegt, dass mir von vornherein klar war, dass das eine einzige Katastrophe würde, da man kaum bestehende Technologien nutzen konnte und das ganze Programm um einen großen Hack herum gezimmert wurde. Alle Diskussionsversuche, dass man das so einfach nicht machen kann, die Entwicklung x-mal länger dauert und das Ganze nie wirklich 100% funktionieren wird blieben erfolglos.
Dann entwickelte sich das Projekt zu einem klassischen "Death Sprint". Die erste Version war recht schnell erstellt und gefiel, aber dann würden Stück für Stück die Anforderungen ausgebaut und geändert, das Projekt ist "vergammelt", bis am Ende jede Änderung nur noch unter Schmerzen möglich war.
Ist leider normal. Ich möchte gerne mal eine Firma kennenlernen, wo das nicht so ist :down:
Viele würden sagen "scheiss drauf", sich über das verdiente Geld freuen und die Sache abhaken. Aber an mir nagt das einfach extrem...
Sei froh, dass du deinen Stolz noch hast. Wenn nicht, stumpfst du ab und dir ist das alles irgendwann egal. Auch blöd...
Das ist leicht gesagt, aber in welcher (kleinen) Firma wird die Entwicklung (primär) interner Tools mit großem Pflichtenheft etc. aufgezogen?
Das blöde ist, dass dir aus dem fehlenden Pflichtenheft ganz schnell ein Strick gedreht wird. Es muss ja nix formal großes sein, nur ein paar Punkte schriftlich, die von allen schriftlich agreed werden. So unschön das ist, es ist notwendig.
Shink
2011-02-24, 10:46:36
Ist leider normal. Ich möchte gerne mal eine Firma kennenlernen, wo das nicht so ist :down:
Kannst ja mal bei uns vorbeischauen.;)
ernesto.che
2011-03-01, 20:25:03
Ich bin auf der anderen Seite. :freak:
Was ich bekommen habe, sah nicht so aus wie ich es wollte und konnte nicht was es sollte. Dafür aber andere Sachen, die technisch möglicherweise reizvoll sind, die ich aber gar nicht benötigt habe.
Schon seit längerem bekommen die auch bei relativ kleinen Projekten von mir deswegen eine Designvorlage und immer auch alles sauber ausformuliert.
Vorher wurde da einiges vergessen und ich durch bestimmt gut gemeinte Eigeninitiative bevormundet.
Seit das ganze optisch und funktional klar definiert ist, gibt es nur noch minimale Probleme. Das muss der Auftraggeber genauso wie der Auftragnehmer lernen. Läuft entspannter und geht schneller.
Dadurch, dass die mir jetzt auch nicht mehr (aus meiner Sicht zu Unrecht) vorwerfen können, ich würde die Anforderungen ändern - da es ja schriftlich vorliegt - spare ich auch Geld ein. Habe mich vorher, um ans Ziel zu kommen, zu Bestechungen mit Keksen, Eiscreme, Big Macs und ganzen Mittagessen nötigen lassen müssen.
So, mal schnell einige Jahre fast forward, weil ich mich das Ganze jetzt wieder eingeholt hat.
Zum Verständis sollte ich noch anmerken, dass besagter Arbeitgeber ein Forschungsinstitut war, an dem ich erst als Hiwi an dem Projekt, dann an meiner Diplomarbeit mit einem anderen Thema und dann wieder als Hiwi an dem Projekt gearbeitet habe. Und die Diplomarbeit wurde sehr gut bewertet.
Seit über 5 Jahren arbeite ich jetzt bei einer anderen Firma, aber so langsam ist da auch die Luft raus, deshalb suche ich was Neues.
Es gab ein sehr interessantes Stellenangebot, dass sehr gut auf mein Profil passt und sogar auf die Diplomarbeit, die ich damals bei besagtem Forschungsinstitut geschrieben habe. Die Hiwi-Tätigkeit habe ich im Lebenslauf lieber verschwiegen, dafür habe ich eh nicht mal ein Arbeitszeugnis.
Ich hatte dann auch extrem schnell ein Vorstellungsgespräch, welches eigentlich wunderbar lief. Darauf sollte dann, wenn ich in die engere Auswahl komme, noch ein zweites Gespräch und eine Probeaufgabe folgen. Kann nicht viel schiefgehen sollte man meinen, so viele Leute mit einem derart passenden Profil wirds schon nicht geben. Außerdem hatte die Firma alternativ noch eine zweite Stelle zu besetzen, auf die ich auch wunderbar gepasst hätte.
Jetzt kommt das Problem: die Leute von der Firma kennen die Leute vom Forschungsinstitut (klar, gleiche Stadt, gleiches Fachgebiet). Und nach einer Woche gabs die Absage. Kann man sich denken, was da gelaufen ist.
interzone
2016-07-17, 20:44:21
ich denke, in der Softwareentwicklung wird man nur alt, wenn man möglichst keine Kundenprojekte (extern) durchleiden muss.
Oder in einer Firma arbeitet, die sich Softwareentwicklung spezialisiert hat (erfahrene Profis), und die IT eben nicht als notwendigen Kostenfaktor sieht, der nichts einbringt (die Systeme laufen ja allein, klar).
Es kann auch schon einmal vorkommen, dass Projekte "politisch" motiviert sind.
Da ist Qualität, bzw. die Rahmenbedingungen dazu, nicht relevant.
Hauptsache, man hat beim Kunden die Tür offen, oder einem Mitbewerber diese geschlossen.
Das brutale ist, wenn man sehenden Auges auf die absehbare Katastrophe zu steuert - ohne Chance, egal mit welchem Einsatz.
Egal wie hart man meint zu sein - sowas nimmt einen immer mit.
So, mal schnell einige Jahre fast forward, weil ich mich das Ganze jetzt wieder eingeholt hat.
:
Jetzt kommt das Problem: die Leute von der Firma kennen die Leute vom Forschungsinstitut (klar, gleiche Stadt, gleiches Fachgebiet). Und nach einer Woche gabs die Absage. Kann man sich denken, was da gelaufen ist.
Nimms wie ein Mann und sag Dir: "Scheiß drauf!"
Vielleicht ist es dann gerade gut, wenn Du eine Absage bekommen hast, weil die Stelle eben aus diesem Grunde nichts für Dich ist, daß ist jetzt vollkommen wertneutral gemeint! Und vor allen Dingen, laß es für Dich offen und verschwende keine Gedanken darüber, warum Du nicht genommen wurdest. Bei vielen Bewerbungsgesprächen habe ich bei Absagen es auch öfters persönlich genommen und die Fehler bei mir gesucht, und dann nach Jahren habe ich durch Zufall erfahren, was da wirklich gelaufen ist. Wie ein TS hier sagte, es ist oft viel Politik und anderes dabei, was rein gar nicht mit Dir zu tun hatte.
Hake es ab, und such die nächste Stelle.
Korfox
2016-07-18, 07:27:14
Kann man sich denken, was da gelaufen ist.
Völlig normal, dass einem die Vergangenheit schonal auf die Füße fällt. Zusammenraffen, zusammennähen, ins nächste Sägewerk rennen.
(Weißt du eigentlich, was aus deinem Projekt später dann geworden ist?)
dr_AllCOM3
2016-07-18, 10:25:34
Wird immer wieder vorkommen. Entweder aus Eigenverschulden oder weil einfach jemand Mist baut. Lern draus und haks dann ab. Vor allem mental, das toetet dich sonst innerlich.
Warte nur mal ab, bis du spaeter mal Leute treffen wirst, die absichtlich ein Projekt in den Sand setzen.
Und nach einer Woche gabs die Absage. Kann man sich denken, was da gelaufen ist.
Was im Hintergrund läuft ist auch nicht wichtig. Sollte irgendwer irgendwas gesagt haben, dann sei über den Ausgang froh, denn letztendlich hätten sie nur auf das Hörensagen von den Versagern gesetzt, die es eigentlich verbockt haben ohne an dir und deinem Können persönlich interessiert zu sein (vorallem nach 5 Jahren). Und wenn das so ist, dann willst du dort nicht arbeiten.
Projekte mit hauptsächlich politisch motivierten, unfähigen Entscheidungsträgern sind das Letzte. Sie meinen, trotz aller Warnungen drüberfahren zu können, komme was wolle. Und am Schlimmsten sind diejenigen, die dann noch dazu wenn der Karren gegen die Wand gefahren ist, keine Verantwortung für ihre beschissenen Entscheidungen übernehmen, sondern das auch noch an jenen Mitarbeitern auslassen, die am meisten dafür getan haben dass es doch irgendwie klappt.
Leider ist das fast überall so und ich glaube jeder hat da so seine Geschichte zu erzählen. In Wirklichkeit kann man nur eins tun: Abhaken und weiterschauen. Viel Erfolg.
Ectoplasma
2016-08-08, 17:36:57
Das ist leicht gesagt, aber in welcher (kleinen) Firma wird die Entwicklung (primär) interner Tools mit großem Pflichtenheft etc. aufgezogen?
In gar keiner. Ausserdem höre ich das Wort Pflichtenheft hier zum ersten mal wieder nach gefühlt 20 Jahren. Du wirst kaum eine Firma finden, auch Großkonzerne nicht, die mit einem vollständigen Pflichtenheft nach DIN hantieren. Meist begnügt man sich mit einer Fachspezifkation, in der zumindest enthalten ist, welche Funktionen die Auftragber haben wollen. Dann wird hier und da noch eine Maske eingeklebt und ein bischen was zum Ablauf erklärt. Sehr selten findet man zum Beispiel Aussagen darüber, wie groß das zu erwartende Mengengerüst ist, oder wie schnell Requests abgearbeitet werden sollen. Das ganze wird dann oft als Gewerk zum Festpreis an den oder die Auftragnehmer weiter gereicht. Der macht darauf eine Schätzung mit genügend Risikoaufschlag und fertig ist der Auftrag.
Korfox
2016-08-08, 18:52:43
Im Automotive-Bereich ist es gang und gebe, dass der Zulieferer Doors-Requirements bekommt und die als Pflichtenheft angesehen werden. Von daher gibt es durchaus auch in der Industrie sowas, wie Pflichtenhefte...
Haarmann
2016-08-09, 09:02:23
Dann kommt mir der Ami in den Sinn, der nach 3 Monaten ne neue Brücke fertigstellt...
Der Deutsche wird nach 3 Jahren nichtmals den Papierkrieg beendet haben.
Und am Ende gibts dann wieder sowas wie BER.
Dort war auch das "UI" wichtiger, denn die Funktion - das habe ich damals ganz klar den Leuten gesagt - das UI passen wir erst an, wenn die Funktionalität abgenommen ist.
Da man das UI per HTML Editor anpassen konnte... war das dann recht schnell gemacht.
Wohl das letzte IT Projekt in der Schweiz vom Staat das Zeit- und Budgetgerecht abgeschlossen wurde ;).
Ectoplasma
2016-08-09, 09:32:29
Da man das UI per HTML Editor anpassen konnte... war das dann recht schnell gemacht.
Und da wären wir auch schon mitten in einem eigenen Thema. Die UI ist eigentlich immer ein eigenständiges Thema. Die will heutzutage Fancy aussehen und hat dann meist auch tonnenweise Javascript in sich. Vergiss dabei gleich mal den HTML Editor, der bringt bei sowas gar nichts. Die eigentlichen Funktionen dahinter (Business Layer), sind meist wesentlich einfacher zu implementieren.
Einfachheit und ansprechendes Design sind kein Widerspruch. Ohne die Form, wäre die Funktion nur halb so beliebt.
Er hat trotzdem nicht unrecht. Es ist einfach unglaublich, wie oft man heute noch cobol und Co. vorfindet. Es läuft einfach und keiner traut es sich mehr anzufassen, man redet nicht umsonst von historisch gewachsenen Altlasten, und hier macht der Begriff monolitisch auch anschaulich mal Sinn.
Na ja, für seine Zwecke ist Cobol nach wie vor noch in vielen Bereichen anderen Programmiersprachen überlegen. Und ich bin bestimmt einer der wenigen hier, die auch in Cobol jahrelang programmiert haben. ;)
Am Ende ist ja auch keinem geholfen, wenn man das Pflichtenheft Wort für Wort genau nach Zeitplan erfüllt hat, aber der Kunde damit nichts anfangen kann.
Sorry, dann stimmt aber was mit der Kommunikation überhaupt nicht. Ein Pflichtenheft wird normalerweise in Absprache mit dem Kunden und dessen Fachabteilungen erstellt und auch entsprechend rereviewed und entsprechend abgesegnet. Ich mache das seid vielen Jahren so, und hatte diesbezüglich bisher keine Probleme, ganz im Gegenteil.
Und da wären wir auch schon mitten in einem eigenen Thema. Die UI ist eigentlich immer ein eigenständiges Thema. Die will heutzutage Fancy aussehen und hat dann meist auch tonnenweise Javascript in sich. Vergiss dabei gleich mal den HTML Editor, der bringt bei sowas gar nichts. Die eigentlichen Funktionen dahinter (Business Layer), sind meist wesentlich einfacher zu implementieren.
Dem kann ich nur zustimmen. Beim letzten Projekt (bei dem auch kein wirkliches Pflichtheft vorlag.....trotz börsennotierten Millionenunternehmen auf beiden Seiten -> dafür aber viel viel viel Politik im Spiel) benötigten der Business Layer zwei Wochen zur Fertigstellung (und der wurde auch nie mehr angefasst danach).....das GUI 6 Monate. Was zum größten Teil eben daran lag, das möglichst viel "Fancy" rein sollte mit Änderungswünschen im Tagestakt.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.