Arbeitet ihr mit Checklisten?

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.

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.

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

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

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.

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 ... .

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

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.

Code Review Checklisten bei F+E Softwareabteilung Siemens VDO Schwalbach 
benutzt.

>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.

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.

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.

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.

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.

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

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).

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.

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.

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.

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

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.

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.

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.

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.

...

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.

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

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..

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).

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.

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').

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.' ;-)

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.

besonders bei Analogschaltungen hilft simulieren! damit kann man im 
Vorfeld Denkfehler und Probleme rechtzeitig erkennen und vermeiden.

ansonsten: Meine Methode ist recht altbacken: Ich drucke den Schaltplan 
komplett aus und gehe Seite für Seite und Signal für Signal durch und 
markiere die Stellen mit einem grünen Textmarker die okay sind.

Es klingt blöd, aber es ist sehr effektiv!

Hier offenbart sich endlich die Wahrheit. Die meisten in diesem Forum 
haben mit Qualität und strukturierter Arbeitsweise nichts am Hut.

Am besten hat mit gefallen " Ich verwende meine eigenen Checklisten". 
Nicht einmal das 4-Augenprinzip eingehalten.

Wollt alle für Automobil und Luftfahrt entwickeln und wisst nicht mal, 
dass es bei entsprechend ernstzunehmenden Kunden dafür vorgegeben 
Prozesse gibt. Das Kunden ein Review der internen Firmenprozesse 
durchführen.

Es ist so lachhaft.

Pob schrieb:
>  Das Kunden ein Review der internen Firmenprozesse
> durchführen.

Das mit den Fachbegriffen aus dem Qualitätsmanagment üben wir noch, da 
ist ein 'Audit' gemeint, kein 'Review'.

Tipp: 
https://www.german-testing-board.info/wp-content/uploads/2016/08/CT_Glossar_DE_EN_V23.pdf

Das ist lediglich das Glossar des Softwaretestens und das mindeste was 
man über Testen wissen könnte.

> "Am besten hat mit gefallen " Ich verwende meine eigenen Checklisten".
> Nicht einmal das 4-Augenprinzip eingehalten."
Ich bevorzuge die Bezeichnung "2-Paar Augen Prinzip", weil das auf 
zugrundeliegene Paar-prinzip oder pair-programming direkt hinweist.
https://m.heise.de/developer/artikel/Pair-Programming-Das-Vier-Augen-Prinzip-im-Erfahrungsbericht-2748049.html?seite=all

Aber das "Zwei Paar Augen Prinzip" ersetzt nicht Checklisten. Und 
externe Checklisten ersetzen auch nicht das Wissen über eigene 
(typische) Fehler.

PS:
Die Definition von checklisten -Test aus oben genannten Dokument:
"Ein erfahrungsbasiertes Testentwurfsverfahren, bei dem der erfahrene 
Tester eine Liste von Kontrollpunkten nutzt, die beachtet, überprüft 
oder in Erinnerung gerufen werden müssen; oder eine Menge von Regeln 
oder Kriterien gegen die ein Produkt verifiziert werden muß."