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: > Ist das normal, dass die SW-Entwicklung in der Automobilindustrie so > groß aufgestellt ist? ja
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.
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ß
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
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
Shorty schrieb: > Wobei die teilweise vehement abstreiten werden schwarze schafe zu sein. Eine ist grün, eine rot. Der Rest schwarz...
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/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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.