Hallo,
ich komme aus der SW-Entwicklung in der Automatisierungstechnik. Durch
ein paar Vorstellungsgespräche hatte ich etwas Einblick in wie im
Automotive-Bereich die Steuergeräteentwicklung aufgestellt ist.
Beispiel 1: Kleinere Firma, gerade so Mittelständler. Entwickelt ein
automotive Steuergerät mit wenigen Aktoren (Ansteuerung Hydraulik),
Steuerungstechnisch (soweit ich Einblick hatte) absolut trivial, dafür
ASIL-C oder D (wissen die wohl selbst nicht genau). Dafür haben die
einen Projektleiter und 8 externe Entwickler.
Beispiel 2: Großer Automobilzulieferer, zufälligerweise ein ähnlicher
Bereich. Natürlich eine Nummer größer und flexibler als Plattformlösung.
Die haben ~30 interne Entwickler + nochmal doppelt so viele in Indien!
Dazu Architekten, Requirements-Engineer und pipapo.
Ist das normal, dass die SW-Entwicklung in der Automobilindustrie so
groß aufgestellt ist? In meiner Branche bearbeiten solche großen
Mannschaften ganze Produktfamilien mit unterschiedlichsten Technologien
und nicht nur ein Steuergerät mit nem CAN-Bus und ner handvoll Aktorik.
Ich bin immernoch Fassungslos wie viele Leute da an (scheinbar, ich mag
mich irren) trivialen Geräten programmieren. Ich hätte für Beispiel 1
1-2 Entwickler und für Beispiel 2 vielleicht so 5-8 geschätzt wenn man
mich vorher gefragt hätte.
MiWan schrieb:> Ich hätte für Beispiel 1> 1-2 Entwickler und für Beispiel 2 vielleicht so 5-8 geschätzt wenn man> mich vorher gefragt hätte.
Gottseidank fragt dich aber keiner.
Ich kenne Projekte, da sind die Kosten trotz großzügiger Planung (du
würdest die Planung als übertrieben erachten) um 8-stellige Beträge
übergelaufen.
Versteh mich nicht falsch.
Ich bin selber Bastler und weiß wie schnell man einen Prototyp hinrotzt.
CAN, paar Sensoren, paar Aktoren, trivial. Sollten 1-2 Leute doch
schnell hinkriegen.
Aber eine saubere Entwicklung, vor allem in sicherheitsrelevanten
Bereichen, ist ne ganz andere Hausnummer.
Folgende Gewerke werden von der Bastlerfraktion gerne übersehen:
- Requirements Engineering
- Funktionale Sicherheit und alles was da an Tests und Doku dranhängt
- (messbare) Qualität
- Testing, die komplette rechte Seite des V-Modells
Wenn du vollständige Unit- und Integrationstests machen möchtest,
womöglich noch jedes Release absichern musst, dann wirst du um ein
Testteam das mindestens so groß ist wie das der Codeschreiber, nicht
herumkommen.
Du kannst ja folgende Faustformel nutzen:
- Schätze reinen Aufwand für das Codeschreiben ab
- Verdopple deine Abschätzung
- vervier- oder -fünffache deine Abschätzung um die Gewerke abzudecken,
die du als kleiner Entwickler garnicht auf dem Schirm hast
- und dann hoffe dass nichts unvorhergesehenes passiert ;-)
Am aktuellen Zentralsteuergerät für die VW MEB Plattform haben über 1000
Programmierer gearbeitet. Trotzdem waren zum geplanten Startzeitpunkt da
noch über 170 sicherheitskritische Fehler drin. Daher wurde die
Auslieferung der ersten ID3 um fast 1 Jahr verschoben.
MiWan schrieb:> Ich bin immernoch Fassungslos wie viele Leute da an (scheinbar, ich mag> mich irren) trivialen Geräten programmieren.MiWan schrieb:> dafür ASIL-C oder D
Und ich bin fassungslos, dass du Steuergeräte ASIL D konform mit so
einer handvoll Ingenieuren entwickeln willst. Nach deiner Definition ist
ein Batteriemanagement auch nur ein paar Schalter, die fast jeder nach
einem Tag Arduino YouTube Videos als Prototyp realisiert bekommt. Nur
hängt da wegen typ. ASIL C noch viel mehr dran.
Was passiert, wenn man so entwickelt wie du suggerierst? Das hier:
https://jaxenter.de/die-gefahren-des-spaghetti-code-20872https://www.spiegel.de/wirtschaft/unternehmen/zuendschloesser-general-motors-zahlt-900-millionen-dollar-a-1053321.html
Für einen Automatisierungstechniker haben die Systeme ja erst Mal
funktioniert, also alles gut. Oder doch nicht? Genau um solche
Ereignisse zu vermeiden, gibt es die ISO26262 und dort definierten
Methoden. Das ist aber keine spaßige Programmierarbeit, sondern Analysen
die richtig Gehirnschmalz erfordern. Das reine Programmieren dauert
weniger als 10% der Zeit. Wenn man aber nur das reine Programmieren
macht, ohne den ganzen anderen Rotz, dann passiert über Lebensdauer
irgendwann etwas Ähnliches wie in den Links beschrieben. Nach 12 Jahren
in der Nähe einer TV Station bei -35 Grad oder so. Automobile sind da
etwas härteren Bedingungen ausgesetzt als Automatisierungstechnik
betrieben bei Raumtemperatur.
Ich bin in der IT eines Großen Autoherstellers und ich kann bestätigen
Effizient arbeiten ist bei uns wirklich nicht. Es gibt zu jedem Thema
erstmal ganz viele Meetings und ganz viel Powerpoint. Dann werden
Zuständigkeiten besprochen und ausdiskutiert über "Virtuelles"
Abteilungsgeld gestritten Marktstudien beauftragt und am ende wird es
fremd vergeben oder nicht gemacht.
Ein Beispiel Ein Meister aus einem Fachbereich wendet sich an die IT er
hätte gerne eine Lösung grafisch auf einem Bildschirm seine
Materialstände zu sehen.
Er hatte also ungefähr 10 Zahlen vom Rohteillager verschiedene
Fertigungszustände bis zum lager wo das fertige Teil liegt. Diese 10
Zahlen wollte er auf einem Bildschirm haben mit Farben um zu sehen wo es
knapp werden könnte. Klingt einfach?! ist es aber nicht.
Das Rohteillager liegt in der Zuständigkeit der Logistik 1
Das Lager für die fertigen Teile liegt in der Zuständigkeit von Logistik
2
Die Bauteilzähler in den Sps der Maschinen werden bei Schichtwechsel auf
0 gesetzt
So hatten wir dann also Daten in 2 Datenbanken und direkt in der Sps.
Mit den Datenbanken Leuten gab es endlose Diskussionen warum sie uns
darauf keinen zugriff ermöglichen könnten. Es ging um was wenn wir beim
zugriff die Datenbank stören, diverse Sicherheitsthemen und die
Verantwortung im Störungsfall (Wohl gemerkt alles Konzern intern)
Alleine dafür hatten wir gefühlt 20 Powerpoint und 100 Meetings mit
verschiedenen Menschengruppen.
Dann die Sps. Dazu ungefähr ähnlich mit den Instanthaltern mit Sps
programierer mit Netzwerktechniker. Es musste ein Edge Gateway an jede
anlage gebaut werden um beim auslesen der sps Anlagennetz und Hallennetz
sauber zu trennen. Für diese edge geräte mussten wieder abnahmen gemacht
werden die Zuständigkeiten geklärt Wartungsprotokolle erstellt und sogar
ein Sicherheitstest (Ob man sensible auf der Speicherkarte dieses
Gerätes finden könnte) Ach ja und ein Notfallkonzept wie man das Edge
Gateway wieder einrichtet wenn es kaputt gegangen ist.
All dieses hat ungefähr 7 Monate gedauert. Dann hatten wir erstmals alle
10 Daten zusammen auf einer Plattform. Danach gab es eine Ausschreibung
für die Erstellung der UI dann einige Gespräche mit Firmen die diesen
Job übernehmen würden und Letztendlich noch diskusionen über die UI
Technologie.
Kurz vor dem Ziel wurde von oben beschlossen das diese Daten wertvoll
sein könnten für spätere Auswertungen und in die Cloud müssen (Vw
arbeitet mit Amazon und möchte grade eine Digitale Produktion Plattform
etablieren)
Das war dann der Punkt wo der Fachbereich der es eigentlich haben wollte
aussteigen wollte.
Jetzt sieht es so aus das die Daten in einem Server an der Anlage
gesammelt werden und dann zu Amazon gesendet werden dort in einem s3
landen und von dort ein Webui daraus gemacht wird. Alle sind glücklich ?
Nein! Der Meister der es eigentlich wollte hat an dem Pc an der Anlage
wo er das Bild braucht kein Internet.
Dafür haben wir ihm illegal an allen Instanzen vorbei einen Raspberry
mit Nodered Dashborard in einen Schaltschrank gehängt....
Masl schrieb:> Aber eine saubere Entwicklung, vor allem in sicherheitsrelevanten> Bereichen, ist ne ganz andere Hausnummer.> Folgende Gewerke werden von der Bastlerfraktion gerne übersehen:>> Requirements Engineering> Funktionale Sicherheit und alles was da an Tests und Doku dranhängt> (messbare) Qualität> Testing, die komplette rechte Seite des V-Modells>> Wenn du vollständige Unit- und Integrationstests machen möchtest,> womöglich noch jedes Release absichern musst, dann wirst du um ein> Testteam das mindestens so groß ist wie das der Codeschreiber, nicht> herumkommen.
Genau das ist der Punkt. Es macht einen Unterschied, ob man
Jubelelektronik mit einem Volumen von 1000 Stück entwickelt oder in ein
entstehendes System eine Komponente entwickelt, die unter allen
klimatischen (Temperatur, Luftfeuchte, Salz...), und anderen
Widrigkeiten (Vibration, Falscheinbau, Fehlerfälle, EMV, Normen) 10
Jahre funktioniern muss, in einer Stückzahl jenseits einer Million auf
den Markt kommt und auch noch billig sein soll.
Da fährt man gerne einmal in Sizilien mit dem IP4 ein paar Monate im
Kreis oder friert sich im Norden bei Testfahren einen Wolf, um
Schwachstellen zu finden. Wenn das Auto dann gefertigt wird, muss die
Komponente passen wie ein alter Schuh, wenn nicht, gibt es
Konventionalstrafen, Lieferabstufungen, Rückrufe und das kann einer
Firma auch gut den Hals brechen.
Vieles bei der deutschen Autoindustrie ist vielleicht übertrieben
(Spaltmaß, Color-Binning), und andere Autohersteller sehen das lockerer
("Dann geht das Display bei Kälte eben nicht" - live erlebt) aber
dadurch kommt auch die hohe Qualität zu stande und man kann im Sommer
auch noch Auto fahren, ohne dass die Systeme wegen Überhitzung aus
gehen und die Karre stehen bleibt.
Chris K. schrieb:> Am aktuellen Zentralsteuergerät für die VW MEB Plattform haben über 1000> Programmierer gearbeitet. Trotzdem waren zum geplanten Startzeitpunkt da> noch über 170 sicherheitskritische Fehler drin
Das ist natürlich ne andere Hausnummer, allein die Variantenvielfalt die
bei VW abgedeckt werden muss. In meinem Beispielen ging es ja "nur"
darum mit nem CAN-Bus zu kommunizieren und ne handvoll Pneumatikventile
anzusteuern.
Masl schrieb:> Wenn du vollständige Unit- und Integrationstests machen möchtest,> womöglich noch jedes Release absichern musst, dann wirst du um ein> Testteam das mindestens so groß ist wie das der Codeschreiber, nicht> herumkommen.
Unit-, Integrations- und UI-Tests machen wir auch. Aber weit weg von
vollständig. Ich wäre ja froh wenn meinem Team (9 Leute von C#, über Web
zu Python) wenigstens eine Vollzeitstelle als Tester zustehen würde.
Aber das wird bei uns als Geldverschwendung betrachtet... Dafür werden
ständig neue Features gefordert und man muss natürlich mit minimalem
Engineering auf jeden kundenspezifischen Quatsch (mit Stückzahl 1-5)
eingehen. Andere SPS Hersteller, spezielle Programmiervorgaben, völlig
andere Anlagenkonzepte etc. pp
Realist schrieb:> Nach 12 Jahren in der Nähe einer TV Station bei -35 Grad oder so.> Automobile sind da etwas härteren Bedingungen ausgesetzt als> Automatisierungstechnik betrieben bei Raumtemperatur.
Und inwiefern hat das Einfluss auf die Software? Dafür braucht man gute
Hardwareentwickler... Unterschätze btw mal nicht was
Industriekomponenten so alles abkönnen müssen (ist aber nicht mein
Bereich).
Wie muß ich mir eigentlich die Rolle eines Function Owners vorstellen?
Ist das wie eim Product Owner aber die Person ist tatsächlich nur für
eine Funktion zuständig? Wie "groß" ist dann so eine Funktion? Also
gehts da nur um die Anzeige des Blinkers im Cockpit oder um ein ganzes
Klimagerät?
MiWan schrieb:> Und inwiefern hat das Einfluss auf die Software? Dafür braucht man gute> Hardwareentwickler...
Wenn die Software die Hardware nicht so nutzt wie von den Hardware
Entwicklern vorgegeben wurde und deswegen vielleicht sogar Gefahr für
Leib und Leben entsteht, dann ist es eben nicht nur Hardware. Siehe die
zwei Links im letzten Beitrag. Ob die Hardware richtig genutzt wird,
sagen dir die Analysen im Zuge der ISO26262, WENN sie gewissenhaft und
zu einem Zeitpunkt im Projekt durchgeführt werden, wo noch etwas
geändert werden kann. Dafür braucht man aber Vollzeit Leute, siehe auch:
MiWan schrieb:> Unit-, Integrations- und UI-Tests machen wir auch. Aber weit weg von> vollständig. Ich wäre ja froh wenn meinem Team (9 Leute von C#, über Web> zu Python) wenigstens eine Vollzeitstelle als Tester zustehen würde.
Bratislava schrieb:> Ich bin in der IT eines Großen Autoherstellers und ich kann bestätigen> Effizient arbeiten ist bei uns wirklich nicht. Es gibt zu jedem Thema> erstmal ganz viele Meetings und ganz viel Powerpoint.
Das kommt mir so bekannt vor...die Effizienz wird durch Bürokratie, viel
Politik, schlechte Prozesse und Inkompetenz der Entscheidungsträger
nieder gemacht. In der Entwicklung zumindest...in der Produktion läufts
meiner Meinung nach besser.
Aber mal ganz ehrlich...wer bitte soll bei den ganzen gesetzlichen
Verordnungen der einzelnen Länder in die man ausliefert noch
durchblicken??? Ein einziges Chaos! Hinzu kommen noch die ganzen
internen "Gesetze"...damit könnte man sich die kompletten 7h am Tag
beschäftigen.
Vertragliche Regelungen der einzelnen Gewerke, Lieferanten,
Tochterfirmen, wer hat wen beauftragt und und und...wer darf mit wem
reden und mit wem nicht?
Hinzu kommt noch ständige Änderung von Regelungen, Prozessen,
Umstrukturierungen, etc. Jede Abteilung hat andere Prozesse, weil es
nicht von einer übergeordneten Instanz gesteuert wird, jeder kleine
Abteilungsleiter kocht sein eigenes Süppchen...A weiß nicht was B macht.
Wer soll da noch durchblicken? Kein Wunder...
Da brauchts schon Manpower...einer arbeitet wirklich, während sich 10
andere um das Ganze drumherum kümmern.
Bratislava...wahrscheinlich arbeiten wir für die gleiche Firma...^^
Gruß
MiWan schrieb:> Ich wäre ja froh wenn meinem Team (9 Leute von C#, über Web> zu Python) wenigstens eine Vollzeitstelle als Tester zustehen würde.> Aber das wird bei uns als Geldverschwendung betrachtet... Dafür werden> ständig neue Features gefordert und man muss natürlich mit minimalem> Engineering auf jeden kundenspezifischen Quatsch (mit Stückzahl 1-5)> eingehen. Andere SPS Hersteller, spezielle Programmiervorgaben, völlig> andere Anlagenkonzepte etc. pp
OK, aber damit sagst du ja indirekt ja selber, du bräuchtest eigentlich
viel mehr Leute um neben der reinen Entwicklung auch noch das Testing,
das Anforderungs- und Änderungsmanagement und die Qualität handlen zu
können.
Dann versteh ich aber deine Eingangsfrage nicht, wieso wolltest du dann
wissen wieso man im Automotive-Umfeld so viele Leute braucht? Wenn du
deren Notwendigkeit ja selber siehst?
Bratislava schrieb:> Ich bin in der IT eines Großen Autoherstellers und ich kann bestätigen> Effizient arbeiten ist bei uns wirklich nicht.Hermann S. schrieb:> Das kommt mir so bekannt vor...die Effizienz wird durch Bürokratie, viel> Politik, schlechte Prozesse und Inkompetenz der Entscheidungsträger> nieder gemacht.
Völlig andere Baustelle.
IT, vor allem wenn sie InHouse beim OEM läuft ist langsam und
bürokratisch (wie aber alles direkt beim OEM).
Die vom TE angesprochene Entwicklung von Automotive-Hard- und Software
ist was ganz andres. Die ist in der Regel effizient (geht garnicht
anders bei dem Preisdruck zwischen den ganzen Dienstleister).
Der Grund für die hohe Mannschaftsstärke ist einfach, man braucht die
Leute tatsächlich. Da sitzt kaum jemand rum und dreht Däumchen.
Branchenfremden und Bastlern kann man das nur schwer vermitteln.
10% Codeschreiben ist in Serienprojekten mit hohen Stückzahlen schon
verdammt viel.
MiWan schrieb:> Ist das normal, dass die SW-Entwicklung in der Automobilindustrie so> groß aufgestellt ist?
Ja!
Die Gründe:
1.) Bindestrich-Ingenieure benötigen eine Aufgabe.
(Wirtschafts-Ingenieure, Requirements-Ingenieure,
Homologations-Ingenieure, Ingenieur-Psychologen, Projekt-Koordinatoren,
Vertriebs-Ingenieure)
2.) Verantwortung wird solange hin- und her-geschoben bis niemand mehr
nachvollziehen kann was warum gemacht wurde.
3.) Man kann es sich (noch) leisten
Ein Beispiel: Diesel-Skandal
Quelle: Meine Erfahrung aus 25 Jahre in der Automobilindustrie (bald in
Rente)
Masl schrieb:> IT, vor allem wenn sie InHouse beim OEM läuft ist langsam und> bürokratisch (wie aber alles direkt beim OEM).
Es ist ja erstmal egal, welchen Dienstleister/Lieferanten der OEM
ausbremst...da wird jeder ausgebremst, da hat keiner einen Vorteil
hinsichtlich Effizienz.
Die Beschaffungstechnischen Hürden wurden gar nicht genannt...wenn alles
in der Luft hängt und der Dienstleister gar nicht weiß was er machen
soll/muss/darf, wenn er arbeiten muss aber aus irgendwelchen politischen
Spielchen keine Nominierung bekommt...Preis muss ja immer gedrückt
werden.
Kenne ich zur Genüge...da kann auch kein Dienstleister effizient
arbeiten.
Lustig, da gab es GENAU den selben Thread gestern abend auch schon im
µC&Elektronik-Forum als Beitrag "Steuergeräteentwicklung vs. Automatisierungstechnik",
aber da ließ sich offenbar niemand triggern.
Dafür hats heute im A&B-Froum tadellos geklappt. Was sagt uns das?
MiWan schrieb:> Unit-, Integrations- und UI-Tests machen wir auch. Aber weit weg von> vollständig. Ich wäre ja froh wenn meinem Team (9 Leute von C#, über Web> zu Python) wenigstens eine Vollzeitstelle als Tester zustehen würde.MiWan schrieb:> ASIL-C oder D
Wenn FuSi notwendig, dann müssen entsprechende Prozesse vorhanden sein
sowie Rollen wie z.B. Entwickler/Validierer benannt sein. Je nach
erforderlichem Level dürfen dies nicht sie selben Personen sein oder gar
nicht mal in der selben Abteilung arbeiten (Zumindest im Bahnbereich,
soweit meine Erfahrung reicht).
Masl schrieb:> Aber eine saubere Entwicklung, vor allem in sicherheitsrelevanten> Bereichen, ist ne ganz andere Hausnummer.> Folgende Gewerke werden von der Bastlerfraktion gerne übersehen:> - Requirements Engineering> - Funktionale Sicherheit und alles was da an Tests und Doku dranhängt> - (messbare) Qualität> - Testing, die komplette rechte Seite des V-Modells
+1
Masl schrieb:> Folgende Gewerke werden von der Bastlerfraktion gerne übersehen:> - Requirements Engineering> - Funktionale Sicherheit und alles was da an Tests und Doku dranhängt> - (messbare) Qualität> - Testing, die komplette rechte Seite des V-Modells
Mit Automotive SPICE kannst du noch mal den Faktor 2-3 draufrechnen.
Diese "übertriebene" Manpower ist leider notwendig, da gefordert.
Nur ein naiver Hobby-Bastler kommt auf die Idee, dass die Prozesse, die
Manpower und das viele Testen doch gar nicht notwendig seien. So stellt
sich das halt Klein-Fritzchen vor. Ein Flugzeug zu fliegen sind auch nur
ein paar Knöpfe zu drücken, und ein Chirurg ist schließlich auch nur ein
besserer Metzger... So einfach kann die Welt sein.
So manches kommt wohl auch aus einem internen Prozess: Ein paar Dinge,
die "einer ja mal schnell machen kann" erfordern ein 4-Augen-Prinzip das
auch penibel eingehalten wird. Da bist du bei vielem schon mal bei
Faktor 2.
Mich würde allerdings aber auch mal interessieren, ob mit "Wir nehmen
viele billige/durchschnittliche Ingenieure" die Sache letztendlich
schneller+billiger läuft als mit "Wir kaufen uns ein paar Spezialisten
teuer ein" läuft. Betrachtet über den kompletten Produktlebenszyklus.
Ich war schon in Stillstands-Teams: 1/3 mittelmäßig, kommen nur
schleichend oder gar nicht voran, da sie an einem schwierigen Problem
hängen. 1/3 schlecht, macht Sachen kaputt. 1/3 sehr gut, repariert die
kaputten Sachen und kann deshalb die schwierigen Sachen nicht angeht.
Und im Projekt ging nix voran.
Lothar M. schrieb:> Lustig, da gab es GENAU den selben Thread gestern abend auch schon im> µC&Elektronik-Forum als Beitrag "Steuergeräteentwicklung vs.> Automatisierungstechnik",> aber da ließ sich offenbar niemand triggern.>> Dafür hats heute im A&B-Froum tadellos geklappt. Was sagt uns das?
Um das zu erkennen muss man eigentlich nur seinen Nicknamen anschauen.
meckerziege schrieb:> Mich würde allerdings aber auch mal interessieren, ob mit "Wir nehmen> viele billige/durchschnittliche Ingenieure" die Sache letztendlich> schneller+billiger läuft als mit "Wir kaufen uns ein paar Spezialisten> teuer ein" läuft.
Hast du denn mal selbst Leute beauftragt? Waren die Spezialisten dann so
viel schneller und billiger als die internen? Siehe auch Handwerker
Heutzutage. Da ist es oftmals schneller und billiger es selbst zu
machen. Auch wenn nicht 100% das gewünschte Ergebnis rauskommt, so weiss
man doch wo die Schwächen der Arbeit liegt, was der Handwerker dir nicht
sagen wird.
Für alle Ingenieure/Lästerschwestern, die lieber hier lästern als zu
arbeiten, und scheinbar selbst nie an Ausschreibungen beteiligt waren:
Zulieferer interessieren die Entwicklungskosten viel weniger als die
Produktion möglichst gut auszulasten und eine hohe Marge zu erzielen
(also möglichst kaum bis gar nicht verändertes Produkt an mehrere Kunden
verkaufen), während Dienstleister so viele Stunden wie möglich bezahlt
haben wollen (egal was wirklich nötig ist und dabei rauskommt) und der
OEM wünscht sich eine Komponente die exakt auf sein Gesamtsystem
Fahrzeug optimiert wurde. Das passt alles nicht zusammen. Es können sich
nicht alle 3 durchsetzen.
Realist schrieb:> so weiss man doch wo die Schwächen der Arbeit liegt, was der Handwerker> dir nicht sagen wird.
Wenn man kein Spezialist ist, so kann man auch nicht so einfach die
Schwächen der eigenen Arbeit erkennen.
Ohne Plan Einfach Los schrieb:> Realist schrieb:>>> so weiss man doch wo die Schwächen der Arbeit liegt, was der Handwerker>> dir nicht sagen wird.>> Wenn man kein Spezialist ist, so kann man auch nicht so einfach die> Schwächen der eigenen Arbeit erkennen.
Ach du hast wohl noch nie einen Handwerker beauftragt und fristest dein
Dasein in einer Mietwohnung.
Frag 5 Heizungsbauer und du kriegst 5 verschiedene Aussagen. Einer will
Alu Verbundrohr pressen, der nächste PE Heizrohr, der nächste will sogar
noch Kupfer löten und jeder will nur eine ganz bestimmte Marke vom
überteuerten Laden um die Ecke. Worin diese Marke für den 3fachen Preis
besser ist, kann keiner erklären, wie die neue moderne Heizung
eingestellt wird auch nicht, aber mit ihren 15 bis 30 Jahren
Berufserfahrung ist das einfach besser, ohne Grund. Ach und Prozente
kriegt keiner von denen. Selbst die Pressmaschine müssen die armen Kerle
nach 30 Jahren noch ausleihen, was natürlich an den Kunden weitergegeben
wird (10% des Neupreises je Kunde, also alle 1-2 Monate ne neue Zange).
Dabei gilt eins immer unabhängig vom Typ Handwerker: Was der vorherige
Handwerker gemacht hat bzw wie es gerade ist, ist pauschal immer falsch.
Das sind keine Spezialisten, sondern die Jungs, die nach der Schule
nichts anderes gefunden haben.
Realist schrieb:> Was der vorherige Handwerker gemacht hat bzw wie es gerade ist, ist> pauschal immer falsch. Das sind keine Spezialisten, sondern die Jungs,> die nach der Schule nichts anderes gefunden haben.
Sehr gut zusammengefasst!
Realist schrieb:> Das sind keine Spezialisten, sondern die Jungs, die nach der Schule> nichts anderes gefunden haben.
Und dann kommt das raus:
https://www.donaukurier.de/nachrichten/bayern/DKmobil-Audi-Ingenieure-
unerwuenscht;art155371,4038012
Die Leute von Audi lassen sich halt vorher den Leitungsumfang zusagen
und fordern den auch ein (Berufskrankheit ;) ) und das geht halt gegen
die Geschäftspraxis von manchen Handwerkern.
Im Handwerk gibt's zwar viele schwarze Schafe (der Fachkräftemangel hat
es zu dem verschlimmert). Es ist trotzdem nicht korrekt alle über einen
Kamm zu scheren. Es gibt schließlich auch schwarze Schafe unter den
Ingenieuren bzw. Akademikern.
Shorty schrieb:> und das geht halt gegen die Geschäftspraxis von manchen Handwerkern.
Saubere Arbeit sieht man selten. Das stimmt schon. Und wenn der Kollege
von Audi das notfalls per Anwalt einfordert, dann regt das den Pfuscher
da halt auf.
Noch schlimmer ist der Bericht über die "Spezialisten" von Handwerker:
https://proteus-solutions.de/Proteus-News:Art.970046.asp
Ohne Plan Einfach Los schrieb:> Es gibt schließlich auch schwarze Schafe unter den> Ingenieuren bzw. Akademikern.
Richtig: Baerbock, Von der Leyen, Giffey, Schavan, Guttenberg...
Shorty schrieb:> Ohne Plan Einfach Los schrieb:>> Es gibt schließlich auch schwarze Schafe unter den>> Ingenieuren bzw. Akademikern.>> Richtig: Baerbock, Von der Leyen, Giffey, Schavan, Guttenberg...
Wobei die teilweise vehement abstreiten werden schwarze schafe zu sein.
Realist schrieb:> Saubere Arbeit sieht man selten. Das stimmt schon. Und wenn der Kollege> von Audi das notfalls per Anwalt einfordert, dann regt das den Pfuscher> da halt auf.> Noch schlimmer ist der Bericht über die "Spezialisten" von Handwerker:> https://proteus-solutions.de/Proteus-News:Art.970046.asp
Ähnliche Kritik ist auch über Ingenieure, zB die bei VW angestellt sind,
vorhanden.
Bei 5:10 deutlich zu hören!
https://youtu.be/pI7ZxDcbNZM
Oder über Vertragswerkstätte, zB von VW!
https://youtu.be/LZk126aH8wo
Der Automotivebereich ist extrem ineffizient. Deswegen ist ein Auto das
einzige technische Gerät, das trotz technischem Fortschritt immer teurer
wird. Das von der Autolobby angeführte Argument, dass es deshalb teurer
würde weil immer kompliziertere Technik drin steckt, zählt nicht. Denn
das trifft in anderen Bereichen genauso zu.
Ohne Plan Einfach Los schrieb:> Ähnliche Kritik ist auch über Ingenieure, zB die bei VW angestellt sind,> vorhanden.> Bei 5:10 deutlich zu hören!
Sag ich ja, bevor man den externen Pfuscher für teures Geld ins Haus
holt, macht man es doch einfach gleich selbst intern und weiss was man
gemacht hat.
Es hat schon seinen Grund warum in Deutschland gar kein Großorojekt mehr
pünktlich und im Budget ins Ziel kommt. Ingenieure wie Handwerker,
überwiegend inkompetent, aber angestellte Ingenieure sind im Gegensatz
zu den Handwerkern wenigstens keine Abzocker. Ich behaupte auf Arbeit
nichts was ich nicht auch halte. Wenn ich von etwas keine Ahnung habe
(siehe Heizungsbauer in den Links oben), dann sage ich das offen.
qwertz schrieb:> Deswegen ist ein Auto das einzige technische Gerät, das trotz> technischem Fortschritt immer teurer wird.
Wenn du die Inflation berücksichtigst, kostet ein Corsa oder Golf
heutzutage nicht mehr als in den 1980ern. Obwohl man nicht nur mehr
Sicherheit und Technik bekommt, sondern viel größere Autos. Du kannst ja
gerne mit Zahlen gegenteiliges belegen. Ich kann welche raussuchen, wenn
du es nicht selbst schaffst.
qwertz schrieb:> Das von der Autolobby angeführte Argument, dass es deshalb teurer würde> weil immer kompliziertere Technik drin steckt, zählt nicht. Denn das> trifft in anderen Bereichen genauso zu.
Nicht vieles ist von 0 Steuergeräte auf 100 von der Komplexität
gewachsen. Die Automobilindustrie behauptet das aber auch gar nicht,
sondern du.
Realist schrieb:> Sag ich ja, bevor man den externen Pfuscher für teures Geld ins Haus> holt, macht man es doch einfach gleich selbst intern und weiss was man> gemacht hat.
Ach jetzt sind wieder, wie so oft, andere Schuld. Warum nehmen dann die
internen Pfuscher die Arbeit überhaupt ab?
Ohne Plan Einfach Los schrieb:> Oder über Vertragswerkstätte, zB von VW!> https://youtu.be/LZk126aH8wo
Intern wird (bewusst) genauso oder mehr gepfuscht. Da kann man froh
sein, dass es Externe gibt. Ansonsten würde man nur noch über den Tisch
gezogen
Ohne Plan Einfach Los schrieb:> Warum nehmen dann die internen Pfuscher die Arbeit überhaupt ab?
Weil das nicht solche Profis wie du sind.
Ohne Plan Einfach Los schrieb:> Intern wird (bewusst) genauso oder mehr gepfuscht.
, weil ... .
Quelle: ...
Ja, es muss alles auch bei 10 Millionen Stück funktionieren.
Trotzdem ist dadurch z.b. Apple entstanden: HP wollte sich Woszs
Gebastel der TV-Ansteuerung nicht antun, weil vielleicht ein Modell
nicht damit klar kommen könnte.
Realist schrieb:> Das hier:> https://jaxenter.de/die-gefahren-des-spaghetti-code-20872
Wobei ich da nicht sehen kann, wie subjektiv das ist. Ja, es gibt die
vielen Beispiele ohne Komplexität, wo alles in 10 Zeilen und McCabe < 1
geht. Aber echter, komplexer Code fällt vermutlich bei jedem aus einer
anderen Stilrichtung durch.
Realist schrieb:> Weil das nicht solche Profis wie du sind.
Ich verstehe. Jetzt lässt sich erklären wie so was zustande kommt. Alles
Fehler von externen "Spezialisten" ⬇️
Ohne Plan Einfach Los schrieb:> Ähnliche Kritik ist auch über Ingenieure, zB die bei VW angestellt sind,> vorhanden.> Bei 5:10 deutlich zu hören!> https://youtu.be/pI7ZxDcbNZMRealist schrieb:> Ohne Plan Einfach Los schrieb:>>> Intern wird (bewusst) genauso oder mehr gepfuscht.>> , weil ... .> Quelle: ...
Siehe hier ⬇️
Ohne Plan Einfach Los schrieb:> Oder über Vertragswerkstätte, zB von VW!> https://youtu.be/LZk126aH8wo