Ein Kollege ist ein Bastler der übelsten Sorte: - schreibt keine Dokumentation - hält sich nicht an den Style Guide - meint nur seine Sicht der Dinge ist richtig - liest keine internen Dokumente und nervt mit sinnlosen Fragen Im Team wird die Stimmung immer schlechter, der Projektleiter ignoriert die Situation und der disziplinarische Vorgesetzte drückt sich vor der Verantwortung. Habt ihr auch solche Kollegen? Wie geht man damit um?
JoBu schrieb: > - schreibt keine Dokumentation Existiert denn dafür ein Arbeitsauftrag? JoBu schrieb: > - hält sich nicht an den Style Guide Würde hier nicht durchs Code Review gehen und dementsprechend könnte er nicht einchecken. JoBu schrieb: > ihr auch solche Kollegen? Nein JoBu schrieb: > Wie geht man damit um? Es zum Problem des Vorgesetzten / Projektleiters machen.
> Autor: JoBu (Gast) > Datum: 07.11.2017 13:56 > Ein Kollege ist ein Bastler der übelsten Sorte: Was heißt hier Bastler ? Hardware, Software ? Wenn das was er fabriziert auch funktioniert ist das ganze doch in Ordnung. > - schreibt keine Dokumentation Soll öfters vorkommen. Auch eine Möglichkeit sich unabhängig zu machen. - hält sich nicht an den Style Guide Wer ist das ? Kenne nur Obergefreiter und Stabsfeldwebel. - meint nur seine Sicht der Dinge ist richtig Das ist sein gutes Recht, vielleicht hat er recht. - liest keine internen Dokumente und nervt mit sinnlosen Fragen Es gibt keine sinnlosen Fragen. Da hast du ein Problem mein Guter. Der Kollege sitzt da eventuell am längeren Hebel, musst nur aufpassen das du dich da nicht ins Abseits manövrierst.
JoBu schrieb: > Im Team wird die Stimmung immer schlechter, der Projektleiter ignoriert > die Situation und der disziplinarische Vorgesetzte drückt sich vor der > Verantwortung. Dann macht das Projekt eventuell eine Bauchlandung. Ich hoffe du arbeitest für ein festes Gehalt und nicht für einen Bonus. Firmen sind von oben nach unten organisiert. Wenn Vorgesetzter und Projektleiter, also oben, nichts tun kannst du in erster Näherung davon ausgehen, dass sie finden es ist ok so wie es ist. Vielleicht sogar, dass sie es genau so wollen. Mindestens, dass sie den Aufwand etwas zu ändern höher einschätzen als der Schaden der angerichtet wird. > Wie geht man damit um? Such dir was aus: Leb damit. Wechsel das Projekt. Wechsel die Gruppe. Wechsel die Firma. Bekehre den Kollegen. \ Bekehre den Projektleiter. |__ Viel Spaß Bekehre den Vorgesetzten. / Und: Sieh zu, dass dir niemand eine Schuld in die Schuhe schiebt sollte das Projekt scheitern.
JoBu schrieb: > Habt ihr auch solche Kollegen? Wie geht man damit um? Na ist doch super. Statt einem Dampfplauderer und Pflichtenheftschreiber, habt ihr einen der die Arbeit macht. Lass ihn machen und konzentriere dich auf das was du kannst: Dokumentieren der Arbeit die er macht.
JoBu schrieb: > - liest keine internen Dokumente und nervt mit sinnlosen Fragen Habt wohl zu viele von denen, überall verstreut, ohne dass noch einer den Überblick hat, wo was in welcher Version liegt. Wah?
Zunächst mal solltest Du (Dir oder auch wem immer) folgende Fragen
beantworten:
1. Gibt es in eurer Firma ein Qualitätsystem?
Wenn Ja zu 1:
2. Widerspricht das Verhalten deines Kollegen dem Qualitätssystem?
Wenn Ja zu 2: Sprich den QM oder den Fachvorgesetzten an
Wenn Nein zu 2: Finde Dich damit ab oder versuche
das Qualitätssystem zu verändern. Viel Spass.
Wenn Nein zu 1:
Überlege Dir sehr genau, welche der Dinge, die Du an ihm kritisierst,
haltbare Punkte sind.
- schreibt keine Dokumentation
- Machen das Alle Anderen? Wenn ja, sind diese Dokumentation
so hilfreich und gut, dass
sie den Workflow in der Abteilung wirklich verbessern? Oder wird
damit
nur ein Haufen Daten- oder Papiermüll produziert, den sich danach
kein Mensch mehr ansieht?
- Hält sich nicht an den Style Guide
- Ist sein Code ansonsten gut? Style Guides sind nice to have
und SOLLTEN beachtet werden,
aber sie sind keinerlei Garantie für guten Code und erst recht kein
Ersatz. Manche Style Guides enthalten komplett untauglichen Unfug,
sind irgendwie mal on the fly zusammengepopelt worden oder
in manchen Fällen sogar widersprüchlich mit gutem Code.
- meint nur seine Sicht der Dinge ist richtig
- Das ist sehr vage formuliert. Hast Du Beispiele?
- liest keine internen Dokumente
- Um welche Art von Dokumenten geht es dabei? In manchen
kopflastigen Firmen wird wesentlich mehr
geschrieben als anständige Arbeit getan. In solchen Fällen
kann es ein gesundes Verhalten sein,
nicht Alles zu Lesen, was Andere so vor sich hin schreiben.
- ...und nervt mit sinnlosen Fragen
- auch hier bitte Beispiele. Hinterfragen ist nicht immer schlecht,
auch wenn Manche es als nervig ansehen.
Wohlgemerkt, es KANN sein, dass Dein Kollege ein nerviger Blubberkopf
ist. Es kann aber auch sein, dass er der Einzige in der Abteilung ist,
der nachdenkt und die Eier hat, sich gegen historisch gewachsene
sinnlose Prozesse zur Wehr zu setzen. Oder iregndwas dazwischen. Das zu
beurteilen geht aber nur, wenn Du wesentlich konkreter wirst.
JoBu schrieb: > Ein Kollege ist ein Bastler der übelsten Sorte: > - schreibt keine Dokumentation > - hält sich nicht an den Style Guide > - meint nur seine Sicht der Dinge ist richtig > - liest keine internen Dokumente und nervt mit sinnlosen Fragen > > Im Team wird die Stimmung immer schlechter, der Projektleiter ignoriert > die Situation und der disziplinarische Vorgesetzte drückt sich vor der > Verantwortung. > > Habt ihr auch solche Kollegen? Wie geht man damit um? Könnte schlimmer kommen, ist aber sicher keine angenehme Situation ... Generell wäre es wohl ratsam, schon bei der Unterzeichnung des Arbeitsvertrags klar zu stellen, welchen qualitativen Aspekten im Unternehmen welcher Stellenwert zukommt; und wie/woran die Qualität der Arbeit (z.B. in Leistungsbewertung) gemessen wird. Stell dir einfach vor, der nette Kollege sucht demnächst den Schulterschluß mit der Projektleitung und deinen Vorgesetzten - falls er es nicht längst getan hat .. Eventuell hast du ihn nicht genug unterstützt? Eine Frage oder Email nicht SOFORT beantwortet? Für mich klingt das sehr nach dem unvermeidlichen Blender, der einem in jedem Unternehmen oder Projekt irgendwann begegnet. Bist Du sicher, daß die schlechte Stimmung im Team ihm und nicht eventuell bald Dir angelastet wird? Weißt Du, was er mit Deinen Kollegen so über Dich redet? - hinter Deinem Rücken? Wenn Du einen guten Stand hast im Unternehmen, denke ich, solltest Du das direkte Gespräch mit deinen Vorgesetzten suchen. Falls Du dich aber dort auch nur ansatzweise nicht sicher fühlst und es dein Alter zuläßt (< 35), ist es schlicht das Einfachste, das Weite zu suchen (bewerben, wechseln). Letztendlich investierst Du viel Zeit und Energie in ein Unternehmen, daß auf Deine Ansichten offensichtlich wenig wert legt. Und Du solltest an allererster Stelle an diejenigen denken, die Du mit Deiner Arbeit unterstützt: Deine Familie, Frau, Kinder, Dich selbst ... Dein AG hat Dich eingestellt, weil er sich einen Gewinn erhoffte. Schwer zu sagen, ob er überhaupt Produkt- oder Projekt-orientriert denkt. Eventuell ist ihm das ganze Universum Schnurz, solage nur der nächste Liefertermin irgendwie eingehalten wird - welchen Gewinn hat er Dir zugebilligt? Und wie, denkst Du, würde sich eine konstruktive, produktive Zusammenarbeit mit Kollegen auf Dein Wohlbefinden und Deine Arbeitsleistung auswirken? Nur ein paar meiner Gedanken zum Thema ..
Gutes Thema, war auch in einer ähnlichen Situation mit so einem Bastler Kollegen. Chef hatte nicht viel Ahnung von Programmierung, dem reichte es schon, wenn einfach jemand viel macht, irgendwas programmiert, sehr beschäftigt aussieht. Ich versuchte, Stabilität und Qualität reinzubringen. Das klappte eigentlich. Wichtig, ich arbeitete mit wirklich konkreten einfachen Beispielen. Irgendwann ging dieser Kollege von selbst.
klausi schrieb: > Irgendwann ging dieser Kollege von selbst. ... in Rente oder das Projekt in die Binsen? Warum kann man keine Bastlerlösung weiterentwickleln und dokumentieren? Auch ein schlechtes Beispiel wird manchmal gebraucht. :-)
JoBu schrieb: > Ein Kollege ist ein Bastler der übelsten Sorte: 1) Wie lange bist Du, wie lange ist er dort? Also, haben andere schon mehr Erfahrung mit ihm? 2) ich kenne das andere Extrem: schlechte Arbeit, die durch Dokumentation und Style Guide gerechtfertigt werden. Und soweit ich zurückdenken kann, waren viele Vorgaben einfach schon immer grenzwert. Nassi-Shneyderman Represenatitionen zu pflegen, Viele Kommentare, Funktionen nie mehr als 100 Zeilen, nur ein Exit-Point, keine Gotos. Ja, es gibt Regeln, wo sowas Sinn macht, und vermutlich gab es mehr Missbrauch als tolerierbar, ... aber absolut ist sowas halt Quatsch und irgendwann pendeln selbst strengste Vorgaben (Autosar) ins Gegenteil. Wenn es dagegen um sowas geht wie Tabs-Weiten und Klammer-Style, ... dann sollte man darüber reden und zumindest seine Argumente kennen. Und den Stab dann erst über die Leistung brechen. Bis dahin kann man sich nervenden Fragen auch genervt (auch kollektiv) entziehen. In einem anderen Forum fragt mal ein Chef ganz ähnlich. Entlassen wollte er ihn nur deshalb nicht, weil der Mitarbeiter die Hälft der gesamten Arbeit machte.
Achim S. schrieb: > irgendwann pendeln selbst strengste Vorgaben (Autosar) ins Gegenteil. Autosar sorgt für maximale Produktivität und ermöglicht Innovation, da der Entwickler sich auf das Wesentliche konzentrieren kann.
JoBu schrieb: > Im Team wird die Stimmung immer schlechter, der Projektleiter ignoriert > die Situation und der disziplinarische Vorgesetzte drückt sich vor der > Verantwortung. Betriebsrat verständigen. Keiner vorhanden? Dann wird's Zeit. Sonst droht Machtmissbrauch.
Embedded Guy schrieb: > Achim S. schrieb: >> irgendwann pendeln selbst strengste Vorgaben (Autosar) ins Gegenteil. > > Autosar sorgt für maximale Produktivität und ermöglicht Innovation, da > der Entwickler sich auf das Wesentliche konzentrieren kann. These: Ein Softwareentwickler schafft keine Innovationen, weil er strikt nach Spec./Req. umsetzen muss. Produktivität ist relativ, was nützt die effizienteste Entwicklung wenn das entwickelte Produkt keinen Käufer findet. Oder es so extrem mach KISS aud das Wesentliche reduziert wurde, das kein Spass für den Entwickler und kein "Wow!" für den Käufer übrig blieb. Was bleibt ist große Langeweile.
> Habt ihr auch solche Kollegen? Wie geht man damit um?
Indem du ihm einfach sagst, was falsch läuft. Musst du dafür erst einen
Thread hier starten? Sozial inkompetent?
Was sollen wir dir denn raten?
Embedded Guy schrieb: > Autosar sorgt für maximale Produktivität und ermöglicht Innovation, da > der Entwickler sich auf das Wesentliche konzentrieren kann. Das merke ich mir und denke daran, wenn ich das nächste mal eine Autosar-XML-Datei bearbeiten, lesen und mergen muss.
JoBu schrieb: > Ein Kollege ist ein Bastler der übelsten Sorte: > - schreibt keine Dokumentation > - hält sich nicht an den Style Guide > - meint nur seine Sicht der Dinge ist richtig > - liest keine internen Dokumente und nervt mit sinnlosen Fragen Und selbst? Hat man keine eigen Sicht der Dinge und kann auch keine Fragen formulieren weil man komplett vom Einhalten des Style Guides, lesen von internen Dokumenten und verfassen von pro forma Dokumenten okkupiert ist? Ich sag mal so, ohne Bastler wie Steve Wozniak, Jay Miner, Clive Sinclair und Sophie Wilson, die sich selbst, also ohne niedergeschrieben Prozesse und Arbeitsanleitung, eine produktive Arbeitsumgebung schufen, würden der Grossteil der Nutzer heute Computer nur als langweilig graue Kisten die in Rechenzentren stehen und Steuern ausrechnen, kennen. Es sind die Bastler die die Technik in den Haushalt von Ottillie Normalverbraucherin bringen.
Du kannst ihm also nicht das Wasser reichen? Oder wie soll ich dein Posting verstehen?
Autonarr schrieb: > Embedded Guy schrieb: > Autosar sorgt für maximale Produktivität und ermöglicht Innovation, da > der Entwickler sich auf das Wesentliche konzentrieren kann. > > Das merke ich mir und denke daran, wenn ich das nächste mal eine > Autosar-XML-Datei bearbeiten, lesen und mergen muss. Mit den richtigen Profitools von Ingenieuren für Ingenieure wird auch das zur vergnüglichen Ausflugsfahrt in die wundersame Welt der Bits und Bytes. Erwünschter Wettbewerb auf Ebene des Toolings (nur da) bringt die nutzerfreundlichsten Tools hervor, die das feuchte Auge des Ingenörs jemals erblickt hat. Dank offener Standards ist stets ein 100% reibungsfreies Zusammenspiel aller Komponenten gewährleistet. Da entwickelt sich die ECU fast von alleine! Warum entwickeln, wenn man in der Zeit doch auch modellieren kann. AUTOSAR - embedded transparency enabling maximum fun and speed on the high way to cost efficiency
Der Superlöter schrieb: > Du kannst ihm also nicht das Wasser reichen? Eventuell das Lötwasser: https://www.felder.de/produktausgabe-sani-haus/kategorie/loetwasser/artikel/loetwasser.html MfG Paul
Michael B. schrieb: > Na ist doch super. Statt einem Dampfplauderer und > Pflichtenheftschreiber, habt ihr einen der die Arbeit macht. > > Lass ihn machen und konzentriere dich auf das was du kannst: > Dokumentieren der Arbeit die er macht. Das nennt man Arbeitsteilung :-) Neben dem Dokumentieren kann man ja auch gleich (stellvertretend natürlich - muss man ja nicht betonen) die Lorbeeren abholen :-)
Arbeitszeugnis schrieb: > Mit den richtigen Profitools von Ingenieuren für Ingenieure wird auch > das zur vergnüglichen Ausflugsfahrt... Na danke. Mein Sarkasmusdetektor ist gerade mit einer Kraft von 1 mio Tonnen TNT explodiert. Jetzt darf ich hier den Stadtteil bezahlen.
Autonarr schrieb: > Jetzt darf ich hier den Stadtteil bezahlen. Das ist doch finanziell überhaupt kein Problem, wenn man sich in Erinnerung ruft, mit welchen Gehaltsangaben sich die Leute hier jeden Tag übertrumpfen. :)) MfG Paul
JoBu schrieb: > Ein Kollege ist ein Bastler der übelsten Sorte: > - schreibt keine Dokumentation > - hält sich nicht an den Style Guide > - meint nur seine Sicht der Dinge ist richtig > - liest keine internen Dokumente und nervt mit sinnlosen Fragen Vielleicht ist er ja so etwas wie ein Genie. Wenn du ihm den aufgezählten "Kleinkram" vom Hals hältst und selber übernimmst, führt er euch blitzschnell zur Lösung!?!
DC schrieb: > Vielleicht ist er ja so etwas wie ein Genie. Wenn du ihm den > aufgezählten "Kleinkram" vom Hals hältst und selber übernimmst, führt er > euch blitzschnell zur Lösung!?! Dieter F. schrieb: > Michael B. schrieb: >> Na ist doch super. Statt einem Dampfplauderer und >> Pflichtenheftschreiber, habt ihr einen der die Arbeit macht. >> >> Lass ihn machen und konzentriere dich auf das was du kannst: >> Dokumentieren der Arbeit die er macht. > > Das nennt man Arbeitsteilung :-) Neben dem Dokumentieren kann man ja > auch gleich (stellvertretend natürlich - muss man ja nicht betonen) die > Lorbeeren abholen :-) Ja - genau - ist doch alles gut :-)
DC schrieb: > Vielleicht ist er ja so etwas wie ein Genie. Wenn du ihm den > aufgezählten "Kleinkram" vom Hals hältst und selber übernimmst, führt er > euch blitzschnell zur Lösung!?! Das Vorgehensmodell "Mick Jagger".
Beitrag #5250891 wurde von einem Moderator gelöscht.
Hannes J. schrieb im Beitrag #5250891: > Das kann man sogar ganz offen machen in einer Besprechung verkünden "Den > Code vom Kollegen X fasse ich nicht an.", "Kollege X weiß das alles > besser, soll unser Held es doch alleine machen". Fertig. Genau so.
Beitrag #5251013 wurde von einem Moderator gelöscht.
Beitrag #5251035 wurde von einem Moderator gelöscht.
Beitrag #5251051 wurde von einem Moderator gelöscht.
Beitrag #5251059 wurde von einem Moderator gelöscht.
Beitrag #5251071 wurde von einem Moderator gelöscht.
Hannes J. schrieb im Beitrag #5250891: > Nein, in 99,999% ist der Typ ein Arsch, ein nicht teamfähiger > Einzelkämpfer, ein Angeber, der sich für den geilsten Programmierer der > Welt hält, sich überlegen fühlt, ein Heldensyndrom und soziale Defizite > hat. In der Idealen Welt, wo alle Programmierer gleich sind, hast Du natürlich recht. Er gehört gefeuert. In der realen Welt werden bei seinen Projekten laufend Fehler gemeldet, ist ständige Nacharbeit erforderlich und es gibt nur Ärger. Leider fragen die Kunden aber genau seine Produkte nach, obwohl die besseren, im Konsens gestreichelten doch viel zuverlässiger sind (zumindest an Reklamationen gemessen).
Beitrag #5251081 wurde von einem Moderator gelöscht.
Der Andere schrieb: > Hannes J. schrieb im Beitrag #5250891: >> Das kann man sogar ganz offen machen in einer Besprechung verkünden "Den >> Code vom Kollegen X fasse ich nicht an.", "Kollege X weiß das alles >> besser, soll unser Held es doch alleine machen". Fertig. > > Genau so. Und der Chef weis es auch zu würdigen, wenn jemand seine Grenzen kennt und nicht bei den guten mitspielen möchte.
Beitrag #5252400 wurde von einem Moderator gelöscht.
Arbeitszeugnis schrieb: > Mit den richtigen Profitools von Ingenieuren für Ingenieure wird auch > das zur vergnüglichen Ausflugsfahrt in die wundersame Welt der Bits und > Bytes. Hahaha. Nur geil!
Geheim schrieb: > Arbeitszeugnis schrieb: > Mit den richtigen Profitools von Ingenieuren für Ingenieure wird auch > das zur vergnüglichen Ausflugsfahrt in die wundersame Welt der Bits und > Bytes. > > Hahaha. Nur geil! Ich sag nur: Head of Superior Senior Chief Cow Milking Marketing Proliferation Facilitation Expert Group Facility Management Services Beginner
C. A. Rotwang schrieb: > findet. Oder es so extrem mach KISS aud das Wesentliche reduziert wurde, > das kein Spass für den Entwickler und kein "Wow!" für den Käufer übrig > blieb. Was bleibt ist große Langeweile. In meiner Branche (Industrieautomatisierung) ist ein "Wow" beim Kunden schon fast der worst-case :-) So drüber nachgedacht werden ein großer Anteil produzierten Produkte niemals ein "Wow" beim Kunden hervorrufen und wurden dazu auch nie entwickelt. Was kein Schaden sein muss. Wann hört man schon mal: "Wow" Spannbetonbrücke "Wow" Klopapier "Wow" Kanalrohr "Wow" Heizkörper "Wow" Spannungsregler .... 99% der Entwicklungsleistung in der Wirtschaft sieht kein Kunde, und wird auch nie ein WOW hervorrufen. Von den meisten Dingen wird einfach nur erwartet, dass sie funktionieren. Das betrifft auch 99% der Dinge in einem Iphone. Wenn das dann "innovativ" ist (=nach Buzzwords zusammengefrickelt) bringt das nichts. von den meisten Dingen wird einfach erwartet, dass sie "in time" "in quality" und "in budget" nach einer Spezifikation entstehen. Entwicklung ist keine kreative Selbstverwirklichung. Wer das will, sollte Künstler werden.
Hmm schrieb: > Entwicklung ist keine kreative Selbstverwirklichung. Wer das will, > sollte Künstler werden. Man kann sich ja nicht nur durch Kreativität selbst verwirklichen, sondern zB auch durch Macht und Einfluss im Unternehmen, ersichtlich an geilen Jobbezeichnungen. "Bewahre mich vor der Angst, ich könnte das Leben versäumen. Gib mir nicht, was ich mir wünsche, sondern was ich brauche. Lehre mich die Kunst der kleinen Schritte." Frohe Weihnachten.
Beitrag #5253103 wurde von einem Moderator gelöscht.
Hmm schrieb: > C. A. Rotwang schrieb: >> findet. Oder es so extrem mach KISS aud das Wesentliche reduziert wurde, >> das kein Spass für den Entwickler und kein "Wow!" für den Käufer übrig >> blieb. Was bleibt ist große Langeweile. > > In meiner Branche (Industrieautomatisierung) ist ein "Wow" beim Kunden > schon fast der worst-case :-) Ebenfalls Zwinker, damit hast du sicher recht. > Entwicklung ist keine kreative Selbstverwirklichung. Wer das will, > sollte Künstler werden. Oder Erfinder. Ein wichtiges Handwerkszeug eines Erfinders/Entwicklers ist die Improvisation, jedenfalls zu meinen Zeiten und in meinem Metier bspw. Prototypen. Natürlich gibt es da eine Grenze wo notwendige Improvisation in Flickschusterei umschlägt, genauso wie es eine Grenze gibt wo Entwickeln nach process in fortschrittslose Selbstbeschäftigung umschlägt. Oder man wartet darauf das der "zuständige" vorbeikommt und weiterhilft als sich selbst helfen. Spätestens bei einem Jobwechsel fällt der, der nur das Überleben in einer detailiert geregelten Umgebung beherrscht auf die Fresse und wäre froh er hätte einige Eigenschaften eines Bastlers die ihm es einfachersich und die neue Umgebung aufeinander anzupassen.
Ich bin auch so einer. Doku kommt immer als letztes, nachdem ich schon vergessen habe, was ich zwischendurch gemacht habe.
Teddy schrieb: > Ich bin auch so einer. Doku kommt immer als letztes, nachdem ich schon > vergessen habe, was ich zwischendurch gemacht habe. Das erfüllt nicht die Definition für einen Bastler sondern für einen verantwortungslosen Depp.
C. A. Rotwang schrieb: > Teddy schrieb: > Ich bin auch so einer. Doku kommt immer als letztes, nachdem ich schon > vergessen habe, was ich zwischendurch gemacht habe. > > Das erfüllt nicht die Definition für einen Bastler sondern für einen > verantwortungslosen Depp. ??? Das war überspitzt dargestellt. Aber ich muss schon 5 bis 10 Minuten überlegen was ich zuvor gemacht habe. Denke, ich sollte diese Einstellung überdenken.
Teddy schrieb: > Ich bin auch so einer. Doku kommt immer als letztes, nachdem ich schon > vergessen habe, was ich zwischendurch gemacht habe. Das kann man sich in richtigen Firmen aber nicht erlauben.
Teddy schrieb: > Ich bin auch so einer. Doku kommt immer als letztes, nachdem ich > schon vergessen habe, was ich zwischendurch gemacht habe. Und die Produktvalidierung wird dann bei der Auslieferung gemacht oder wie?
Nop schrieb: > Teddy schrieb: >> Ich bin auch so einer. Doku kommt immer als letztes, nachdem ich >> schon vergessen habe, was ich zwischendurch gemacht habe. > > Und die Produktvalidierung wird dann bei der Auslieferung gemacht oder > wie? Und das Ergebnis lautet: Laut Doku müsste das funktionieren.
Nop schrieb: > Und das Ergebnis lautet: > Laut Doku müsste das funktionieren. Das ist Verifikation, nicht Validierung.
Angehängte Dateien:
-
zspace_000454.png
900 KB
Ich bastle selbst gern. Ich leide aktuell darunter, dass meine Dokumente kaum jemand liest.
Nop schrieb: > Nop schrieb: > >> Und das Ergebnis lautet: >> Laut Doku müsste das funktionieren. > > Das ist Verifikation, nicht Validierung. Du hast den Fehler gefunden!
Also wenn ich da auch mal aus dem Nähkästchen blaudern darf. Im letzten Betrieb war ich der einzige der sein Zeugs zu 100 % in Doors dokumentiert hat. Das ist extrem wichtig traceability zum testen nach a spice. Das Ergebnis: die Architekten haben meinem Softwaremodul alle Signale zugeordnet auch jene welche dort nix verloren hatten, damit ich für Sie requirements schreibe ;) Die Signale waren dann doppelt vorhanden nur bei mir eben nutzlos :) Ich mag es wenn ich jede Zeile im Quellcode einem Requrement zuordnen kann. In der Folge hab ich die Doku auf ein stark kritisierfähiges Mass zurückgefahren, mit Erfolg. Wobei ganz weglassen geht nicht das ist in jedem Fall so. Aber bevor jetzt über die bösen nichtsokumentierer gelästert wird... es gibt auch die andere Seite...
Was ich eigentlich sagen wollte, wenn die Dokumentation sinnvoll angelegt ist, machen das die Leute normalerweise echt gern. Tut auch mal gut nicht über Syntax und Speicher nachdenken zu müssen. Die Frage muss doch lauten, wie machen wir das dem guten Menschen schmackhaft... draufhauen ist auf jeden Fall eher eine Abreaktion der Kollegen und aus meiner Sicht keine gute Idee.
Werkler schrieb: > Teddy schrieb: > Ich bin auch so einer. Doku kommt immer als letztes, nachdem ich schon > vergessen habe, was ich zwischendurch gemacht habe. > > Das kann man sich in richtigen Firmen aber nicht erlauben. Wie recht du hast. Aber hey: Warum Probleme lösen, wenn es genug Schuldige gibt. Einfach genug Absolventen einstellen. Und jegliche Form von Mitsprache verhindern, wo es nur geht. Denn Kommunikation funktioniert am besten, wenn sie nur in einer Richtung (Broadcast) stattfindet. "Toxisch" wie wir von einem hart arbeitenden Mittelschichtler gelernt haben.
Hmm schrieb: > Entwicklung ist keine kreative Selbstverwirklichung. Wer das will, > sollte Künstler werden. Oder eben Entwickler für Endkunden-Produkte werden in einem Mittelständischen oder kleinen Unternehmen (wo es keine strikte Aufteilung Designer <-> Entwickler gibt). So rar sind diese Jobs nicht. Hat aber natürlich auch Nachteile für die mehr oder weniger breite Masse zu entwickeln deren Wünsche (denen sie sich oft nicht mal selbst bewusst sind) man nicht aus einem Faktsheet ablesen kann.
:
Bearbeitet durch User
robocash schrieb: > Ich bastle selbst gern. Ich leide aktuell darunter, dass meine Dokumente > kaum jemand liest. Du hast es genau auf den roten Punkt gebracht. Heute wird viel lieber dokumentiert als produziert, aber damit kann man keine Mark verdienen. Die Dokumente landen in den Aktenschrank und werden nie wieder angeschaut. Es haben sich auch schon Firmen an DIN ISO 9000, Audit, Zertifikaten, Arbeitssicherheit und Produktinformationen totdokumentiert.
Ach Du grüne Neune schrieb: > robocash schrieb: >> Ich bastle selbst gern. Ich leide aktuell darunter, dass meine Dokumente >> kaum jemand liest. > > Du hast es genau auf den roten Punkt gebracht. Heute wird viel lieber > dokumentiert als produziert, aber damit kann man keine Mark verdienen. > Die Dokumente landen in den Aktenschrank und werden nie wieder > angeschaut. Die Dokumente werden in 10 Jahren angeschaut, wenn der Nachfolger des Entwicklers die Schaltung ändern muss, wiel ein wichtiges Bauteil abgekündigt wurde und es keinen direkten Ersatz gibt. Ach Du grüne Neune schrieb: > Es haben sich auch schon Firmen an DIN ISO 9000, Audit, Zertifikaten, > Arbeitssicherheit und Produktinformationen totdokumentiert. In der Tat Hirnrissig. Man benötigt selbst für das kleinste Maschinchen eine Betriebsanweisung in der alle Sicherheitshinweise Idiotensicher dokumentiert sind. Da gibt es dann die Betriebsanweisung "Bohrmaschine", damit der ausgebildete Facharbeiter bei Bedarf nachlesen kann, dass er EINE Schutzbrille und KEINE Handschuhe zu tragen hat. Dass man den Bohrfutterschlüssel vor dem Einschalten abziehen muss, steht da auch noch... Problem: Hat man keine Betriebsanweisung und es passiert irgendwas, steigt einem die Berufsgenossenschaft aufs Dach...
Schreiber schrieb: > Die Dokumente werden in 10 Jahren angeschaut, wenn der Nachfolger des > Entwicklers die Schaltung ändern muss, wiel ein wichtiges Bauteil > abgekündigt wurde und es keinen direkten Ersatz gibt. Und derjenige stellt dann fest, dass die vorgefundene Dokumentation reichlich wenig mit dem hergestellten Produkt zu tun hat. Aber sie erfüllt sämtliche formalen Anforderungen an Dokumentation, wie sie zehn Jahre zuvor galten. > Problem: Hat man keine Betriebsanweisung und es passiert irgendwas, > steigt einem die Berufsgenossenschaft aufs Dach... Vor ein paar Jahren unterhielt ich mit mit einem Augenoptiker, dessen alte, aber technisch einwandfreie Brillenglasschleifmaschine der BG ein Dorn im Auge war, weil sie noch keine CE-Kennzeichnung aufwies. Er zeigte mir die Maschine sogar, und ich konnte da auch keine sonderliche Gefährdung eines Bedieners erkennen. Seit dem Besuch der BG darf er die Maschine nur noch dann persönlich verwenden, wenn sich kein Angestellter in den Geschäftsräumen befindet.
@ Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) >Dorn im Auge war, weil sie noch keine CE-Kennzeichnung aufwies. Er >zeigte mir die Maschine sogar, und ich konnte da auch keine sonderliche >Gefährdung eines Bedieners erkennen. Seit dem Besuch der BG darf er die >Maschine nur noch dann persönlich verwenden, wenn sich kein Angestellter >in den Geschäftsräumen befindet. Jajaja, der liebe Formalismus. Dann macht halt der Optiker die CE-Erklärung. Denn CE ist nicht gottgegeben. Die Leute WOLLEN verarscht werden. Denn am Ende geht es nur um die Juristerei, sonst gar nichts.
Falk B. schrieb: > @ Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) > >>Dorn im Auge war, weil sie noch keine CE-Kennzeichnung aufwies. Er >>zeigte mir die Maschine sogar, und ich konnte da auch keine sonderliche >>Gefährdung eines Bedieners erkennen. Seit dem Besuch der BG darf er die >>Maschine nur noch dann persönlich verwenden, wenn sich kein Angestellter >>in den Geschäftsräumen befindet. > > Jajaja, der liebe Formalismus. Dann macht halt der Optiker die > CE-Erklärung. Denn CE ist nicht gottgegeben. Die Leute WOLLEN verarscht > werden. Denn am Ende geht es nur um die Juristerei, sonst gar nichts. Und gena für eine derart motivirte Urkundenfälschung ist ein Mitbewerber eingerückt nun ja er hatte wohl noch etwas mehr angestellt. Namaste
Ach Du grüne Neune schrieb: > Es haben sich auch schon Firmen an DIN ISO 9000, Audit, Zertifikaten, > Arbeitssicherheit und Produktinformationen totdokumentiert. Stell ich mir amüsant vor, wenn die Qualitätsabteilung ein zu 20% fertiges Bananenprodukt laut Normen als zu 100% qualitativ hochwertig abstempelt und der Kunde ein entsprechendes DOKUMENT mit wertig wirkendem Logo zu seinem nicht funktionierendem Produkt bekommt.
El Banano schrieb: > Ach Du grüne Neune schrieb: >> Es haben sich auch schon Firmen an DIN ISO 9000, Audit, Zertifikaten, >> Arbeitssicherheit und Produktinformationen totdokumentiert. > > Stell ich mir amüsant vor, wenn die Qualitätsabteilung ein zu 20% > fertiges Bananenprodukt laut Normen als zu 100% qualitativ hochwertig > abstempelt und der Kunde ein entsprechendes DOKUMENT mit wertig > wirkendem Logo zu seinem nicht funktionierendem Produkt bekommt. Es gibt neben den Normen ja auch noch ein Lastenheft (bei Auftragswerk) oder Spec-Sheet (bei generell verkauftem Produkt) welches die Wahrheit über das Produkt beschreiben muss.
Alex G. schrieb: > Es gibt neben den Normen ja auch noch ein Lastenheft (bei Auftragswerk) > oder Spec-Sheet (bei generell verkauftem Produkt) welches die Wahrheit > über das Produkt beschreiben muss. frei nach dem Motto "das Produkt reift beim Kunden" ;-)
Gut, sowas gibts auch. Hängt oft auch mit dem Konkurenzdruck zusammen...
El Banano schrieb: > Stell ich mir amüsant vor, wenn die Qualitätsabteilung ein zu 20% > fertiges Bananenprodukt laut Normen als zu 100% qualitativ hochwertig > abstempelt Die ISO 9000ff hat praktisch nichts mit Entwicklung zu tun und ist auch nicht dafür da, die Qualität von Produkten zu erhöhen.
JoBu schrieb: > - schreibt keine Dokumentation > - hält sich nicht an den Style Guide > - meint nur seine Sicht der Dinge ist richtig > - liest keine internen Dokumente und nervt mit sinnlosen Fragen > > Im Team wird die Stimmung immer schlechter, der Projektleiter ignoriert > die Situation und der disziplinarische Vorgesetzte drückt sich vor der > Verantwortung. > > Habt ihr auch solche Kollegen? Wie geht man damit um? Das ist ganz unterschiedlich und auch immer dem gesellschaftspolitischen Rahmen geschuldet: Vor 500 Jahren hätte man ihn als Hexer/Zauberer der Heiligen Inquisition zuführen können. Vor 80 Jahren konnte man solche Leute beim Blockwart melden. In meiner Jugend gabt es dafür das sozialistische Kollektiv und den SED-Parteisekretär. Heute könnte man ihn entweder ihn als Rechten und/oder Nazi diffamieren - oder wenigstens als Quertreiber, der div. DIN-ISO Zertifizierungen oder Kulturwandel oder Qualitätsmanagement oder wichtige Firmenziele kritisch hinterfragt!
Ach Du grüne Neune schrieb: > Es haben sich auch schon Firmen an DIN ISO 9000, Audit, Zertifikaten, > Arbeitssicherheit und Produktinformationen totdokumentiert. hier: Verwaltung 2 drittel Rest 1 drittel und dieser Rest ist nicht nur Produktion...
El Banano schrieb: > Stell ich mir amüsant vor, wenn die Qualitätsabteilung ein zu 20% > fertiges Bananenprodukt laut Normen als zu 100% qualitativ hochwertig > abstempelt und der Kunde ein entsprechendes DOKUMENT mit wertig > wirkendem Logo zu seinem nicht funktionierendem Produkt bekommt. Ist branchenüblich.
Vril schrieb: > Heute könnte man ihn entweder ihn als Rechten und/oder Nazi diffamieren > - oder wenigstens als Quertreiber, der div. DIN-ISO Zertifizierungen > oder Kulturwandel oder Qualitätsmanagement oder wichtige Firmenziele > kritisch hinterfragt! Wo du einen "Kritischen Hinterfrager" siehst sehe ich einen teamunfähigen Querulanten.
Ach Du grüne Neune schrieb: > Heute wird viel lieber > dokumentiert als produziert, aber damit kann man keine Mark verdienen. Korrekt. Aber im Schadensfall viel gespart. Stichwörter: Stand der Technik, Arbeiten nach bestem Wissen vs. grob Fahrlässig, Qualifikationsmatrix. Je sicherheitsrelevanter das Produkt, desto sinnvoller die Doku. Und gegebenenfalls wird sogar kein "halbfertiges" Produkt verkauft. Stichwörter: Lastenheft, Validierungsplan, Design Review. Schreiber schrieb: > Die Dokumente werden in 10 Jahren angeschaut, wenn der Nachfolger des > Entwicklers die Schaltung ändern muss, wiel ein wichtiges Bauteil > abgekündigt wurde und es keinen direkten Ersatz gibt. Korrekt. Gut ist, wenn dann noch Berechnungen dazu zu finden sind. Andreas S. schrieb: > Und derjenige stellt dann fest, dass die vorgefundene Dokumentation > reichlich wenig mit dem hergestellten Produkt zu tun hat. Dann hat ja wieder der Bastler geschlampt. Bzw. der, welcher die Doku freigibt. Oder es gibt gar keinen Prozess. Genau DAFÜR gibt es Prozesse. Damit Fehler (oder Unwillen) einzelner Personen sich nicht dramatisch auswirken. Jedem passieren Fehler. Unwillige gibt es auch. Alex G. schrieb: > Es gibt neben den Normen ja auch noch ein Lastenheft (bei Auftragswerk) > oder Spec-Sheet (bei generell verkauftem Produkt) welches die Wahrheit > über das Produkt beschreiben muss. "beschreiben sollte" ;) Ansonsten korrekt. Normen sagen in der Tat 0 über die "korrekte" Funktion aus. Das Einhalten von Normen zielt auf rechtliche Sicherheit ab. Nicht auf Funktion.
Knobikocher schrieb: > Andreas S. schrieb: >> Und derjenige stellt dann fest, dass die vorgefundene Dokumentation >> reichlich wenig mit dem hergestellten Produkt zu tun hat. > > Dann hat ja wieder der Bastler geschlampt. Bzw. der, welcher die Doku > freigibt. Oder es gibt gar keinen Prozess. Diese Äußerungen muss man in genau dem Kontext bewerten, in dem sie verfasst wurden: 1. Der Bastler hat irgendwann innerhalb der letzten zehn Jahre das Unternehmen verlassen und ist nicht mehr greifbar. 2. Derjenige, der heute für die Freigabe der Dokumentation zuständig ist, muss nicht identisch sein mit demjenigen, der es vor zehn Jahren war. 3. Möglicherweise wurde "der Bastler" zwischendurch sogar entlassen, nachdem er der Aufforderung, geeignete Dokumentation zu verfassen, nicht nachgekommen war. 4. Möglicherweise gab es vor zehn Jahren einen Freigabeprozess, der nicht funktionierte. Möglicherweise wurde deutlich später ein Freigabeprozess etabliert, der sogar funktioniert. Aus der Nichtexistenz der Dokumentation zu veralteten Produkte auf die aktuellen Prozesse zu schließen, ist fragwürdig. Natürlich bedient man sich gerne solcher Methoden, um gegen sog. Kollegen zu schießen und sie damit zu diskreditieren. 5. Möglicherweise gab es zwischendurch den begründeten Beschluss, den durch "den Bastler" verursachten Mangel an Dokumentation nicht aufzuarbeiten, da der Nutzen in keinem Verhältnis zum Aufwand gestanden hätte. Letztendlich verdeutlicht Knobikocher eben die typisch deutsche Vorgehensweise: es ist völlig egal, wann und mit welchem Aufwand ein Produkt zustandekommt oder eben auch nicht, aber Hauptsache, man kann einen Schuldigen benennen.
Du befürwortest so ein Vorgehen und Ignorieren also? Btw. Deutschland anzurechnen wir hätten ein starkes Bedürfnis danach Verantwortliche zu finden ist etwas weit hergeholt. Wenn man den Kulturkompass und ähnliche Vergleichsgrundlagen betrachtet merkt man dass wir im internationalen Vergleich, verhältnismässig flache Hierarchien haben.
:
Bearbeitet durch User
Alex G. schrieb: > Du befürwortest so ein Vorgehen und Ignorieren also? Nein, aber ich befürworte auch nicht, sich hinter der Bürokratie zu verstecken. Je größer die Organisation ist, desto mehr (virtuelles) Papier wird produziert, das weder mit den realen Kundenanforderungen noch mit der technischen Umsetzbarkeit zu tun hat. Natürlich behaupten alle möglichen Leute, der Kunde wünsche dieses oder jenes, aber wenn man mal nachbohrt, stellt sich sehr schnell heraus, dass dieser Kundenwunsch niemals formuliert wurde. Und deswegen werden eben auch sehr viele Produkte entweder am Markt vorbeientwickelt oder sie kommen erst dann auf den Markt, wenn das Thema längst überholt ist. Oder die häufigste Variante: das Produkt wird in halbfertigem Zustand eingestampft, weil es dann berechtigte Zweifel an einer Markttauglichkeit gibt. Statt jedoch nun zu schauen, wie man die Entscheidungsprozesse drastisch verschlanken kann, wird dann eben einfach noch eine weitere Ebene an Bürokratie draufgepackt. > Btw. Deutschland anzurechnen wir hätten ein starkes Bedürfnis danach > Verantwortliche zu finden ist etwas weit hergeholt. Das sehe ich komplett anders. Ich habe schon etliche Projektanfragen bekommen, bei denen es nur noch darum geht, dass ein paar Entscheidungsträger ihren Kopf aus der Schlinge ziehen und das Scheitern ihrer Projekte an unbeteiligte Dritte "outsourcen" wollen. Oder der Einsatz von Open-Source-Software wird alleine mit der Begründung abgelehnt, dass es dann niemanden gäbe, den man auf Schadensersatz verklagen könne. > Wenn man den > Kolturkompass und Ähnlichen Vergleichsgrundlage nutzt merkt man dass wir > im internationalen vlVergleich, verhältnismässig flache Hierarchien > haben. Natürlich handelt es sich nicht um ein Problem, das nur in Deutschland existiert. Es ist hier aber definitiv so ausgeprägt, dass es sehr viele Erfolge wirkungsvoll verhindert, und zwar auf allen möglichen Entscheidungsebenen. Das ganze hängt auch damit zusammen, dass es hier keine "Kultur des Scheiterns" gibt; mittlerweile findet man allerdings schon die allerersten kleinen Ansätze der Besserung. Es gibt hingegen z.B. in den USA durchaus Unternehmer, die ganz klar sagen, dass sie einige unternehmenskritische Schlüsselpositionen nur mit Leuten besetzen, die schon einmal so richtig auf die Fresse gefallen sind, aber anschließend die Fehlentscheidungen genau analysiert haben. In Deutschland macht man eher Karriere, indem man darauf achtet, sich keinen Fehler nachweisen zu lassen, sondern Dritten in die Schuhe zu schieben. Wer ist Deutschland z.B. ein Startup an die Wand gefahren hat, wird fortan ausgelacht; in den USA wird der nächste Investor hellhörig. Wir erleben es doch auch hier im Mikrocontrollerforum, wie viele Konzernbeamte genau diese Einstellung vertreten. Und um auf das eigentliche Themen zurückzukommen: Der Dokumentationsprozess muss so schlank gehalten werden, dass das dokumentieren kein Hindernis darstellt. Statt irgendwelche telefonbuchstarken Office-Dokumente zu erstellen, die tage-, wochen- oder monatelang von irgendwelchen Instanzen begutachtet werden müssen, sollte viel mehr z.B. auf Wikis gesetzt werden, in die man auch Informationen reinschreibt, die man üblicherweise höchstens für den Eigenbedarf hinkritzelt. Und wenn man irgendetwas aufgebaut und daran herumgelötet hat, wird eben ein Schnappschuss Smartphonekamera angehängt. Wer aber erst einen schriftlichen Antrag für die Beauftragung eines Fotografen stellen muss, hat doch schon verloren. Natürlich kann man solche Informationen nicht in Rohform an Dritte weitergeben. Dafür sucht man sich dann eben Technische Redakteure, die Spaß daran haben, solche formlosen Sammlungen in die für formale Zwecke erforderliche Dokumentation zu überführen. Von jedem "Bastler" zu erwarten, dass er mit Begeisterung selbst die gesamte Dokumentation schreibt statt seine technische Aufgabe zu erfüllen, ist jedoch unsinnig. Mit solchen Vorgaben selektiert man doch nur die Bürokraten.
:
Bearbeitet durch User
> ... DIN ISO 9000
Wir haben hier Spitaeler, die haben ISO 9000, und zeigen das als
Qualitaetsmerkmal herum. Wenn man genauer fragt, betrifft das nur die
Kueche.
Andreas S. schrieb: > Der Dokumentationsprozess muss so schlank gehalten werden, dass das > dokumentieren kein Hindernis darstellt Da bin ich ganz derselben Meinung, Wenn ich etwas entwickle, möchte ich in der Regel sehr schnell dokumentieren können, und es soll Mehrwert bringen. Da möchte schnell ein Bild anfügen, editieren können, synchronisieren, in der Regel in ein schönes Wiki oder zB OneNote, es sollte schnell auffindbar sein und indexierbar. Sicher nicht in ein Word-Dokument. Andreas S. schrieb: > Ich habe schon etliche Projektanfragen bekommen, bei denen es nur noch > darum geht, dass ein paar Entscheidungsträger ihren Kopf aus der > Schlinge ziehen und das Scheitern ihrer Projekte an unbeteiligte Dritte > "outsourcen" wollen Habe ich auch bemerkt. Da wird das Outsourcen sogar zur Strategie! Überrascht sind dann wohl alle, wenn's trotzdem dann mit ner Lösung klappt
klausi schrieb: > Habe ich auch bemerkt. Da wird das Outsourcen sogar zur Strategie! > Überrascht sind dann wohl alle, wenn's trotzdem dann mit ner Lösung > klappt Sowas kommt gar nicht so selten vor, nur wäre dann mal zu überlegen, ob die internen Großkopferten überhaupt noch an diese Stellen gehören? Durch Unfähigkeiten im eigenen Arbeitsprozess "glänzen" aber beim Outsourcen von Problemen die Meister. Am Ende kassieren die dann noch dafür die Lorbeeren!
Vril schrieb: > > Heute könnte man ihn entweder ihn als Rechten und/oder Nazi diffamieren > - oder wenigstens als Quertreiber, der div. DIN-ISO Zertifizierungen > oder Kulturwandel oder Qualitätsmanagement oder wichtige Firmenziele > kritisch hinterfragt! - AGG - Grundgesetz Artikel 1 - § 223 StGB - § 187 StGB - Grundgesetz Artikel 5 - §§ 3, 4 Nr. 10, 8 I UWG
Beitrag #5302673 wurde von einem Moderator gelöscht.
Niemand schrieb: > beim Outsourcen von Problemen die Meister. Die 10 großen "A"der Arbeitsproduktivität Alle Anfallende Arbeit Auf Andere Abschieben Anschließend Anscheißen Aber Anständig Namaste
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.