» »

Berufsleben: Wie viel interne Sabotage ist/findet ihr "normal"?

Syoro'mxan


Kommunizieren würde ich gerne, allerdings passiert das zur Zeit nur, wenn Zwang von oben ausgeübt wird.

Ich kann mir nicht vorstellen, dass ihr so strenge innerbetriebliche Vogaben an die Kommunikation habt. Was hindert dich, selbst auf andere zuzugehen? Oder lehnen die deine Kommunikationsversuche ab, wenn sie nicht "von oben" diszipliniert werden?

Ich empfinde das Benennen vom Missständen nicht als destruktiv - die Ansichten variieren hier aber natürlicherweise je nach Rollenverteilung.

Ich auch nicht. Aber sie sollte konstruktiv sein und im Ermessen desjenigen liegen, der die Entscheidung trifft. Sonst hat er zwar eine Handlungsempfehlung, aber kann sie dieser nicht folgen.

Zumal ich durchaus Lösungsvorschläge anbiete. Da sich diese Lösungen aber auf reale Probleme beziehen sind sie meist komplizierter als die ursprünglichen pseudosachlichen Darstellungen, die sich zunächst so überzeugend angehört haben.

Ich kenne das gut.

Auch ich wurde schon dafür kritisiert, Sachverhalte schlecht managementtauglich zusammenfassen zu können. Meiner Argumentation, dass dies in einem technologieorienteierten Umfeld halt schwer ist, weil es viele kleine Abhängigkeiten und Sprungfunktionen gibt, wurde nicht gefolgt.

Wir haben dann so Entscheiderfolien-Templates vorbereiten müssen, aber wer wirklich danach entscheiden will, ist IMHO eh verloren. Wofür ich Verständnis habe: das Management MUSS zwnagsweise eine andere Abstraktionsebene haben als die technologischen Mitarbeiter.

Ich bin ein Mensch, der gern und oft abstrakt denkt. Was sich für das Management oft lohnt (und oft die Sache vereinfacht), ist eine Zusammenfassung in Geldbeträgen und Zeit. Das sind die Universalgrößen, mit der klassische BWLer und Controller gut umgehen können. Dass es aber schwierig ist, technische Sachverhalte in Geld und Zeit abzubilden (Vorteile als Geld, Risiken als Geld, Einsparungen als Geld, Chancen als Geld, Fertigstellungstermine, Beginntermine, Meilensteine) bzw. unterschiedliche Ableitungsmethoden gibt, lässt sich das nicht eindeutig abbilden. Und so macht dann doch wieder jeder seine Rechnung. Was das Management dann noch mehr verwirrt, denn die glaubten ja an eine schlüssige, konsistente, "abgestimmte", neutrale Darstellung.

PS: Nicht-Optimalität muss nicht zwangsläufig als Sabotage zählen. Und selbst Optimalität ist abhängig von der konkreten Gestaltung der Zielfunktion und der einzuhaltenden Nebenbedingungen.

Meine Lehre aus dem ganzen ist, dass ich mich mehr auf technische Sachverhalte konzentriere. Der Managementanteil macht mir eh keinen Spaß. Das sollen gern andere machen. Die sollen ruhig Karriere machen, mit den Mios um sich werfen (verbal), in Headcounts und Budgets denken, strategische Planung machen und sich in Luftschlössern verlieren. Ist schlicht nicht meine Baustelle. Mit dem Ansatz geht es mir deutlich besser.

rNatsxch


Ich kann mir nicht vorstellen, dass ihr so strenge innerbetriebliche Vorgaben an die Kommunikation habt.

Kommunikation ist in der Tat sehr gewünscht und wird zu fördern versucht (hauptsächlich per gesponsortem Alkohol...)

Oder lehnen die deine Kommunikationsversuche ab, wenn sie nicht "von oben" diszipliniert werden?

Ja leider.

Wir haben dann so Entscheiderfolien-Templates vorbereiten müssen, aber wer wirklich danach entscheiden will, ist IMHO eh verloren.

Kann ich mir sehr gut bildlich vorstellen. ;-D

Wofür ich Verständnis habe: das Management MUSS zwangsweise eine andere Abstraktionsebene haben als die technologischen Mitarbeiter

Und da gerate ich wahrscheinlich immer wieder mit dem Management aneinander - ich bin der einzige in der Firma, der jeden technischen Aspekt unserer Arbeit versteht. Trotzdem bin ich aber auch der Meinung, auf dieser Basis fundierte Hilfe bei Entscheidungen auf abstrakterer Ebene anbieten zu können - wo sich andere dann gerne mal im Abseits fühlen, die dann nur noch mit irgendwelchen Gemeinplätzen um sich schmeissen.

Was sich für das Management oft lohnt (und oft die Sache vereinfacht), ist eine Zusammenfassung in Geldbeträgen und Zeit. Das sind die Universalgrößen, mit der klassische BWLer und Controller gut umgehen können.

Ja, das ist mir auch schon öfter geraten worden.

Genauso wie wir immer wieder bei den verwendeten Zeiteinheiten aneinandergeraten: Wenn ich schätze, dass etwas zwei Mannwochen dauert, dann bedeutet dies für mich, dass ich zwei Wochen ausschließlich daran zu arbeiten habe. Das Management fasst es aber regelmäßig so auf, dass die Resultate in zwei Wochen vorliegen werden, neben meiner (meist bereits die komplette Arbeitszeit einnehmenden) sonstigen Tätigkeiten.

Dass es aber schwierig ist, technische Sachverhalte in Geld und Zeit abzubilden (Vorteile als Geld, Risiken als Geld, Einsparungen als Geld, Chancen als Geld, Fertigstellungstermine, Beginntermine, Meilensteine) bzw. unterschiedliche Ableitungsmethoden gibt, lässt sich das nicht eindeutig abbilden. Und so macht dann doch wieder jeder seine Rechnung. Was das Management dann noch mehr verwirrt, denn die glaubten ja an eine schlüssige, konsistente, "abgestimmte", neutrale Darstellung.

Volle Zustimmung.

PS: Nicht-Optimalität muss nicht zwangsläufig als Sabotage zählen. Und selbst Optimalität ist abhängig von der konkreten Gestaltung der Zielfunktion und der einzuhaltenden Nebenbedingungen.

Schon richtig, und auch sicherlich die Ursache mancher Dinge, die mich auf die Palme bringen aber von anderen einfach als Optimum bezüglich Arbeitseinsatz-Minimierung angesehen. Besonders beliebte Beispiele: Fehlersuche, Testen und Bugfixes werden gerne als vergeudete Zeit angesehen - während ich umgekehrt das arbeiten mit fehlerhafter Software für Verschwendung halte.

Meine Lehre aus dem ganzen ist, dass ich mich mehr auf technische Sachverhalte konzentriere. Der Managementanteil macht mir eh keinen Spaß. Das sollen gern andere machen. Die sollen ruhig Karriere machen, mit den Mios um sich werfen (verbal), in Headcounts und Budgets denken, strategische Planung machen und sich in Luftschlössern verlieren. Ist schlicht nicht meine Baustelle. Mit dem Ansatz geht es mir deutlich besser.

So groß ist unsere Firma dann doch noch nicht, dass ich das als Option für mich sehen würde. Mir bringt Management zwar auch viel weniger Spaß als das Feilen an der Technik. Wenn ich aber sehe, wie wir Geld völlig unnütz zum Fenster rauswerfen oder wie sich unsere Verkaufskampagnen Monate-, manchmal Jahrelang hinziehen, weil die Kunden seiner zahlreichen Fehler von unserem Produkts nicht richtig überzeugt sind, dann kann ich nicht einfach wegschauen.

Genau deswegen bin ich nämlich ursprünglich in die Firma gekommen - weil ich gesehen habe, dass es technisch nicht richtig läuft und sich viel besser machen ließe. Klar, dass man dabei einigen Leuten auf die Füße tritt. Obwohl ich generell zu den meisten trotzdem einen guten Draht habe. Die meisten freuen sich, wenn wir etwas zusammen besser machen können. Aber zwei sind eben dabei, die das in ihrem Ego kränkt und/oder die negative Auswirkungen auf ihre Karriere befürchten (ich vermute beides, mit hauptsächlichem Gewicht auf dem Ego).

Mir geht es zwar noch nicht richtig gut. Aber wie eingangs erwähnt habe ich ja (zunehmend) Unterstützung von ganz oben. Gerade in den letzten Tagen mehr, als ich jemals erwartet hätte. Allerdings sehe ich den obersten Chef halt nur alle paar Wochen einmal, während ich mit den besagten Kollegen jeden Tag umgehen muss.
Außerdem sehe ich noch keinen Weg, wie die beiden aus der Sache herauskommen können und dabei auch nur halbwegs ihr Gesicht wahren. Nachdem ich inzwischen die nötige Unterstützung habe dürfte dort jetzt das Hauptproblem liegen.

r%atsxch


Ups, hätte ich doch mal lieber Korrektur lesen sollen: "monate-, manchmal jahrelang" natürlich.

L?oMlCaX5


Berufsleben: Wie viel interne Sabotage ist/findet ihr "normal"?

Wahrscheinlich läuft diesbezüglich deutlich mehr, als man sich als braver Nicht-Sabotierer so vorstellt. ":/ Für häufiger halte ich allerdings Fehler/Unfähigkeit mit anschließenden Vertuschungsversuchen.

Fehlersuche, Testen und Bugfixes werden gerne als vergeudete Zeit angesehen - während ich umgekehrt das arbeiten mit fehlerhafter Software für Verschwendung halte.

Da wird es wohl darum gehen, einen gesunden Mittelweg zu finden. Wenn man testet bis jeder Bug und Fehler beseitigt ist, würde die Software wahrscheinlich nie auf den Markt kommen. ;-) Und gar nicht oder zu wenig zu testen wäre wohl auch eher unklug.

SKoromxan


Kommunikation ist in der Tat sehr gewünscht und wird zu fördern versucht (hauptsächlich per gesponsortem Alkohol...)

Da ist wohl eher das persönliche Kennenlernen gemeint. Denn Sommeliere oder Brauer seid ihr ja nicht.

Oder lehnen die deine Kommunikationsversuche ab, wenn sie nicht "von oben" diszipliniert werden?

Ja leider.

Dann ist aber schon viel Porzellan zerbrochen.

Genauso wie wir immer wieder bei den verwendeten Zeiteinheiten aneinandergeraten: Wenn ich schätze, dass etwas zwei Mannwochen dauert, dann bedeutet dies für mich, dass ich zwei Wochen ausschließlich daran zu arbeiten habe.

Zwei Mannwochen ist keine Angabe für eine Zeitdauer, sondern für einen Aufwand.

10 Männer, 2 Tage = 2 Mannwochen (20 Manntage) - bei einer 5 Tage Woche

1 Mann, 2 Wochen = 2 Mannwochen (20 Manntage)

Auch Personentage genannt, oder "Full Time Equivalents" (FTE). Der letzte Begriff macht den Vollzeitaspekt deutlich.

Das Management fasst es aber regelmäßig so auf, dass die Resultate in zwei Wochen vorliegen werden, neben meiner (meist bereits die komplette Arbeitszeit einnehmenden) sonstigen Tätigkeiten.

Dann liegt es an die, das deutlich zu machen. Und abzustimmen: wer übernimmt dann in der Zeit meine anderen Aufgaben?

Besonders beliebte Beispiele: Fehlersuche, Testen und Bugfixes werden gerne als vergeudete Zeit angesehen - während ich umgekehrt das Arbeiten mit fehlerhafter Software für Verschwendung halte.

Drücke es in Geld und Zeit aus. ;-)

Und: Testen kann richtig viel Gelf kosten. Aber als Testautomatisierung mit Unit Tests und Test Cases auch mit sehr wenig Aufwand auch enorme Aufwände sparen. Falls ihr also Software entwickelt: Testautomatisierung ist Bestandteil professioneller Sw-Entwicklung.

Mir bringt Management zwar auch viel weniger Spaß als das Feilen an der Technik. Wenn ich aber sehe, wie wir Geld völlig unnütz zum Fenster rauswerfen oder wie sich unsere Verkaufskampagnen Monate-, manchmal Jahrelang hinziehen, weil die Kunden seiner zahlreichen Fehler von unserem Produkts nicht richtig überzeugt sind, dann kann ich nicht einfach wegschauen.

Musst du ja auch nicht. Aber du kannst das auf der technischen Ebene angehen.

Und während das Management noch über alles mögliche diskutiert, legst du einen Unit Test über die wichtigsten Module, schreibst Test Cases mit erwarteten Resultaten, richtest einen Cron-Job ein, der das nächtlich auf dem nightly build durchtestet (reale Ergebnisse mit erwarteten vergleicht) und die Ergebnisse bei Auffälligkeiten an die Entwickler schickt. Das lässt du dann mal 2-4 Wochen laufen, einige Entwickler gewöhnen sich dran, merken wieviel Arbeit das spart und wie sehr es ihre Arbeit verbessert. Dann fasst du das Zwischenergebnis mit Zahlen zusammen (Fixed Bugs über die Zeit), und erbittest vom Management zwei Sachen:

* Budget für Testautomatisierung (z.B. Software)

* Budget für Mitarbeiter-Schulungen in sinnvolle Testcases schreiben, Unit Tests schreiben, Ausgabe des Test-Systems richtig interpretieren

Und vorrechnen, dass es sich aus der Arbeitsersparnis finanziert.

Und weitere Maßnahme: du richtest ein Fehlermelde-Formular ein. Entweder zum Ausfüllen für den Kunden oder euren Support. Oder aber als Fehlermelde-Komponente in der Software, die der Kunde aktivieren kann. Vorstellung fürs Management, Freischaltung nach Freigabe. Sorgt für eine strukturierte Erfassung der Fehlermeldungen, die dann auch auswertbar ist. Die Zuordnung der Fehlermeldungen zu den betroffenen Modulen weist dann die Richtung, wo noch mehr Test Cases für die Testautomatisierung her müssen.

Dritte Maßnahme: Abstimmung des Release-Managements intern. Also Vorgaben: welches Ergebnis der Testautomatisierung brauchen wir, bevor wir ein Release freigeben? Das ist ein Prozessthema. Aber hat mit einem Testberichtswesen auch eine technische Ebene. Also gibt es eine Web-App, die die Test-Ergebnisse managementtauglich in Kennzahlen aufbereitet. Die muss man wieder erstmal bauen.

Vierte Maßnahme: Update-Automatisierung. Denn die Patches/Updates müssen ja dann auch zu den Kunden.

So bekommt man ein organisatorisches/Vertriebsproblem auf die technische Ebene. Mehr programmieren, weniger rumlabern in Meetings. :-) Aber natürlich konkurriert man weiterhin um die Arbeitsressourcen. Wenn andere denken: wir brauchen keine Tests, sondern müssen Features, Features, Features bauen, dann zeig, wie das zusammenpasst. Und dass die neuen Features ja gerade von den Tests profitieren.

rjatjsch


Hallo Lola! *:)

Wahrscheinlich läuft diesbezüglich deutlich mehr, als man sich als braver Nicht-Sabotierer so vorstellt. ":/

Ja leider.

Für häufiger halte ich allerdings Fehler/Unfähigkeit mit anschließenden Vertuschungsversuchen.

Die gibt es natürlich auch noch, und nicht zu knapp. Aber das stört mich weit weniger, solange es in Ordnung gebracht werden kann.

Soroman:

Entschuldige bitte, wenn ich dich mit der Software auf die falsche Fährte geschickt habe - wir sind kein Softwareunternehmen. Allerdings spielt Software heutzutage wohl in beinahe jedem Technologiebereich eine Rolle.

Dann ist aber schon viel Porzellan zerbrochen.

Ja leider. Ich hätte diese Firma eigentlich schon lange verlassen müssen. Aber es fällt mir schwer, sie so fallen zu lassen - zumal ich dem (Haupt)-Inhaber das Gegenteil versprochen habe und er mich ja auch "uneingeschränkt" unterstützt.

Auch Personentage genannt, oder "Full Time Equivalents" (FTE).

Ja, davon reden wir. Entschuldige bitte die laxe Übersetzung uns Deutsche.


Gestern in der Mittagspause spricht mich mein Kollege unter vier Augen an: Ob ich denn gar nicht bemerken würde, dass Kollege Xyz versucht, unsere Arbeit zu untergraben, wo er nur kann. Er hat dabei einen interessanten Aspekt angesprochen, der mir zwar bewusst war, aber den ich hier noch nicht erwähnt und auch generell etwas vernachlässigt habe: Dass mein direkter Chef offensichtlich Angst vor Kollege Xyz hat, obwohl er genauso auch dessen Chef ist. Was natürlich der Grund ist, weshalb mein Chef sich weigert, mit mir zu reden.

Wollen Sie selber etwas dazu schreiben?

Dann melden Sie sich an bzw. lassen Sie sich jetzt registrieren, das ist kostenlos und innerhalb weniger Minuten erledigt. Interessant sind sicher auch die übrigen Diskussionen des Forums Beruf, Alltag und Umwelt oder aber Sie besuchen eines der anderen Unterforen:

Allergien · Zahnmedizin


Nicht angemeldet: Anmelden | Registrieren | Zugangsdaten vergessen? | Hilfe

Startseite | Impressum | Nutzungsbedingungen | Netiquette | Datenschutz | Mobile Ansicht   © med1 Online Service GmbH