Forum: Ausbildung, Studium & Beruf Übertriebene Manpower im Automotive Bereich?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von MiWan (Gast)


Lesenswert?

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.

von Masl (Gast)


Lesenswert?

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 ;-)

von Chris K. (Gast)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

MiWan schrieb:
> Ist das normal, dass die SW-Entwicklung in der Automobilindustrie so
> groß aufgestellt ist?

ja

von Realist (Gast)


Lesenswert?

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

https://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.

von Bratislava (Gast)


Lesenswert?

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

von DoS (Gast)


Lesenswert?

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.

von MiWan (Gast)


Lesenswert?

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?

von Realist (Gast)


Lesenswert?

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.

von Hermann S. (diphtong)


Lesenswert?

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ß

: Bearbeitet durch User
von Masl (Gast)


Lesenswert?

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?

von Masl (Gast)


Lesenswert?

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.

von noemail@noserver.edu (Gast)


Lesenswert?

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)

von Hermann S. (diphtong)


Lesenswert?

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.

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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?

: Bearbeitet durch Moderator
von Dirk K. (knobikocher)


Lesenswert?

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

von Shorty (Gast)


Lesenswert?

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.

von Senf D. (senfdazugeber)


Lesenswert?

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.

von meckerziege (Gast)


Lesenswert?

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.

von Udo S. (urschmitt)


Lesenswert?

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.

von Realist (Gast)


Lesenswert?

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.

von Ohne Plan Einfach Los (Gast)


Lesenswert?

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.

von Realist (Gast)


Lesenswert?

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.

von Senf D. (senfdazugeber)


Lesenswert?

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!

von Shorty (Gast)


Lesenswert?

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.

von Ohne Plan Einfach Los (Gast)


Lesenswert?

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.

von Realist (Gast)


Lesenswert?

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

von Shorty (Gast)


Lesenswert?

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

von Shorty (Gast)


Lesenswert?

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.

von Ohne Plan Einfach Los (Gast)


Lesenswert?

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

von Klaus W. (mfgkw)


Lesenswert?

Shorty schrieb:
> Wobei die teilweise vehement abstreiten werden schwarze schafe zu sein.

Eine ist grün, eine rot. Der Rest schwarz...

von qwertz (Gast)


Lesenswert?

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.

von Realist (Gast)


Lesenswert?

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.

von Ohne Plan Einfach Los (Gast)


Lesenswert?

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

von Realist (Gast)


Lesenswert?

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

von A. S. (achs)


Lesenswert?

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.

von A. S. (achs)


Lesenswert?

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.

von Ohne Plan Einfach Los (Gast)


Lesenswert?

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/pI7ZxDcbNZM


Realist 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.