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.
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.
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.
