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!
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).
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.
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.
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.
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 :)
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.
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.
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.
"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.
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?
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:> * 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
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
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.
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
