Forum: Ausbildung, Studium & Beruf Arbeitet ihr mit Checklisten?


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 Der Checker vom Neckar (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Hallo Leute,

mich würde interessieren ob ihr Checklisten benutzt um Schaltpläne oder 
Layouts zu prüfen?
Wenn ja, habt ihr die selbst erstellt oder ist sie in der Firma 
gewachsen?
Oder nutzt ihr online verfügbare Listen? Wenn ja, welche?

Danke.

Beitrag #6393415 wurde von einem Moderator gelöscht.
von Voight-Kampff untested (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der Checker vom Neckar schrieb:

> mich würde interessieren ob ihr Checklisten benutzt um Schaltpläne oder
> Layouts zu prüfen?

Ja und Nein,

also man hat schon so seine Kriterien nach dem man die Dokumente 
systematisch prüft. Aber die müssen nicht unbedingt als Liste 
niedergeschrieben sein, so was hat man vom Studium und Beruf als 
Erfahrung im Kopf.

Ich glaube auch nicht, das eine fremde' Checkliste viel nutzt, wenn man 
nicht selbst versteht ,warum da steht "Kriechstrecke für Anwendung Peru 
überprüft"

Der beste Weg zu einer Checkliste ist der, eine selbst zu beginnen und 
mit jedem erkannten Fehler zu erweitern.

Andernfalls heisst es stur
"Das muss funktionieren, das Layout ist doch nach Checklist gemacht"
auch wenn die Störberichte aus dem Feld sich inzwischen bis zur Decke 
stapeln.

von Der Checker vom Neckar (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Voight-Kampff untested schrieb:
> Der beste Weg zu einer Checkliste ist der, eine selbst zu beginnen und
> mit jedem erkannten Fehler zu erweitern.

Ist das wirklich der beste Weg? Wieviele Fehler darfst du machen bis 
dein Chef meckert? Als Anfänger braucht man dann ja 100 Iterationen bis 
man die Standardfehler alle mal durch hat.

von Rudolf (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Der Checker vom Neckar schrieb:
> Ist das wirklich der beste Weg? Wieviele Fehler darfst du machen bis
> dein Chef meckert?

Bei manchen Firmen ist die Anzahl der zulässigen Fehler stark begrenzt. 
Damals als Werkstudent habe ich drei Fehler in meinem Layout gehabt. 
Danach wurde ich leider schon gekündigt.

MfG

von Voight-Kampff untested (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der Checker vom Neckar schrieb:
> Voight-Kampff untested schrieb:
>> Der beste Weg zu einer Checkliste ist der, eine selbst zu beginnen und
>> mit jedem erkannten Fehler zu erweitern.
>
> Ist das wirklich der beste Weg? Wieviele Fehler darfst du machen bis
> dein Chef meckert? Als Anfänger braucht man dann ja 100 Iterationen bis
> man die Standardfehler alle mal durch hat.

Ja, deshalb sollte man ja auch möglichst früh mit Schaltplan zeichnen 
anfangen und nicht erst nach dem Hochschulabschluß.
Und Chef meckert erst wenn die Budgetgrenze für "Lehrgeld" erreicht ist.

Wenn man immer nur nach fremdem checklists nachbaut, ist man irgendwann 
soweit verblödet das man nicht mal mehr nachbauen kann. Beispiel: 
russische Mikroelektronik.
http://www.deutsches-museum.de/fileadmin/Content/010_DM/060_Verlag/060_KuT/2015/2_15_Spionage/Dittmann_web.pdf

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Voight-Kampff untested schrieb:
> also man hat schon so seine Kriterien nach dem man die Dokumente
> systematisch prüft. Aber die müssen nicht unbedingt als Liste
> niedergeschrieben sein, so was hat man vom Studium und Beruf als
> Erfahrung im Kopf.

Die allermeisten Sachen hat man zwar noch im Kopf, aber irgendein Detail 
vergisst man dann doch recht schnell. Daher habe ich mir entsprechende 
Checklisten angelegt.

Es gibt auch hinreichend gute Gründe dafür, dass Piloten bei fast allen 
Handlungen nach Checkliste arbeiten und nur ausnahmsweise nach sog. 
"memory items", sogar bei den völlig alltäglichen Handlungen, die sie 
schon tausendmal ausgeführt haben.

> Ich glaube auch nicht, das eine fremde' Checkliste viel nutzt, wenn man
> nicht selbst versteht ,warum da steht "Kriechstrecke für Anwendung Peru
> überprüft"

Natürlich ist nicht jede fremde Checkliste gut; daraus aber zu 
schließen, fremde Checklisten seien per se Mist, ist völliger Unsinn. 
Gerade bei Leiterplatten ist es sehr sinnvoll, noch einmal unmittelbar 
vor der Freigabe eines Standes die tagesaktuell gültigen 
Fertigungsparameter des konkret gewählten Leiterplattenherstellers zu 
prüfen.

> Der beste Weg zu einer Checkliste ist der, eine selbst zu beginnen und
> mit jedem erkannten Fehler zu erweitern.

Man muss sie nicht neu beginnen, sondern sie kann sinnvollerweise auch 
auf anderen Listen und Erfahrungen aufbauen. Außerdem ist es sinnvoll, 
nicht nur erkannte Fehler zu berücksichtigen, sondern auch allgemein 
bekannte bzw. sinnvolle Regeln, um zukünftige Fehler zu vermeiden. Die 
Checkliste soll ja nicht nur zur historischen Dokumentation dienen, 
sondern insbesondere für zukünftige Projekte eingesetzt werden.

Bei strenger Auffassung Deiner Vorgehensweise liefe es wie folgt:

Chef/Kunde: "Warum ist denn schon wieder ein Fertigungslos Leiterplatten 
in die Tonne gewandert? Und warum haben Sie überhaupt die Leiterplatten 
bestellt?"

Voight-Kampff: "Ich war damit beschäftigt, unsere Checklisten für 
Leiterplatten zu erweitern. Gemäß Vorgabe dürfen aber nur begangene 
Fehler in die Checkliste aufgenommen werden. Bei diesen Leiterplatten 
habe ich daher zu kleine Bohrlöcher verwendet, bei jenen Leiterplatten 
fehlen die Innenlagen, und schauen Sie mal hier: gespiegelter 
Kennzeichnungsdruck. Und dort haben wir fehlende Teardrops."

> Andernfalls heisst es stur
> "Das muss funktionieren, das Layout ist doch nach Checklist gemacht"
> auch wenn die Störberichte aus dem Feld sich inzwischen bis zur Decke
> stapeln.

Genau das heißt es nicht. Die Checklisten stellen nur die 
Minimalanforderungen dar.

: Bearbeitet durch User
von Voight-Kampff untested (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
>> Andernfalls heisst es stur
>> "Das muss funktionieren, das Layout ist doch nach Checklist gemacht"
>> auch wenn die Störberichte aus dem Feld sich inzwischen bis zur Decke
>> stapeln.
>
> Genau das heißt es nicht. Die Checklisten stellen nur die
> Minimalanforderungen dar.

Minimal für was? Wenn es heissen soll das eine komplette Abarbeitung der 
checklist nur zu 90% Fehlerfreiheit garantiert und restlichen 10% adhoc 
gefunden werden müssen, dann sprichst es IMHO gerade dafür, das der 
Layouter sich die Checklist selbst erarbeiten muß, den nur so ist er 
befähigt auch die fehlenden 10% nachzutragen.

>Es gibt auch hinreichend gute Gründe dafür, dass Piloten bei fast allen
>Handlungen nach Checkliste arbeiten und nur ausnahmsweise nach sog.
>"memory items", sogar bei den völlig alltäglichen Handlungen, die sie
>schon tausendmal ausgeführt haben.

Naja auch die 'Challenger' ist 77 sec nach Abarbeitung der checklist 
explodiert. Grund: Keiner bei den NASA-Verantwortlichen wollte wissen, 
das Dichtungsringe im Frost drastisch an Qualität verlieren.

Die Checklist beim Flieger ist eine simple Abfolge von simplen Handlung 
(Knopf "Fahrwerk raus" gedrückt, Lampen "Fahrwerk eingerastet" an),
so ne Layout/Schaltplan-prüfung verlangt aber mehr KnowHow als Knöpfchen 
drücken und Lampen beobachten. Und diese KnowHow steht nicht auf der 
Liste, im Gegenteil man geht davon aus das der Listen-Nutzer 
qualifiziert ist, diese richtig anzuwenden.

>> Ich glaube auch nicht, das eine fremde' Checkliste viel nutzt, wenn man
>> nicht selbst versteht

>Natürlich ist nicht jede fremde Checkliste gut; daraus aber zu
>schließen, fremde Checklisten seien per se Mist, ist völliger Unsinn.
Da hast Du natürlich recht, trotzdem finde ich eine Diskussion zu 
"fremde Checklist in den falschen Hände" nötig. Das Problem sehe ich 
weniger in der Checklist sondern in dem Umgang mit dieser als 
(missverständliches) Dogma.
Und gerade Personen die noch nie selbst eine erstellt haben, neigen dazu 
eine zugelieferte Liste als 'seelig machende Bibel' misszuverstehen.

Siehe das Beispiel mit den Kriechstrecken, respektive die Cut-Outs im 
PCB, um diese einzuhalten. Da stoppt vielleicht ein Prüfer die Freigabe 
weil er diese resp das Outline partout nicht findet, weil er nicht auf 
die Idee gekommen ist, das für diese 5V Platine diese nicht nötig sind 
und er nicht nachfragte.

Auch ein Layouter/Ing. muss erst zu einem gewissenhaften Prüfer erzogen 
werden. Ein Weg (sicher nicht der einzige) ist, ihn die erste Fassung 
selbst schreiben zu lassen. Wenn er diese checklist fertig hat, dann 
kann man mit ihm die Liste selbst durchgehen und fremde Listen 
einarbeiten.

So wie bei den Hausaufgaben-threads hier, erst mal zeigen lassen, was 
der TO bis jetzt gemacht hat.

von Toby P. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Der Checker vom Neckar schrieb:
> mich würde interessieren ob ihr Checklisten benutzt um Schaltpläne oder
> Layouts zu prüfen?
Für Schaltplan, Layout, Produktion, Stencil und Testplan hab ich eigene.

Dazu noch eine 2do list als Notizzettel, auch  für Mechanik Installation 
etc.

Motto: Planung ersetzt den Zufall durch den Irrtum.

.
.

Aber Irrtümer kann man korrigieren.


> Wenn ja, habt ihr die selbst erstellt oder ist sie in der Firma
> gewachsen?

Selber gemacht. Die werden auch ständig nachgeführt, verbessert, 
präzisiert, neu gegliedert ... .

Beitrag #6393680 wurde von einem Moderator gelöscht.
Beitrag #6393739 wurde von einem Moderator gelöscht.
von Freddy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
10 Schritte zum Erfolg

0. Empfange die Requirements
1. Entwickel die HW-Architektur
2. Entwirf die Prüfstrategie
3. Entwickel den Schaltplan
4. Prüfe die Constraints
5. Beauftrage das Layout
6. Prüfe das Layout
7. Prüfe die Bohrlöcher und Stecker passt da auch das Werkzeug zum 
Anschrauben
8. Bestelle Musterplatinen
9. Inbetriebnahme
10. Prüfe die Requirements

von Zerberus (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Nur in beschränkten Maß. Beim Layout sollte man alle wichtigen Design 
Rules im CAD Programm erstellen um sicher zu stellen, daß kritische 
Vorgaben eingehalten werden.

Bei der Erstellung des Schaltplans nach Möglichkeit ein paar Tage Pause 
einlegen um eine gewisse Objektivität wieder zu erlangen weil man sonst 
Gefahr läuft den Balken vor den Augen zu übersehen. Sonst übersieht man 
manchmal die elementarsten Flüchtigkeitsfehler die beim ersten 
Durchsehen sonst vom Gehirn ignoriert werden.

Es versteht sich von selbst, daß zu diesem Zeitpunkt alle Komponenten 
elektrisch und mechanisch korrekt gewählt wurden und die 
Designberechnungen zufriedenstwllend abgeschlossen wurden.

Bei Schaltplänen kann es passieren, daß falsche, aber gleichaussehende 
Symbole mit unterschiedlichen Pinouts relativ zum Footprint verwendet 
werden. Man sollte strikt alle kritischen Schaltbildsymbole mit den 
Datenblattangaben und Package verifizieren um Verwechslungsfehler 
auszuschließen.

Besonders hilfreich ist es nach Möglichkeit schon alle Bauteile zur Hand 
zu haben und das Layout im Maßstab 1:1 auf Papier ausdrucken und die 
kritischen Komponenten dann auf die zugehörigen Footprints zu legen. 
Etwaige Fehler offenbaren sich dann schnell ohne Barmherzigkeit.

Das sind alles einfache, aber wichtige Phasen des Layoutprozesses. Wer 
zu sehr in Eile ist macht erfahrungsgemäß meistens mehr Fehler. Das sind 
meine Erfahrungen im Lauf von einigen hundert Layouts in meinem Leben. 
Durch Fehler wird man klug. Man muß halt vermeiden den gleichen Fehler 
doppelt zu machen.

Das ist alles was mir zur Threadfrage einfällt. Mit Erfahrung sind 
Checklisten nicht unbedingt notwendig. Die aufgeführten Maßnahmen sind 
da m.M.n. wichtiger.

von Claus W. (claus_w)


Bewertung
0 lesenswert
nicht lesenswert
Code Review Checklisten bei F+E Softwareabteilung Siemens VDO Schwalbach 
benutzt.

von Bernd (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
>mich würde interessieren ob ihr Checklisten benutzt um Schaltpläne oder
>Layouts zu prüfen?

Nein, sowas braucht unsere Truppe nicht (mehr).

Checklisten sind nur eine hilfreiche Gedankenstütze, wenn man kongnitiv 
nicht in der Lage ist, breitbandig Informationen zu verarbeiten. Fähiges 
und vor allem erfahrenes Personal braucht sowas schlichtweg nicht.

von Toby P. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Bernd schrieb:
> wenn man kongnitiv
> nicht in der Lage ist, breitbandig Informationen zu verarbeiten.

Ich bin dazu nicht in der Lage, sehe auch kenen Sinn darin es zu machen.



Hier ein Ausschnit aus einer meiner Checklisten (über 120 Punkte)

...

Electric:
[ ] Renumber parts 1xx (or Nxx) where N is the sheet number (keep part 
...
[ ] DRC/Ratsnest no Airwires left. polygons processed Layers 1..16, ...
[ ] DRC with manufacturer settings (no errors!)
[ ] DRC again until no errors (wire stubs)left
[ ] Check vrestrict manually, eagle does not report errors there
[ ] Restrings min. 0,3mm on Pads and vias if applicable
[ ] Isolation Gaps correct? Values must ...

Kann und will ich nícht im Kopf halten.

Beitrag #6393957 wurde von einem Moderator gelöscht.
Beitrag #6394197 wurde von einem Moderator gelöscht.
von D. C. (gnd)


Bewertung
0 lesenswert
nicht lesenswert
Bernd schrieb:
> Checklisten sind nur eine hilfreiche Gedankenstütze, wenn man kongnitiv
> nicht in der Lage ist, breitbandig Informationen zu verarbeiten. Fähiges
> und vor allem erfahrenes Personal braucht sowas schlichtweg nicht.

Ihr braucht auch keine Doku weil ihr kognitiv so gut geschult seit?

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Jede Agenda ist quasi eine Checkliste, und die hat oft nur 2-3 punkte. 
Ebenso Einkaufszettel.

Wie willst Du ohne Checkliste allein schon behalten, was Du alles 
gechecked hast.

von Mani W. (e-doc)


Bewertung
-1 lesenswert
nicht lesenswert
Der Checker vom Neckar schrieb:
> mich würde interessieren ob ihr Checklisten benutzt um Schaltpläne oder
> Layouts zu prüfen?
> Wenn ja, habt ihr die selbst erstellt

Naja!

Meine Schaltpläne erstelle ich prinzipiell mit A4-Papier, Bleistift und
Spitzer, Radiergummi...

LAYOUTS erstelle ich selbst...

Die einzige Checkliste, die ich benutze, ist mein Hirn welches immer
wieder versucht, einen Fehler zu entdecken!

von Knallt ihn ab, den Troll (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Bernd schrieb:
> Checklisten sind nur eine hilfreiche Gedankenstütze, wenn man kongnitiv
> nicht in der Lage ist, breitbandig Informationen zu verarbeiten. Fähiges
> und vor allem erfahrenes Personal braucht sowas schlichtweg nicht.

Wahrscheinlich braucht auch niemand von euch Notizzettel, und einen 
Truckfaktor von 1 habt ihr vermutlich auch.

Gut, wenn man nur Arduinoprojekt aus dem Internet zusammenkopiert und 
nix Komplizierteres macht, dann geht das schon.

von Mani W. (e-doc)


Bewertung
0 lesenswert
nicht lesenswert
Knallt ihn ab, den Troll schrieb:
> Wahrscheinlich braucht auch niemand von euch Notizzettel, und einen
> Truckfaktor von 1 habt ihr vermutlich auch.

Notizzettel brauche ich und wahrscheinlich Andere hier nicht!

Was ist ein "Truckfaktor" in Deiner Sicht?

von Old P. (Firma: nix) (old-papa)


Bewertung
3 lesenswert
nicht lesenswert
Hmmm, was sind "Checklisten"?
Je nach Größe des Projektes arbeite ich noch nichtmal mit Schaltplänen 
oder gar Zeichnungen ;-)
Letztes Jahr eine 50Tonnen Hydraulikpresse, komplett im Eigenbau ohne 
einen Zettel. ;-)
Andererseits pinsel ich schon mal einen kompletten Schaltplan für ein 
Mischpult in den Computer, weil ich bei rund einigen Hundert 
Transistoren und ICs, dazu ca. 400 Potis und Schalter nebst einem 
Dutzend Bussen sonst "etwas" die Übersicht verliere. (ok, ist ein paar 
Jahre her).
Aber eine Checkliste habe ich auch dabei nicht.
Ganz früher hatte ich noch fast ganze Schaltpläne einfacher 
Handfunkgeräte im Kopf. Musste ich auch, entweder aufmalen oder merken, 
denn Drucker/Kopierer gab es für Otto Normal-Ossi nicht. Heute reichts 
gerade noch zum Mikrofonverstärker...

Old-Papa

von Mani W. (e-doc)


Bewertung
0 lesenswert
nicht lesenswert
Old P. schrieb:
> Heute reichts
> gerade noch zum Mikrofonverstärker...

Fürs Gehör in späten Jahren...

;-)))

von Old P. (Firma: nix) (old-papa)


Bewertung
0 lesenswert
nicht lesenswert
Mani W. schrieb:
>
> Fürs Gehör in späten Jahren...
>
> ;-)))

Noch gehts ohne, auch wenn die Höhen schon gelitten haben. Das freut die 
Musiker immer, wenn ich am Mischpult nach Gehör regle,.. "Nimm die Höhen 
raus" wird dann gelegentlich gebrüllt ;-)

Old-Papa

von Mani W. (e-doc)


Bewertung
0 lesenswert
nicht lesenswert
Old P. schrieb:
> "Nimm die Höhen
> raus" wird dann gelegentlich gebrüllt ;-)

Verständlich...

Dazu braucht man keine "Checklist"...

von Senf D. (senfdazugeber)


Bewertung
1 lesenswert
nicht lesenswert
Mani W. schrieb:
> Was ist ein "Truckfaktor" in Deiner Sicht?

https://de.m.wikipedia.org/wiki/Truck_Number

von Mani W. (e-doc)


Bewertung
1 lesenswert
nicht lesenswert
Truck Faktor:

 Mit dem Wert wird die Anzahl der Mitarbeiter in einem Projekt 
beschrieben, die ausfallen können, ohne das Projekt zu gefährden.

Eigenartig, wie man heute arbeitet...

von OhMan_EsIstDoch2020 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nachfolgend eine Liste der Frickler, die nicht wissen wie man etwas mit 
Qualität für Serie entwickelt:

Voight-Kampff untested schrieb:
> Aber die müssen nicht unbedingt als Liste niedergeschrieben sein, so was
> hat man vom Studium und Beruf als Erfahrung im Kopf.

Hannes J. schrieb im Beitrag #6393680:
> Das ist wieder eine Idiotenfrage von einem typischen Idioten-Nick.
>
> Wenn dir Checklisten helfen dann benutze sie. Wenn dir Checklisten nicht
> helfen, dann lass es. Was nützt dir die Information ob jemand anderes

Zerberus schrieb:
> Das ist alles was mir zur Threadfrage einfällt. Mit Erfahrung sind
> Checklisten nicht unbedingt notwendig.

Bernd schrieb:
> Checklisten sind nur eine hilfreiche Gedankenstütze, wenn man kongnitiv
> nicht in der Lage ist, breitbandig Informationen zu verarbeiten. Fähiges
> und vor allem erfahrenes Personal braucht sowas schlichtweg nicht.

Mani W. schrieb:
> Die einzige Checkliste, die ich benutze, ist mein Hirn welches immer
> wieder versucht, einen Fehler zu entdecken!

Old P. schrieb:
> Hmmm, was sind "Checklisten"? Je nach Größe des Projektes arbeite ich
> noch nichtmal mit Schaltplänen oder gar Zeichnungen ;-)

Es folgt einer der 3 lesenswerten Beiträge in diesem Thread. Der Rest 
klingt wie alte Leute die nicht verstehen wozu es einen 
Entwicklungsprozess gibt. Und NEIN, man kann sich nicht ohne Checklisten 
nicht alles merken, man darf sie sich auch nicht selbst alleine 
schreiben ohne jemand drüber schauen zu lassen.

Knallt ihn ab, den Troll schrieb:
> Bernd schrieb:
>> Checklisten sind nur eine hilfreiche Gedankenstütze, wenn man kongnitiv
>> nicht in der Lage ist, breitbandig Informationen zu verarbeiten. Fähiges
>> und vor allem erfahrenes Personal braucht sowas schlichtweg nicht.
>
> Wahrscheinlich braucht auch niemand von euch Notizzettel, und einen
> Truckfaktor von 1 habt ihr vermutlich auch.
>
> Gut, wenn man nur Arduinoprojekt aus dem Internet zusammenkopiert und
> nix Komplizierteres macht, dann geht das schon.

von Volker U. (Firma: Ingenieurbüro Volker Urban) (ib-volker-urban)


Bewertung
0 lesenswert
nicht lesenswert
OhMan_EsIstDoch2020 schrieb:
> Der Rest
> klingt wie alte Leute die nicht verstehen wozu es einen
> Entwicklungsprozess gibt.

Und damit nähert man sich dem eigentlichen Problem in der Fragestellung 
des TO.

Hinter der Frage nach der aus dem Internet downloadbaren checkliste 
verbirgt sich IMHO tatsächlich die Frage nach mehreren Inhalten:
(1)einer Anleitung wie man ein (größeres) Schaltplanprojekt aufsetzt, 
welche Dokumente überhaupt genriert werden müssen
(2)wie man die während der Schaltplannerstellung geschaffenen Dokumente 
und Unterlagen auf inhaltliche Fehler und zukünftige Probleme (i.e. 
"Design for Manufactoring/test" )prüft
(3)wie man eine  Freigabe durch alle beteiligten Abteilungen (Einkauf, 
Lager, Fertigung, Prüffeld, Softwareentwicklung, Frontend-test ...) 
gestaltet, damit die Schaltung nach Erstellung in die Fertigung geht.

Über diese Punkte kann man jeweils mehrere Seiten Lehrbuchtext verfassen 
um die nötigen Infos aus Projektmanagment, Electronic design 
Automatisation, Leiterplattenfertigung etc. wiederzugeben. Einiges ist 
davon so speziell an die benutzte Software (Altium,Mentor,...) Fertigung 
(Mehrlagen) und Anwendung (Medizintechnik, Avionic, Consumer, 
Automitive), das es andere Entwickler nicht interessiert, stört oder das 
Produkt unnötig verteuert.

In diesem Forum wurde dort mal angerissen, welche Problemfelder sich 
hinter der Aufgabe "Schaltung entwickeln" verbergen : 
Beitrag "Hardware-Designtipps des Monats: Vor dem Projektstart"

> Und NEIN, man kann sich nicht ohne Checklisten
> nicht alles merken, man darf sie sich auch nicht selbst alleine
> schreiben ohne jemand drüber schauen zu lassen.

Ja, wenn es aber keinen anderen gibt der befähigt oder willens ist 
drüber zu schauen? Wie führt man einen Review über Dokumente und 
Entwicklungsschritte durch, ohne das diese zum hirnlosen Abhaken ohne 
Verständnis degeneriert?! Ich erinnere in diesem Zusammenhang an den 
Klassiker Therac-25. Da wurde die Entwicklungscheckliste auch komplett 
abgehackt, weil Software nicht altert und lediglich "Alterung" als 
fundamentales Problem in der Gerätesicherheit galt/gilt 
(Materialermüdung). https://de.wikipedia.org/wiki/Therac-25#Ger%C3%A4t

von Knallt ihn ab, den Troll (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Volker U. schrieb:
>> Und NEIN, man kann sich nicht ohne Checklisten
>> nicht alles merken, man darf sie sich auch nicht selbst alleine
>> schreiben ohne jemand drüber schauen zu lassen.
>
> Ja, wenn es aber keinen anderen gibt der befähigt oder willens ist
> drüber zu schauen?

Dann kann die Firma - aus meiner Sicht - keinen seriösen Designprozess 
durchführen.

Mit entsprechender Erfahrung kann man grobe Konzeptfehler vielleicht 
vermeiden und mit gründlichen und aufwendigen Tests theoretisch viel 
erreichen. Dann läuft man aber in Probleme, die praktisch immer 
auftauchen wenn ein Entwickler Konstrukteur und Tester in Personalunion 
ist.

Und Probleme wie etwa Betriebsblindheit kriegt man alleine nie und 
nimmer in den Griff. Oder daß die Dokumentation für den Entwickler 
völlig klar und verständlich ist - für jeden anderen (insbesondere für 
andere Entwickler) jedoch unvollständig, ohne roten Faden und letztlich 
unbrauchbar ist.

Oder einfach die Tatsache, daß man jemanden hat (oder eben nicht hat), 
mit dem man über seine Arbeit und Gedankengänge sprechen kann, ändert 
vieles grundlegend.

Wie gesagt: bei einfach Kleinkram mag das so gehen. Oder wenn die Firma 
letztlich immer wieder dasselbe macht und nichts wirklich entwickelt, 
sondern bei jedem neuen Auftrag das letzte Projekt kopiert und mehr oder 
weniger leicht modifiziert wird.
Aber das hat mit Entwicklung ja nichts zu tun.



Mani W. schrieb:
> Truck Faktor:
>
>  Mit dem Wert wird die Anzahl der Mitarbeiter in einem Projekt
> beschrieben, die ausfallen können, ohne das Projekt zu gefährden.
>
> Eigenartig, wie man heute arbeitet...

Was ist - bei einer verantwortungsvollen Firmenführung - eigenartig, 
darüber nachzudenken, wenn einer der Goldesel ausfällt?

Wenn Entwicklung in einer Firma nur nachrangig ist und lediglich 
bestehende Produkte erweitert werden und die Firma hauptsächlich vom 
Verkauf lebt - dann kann man sich so etwas vielleicht leisten. Wenn man 
z.B. nicht gerade unter Konkurrenzdruck steht.

Wenn Entwicklung aber - direkt oder indirekt - einen wesentlichen Teil 
des Gewinns einbringt, hast nur einen Entwickler bzw. arbeitet jeder 
Entwickler für sich alleine, dann hat die Firma sehr schnell ein sehr 
ernstes Problem, wenn der Entwickler kurzfristig für längere Zeit 
ausfällt. Tod, Krankheit, Kündigung, ...

Dann stellen sich Fragen wie:
-Wo kriegt man möglichst schnell Ersatz für den einzigen Entwickler her?
-Wenn ich Ersatz habe (neuer MA oder andere MA, weil man mehrere hat), 
wie schnell kann ein anderer das Projekt übernehmen? Wieviele 
Informationen findet er vor, was muß er erst langwierig zusammensuchen, 
was muß er sich neu ausdenken (und damit bereits erledigte Arbeit 
nochmal machen)?

Ich wundere mich sehr, daß hier Leute von "erfahrenem Personal" sprechen 
und solche Überlegungen dabei nicht automatisch im Oberstübchen 
ablaufen.
Ein erfahrener Entwickler (also daß, was ICH unter erfahren verstehe), 
der am Ende zu dem Ergebnis kommt daß Checklisten in seinem 
Konstruktoinsprozeß keine Hilfe sind (z.B. weil andere Werkzeuge 
automatisiert für Einhaltung sorgen), der hat diese Gedankengänge 
zumindest mal durchdacht und das Problem verstanden.

Nach meiner bisherigen Erfahrung neigt der größere Teil der deutschen 
Entwickler zum Pfusch, wie er hier von einigen ungewollt beschrieben 
wird.
Sehr bedenklich für den Ruf von "Made in Germany" (wobei m.M.n. MiG 
schon länger wieder zu seiner ursprünglichen Bedeutung tendiert).

von Senf D. (senfdazugeber)


Bewertung
0 lesenswert
nicht lesenswert
Ich empfinde die ganze Diskussion um Checklisten in diesem Thread als 
sinnlos.

Wer sie als hilfreich erachtet, weil er sich damit sicherer fühlt, soll 
sie nutzen.

Wer sie nicht als hilfreich und als überflüssig erachtet, soll sie 
weglassen.

Wo ist jetzt eigentlich das Problem?

Eine gewisse Wissensverteilung im Team sollte es natürlich geben, so 
dass ein Kollege auch mal bei Krankheit oder Urlaub einspringen kann, 
ohne dass alles stillsteht, aber das bedeutet nicht unbedingt den 
Einsatz von irgendwelchen Checklisten.

: Bearbeitet durch User
von Volker U. (Firma: Ingenieurbüro Volker Urban) (ib-volker-urban)


Bewertung
0 lesenswert
nicht lesenswert
Knallt ihn ab, den Troll schrieb:
> Volker U. schrieb:
>>> Und NEIN, man kann sich nicht ohne Checklisten
>>> nicht alles merken, man darf sie sich auch nicht selbst alleine
>>> schreiben ohne jemand drüber schauen zu lassen.
>>
>> Ja, wenn es aber keinen anderen gibt der befähigt oder willens ist
>> drüber zu schauen?
>
> Dann kann die Firma - aus meiner Sicht - keinen seriösen Designprozess
> durchführen.

Naja binäres Denken in Begriffen wie 'seriös' oder 'nicht seriös' ist 
hier IMHO fehl am Platze. Natürlich kann auch ein einziger Entwickler 
eine Hardware entwickeln, Prototyp bauen, ausmessen und fixen. Dauert 
halt länger die gleiche Qualitätstufe zu ereichen wie mit einem 
eingespielten und erfahrenen Team. Projektentwicklung spielt sich 
bekanntlich drei Dimension ab (in time, in budget, in quality) und nicht 
in einer einzelnen und zweiwertigen (GEHT, GEHT NICHT).

> Nach meiner bisherigen Erfahrung neigt der größere Teil der deutschen
> Entwickler zum Pfusch, wie er hier von einigen ungewollt beschrieben
> wird.

Und nach meiner Erfahrung wird die Qualitätsbezeichnung "Pfusch" zu 
häufig von den 'falschen' Leuten und im falschen Kontext benutzt.

: Bearbeitet durch User
von Knallt ihn ab, den Troll (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Volker U. schrieb:
> Naja binäres Denken in Begriffen wie 'seriös' oder 'nicht seriös' ist
> hier IMHO fehl am Platze. Natürlich kann auch ein einziger Entwickler
> eine Hardware entwickeln, Prototyp bauen, ausmessen und fixen. Dauert
> halt länger die gleiche Qualitätstufe zu ereichen wie mit einem
> eingespielten und erfahrenen Team. Projektentwicklung spielt sich
> bekanntlich drei Dimension ab (in time, in budget, in quality) und nicht
> in einer einzelnen und zweiwertigen (GEHT, GEHT NICHT).

Ach doch...ein Endergebnis kann durchaus relativ binär eingestuft 
werden. Du hast ja selber den Therac gebracht. Sporadische 
Fehlfunktionen fallen zumindest bei mir unter "Geht nicht". Präziser: 
"Funktioniert nicht wie erwartet".

Es gibt durchaus auch Entwicklungen, da reichen die niedrigsten 
Ansprüche und selbst die müssen dann vielleicht noch nichtmal zu 100% 
befriedigt sein.
Dann ärgern sich die Kunden halt über Überwachungskameras und Smart TVs 
mit Sicherheitslücken, die förmlich zum Netzwerkeinbruch einladen. Oder 
Infotainmentsystemen in ihren Autos, die über ungesicherte 
Bluetoothschnittstellen z.B. Kommandos verschiedenster Steuergeräte ein- 
oder ausleiten.

An organisatorischen Mängeln sehe ich zwar auch nicht die Entwickler als 
Alleinschuldigen - wenn die Firma mangelhaft organisiert ist, dann liegt 
das nicht an den unteren Diensträngen. Wenn die Firma keine 
strukturierten Arbeitsabläufe kennt oder - schlimmer noch - diese aktiv 
behindert, dann liegt die Ursache in den Chetetagen.
Aber wenn Entwickler von sich behaupten, daß sie aufgrund ihrer 
Genialität keine Fehler machen und stets bei der Sache sind, stehen 
Wahrnehmung und Wirklichkeit dann doch meist in stark im Kontrast 
zueinander.
Und dann auch noch die Versuche belächeln, mit den typisch menschlichen 
Unzulännglichkeiten fertigzuwerden - ignoranter geht es doch eigentlich 
nicht mehr.

von Volker U. (Firma: Ingenieurbüro Volker Urban) (ib-volker-urban)


Bewertung
0 lesenswert
nicht lesenswert
Knallt ihn ab, den Troll schrieb:
> Und dann auch noch die Versuche belächeln, mit den typisch menschlichen
> Unzulännglichkeiten fertigzuwerden - ignoranter geht es doch eigentlich
> nicht mehr.

Was ist daran ignorant hinzuweise, das es kein Go/NoGo ist sondern ein 
"dauert eben länger mit weniger Headcount" ? Ignorant ist es eher zu 
glauben das mit reiner Formalienerfüllung getan ist, insbesonders wenn 
diese Formalien nicht selbst erarbeitet worden sondern lediglich aus dem 
Internet runtergeladen wie es der TO gerne hätte.

von sid (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Nicht wirklich..
oder sagen wir sehr selten.

Checklisten sind nur bei wirklich kritischen Dingen wirklich hilfreich,
und auch nur wenn sie eine gewisse zeitliche stabilität haben.
(man also die eine Checkliste für Jahre benutzt)

Normalerweise sind solche Checklisten (sofern man sie häufig braucht) 
dann aber derart, dass sie sich eh im Hirn einnisten und man sie mental 
abarbeitet, noch bevor man zum Zettel greift.

Nur wenn neue OoO auf einen zukommen und sich somit neue Dinge auf die 
Checkliste vorarbeiten, dann in der Tat mach ich mir dazu passend 
Notizen
(in der Regel lieber in Papierform als digital sogar)
sodass sie sich schneller ins Hirn nisten.

In vielen anderen Fällen verkommen Checklisten zu ToDo listen,
und die sind immer kontraproduktiv,
denn das aufschreiben alleine belohnt das Gehirn ähnlich gut wie das
Erledigen der eigentlichen Aufgabe,
damit ist es leichter sich selber auszutricksen und es am Ende doch zu 
vergessen.

Checklisten erstellen also nur in homöopatischen Dosen,
um der Verdummung entgegenzuarbeiten.
(es sei denn man hat Personal das einem die Listen zur Abarbeitung 
vorlegt.. das ist aber ein Luxus den ich leider nicht habe ;)
nur selber schreiben ist eben ersteinmal schlecht )

'sid

von OhMan_EsIstDoch2020 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Knallt ihn ab, den Troll schrieb:
> An organisatorischen Mängeln sehe ich zwar auch nicht die Entwickler als
> Alleinschuldigen - wenn die Firma mangelhaft organisiert ist, dann liegt
> das nicht an den unteren Diensträngen. Wenn die Firma keine
> strukturierten Arbeitsabläufe kennt oder - schlimmer noch - diese aktiv
> behindert, dann liegt die Ursache in den Chetetagen.
> Aber wenn Entwickler von sich behaupten, daß sie aufgrund ihrer
> Genialität keine Fehler machen und stets bei der Sache sind, stehen
> Wahrnehmung und Wirklichkeit dann doch meist in stark im Kontrast
> zueinander.

Richtig. Leider sind hier zu viele Pfuscher unterwegs.

von Chefingenieur (Gast)


Bewertung
1 lesenswert
nicht lesenswert
OhMan_EsIstDoch2020 schrieb:
> Knallt ihn ab, den Troll schrieb:
>> An organisatorischen Mängeln sehe ich zwar auch nicht die Entwickler als
>> Alleinschuldigen - wenn die Firma mangelhaft organisiert ist, dann liegt
>> das nicht an den unteren Diensträngen. Wenn die Firma keine
>> strukturierten Arbeitsabläufe kennt oder - schlimmer noch - diese aktiv
>> behindert, dann liegt die Ursache in den Chetetagen.
>> Aber wenn Entwickler von sich behaupten, daß sie aufgrund ihrer
>> Genialität keine Fehler machen und stets bei der Sache sind, stehen
>> Wahrnehmung und Wirklichkeit dann doch meist in stark im Kontrast
>> zueinander.
>
> Richtig. Leider sind hier zu viele Pfuscher unterwegs.

Es ist erstaunlich wie leichtfertig andere Leute, ohne deren nähere 
Umstände und Erfahrung man kennt, pauschal abgeurteilt werden. 
Überheblichkeit etablierter Leute ist leider sehr oft beobachtbar.

von OhMan_EsIstDoch2020 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Chefingenieur schrieb:
> ohne deren nähere Umstände und Erfahrung man kennt, pauschal abgeurteilt
> werden.

Jemand der denkt nie Fehler zu machen, nichts zu übersehen, da braucht 
es tatsächlich nicht die näheren Umstände und Erfahrungen zu kennen, um 
zu beurteilen, dass da ohne für Qualität erforderliche Prozesse 
gearbeitet wird. Solche Prozesse sind heutzutage Standard. In der 
Vorentwicklung bei Prototypen kann ja gefrickelt werden, aber bei 
Serienprodukten darf man nicht auf den Held der Arbeit angewiesen sein. 
Bei Unternehmen die ordentlich arbeiten, geht nicht gleich ein Projekt 
vor die Hunde, nur weil einer der Entwickler plötzlich nicht mehr da 
ist. Wenn doch, herzlichen Glückwunsch, sie arbeiten in einer 
Frickelbude. Ausnahmen sind natürlich Unternehmen mit nur wenigen 
Angestellten. Richtig wäre: Der nächste Hardwareentwickler kommt ins 
Projekt und kann aufgrund der einheitlichen Dokumente, Namensgebungen, 
Ablagen, Checklisten usw direkt nachvollziehen wo man im Projekt steht 
und wie es weitergeht, ohne dem Vorgänger in den Kopf zu schauen.

von Chefingenieur (Gast)


Bewertung
0 lesenswert
nicht lesenswert
OhMan_EsIstDoch2020 schrieb:
> Chefingenieur schrieb:
>> ohne deren nähere Umstände und Erfahrung man kennt, pauschal abgeurteilt
>> werden.
>
> Jemand der denkt nie Fehler zu machen, nichts zu übersehen, da braucht
> es tatsächlich nicht die näheren Umstände und Erfahrungen zu kennen, um
> zu beurteilen, dass da ohne für Qualität erforderliche Prozesse
> gearbeitet wird. Solche Prozesse sind heutzutage Standard. In der
> Vorentwicklung bei Prototypen kann ja gefrickelt werden, aber bei
> Serienprodukten darf man nicht auf den Held der Arbeit angewiesen sein.
> Bei Unternehmen die ordentlich arbeiten, geht nicht gleich ein Projekt
> vor die Hunde, nur weil einer der Entwickler plötzlich nicht mehr da
> ist. Wenn doch, herzlichen Glückwunsch, sie arbeiten in einer
> Frickelbude. Ausnahmen sind natürlich Unternehmen mit nur wenigen
> Angestellten. Richtig wäre: Der nächste Hardwareentwickler kommt ins
> Projekt und kann aufgrund der einheitlichen Dokumente, Namensgebungen,
> Ablagen, Checklisten usw direkt nachvollziehen wo man im Projekt steht
> und wie es weitergeht, ohne dem Vorgänger in den Kopf zu schauen.

Ich gebe Dir trotz meiner verhergehenden Kritik eigentlich 100% recht. 
Projektdokumentation muß vollständig genug sein um personalunabhängige 
Projektkontinuität zu gewährleisten. Leider wird dieses Zuel in vielen 
Fällen nicht oft erreicht.

...

von Volker U. (Firma: Ingenieurbüro Volker Urban) (ib-volker-urban)


Bewertung
1 lesenswert
nicht lesenswert
Chefingenieur schrieb:
> OhMan_EsIstDoch2020 schrieb:

>> Richtig. Leider sind hier zu viele Pfuscher unterwegs.
>
> Es ist erstaunlich wie leichtfertig andere Leute, ohne deren nähere
> Umstände und Erfahrung man kennt, pauschal abgeurteilt werden.
> Überheblichkeit etablierter Leute ist leider sehr oft beobachtbar.

Volle Zustimmung, bis auf den Punkt "ohne deren nähere  Umstände und 
Erfahrung man kennt".
Weiter oben ( Beitrag "Re: Arbeitet ihr mit Checklisten?" ) 
bezichtigt der selbe Autor mehr oder weniger direkt folgende 
Forumsschreiber der Pfuscherei:

*Voight-Kampff untested schrieb:
*Hannes J. schrieb im Beitrag #6393680:
*Zerberus schrieb:
*Bernd schrieb:
*Mani W. schrieb:
*Old P. schrieb:

Und einige der so gebrandmarkten "Pfuscher" sind hier sehr wohl bekannt.

Soweit erkennbar gründet das Urteil "Pfuscher" auf der Annahme, die 
Genannten würden ihre Ergebnisse nicht überprüfen, dabei lehnen IMHO die 
Gelisteten lediglich ab, fremde, online verfügbare Checklisten zu 
verwenden und machen ihre Verifikationen als integraler Bestandteil des 
individuellen Entwicklungsprozess nicht 'papiergebunden' selbst.

Oben wurde auch die Challenger-Katastrophe angeführt, wie trotz 
abgearbeiter Checklisten etc. zwangsläufig eine Katastrophe eintrat. 
Pikanterweise wurde der Entscheidungsprozess nach Ausschluss der 
Ingenieure wiederholt um zu einer Freigabe zu kommen. Alles formal 
korrekt und dennoch BUMM!.

Die Qualität des Endproduktes wird eben nicht durch die bloße Befolgung 
der (aufdoktrinierten) Entwicklungsprozeße garantiert. Insbesonders wenn 
diese Richtlinien einzig von außen stammen.

Auch der Einwurf mit der Dokumentation zur Einarbeitung stützt nicht das 
Urteil, das ohne formale Freigaben nur Pfusch entstehen würde. Im 
Gegenteil, es ist auch gut möglich Produkte, die nicht-funktionieren, so 
zu dokumentieren, das auch neue Mitarbeiter sicher nicht-funktionierende 
Produkte fertigen. Eine Dokumentation sagt wenig/garnichts über die 
Produktqualität aus.
Was allerdings nicht heißt, das Dokumentation unnötig wäre. 
Dokumentation kann aber wie alle aufdoktrinierten Maßnahme den Nachteil 
haben, den bisherigen (nicht zufriedenstellenden) Zustand zu 
zementieren, wenn sie das Creative Element in der Entwicklung 
unterdrückt. Sinn der Prozessstandardisierung ist aber gerade zu einem 
sich selbst verbesserten, selbstlernenden, selbst optimierenden 
Unternehmen zu kommen, keine Dokumentation/Checkliste darf zum 
Selbstzweck werden. Diese Gefahr des Selbstzweckes sehe ich aber 
insbesonders dort, wo behauptet wird, ohne diese würde nur Pfusch 
entstehen.

: Bearbeitet durch User
von Checklistenbenutzer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Um mal etwas produktiv zum Thema Checklisten beizutragen: Hier ist eine 
vielseitige und praxiserprobte Liste, die ich für verschiedene Projekte 
benutzt habe und mir bereits einige Revisionen erspart hat:

https://github.com/azonenberg/pcb-checklist

von Volker U. (Firma: Ingenieurbüro Volker Urban) (ib-volker-urban)


Bewertung
0 lesenswert
nicht lesenswert
Checklistenbenutzer schrieb:
> Um mal etwas produktiv zum Thema Checklisten beizutragen: Hier ist eine
> vielseitige und praxiserprobte Liste, die ich für verschiedene Projekte
> benutzt habe und mir bereits einige Revisionen erspart hat:
>
> https://github.com/azonenberg/pcb-checklist

Bewertungsfreie Anmerkungen:
Die schematic-liste ist eine ToDo-Liste mit Checkboxen. Die nützt 
hauptsächlich denen, die so was wie "Thermal calculations for all large 
/ high power ICs" bereits können.

Andere Punkte wie korrektes TX/RX Pairing kann auch das schematictool 
checken (ERC) wenn man es entsprechend konfiguriert.
Oder wenn man FPGA verwendet die FPGA-tools.

Bei solchen Dimensinierungsaufgaben wie "Correct load caps provided for 
discrete crystals" benötigt es auch die Angabe , woher diese Werte 
stammen (Datenblatt) und es impliziert, das das Datenblatt auch korrekt 
abgelegt ist.

Das sind dann auch Punkte, die eher in der 
Prüfung/Erstellungsrichtlinien der 'Symbol/Bauteil-bibliothek' eingehen, 
respektive ins eigene 'Inventarverzeichniss', hier also welche Quartze 
sind mit welchen Eigenschaften, Kurzbeschreibungen wo im Lager abgelegt. 
Der Einkauf ergänzt solche Lagerlisten auch gern mit eigenen Feldern wie 
Lieferant, Kosten, Lieferzeiten etc. pp..

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mir scheint diese Frage recht allgemein gestellt. Dementsprechend waren 
die Antworten!

Wer nur einen einen Stiel an die Schaufel montiert, braucht sicher keine 
Checkliste. Ein Pilot sollte schon eine haben. Auch bei Fleißarbeiten 
sind Checklisten nützlich zur Qualitätssicherung. Den Kopf kann man 
trotzdem benutzen (weil oft nicht alle wichtigen Punkte erfasst wurden).

von Wühlhase (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Volker U. schrieb:
> Knallt ihn ab, den Troll schrieb:
>> Und dann auch noch die Versuche belächeln, mit den typisch menschlichen
>> Unzulännglichkeiten fertigzuwerden - ignoranter geht es doch eigentlich
>> nicht mehr.
>
> Was ist daran ignorant hinzuweise, das es kein Go/NoGo ist sondern ein
> "dauert eben länger mit weniger Headcount" ? Ignorant ist es eher zu
> glauben das mit reiner Formalienerfüllung getan ist, insbesonders wenn
> diese Formalien nicht selbst erarbeitet worden sondern lediglich aus dem
> Internet runtergeladen wie es der TO gerne hätte.

Ich meinte mit ignorant eher z.B. den bereits von mir zitierten Post von 
Mani-W. Und ich gebe dir auch Recht daß die besten Formalien nix 
bringen, wenn solche Prozesse nicht auch gelebt werden, aber das 
verbuche ich schon unter Pfuscherdenke: "Uhh, wieso muß ich denn jetzt 
noch diese dämliche Liste ausfüllen, naja, hak ich mal alles ab...".

Ich behaupte auch nicht daß jede Checkliste aus dem Internet suergut 
sei. Ich finde jedoch daß jede fremde Checkliste es wert ist mal kurz 
durchdacht zu werden, ob der ein oder andere Punkt nicht evt. auch einen 
selber treffen könnte und man die eigene Checkliste nicht darum ergänzen 
sollte - sofern man so etwas überhaupt hat.

In guten Checklisten steht viel, was eigentlich erstmal 
selbstverständlich ist, das mag auch das erste Mal wunderlich aussehen. 
Sowas wie:

-Desginrulecheck fehlerfrei?
-Mechanische Kompatibilität geprüft?

Natürlich wird jeder zustimmen daß ein Layout auch im Prototypenstatus 
nicht in die Produktion gehen sollte, wenn man die Prototypenplatine in 
ein Gehäuse stecken will.
Und trotzdem hab ich schon gesehen, daß ein Gehäuse - übrigens aus 
Vollmaterial gefräst - weggeworfen werden mußte weil die mechanische 
Kompatibilitätskontrolle einmal zu wenig durchgeführt wurde. Man hat sie 
zwar durchgeführt, dann aber nochmal eine Kleinigkeit geändert und 
danach darauf verzichtet. Und schon stand ein Kondensator in anderem 
Material drin.

Und selbstverständlich waren Prozesse in dieser Firma kaum vorhanden 
bzw. wurden auf Eigeninitiative meines damaligen Teamleiters 
angestrengt, aber das konnte er halt nur teamintern machen. Das Gehäuse 
wurde von einer anderen Abteilung gebaut.

Ich behaupte einfach mal dreist und ohne Beleg, daß die Leute im größten 
Teil deutscher Firmen wesentlich weniger Überstunden machen müßten und 
weniger Projektstreß hätten und die Firma trotzdem besser dastehen 
könnte, wenn man in der Arbeitsorganisation etwas mehr Hirnschmalz 
reinstecken würde.

Und nochmal: auch ich sehe Checklisten weder als Allheilmittel, noch als 
zwingend notwendig an.
Ich sehe eine gute Arbeitsorganisation allerdings als unverzichtbar an, 
und in diesem Punkt sind sehr viele Firmen - die meisten - einfach 
fürchterlich.

Beitrag #6396162 wurde von einem Moderator gelöscht.
von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
Wühlhase schrieb:
> wenn solche Prozesse nicht auch gelebt werden, aber das
> verbuche ich schon unter Pfuscherdenke: "Uhh, wieso muß ich denn jetzt
> noch diese dämliche Liste ausfüllen, naja, hak ich mal alles ab...".

entweder vom Mechaniker, oder vom Chef
sowas erlebte ich in der Vertragswerkstatt vom PKW, alles abgehakt und 
trotzem nur berechnet! (Schaubensicherungslack auf den 
Ventildeckelschrauben sind auch eine Gemeinheit von mir, aus Erfahrung)

Orginakkommentar, "das war wohl die Schuld vom Mechaniker", obwohl ich 
mir auch denken kann das es Vorgaben gibt die unerfüllbar sind also 
Chefsache!

: Bearbeitet durch User
Beitrag #6396223 wurde von einem Moderator gelöscht.
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Wühlhase schrieb:
> aber das
> verbuche ich schon unter Pfuscherdenke: "Uhh, wieso muß ich denn jetzt
> noch diese dämliche Liste ausfüllen, naja, hak ich mal alles ab...".

Die Antwort auf diese Frage hängt entscheidend von der 
Unternehmensstruktur und -größe ab. Für mich lautet die Antwort auf die 
Frage: "Wenn die Leiterplatte einen banalen Fehler aufweisen sollte, den 
ich durch einfaches Kontrollieren anhand meiner eigenen Checkliste hätte 
finden können, muss ich das verhunzte Fertigungslos aus meiner eigenen 
Tasche bezahlen. Das Umfädeln und Nacharbeiten der Prototypen kann ich 
auch keinem Kunden in Rechnung stellen. Und der Kunde ist zu recht 
genervt durch den Projektverzug."

Ich empfehle jedem Skeptiker bzw. Gegner von Checklisten, das folgende 
Spiel zu spielen:

https://en.wikipedia.org/wiki/The_Moron_Test

Es ist wirklich erschreckend, wie schwierig es ist, selbst die 
einfachsten Level ohne Fehler durchzuspielen. Und selbst wenn man 
mehrmals einen schon etliche Male gespielten Level wiederholt, passieren 
einem doch noch Fehler. Bei Checklisten im beruflichen Bereich ist zwar 
der zeitliche Druck nicht ganz so hoch wie bei diesem Spiel, aber dafür 
sind die Aufgaben auch um so schwieriger.

Schon vor etlichen Jahren habe ich mir auch Checklisten für verschiedene 
Arten von Reisen angelegt. Insbesondere wenn ich erst am Abend (oder in 
der Nacht) vor einer Reise meine Sachen packe, passiert es ansonsten 
viel zu häufig, dass ich irgendetwas vergesse. Dabei handelt es sich 
niemals um die wichtigen Dinge, die den Anlass der Reise darstellen. 
Natürlich würde ich nicht den Prototypen, mein Notebook oder die 
hektisch zusammengetippten Dokumente vergessen, aber dann fehlen eben 
doch die Zahnpaste, der Schlafanzug oder die Visitenkarten.

von D. C. (gnd)


Bewertung
0 lesenswert
nicht lesenswert
Was haltet ihr von der Geschäftsidee, eine umfangreiche Checkliste zu 
erstellen und für jeden Fehler der damit gefunden wurde 10€ zu 
verlangen?

von Volker U. (Firma: Ingenieurbüro Volker Urban) (ib-volker-urban)


Bewertung
1 lesenswert
nicht lesenswert
Wühlhase schrieb:


> Ich meinte mit ignorant eher z.B. den bereits von mir zitierten Post von
> Mani-W. Und ich gebe dir auch Recht daß die besten Formalien nix
> bringen, wenn solche Prozesse nicht auch gelebt werden, aber das
> verbuche ich schon unter Pfuscherdenke: "Uhh, wieso muß ich denn jetzt
> noch diese dämliche Liste ausfüllen, naja, hak ich mal alles ab...".

Ich rate dringend davon ab, den Begriff "Pfuscher" zu verwenden und 
dagegen etwas Empathie aufzubringen um die Ursachen für gewisse 
Handlungen zu ergründen. Höchstens das man dem Begriff "Pfuscher" 
selbstkritisch auf sich anwendet, um zu verstehen, was bei der 
Einführung der Checkliste schief gelaufen ist:

> -Desginrulecheck fehlerfrei?
> -Mechanische Kompatibilität geprüft?

> Und trotzdem hab ich schon gesehen, daß ein Gehäuse - übrigens aus
> Vollmaterial gefräst - weggeworfen werden mußte weil die mechanische
> Kompatibilitätskontrolle einmal zu wenig durchgeführt wurde. Man hat sie
> zwar durchgeführt, dann aber nochmal eine Kleinigkeit geändert und
> danach darauf verzichtet.

Ich seh hier folgende Zusammenhänge:
* wenn ein Punkt auf der Checkliste hinzugefügt wird, muss auch die 
Möglichkeit gegeben werden diesen Check durchzuführen.
* Der Bearbeiter der Checkliste wird immer die Konsequenzen für ihn 
abwägen die sich aus allen Szenarien ("Checks ausführen und entsprechend 
Ergebniss Freigabe verweigern oder erteilen", "Freigabe erteilen und 
'beten' das es gut geht") ergeben.

Bei den Gehäuse-Kondensatorbeispiel kann ich mir gut vorstellen, das der 
Bearbeiter vor der Wahl aus

*sicherer Anschiss wegen Terminverschiebung weil Freigabe nicht erteilt
*möglischer Anschiss wegen Fertigung aus nachlässig geprüften Unterlagen

stand.
Wenn dann die eine Prüfung von einem dritten (Mechaniker) gemacht werden 
muß, der gerade nicht anwesend ist (mglw. weil mit anderem dringenden 
Projekt beschäftigt) und der Folgetermin nach dem Abhaken der Checkliste 
wirklich drängt (PCB-Fertiger verteilen gerne 'Time-Slots' [wenn wir zum 
8.9. starten können, dauert es 10d, wenn wir die Unterlagen erst am 9.9. 
bekommen, wüssen wir auf den nächsten freien Slot am 23.9. warten und 
dann 10d lang fertigen]) dann fällt die Wahl zwischen Erschießen oder 
Erhängen immer auf die (scheinbar) falsche Option.

Mit dem bloßen Erstellen und Aufdoktrinieren einer Checkliste ist es 
leider nicht getan, man (Projektleitung, Arbeitsvorbereitung) muss auch 
die konsequente Umsetzung der selben ermöglichen.

In dem Heftchen "Weniger schlecht programmieren ISBN 978-3-89721-567-2 
wird einiger Text daran verwandt wie man Änderungen im Arbeitsablauf 
(schonend) den Mittkollegen beibringt. Den Umstieg einfach machen, 
ausgiebig schulen, keinen Druck aufbauen, selber die Erfahrung machen 
lassen.


BTW:
Ich habe den Eindruck, du bist mit deinen Nicks durcheinander gekommen, 
ich finde hier nur ein "Wühlhase"-Post in dem ist aber die Rede das 
derselbe Autor bereits posts in diesem Thread verfasste (vermutlich 
unter 'OhMan_EsIstDoch2020').

von Volker U. (Firma: Ingenieurbüro Volker Urban) (ib-volker-urban)


Bewertung
2 lesenswert
nicht lesenswert
D. C. schrieb:
> Was haltet ihr von der Geschäftsidee, eine umfangreiche Checkliste zu
> erstellen und für jeden Fehler der damit gefunden wurde 10€ zu
> verlangen?

Gibt es schon, nennt sich 'Freiberufler, der zum Feuerlöschen kurz vor 
Projektabbruch eingekauft wird.' ;-)

von Christoph Z. (christophz)


Bewertung
1 lesenswert
nicht lesenswert
Der Checker vom Neckar schrieb:
> mich würde interessieren ob ihr Checklisten benutzt um Schaltpläne oder
> Layouts zu prüfen?
> Wenn ja, habt ihr die selbst erstellt oder ist sie in der Firma
> gewachsen?

Ja, definitiv.

Checklisten für Schema und Layout sind eine Sammlung vom Empfehlungen, 
Regeln, Optimierungen, früheren Fehlern etc.

Es lohnt sich alle Checklisten die man im Laufe der Zeit findet 
anzusehen, und die neuen Punkte, deren Sinn man versteht, in die eigene 
Liste aufzunehmen. Man lernt immer wieder dazu!

Diese Listen können recht lang werden, weil sie alle Aspekte abdecken 
sollen. Dazu gehören mindestens Funktionalität, Fehlerverhalten, 
Ein-/Ausschaltverhalten, Herstellbarkeit, Testbarkeit, Normgerecht, 
Mechanisch/Termische Kompatibilität, Kosten Optimierung, Ausbeute 
erhöhen.

Ich will mir das nicht alles auswendig im Kopf merken. Das ist mir zu 
anstrengend und darum wird es aufgeschrieben.

Es wurde auch Teilweise auf ERC und DRC verwiesen. Ja natürlich soll 
automatisiert werden was kann. Es ist aber wichtig, dass am Schluss 
keine Fehler mehr vorhanden sind oder unabhängig geprüft wurde, dass die 
verbliebenen OK sind.
Und wie schon geschrieben wurde, die ERC/DRC Einstellungen überprüfen 
ist wichtig (vor allem wenn sie nur irgendwo im GUI versteckt sind und 
nicht mit dem Projekt dokumentiert werden. Super wenn es im Schema 
sichtbar ist).

Beitrag #6401531 wurde von einem Moderator gelöscht.
von Knallt ihn ab, den Troll (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Volker U. schrieb:
> Ich rate dringend davon ab, den Begriff "Pfuscher" zu verwenden und
> dagegen etwas Empathie aufzubringen um die Ursachen für gewisse
> Handlungen zu ergründen. Höchstens das man dem Begriff "Pfuscher"
> selbstkritisch auf sich anwendet, um zu verstehen, was bei der
> Einführung der Checkliste schief gelaufen ist

Naja, ich sehe das halt so: Meckern ist der erste Schritt zur Besserung. 
Und klare Worte unterbinden Fehlinterpretationen.
Aber keine Sorge, wenn ich Mist baue, dann drücke ich das ebenso klar 
aus.

Davon abgesehen kann es durchaus sein daß ich hier vielleicht auch etwas 
übertreibe, mich ärgert die Arbeitsweise in vielen Firmen einfach.


Volker U. schrieb:
> Bei den Gehäuse-Kondensatorbeispiel kann ich mir gut vorstellen, das der
> Bearbeiter vor der Wahl aus
>
> *sicherer Anschiss wegen Terminverschiebung weil Freigabe nicht erteilt
> *möglischer Anschiss wegen Fertigung aus nachlässig geprüften Unterlagen
>
> stand.

Wie ich schon sagte - der Fisch stinkt vom Kopf an. Auch wenn mich die 
Einstellung zu Gründlichkeit, Dokumentation und Struktur vieler Kollegen 
ankotzt, liegt es vor allem an der Firma vernünftige Arbeitsprozesse zu 
schaffen.
Du hast mit deiner Einschätzung weitgehend recht (die MA in der 
Entwicklung hatten zum Jahresende teilweise >100 Überstunden auf dem 
Zeitkonto, das zum Jahresende ersatzlos genullt wurde), MA 
dauerüberlastet, zuviele Projekte, usw. Mangelhafte Organisation auf 
jeder Ebene.

Aber: Es gibt auch Möglichkeiten, gerade solche Checks sofort 
durchzuführen. Es gibt Kollaborationssysteme für Elektronik- und 
Mechanik-CADs, wo solche Fehler sofort oder zeitnah auffallen. Wenige 
Monate vor dieser Fehlfertigung habe ich so etwas vorgeschlagen. Wurde 
abgelehnt.


Volker U. schrieb:
> Mit dem bloßen Erstellen und Aufdoktrinieren einer Checkliste ist es
> leider nicht getan, man (Projektleitung, Arbeitsvorbereitung) muss auch
> die konsequente Umsetzung der selben ermöglichen.
>
> In dem Heftchen "Weniger schlecht programmieren ISBN 978-3-89721-567-2
> wird einiger Text daran verwandt wie man Änderungen im Arbeitsablauf
> (schonend) den Mittkollegen beibringt. Den Umstieg einfach machen,
> ausgiebig schulen, keinen Druck aufbauen, selber die Erfahrung machen
> lassen.

Ich kenne das Buch, fand es jedoch nicht sonderlich gut, auch wenn da 
trotzdem einige nützliche Dinge drinstanden.
Sicher reicht das bloße Anbefehlen neuer Prozesse nicht - man muß das 
auch leben. Keine Frage. Aber das ist tatsächlich dann eine Frage der 
Einstellung von jedem selbst und an dieser Stelle kann auch die Firma 
nix mehr dafür. Man muß schon professionell sein wollen.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




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

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