Hab mal ne blöde Frage. Nicht zum ersten Mal macht mir der Kollege die Kommentierung nicht fertig. Ist ca. 2 Stunden Arbeit, ein richtiger Endtermin existiert so nicht. Der steht ca. 3 Jahre vor der Rente, das Verhältnis ist an sich ganz gut. Mehrmalige Nachfragen bisher ohne Erfolg (6 Wochen lang). Bin Externer, der Gruppenleiter hat andere Sorgen (er hält fast keinen Termin ein). Ich weiss doch wie es ist, hinterher heißt es nur, Du hast zu wenig Output gebracht (geliefert). Gruppenmeetings gibt's nicht (bzw. eins kurz nach Nikolaus). Ach so das ist ein bundeseigenes Unternehmen (Energie). Also was ist zu tun?
Dokumentenhistorie/Versionierung einfügen. Z.B. v0.x / 1. Aug. 2016 - Doku zur Kommentierung bereitgestellt v0.x / 15. Sept- 2016 - Kommentierte Version zurückerhalten v1.0 / 16. Sept- 2016 - Korrigierte Version auf Basis Kommentierung v. Herr XY Dann ist zumindest klar wer was wie lange gemacht hat...
Wer ist derjenige, der die Bezahlung Deiner Rechnung freigibt? Denjenigen musst Du davon vorzugsweise schriftlich in Kenntnis setzen, dass Du bei der Durchführung Deiner Arbeiten behindert wirst und daraus ein Projektverzug droht. So etwas solltest Du als reine Feststellung formulieren und nicht als Drohung Deinerseits. Du solltest aber auf keinen Fall Dir selbst ins Knie schießen und behaupten, dass Du ohne die Kommentierung nicht weiterarbeiten könntest! Denn solch eine Aussage würde bedeuten, dass Dich Dein Kunde für die Zeit bis zur Zustellung der Kommentierung nicht bezahlen müsste, denn schließlich kündigst Du ja selbst Deine Untätigkeit an. Man muss bei so etwas ggf. ganz formell vorgehen. Es kommt nicht darauf an, dass Du üblicherweise Deinem Gruppenleiter den Stundenzettel oder die Rechnung in die Hand drückst, sondern wer der Kostenstellenverantwortliche ist. Wessen Unterschrift steht auf der Beauftragung? Falls jedoch nicht Du, sondern ein Projektvermittler o.ä. der Vertragspartner des Kunden sein sollte, solltest Du mit ihm diesbezüglich Rücksprache halten. Er wird wesentlich genauer wissen, welches die relevanten Entscheidungsträger sind. In keinem Fall solltest Du aber davon ausgehen, dass Du die Kommentierung zügiger erhalten wirst, sondern es geht bei den obigen Maßnahmen ausschließlich darum, ggf. gerichtsfest nachzuweisen, dass Du drohenden Verzug den Verantwortlichen gemeldet hast, um eine Schadensbegrenzung für den Kunden zu vermeiden und sowohl Deine Honorarforderung abzusichern und eine Schadensersatzforderung Deines Kunden zu vermeiden.
:
Bearbeitet durch User
Ein Verzicht der Kommentierung bedeutet doch : Angenommen !
Oh D. schrieb: > Ein Verzicht der Kommentierung bedeutet doch : Angenommen ! Das bedeutet es keineswegs. Zum einen kann es durchaus die Anweisung eines Entscheidungsträgers gegeben haben, dass die Spezifikation nur nach erfolgter Kommentierung verwendet werden dürfe, und zum anderen muss der TE ggf. auf den Verzug hinweisen. Sofern also nicht ausdrücklich vereinbart wurde, dass er auf der nicht-kommentierten Version arbeiten dürfe, sieht es für ihn schlecht aus. Und wie schon angedeutet, kann es im Extremfall sogar bedeuten, dass seine Arbeit nicht abgenommen bzw. bezahlt wird.
Um was für ein Dokument geht es überhaupt? Wieso bist Du als Externer für Inhalte zuständig? Normal wäre, dass man Dir sagt, wann was fertig zu sein hat und was es zu tun gibt und da ist der Verzug durch einen Internen nicht Dein Problem. So eine komische Verstrickung darf es bei Externen gar nicht geben, weil Du eine abgegrenzte Arbeit abliefern (können) musst! Der Herr ist also auch nicht Dein Kollege! Ansonsten gibt es das nur, wenn Du ein externer Projektleiter bist und dann machst Du die Termine!
externer Projektleiter schrieb: > So eine komische Verstrickung darf es bei Externen gar nicht geben, weil > Du eine abgegrenzte Arbeit abliefern (können) musst! Das gilt nur bei Werkverträgen, nicht aber bei Arbeitnehmerüberlassung.
Danilo schrieb: > Hab mal ne blöde Frage. > > Nicht zum ersten Mal macht mir der Kollege die Kommentierung nicht > fertig. > > Ist ca. 2 Stunden Arbeit, ein richtiger Endtermin existiert so nicht. Vielleicht - ist der Entwurf inhaltlich so unsagbarer Mist, dass es das erfahrene Projektmitglied schon bei dem Gedanken daran ihn lesen zu müssen graut? - ist das Dokument schlecht lesbar, unverständlich, verschwurbelt-angeberisch gechrieben, mit Berater-BWL-Sprech aufgepimpt und in Neusprech-Zuckerguss vepackt? - ist die Schätzung von zwei Stunden Arbeit maßlos untertrieben? - hat besagtes Projektmitglied keine Lust mittels der Kommentare den Entwurf gerade zu ziehen und damit deine Arbeit zu machen? - hat er schlicht und ergreifend Aufgaben höherer Priorität und keine Lust wegen dem Entwurf noch 2 + x Überstunden dran zu hängen? - hat er keine Lust auf die absehbar folgende endlose, sinnlose und fruchtlose Diskussion über seine Kommentare? - sagt ihm seine Erfahrung, dass dein ganzes Projekt eine Luftnummer irgendwelcher Wichtigmacher ist? - war das mal sein Projekt oder seine Idee, die man ihm weggenommen hat und die du jetzt an die Wand fährst? > Also was ist zu tun? Aktennotiz und ohne Kommentare weitermachen. Sollten die Kommentare laut Prozess / Vorgehensmodell Pflicht sein dann formal eine Ausnahme beantragen um ohne Kommentare weitermachen zu dürfen.
Danilo schrieb: > Also was ist zu tun? Den Kameraden mal kräftig aufn Pott setzen, scheiss auf sein Alter... Leider erlebt man immer häufiger, dass sich ältere Kollegen kurz vor der Rente quer stellen um ihre Wichtigkeit zu demonstrieren. Oft sind aber gerade diese Leute in der Weiterbildung vor 10-15 Jahren stehengeblieben und um das zu vertuschen machen sie sich unnötig wichtig.
Ingo Less schrub: > Den Kameraden mal kräftig aufn Pott setzen, scheiss auf sein Alter... > Leider erlebt man immer häufiger, dass sich ältere Kollegen kurz vor der > Rente quer stellen um ihre Wichtigkeit zu demonstrieren. Oft sind aber > gerade diese Leute in der Weiterbildung vor 10-15 Jahren stehengeblieben > und um das zu vertuschen machen sie sich unnötig wichtig. Auch du wirst mal alt sein, vergiss das nicht!
Ingo Less schrieb: > Danilo schrieb: >> Also was ist zu tun? > Den Kameraden mal kräftig aufn Pott setzen, scheiss auf sein Alter... Ist er derjenige, der den Leistungsnachweis unterschreibt? Nein? Dann ist er nicht der richtige Ansprechpartner.
Ingo Less schrieb: > Den Kameraden mal kräftig aufn Pott setzen, scheiss auf sein Alter... > Leider erlebt man immer häufiger, "Man erlebt"? Und "häufig"? Glaube ich dir nicht. Das klingt mehr nach der Wiederholung von Standardsprüchen denen keine eigene Erfahrung zugrunde liegt. > dass sich ältere Kollegen kurz vor der > Rente quer stellen um ihre Wichtigkeit zu demonstrieren. Gerade erfahrene Kollegen haben es nicht nötig ihre Wichtigkeit zu demonstrieren. Normalerweise sind es die prallen Jungspunde die sich aufführen als wären sie Gottes Geschenk an die Ingenieurskunst.
Jack schrieb: > Vielleicht > > 1) ist der Entwurf inhaltlich so unsagbarer Mist, dass es das erfahrene > Projektmitglied schon bei dem Gedanken daran ihn lesen zu müssen graut? > > 2) ist das Dokument schlecht lesbar, unverständlich, > verschwurbelt-angeberisch gechrieben, mit Berater-BWL-Sprech aufgepimpt > und in Neusprech-Zuckerguss vepackt? > > 3) ist die Schätzung von zwei Stunden Arbeit maßlos untertrieben? > > 4) hat besagtes Projektmitglied keine Lust mittels der Kommentare den > Entwurf gerade zu ziehen und damit deine Arbeit zu machen? > > 5) hat er schlicht und ergreifend Aufgaben höherer Priorität und keine > Lust wegen dem Entwurf noch 2 + x Überstunden dran zu hängen? > > 6) hat er keine Lust auf die absehbar folgende endlose, sinnlose und > fruchtlose Diskussion über seine Kommentare? > > 7) sagt ihm seine Erfahrung, dass dein ganzes Projekt eine Luftnummer > irgendwelcher Wichtigmacher ist? > > 8) war das mal sein Projekt oder seine Idee, die man ihm weggenommen hat > und die du jetzt an die Wand fährst? Sehr gute Anmerkungen Deinerseits. Antworten wie folgt: 1) Entwurf inhaltlich so unsagbarer Mist: Nö Dokument ist Klasse, jedenfalls mind. so gut wie das meiste was da bisher so fabriziert wurde! 2) Dokument ist inhaltlich fast genauso wie einige der Unterlagen die der "Kommentierende" früher selbst erstellt hat (techn. Beschreibung, Selektivitätsnachweis, Materialliste, Prüfprotokolle, Schaltpläne im Änderungsmodus, usw..) zu 3) zwei Stunden Arbeit maßlos untertrieben Kann auch etwas mehr sein. Ist aber irgendwie ein Standard-Kleinprojekt (wo derjenige schon mind. 50 Stück so abgewickelt hat) zu 4) besagtes Projektmitglied hat keine Lust: gut möglich, glaube aber fast eher, dass da firmenintern einer die Bremse reingedrückt hat weil ich doch etwas zu viel guten Output gebracht habe (ohne Quatsch). Das gefällt den wenigsten wenn ein externer kommt und den Spiegel aufstellt und die Transparenz über die "Leistung" vieler Interner herstellt! zu 5) Aufgaben höherer Priorität: Kann sein, dass er die hat, ich weiß aber nicht was andere machen da keine Gruppenmeetings 7) ist keine Luftnummer sondern nur ein Planungs-Dokument welches für die Gruppe ein recht wichtiger Output sein könnte (weil es ähnlich in Zukunft wieder genutzt werden könnte für ähnliche Projekte) zu 8) war das mal sein Projekt?: ja das gehört zu seinem früheren Aufgabengebiet
Danilo schrieb: > glaube aber fast eher, dass da firmenintern einer die Bremse > reingedrückt hat weil ich doch etwas zu viel guten Output gebracht habe > (ohne Quatsch). Bundeseigenes Unternehmen, älterer Mitarbeiter, Du kommst als externe Heißdüse rein und versaust den Akkord. Ja, damit macht man sich auf Arbeitsebene nicht beliebt. Andererseits kommt es beim Chef nicht gut an, wenn man genauso bummelt wie der durchschnittliche Festangestellte. Strategisch wählt man da einen Kompromiß und positioniert sich im oberen Drittel, aber nicht als Überflieger. Dann ist der Chef zufrieden, aber man eckt auf Arbeitsebene nicht an.
Dokuentwurf kommentieren? Wie hat man vor ein paar Jahren noch ohne einen solchen Schwachsinn arbeiten können? Ach Halt! Da hat man ja wirklich arbeiten müssen und nicht die Produktion von Papierbergen als Arbeit bezeichnet. SCNR
идиотендетектор schrieb: > Da hat man ja wirklich arbeiten müssen > und nicht die Produktion von Papierbergen als Arbeit bezeichnet. Da hat man schlichtweg überhaupt keine Doku gemacht, und wenn der ursprüngliche Hacker weg war, dann wurde der Einbau von selbst trivialen neuen Features sauteuer. Man hat auch kein Design gemacht und das erstmal einem Review unterzogen, sondern gleich mal drauflosgehackt. Damit war man ja viel produktiver. Gut, daß dann eine vierstellige Zahl von Geräten aus dem Feld zurückkam und die Kunden bei den nächsten Preisverhandlungen dann sehr aggressiv verhandelt haben, hat man nicht miteinander in Verbindung gebracht. Jaja, die guten alten Zeiten. Obwohl, alteingesessene Firmen arbeiten heute noch auf diese Weise. Das Ergebnis kann man sich dann z.B. bei BMW connected drive anschauen.
Nop schrieb: > Man hat auch kein Design gemacht und das erstmal einem Review > unterzogen, sondern gleich mal drauflosgehackt. Heutzutage sieht man aber häufig genau das Gegenteil, nämlich teils jahrelange Spezifikationsprozesse, die komplett an der technischen Machbarkeit vorbeigehen. In der Zeit hätte man schon etliche Prototypen zusammenbasteln und daraus wichtige Erkenntnisse gewinnen können. Wer auf Anglizismen steht, kann das als "Rapid Prototyping" bezeichnen. Wichtig sind aber bloß die darauffolgenden Schritte. Wer meint, dass solche Prototypen schon nahezu fertigentwickelte Serienprodukte seien, lügt sich in die eigene Tasche. Wer aber die Erkenntnisse aus dieser RP-Phase akribisch zusammenträgt, hat eine viel bessere Grundlage für die Erstellung der Spezifikationen für das Serienprodukt. Allerdings scheitert die erfolgreiche Umsetzung in manchen Fällen auch daran, dass viele Entwickler nicht bereit sind, Programmcode oder Schaltungen, die sich nicht bewährt haben, einfach in die Tonne zu treten, sondern ihr Leben lang daran hängen. Ggf. muss man da als Projektleiter sehr stringent vorgehen und auch immer wieder kontrollieren, dass nicht hintenherum solche verkorksten Teile wieder eingeführt werden. Auch wenn sich in etlichen Jahrzehnten der Ingenieurskunst immer wieder gezeigt hat, dass reine Top-Down-Entwicklungsmodelle zu komplett unbrauchbaren Produkten geführt haben, sehe ich aber in letzter Zeit eine stärkere Rückkehr zu solchen Prozessen. Dies liegt in vielen Fällen auch an der unglaublichen Arroganz mancher "Systemarchitekten", die sich mit der realen Produktentwicklung nicht die Finger dreckig machen wollen. Gerade Entwicklungsprozesse, in denen Unmengen an Dokumentation produziert werden, sorgen auch dafür, dass in den meisten Fällen genau diese Dokumentation weder in sich konsistent ist noch die Dokumente untereinander. Und die Umsetzung im konkreten Produkt unterscheidet sich dann auch nochmals sehr deutlich von den zuvor angefertigten Spezifikationen.
:
Bearbeitet durch User
Nop schrieb: > Bundeseigenes Unternehmen, älterer Mitarbeiter, Du kommst als externe > Heißdüse rein und versaust den Akkord. Ja, damit macht man sich auf > Arbeitsebene nicht beliebt. Andererseits kommt es beim Chef nicht gut > an, wenn man genauso bummelt wie der durchschnittliche Festangestellte. > > Strategisch wählt man da einen Kompromiß und positioniert sich im oberen > Drittel, aber nicht als Überflieger. Dann ist der Chef zufrieden, aber > man eckt auf Arbeitsebene nicht an. Genauso sieht das aus. Weder die Zeiten kaputtmachen noch bummeln, das ist der richtige Weg. Da aber der Gruppenleiter offenbar in der Kritik steht, weil nix richtig geht strebe ich aber schon an den Schnitt etwas zu anzuheben. Ich denke in 12 Monaten ca. 150 Seiten gute Planungsdokumente machen ist durchaus noch nicht übertrieben. Das sind im Monat 15 Seiten, das muss ein Minimum sein. Immerhin sind das hier auch Steuergelder (bzw. fast nur) die verbraten werden.
Du hast Dich immer noch nicht dazu geäußert, wer für die Abnahme Deiner Lieferungen bzw. Freigabe Deiner Leistungsnachweise zuständig ist. Nur dessen Befindlichkeiten sind relevant.
Andreas S. schrieb: > Heutzutage sieht man aber häufig genau das Gegenteil, nämlich teils > jahrelange Spezifikationsprozesse, die komplett an der technischen > Machbarkeit vorbeigehen. Was im Wesentlichen auf schlechtes Projektmanagement zurückzuführen ist. Namentlich, daß eben keine strukturierte Vorgehensweise da ist, sondern z.T. ganz wesentliche Änderungen zu jedem Zeitpunkt einfließen, wodurch man überhaupt nicht mehr dazu kommt, ein rundes Konzept zu machen. Das wiederum kommt durch Featuritis zustande. Egal, wie unnütz und unbrauchbar ein Feature ist, Hauptsache, man kann im Prospekt damit werben. Wenn die Waschmaschine der Konkurrenz schon einen Webserver und beinhaltet, dann "muß" man natürlich ins eigene Produkt zusätzlich auch noch GPS integrieren. Auch ein hübsches Beispiel für sowas sind transnationale Rüstungsprojekte, wo jeder für seine Armee irgendwelche Sonderwünsche hat und am Ende die eierlegende Wollmilchsau herauskommen soll. Die, oh Wunder, nicht funktioniert. > In der Zeit hätte man schon etliche Prototypen > zusammenbasteln und daraus wichtige Erkenntnisse gewinnen können. Das war früher mal. Inzwischen ist das Problem, daß nennenswerte Neuentwicklung an sich schon sauteuer geworden ist. Außer für Produkte, die man aus vorhandenen Sachen zusammenstoppeln kann, aber das tun die Chinesen dann für 10% des Preises. > Wichtig sind aber bloß die darauffolgenden Schritte. Wer meint, dass > solche Prototypen schon nahezu fertigentwickelte Serienprodukte seien, > lügt sich in die eigene Tasche. Das sag mal Managern. Auch ein Grund, wieso man von Rapid Prototyping abgekommen ist, weil die Entscheider dann unfähig waren, das als Prototypen zu sehen. Mit dem Ergebnis, daß zusammengefrickeltes Zeug in Serie ging. Deswegen ist das heute wieder prozeßlastiger. > Auch wenn sich > in etlichen Jahrzehnten der Ingenieurskunst immer wieder gezeigt hat, > dass reine Top-Down-Entwicklungsmodelle zu komplett unbrauchbaren > Produkten geführt haben, sehe ich aber in letzter Zeit eine stärkere > Rückkehr zu solchen Prozessen. Liegt auch daran, daß die Welt komplexer geworden ist und man dasselbe Produkt nahezu beliebig aufwendig machen kann. Besonders unbeliebt sind versteckte Kostentreiber wie z.B. alles, was mit IT-SIcherheitsaspekten zu tun hat. Die sieht der Nutzer halt nicht direkt, also bezahlt er sie auch nicht gerne. Deswegen kommt am Ende so ein unreifer Mist wie BMW connected drive raus. Oder der Hack, wo sie einen Chrysler während der Fahrt in den Graben geschickt haben, von außen. Derlei wird eben nur korrekt implementiert, wenn es auch so spezifiziert und bezahlt wurde. Das gilt nochmal verschärft, wenn man Teile davon nach Indien auslagert.
Andreas S. schrieb: > Du hast Dich immer noch nicht dazu geäußert, wer für die Abnahme > Deiner > Lieferungen bzw. Freigabe Deiner Leistungsnachweise zuständig ist. Nur > dessen Befindlichkeiten sind relevant. Den Stundenzettel unterschreibt der Gruppenleiter (bei dessen Abwesenheit der AL). Wie gesagt steckt der GL (weil er erst seit 10 Monaten GL ist) noch aktiv in eigenen Projekten drin(die aus dem Ruder laufen terminlich). Er hat da zwar eigene Leute für, steckt aber ganz tief drinne und kann nicht loslassen. Zumind. sehe ich das so. Will ich 10 (oder 15) Leute führen kann der das so nicht mehr machen. Der dürfte nur noch managen.
Andreas S. schrieb: > Auch wenn sich in etlichen Jahrzehnten der Ingenieurskunst immer wieder > gezeigt hat, dass reine Top-Down-Entwicklungsmodelle zu komplett > unbrauchbaren Produkten geführt haben, sehe ich aber in letzter Zeit > eine stärkere Rückkehr zu solchen Prozessen. Das ist die eine Richtung, aber es gibt auch eine Gegenbewegung -- zumindest im Softwareumfeld. Durch die Agile Entwicklung sollen die von Dir so richtig identifizierten Probleme vermieden werden. Softwareentwickler haben im Laufe der Jahrzehnte gelernt, daß man Software nicht im Elfenbeinturm entwerfen kann, daß sich Anforderungen laufend ändern und zum Teil auch erst während des Entwicklungsprozesses erkannt werden können.
Sheeva P. schrieb: > Durch die Agile Entwicklung sollen die von > Dir so richtig identifizierten Probleme vermieden werden. Ja, und das Ergebnis ist, daß die Leute dabei lernen, wieso man überhaupt erst dazu kam, definierte Prozesse einzuführen. Agile Entwicklung kannste bei tendentiell GUI-lastigen Sachen als interaktives Rapid Prototyping machen, aber ansonsten führt das zu völlig vergurkten Systemdesigns, weil keine Planung mehr stattfindet, sondern nur noch Userstories irgendwie kurzfristig ins bestehende System reingefrickelt werden.
Und in vielen Firmen (bei uns auch) wird dann noch versucht dieses agile Konzept auf alles auszubreiten. Das es bei Elektronikentwicklungen ggf. nicht sinnvoll ist sich täglich 10min mit dem gesamten Team zu treffen und zu sagen was man dann in der nächsten Stunde macht leuchtet den Managern nicht so ein. Dabei wird man als Elektronikentwickler doch lieber mal wenigstens eine Woche mit den Spezifikationen alleine gelassen um sich überhaupt mal grobe Ansätze zu überlegen...
Ingo Less schrieb: > Leider erlebt man immer häufiger, dass sich ältere Kollegen kurz vor der > Rente quer stellen um ihre Wichtigkeit zu demonstrieren. Das ist leider wahr. Trauig eigentlich, wenn es soweit kommt. Hat aber auch damit zu tun , dass die von den Firmen irgendwann abserviert wurden. > Oft sind aber gerade diese Leute in der Weiterbildung vor 10-15 Jahren > stehengeblieben ... was daran liegt, dass man Leute über 50 nicht mehr fördert.
Kommunikator schrieb: >> Oft sind aber gerade diese Leute in der Weiterbildung vor 10-15 Jahren >> stehengeblieben > ... was daran liegt, dass man Leute über 50 nicht mehr fördert. Dem muss ich widersprechen. Viele Leute sind der Auffassung, dass sie nach dem Studium keine fachbezogene Weiterbildung mehr betreiben müssen, zumindest nicht aus eigenem Antrieb. Wer dann irgendwann, wenn das Kind in den Brunnen gefallen ist, sich darauf beruft, dass der Arbeitgeber ihn in all den Jahren nicht zu Weiterbildungsmaßnahmen gezwungen habe, ist selbst Schuld. Solche Leute merken auch nicht, dass sich ihre fachlich wesentlich besser aufgestellten Kollegen fortwährend weiterbilden, und zwar nicht (nur) in irgendwelchen verordneten Kursen, sondern im Selbststudium.
Hab auch mal Fast- Rentner in ner IT Abteilung erlebt.. grausam. Machen seit Jahren dasselbe, keine Lust, kein Interesse, keine Weiterbildung. Kommen immer genau um 8, um 17 Uhr Feierabend. Die hatten so ein Schneckentempo, einfachste Sachen oder mal selbst was überlegen, undenkbar. War so ein halber Beamtenladen.
Nop schrieb: > Sheeva P. schrieb: >> Durch die Agile Entwicklung sollen die von >> Dir so richtig identifizierten Probleme vermieden werden. > > Ja, und das Ergebnis ist, daß die Leute dabei lernen, wieso man > überhaupt erst dazu kam, definierte Prozesse einzuführen. Agile > Entwicklung kannste bei tendentiell GUI-lastigen Sachen als interaktives > Rapid Prototyping machen, aber ansonsten führt das zu völlig vergurkten > Systemdesigns, weil keine Planung mehr stattfindet, sondern nur noch > Userstories irgendwie kurzfristig ins bestehende System reingefrickelt > werden. Nach meiner Erfahrung kommen "vergurkte Systemdesigns" meistens davon, daß sich jemand am Anfang der Entwicklung auf ein bestimmtes Design festgelegt hat und daran unbeirrt und stur festhält, obwohl veränderte Anforderungen eigentlich ein Refactoring nötig machen würden. Aber dann sitzt dann unser Systemdesigner da und will a) nicht zugestehen, daß sein Design nicht mehr zur Aufgabenstellung paßt und b) nicht für ein vermeintlich unproduktives, zeitaufwändiges Refactoring verantwortlich sein.
klausi schrieb: > Hab auch mal Fast- Rentner in ner IT Abteilung erlebt.. grausam. Machen > seit Jahren dasselbe, keine Lust, kein Interesse, keine Weiterbildung. > > Kommen immer genau um 8, um 17 Uhr Feierabend. > Die hatten so ein Schneckentempo, einfachste Sachen oder mal selbst was > überlegen, undenkbar. > > War so ein halber Beamtenladen. Genauso sieht das da aus, mit der Ergänzung, dass die Jüngeren nicht viel besser sind. Die Externen (AÜG) sorgen dafür, dass überhaupt noch bisschen was geht. Ich nehme an die Geschäftsführung weiß das aber auch (obwohl die etablierten Führungskräfte das best. anders darstellen). Des Weiteren gehe ich davon aus, dass der Laden mal durchleuchtet wird. Wobei ich auch sicher keiner bin der 130 % bringt (bringen kann). Kann auch sein, dass man da selbst dran krank wird, dann muss man vorher gehen.
@ Danilo (Gast) >> Hab auch mal Fast- Rentner in ner IT Abteilung erlebt.. grausam. Machen >> seit Jahren dasselbe, keine Lust, kein Interesse, keine Weiterbildung. > >> Kommen immer genau um 8, um 17 Uhr Feierabend. >> Die hatten so ein Schneckentempo, einfachste Sachen oder mal selbst was >> überlegen, undenkbar. > >> War so ein halber Beamtenladen. >Genauso sieht das da aus, mit der Ergänzung, dass die Jüngeren nicht >viel besser sind. Die Externen (AÜG) sorgen dafür, dass überhaupt noch >bisschen was geht. Willkommen im VEB! https://de.wikipedia.org/wiki/Volkseigener_Betrieb
Steffen schrieb: > Und in vielen Firmen (bei uns auch) wird dann noch versucht dieses agile > Konzept auf alles auszubreiten. Das es bei Elektronikentwicklungen ggf. > nicht sinnvoll ist sich täglich 10min mit dem gesamten Team zu treffen > und zu sagen was man dann in der nächsten Stunde macht leuchtet den > Managern nicht so ein. Dabei wird man als Elektronikentwickler doch > lieber mal wenigstens eine Woche mit den Spezifikationen alleine > gelassen um sich überhaupt mal grobe Ansätze zu überlegen... Tja, und auch dann ist eine Agile Entwicklung gar keine so schlechte Idee, wie Du sie hier darstellst. Wenn der Elektronikentwickler im Meeting über seine Fortschritte berichtet, können ihn die anderen dabei unterstützen und erfahren gleichzeitig die große Richtung dessen, was auf sie zukommt. Es geht schließlich darum, die Leute aus ihren stillen Kemenaten heraus und ins Gespräch mit einander zu bringen. Letzten Endes geht es bei der Agilen Entwicklung primär um eine bessere Kommunikation zwischen allen Beteiligten, anders gesagt: um eine andere Kultur des Umgangs miteinander und mit der Aufgabe. Die formalen Prozesse sind nicht das Ziel, sondern lediglich ein Hilfsmittel, einen kulturellen Wandel zu erzielen und erfolgreich zu bewältigen. Wenn ich Deine Klage lese, gewinne ich den Eindruck, daß der kulturelle Aspekt bei Euch nicht verstanden wurde oder jedenfalls deutlich zu kurz gekommen ist. Stattdessen scheint es, als seien nur die alten Prozesse gegen neue ausgetauscht worden, ohne daß der Sinn und Zweck dieser neuen Prozesse verstanden worden sind, und ohne daß die neuen Prozesse sinnvoll und zweckgemäß genutzt würden, um ihre Ziele zu erreichen. Sowas passiert leider häufig in Unternehmen mit starken Formalismen, die daran gewöhnt sind, ihre Prozesse von Zeit zu Zeit umzustellen, weil ein Wichtigtuer ein Buch gelesen oder ein Seminar besucht hat. Da werden die Ziele der neuen Prozesse dann nicht verstanden und die Prozesse einfach nur als neue Prozesse installiert, ohne den damit bezweckten kulturellen Wandel zu befördern.
Sheeva P. schrieb: > Tja, und auch dann ist eine Agile Entwicklung gar keine so schlechte > Idee, wie Du sie hier darstellst. Wenn der Elektronikentwickler im > Meeting über seine Fortschritte berichtet, können ihn die anderen dabei > unterstützen Das mag gelten, wenn das Meeting mit anderen Elektronikentwicklern stattfinden würde. Aber hier bei uns sind in einem Team normalerweise nur ein bis zwei Elektronik Entwickler, dazu kommen dann Konstrukteure, Physiker und Softwareentwickler. Wenn der Softwareentwickler mir dann in diesen täglichen Meetings erzählt wie er bestimmte Klassen implementieren möchte kann ich damit genauso wenig anfangen wie er mit meinen aktuellen Berechnungen zur Optimierung des Rauschens als Beispiel. Ich finde da größere Zeiträume mit etwas abstrakter beschriebenen Tätigkeiten sinnvoller. Ich brauche diese täglichen Updates von Mitarbeitern die ein anderes Fachgebiet haben nicht wirklich. Natürlich müssen am Ende alle zusammen wirken, aber die Ebene der Kommunikation muss so gewählt sein, dass man eine gemeinsame Sprache spricht. Tägliche Monologe von jedem bringen kaum etwas, wenn die anderen einem eh nicht folgen können.
Sheeva P. schrieb: > Tja, und auch dann ist eine Agile Entwicklung gar keine > so schlechte Idee, wie Du sie hier darstellst. Ich lese Dein Loblied auf die Agilität mit äußerst gemischten Gefühlen. Ich bin ein großer Freund agiler Methoden, aber man sollte doch wissen, dass sie - so wie überhaupt alle Methoden - nur unter bestimmten Voraussetzungen funktionieren. Agiles Vorgehen eignet sich nur für bestimmte Leute und nur für bestimmte Probleme. Sie sind kein Allheilmittel. > Da werden die Ziele der neuen Prozesse dann nicht verstanden > und die Prozesse einfach nur als neue Prozesse installiert, > ohne den damit bezweckten kulturellen Wandel zu befördern. Ja - und genau das gilt auch für die agilen Methoden selbst. Du kannst Menschen, die sich nicht kulturell wandeln wollen, dazu nicht wirksam zwingen.
Steffen schrieb: > Und in vielen Firmen (bei uns auch) wird dann noch > versucht dieses agile Konzept auf alles auszubreiten. Naja... man kann jede beliebige Methode dadurch in Verruf bringen, dass man sie hartnäckig auf Fälle anwendet, für die sie sich nicht eignet. > Das es bei Elektronikentwicklungen ggf. nicht sinnvoll > st sich täglich 10min mit dem gesamten Team zu treffen > und zu sagen was man dann in der nächsten Stunde macht > leuchtet den Managern nicht so ein. Das kommt auf die Aufgabe und die Firmengröße bzw. die Teamgröße an. Ich habe mal in einer 10-Mann-Bude gearbeitet, die spezielle elektronische Messtechnik gemacht hat. Unser kaufmännischer Chef war brilliant, aber schüchtern; unser technischer Chef war fachlich brauchbar bis sehr gut, aber menschlich SEHR speziell. Wir haben bestimmte Projekte nur deshalb erfolgreich überlebt, weil auf den Druck der Belegschaft hin (!!) wöchentliche (und zeitweise tägliche) Besprechungen gemacht wurden. > Dabei wird man als Elektronikentwickler doch lieber > mal wenigstens eine Woche mit den Spezifikationen > alleine gelassen um sich überhaupt mal grobe Ansätze > zu überlegen... Klar. Der Witz ist, dass sich das überhaupt nicht ausschließt. Je nach Projektphase gab es Zeiten, in denen ich fast wochenlang ungestört arbeiten konnten, und auch solche, in denen ich alle Stunde gezwungen war, neu zu planen.
Nop schrieb: > Ja, und das Ergebnis ist, daß die Leute dabei lernen, wieso > man überhaupt erst dazu kam, definierte Prozesse einzuführen. Die definierten Prozesse hat man, damit ein anderer schuld ist, wenn es am Ende nicht funktioniert. Agile Methoden hat man, damit es am Ende funktioniert. > Agile Entwicklung kannste bei tendentiell GUI-lastigen > Sachen als interaktives Rapid Prototyping machen, Zu enger Fokus: Agile Methoden können sich eignen, wenn kleine Teams komplexe Dinge tun. > aber ansonsten führt das zu völlig vergurkten Systemdesigns, > weil keine Planung mehr stattfindet, Vermutlich einer der folgenschwersten Irrtümer: Agilität macht Planung nicht überflüssig! > sondern nur noch Userstories irgendwie kurzfristig ins > bestehende System reingefrickelt werden. Die Schlüsselworte hier sind "irgendwie" und "reingefrickelt". "Irgendwie reinfrickeln" führt mit jeder Methode zu einem vergurkten System.
Possetitjel schrieb: > "Irgendwie reinfrickeln" führt mit jeder Methode zu einem > vergurkten System. Mitteilung aus dem VEB Vegetarierproduktion: Wer mit Tomaten auf den Augen an einem vergurktem System arbeitet, hat bald den Salat und wird angepflaumt. Da muß man seine Birne mal anstrengen, um auf einen grünen Zweig zu kommen, bevor Gras über die Sache gewachsen ist. Wenn erst etwas im Busche ist, braucht man die Kastanien auch nicht mehr aus dem Feuer zu holen. gez. -Paul- Produktionsleiter
Possetitjel schrieb: > Die definierten Prozesse hat man, damit ein anderer schuld ist, > wenn es am Ende nicht funktioniert. Nein, die hat man, damit es funktioniert. Ich hab es noch jedesmal erlebt, wenn "aus Zeitgründen" die Prozesse mißachtet wurden, daß es am Ende länger dauerte und schlechter wurde. Beispielsweise, weil jemand mit der Codierung schon angefangen hat, obwohl die Spec noch nicht mit dem Kunden gefixt war, sondern nur irgendwelche Memos herumfluteten. Was dann auch beim Testdesign aus derselben Unklarheit zu vergurkten Testfällen führte, die die Fehler ebenfalls nicht aufdecken konnten. > Zu enger Fokus: Agile Methoden können sich eignen, wenn > kleine Teams komplexe Dinge tun. Das ist übrigens der Hauptgrund, wieso die agilen Methoden sich mit der höheren Erfolgsrate schmücken können. Kleine Projekte haben nämlich IMMER eine höhere Erfolgrate als große, weil weniger schiefgehen kann, und Agile Entwicklung pickt sich da die Rosinen der Kleinprojekte raus. Nur, diese kleinen Projekte klappen auch ohne Agilität besser als die großen. > Vermutlich einer der folgenschwersten Irrtümer: Agilität > macht Planung nicht überflüssig! Genau das ist aber die Praxis, weil die Performancebewertung der Mitarbeiter nach implementierten Userstories geht. Wenn man so ein Anreizsystem setzt, wird eben nicht mehr groß geplant. > Die Schlüsselworte hier sind "irgendwie" und "reingefrickelt". Anders geht's aber auch nicht, wenn man Frontup-Design unter den Tisch fallen läßt, und genau das passiert nunmal bei Agiler Entwickung, weil das ja gerade deren Sinn war. Das funktioniert, wenn es um Sachen wie Änderungswünsche geht, bei denen im Grunde nur mal eine kleine Routine oder ein paar Konstanten geändert werden müssen. Die ursprüngliche Kritik seitens der Agilbewegung, daß man an solchen Stellen nun wirklich nicht 8 Wochen Dokumentationsvorlauf machen braucht, ist ja durchaus berechtigt gewesen. Ansonsten kann man die Grundidee agiler Entwicklung auch mit iteriertem Wasserfall kombinieren. Ohne nervige Standup-Labermeetings, bei denen man sich nur wünscht, endlich wieder an die Arbeit gehen zu können. Der Trick ist sehr einfach, mit seinen Kollegen zu REDEN, und zwar sinnvoll. Jede Phase wird nach dem Grundentwurf gemeinsam einen Review unterzogen, damit man den Wasserfall ohne Iteration hinbekommt (die nächste Iteration soll erst beim nächsten Änderungsdurchlauf sein). Sinnigerweise sind dabei nicht nur die Entwickler zugegen, sondern auch die Tester, die auf diese Weise gleich mitbekommen, was sich ändert, und worauf es beim Testen dabei ankommt. Oder die aus praktischer Erfahrung heraus gleich inhaltliche Anregungen machen, weil nämlich Tester die sind, die das System in der Realität sehr gut kennen.
Nop schrieb: > Beispielsweise, weil jemand > mit der Codierung schon angefangen hat, obwohl die Spec noch nicht mit > dem Kunden gefixt war, sondern nur irgendwelche Memos herumfluteten. No Comment.
Falk B. schrieb: >>> War so ein halber Beamtenladen. > >>Genauso sieht das da aus, mit der Ergänzung, dass die Jüngeren nicht >>viel besser sind. Die Externen (AÜG) sorgen dafür, dass überhaupt noch >>bisschen was geht. > > Willkommen im VEB! > > https://de.wikipedia.org/wiki/Volkseigener_Betrieb Nachdem hier im Fred nun die "agile Entwicklung" besprochen wurde ist festzuhalten, dass es hier in der Fa. nix agiles gibt. Man muss alles mal erlebt haben: Es ist hier so wie einst in der TK-Firma als innerhalb von 6 Wochen der Bereichsleiter, der Abt.-Leiter und der Teamleiter abgehauen sind und die Nachfolger nur zu 30 % (und zeitversetzt) da waren. Da gab es auch nix an Führung. Dann muss man halt selbst sehen das Bestmögliche für das Team (und mich selbst) herauszuholen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.