Hallo zusammen, ich bin Student der Elektrotechnik und lese hier im Forum immer wieder, dass in kleinen Firmen eher gebastelt und nicht „richtig“ entwickelt wird. Mich interessiert sehr, wie der grobe Entwicklungsprozess (Beispiel Elektronik Hardwareentwicklung) bei euch in der Firma aussieht. Welche Entwicklungsmodelle und Tools werden eigesetzt (V-Modell?) Wie ist bei euch die Aufgabenverteilung: gibt es eine strikte Trennung zwischen Design, der eigentliche Entwicklung, Aufbau und Bestückung von Testmuster, Unit Test, usw. oder erfolgt das alles aus einer Hand? Ist es nicht so, dass am Anfang immer gebastelt wird? Es werden zuerst kleine Testschaltungen aufgebaut, bevor es an das Große und Ganze geht. Grüße Peter
Pet schrieb: > dass in kleinen Firmen kleine Firmen nennen die Top Entwickler hier alle "Klitschen" :D ich bin schon gespannt was man Dir antwortet, gute Frage!
Beitrag #5467515 wurde von einem Moderator gelöscht.
Pet schrieb: > Ist es nicht so, dass am Anfang immer gebastelt wird? Es werden zuerst > kleine Testschaltungen aufgebaut, bevor es an das Große und Ganze geht. Das kommt darauf an, was entwickelt wird. Handelt es sich um ein typisches embedded design wo der Kunde ein x-beliebige CPU/µC/µProc verwenden will und einfach nur Interfaces bedient werden (z.B. Router, Multimedia, usw.), dann erwartet der Kunde typischerweise schon ein Design dass prinzipiell serientauglich ist. Je nach dem ob es ein realitätsnaher Kunde ist, ist er sich bewusst, dass noch ein kleines Redesign dafür notwendig ist oder eben nicht. Viele Kunden wollen schnell an den Markt und ein Funktionsmuster erscheint im ersten Moment als zu Zeitaufwendig (lieber noch 4 Wochen mehr Aufwand reinstecken und was richtiges habn). Manche Entwicklerbuden machen das Spiel mit. Richtige Firmen machen das dem Kunden klar. Wird jedoch z.B. ein innovatives Produkt entwickelt sieht, das anders aus. Je nachdem wieviel Aufwand in die konzeptionelle Phase gesteckt werden muss lohnt sich ein Funktionsmuster oder Frickelaufbau. Besteht der Hauptaufwand im Schaltplan und Layout und eher nicht im Konzept wird häufig auf Funktionsmuster verzichtet. Weil man/Kunde meist davon ausgeht, dass Layout nur reines doing ist und ja alle Probleme im Konzept gelöst wurden. (Tatsache, nicht meine Meinung).
Beitrag #5467538 wurde von einem Moderator gelöscht.
Beitrag #5467547 wurde von einem Moderator gelöscht.
Richtig vermutet - das war nur unser bekannter Forentroll Matthis ;-)
Chris D. schrieb: > Richtig vermutet - das war nur unser bekannter Forentroll Matthis > ;-) Woran erkennt ihr den? Session / IP? Benutzt der VPN?
An der permanenten Wiederholung derselben ähnlichen Texte, das kann jedes Skript ;-) Und hier natürlich, weil das vollkommen am Thema vorbei war.
Aber kommt das immer vom gleichen Provider? Hat er ständig neue IPs? Falls ja, wer hat die Möglichkeiten dazu, so viele verschiedene IPs zu verwenden?
?!? jeder..Router neu starten, Proxys etc pp Verschiedene IPs, Cookies löschen, z.B...
:
Bearbeitet durch User
Ich hoffe mal das sich Primär Leute melden die in beiden Definitionen von Unternehmen Unterwegs waren. Es ist schon lustig zu hören wie manche Kommilitonen die direkt bei Siemens gelandet sind sich das so vorstellen mit dem entwickeln in einer Klitsche. Ich bin bei einer Klitsche (1-5 MA) eingestiegen und von einem "kleinem großen" Unternehmen ca. 6000 MA angeheuert worden für die ich früher entwickelt habe beim alten Arbeitgeber. Ein paar vergleiche könnte ich schon Stellen. Auch wenn das hier kein Conti, Linde, Bosch oder Siemens ist. Der Vergleich würde recht ausgewogen ausfallen, womit das größere Unternehmen durch seine besseren Arbeitsrechtlichen und Entgeltlichen Faktoren als Arbeitgeber deutlich gewinnt. Aber das war ja nicht gefragt. Für eine lange Antwort baut der Rechner gerade die Software dann doch zu schnell ;)
Pet schrieb: > (Beispiel Elektronik Hardwareentwicklung) (V-Modell) Das V-Modell ist für Softwareentwicklung. Natürlich arbeiten heute alle unglaublich agil. Und das Controlling möchte Zahlen sehen, einfach verständliche Zahlen. Die muss der Entwickler liefern, ab Besten in dem er seine velocity jeden Monat erhöht, das geht am einfachsten in dem die Anzahl der Aufgaben immer höher wird. Und der Inhalt immer kleiner, aber das interessiert und versteht das Controlling ja nicht. Weil alles so agil ist, weiss keiner heute, was er denn morgen macht. Statt Planung also hektisches Durcheinanderlaufen. Und weil agil bedeutetd aß alle in einem Team gleichwertig sind, gibt es niemanden der einen Plan macht oder den Überblick hat. Entsprechend kommt eigentlich nur noch Scheisse bei raus. Wo wir bei Hardware sind: Autos wie VW Diesel (sehr agil entwickelt), Kühlschränke wie BSH (deutlich schlechter benutzbar als 1980), Smartphones die im Laufe der Benutzung einfach von alleine immer schlechter wegen bis zur Unbrauchbarkeit geupdated, Geräte die keine Gewährleistungszeit mehr halten und nicht reparabel sind weil man aus den Fehlern der Vergangenheit eben NICHT gelernt hat. Statdessen hat sich die Rechtsabteilung durchgesetz: Bitte keine technischen Daten mehr nennen nur noch Begriffe wie geil super toll das beste denn ein Kunde könnte reale Daten einfordern, keine Bedienungsanleitungen mehr (tatsächlich, Handys werden mit Zetteln ausgeliefert und mit CDs auf denen nicht mal mehr steht wie man eine SMS schreibt und das T9 Wörterbuch benutzt) denn sie sichern etwas zu und auf keinen Fall Internas enthält wie Schaltpläne denn da kölnnten Patentverstösse drin dokumentiert sein. Der Wahnsinn hat Methode.
https://medium.freecodecamp.org/the-two-types-of-programmers-hackers-vs-academics-514044ed40c Je nach Einsatzzweck ist das eine oder das andere passender.
Kein entweder oder! Man bastelt einen Prototypen hin, den man dann zu einem richtigen Serienprodukt entwickelt. Manche grossen Serienbauer können nicht mehr basteln und müssen gebastelte Prototypen samt Klitsche einkaufen um noch nachgefragte Serienmodelle fertigen zu dürfen.
Vergleich dazu: Minimal- / Maximal-Prinzip. Gebastel: Maximal-Prinzip. Mit gegebenem Aufwand (Entwickler * Zeit) das maximale Ergebnis erzielen. Vorher ist das gewünschte Ergebnis nicht genau bekannt. Entwickeln: Minimal-Prinzip. Ein gestecktes Ergebnis (Produkt mit Eigenschaften X/Y/Z) mit minimalem Aufwand erreichen. Dafür muss eben das Produkt genau definiert sein. Michael B. schrieb: > Das V-Modell ist für Softwareentwicklung. Das V-Modell stammt aus der Softwareentwicklung, ist aber inzwischen als allgemeiner Entwicklungsprozess "verbreitet". Halt mehr oder weniger ;) Wenn man sicherheitsrelevante Produkte im Automotive Bereich entwickeln willst, kommst du um solche Prozesse nicht herum. Siehe ISO 26262. In dieser Norm ist das geradezu pervers aufgezogen: bevor nur eine Schaltung gezeichnet wird, bevor ein Bauteil eingeplant wird, müssen ganz grundlegende (Sicherheits-)Eigenschaften der Entwicklung definiert und dokumentiert werden.
:
Bearbeitet durch User
Bastlerbude, Frickelladen und Klitsche sind solche Begriffe, die Konzernbeamte gern benutzen, um über Firmen zu sprechen, die echte Entwicklung betreiben. Da die eigentliche Tätigkeit (Powerpoint, Excel, Requirements) so langweilig ist redet man sich ein, innovative Tätigkeit (F&E) sei Fricklerei. Wird auch gern über die eigene F&E Abteilung im Konzern gesagt. Das ist ein Schutzmechanismus des Gehirns, der verhindert dass man völlig verblödet. Sollte man den Schutzmechanismus überwinden, ist die Beförderung möglich.
seit es Digitalfotografie gibt wird kaum noch entwickelt, gebastelt wird überall, deswegen gibt es Bananensoftware und auch richtige Produkte werden nur noch zusammengebastelt, deswegen funktionieren die meisten nur zufällig. Das einzige was gut funktioniert ist das Überleben der gesetzlichen Gewährleistung für das Produkt, das passt zu 99,9%
SW I. schrieb: > Bastlerbude, Frickelladen und Klitsche sind solche Begriffe, die > Konzernbeamte gern benutzen, um über Firmen zu sprechen, die echte > Entwicklung betreiben. Da die eigentliche Tätigkeit (Powerpoint, Excel, > Requirements) so langweilig ist redet man sich ein, innovative Tätigkeit > (F&E) sei Fricklerei. Wird auch gern über die eigene F&E Abteilung im > Konzern gesagt. Das ist ein Schutzmechanismus des Gehirns, der > verhindert dass man völlig verblödet. Sollte man den Schutzmechanismus > überwinden, ist die Beförderung möglich. Der beste Kommentar bisher :)
Gibt es denn im Hardware-Bereich keine "normierten" Entwicklungsprozesse? Also z.B. so etwas wie V-Modell, RUP oder Agile im Softwarebereich? Oder z.B. NGOSS im Telko-Umfeld; ITIL für Betriebsprozesse?
Pete K. schrieb: > Gibt es denn im Hardware-Bereich keine "normierten" > Entwicklungsprozesse? Doch, die gibt es sicherlich. > Also z.B. so etwas wie V-Modell, RUP oder Agile im > Softwarebereich? "Normierte" Entwicklungsprozesse braucht man nur, um sich mit juristischen Mitteln gegen irgendwen zur Wehr zu setzen. Um seine Arbeit gut zu erledigen, braucht man Wissen, Erfahrung und Austausch. Normenkenntnis kann echtes Verständnis nicht ersetzen.
Michael B. schrieb: > Die muss der Entwickler liefern, ab Besten in dem er seine velocity > jeden Monat erhöht, das geht am einfachsten in dem die Anzahl der > Aufgaben immer höher wird. Und der Inhalt immer kleiner, aber das > interessiert und versteht das Controlling ja nicht. > Weil alles so agil ist, weiss keiner heute, was er denn morgen macht. > Statt Planung also hektisches Durcheinanderlaufen. Und weil agil > bedeutetd aß alle in einem Team gleichwertig sind, gibt es niemanden der > einen Plan macht oder den Überblick hat. > Entsprechend kommt eigentlich nur noch Scheisse bei raus. Dein Beitrag hat mich zum Schmunzeln gebracht.
Possetitjel schrieb: > "Normierte" Entwicklungsprozesse braucht man nur, um > sich mit juristischen Mitteln gegen irgendwen zur Wehr > zu setzen. > > Um seine Arbeit gut zu erledigen, braucht man Wissen, > Erfahrung und Austausch. Normenkenntnis kann echtes > Verständnis nicht ersetzen. Wissen, Erfahrung und Austausch ersetzen ja auch keine Prozesse oder werden durch diese ersetzt. Ich kann mir kaum vorstellen, dass bei einer Entwicklung für z.B. Automobilhersteller nicht gewisse Vorgaben (Dokumentation, Prüfpflichten, etc.) existieren. Was ist eigentlich mit ISO-26262?
Pete K. schrieb: > Gibt es denn im Hardware-Bereich keine "normierten" gibt es die wirklich, ein Studienkollege war in der Funkgeräteentwicklung, er beschrieb es kurz so: Man entwirft eine Platine nach Vorlage,optimiert auf Kosten und Genauigkeit, Stabilität, lässt sie fertigen, misst nach und wenn sie schlechter war dann Ablage Rundordner und von vorne. Das nenne ich basteln auf hohem Niveau, in der Prüfgeräteentwicklung haben wir oft kleinere Dinge "entwickelt" Erprobtes was den Beweis der Funktion im gefädelten Prototyp bewies, erst dann wurden Platinen in Serie gefertigt, aber nicht immer, nicht für Einzelstücke.
Beitrag #5467775 wurde von einem Moderator gelöscht.
Pet schrieb: > Mich interessiert sehr, wie der grobe Entwicklungsprozess (Beispiel > Elektronik Hardwareentwicklung) bei euch in der Firma aussieht. Schau dir einfach mal ein paar Diskussionen nebenan im Platinenforum an. Oder-ganz frisch-das hier: Beitrag "Freilaufdiode auf Platine platzieren?" Der Unterschied zwischen Gefrickel und richtiger Entwicklung liegt meines Erachtens im methodischen Vorgehen. Der Bastler frickelt etwas zusammen, irgendwie funktioniert es, aber so wirklich weiß er nicht was er da getan hat. Merkt man sehr schnell, wenn man "warum" fragt. Der Entwickler weiß vorher was er da macht und was es machen soll. Manchmal weiß er es nicht (z.B. weil keine Zeit zum Entwickeln ist), aber dann weiß er auch daß er es nicht weiß. Schau dir dazu mal die Beiträge von Falk im verlinkten Thread an. Und vergleiche diese von dem "mit felderfahrung".
Pete K. schrieb: > Possetitjel schrieb: >> "Normierte" Entwicklungsprozesse braucht man nur, um >> sich mit juristischen Mitteln gegen irgendwen zur Wehr >> zu setzen. >> >> Um seine Arbeit gut zu erledigen, braucht man Wissen, >> Erfahrung und Austausch. Normenkenntnis kann echtes >> Verständnis nicht ersetzen. > > Wissen, Erfahrung und Austausch ersetzen ja auch keine > Prozesse oder werden durch diese ersetzt. Prozesse SIND faktisch kein Ersatz für Wissen, Erfahrung und Austausch, da gebe ich Dir Recht. Dennoch wird oft genug so getan, ALS SEIEN SIE ein vollwertiger Ersatz -- was sie aber nicht sind. > Ich kann mir kaum vorstellen, dass bei einer Entwicklung > für z.B. Automobilhersteller nicht gewisse Vorgaben > (Dokumentation, Prüfpflichten, etc.) existieren. Klar existieren die Vorgaben. Und? Es existiert auch eine Pflicht, Steuern zu zahlen oder die Geschwindigkeitsbegrenzung einzuhalten, wenn Du verstehst, was ich meine.
Possetitjel schrieb: > "Normierte" Entwicklungsprozesse braucht man nur, um > sich mit juristischen Mitteln gegen irgendwen zur Wehr > zu setzen. Das trifft die ISO 26262 auf den Punkt. > Um seine Arbeit gut zu erledigen, braucht man Wissen, > Erfahrung und Austausch. Normenkenntnis kann echtes > Verständnis nicht ersetzen. Das Unterschreibe ich. Dennoch helfen Prozesse, die Fehlerrate niedrig zu halten. Jeder macht Fehler. Eine zweite Instanz kann da helfen. Ein entsprechender Prozess, wenn er denn gelebt wird, kann auch eben genau zu dem Austausch unter Kollegen führen. Sprichwort Design Review! Was wurden meine Schaltungen im Design Review auseinander genommen! Am Ende sind dort immer noch Sachen aufgefallen, welche im Detail besser gelöst werden konnten -> durch Austausch mit Kollegen bessere Hardware.
Pete K. schrieb: > Gibt es denn im Hardware-Bereich keine "normierten" > Entwicklungsprozesse? Also z.B. so etwas wie V-Modell, RUP oder Agile im > Softwarebereich? Lernt man denn als Softwerker nur den Teil vom V-Modell, der sich auf Software bezieht? In der VDI-Richtlinie 2206 "Entwicklung mechatronischer Systeme" ist das lang und breit ausgewalzt. SW I. schrieb: > Bastlerbude, Frickelladen und Klitsche sind solche Begriffe, die > Konzernbeamte gern benutzen, um über Firmen zu sprechen, die echte > Entwicklung betreiben. Da die eigentliche Tätigkeit (Powerpoint, Excel, > Requirements) so langweilig ist redet man sich ein, innovative Tätigkeit > (F&E) sei Fricklerei. Wird auch gern über die eigene F&E Abteilung im > Konzern gesagt. Das ist ein Schutzmechanismus des Gehirns, der > verhindert dass man völlig verblödet. Sollte man den Schutzmechanismus > überwinden, ist die Beförderung möglich. Konzernbeamte ist ein solcher Begriff, den Bastler und Frickler gern benutzen, um über Menschen zu sprechen, die Produkte systematisch und immer mit Blick auf das Endprodukt entwickeln. Da die Bezahlung so gering ist, redet man sich ein, Erfassung und Management von Anforderungen und Projekten, Dokumentation von Ergebnissen und internem Fachwissen, Beachtung von Normen und Richtlinien bereits beim Entwurf, Fertigbarkeit (z.B. durch Beschränkung auf "Katalogteile"), Langlebigkeit durch Second-Source sei unnötig. Wird auch gern über Kollegen in der Firma gesagt. Das ist ein Schutzmechanismus des Gehirns, der verhindert, dass man am eigenen Leben verzweifelt. Sollte man den Schutzmechanismus überwinden, muss man viel weniger Feuerwehr spielen, weil die Produkte zuverlässiger und weniger zufällig so funktionieren wie sie sollen. Danke für die Vorlage ;) Das Optimum liegt natürlich wie so oft irgendwo in der Mitte: Ein Bastler wird einen Arduino kaufen und bei Aliexpress fünf Infrarot-Sensoren, zwei Studenten einstellen, die irgendetwas coden. Dann hat er nach einem halben Jahr eine Lösung, stellt aber fest, dass es die IR-Sensoren bei Ali nicht mehr gibt, dass der Arduino die EMV-Prüfung nicht besteht, dass die Studenten mehr Bugs als Codezeilen hinterlassen haben und keiner in der Firma den Gedankengang des Bastlers nachvollziehen kann, wenn der mal krank, im Urlaub oder womöglich bei einer anderen Firma ist. Außerdem will der Kunde plötzlich "das hab ich schon immer gesagt" noch, dass das Teil nicht 15cm (wie bisher immer angenommen), sondern 45cm Reichweite hat und nach zwei Wochen herumärgern stellt sich heraus, dass schon in der ersten eMail von "15-45cm Reichweite" die Rede war, der Vertrieb aber nur die 15cm an die Entwicklung weitergegeben hat. Und bei der ersten Anfrage nach einer Kleinserie fällt dem Chef alles aus dem Gesicht, weil der Bestücker dreimal so teuer ist wie geplant, weil jeder Widerstand einen anderen Wert und eine andere Bauform hat und der Arduino irgendwie im 45-Grad-Winkel mit Lochband manuell auf die Platine geklebt werden muss, sonst passt das Ganze nicht ins Gehäuse. Dummerweise hat der Kunde schon ein Festpreisangebot vorliegen und besteht auf Erfüllung. Ein Konzernbeamter wird erstmal drei Monate mit dem Kunden (oder Vertrieb) diskutieren, welche Anforderungen der Kunde denn hat. Dann alle einschlägigen und nicht-einschlägigen Normen nachrecherchieren, die in den ca. 192 Ländern dieser Erde vielleicht für das Produkt gelten könnten. In jeder eMail steht dann der Vermerk "Beim Export in Länder außerhalb des im Angebot genannten Verwendungsbiets verpflichtet sich der Kunde, die gegebenenfalls zusätzlich notwendigen Prüfungen zu recherchieren und zu veranlassen. Ein Export in den Weltraum ist von uns nicht freigegeben. Vor der Verwendung bei mehr als 22 oder weniger als 18 Grad ist eine kostenpflichtige Freigabe von uns einzuholen. Nicht zur Verwendung in Rettungsgerät geeignet. Ein Trocknen zusammen mit der Katze in der Mikrowelle ist nicht gestattet." Und am Ende greift er entweder ins Regal und holt ein (ungefähr) zum Problem passendes Produkt heraus oder schickt ein Angebot "Sonderkonstruktion nach Aufwand", nach dem der Kunde nie wieder anruft, weil schon die Grundkosten für "Klärung der Anforderungen" dreimal so hoch sind, wie er als Gesamtpreis eingeplant hatte. Oder falls der Kunde doch bestellt, schickt der Konzernbeamte nach zwei Jahren Papierkrieg seinen Frickler hin, der das ganze irgendwie zum Laufen bringt. Ich hab als Kunde schon mit beiden zu tun gehabt. MfG, Arno
Was IMO in dem Zusammenhang wichtig ist, ist der Teil vor dem Entwickeln: Die Spezifikation dessen, was eigentlich rauskommen soll. Mein Eindruck Klitsche vs. Grossfirma ist der, das bei letzterer alles bis auf die letzten 10 Nachkommastellen "durchgespec'd" wird, damit der Fliesbandentwickler (der ja typischerweise 5 Projekte gleichzeitig machen muss) nicht auf andere/dumme Ideen kommt und effizient und geradlinig durcharbeiten kann (etwas übertrieben gesprochen, ich weiss schon, dass man auch da viel nachdenken und "basteln" muss). Das Ergebnis sind hochkomplexe und meistens auch schon gut funktionierende Schaltungen, die aber so im Gesamtzusammenhang diverse Defizite (fehlende Erweiterbarkeit, Praktikabilitätsprobleme, etc.) aufweisen können. Klitschen haben meistens nur die groben funktionalen Anforderungen im Blick und mäandern auch im Entwicklungsprozess selbst etwas rum, so ala "Hey, da könnte man doch noch" oder "so wäre es doch viel praktischer". Kann bei falscher Anwendung zu totalem Chaos oder Ewigkeitsentwicklungen führen. Und wenns gut geht, kommt was viel innovativeres als ursprünglich geplant raus.
Arno schrieb: > Konzernbeamte ist ein solcher Begriff, den Bastler und Frickler gern > benutzen, um über Menschen zu sprechen, die Produkte systematisch und > immer mit Blick auf das Endprodukt entwickeln. Da die Bezahlung so > gering ist, redet man sich ein, Erfassung und Management von > Anforderungen und Projekten, Dokumentation von Ergebnissen und internem > Fachwissen, Beachtung von Normen und Richtlinien bereits beim Entwurf, > Fertigbarkeit (z.B. durch Beschränkung auf "Katalogteile"), > Langlebigkeit durch Second-Source sei unnötig. Wird auch gern über > Kollegen in der Firma gesagt. Das ist ein Schutzmechanismus des Gehirns, > der verhindert, dass man am eigenen Leben verzweifelt. Sollte man den > Schutzmechanismus überwinden, muss man viel weniger Feuerwehr spielen, > weil die Produkte zuverlässiger und weniger zufällig so funktionieren > wie sie sollen. Der beste Kommentar bisher :)
Es hätte ernsthaft werden können, ist aber wieder auf Hauptschulniveau gelandet.
Pete K. schrieb: > Also z.B. so etwas wie V-Modell, RUP oder Agile im > Softwarebereich? > Oder z.B. NGOSS im Telko-Umfeld; ITIL für Betriebsprozesse? einfach mal alles rausgehauen was du irgendwie noch ausm Studium im Kopf hattest mit der Hoffnung, wir coolen Jungs denken du hast was drauf. Falsch gedacht.
Beitrag #5468377 wurde von einem Moderator gelöscht.
Arno schrieb: > Konzernbeamte ist ein solcher Begriff, den Bastler und Frickler gern > benutzen, um über Menschen zu sprechen, die Produkte systematisch und > immer mit Blick auf das Endprodukt entwickeln. Da die Bezahlung so > gering ist, redet man sich ein, Erfassung und Management von > Anforderungen und Projekten, Dokumentation von Ergebnissen und internem > Fachwissen, Beachtung von Normen und Richtlinien bereits beim Entwurf, > Fertigbarkeit (z.B. durch Beschränkung auf "Katalogteile"), > Langlebigkeit durch Second-Source sei unnötig. Wird auch gern über > Kollegen in der Firma gesagt. Das ist ein Schutzmechanismus des Gehirns, > der verhindert, dass man am eigenen Leben verzweifelt. Sollte man den > Schutzmechanismus überwinden, muss man viel weniger Feuerwehr spielen, > weil die Produkte zuverlässiger und weniger zufällig so funktionieren > wie sie sollen. > Ein Konzernbeamter wird erstmal drei Monate mit dem Kunden (oder > Vertrieb) diskutieren, welche Anforderungen der Kunde denn hat. etwas gekürzt, ich glaube zu verstehen was du meinst, habe es in einem KMU? aber anders erlebt, der Einkauf wich von den üblichen Kondensatoren ab die die Entwicklung vorgab, die gekauften Kondensatoren hatte ALLE -8% also im Rahmen des Erlaubten -10% aber am ICT/Kombitester welches nun kein Präzisionsmessgerät ist habe ich bestimmt 2 Monate Programmanpassung gehabt um die Baugruppen mit GUT über den Prüfplatz zu bekommen. Ich bin mir nicht sicher ob der gesparte 1/10 Pfennig pro Kondensator das wert war. Aber vielleicht ging es nicht um Kosteneinsparung sondern um die Begründung die Fertigung abzuwickeln weil zu teuer?
Der entscheidende Aspekt ist die Qualität für die man entwickelt. Hohe
Qualität heißt Reproduzierbarkeit und möglichst wenige Produktions- und
Feldfehler. Denn Fehler gehen ins Geld ("Fehlleistungskosten").
Welche Qualität man haben will und was es kostet sie zu erreichen hängt
auch von der gewünschten Stückzahl ab. Bei Stückzahl "1" ist das anders
als bei "1 Million".
Versuchen wir einen Vergleich:
Am Flugplatz steht ein selbergebasteltes Flugzeug wo der Pilot behauptet
es (und er) kann fliegen. Er dreht auch mal schnell eine kleine Runde.
Daneben steht ein mit tausenden Normen und Zulassungsvorschriften
geprüfter A320 (also auch die Elektronik und deren Entwicklung) und ein
Pilot der alle Prüfungen geschafft hat und das von einer amtlich
zugelassenen Fluggesellschaft.
Bei wem steigt man wohl ein, wenn man nur mal schnell von A nach B will?
Da kommt dann ein dritter Faktor ist Spiel: die Risikobereitschaft des
Kunden.
D.h. der Bastlerentwickler entwickelt für Stückzahl 1 und gerade
ausreichende Qualität und geht hohe Risiken ein (notfalls kehrt er die
Reste zusammen und bastelt ein neues Exemplar).
Der beamtete Entwickler entwickelt für hohe Stückzahlen in guter
Qualität (geringe Ausfallrate) und versucht damit (finanzielle) Risiken
zu minimieren. Deshalb hält er sich an Prozessvorschiften und löst nicht
jedes Problem durch Experimentieren.
Insofern gibt es kein "richtig" und "falsch". Jede dieser
Vorgehensweisen kann im Einzelfall angemessen sein.
:
Bearbeitet durch User
Nikolaus S. schrieb: > Versuchen wir einen Vergleich: > Am Flugplatz steht ein selbergebasteltes Flugzeug wo der Pilot behauptet > es (und er) kann fliegen. Er dreht auch mal schnell eine kleine Runde. > Daneben steht ein mit tausenden Normen und Zulassungsvorschriften > geprüfter A320 (also auch die Elektronik und deren Entwicklung) und ein > Pilot der alle Prüfungen geschafft hat und das von einer amtlich > zugelassenen Fluggesellschaft. Schlechter Vergleich, da für beide die gleichen Normen gelten. Der Unterschied zwischen Bastlern und Entwicklern ist, dass die Bastler zwar wissen, was Ende rauskommen soll, aber der Weg dorthin nicht unbedingt gradlinig erfolt. Entwickler planen mehr, weswegen der Weg zum Endprodukt gradliniger ist. Das erfordert Erfahrung und Wissen, das man sich u.a. durch Basteln aneignet.
@ STK500-Besitzer (Gast) >Der Unterschied zwischen Bastlern und Entwicklern ist, dass die Bastler >zwar wissen, was Ende rauskommen soll, aber der Weg dorthin nicht >unbedingt gradlinig erfolt. Entwickler planen mehr, weswegen der Weg zum >Endprodukt gradliniger ist. Das erfordert Erfahrung und Wissen, das man >sich u.a. durch Basteln aneignet. Es fehlen noch zwei wichtige Eigenschaften. (Selbst)Disziplin und Ordung. Denn auch die fehlen einigen Profis in erheblichem Maße.
STK500-Besitzer schrieb: > Nikolaus S. schrieb: >> Versuchen wir einen Vergleich: >> Am Flugplatz steht ein selbergebasteltes Flugzeug wo der Pilot behauptet >> es (und er) kann fliegen. Er dreht auch mal schnell eine kleine Runde. >> Daneben steht ein mit tausenden Normen und Zulassungsvorschriften >> geprüfter A320 (also auch die Elektronik und deren Entwicklung) und ein >> Pilot der alle Prüfungen geschafft hat und das von einer amtlich >> zugelassenen Fluggesellschaft. > > Schlechter Vergleich, da für beide die gleichen Normen gelten. Gelten schon, aber ein Bastlerpilot hält sich nicht an alle (kann es aus Kapazitätsgründen auch gar nicht)... Und der Unterschied ist ob die Normeinhaltung geprüft wird oder nicht. Außerdem ziele ich gar nicht auf das Gelten von Normen, sondern das Ergebnis. Ob man dem vertraut oder nicht. Und das macht den Unterschied.
Falk B. schrieb: > @ STK500-Besitzer (Gast) > >>Der Unterschied zwischen Bastlern und Entwicklern ist, dass die Bastler >>zwar wissen, was Ende rauskommen soll, aber der Weg dorthin nicht >>unbedingt gradlinig erfolt. Entwickler planen mehr, weswegen der Weg zum >>Endprodukt gradliniger ist. Das erfordert Erfahrung und Wissen, das man >>sich u.a. durch Basteln aneignet. > > Es fehlen noch zwei wichtige Eigenschaften. (Selbst)Disziplin und > Ordung. Denn auch die fehlen einigen Profis in erheblichem Maße. Genau das erzwingt ein beamtenartiges Regelwerk im Großkonzern, wenn die Selbstdisziplin und ein Ordnungssinn fehlt. Allerdings gelingt das nicht perfekt :) Auch im Großkonzern finden Leute immer Wege die Regeln zu umgehen, vor allem wenn es höhere Chefs sind... Und wundern sich warum trotz teuer per Berater eingeführten formalen Prozessen etwas schief geht.
:
Bearbeitet durch User
Zitat Mythbusters: "Der Unterschied zwischen Spielerei und Wissenschaft? Man schreibt sich Dinge auf"
"Entwickeln" wird für 2 verschiedene Dinge verwendet. a) im Sinne von Erfinden: etwas neues, kreatives (das erste IPhone, eine App zum Mäusemelken, ...) b) etwas Neues gemäß Stand der Technik bauen (Ein aktuelles IPhone in billig, eine 34te Version der Mäusemelk-App) V-Modell geht zum Beispiel nur für b) (siehe z.B. SIL 61508 etc.) Bei a) ist immer auch basteln mit dabei. Dazu kommen noch Stüchzahlen bzw. Auftragsvolumen: Bei 1 Mio Devices zu 10€ steckt man halt ein bisschen mehr Überlegung in das Design als bei 2-3 Einzel-Geräte zu 1000€. Ob der BER nun gebastelt oder entwickelt oder nur einfach (nicht) gebaut wird, ist dann wieder Sprachspielerei.
Nikolaus S. schrieb: > Genau das erzwingt ein beamtenartiges Regelwerk im Großkonzern, wenn die > Selbstdisziplin und ein Ordnungssinn fehlt. Nur, dass dort die Verwaltung gerne mal den Entwicklungsprozess ausbremst/behindert. Nikolaus S. schrieb: > Gelten schon, aber ein Bastlerpilot hält sich nicht an alle (kann es aus > Kapazitätsgründen auch gar nicht)... Dann wird er auch keine Aufstiegsgenehmigung bekommen - zumindest nicht in Deutschland.
STK500-Besitzer schrieb: > Nikolaus S. schrieb: >> Genau das erzwingt ein beamtenartiges Regelwerk im Großkonzern, wenn die >> Selbstdisziplin und ein Ordnungssinn fehlt. > > Nur, dass dort die Verwaltung gerne mal den Entwicklungsprozess > ausbremst/behindert. Kommt drauf an - manchmal ist das im Sinne des Kunden (eben kein "machen wir doch schnell mal so wie immer"). Manchmal natürlich nicht ("fülle mir noch dieses und jenes Formular aus"). Aber letzteres kann wichtig werden, wenn der Kunde 2 Jahre später kommt und behauptet das wäre ja nicht ordentlich entwickelt worden. Nur weiß das niemand vorher ob er kommt - und wenn der Kunde zufrieden ist, sieht es nach unnötiger Arbeit aus.
:
Bearbeitet durch User
STK500-Besitzer schrieb: > Nikolaus S. schrieb: >> Genau das erzwingt ein beamtenartiges Regelwerk im Großkonzern, wenn die >> Selbstdisziplin und ein Ordnungssinn fehlt. > > Nur, dass dort die Verwaltung gerne mal den Entwicklungsprozess > ausbremst/behindert. Ach, ausbremsen...es ist halt schon ein Unterschied ob man für seine Arbeit unterschreibt (z.B. nach einem Review) oder in der Anonymität seiner Abteilung einfach untergeht.
ChristophS schrieb: > Pete K. schrieb: >> Also z.B. so etwas wie V-Modell, RUP oder Agile im >> Softwarebereich? >> Oder z.B. NGOSS im Telko-Umfeld; ITIL für Betriebsprozesse? > > einfach mal alles rausgehauen was du irgendwie noch ausm Studium im Kopf > hattest mit der Hoffnung, wir coolen Jungs denken du hast was drauf. > Falsch gedacht. Nein, bis auf RUP habe ich mit allen Prozessen fast täglich zu tun. :-) P.S.: In welchem Studium kann man so etwas lernen?
:
Bearbeitet durch User
Duden: Basteln 1.) sich [in der Freizeit] aus Liebhaberei mit der handwerklichen Anfertigung verschiedener kleiner Dinge beschäftigen 2.) durch kleinere Handwerksarbeiten [als Hobby] herstellen, [nach eigenen Ideen] anfertigen sich an etwas handwerklich oder technisch betätigen, was man verbessern, um- oder ausbauen will Wenn man einen Entwickler denunzieren möchte dann nennt man ihn Bastler. Denn nur das Diplom auf dem Papier berechtigt mancherlei Aufgabe professionell nachgehen zu können. Würde eine Person welche dich als Bastler mit negativer Konnotation bezeichnet begründete Kritik an deiner Methodenkompetenz haben, wäre aber selbst im Besitz der Selben, wäre die Kritik sicher nicht „Bastler“ sondern etwas konkreter. In diesem Fall wäre das Problem aber auch schnell behoben da lokalisiert und erkannt. Also das ist einfach affentheater und jemand lässt der sowas sagt ist entweder inkompetent oder er traut sich nicht direkt a.......h zu dir zu sagen...
Wühlhase schrieb: > Pet schrieb: >> Mich interessiert sehr, wie der grobe Entwicklungsprozess (Beispiel >> Elektronik Hardwareentwicklung) bei euch in der Firma aussieht. > Schau dir einfach mal ein paar Diskussionen nebenan im Platinenforum an. > Oder-ganz frisch-das hier: > Beitrag "Freilaufdiode auf Platine platzieren?" > > Der Unterschied zwischen Gefrickel und richtiger Entwicklung liegt > meines Erachtens im methodischen Vorgehen. > > Der Bastler frickelt etwas zusammen, irgendwie funktioniert es, aber so > wirklich weiß er nicht was er da getan hat. Merkt man sehr schnell, wenn > man "warum" fragt. > > Der Entwickler weiß vorher was er da macht und was es machen soll. > Manchmal weiß er es nicht (z.B. weil keine Zeit zum Entwickeln ist), > aber dann weiß er auch daß er es nicht weiß. Schau dir dazu mal die > Beiträge von Falk im verlinkten Thread an. Und vergleiche diese von dem > "mit felderfahrung". Sehr schön gesagt und es bestätigt meine Sichtweise als Entwickler. Da ich selbst so ein Typ bin, der andere gerade erfahrene Entwickler nach dem "Warum" fragt, denke ich mir bei meiner Tätigkeit immer "Was passiert, wenn Dich jetzt ein Praktikant nach dem Grund fragt? Kannst Du den Grund nennen, warum du es so gemacht hast?" Und das ist ganz wichtig und gehört meiner Meinung nach zur Integrität eines Entwicklers. Ein Entwickler muss wissen, was er da tut und wenn er es nicht genau weiß sollte er jemanden fragen, der es wissen könnte.
Schön schrieb: > Ein Entwickler muss wissen, was er da tut und wenn er es nicht genau > weiß sollte er jemanden fragen, der es wissen könnte. Im Laufe der Jahre stumpft man aber ab und schaut nur noch aufs Geld, das jeden Monat überwiesen wird. So meine Beobachtung. Der hohe Anspruch an sich selbst hängt meist mit Idealismus zusammen, der vor allem bei Anfängern zu finden ist. Irgendwann holt sie aber die Realität ein. Hinzu kommt, dass solche Tugenden selten vom Management geschätzt werden, Hauptsache das Projekt ist in time und in budget.
Schön schrieb: > dem "Warum" fragt, denke ich mir bei meiner Tätigkeit immer "Was > passiert, wenn Dich jetzt ein Praktikant nach dem Grund fragt? Kannst Du > den Grund nennen, warum du es so gemacht hast?" Richtig! Wer sich nicht ständig hinterfragt, wird nie auf Verbesserungen kommen oder Probleme finden. Ich bin schon oft auf Dinge gekommen, die ich jahrelang falsch gemacht habe. Einfach weil ein Kollege "warum machst du das so" gefragt hat. Bei der Erklärung kommt man dann ins Grübeln. Ich schreibe das "warum so" deswegen in die Dokumentation, und komme so auf viele Fehler. Ähnliches gilt für Forenbeiträge. Bei 70% der Fragen, die ich hier stellen wollte, ist mir beim genauen Beschreiben des Problems dann die Lösung eingefallen. Einfach, weil ich das Problem genau beschreiben musste.
Heinrich schrieb: > Hinzu kommt, dass solche Tugenden selten vom Management geschätzt > werden, Hauptsache das Projekt ist in time und in budget. Das Management sieht es ja immer anders als das Engineering und das ist ja die Quintessenz dieses Threads. Als Entwickler muss man dann jedoch das Management über die möglichen Risiken aufklären und das auch entsprechend dokumentieren, um seinen Arsch an die Wand zu bekommen. Ich habe mir schon öfters in Gesprächen mit dem Management gedacht "Ich hab dich aufgeklärt, es dokumentiert, dass ich dich aufgeklärt habe und du musst die CE-Erklärung unterschreiben".
Heinrich schrieb: > Im Laufe der Jahre stumpft man aber ab und schaut nur noch aufs Geld, > das jeden Monat überwiesen wird. So meine Beobachtung. > Der hohe Anspruch an sich selbst hängt meist mit > Idealismus zusammen, der vor allem bei > Anfängern zu finden ist. Irgendwann holt sie aber > die Realität ein. Ich behaupte an dieser Stelle, dass die Förderung und Aufgabengebiete der Mitarbeiter einen großen Teil dazu beitragen, dass man abstumpft und die Motivation nachlässt. 1. Die Mentalität vieler (älteren) Arbeitnehmer ist, dass man arbeitet, um am Monatsende seine Miete bezahlen zu können. Interesse und Spaß an den Aufgaben stehen dabei oft an zweiter Stelle. 2. Viel Entwicklung findet auf einem recht niedrigen theoretischen Niveau statt. Ein tiefgründiges, theoretisches Wissen bedarf intensivem Lernen, für das man auf Arbeit keine Zeit hat, weil das Projekt fortgeführt werden muss. In seiner Freizeit hat man allerdings andere Sachen zu tun, wie zB Einkauf / Kochen, Hobbys, Familie, Freunde etc. Am Abend fehlt dann die nötige Energie und Motivation, nochmal das Buch aufschlagen und die Mathematik / Theorie zu lernen. Die Konsequenz ist, dass viel nach Try & Error gearbeitet wird, sobald das Produkt mehr tiefgründiges Spezialwissen fordert. > Hinzu kommt, dass solche Tugenden selten vom > Management geschätzt > werden, Hauptsache das Projekt ist in time und in budget Und genau da beißt sich die Katze in den eigenen Schwanz. Die Erfahrung habe ich jetzt in zwei großen Unternehmen wahrnehmen müssen. Und viel spiegelt sich auch hier im Forum wider. Gruß,
Entwickeln ist: * Man bekommt eindeutige schriftliche Vorgaben (Lastenheft) * Nach einer deadline gibt es keine Änderungen mehr, die fließen ins Redesign ein. * Die Vorgaben sind funktionaler Art, die Realisation obliegt dem Entwickler * Absprache der Realisation mit dem Auftraggeber. Kann auch das eigene Produktmarketing sein (Pflichtenheft) * Realisation eines Entwicklungsmusters, Fertigung einer ausreichender Zahl von Platinen * Inbetriebnahme aller Komponenten. * Verifikation der Entwicklung. Compliance-Tests, EMV, Klimaschrank etc. * Herausgabe der getesteten Entwicklungsmuster an Auftraggeber * Iteration wegen Fehlerbeseitigung und Optimierung * Serienfreigabe des Auftragnehmers * Serientest aufsetzen * Serienstart begleiten * Fertig Basteln: * Keine eindeutige Vorgaben. Man bekommt Anforderungen mündlich, jeder darf mitlabern * Änderungen auf Zuruf, jeder darf mal. Natürlich nicht mit dem Rest abgesprochen * Es wird zu wenig Hardware gefertigt. Die Entwicklungsmuster werden dem Entwickler vom Tisch geklaut um sie auf der IoT-Superworld-Messe auszustellen. Der Vertrieb beschwert sich daß die Muster nicht funktionieren. * Es gibt keine Testaufbauten und Messgeräte um alle Komponenten in Betrieb zu nehmen. * Die Inbetriebnahme wird abgebrochen und die Muster an den Auftraggeber gegeben * Iteration Fehlerbeseitigung/Inbetriebnahme * Serienfertigung, Shipping * Test wird an jemanden abgedrückt der mit der Entwicklung nichts zu tun hat * Ärger ohne Ende, Fehler von Kunden gefunden etc.
Michael X. schrieb: > Entwickeln ist: > Basteln: Meine Meinung. Beides kenne ich sogar innerhalb eines Unternehmens.
Michael X. schrieb: > Entwickeln ist: > * Man bekommt eindeutige schriftliche Vorgaben (Lastenheft) > * Nach einer deadline gibt es keine Änderungen mehr, die fließen ins > Redesign ein. > * Die Vorgaben sind funktionaler Art, die Realisation obliegt dem > Entwickler > * Absprache der Realisation mit dem Auftraggeber. Kann auch das eigene > Produktmarketing sein (Pflichtenheft) > * Realisation eines Entwicklungsmusters, Fertigung einer ausreichender > Zahl von Platinen > * Inbetriebnahme aller Komponenten. > * Verifikation der Entwicklung. Compliance-Tests, EMV, Klimaschrank etc. > * Herausgabe der getesteten Entwicklungsmuster an Auftraggeber > * Iteration wegen Fehlerbeseitigung und Optimierung > * Serienfreigabe des Auftragnehmers > * Serientest aufsetzen > * Serienstart begleiten > * Fertig Wer daran glaubt, fällt schon wieder unter Amateur/Bastler. Gruss Axel
Axel L. schrieb: > Wer daran glaubt, fällt schon wieder unter Amateur/Bastler. Falsch. Wenn, dann unter die Kategorie Theoretiker.
Heinrich schrieb: > Axel L. schrieb: >> Wer daran glaubt, fällt schon wieder unter Amateur/Bastler. > > Falsch. Wenn, dann unter die Kategorie Theoretiker. Die auch. Aber die Amateure/Bastler glauben, dass es bei den Profies so liefe. Gruss Axel
Axel L. schrieb: > Heinrich schrieb: >> Axel L. schrieb: >>> Wer daran glaubt, fällt schon wieder unter Amateur/Bastler. >> >> Falsch. Wenn, dann unter die Kategorie Theoretiker. > > Die auch. Aber die Amateure/Bastler glauben, dass es bei den Profies so > liefe. Tut es ja auch. Nicht immer 100%ig und perfekt, aber die grobe Marschrichtung stimmt. Oder besagte Profis sind eben...naja, keine Entwickler. ;)
Wühlhase schrieb: > Axel L. schrieb: >> Heinrich schrieb: >>> Axel L. schrieb: >>>> Wer daran glaubt, fällt schon wieder unter Amateur/Bastler. >>> >>> Falsch. Wenn, dann unter die Kategorie Theoretiker. >> >> Die auch. Aber die Amateure/Bastler glauben, dass es bei den Profies so >> liefe. > Tut es ja auch. Nicht immer 100%ig und perfekt, aber die grobe > Marschrichtung stimmt. > Oder besagte Profis sind eben...naja, keine Entwickler. ;) Womit Du Dich eindeutig eingeordnet hättest :) Aber die Projekte, bei denen: > * Nach einer deadline gibt es keine Änderungen mehr, zutrifft, sind allenfalls Projekte, an denen keiner irgendein Interesse hat. Die kann man dann natürlich in aller Ruhe nach den goldenen Regeln abwickeln, allerdings fehlt dann in der Regel: > * Serienstart begleiten Gruss Axel
:
Bearbeitet durch User
Axel L. schrieb: > Aber die Projekte, bei denen: >> * Nach einer deadline gibt es keine Änderungen mehr, > zutrifft, sind allenfalls Projekte, an denen keiner irgendein Interesse > hat. Die kann man dann natürlich in aller Ruhe nach den goldenen Regeln > abwickeln, allerdings fehlt dann in der Regel: >> * Serienstart begleiten Du hast den Teil mit dem Redesign unterschlagen. Denn wer aus Erfahrung weiß das mit dem ersten Prototypen unweigerlich sowieso Änderungswünsche kommen (z.B. weil der Kunde erst dann die richtige Phantasie entwickelt), der weiß das ein harter Schnitt irgendwann sein muß, sonst wird es einfach nicht fertig. Änderungswünsche werden dann umgesetzt wenn es in den Designzyklus passt, und nicht wenn es teuer und das Gesamtergebnis versaut wird. Was es auch gibt sind sicherheitskritische Projekte, wo kleinste Änderungen dafür sorgen, daß diese von 2 weiteren Leuten reviewt, von anderen dokumentiert (einschl. Doku-Review) und zig Entscheidern abgesegnet werden müssen. Da sortiert man Änderungen erst nach notwendig ja/nein und sammelt diese, um sie zu einem geeigneten Design-Zeitpunkt einfließen zu lassen. Falls man Erweiterungen überhaupt zulässt.
Wühlhase schrieb: > Axel L. schrieb: >> Aber die Projekte, bei denen: >>> * Nach einer deadline gibt es keine Änderungen mehr, >> zutrifft, sind allenfalls Projekte, an denen keiner irgendein Interesse >> hat. Die kann man dann natürlich in aller Ruhe nach den goldenen Regeln >> abwickeln, allerdings fehlt dann in der Regel: >>> * Serienstart begleiten > Du hast den Teil mit dem Redesign unterschlagen. Denn wer aus Erfahrung > weiß das mit dem ersten Prototypen unweigerlich sowieso Änderungswünsche > kommen (z.B. weil der Kunde erst dann die richtige Phantasie > entwickelt), der weiß das ein harter Schnitt irgendwann sein muß, sonst > wird es einfach nicht fertig. Änderungswünsche werden dann umgesetzt > wenn es in den Designzyklus passt, und nicht wenn es teuer und das > Gesamtergebnis versaut wird. > > Was es auch gibt sind sicherheitskritische Projekte, wo kleinste > Änderungen dafür sorgen, daß diese von 2 weiteren Leuten reviewt, von > anderen dokumentiert (einschl. Doku-Review) und zig Entscheidern > abgesegnet werden müssen. > Da sortiert man Änderungen erst nach notwendig ja/nein und sammelt > diese, um sie zu einem geeigneten Design-Zeitpunkt einfließen zu lassen. > Falls man Erweiterungen überhaupt zulässt. Änderungen müssen professionell gemanaged werden, das gilt nicht nur bei sicherheitskritischen Projekten, sondern bei allen. Das heißt aber nicht, dass es nach einer Deadline keine Änderungen mehr gibt, ein Produkt, was nachher nicht marktfähig ist, nützt auch nichts. Und es gilt natürlich, daß je später die Änderung kommt, sie um so teurer ist. Das verstehen letztlich auch Kunden, man muss das dann entsprechend kommunizieren. Die Dringlichkeit eines Änderungswunsches muss dann eben im Laufe des Projektes immer weiter ansteigen, damit dieser noch berücksichtigt wird. Aber die Vorstellung, dass man nach eine Deadline in Ruhe vor sich hin werkeln kann, ist schon sehr theoretisch. Gruß Axel
Axel L. schrieb: > Änderungen müssen professionell gemanaged werden, das gilt nicht nur bei > sicherheitskritischen Projekten, sondern bei allen. Genau dafür gibt es ja ein Change Control Board, das kümmert sich schon darum. Wie, das gibt es in einer Frickelbude nicht? Haben die dann wenigstens ein Ticket System und Versionsverwaltung, sowie Continuous Integration?
Michael X. schrieb: > * Nach einer deadline gibt es keine Änderungen mehr, die fließen ins > Redesign ein. > * Die Vorgaben sind funktionaler Art, die Realisation obliegt dem > Entwickler Ich sehe du hast wohl noch nicht in der Automobilindustrie gearbeitet. Das schaffen selbst OEMs mit Bosch und Conti nicht.
Michael X. schrieb: > * Es wird zu wenig Hardware gefertigt. Die Entwicklungsmuster werden dem > Entwickler vom Tisch geklaut um sie auf der IoT-Superworld-Messe > auszustellen. Der Vertrieb beschwert sich daß die Muster nicht > funktionieren. Yupp, kommt mir bekannt vor. Bei meinem letzten Arbeitgeber lief das genau so. Da gabs zum Beispiel den Messeheini, der Nächtens durch die Entwicklungsabteilung schlich, und sich seine Aufbauten zusammengeklaut hat. Aber nicht nur, die Diebe schlichen immer herum. Ich habe dann mal "Giftköder" ausgelegt. Also Hardware mit fatalen Fehler - 24V in der 5V-Versorung. Natürlich brav mit "defekt" Beschriftung, die aber schlaue Diebe nicht abhält. Da mir der Prüfmittelbau netterweise 300 solcher "Giftköder" produziert hat (ein "innovatives" Testverfahren), war das kein Problem. Mir wurden bis zu meinem Weggang von der Firma satte 20 geklaut. Und an Kunden geliefert, was man so hörte. Übrigens war das kein Kleinunternehmen, so mit >2000 Mitarbeitern...
Pet schrieb: > lese hier im Forum immer wieder, dass in kleinen Firmen > eher gebastelt und nicht „richtig“ entwickelt wird. Haha. ;-) Auch im Konzern kann es dir passieren, dass du das nächste Entwicklungstool erstmal aus Pappe (oder in Pappe) baust. Oder den Drahtverhau mit zusammengeklebten Smartphones in irgendwelche Ikea-Schränke schraubst. Der Unterschied ist nur, dass das dann nicht "Produkt" heißt und nicht verkauft wird, sondern die nächsten zwei Jahre in der Schublade landet. Und vielleicht dann produktifiziert wird.
Das ist mir vor 10 Jahren passiert. Hatte nur drei Monate Zeit um ein HDMI/SMS Demo Gerät mit ARM7TDI Controller und TFT/TS Display für eine Industrie Messe auf die Beine zu stellen. Konnte dann nur hübsche, kompliziert anzuschauende, bunte Graphiken mit simulierten Daten anzeigen. Den Frontplattenrahmen ließen wir als 3D Druck herstellen. Aber es hat gereicht um das Interesse der Kunden zu erwecken. Das wirkliche Gerät wird heute noch als Industrie Produkt für den Energiesektor produziert und verkauft sich nach 10 Jahren immer noch gut. Manchmal muß man halt solche Sachen angreifen.
Du meinst das, was in der KI-Szene gerade üblich ist? https://www.theguardian.com/technology/2018/jul/06/artificial-intelligence-ai-humans-bots-tech-companies
Gerhard O. schrieb: > Das ist mir vor 10 Jahren passiert. Hatte nur drei Monate Zeit um ein > HDMI/SMS Demo Gerät mit ARM7TDI Controller und TFT/TS Display für eine > Industrie Messe auf die Beine zu stellen. Konnte dann nur hübsche, > kompliziert anzuschauende, bunte Graphiken mit simulierten Daten > anzeigen. Den Frontplattenrahmen ließen wir als 3D Druck herstellen. > Aber es hat gereicht um das Interesse der Kunden zu erwecken. Das > wirkliche Gerät wird heute noch als Industrie Produkt für den > Energiesektor produziert und verkauft sich nach 10 Jahren immer noch > gut. Manchmal muß man halt solche Sachen angreifen. Auch das ist ein schönes Beispiel für den Unterschied zwischen "Entwickeln" und "Basteln". Für Entwickler ist klar: Das ist ein Messemuster, das macht hübsch bunt, hat wenig Aufwand gekostet, funktioniert aber nicht (oder nur zufällig) - was für ein Messemuster genau das richtige ist. Das Produkt, was funktionieren soll, bauen wir von Grund auf neu, unter Beachtung aller externen und internen Standards für ein Produkt. Für Bastler gilt der Meister-Röhrich-Spruch "Das ist doch noch gut". Hat auf der Messe ja schon was abngezeigt, dann können wir es ja schon verkaufen und dem Kunden anschließend per Firmware-Update die Funktion nachliefern. Egal nach welchen Standards das Messemuster gebaut wurde. MfG, Arno
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.