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.
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
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
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 ... .
Beitrag #6393680 wurde von einem Moderator gelöscht.
Beitrag #6393739 wurde von einem Moderator gelöscht.
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.
Beitrag #6393957 wurde von einem Moderator gelöscht.
Beitrag #6394197 wurde von einem Moderator gelöscht.
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?
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.
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!
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.
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?
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
Old P. schrieb: > Heute reichts > gerade noch zum Mikrofonverstärker... Fürs Gehör in späten Jahren... ;-)))
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
Old P. schrieb: > "Nimm die Höhen > raus" wird dann gelegentlich gebrüllt ;-) Verständlich... Dazu braucht man keine "Checklist"...
Mani W. schrieb: > Was ist ein "Truckfaktor" in Deiner Sicht? https://de.m.wikipedia.org/wiki/Truck_Number
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...
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).
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
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.
Beitrag #6396162 wurde von einem Moderator gelöscht.
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.
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.
Was haltet ihr von der Geschäftsidee, eine umfangreiche Checkliste zu erstellen und für jeden Fehler der damit gefunden wurde 10€ zu verlangen?
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.' ;-)
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.
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!
Beitrag #6426425 wurde von einem Moderator gelöscht.
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: > Wollt alle für Automobil Was soll solch eine Unterstellung bzw. Beleidigung? Ich nehme Aufträge aus fast allen Branchen, auch solche mit hohen Sicherheitsanforderungen, an, aber mit Sicherheit nicht von der korrupten deutschen Automobilindustrie.
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ß."
Pob schrieb: > Hier offenbart sich endlich die Wahrheit. Die meisten in diesem Forum > haben mit Qualität und strukturierter Arbeitsweise nichts am Hut. Was erwartest Du in einem Forum, wo vom Chefentwickler über fast professionellem Amateur bis zum halbwissenden Halbelektriker sehr unterschiedliche Menschen unterwegs sind? > Am besten hat mit gefallen " Ich verwende meine eigenen Checklisten". > Nicht einmal das 4-Augenprinzip eingehalten. Ich als Amateur habe zu 99% nur das 2-Augenprinzip eingehalten (manchmal nichtmal das...) > 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. Ich will zu allererst für mich und eventuell für Freunde/Kollegen entwickeln, mehr nicht. > Es ist so lachhaft. Eben! Schon die Ausgangsfrage in der Überschrift ist falsch! Bei Deiner Erwartungshaltung hätte da zumindest "... im Job..." stehen müssen. Steht da aber nicht! Old-Papa
:
Bearbeitet durch User
Beitrag #6451924 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.