Forum: Ausbildung, Studium & Beruf Richtig entwickeln vs. basteln?


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


Bewertung
1 lesenswert
nicht lesenswert
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

von ChristophS (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.
von Mad (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Richtig vermutet - das war nur unser bekannter Forentroll Matthis ;-)

von Jerry (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
> Richtig vermutet - das war nur unser bekannter Forentroll Matthis
> ;-)

Woran erkennt ihr den? Session / IP?
Benutzt der VPN?

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
An der permanenten Wiederholung derselben ähnlichen Texte, das kann 
jedes Skript ;-)

Und hier natürlich, weil das vollkommen am Thema vorbei war.

von Jerry (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Max S. (maximus-minimus)


Bewertung
0 lesenswert
nicht lesenswert
?!? jeder..Router neu starten, Proxys etc pp
Verschiedene IPs, Cookies löschen, z.B...

: Bearbeitet durch User
von Test (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Michael B. (laberkopp)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Cyblord -. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
https://medium.freecodecamp.org/the-two-types-of-programmers-hackers-vs-academics-514044ed40c

Je nach Einsatzzweck ist das eine oder das andere passender.

von RESEARCH SERVICES (Gast)


Bewertung
6 lesenswert
nicht lesenswert
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.

von Dirk K. (knobikocher)


Bewertung
0 lesenswert
nicht lesenswert
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
von SW I. (sw-ing)


Bewertung
12 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
-3 lesenswert
nicht lesenswert
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%

von Hello (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Pete K. (pete77)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Possetitjel (Gast)


Bewertung
7 lesenswert
nicht lesenswert
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.

von Al3ko -. (al3ko)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Pete K. (pete77)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Wühlhase (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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".

von Possetitjel (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Dirk K. (knobikocher)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Arno (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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

von Georg A. (georga)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Trouble (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von SW I. (sw-ing)


Bewertung
0 lesenswert
nicht lesenswert
Arno schrieb:
> Danke für die Vorlage ;)

Gerne, gut zurück getrollt.

von MAd (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Es hätte ernsthaft werden können, ist aber wieder auf Hauptschulniveau 
gelandet.

von Dumdi D. (dumdidum)


Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> "durchgespec'd

Sobald Doors verwendet wird auf jeden fall...

von ChristophS (Gast)


Bewertung
4 lesenswert
nicht lesenswert
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.
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Bewertung
0 lesenswert
nicht lesenswert
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
von STK500-Besitzer (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
1 lesenswert
nicht lesenswert
@ 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.

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Bewertung
0 lesenswert
nicht lesenswert
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
von Chris K. (deadeye5589)


Bewertung
6 lesenswert
nicht lesenswert
Zitat Mythbusters:

"Der Unterschied zwischen Spielerei und Wissenschaft? Man schreibt sich 
Dinge auf"

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
"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.

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Wühlhase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Pete K. (pete77)


Bewertung
0 lesenswert
nicht lesenswert
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
von Titus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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...

von Schön (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Heinrich (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von soso... (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Schön (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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".

von Al3ko -. (al3ko)


Bewertung
0 lesenswert
nicht lesenswert
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ß,

von Michael X. (Firma: vyuxc) (der-michl)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Dirk K. (knobikocher)


Bewertung
0 lesenswert
nicht lesenswert
Michael X. schrieb:
> Entwickeln ist:

> Basteln:

Meine Meinung.

Beides kenne ich sogar innerhalb eines Unternehmens.

von Axel L. (axel_5)


Bewertung
0 lesenswert
nicht lesenswert
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

von Heinrich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Axel L. schrieb:
> Wer daran glaubt, fällt schon wieder unter Amateur/Bastler.

Falsch. Wenn, dann unter die Kategorie Theoretiker.

von Axel L. (axel_5)


Bewertung
0 lesenswert
nicht lesenswert
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

von Wühlhase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. ;)

von Axel L. (axel_5)


Bewertung
0 lesenswert
nicht lesenswert
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
von Wühlhase (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Axel L. (axel_5)


Bewertung
0 lesenswert
nicht lesenswert
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

von Heinrich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von asdfg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von soso... (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
2 lesenswert
nicht lesenswert
If you cant't make it, fake it!

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert

von Arno (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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