Von Bremsern und Machern

[carstenj]

Hi,

nach ca. 20 Jahren Berufserfahrung in der IT ist mir vor allem eine Sache besonders aufgefallen und mich würde mal interessieren wie es anderen ergeht.

Ich arbeite zurzeit als DBA, davor als System Engineer bzw. Systemadministrator. Dabei bin ich immer bestrebt, soviel wie möglich zu wissen was sowohl meinen Bereich angeht als auch den Bereich drumherum. Als DBA z.B. reicht es nicht die DB zu kennen, sondern man muss eben auch grundlegende Kenntnisse von Betriebssystemen, Storages und Programmierung haben (meiner Meinung nach), weil man sonst nicht effektiv arbeiten kann. Wenn irgendwo ein Fehler auftritt, will ich GENAU wissen warum das passiert, damit das in Zukunft nicht mehr auftritt und anschließend dieses Problem sowie die Lösung irgendwo dokumentiert wird. Unabhängig von der pragmatischen Seite ist es ja auch genau das was mir an dem Job Spaß macht: Fehler finden, Verbesserungen erarbeiten, diese implementieren etc.

Aber oft steht der folgende Satz dem entgegen: "Das ist historisch gewachsen"

Das löst bei mir immer direkt einen Brechreiz aus. Wie oft man irgendwelche Krücken findet, oder schlecht gepflegte Skripte etc. Dokumentationen sind unvollständig oder gar nicht vorhanden. I.d.R. lege ich Wert bei meiner Arbeit auf Dokumentation, damit das auch andere übernehmen können, ich versuche viel zu erklären, weil ich weiss wie schwer es ist sich in eine Umgebung reinzufinden, gerade wenn "Informationhiding" betrieben wird. Ich versuche ständig auf dem Laufenden zu bleiben, Buzzwords zu analysieren und neue Trends zu erkennen und prüfe dabei immer wieder, ob man irgendwas davon einsetzen kann, um den IT-Alltag einfacher, besser, schneller zu gestalten. Das ist auch das, was mich an der IT grundsätzlich reizt. Natürlich muss man auf aufpassen, dass man nicht jeden Trend mitmacht und ständig alles erneuert, aber das soll gar nicht das Thema hier sein.

Aber ständig gibt es Bremser, die überhaupt gar kein Interesse daran haben, die gefühlt nur ihre seit etlichen Jahren ausgeübte Tätigkeit unverändert fortzuführen wollen, selber überhaupt nichts erklären und jegliche Informationen wie Staatsgeheimnisse hüten. Oder Fehler gar nicht analysieren (wollen): Läuft wieder, Thema erledigt. Wenn man nachfragt, bekommt man Infos auch nur Bitweise, was extrem nervig ist. Kommunikation ist oft auch ein großes Problem, entweder hat man 200 Meetings in der Woche die zu gar nichts führen, oder man quatscht nur das Nötigste. Ein effektives Besprechen von Problemen, oder gar mal eine strategische Planung habe ich bisher ganz selten erlebt. Zudem werden häufig keine Entscheidungen getroffen, in manchen Firmen gibts offenbar "Ja" oder "Nein" gar nicht, da heisst es immer wieder mal "Vielleicht", "Lass uns mal ein Meeting machen" etc. Kommt mir das nur so vor, oder hat die Masse der ITler wirklich keinen Bock auf Veränderungen? Und scheinbar wollen auch viele gar nicht mehr Wissen als notwendig. Gerade das Zusammenspiel Admin/Entwickler ist ja oft ein sehr zermürbendes, da fehlt oft Verständnis für die andere Seite.

Wie gesagt, es geht nicht darum irgendwas anders zu machen nur um der Veränderung willen, aber ab und zu mal die eigene Tätigkeit/Infrastruktur überdenken, prüfen ob hier und da ein bisschen was anpassen, schauen ob Tool X,Y oder Z nützlich sein können, ob man Fehler A,B,C nicht durch bessere Planung oder Kommunikation vermeiden könnte, etc. Ich selber würde auch gerne wissen, ob ich das evtl. zu eng sehe und würde auch meine eigenen Gedankengänge überprüfen, daher hoffe ich auf einen interessanten Meinungsaustausch.

[Rabber]

Ich denke, dass ist der normale Gang der Dinge. Für die Meisten ist es ein Job, der erledigt werden muss, weil man dafür Geld bekommt. Die wenigsten machen das aus Spaß und dementsprechend wenig enthusiastisch. Mir fällt dies besonders auf, wenn ich mir den angehenden Nachwuchs anschaue.

Als ich 2001 meine Ausbildung angefangen habe, war es so, dass weite Teile der Azubis echte Nerds waren. Da war IT noch nicht so etabliert wie heute und das hat man dem Publikum auch angemerkt. Diejenigen, welche diesen Beruf ergriffen haben, waren mit Feuer und Flamme bei der Sache. Fachkenntnis und Expertise waren häufig schon vor der Ausbildung gegeben. Neugier ein Dauerzustand. Aber, es waren eben Nerds. Davon konnte man nicht jeden zum Kunden schicken.

Schaue ich die Azubis und Studenten von Heute an, ist davon wenig übrig geblieben. Die Leute könnten so auch bei einer Bank, Versicherung, Industrie oder sonst wo arbeiten. Besseres Auftreten, förmlicher, dafür weniger Begeisterung und Nerdigkeit.

Kurzum: Die IT ist vom Nischen- zum Massenmarkt geworden. Mit allen Vor- und Nachteilen. Ein Nachteil ist z. B., dass viele mit weniger Begeisterung dabei sind als noch vor 20 oder 30 Jahren und das Ganze als bloßen Broterwerb sehen. Das spiegelt sich in der Arbeitshaltung wieder und ist, was Du kritisiert.

Machen wir uns nichts vor: Daran werden weder Du noch ich etwas ändern. Ist wie bei so vielen Szenen, Berufen und Hobbies, wenn sie einem gewissen Stadium entwachsen sind. Die Professionalität steigt, dafür sinkt der Charme der guten, alten Zeit.

[Whiz-zarD]

vor 35 Minuten schrieb Errraddicator:

Schaue ich die Azubis und Studenten von Heute an, ist davon wenig übrig geblieben. Die Leute könnten so auch bei einer Bank, Versicherung, Industrie oder sonst wo arbeiten. Besseres Auftreten, förmlicher, dafür weniger Begeisterung und Nerdigkeit.

Ich arbeite überwiegend mit Entwicklern, die so auf die 50 zugehen und da muss ich feststellen, dass viele doch ihren Antrieb verloren haben (wenn sie ihn jemals besessen haben) und sich auch gar nicht mehr weiterbilden wollen und lieber nur noch das machen wollen, was sie kennen. Da sind dann Spezialisten bei, die meinen, sie seien Schlauer als Microsoft und Oracle und bauen Datenbank-Features nach und verteufeln das yield return in C#, weil der Compiler zusätzlichen IL-Code drumherum baut und Microservices sind ja per Se schlecht, weil ist so aber produzieren fleißig Spaghetticode und von agilen Prozessen braucht man erst gar nicht reden, weil das ja nur Chaos bedeutet. Da bleibt man ja lieber beim Wasserfallmodell und fällt jedes Mal wieder auf die Fresse. Es sind gerade unsere Werksstudenten, die die Nerdigkeit in das Unternehmen bringen. Klar, entsprechen sie nicht mehr dem Klischee eines typischen Nerds. Einer baut in Fitnessstudio seine Muskeln auf und ein anderer läuft Marathons aber das ist nun mal der Wandel der Zeit und ich würde sagen, dass die heutigen Nerds doch aktiver sind, was ihre Freizeitgestaltung angeht und der typische Klischee-Nerd (im dunklen Keller hocken und D&D zocken) verdrängt wird.

[cortez]

vor 1 Stunde schrieb carstenj:

Aber ständig gibt es Bremser, die überhaupt gar kein Interesse daran haben, die gefühlt nur ihre seit etlichen Jahren ausgeübte Tätigkeit unverändert fortzuführen wollen, selber überhaupt nichts erklären und jegliche Informationen wie Staatsgeheimnisse hüten. Oder Fehler gar nicht analysieren (wollen): Läuft wieder, Thema erledigt. Wenn man nachfragt, bekommt man Infos auch nur Bitweise, was extrem nervig ist

Das kenne ich aus eigener Erfahrung nur all zu gut. Bei mir war es allerdings entgegengesetzt zu dem Bild was @Errraddicator gezeichnet hat. Ich durfte als übernommener Azubi mich um die interne Auftragsbearbeitungssoftware kümmern und musste bei Null anfangen, weil nichts dokumentiert war, vor allem keine Schnittstellen zu anderen Programmteilen. 

Der leitende Programmierer mit gut 30 Jahren Berufserfahrung meinte auf meine Fragen nach Dokumentation nur "Gibt's nicht, wenn ich was nachgucken will schaue ich im Quellcode nach."

[maestro impostor]

vor 2 Minuten schrieb cortez:

"Gibt's nicht, wenn ich was nachgucken will schaue ich im Quellcode nach."

Finde ich gar nicht mal so schlecht die Aussage.
Im Gegensatz zur Dokumentation lügt der Code nie

[Whiz-zarD]

vor 4 Minuten schrieb r4phi:

Finde ich gar nicht mal so schlecht die Aussage.
Im Gegensatz zur Dokumentation lügt der Code nie

Ist halt nur schlecht, wenn der Kunde eine Dokumentation haben will, wie z.B. Kennzahlen berechnet werden.

[Rabber]

Was Kommentare und Dokument angeht, hat sich meine Meinung über die Jahre gewandelt. Zu Beginn war ich absoluter Verfechter von Quellcode-Kommentaren und Dokumentation. Je mehr, desto besser. Davon bin ich mittlerweile fast komplett weg.

Es gibt mit Sicherheit die eine oder andere Stelle, wo Dokumentation Sinn macht. Gerade bei komplexer Business-Logik, Seiteneffekten oder unvorhersehbaren Sonderfällen.

Für die meisten Sachen ist es aber tatsächlich so, dass Kommentare nur unnötig aufblähen. Sie sind häufig zu allgemein, veraltet oder unvollständig und bieten so eine gefährliche Form von Halbwissen. Das braucht keiner. Dann lieber einen ordentlich formatierten, benannten und strukturierten Code mit wenig Kommentaren. Den muss man sich zwar erst erschließen, aber mit der Erfahrung erkennt man bestimmte Muster recht zügig wieder und man verlässt sich nicht auf veraltete Aussagen von Dritten, sondern schaut nach, was wirklich Sache ist. Zudem stärkt es das Verständnis als Fachkraft ungemein, wenn man sich regelmäßig bestehenden Code aneignen muss, was wiederum in besserem Code enden kann, da man nicht den faulen Weg des Dirty Codes mit zahlreicher Kommentierung gehen kann.

Bearbeitet 21. März 2018 von Errraddicator

[carstenj]

Hi,

da ich eher aus der Administratorschiene komme ist Dokumentation quasi Pflicht, weil ich ja keinen Code habe auf den ich mich konzentrieren kann. Aber ich bin auch ein Freund von mindestens einer High Level Dokumentation, wo quasi in Alltagssprache steht, was das Skript, die Funktion oder die Klasse XYZ überhaupt tut und dann kannbzw. muss man natürlich ins Detail gehen, zumal man Skripte, die quasi die gesamte Überwachung und das Backup steuern, elementar sind um den Laden überhaupt am Laufen zu halten.

Oftmals ist es dann einer, der seit 25 Jahren im Unternehmen ist, alles weiss, nichts verrät und niemals ausfallen darf, den man dann mit seinen Fragen beglücken kann.

Bearbeitet 21. März 2018 von carstenj

[SaJu]

Ich stoße im Berufsleben auch immer wieder auf Leute, die "null" Bock auf IT haben, es aber des Geldes wegen machen. Sie haben wenig Fachkenntnisse und wollen am liebsten alles so lassen, wie es ist, weil es schon vor 10 Jahren so gemacht wurde. Wenn man Tipps und Ratschläge gibt, wird das eskaliert.

Zum Glück kriege ich regelmäßig Führungskräfte-Trainings, wo wir uns unter Beruflich Qualifizierten zu  solchen Themen austauschen können. Dort wurde mir ein Buch von einem Stanford-Professor empfohlen: Der Arschloch-Faktor

Seitdem Prof. Sutton einen Artikel dazu veröffentlicht hat, ist der Begriff "Arschloch" zum Fachbegriff im Management geworden. Dann hat er das Buch No Ashole Rule geschrieben, worauf basierend besonders Großunternehmen solche Leute aus dem Unternehmen kicken.

Ich finde das ganz interessant, wenn man selbst irgendwann eine Führungsposition anstrebt und dann gerne für einen besseren Umgang und Kreativität sorgen will.

[arlegermi]

Sicher gibt's auch Bremser, was mich aber ebenfalls aufregt, sind die Leute, denen anscheinend alles total egal ist. Die machen seit Jahren ihren Job und die immer gleichen Handgriffe und haben keinerlei Ambitionen, etwas daran zu ändern.

Als ich hier anfing, sah unser Patchprozess so aus, dass alle 14 Tage ein (und immer nur der eine) Entwickler den aktuellen Stand aus'm CVS ausgecheckt hat, in Visual Studio auf "neu erstellen" geklickt hat und dann die Dateien, die in den Patch gehören, gezippt und an drei Stellen im Intranet gelegt hat. Wenn der Kollege mal Urlaub hatte, fiel der Patch dann eben aus. Weil niemand anderes wusste, welche Dateien in den Patch gehören, welche Inkantationen notwendig waren, um die richtigen Releasenotes zu erzeugen, etc. etc.

Das schlimmste? Das haben alle - vom Entwickler über Produkt-/Projektmanager bis hin zur Geschäftsleitung - so hingenommen. Als ich dann irgendwann aus Frust mal mit CI angefangen habe (erstmal nur für mich), hieß es "och, das ist ja schick". Überhaupt keine Ablehnung, sondern eher Überraschung, dass es sowas gibt und funktioniert. Mittlerweile laufen hier vier Boxen als Build-Server mit Dutzenden Builds pro Tag und einem annähernd automatisierten Patch-Ablauf. Aber der einzige, der sich drum kümmert und neues anstößt bin immer noch ich. Auf der einen Seite macht's mir ja Spaß, die Prozesse mal in's 21. Jahrhundert zu holen, aber auf die Dauer strengt's halt einfach an, immer derjenige sein zu müssen, der den Ball am Rollen hält.

Das ist auch der Grund, wieso ich auf absehbare Zeit eine neue Stelle suchen werde, auch wenn's mir hier was die Entlohnung und die Kollegen angeht, wirklich nicht schlecht geht.

[allesweg]

Auch mir begegnen diese Bewahrer und Geheimniskrämer immer wieder. Oft versuchen diese Leute, sich dadurch ihren Experten-Status zu wahren - den sie nur auf dem alten System haben, weil sich sonst keiner auskennt. Mit jeder Neuerung/Änderung könnte deren Inkompetenz offensichtlicher werden. Oder zumindest ihre mangelnde Anpassungsfähigkeit. Und das waren alle Altersgruppen, vom nerdigen Hypetoolbenutzer der plötzlich ein etabliertes Konzerntool nutzen musste bis hin zum kurz vor der Rente stehenden Guru, der ein (perspektivisch gesehen) neues Tool bekommen sollte.

@arlegermi genau das habe ich aber auch erlebt.

Generell: Mir gefällt die Art, wie die agilen Werte beschrieben sind: "xxx steht über abc" und so ist meine Meinung:

Selbst erklärende Systeme sind wichtiger wie Dokumentation.

Lieber probiere ich vermeintliche Verbesserungen aus und verwerfe sie statt starr am alten, rumpelig Laufenden festzuhalten.

[Goulasz]

Mahlzeit in die Runde!

Spoiler: Dieses Posting kann Spuren von angestautem Frust oder Unverständnis enthalten.

Ich habe die Fresse mittlerweile gestrichen voll von Leuten, die mir mit "Das ist hier schon immer so", "das ist ein gewachsenes System" um die Ecke kommen. Ich. kann. es. nicht. mehr. hören. Das sind Ausreden von Leuten, die entweder keine Lust oder keine Ahnung haben, ein System ggfs. zu zerlegen und parallel neu Aufzusetzen.
"Ja, aber das können wir uns gar nicht leisten" - "IN 2 JAHREN HABT IHR SO VIEL AN MEHRARBEIT VERBRATEN, DA HABT IHR DIE KOSTEN LOCKER RAUS, IHR DEPPEN!" - "Stimmt doch gar nicht!". 2 Jahre später: "Hätten wir mal die Reißleine gezogen..."

Das ging soweit, dass ich mir in meiner letzten Firma intern mit einigen automatisierten Skripten zur selbstlernenden Referenzierung von Datensätzen regelrecht Feinde gemacht habe, weil ich quasi Leute "überflüssig" gemacht habe, die seit 15(!) Jahren und mehr stumpfste manuelle Aufgaben durchführen und partout nichts daran ändern wollen. Wir reden hier von "Ich lese eine Rechnung und gucke, ob da GOFL steht statt GOLF und weise den Datensatz dann manuell einem Typen zu" vs. "Automatisiert mit Levenshtein-Distanz".

Ich dachte ja, sowas gibt es nur in alten KMUs oder Konzernen (wobei mir da die persönliche Erfahrung fehlt), aber nein, es geht auch in kleinen Agenturen.

Das klingt vermutlich ultra arrogant, aber mir persönlich ist meine Lebenszeit zu wichtig, um sie mit wiederkehrenden, manuellen Aufgaben zu füllen. Ich habe 3 Kinder, ich habe private Projekte wie z.B. die Schulgründung und ich könnte jedes mal im Strahl kotzen, wenn ich Menschen sehe, die willentlich und wider besseren Wissens ineffiziente und zeitaufwändige Prozesse von Hand oder mit völlig veralteten und im besten Fall auch noch kostenpflichten Tools ausführen. 

Und zum Thema Dokumentationen und Wissen teilen: Ich teile mein Wissen liebend gerne und permanent. Ich will nichts horten, ich will effizient saubere Lösungen produzieren und streue dafür alles an Wissen, was ich für relevant erachte. Idealerweise auf einer dafür geeigneten Plattform. Analog dem Sicherheits"prinzip" halte ich es bei "Employer value by obscurity" so, dass man schon eine ziemliche Pfeife sein muss, wenn das Verheimlichen die einzige Option ist, den eigenen Wert als Arbeitnehmer zu bewahren.

Was Coding-Style angeht bevorzuge ich den "Newspaper Style". Also zum Start einer Klasse alle public Properties und Methoden, sprechend benannt. Also z.B. eine Abfrage nach dem Verbindungsstatus nicht "CheckConnection()" nennen, sondern eher "IsNetworkConnectionEstablished()"(Der Name ist auch nicht perfekt, zeigt aber die Richtung auf), damit es im Codefluss eher wie Prosa lesbar ist.
Darunter dann die private und protected-Themen. So sieht man direkt "Ah ok, das passiert hier" und wenn man in die Tiefe möchte, tut man das einfach.

Gruß, Goulasz   

Nachtrag: Ich habe überhaupt kein Problem damit, wenn Menschen fachlich nicht wissen, wie sie ein Problem lösen können und damit offen und ehrlich umgehen. Ich mache das permanent. Ich reagiere aber mittlerweile extrem allergisch auf Leute, die für Probleme mit tatsächlicher Komplexität irgendwelche dahingeschmierten "das wird schon passen"-Lösungen konzipieren und eintüten, bei denen am Ende die Entwickler_innen die, mit Verlaub, Scheiße ausbaden müssen, weil irgendjemand auf Twitter gelesen hat, mit der Blockchain und IoT kann man ja ALLES lösen.

 

 

Bearbeitet 21. März 2018 von Goulasz

[Kwaiken]

Oh oh, ich mache mir gleich Feinde ...

Aber ich habe Verständnis für diese Personengruppe, die euch so in den Wahnsinn treibt.

Meistens (aber nicht immer) sind die hier beschriebenen Leute nur Menschen, die den Job als das sehen, was er ist: einfach nur ein Job! Man kommt um 9 und geht um 5. Danach fängt das Leben an. Nicht jeder empfindet seinen Beruf als Berufung, will ständig was verbessern, sich (in seiner Freizeit) permanent weiterbilden. Ist nichts verwerfliches dran. 

Vielleicht rührt meine eher neutrale Haltung gegenüber diesem Personenkreis daher, dass ich die Evolution vom "Nerd" zum "Bremser" (um in der verwendeten Terminologie zu bleiben) miterlebt habe: Ein Kollege, der mit mir zeitgleich angefangen hat, war anfangs Feuer und Flamme. Hat sich permanent weitergebildet, immer was verbessert und alle Systeme State-of-the-Art gehalten. Neuste Doku im DMS keine 10 Min. nach Change.

Nach einigen Jahren kam Frau, Haus und Kind. Weiterbildung blieb liegen (u. a. Fernstudium abgebrochen) und die Prioritäten verschoben sich von Arbeit zu Sohn, Familie und Hobbies. 9to5 und schleunigst Heim. Er ist immer noch bei meinem Ex-Ex-Ex*-Arbeitgeber beschäftigt. Das Informationholding ("Keine Zeit für Doku!"), welches er betreibt, ist der simple Versuch einer Besitzstandswahrung. Sonst könnte er nämlich einfach von dem frisch ausgelernten Azubi ersetzt werden, der mangels Kinder und Hobbies min. 10 Stunden in der Firma ist, sich zu Hause aus Spaß durch c't, IX und Fachbücher wühlt und am Wochenende per VPN alles ausprobiert, was er gerade gelesen hat.

Alleinverdiener, Kredit, Familie. Schon leicht fortgeschrittenes Alter. Einen neuen Job mit dem aktuellen Gehalt zu finden ist nicht mehr. Hier wundert es mich nicht, wenn jemand zunächst eher an sich, denn an den Azubi denkt, der sich durch undokumentierten Spaghetticode wühlen muss.

Macht auch mir als Berater das Leben nicht leicht ("Das geht bei uns nicht so schnell... Prozesse, wissensschon!" - jaja, Heim willst Du, Schalke spielt heute! Hast doch ne 04er Tasse auf dem Tisch!). Aber da habe ich - ehrlich gesagt - Verständnis für.

Dann macht man seinen Job eben etwas weniger effektiv. Ist halt so. Historisch gewachsen ;-)

Bearbeitet 21. März 2018 von Kwaiken

[Gast UnknownX]

Mich würde interessieren, in wie weit die einzelnen Poster hier privat aufgestellt sind. Das hilft deren Perspektive besser einzustufen. 

Es gibt halt wirklich ein Leben neben der IT - wäre traurig wenn nicht. Ich bin Fan vom lebenslangen Leben und bleibe dabei. Gerade als Berater unumgänglich. Aber mit Familie ist dennoch ein Unterschied zwischen meinen 20ern und 30ern zu sehen hinsichtlich der aufbringbaren Zeit.

Ansonsten bin ich ganz bei Kwaiken. Zu mal die Komponente noch dazu kommt, in wie weit der Arbeitgeber in der Firmenkultur Weiterbildung verankert hat. Wenn das dort ein Randthema ist, brauch man sich über derartige Entwicklungen nicht wundern. Insbesondere wenn Weiterbildung dadurch komplett auf das Privatleben geschoben wird.

Wobei der MA hier natürlich wechseln könnte, aber Menschen sind eben verschieden. Sich darüber zu ärgern, ist vergeudete Lebenszeit.

Bearbeitet 21. März 2018 von UnknownX

[Goulasz]

Nachvollziehen kann ich das schon. Ein System ist ja immer darauf bedacht, den Status Quo zu erhalten und möglichst wenig Energie zu "verlieren". Das ist ja ein ähnlicher Grund, wieso "Change" so oft schief geht. Es ist eben nicht so einfach. Siehe Literatur von Kotter & Co. dazu.

Das ändert aber nichts daran, dass es mich unendlich nervt und ich nicht nachvollziehen kann, wie man grade bei automatisierbaren Aufgaben diese nicht automatisiert um im Zweifel seine Zeit angenehmeren Dingen zu widmen. 

@UnknownX Ich bin 31, seit 2012 verheiratet, habe 3 Kinder und mittlerweile 5 1/2 Jahre relevante Berufserfahrung. Meine "privaten" Themen sind mir eher Antrieb als Hindernis, meine Arbeit so effizient, bullshitfrei und aufgabenangemessen zu lösen wie nur irgend möglich.

Gruß, Goulasz  

Bearbeitet 21. März 2018 von Goulasz

[Graustein]

Ich kann die Angst, bei gescheiter Doku ganz easy ersetzt zu werden nicht nachvollziehen sorry. Also wenn meinen Job jeder trottel machen kann der ne Doku lesen könnte, dann würde ich mich selber fragen, was mach ich hier.

[pr0gg3r]

vor 6 Stunden schrieb carstenj:

Wie oft man irgendwelche Krücken findet, oder schlecht gepflegte Skripte etc. Dokumentationen sind unvollständig oder gar nicht vorhanden. I.d.R. lege ich Wert bei meiner Arbeit auf Dokumentation, damit das auch andere übernehmen können

Es bringt nichts, wenn du Wert auf Dokumentation legst. Es ist wichtig, dass der Leiter darauf legt. Ich kenn deine Stellung nicht, ich weiß nicht ob du eine leitende Tätigkeit hast. In gut organisierten Firmen weiß man, wie wichtig Dokumentation ist und kriegt auch entsprechende Zeit und es gibt eine Kontrolle dahinter. 

vor 6 Stunden schrieb carstenj:

Aber ständig gibt es Bremser, die überhaupt gar kein Interesse daran haben, die gefühlt nur ihre seit etlichen Jahren ausgeübte Tätigkeit unverändert fortzuführen wollen, selber überhaupt nichts erklären und jegliche Informationen wie Staatsgeheimnisse hüten.

Wiederum bist halt du nicht derjenige, der anderen zu sagen hat, wie sie zu arbeiten haben. Wenn ein solches Verhalten geduldet wird, ist das das Versagen der Leitung. 

Dennoch: Wenn du an deiner Arbeit geblockt wirst, solltest du beim Projektmanagement eskalieren. Dieser ist dann dafür zuständig, eine Lösung zu finden. Interessiert es ihn nicht, ist die Stelle fehlbesetzt, woran du aber nichts ändern können wirst.

vor 9 Stunden schrieb carstenj:

Zudem werden häufig keine Entscheidungen getroffen

Auch das deutet bei mir auf Versagen der Leitung hin. Es müssen einfach manchmal Entscheidungen getroffen werden, sonst macht jeder so wie er es für richtig hält, was wiederum mit anderen Kollegen kollidieren kann.

vor 9 Stunden schrieb carstenj:

Ich selber würde auch gerne wissen, ob ich das evtl. zu eng sehe und würde auch meine eigenen Gedankengänge überprüfen, daher hoffe ich auf einen interessanten Meinungsaustausch.

Ich denke nicht, dass du es zu eng siehst, ich kann es super nachvollziehen. Ich finde es super, dass du mit gewissem Enthusiasmus bei der Arbeit bist. Es ist ja gerade in der IT notwendig, sich auf dem neuesten Stand zu halten. Es sehen einfach viele ihre Arbeit als Arbeit an und das ist auch vollkommen legitim und OK so. Es passt halt nicht zu deiner Arbeitsweise.  Aber vielleicht bist du einfach in dem falschen Team oder Unternehmen?

[Kwaiken]

vor 2 Stunden schrieb Goulasz:

Das ändert aber nichts daran, dass es mich unendlich nervt und ich nicht nachvollziehen kann, wie man grade bei automatisierbaren Aufgaben diese nicht automatisiert um im Zweifel seine Zeit angenehmeren Dingen zu widmen. 

Und welche Dinge wären das? 8h am Tag fachinformatiker.de lesen wird vom AG sicherlich nicht sonderlich gerne gesehen. Also was passiert, wenn Du einen ungeliebten Task - für den Du bezahlt wirst (!) -  automatisierst? Du bekommst einen neuen! Im schlimmsten Fall hast Du mit deiner Automatisierung dich selbst wegrationalisiert. 

vor 14 Minuten schrieb Graustein:

Also wenn meinen Job jeder trottel machen kann der ne Doku lesen könnte, dann würde ich mich selber fragen, was mach ich hier.

Korrekt. Also wenn Du deinen Job behalten willst, tust Du gut daran, dass der AG von dieser Tatsache nicht Wind bekommt.

Ich bin verwundert, dass dieser Umstand hier so hochemotional gesehen wird. Jeder möchte "überleben", aber nicht jeder zieht aus seinem Job das gleiche Maß an Selbsterfüllung, wie wir es tun. Auch wenn ich mich anstrenge, kann ich nichts verwerfliches darin erkennen, dass jemand, der den Job nur als notwendiges Übel zum Überleben sieht, hier so wenig Aufwand wie möglich reinstecken möchte.

Und dass man nicht am Ast sägen will, auf dem man (evtl. recht bequem) sitzt, dass wundert mich ebenso wenig.

[neinal]

Mir ist total egal, ob jemand seinen Job gern macht, oder nicht. IT ist auch für mich keine Berufung. Aber ich will in meinem Job Spaß haben. Immerhin verbringt man verdammt viel Zeit in der Arbeit. Und meistens ist es so, dass die Leute die keinen Bock haben, dir das Leben einfach schwerer machen. Ich bin es Leid ständig zu diskutieren, dass das ja schon immer so war.

Beispiel: Wir haben ein SAP System auf Unicode umgestellt. D.h. es gibt verschiedene Anpassungen die im Quellcode gemacht werden müssen. Jedes Programm, dass irgendwann mal angepasst oder selbst entwickelt wurde, muss geprüft und ggf angepasst werden. Ich meine es waren ~9k Programme die angepasst werden mussten. Zum Teil genügte ein Haken, der in den Einstellungen gesetzt werden musste, zum Teil musste an mehreren Stellen der Quellcode angepasst werden. Unter allen Programmen waren ~2k Programme, die 1998 geschrieben wurden, seitdem Syntax Fehler enthalten und nicht mehr angefasst wurden. D.h. die Programme sind DEFINITIV nicht ausführbar! Seit 1998!. Und Dennoch haben wir mehrmals mit dem Kunden diskutiert, dass wir die Programme UNBEDINGT auch ALLE anpassen müssen, weil "wir benutzen die regelmäßig". Nein! Machen sie eindeutig NICHT! Aber Hauptsache man  kann erstmal wieder eine Telko mit 15 Leute abhalten und 2 Stunden verplempern. Dass wir deshalb Code am Wochenende angepasst haben, ist ja egal. Interessiert ja den Kunden nicht. Er hatte ja Freizeit. In dem Projekt hatten wir in den letzten 4 Wochen jeden Tag 2 Telkos. Mit ~15 Personen. JEDEN. TAG. Und bei jeder Telko waren die gleichen Personen anwesend. Und am Morgen (8 Uhr) wurde JEDES MAL das gleiche besprochen wie am Nachmittag (16 Uhr) am Tag vorher. Ich will gar nicht überschlagen, was das gekostet hat.

Dazu stolpere ich immer wieder über Systeme die "historisch gewachsen" sind und sitze vor dem System und glaube nicht, was ich da sehe.

Aktuell ein Kunde. Ehemalige Tochterfirma eines Konzerns. Im Konzern wurden andere Daten verarbeitet, die jetzt (seit ~10 Jahren) nicht mehr benötigt werden. Deshalb wird aber das System nicht angepasst. Man hat das schließlich einfach kopiert, als man die Firma ausgegliedert hat. Ist ja alles nicht so schlimm. Nur, dass es quasi überall Mussfelder gibt, die mit Daten gefüllt werden müssen, die NIEMAND benutzt.... Aber hey. Man kann ja einfach mal eine Masse an Daten in die Datenbanken schmeißen, die keiner braucht. Weil "War ja schon immer so". Anstatt das System mal platt zu machen und neu aufzusetzen.

Niemand muss sich zur IT berufen fühlen. Aber vielleicht einfach darauf einlassen.

Und mir ist bewusst, dass ich für etwas, dass ich sinnlos finde dennoch bezahlt werde. Ich würde es aber lieber sinnvoller und schneller gestalten um den Rest aufzuarbeiten. Ist ja nicht so, als gäbe es manchmal auch genügend Arbeit für mehr als eine Person auf meinem Schreibtisch.

 

Und zum Abschluss ein Zitat, dass @Goulasz sehr gern verwendet und das meiner Meinung nach  zum Thema passt: "Wir haben keine Zeit einen Zaun zu bauen. Wir müssen die Rinder einfangen."

[Velicity]

Ich kann die Frustration bedingt mitempfinden. Bei uns (Softwarebereich) läuft das Ganze auf etwas größerer Ebene, sprich wir haben eine Menge Probleme die bewusst komplett ignoriert werden, wo man auch gar nicht bei darf, weil es zuviel Aufwand wäre und am Core nix groß geändert werden darf.

Menschen sind verschieden und in einen Team ergänzt man sich halt ein wenig und hier und da muss man schauen mit wen man kann für ein bestimmtes Problem und mit wem nicht. Habe auch einen Kollegen den ich als Bremser empfinden würde, was ich eigentlich schade finde, da ich ihn bei uns im Unternehmen von dem was er kann ganz klar in der Top 3 sehen würde. Schnellste Reaktion ist aber bei ihm meist, geht nicht oder weißt du wie viel Aufwand das wäre, weißt du wie umständlich das ist usw. Sachlich über sowas diskutieren kann man mit ihm auch nicht, er wird dann schnell laut und meint wer am lautesten ist hat Recht.

Ich bin in 2-3 Bereichen stärker vertreten, den einen davon leitet er quasi bzw. ist da Dienstältester und der, der am meisten umgesetzt hat. Mittlerweile gehe ich bei kleineren Sachen einfach dazu über, sie einfach umzusetzen, seine Antwort kenne ich, er ist dagegen. Endet dann aber i.d.R. damit dass er froh über die Änderung ist und das auch so weiterpflegt.

Nervt mich zwar ein wenig, sehe ich aber gar nicht als so problematisch, sofern ich mich darüber hinwegsetzen kann bzw. nicht darauf angewiesen bin, dass er mir zustimmt, dass einige Sachen geändert werden müssen.

Größte Problem bei mir ist wie gesagt der Core bei uns. Und ja der ist auch "historisch" gewachsen. Er ist schrecklich, unwartbar, nicht erweiterbar und verdammt langsam. Verdammt langsam bedeutet, dass bei jeden Kundenprojekt mehre Wochen ins Land gehen, weil bestimmte Sachen zu langsam sind. Natürlich wird dafür nicht der Core angefasst, sondern man probiert mit Pflastern hier und da und ein wenig Parallelisierung Probleme zu lösen. Wir reden hier von Aktionen die innerhalb eines Dialogs ausgeführt werden, die dann gerne zig Sekunden bis Minuten in Extremfällen sogar Stunden dauern bzw. gar nicht vom Anwender genutzt werden, sondern damit enden, dass er anruft und wir direkt auf der Datenbank arbeiten. Natürlich ist das nix asynchrones, sondern würde bedeuten, der Kunde kann in der Zeit an dem Arbeitsplatz nicht arbeiten.

Eigentlich müsste man den Core einmal weghauen, viele Sachen in der Datenbank mal umstellen, da um die selben Probleme bei jeden zweiten Projekt jeweils von einen anderen Kollegen eine andere Krücke gestrickt wird. Sind dann natürlich auch die Projekte, wo die Betreuung am meisten Spaß macht, weil sich immer nur ein Kollege damit auskennt. Wenn man Pech hat wie ich und die meisten der Kunden hat, die auch Nachts arbeiten bedeutet das für die Betreuung dann, dass man auch wenn andere Kollegen gerade Bereitschaft haben gerne Nachts rausgeklingelt wird.

Alles verstehen wollen klingt ein wenig nach kleinerer Firma? Geht mir ähnlich, wobei man das auch bei Problemen muss. Es gibt halt kein Spezialisten für einzelne Bereiche. Bedeutet wenn was nicht funktioniert oder langsam ist oder wie auch immer, dann muss man einmal durch die ganze Kette durch, vom Frontend, über das Backend, über die einzelnen Abfragen der Datenbank, die Indizes, bis über Wireshark, um zu schauen was auf der Leitung überhaupt passiert. Arbeite mich hier aber auch gern in neue Sachen ein und verstehe die ganzen Abläufe, denke das ist auch wichtig, sonst optimiert man oft an der falschen Stelle.

Größte Frustration bei uns, was ich als Bremse empfinden würde ist aber gar nicht ein Kollege oder der historische Code, sondern der Umgang mit Kunden bei Projekten wenn Probleme auftauchen. Wir haben bei jeden 2-3ten Projekt massive Probleme. Häufig sind die Sachen faktisch klar. Ggf. hat man was nicht bedacht und man müsste ein wenig was umstellen ggf. liegt es auch an den Daten des Kunden usw. Das sind aber alles Probleme die in ein paar Tagen zu lösen wären. Stattdessen probiert man den Kunden der sich beschwert aber zu beweisen, dass alles toll läuft und steckt Wochen an Energie rein um das Thema herum zu reden. Sei es bestimmte Testcases aufzubauen, die beweisen, dass bei uns alles läuft oder um andere Sachen umzusetzen, die optisch für ihn nach einer Verbesserung aussehen. Alles nur nicht eingestehen, dass man selbst ggf. einen Fehler gemacht hätte.

Der Code wird umfangreicher. Häufig werden Sachen umgesetzt die totaler quatsch sind, der Kunde ist ggf. 1-2 Wochen ruhig, weil er an einer bestimmten Stelle eine Veränderung sieht, die aber gar nicht sein Problem ist. Anstatt dass man ihn sagt deine Daten sind Mist, wir haben uns hier ein wenig verplant, dadurch haben wir Probleme bei der Parallelisierung und da durch hast du effektiv aktuell unter 20% der maximalen Leistung. Ändern können wir das so und so. Du musst uns diese und diese Daten geben und wir müssen da noch was ändern.

Den Kunden belügen und so ein riesen Eiertanz um das eigentliche Problem rum, da fühle ich mich persönlich mich als ausgebremst. Ich kenne ja die Probleme, würde sie gerne lösen, darf aber nicht. Wovor man da Angst hat kann ich auch nicht verstehen, am Ende kriegt der Kunde diese ganzen Testcases meist eh umsonst als Gewährleistung, sprich wir arbeiten Wochen lang umsonst um das Problem nicht zu lösen und das mehrfach, anstatt es in ein paar Tagen zu lösen und dafür einen Fehler oder eine Fehlplanung zuzugeben. Geht dann am Ende soweit, dass der Kunde selbst probiert die Fehler zu analysieren, sich Millionen von Datensätzen zuschicken lässt und probiert das Problem anhand von Logs nachzuvollziehen, wo er natürlich keine Chance hat. Das wird dann natürlich auch automatisiert mit täglichen Reporting usw.

Naja ist ein Thema worüber ich ewig weinen könnte. Viele scheint das alles nicht zu stören, die können ihren Kopf bei der Arbeit ausschalten, machen was man ihnen sagt und sind glücklich. Wenn ich den Kunden sagen muss es liegt am Wetter oder der Badehose, dass seine Software nicht tut und Sachen umsetzen muss, die das Ganze im Zweifel sogar noch schlimmer machen, als Alibi um das eigentliche Problem zu vertuschen fühlt sich das für mich an wie ein Tritt in die Eier.

Glaube auf lange Sicht wäre für mich eh eine Selbstständigkeit oder eine Freelancertätigkeit am besten aber dafür fehlen mir bis dato auch die Eier, ergo warte ich bis die Frustration ein entsprechendes Level erreicht um in diese Richtung zu gehen.

Gesprochen wird bei uns über Veränderungen übrigens auch manchmal. Das endet dann in Stunden langen Meetings, wo immer wieder die selben Probleme auf den Tisch kommen und mögliche Lösungsansätze, die danach ganz schnell wieder vergessen werden. Man hat ja auch keine Zeit dafür, lieber kümmert man sich um neue Projekte die Geld einbringen, anstatt mal in die Eigenentwicklung zu investieren um im Anschluss die Projekte wesentlich schneller und besser durchziehen zu können.

Bearbeitet 22. März 2018 von Velicity

[Gast UnknownX]

10 hours ago, Goulasz said:

@UnknownX IMeine "privaten" Themen sind mir eher Antrieb als Hindernis, meine Arbeit so effizient, bullshitfrei und aufgabenangemessen zu lösen wie nur irgend möglich.

Vllt. bin ich zu sehr "Berater" denkend, aber wenn der Kunde keine effiziente, bullshitfreie Projektierung möchte, dann bekommt er sie eben nicht. Deswegen bleibe ich aber nicht bis 22 Uhr. Dann erfolgen weitere abrechenbare Tage, bis es verstanden wurde.

Die Zeiten, in denen ich das als persönliche Mission sehe Andere zu missionieren, sind lange vorbei. Und das ist gut so. Und so würde ich das auch als interner Mitarbeiter durchziehen. Ist es mein Unternehmen? Nein.  Habe ich Lust auf absolut grandiose Projekte (da habe ich alles in der Hand), mach ich das Privat oder würde dann eben das Unternehmen wechseln. Aber auch da wird man wieder auf solche Situationen stoßen. Das ist eben die Realität - that's life.

Eigentlich müsste man mit Bremsern auf einer persönlichen Ebene sprechen statt sie als "übel" zu sehen. Denn es spielen soviele verdeckte Motivationen in gewissen Verhaltenweisen rein, die oft 0 mit IT zu tun haben. Viel hat auch mit genannter Unternehmenskultur zu tun. Da ich nicht Manager/Geschäftsfüher bin, kümmert es mich aber nur minimal. 

Beim lesen der Posts fällt mir auch wieder ein, warum ich so gerne Berater bin. Ich muss manche Unternehmenswelten nicht auf Dauer ertragen. ;-)

Bearbeitet 22. März 2018 von UnknownX

[Kwaiken]

vor 7 Stunden schrieb neinal:

Mir ist total egal, ob jemand seinen Job gern macht, oder nicht. ... Aber ich will in meinem Job Spaß haben.

Und dein Kollege möchte gerne seine Daseinsberechtigung in Form eines nicht (mehr) notwendigen Tasks behalten. Ob er nun händisch DOS-Dateien nach Unix konvertiert - statt dos2unix zu nutzen - oder Meetings veranstaltet, weil er außer Labern nichts kann, so what? 

vor 31 Minuten schrieb UnknownX:

Vllt. bin ich zu sehr "Berater" denkend, aber wenn der Kunde keine effiziente, bullshitfreie Projektierung möchte, dann bekommt er sie eben nicht. Deswegen bleibe ich aber nicht bis 22 Uhr. Dann erfolgen weitere abrechenbare Tage, bis es verstanden wurde.

Genau das. Wenn ich für jedes Mal, wo ich den Satz "Machen Sie mal langsam!" höre 1 EUR bekommen würde, müsste ich nicht mehr arbeiten. 

Versetzt euch in die Lage eurer Kollegen, ein bisschen Empathie schadet nicht. Dann soll er halt in der Datei 2 Stunden Lang einen String durch einen anderen ersetzen, statt "ReplaceAll" zu nutzen. Bremst dich das aus? Mach derweil was anderes. Nur wenn Du Nachteile in Form von "Warum brauchen Sie so lange?!" hast, weil Du auf deinen Kollegen wartest, würde ich hier Konsequenzen ziehen.

Zitat

Eigentlich müsste man mit Bremsern auf einer persönlichen Ebene sprechen statt sie als "übel" zu sehen. Denn es spielen soviele verdeckte Motivationen in gewissen Verhaltenweisen rein, die oft 0 mit IT zu tun haben.

Kaum jemand wird Dir offen sagen, dass er gerne ein Minderleister ist und es auch bleiben möchte. Das sollte man zwischen den Zeilen herauslesen und selbst entsprechende Schlüsse ziehen, finde ich.

Wie gesagt: ich habe da Verständnis für. 

 

Bearbeitet 22. März 2018 von Kwaiken

[allesweg]

Wenn der Bremser auf gleicher Hierarchieebene ist und mir das Leben unangenehm macht, gibt es den dezenten Hinweis, dass dieses Spiel zu zweit gespielt werden kann. Ich will nicht drölftausendachtundvierzig manuelle Eingriffe ins System machen müssen, nur weil einer es nicht automatisiert haben will.

Gegen hierarchisch höher gestellte Bremser muss man sich entscheiden, wie man dagegen / damit umgeht. Da reicht die Palette von Überzeugen (notfalls mit Unterstützung durch Chefchef), Aushalten ... hin zur "Flucht".

[arlegermi]

vor 15 Stunden schrieb Kwaiken:

Meistens (aber nicht immer) sind die hier beschriebenen Leute nur Menschen, die den Job als das sehen, was er ist: einfach nur ein Job! Man kommt um 9 und geht um 5. Danach fängt das Leben an. Nicht jeder empfindet seinen Beruf als Berufung, will ständig was verbessern, sich (in seiner Freizeit) permanent weiterbilden. Ist nichts verwerfliches dran. 

Absolut nicht. Dann ist das Problem aber die Firma, die nicht dafür sorgt, dass ihre Mitarbeiter sich während der Arbeitszeit fortbilden können. Ich erwarte von niemandem, dass er sich zu hause hinsetzt und mit dem coolen neuen Framework spielt. Ich erwarte aber vom Chef, dass er sich darum kümmert, dass seine Mitarbeiter auf dem aktuellen Stand sind.

Und ich kann das total verstehen, dass man lieber den Kopf unten hält, wenn man Angst um seine Stelle hat. Wir haben das gleiche hier: Ich habe eine Kollegin, deren einziger Job es ist, InstallShield zu bedienen, um Setups zu erzeugen. Pro Setup braucht sie dafür einen halben Tag. Da sie auch nur halbtags arbeitet, muss man ein benötigtes Setup teilweise Wochen im Voraus ankündigen. Ist mir schon klar, dass die nicht unbedingt will, dass die Setups automatisch jede Nacht erzeugt werden. Wenn aber meine Arbeit (und meine Laune) darunter leidet, ist mir das erstmal egal. Dann muss die Geschäftsleitung eben andere Aufgaben finden.

[Goulasz]

vor 9 Stunden schrieb Kwaiken:

Und welche Dinge wären das? 8h am Tag fachinformatiker.de lesen wird vom AG sicherlich nicht sonderlich gerne gesehen. Also was passiert, wenn Du einen ungeliebten Task - für den Du bezahlt wirst (!) -  automatisierst? Du bekommst einen neuen! Im schlimmsten Fall hast Du mit deiner Automatisierung dich selbst wegrationalisiert. 

8 Stunden am Tag im Forum lauern ist jetzt auch nicht das Wahre, nein.  
Wenn ich solche Aufgaben automatisiert habe, suche ich mir neue. Oder ich schreibe Unit Tests, baue, falls es sowas noch nicht gibt, eine saubere Build Pipeline auf, evaluiere neue, relevante Technologien und Frameworks, erstelle Workshops für Kolleg_innen zur Wissensverteilung in Software Craftsmanship-Runden, und und und. Es gibt immer etwas zu tun. Als ich mit der oben beschriebenen automatischen Referenzierung fertig war, hab ich mich in Selenium eingearbeitet und ein Framework in C# geschrieben, mit dem die monatlichen Versionstests der entwickelten Software automatisiert werden können. Das Framework hab ich auf dem internen Bitbucket-Server zur Verfügung gestellt und die Leute dann forken lassen, die das wollten. Die Zeit, die ich da investiert hatte, war nach nicht mal einem Test schon wieder "raus".

Dann hab ich auch schon Last- und Penetrationstests konzipiert und durchgeführt, mich natürlich im Vorfeld auf (in dem Fall) dem Kali Linux eingearbeitet, OWASP ZAP mal (in Absprache mit der IT) auf die DEV und INT-Umgebungen losgelassen und für die ISO 27001 ne Liste mit Incidents erstellt. Natürlich nicht zum Selbstzweck, sondern weil absehbar war, dass von einem Kunden aufgrund eines großen Rollouts Anfragen zur Performance des Systems bei Mehrbenutzerzugriff kommen werden. 
Als ich mich eher Richtung Usability orientiert habe, habe ich angefangen, parallel zur Aufbereitung von Infomaterial Inspektionen unserer eigenen Tools durchzuführen und die Findings zu notieren. Oder ich habe einen Usability Test konzipiert und durchgeführt oder Fokusgruppen & Retrospektiven für andere Teams moderiert.

Und wenn gar nichts zu tun war, hab ich bei den Praktikanten und Azubis vorbeigeschaut, kleine Design Thinking oder Business Model Canvas Workshops durchgeführt, als Sparringspartner für Projekte und Ähnliches gedient, verschiedene Projektmanagementmethoden unter anderem mit Lego Serious Play erfahrbar gemacht und so weiter und so fort.

Kurz: Ich tue (in Absprache mit Betroffenen) Dinge, die die Firma, in der ich arbeite, entweder im Jetzt oder für die Zukunft besser aufstellen. Wenn die Firma das nicht möchte, suche ich mir eine neue, die das annimmt und mich "laufen lässt", anstatt mir Steine vor die Füße zu legen.

Ich vertrete die Haltung, dass ein bisschen Entrepreneur-Denke (und Selbstreflexion) nicht nur Geschäftsführern und Managern vorbehalten sein sollte, sondern grade die Leute, die in der Peripherie des Unternehmens mit und für Kunden Probleme lösen, entscheidend zum Erfolg beitragen (können), wenn man sie nur fragt oder einfach zuhört. Vorausgesetzt sie haben die notwendigen Daten, um Entscheidungen treffen zu können.

Gruß, Goulasz