Ich hab ein Problem.... Wir sind ein kleines IT-Unternehmen (10 MA) und beschäftigen uns hauptsächlich damit, eine Software zu verkaufen und zu implementieren. Die Implementierung ist recht aufwändig und langwierig (typische Projektlaufzeiten zwischen 2 und 18 Monaten) und geht vom Erheben der konkreten Kundenbedürfnisse und Prozesse über Konfiguration der Software bis hin zu kleineren Programmierungen (SQL, Perl, C#). Speziell die Programmierungen sind im Detail nicht umfangreich, in Summe kommt aber schon was zusammen. Erschwert wird das dadurch, dass Kunden dazu tendieren, ihre Meinung zu ändern :-( Am Ende steht dann eine langfristige Betreuung des Kunden (Updates, neue/geänderte Anforderungen etc.) Ich habe vor Jahren zur Dokumentation eine Art "Tagebuch" eingeführt, das Ding sollte eigentlich dauernd offen sein, wenn ich für einen Kunden was mache, und es sollte dokumentiert werden was ich mache, warum ich es mache, welche Probleme es gab, wie diese gelöst wurden, vor welchen Alternativen wir (zusammen mit dem Kunden) standen und für welche wir uns entschieden haben etc. Das hat sich aus meiner Sicht extrem bewährt, weil der gesamte Projektverlauf festgehalten wird, und man auch in "unangenehmen" Situationen immer belastbar nachvollziehen kann warum was wann gemacht wurde (oder eben auch nicht, weil es der Kunde damals so wollte) Speziell wichtig ist das, wenn mal jemand für jemanden anderen einspringen muss: Unsere Leute sind im wesentlichen Generalisten, d.h. jeder Techniker ist in der Lage, ein Projekt zu 80% alleine abzuwickeln, und tut das auch. Wenn der in Urlaub ist kommt es immer wieder zu Fällen "der Kollege X hat vor zwei Wochen y geändert, das funktioniert aber im Fall z nicht" und ein anderer (mit dem Projekt wenig vertrauter) soll das dann möglichst schnell reparieren.... In solchen Fällen ist dieses "Tagebuch" unbezahlbar. Subversion ist zwar auch eine große Hilfe, aber da steht halt nur drinnen was gemacht wurde, aber nicht warum (das "big picture" fehlt). Von einem langfristigen (Krankheit) bis dauerhaften (MA verlässt das Unternehmen) Ausfall red ich jetzt erstmal gar nicht... Soweit, so gut. Mein Problem: einige Mitarbeiter tun das einfach nicht, oder nur extrem unvollständig = unbrauchbar. ich hab schon so ziemlich alle Varianten durch, die ganze Bandbreite von freundlichem Erklären warum wir das machen müssen bis hin zu (sehr unkorrekten) Wutausbrüchen. Kündigungsdrohung ist leider eine leere, weil unsere MA eigentlich einen sehr guten Job machen, und sehr gut wissen dass sie nicht so einfach gekündigt werden können. Ca. alle zwei bis drei Monate schau ich mal über diese Tagebücher, krieg Magengeschwüre, es gibt mal wieder mehr oder weniger ernste Gespräche, dann funktionierts wieder. Genau eine Woche lang :-( Was tut man in einer solchen Situation? ich bin ratlos...
Michael Reinelt schrieb: > Was tut man in einer solchen Situation? ich bin ratlos... Dokumentation als Ziel definieren und einen Teil (die freiwillige Zulage) des Gehaltes davon abhängig machen. Ist bei uns ganz normal.
1. Hintergründe erfragen, warum es nicht gemacht wird? Vll. ist das Logbuch ja technisch schlecht realisiert, so dass ein ergonomischerer Workflow schon etwas bringen kann. 2. Den MA klar machen, dass die Doku zentraler Bestandteil ihrer Aufgabe ist. Also nicht Proggen ist Hauptaufgabe und Doku Nebenspielplatz sondern gleichwertig. 3. Technische Hilfsmittel: Bei jedem Commit etc muss ein Link auf ein Dokuelement gesetzt sein, sondern wird der Commit abgelehnt. Nächtlicher Suchlauf, ob bei jedem Mitarbeiter in der Doku für den jeweiligen Tag etwas eingetragen wurde, sonst gibt es eine Email etc. Workflows einführen. (Programmieren -> Dokumentieren -> Commiten) 4. Dokuerstellung als Ziel definieren und Zielerreichung mit Bonus verknüpfen. 5. Checkliste für Dokumentation (Mindestanforderung).
https://de.wikipedia.org/wiki/5-Why-Methode Wird ja einen Grund haben warum das nicht korrekt gemacht wird. Ohne den zu kennen dokterst du nur an Symptomen herum - den Erfolg beschreibst du ja selbst.
Also, was ich aus deinem Fall herauslese: Jeder wurschtelt vor sich hin, ein Wissensautausch findet zwischen den Mitarbeitern nicht statt. Zusätzlich hast du noch das Problem, dich bei deinen Mitarbeitern durchzusetzen, bzw, weisst nicht, wie man hier etwas ändern könnte. Zuerst würde ich es abstellen, dass einer alleine ein Projekt macht, das sollte schon einen Teil der Probleme lösen. Für die Doku musst du als Chef konkrete Vorgaben machen und diese auch überprüfen. Wie du dann deine Mitarbeiter dzau bringst, dies zu pflegen, da gibt es mehrere Ansätze, du kannst es z.B. über "Management by objectives" sprich Zielvereinbarungen machen. Du kannst auch einen Preis ausloben, für den Besten dokenteur, ... Du musst dir vor allem überlegen, wie du einen Change hinbekommst (Stichwort Change-Management). Sie werden erstmal so weitermachen, wie bisher, wenn du nicht dabei bleibst. Ansonsten für Dokumentation selbst hilft es ein paar Regeln aufzustellen, wie z.B. Commitkommentare aussehen soll. Sowas wie "Have file xy geändert" ist z.B. Quatsch, das kannst du auch aus dem Diff lesen, aber sowas wie "Dieser commit fixt Bug XY, dazu musste Z getan werden, weil ....".
Erstmal danke! Da kommen ja gute Anregungen... J. L. schrieb: > Dokumentation als Ziel definieren und einen Teil (die freiwillige > Zulage) des Gehaltes davon abhängig machen. Ist bei uns ganz normal. Hätt ich mich bisher nicht getraut, klingt aber interessant... Tutorial schrieb: > 1. Hintergründe erfragen, warum es nicht gemacht wird? Vll. ist das > Logbuch ja technisch schlecht realisiert, so dass ein ergonomischerer > Workflow schon etwas bringen kann. Hatten wir alles schon, und wir sind uns alle einig dass die jetzige methode ok ist. > 2. Den MA klar machen, dass die Doku zentraler Bestandteil ihrer Aufgabe > ist. Also nicht Proggen ist Hauptaufgabe und Doku Nebenspielplatz > sondern gleichwertig. Das wird laufend und deutlich kommuniziert. > 3. Technische Hilfsmittel: Bei jedem Commit etc muss ein Link auf ein > Dokuelement gesetzt sein, sondern wird der Commit abgelehnt. Nächtlicher > Suchlauf, ob bei jedem Mitarbeiter in der Doku für den jeweiligen Tag > etwas eingetragen wurde, sonst gibt es eine Email etc. Workflows > einführen. (Programmieren -> Dokumentieren -> Commiten) Oweia... ich bin schon froh, dass wir die Commit-Frequenz entsprechend erhöhen konnten. Früher gab es den "Tages-Commit" um 17:00 :-) > 4. Dokuerstellung als Ziel definieren und Zielerreichung mit Bonus > verknüpfen. Siehe oben, gefällt mir. > 5. Checkliste für Dokumentation (Mindestanforderung). Was meinst du damit? Jan Hansen schrieb: > https://de.wikipedia.org/wiki/5-Why-Methode > > Wird ja einen Grund haben warum das nicht korrekt gemacht wird. Ohne den > zu kennen dokterst du nur an Symptomen herum - den Erfolg beschreibst du > ja selbst. Ja, die 5W werd ich aufgreifen. Obwohl ich den Grund zu kennen glaube: Faulheit. ich krieg aich nie eine zielführende Antwort auf "Warum machst du das nicht?" außer "ja, du hast recht, ich sollte, ich weiss es ist notwenig, ich werde mich zusammenreissen"
Michael Reinelt schrieb: > Kündigungsdrohung ist leider eine leere, weil unsere MA eigentlich einen > sehr guten Job machen, und sehr gut wissen dass sie nicht so einfach > gekündigt werden können. Ich erlebte da auch schon so einiges. Meine eigene Kündigung vor Jahren kann ich wohl auch großteils ausführlichster Dokumentation verdanken, daß man damit dann ganz locker ohne mich zurecht kommt. Zwei Kollegen erlebte ich, wo ich mit der Einarbeitung nicht zurecht kam, und die mich immer nur überall voll auflaufen ließen. Beide in verschiedenen Betrieben unabhängig voneinander sagten, daß sie sich doch nicht unentbehrlich machen wollten. Es wurde also sowohl nach oben als auch nach unten zur Schikane benutzt. Aber nichtsdestotrotz, ich strebe schon aus eigenem Interesse für Dokumentation, weil sie mir selbst hilft. Ich vergesse vieles über die Zeit. Heute führe ich sogar privat Notizbücher, wo ich mir alle Tagesgeschehnisse wie z.B. Telefonate und deren Inhalte und andere Geschehnisse fest halte. Das Ostfriesenbuch mit dem Ostfriesenwitz über den Ostfriesen, daß man ihn nach einem Urlaub wieder neu anlernen muß, darüber lachte ich ja früher, als ich selbst noch überhaupt nie was aufzeichnete. Heute lache ich darüber weniger. Gelernt hatte ich das erst mit 35, als ich einen akribisch genauen jüngeren Kollegen mit 20 hatte, der sich bei jedem Telefonat den Namen des Gesprächspartners und Gesprächsinhalt und Uhrzeit und Datum notierte. Damit nix mehr übel passieren kann.
Sven schrieb: > Also, was ich aus deinem Fall herauslese: > > Jeder wurschtelt vor sich hin, ein Wissensautausch findet zwischen den > Mitarbeitern nicht statt. Nö, da kann ich dich beruhigen: Das funktioniert sehr gut (kommt vielleicht in meiner verkürzten Darstellung nicht so raus) > Zusätzlich hast du noch das Problem, dich bei > deinen Mitarbeitern durchzusetzen, bzw, weisst nicht, wie man hier etwas > ändern könnte. Richtig. > Zuerst würde ich es abstellen, dass einer alleine ein Projekt macht, das > sollte schon einen Teil der Probleme lösen. Das wird sich in absehbarer Zeit leider nicht ändern lassen, dafür sind wir zu klein. Grundsätzlich lassen sich Projekte von einem MA abarbeiten, und das funktioniert auch gut. > Ansonsten für Dokumentation selbst hilft es ein paar Regeln > aufzustellen, wie z.B. Commitkommentare aussehen soll. Sowas wie "Have > file xy geändert" ist z.B. Quatsch, das kannst du auch aus dem Diff > lesen, aber sowas wie "Dieser commit fixt Bug XY, dazu musste Z getan > werden, weil ....". Richtig, aber: siehe oben: Wenigstens wird jetzt einigermaßen regelmäßig commitet (und nicht nur einmal am Tag) was ich aber unvollständig beschrieben habe: nur etwa die Hälfte der typischen Tätigkeit lässt sich committen (der Rest sind Konfigurationen, die sich nicht im svn abbilden lassen)
Michael Reinelt schrieb: > Soweit, so gut. Mein Problem: einige Mitarbeiter tun das > einfach nicht, oder nur extrem unvollständig = unbrauchbar. > > ich hab schon so ziemlich alle Varianten durch, die ganze > Bandbreite von freundlichem Erklären warum wir das machen > müssen bis hin zu (sehr unkorrekten) Wutausbrüchen. Lerne, Deinen Leuten zuzuhören und ihre Beweggründe zu verstehen. Das ist mein voller Ernst; der Ratschlag resultiert aus bitterer eigener Erfahrung. Nicht allen liegt alles gleichermaßen; die Menschen sind keine Automaten. Du kannst entweder den Chef raushängen lassen und Macht demonstrieren; dann bist Du der schlechte Chef eines mäßigen Teams. Oder Du erkennst die individuellen Stärken und Schwächen und steuerst den Projektablauf unauffällig so, dass jeder seine Stärken ausspielen kann. Dann kannst Du u.U. der gute Chef eines unschlagbaren Teams werden.
Manche Menschen können einfach nicht dokumentieren. Das ist ein psychisches Phänomen, ähnlich Prokrastination. Hängt vermutlich sogar damit zusammen. Ich kenne das ganz gut, habe selbst öfters Probleme. Gut zureden, Checklisten, Drohungen, und so weiter hilft da gar nicht. Technische Hilfsmittel helfen auch nur bedingt, da die die Qualität nicht beurteilen können. Die erste Maßnahme wäre also die Wahl der richtigen Personen. Meistens ist es aber so, dass die Leute andere Stärken haben. Wenn nicht dürfte die Kündigung ja wohl nicht schwer fallen. Vorbilder sind wichtig. Wenn der Chef es macht und alle anderen es machen, gewöhnt man sich selbst auch an den Gedanken. Ansonsten hilft nur: Dahinter bleiben. Und nicht davon ausgehen, dass das irgendwann ein Selbstläufer wird. Das heißt im Prinzip: Dauernde Kontrolle. Das darf natürlich nicht auf totale Überwachung hinaus laufen. Idealerweise bildet man Paare oder kleine Teams, bei dem ein "sorgfältiger" Mensch die Dokumentation der anderen kontrolliert. Und dann wird die Dokumentation gemeinsam verbessert. Das heißt nicht einfach sagen: "Das ist Schrott, mach neu", sondern zusammen hin setzen und komplett Punkt für Punkt durchgehen. Das mag erst einmal Zeit kosten, hat aber auch den Vorteil, dass die Qualität höher ist und sich gleich zwei Leute mit dem Thema auskennen. Wenn man Glück hat, kann man phasenweise die Kontrolle reduzieren, man muss aber davon ausgehen, dass es der Mitarbeiter auf die Dauer wieder schleifen lässt, so dass man die Leine dann wieder etwas kürzer halten muss. Alternativ kann man auch einen zentralen "Redakteur" benennen, der die Aufgabe hat, die Dokumentation zu pflegen und sich die notwendigen Informationen bei Bedarf einzuholen. Das muss natürlich jemand sein, dem das richtig Spaß macht und der sorgfältig ist. Je nach Aufwand kann das ein Vollzeitjob sein. Das klingt zwar ineffizient, es wird aber ganz sicher deutlich günstiger sein als seine "schlampigen" Leute zu zwingen, eine Doku zu schreiben. Mit viel Druck werden sie es zwar machen, sind dann aber ineffizient und unmotiviert.
Michael Reinelt schrieb: >> Zuerst würde ich es abstellen, dass einer alleine >> ein Projekt macht, das sollte schon einen Teil der >> Probleme lösen. > Das wird sich in absehbarer Zeit leider nicht ändern > lassen, dafür sind wir zu klein. Grundsätzlich lassen > sich Projekte von einem MA abarbeiten, Dass etwas möglich ist, heißt nicht automatisch, dass es auch optimal ist. > und das funktioniert auch gut. Offenbar ja nicht - wenn die Dokumentation leidet.
Wenn einfach drauflos programmiert wird: Gar nicht. Sonst ist das recht einfach: Die Dokumentation wird zu einem Teil der Aufgabe gemacht. Somit ist sie auch nicht fertig, wenn diese nicht steht. Es gibt aber hierbei eine "Bringschuld". 1. Der Begriff: Dokumentation muss festgelegt werden. Zum Beispiel ob ein Inline-Kommentar, zwei Zeilen am Anfang einer Funktion oder ein 5-seitiger Roman, eine Dokumentation ist. 2. Es gibt keine Ausnahmen. Dies ist in sofern ein Problem, als das sich dadurch das Ende des Jobs verzögert. Also: "Willst Du den Code haben oder soll ich ihn erst noch dokumentieren"... Es gibt auch "Automaten" die anhand von Schlüsselworten eine Art von Dokumentation erstellen. Steht und fällt aber mit Punkt 1 und der konsequenten Verwendung dieser Schlüsselworte. Wenn sich, wie üblich, die Fertigstellung mal wieder verzögert, ist Punkt zwei am schwersten einzuhalten. Hier muss aber gelten: Die Dokumentation hat parallel zur Programmerstellung zu erfolgen, weshalb "fast" alles Dokumentiert sein sollte oder eine faule Ausrede vorliegt.
Einen Anreiz dafür schaffen, und zwar eher einen positiven als einen negativen. Zum Beispiel. Für gute Führung des Tagebuchs gibt es am Jahresende einen Tausender als Extrabonus. Pro Monat ungenügender Führung des Tagebuchs werden davon 200 abgezogen. Das Problem ist wie schaffst du eine objektive von möglichst allen akzeptierte Bewertung was eine "gute Führung des Tagebuchs" ist und was nicht.
Michael Reinelt schrieb: > Obwohl ich den Grund zu kennen glaube: Faulheit. Diese Einschätzung ist für einen Vorgesetzten eine Bankrotterklärung. > ich krieg aich nie eine zielführende Antwort auf > "Warum machst du das nicht?" [...] Natürlich nicht. Glaubst Du, Dein Kollege sagt seinem Chef in's Gesicht: "Ich halte diesen Schwachsinn für völlige Zeitverschwendung?" Lies mal irgendwelche klugen Management-Ratgeber. Da stehen so erhellende Sachen drin wie "Mach das Wichtige sofort und das Unwichtige überhaupt nicht." Wieso ist das, was für die Arbeitsweise des Chefs richtig ist, für die Arbeitsweise des Programmierers nicht richtig? Du sagst, wenn Du über Deine Leute redest: Faulheit. Euer Ober-BWLer würde, wenn er über sich redet, sagen: Effizienz.
>Ca. alle zwei bis drei Monate schau ich mal über diese Tagebücher,
Mach das taeglich. Bis es gut ist, auch wenn's kleinlich erscheint. Wenn
es ein Arbeitsziel ist, muss darauf geachtet werden. Nicht alle paar
monate einmal.
Amateur schrieb: > Die Dokumentation wird zu einem Teil der Aufgabe > gemacht. Du kennst offenbar Tom DeMarco nicht. Seine These: Dokumentation ist kein Teil der Lösung, sie ist Teil des Problems. Damit steht im Zusammenhang: Wer vor dem Codieren einen brauchbaren Feinentwurf macht, muss nach dem Codieren nicht dokumentieren - er hat nämlich schon dokumentiert.
Udo Schmitt schrieb: > Einen Anreiz dafür schaffen, und zwar eher einen positiven als einen > negativen. > Zum Beispiel. Für gute Führung des Tagebuchs gibt es am Jahresende einen > Tausender als Extrabonus. > Pro Monat ungenügender Führung des Tagebuchs werden davon 200 abgezogen. Ja, sowas wäre schon gut. Arbeitsregeln einführen. Bestenfalls findet man auch Normen als Vorschriften, damit man als Chef nicht selbst nur alleine als Buhmann da steht. Auf dem Bau hatte ich auch Vorschriften, eine Anlage und die Verkabelung vorschriftsmäßig zu installieren. Mit einem Spinnengeflecht aus unbefestigten Drähten hätte man die Anlage wohl aber auch zur Funktion bekommen, dann sieht eine Installation mal aus wie in manchen südöstlichen Ländern Telefonleitungen. Man mag es kaum glauben, aber ich hatte da auch deutsche Kollegen, schnell hin und schnell wieder weg, und so sah es dann auch aus.
1.Doku sollte nicht nach Aufwand, sondern eher nach Erfolg honoriert werden. 2.Es nützt das dickste Telefonbuch wenig, wenn nix Gescheites drin steht. Doku muß aus Begeisterung erzeugt werden, weil man sie hinterher selbst gut nutzen kann. 3.Leider nimmt mit der zunehmenden Unsicherheit eines Arbeitsplatzes die Motivation des Mitarbeiters ab, auch Anderen eine Freude zu machen. Warum sollte er für Outsourcing noch den Weg ebenen?
Possetitjel schrieb: > Damit steht im Zusammenhang: Wer vor dem Codieren einen > brauchbaren Feinentwurf macht, muss nach dem Codieren > nicht dokumentieren - er hat nämlich schon dokumentiert. Nur daß bei einem realen Projekt die Dinge im Projektverlauf 10 mal geändert werden una am Ende 80% des Produktes völlig anders ist als am Anfang gedacht. Mit deinen Feinentwürfen hast du noch nicht mal angefangen wo dein Mitbewerber schon eine fertige Lösung hat. Dieses alles durchspezifizieren war ein 80/90er Jahre Ansatz und ist bei Software von der Realität längt überholt.
Michael Reinelt schrieb: > Was tut man in einer solchen Situation? ich bin ratlos... Was mir aus Deiner Schilderung nicht so recht klar wird: Bist Du der Vorgesetzte dieser Mitarbeiter? Wenn ja, dann ist es Dein gutes Recht eine vernünftige Dokumentation zu verlangen. Sie ist schlicht und ergreifend ein Teil des Arbeitsergebnisses, das ein Mitarbeiter zu erbringen hat. Wenn nein, dann solltest Du den Vorgesetzten (also vermutlich den Chef der Firma) davon überzeugen, dass es zum Wohl der Firma ist, wenn nicht jeder einfach vor sich hin wurschtelt und seine Arbeitsergebnisse nur er allein verstehen kann. Ansonsten, was für Dokumente fertigt Ihr überhaupt an? Gibt es bei Euch Anforderungsspezifikationen? Designspezifikationen? Testspezifikationen und -protokolle? Udo Schmitt schrieb: > Nur daß bei einem realen Projekt die Dinge im Projektverlauf 10 mal > geändert werden una am Ende 80% des Produktes völlig anders ist als am > Anfang gedacht. Das hängt entscheidend von der Branche ab. Es gibt Projekte, bei denen zur Unterzeichnung der Verträge Anwälte dabei sind. Da kannst Du Dir sicher sein, dass nicht mal eben im Projekt dauernd was geändert wird. Es gilt das was im Vertrag steht. > Dieses alles durchspezifizieren war ein 80/90er Jahre Ansatz und ist bei > Software von der Realität längt überholt. Das mag ja sein, aber nur "wild programmieren" und nichts schriftlich in Dokumenten festhalten kann ja nun auch nicht die Lösung sein.
:
Bearbeitet durch User
Ein Bewertungssystem einführen und entsprechend mit Zuschlägen und Abzügen vergüten. wöchentlich oder 14tägig: Projekt A bewertet Tagebuch von Projekt B Projekt B bewertet Tagebuch von Projekt C Projekt C bewertet Tagebuch von Projekt A Du kontrollierst die Bewertungen und realisierst die Zuschläge und Abzüge, verantwortlich bleiben jedoch A,B und C.
Michael Reinelt schrieb: > Was tut man in einer solchen Situation? ich bin ratlos... Das mit dem Dokumentieren ist so eine Sache. Ich komme leider auch viel zu selten dazu. Der Hauptgrund ist aber einfach: Mitarbeiter A sagt: Schau mal über XYZ drüber, da geht was nicht! Mitarbeiter B kommt währenddessen: Wie schauts in unserem Hauptprojekt aus, wo bist du da grad? Vorgesetzter: Dokumentier mal bitte das Projekt von letztem Monat fertig. Mitarbeiter C: Hast du ne Idee wegen XYZASDF? Dokumentieren bringt keinen sichtbaren(!) Fortschritt! Viele andere Sachen scheinen eine größere Priorität zu haben, insbesondere wenn die Arbeit von anderen Leuten wieder davon abhängt. Ich hab auch meist viel mehr andere Sachen zu tun die interessanter, wichtiger und dringender sind, als JETZT SOFORT die Doku zu machen. Es ist aber auch einfach eine sehr trockene Angelegenheit. Meiner Meinung nach gibts zwei Hauptgründe: Es ist langweilig und man hat besseres zu tun (oder glaubt, man hätte besseres zu tun!). Du könntest mal versuchen, dass du nem Mitarbeiter sowas sagst wie: Dokumentiere heute nur mal die Sachen vom letzten Projekt fertig, ansonsten machst du nichts anderes (und dies auch mit den anderen Mitarbeitern kommunizieren bzw. sie gleiches machen zu lassen). Doku sieht vermutlich für sie auch nicht so sonderlich wichtig aus, darum würden sie ihren Kollegen dabei einfacher unterbrechen und ablenken.
Udo Schmitt schrieb: > Possetitjel schrieb: [...] > > Dieses alles durchspezifizieren war ein 80/90er Jahre > Ansatz und ist bei Software von der Realität längt > überholt. Wenn Du meinen Text zitierst, wäre es ganz schön, wenn Deine Antwort inhaltlich auch irgend etwas mit meinem Beitrag zu tun hätte.
Udo Schmitt schrieb: > Nur daß bei einem realen Projekt die Dinge im Projektverlauf 10 mal > geändert werden una am Ende 80% des Produktes völlig anders ist als am > Anfang gedacht. Sowas ist schlecht. Projektänderungen in einem Projekt verlängern die Projektdauer auf jeden Fall, im schlimmsten Fall bis hin zum Projektanfang und einem Neubeginn.
Udo Schmitt schrieb: > Possetitjel schrieb: > Damit steht im Zusammenhang: Wer vor dem Codieren einen > brauchbaren Feinentwurf macht, muss nach dem Codieren > nicht dokumentieren - er hat nämlich schon dokumentiert. > > Nur daß bei einem realen Projekt die Dinge im Projektverlauf 10 mal > geändert werden una am Ende 80% des Produktes völlig anders ist als am > Anfang gedacht. > > Mit deinen Feinentwürfen hast du noch nicht mal angefangen wo dein > Mitbewerber schon eine fertige Lösung hat. > > Dieses alles durchspezifizieren war ein 80/90er Jahre Ansatz und ist bei > Software von der Realität längt überholt. Leider wird an den Unis und FHs derxalte Quark immer no ch verbreitet. xP macht das besser, Code als Doku, daxu gehören auch Tests als Doku.
#Include Promille.h schrieb: > Udo Schmitt schrieb: >> Nur daß bei einem realen Projekt die Dinge im Projektverlauf >> 10 mal geändert werden una am Ende 80% des Produktes völlig >> anders ist als am Anfang gedacht. > > Sowas ist schlecht. Das ist zu hart ausgedrückt. Bei Software, die sehr stark in Geschäftsprozesse eingreift, kann die Anforderungserhebung sehr schwierig sein. Dort kann es sehr wohl sein, dass sich erst im Laufe des Projektes herausstellt, wie die optimale Lösung aussieht. Das hat nur überhaupt nichts mit meinem Zielpunkt zu tun: Wenn ich für das, was ich heute codieren will, erstmal einen Entwurf mache und dann den Code in den Rechner tippere, ist der Code automatisch dokumentiert. Wenn ich den Code morgen wegschmeisse, muss ich den Entwurf mit wegschmeissen und einen neuen machen. Kein Konstrukteur stellt sich selbst an die Fräse und fertigt Teile ohne Zeichnung an. Programmierer tun das im übertragenen Sinne ständig.
Kollege schrieb: > xP macht das besser, Extreme Programming fordert, dass man keinen Entwurf machen darf? Das kenne ich aber anders.
Michael Reinelt schrieb: > Ja, die 5W werd ich aufgreifen. Obwohl ich den Grund zu kennen glaube: > Faulheit. ich krieg aich nie eine zielführende Antwort auf "Warum machst > du das nicht?" außer "ja, du hast recht, ich sollte, ich weiss es ist > notwenig, ich werde mich zusammenreissen" Schonmal daran gedacht, das 4-Augen-Prinzip in so fern aufzuweiten, dass einer programmiert und der andere das gleichzeitig dokumentiert? Du verlangst zwei in Ihrer Zusammensetzung völlig unterschiedliche Ergebnisse am Ende des Tages, und das ist bei SW-Entwicklung eben nicht sinnvoll. Ein Entwickler braucht u.U. mal einen Tag zum denken und den nächsten Tag zum Implementieren. Da müsste jetzt noch ein Tag für die Doku dazu. Bei dir soll aber alles am selben Tag passieren und von ein und derselben Person erledigt werden - vielleicht liegt es ja daran? Wenn ich höre, dass einer seinen Leuten Faulheit vorwirft und selber auf anonyme Ratschläge aus dem Internet angewiesen ist, schrillen bei mir die Alarmglocken.
Wow, so viel Resonanz! Noch ein paar Inputs von meiner Seite: Ich bein einer von zwei Inhabern, also ja, ich bin einer der Chefs. Obwohl ich versuche, den nicht "raushängen" zu lassen. In der Praxis mach ich den gleichen Job wie meine Kollegen (wie gesagt, wir sind ein kleiner Laden, Die Häuptlinge arbeiten also auch) Was vielleicht auch falsch verstanden wurde: "Programmieren" macht bei uns nur grob 50% der Projektarbeit aus. Den haben wir auch (nicht zuletzt dank Subversion) ganz gut im Griff. Der Rest ist es, der mir Sorgen macht.
Possetitjel schrieb: > Kein Konstrukteur stellt sich selbst an die Fräse und > fertigt Teile ohne Zeichnung an. Programmierer tun das > im übertragenen Sinne ständig. Ja! Das bringt es auf den Punkt, was wir tagtäglich machen...
Possetitjel schrieb: > Kein Konstrukteur stellt sich selbst an die Fräse und > fertigt Teile ohne Zeichnung an. Programmierer tun das > im übertragenen Sinne ständig. Ich kenne das noch von früher. Wie gesagt, Doku kannte ich lange überhaupt gar nicht. Man machte 1980 mal eine Schaltung aus dem Stehgreif. In der Zeit vor dem PC hätte man auch sehr viel von Hand schreiben müssen. Aber wenn ich heute einen nackten Code ohne Beschreibung irgendwo finde, da bekomme ich die Krise.
Michael Reinelt schrieb: > Ja! Das bringt es auf den Punkt, was wir tagtäglich machen... Nun sag bloß noch, Ihr entwickelt einfach auf Zuruf und ohne schriftlich festgehaltene Anforderungen. :-( Häsch Define schrieb: > Aber wenn ich heute einen nackten Code ohne Beschreibung irgendwo finde, > da bekomme ich die Krise. Zu Recht!
:
Bearbeitet durch User
Meister Eder schrieb: > Wenn ich höre, dass einer seinen Leuten Faulheit vorwirft und selber auf > anonyme Ratschläge aus dem Internet angewiesen ist, schrillen bei mir > die Alarmglocken. Ich nehme das mit der "Faulheit" zurück, und schiebe das auf meine momentane Frustration.
Mark Brandis schrieb: > Michael Reinelt schrieb: >> Ja! Das bringt es auf den Punkt, was wir tagtäglich machen... > > Nun sag bloß noch, Ihr entwickelt einfach auf Zuruf und ohne schriftlich > festgehaltene Anforderungen. :-( Naja, nicht ganz :-) Unsere Herausforderung ist, dass wir Kunden in einen für sie neuen Bereich begleiten, und es dort für den Kunden sehr schwierig ist, vorab genau zu definieren, was sie wollen (weil sie nicht wissen können, was sie wollen) Dass wir dabei extrem flexibel sind, ist Teil unseres Erfolgs.
Michael Reinelt schrieb: > Dass wir dabei extrem flexibel sind, ist Teil unseres Erfolgs. Richtiges Projektmanagement und extrem flexibel widerspricht sich aber wegen laufender Änderungen sehr. Da kann nur so ein halber Mischmasch bei raus kommen.
ein Issue-System wie zB. Jira und ein Repository-System wie SVN. -->Jira mit FishEYE(schnittstelle zu svn). Perfekt kannst du mehrere Issues zb auf einen Bestimmten release als ge fixt markieren und und und... so könntest du dir auch gleich einen automatischen Change-Log generieren ohne zusatz aufwand. Es fallen ganz kleine Lizenskosten an. aber es kann vollumfänglich alles auf eigene Bedürfnisse angepasst werden. unschlagbar. https://www.atlassian.com/de/software/jira
Und Leute, die sehr flexibel denken können, sind oft eben auch schlechte Dokumenteure. Was wieder für die Zweierteam/Redakteurmethode spricht.
#Include Promille.h schrieb: > Michael Reinelt schrieb: >> Dass wir dabei extrem flexibel sind, ist Teil unseres Erfolgs. > > Richtiges Projektmanagement und extrem flexibel widerspricht sich aber > wegen laufender Änderungen sehr. Da kann nur so ein halber Mischmasch > bei raus kommen. Ja. Und dieser Mischmasch muss eben dokumentiert sein. Wobei wir wieder am Anfang angelangt wären...
Antimedial schrieb: > Und Leute, die sehr flexibel denken können, sind oft eben auch schlechte > Dokumenteure. Was wieder für die Zweierteam/Redakteurmethode spricht. Ist sicher richtig. Nur leider momentan bei unserer Größenordnung unrealistisch. Leider!
>Und Leute, die sehr flexibel denken können, sind oft eben auch schlechte >Dokumenteure. Was wieder für die Zweierteam/Redakteurmethode spricht. Das Erste ist eine faule Ausrede. Das Zweite halte ich für Unsinn. Der Programmierer erklärt dem Dokumentierer was er da und da gemacht hat. Der Dokumentierer schreibt das dann auf. Unterbricht dann den Programmieren bei seiner Arbeit, weil noch Klarheiten zu beseitigen sind. In der Zeit hat der Programmierer seinen Erguss auch selbst Dokumentiert.
Michael Reinelt schrieb: [Umsortiert] > In der Praxis mach ich den gleichen Job wie meine > Kollegen Ich sag's mal ganz hart: Das ist der Fehler. Denn... > [...] Der Rest ist es, der mir Sorgen macht. ... Dieser "Rest" ist Dein Job. Programmieren können Deine Leute auch allein - nehme ich zumindest an. Aber den "Rest" können sie nicht allein. > [...] Die Häuptlinge arbeiten also auch Das ist ein ganz böser Spruch. - Ich kenne den Quatsch mit Zitronenfaltern und Projektleitern auch; das ist typischer Blödsinn von Leuten, die nie ein Projekt geleitet haben. Verstehen, was der Kunde will, Verträge machen, die richtigen Leuten auf die richtigen Probleme ansetzen. Komplikationen vorhersehen und Notfallpläne in der Schublade haben - das ist richtig Arbeit. Ich hatte auch Projektverantwortung; ich kenne das also aus eigener Erfahrung.
Lasst ihn, verdammt! er will hilfe zu seinem Problem(1. Post) und versucht nicht mit irgendwelchen abschweifenden Disskusionen ständig die Fragesteller zu beleidigen. schlussendlich ist es sein ding seine Firma und seine art. er reorganisiert doch seine Firma nicht neu wegen euch und will auch nicht hören was er alles falsch und anders machen muss. Lösung für sein Problem heisst in meinen Augen: Jira verwende es selber produktiv in einer Firma. und bin absolut begeistert. läuft alles im browser, also platform unabhängig. Von Designer techniker bis Buchhaltung, gibt keine ausrede diese Tool nicht zu verwenden.
Possetitjel schrieb: > Ich hatte auch Projektverantwortung; ich > kenne das also aus eigener Erfahrung. Im Extremfall möchte ein Kunde aus der Textverarbeitung Word das Spiel DOOM3 gemacht haben. Das klingt jetzt kindisch und stark übertrieben, aber so ähnlich läuft es ja manchmal.
Michael Reinelt schrieb: > Ist sicher richtig. Nur leider momentan bei unserer Größenordnung > unrealistisch. Leider! Mit der Größe hat das jedenfalls nichts zu tun, sondern eher mit der Organisationsstruktur. Man kann auch mit zwei Personen so arbeiten. Die Organisation kann man ändern, es erfordert nur etwas Mut. Die Gesamteffizienz steigt aber auf jeden Fall. Amateur schrieb: > Das Erste ist eine faule Ausrede. Nein, es ist die Realität. Menschen haben gewisse Neigungen. Natürlich gibt es auch die flexiblen, die trotzdem eine 1A-Dokumentation abliefern. Amateur schrieb: > Das Zweite halte ich für Unsinn. Der Programmierer erklärt dem > Dokumentierer was er da und da gemacht hat. Der Dokumentierer schreibt > das dann auf. Unterbricht dann den Programmieren bei seiner Arbeit, weil > noch Klarheiten zu beseitigen sind. > In der Zeit hat der Programmierer seinen Erguss auch selbst > Dokumentiert. Natürlich kann man die Leute zum dokumentieren zwingen, aber der deutlich einfachere Weg ist, seine vorhandenen Ressourcen richtig einzusetzen. Und es ist definitiv nicht effizient, wenn man Leute, die nicht dokumentieren können, dazu zu zwingen. Die Vorteile meines Ansatzes hast du noch nicht erkannt. Erstens einmal bekommt man so eine Dokumentation mit gleichbleibender Qualität. Das bekommt man durch Zwang niemals hin. Eine der Hauptaufgaben des Redakteurs ist es, den Mitarbeitern ein Gefühl für gute Dokumentation beizubringen. Wenn es gut läuft muss er nach einiger Zeit gar nicht mehr nachfragen, die Leute wissen, wie sie ihren Beitrag zu leisten haben. Er kennt sich außerdem auch mit allen Projekten aus und kann deshalb bei einfacheren Fragen unterstützen, wenn z.B. der Hauptentwickler krank ist. Das Hauptargument ist und bleibt aber die gesteigerte Effizienz.
#Include Promille.h schrieb: >> Dass wir dabei extrem flexibel sind, ist Teil unseres >> Erfolgs. > > Richtiges Projektmanagement und extrem flexibel > widerspricht sich aber wegen laufender Änderungen sehr. Nicht notwendig. Die agilen Methoden sind entwickelt worden, um gerade diesen Widerspruch zu lösen. > Da kann nur so ein halber Mischmasch bei raus kommen. Der kommt meistens raus. Der Unterschied ist: Die einen leugnen es, die anderen stehen dazu :)
Michael Reinelt schrieb: > Meister Eder schrieb: >> Wenn ich höre, dass einer seinen Leuten Faulheit vorwirft und selber auf >> anonyme Ratschläge aus dem Internet angewiesen ist, schrillen bei mir >> die Alarmglocken. > > Ich nehme das mit der "Faulheit" zurück, und schiebe das auf meine > momentane Frustration. Da bin ich ja froh, also nicht weil du frustriert bist sondern dass du noch differenzieren kannst. Versuch doch mal, in Gedanken, dein Team in 2er-Gruppen aufzuteilen und überlege dir, welche Paarungen sich gut ergänzen. z.B. Wer kann vom anderen noch was lernen? Wer arbeitet unter Umständen befreiter und effektiver, wenn er einen "alten Hasen" an seiner Seite hat? Ich glaube du merkst worauf ich hinaus will. Du hast ja ein konkretes Ziel, wo du hin willst. Mit den bisherigen Maßnahmen wurde es nicht erreicht, obwohl du eingeräumt hast, dass ihr eigentlich ganz gute Leute habt. Also musst du, der Chef, was ändern und auch etwas investieren. Wenn du 2er Teams hast, wo einer den Part der Dokumentation zu 100% verantworten muss, heisst das ja nicht zwangsläufig, dass nur noch 50% effektiv gearbeitet wird. Trotzdem verringert sich der "Wirkungsgrad" deiner Mannschaft, das ist klar. Aber diesem Verlust steht ja der Gewinn der vollen Dokumentation aller Arbeitsschritte und alle damit verbundenen Möglichkeiten der Optimierung gegenüber. Wenn deine Einzelkämpfer zu 100% ausgelastet sind, musst du entweder mehr Leute einstellen oder mit längeren Projektzeiten rechnen. Aber wie heisst es immer: von Nix kommt Nix.
:
Bearbeitet durch User
Meister Eder schrieb: > Trotzdem verringert sich der "Wirkungsgrad" > deiner Mannschaft, das ist klar. Doku braucht Zeit. Es sagte mir mal einer schon als Jugendlichem, es gäbe drei Grundregeln auf der Welt. Eine davon: In keiner Zeit geschieht nichts. Der Administrationsaufwand in manchen Unternehmen beläuft sich schon bis zu 80% der Nebentätigkeiten. Dann kommt da wieder einer gelaufen, der sich beklagt: Entwickeln und machen die hier eigentlich nichts mehr?
> Da bin ich ja froh, also nicht weil du frustriert bist sondern dass du > noch differenzieren kannst. Danke :-) > Versuch doch mal, in Gedanken, dein Team in 2er-Gruppen aufzuteilen und > überlege dir, welche Paarungen sich gut ergänzen. z.B. Wer kann vom > anderen noch was lernen? Wer arbeitet unter Umständen befreiter und > effektiver, wenn er einen "alten Hasen" an seiner Seite hat? Ich glaube > du merkst worauf ich hinaus will. Diese Zweierteams haben wir t.w. eh, aber aus anderen Gründen: ein "alter Hase" kriegt einen neuen MA zur Seite gestellt, um den auszubilden und in die Praxis einzuführen. Dem neuen kann man aber die Doku schwer umhängen, der ist schon bedient genug zu verstehen was da gerade abgeht :-) > Du hast ja ein konkretes Ziel, wo du hin willst. Mit den bisherigen > Maßnahmen wurde es nicht erreicht, obwohl du ja selber sagst, dass ihr > gute Leute habt. Also musst du, der Chef, was ändern und auch etwas > investieren. > Wenn du 2er Teams hast, wo einer den Part der Dokumentation zu 100% > verantworten muss, heisst das ja nicht zwangsläufig, dass nur noch 50% > effektiv gearbeitet wird. Trotzdem verringert sich der "Wirkungsgrad" > deiner Mannschaft, das ist klar. Aber diesem Verlust steht ja der Gewinn > der vollen Dokumentation aller Arbeitsschritte und alle damit > verbundenen Möglichkeiten der Optimierung gegenüber. Wenn deine > Einzelkämpfer zu 100% ausgelastet sind, musst du entweder mehr Leute > einstellen oder mit längeren Projektzeiten rechnen. Aber wie heisst es > immer: von Nix kommt Nix. Das weiss ich. Zweierteams wirds leider kurz- und mittelfristig nicht spielen, dazu sind wir zu wenige, und haben (gottseidank) zu viele Aufträge. (Ausnahme: neue Mitarbeiter als "Beiwagerl"). ich persönlich empfinde die Doku (das "Tagebuch") auch überhaupt nicht als Belastung, ganz im Gegenteil (und nochmal, ich mach im wesentlichen den gleichen Job wie meine Kollegen). Aber ich hab auch kein Problem damit, wenn die Kollegen dann nur mehr 90% Leistung bringen, weil 10% fürs Tagebuch draufgehen (das kann man dann ja optimieren). Aber dass das Tagebuch fast schon konsequent nicht geführt wird, obwohl es eine sehr klare Anweisung der Führung gibt, damit kann ich nicht umgehen.
Michael Reinelt schrieb: > Das weiss ich. Zweierteams wirds leider kurz- und mittelfristig nicht > spielen, dazu sind wir zu wenige, und haben (gottseidank) zu viele > Aufträge. (Ausnahme: neue Mitarbeiter als "Beiwagerl"). Du gehst irrtümlich davon aus, dass Zweierteams automatisch "weniger Effizienz" bedeutet. Richtig umgesetzt ist es umgekehrt. Aber gut, es ist dein Laden. Michael Reinelt schrieb: > ich persönlich empfinde die Doku (das "Tagebuch") auch überhaupt nicht > als Belastung, ganz im Gegenteil (und nochmal, ich mach im wesentlichen > den gleichen Job wie meine Kollegen) Michael Reinelt schrieb: > Aber dass das Tagebuch fast schon konsequent nicht geführt wird, > obwohl es eine sehr klare Anweisung der Führung gibt, damit kann ich > nicht umgehen. Da liegt das Problem: Du verstehst nicht, dass es für deine Kollegen sehr wohl eine Belastung ist. Menschen sind eben keine Maschinen und manche Leute empfinden eben auch etwas als Belastung, was völlig objektiv betrachtet keine ist. Eigne dir vielleicht ein paar Psychologie-Kenntnisse an, das könnte dir helfen, deine Mitarbeiter zu verstehen.
Antimedial schrieb: > Nein, es ist die Realität. Menschen haben gewisse Neigungen. Natürlich > gibt es auch die flexiblen, die trotzdem eine 1A-Dokumentation > abliefern. "Gewisse Neigungen" bedeutet aber nicht, dass man im Berufsleben nur die angenehmen Dinge machen kann und die lästigen Arbeiten stets auf jemand anderen abschiebt. So funktioniert Arbeit gegen Geld nun mal nicht. > Amateur schrieb: > Natürlich kann man die Leute zum dokumentieren zwingen, aber der > deutlich einfachere Weg ist, seine vorhandenen Ressourcen richtig > einzusetzen. Und es ist definitiv nicht effizient, wenn man Leute, die > nicht dokumentieren können, dazu zu zwingen. "Nicht dokumentieren können" ist keine unheilbare Krankheit. Man kann Leute darin schulen, wie es richtig geht. Mir ist schon klar, dass der Aspekt Schulung in vielen Firmen zu kurz kommt. Erlebe es bei meinem Arbeitgeber ja selbst so. Aber ein unabänderlicher Zustand ist das nicht.
:
Bearbeitet durch User
Michael Reinelt schrieb: > Ich habe vor Jahren zur Dokumentation eine Art "Tagebuch" eingeführt, > das Ding sollte eigentlich dauernd offen sein, wenn ich für einen Kunden > was mache, und es sollte dokumentiert werden was ich mache, warum ich es > mache, welche Probleme es gab, wie diese gelöst wurden, vor welchen > Alternativen wir (zusammen mit dem Kunden) standen und für welche wir > uns entschieden haben etc. Das hat sich aus meiner Sicht extrem bewährt, Letztendlich muß sich dann die Person aber genauso durch die massige Aufzeichnungen erstmal durchkämpfen. Ich glaube, Du siehst das Problem nur noch aus einer speziellen Brille. Wenn Du mit spontan mit so einer Idee wie so einem Tagebuch kommen würdest, könnte ich nur den Kopf schütteln. Wenn ich mal unsere Mitmenschen halbwegs richtig einschätze, würdest Du mindestens doppelt soviele Mitarbeiter benötigen, die aber dann auch doppelt solange für die wirkliche Arbeit benötigen. > Speziell wichtig ist das, wenn mal jemand für jemanden anderen > einspringen muss: Unsere Leute sind im wesentlichen Generalisten, d.h. > jeder Techniker ist in der Lage, ein Projekt zu 80% alleine abzuwickeln, > und tut das auch. Wenn der in Urlaub ist kommt es immer wieder zu Fällen > "der Kollege X hat vor zwei Wochen y geändert, das funktioniert aber im > Fall z nicht" und ein anderer (mit dem Projekt wenig vertrauter) soll > das dann möglichst schnell reparieren.... In solchen Fällen ist dieses > "Tagebuch" unbezahlbar. Das ist doch immer so, wo ist jetzt das Problem? Der Urlaub? > Ca. alle zwei bis drei Monate schau ich mal über diese Tagebücher, krieg > Magengeschwüre, es gibt mal wieder mehr oder weniger ernste Gespräche, > dann funktionierts wieder. Genau eine Woche lang :-( Ich habe schon einige Jahre in einem streng reguliertem Umfeld mit umfassenden Dokumentationspflichten gearbeitet. Du kannst Dir wohl gerade nicht wirklich vorstellen was Du da anrichten wirst.
Mark Brandis schrieb: > "Gewisse Neigungen" bedeutet aber nicht, dass man im Berufsleben nur die > angenehmen Dinge machen kann und die lästigen Arbeiten stets auf jemand > anderen abschiebt. So funktioniert Arbeit gegen Geld nun mal nicht. Ich würde dir Recht geben bei Aufgaben, die jeder als unangenehm empfindet. Es ist aber so, dass es Leute gibt, denen dokumentieren durchaus Spaß macht. Wieso also nicht diese Leute diese Aufgaben geben? Idealerweise stellt man sein Team so auf, dass jeder größtenteils angenehme Arbeiten macht. Zu 100% funktioniert das nie, aber wenn man da nahe ran kommt, erreicht man die bestmögliche Motivation. Mark Brandis schrieb: > "Nicht dokumentieren können" ist keine unheilbare Krankheit. Man kann > Leute darin schulen, wie es richtig geht. Vielleicht nicht unheilbar, aber es ist nicht verkehrt, das wie eine langwierige Krankheit zu betrachten. Dann ist nämlich klar, dass es kein Allheilmittel gibt, sondern eine längere Therapie notwendig ist. Ebenso ist klar, dass es unterschiedliche Schweregrade gibt. Bei wenigen Leuten reicht eine einzelne Ermahnung, bei anderen ist es aber sehr hartnäckig. Man kann Leute darin schulen, allerdings ist das nicht mit einer Tagesschulung getan, sondern erfordert mitunter langfristiges Engagement über mehrere Monate oder gar Jahre.
Mark Brandis schrieb: > "Nicht dokumentieren können" ist keine unheilbare Krankheit. Man kann > Leute darin schulen, wie es richtig geht. Es ist die selbe Krankheit, wie ein Draufloscodierer auch Flußdiagramme und Struktogramme wie eine Pest scheut.
Klaus I. schrieb: > Letztendlich muß sich dann die Person aber genauso durch die massige > Aufzeichnungen erstmal durchkämpfen. Ja, richtig, aber wenn ich ein konkretes sehr ernstes Problem habe, dann bin ich froh wenn ich irgendwas habe durch das ich mich durchkämpfen muss, als gar nix! (hat dich schon mal ein Kunde angerufen und gebrüllt "unsere Beschaffung steht! Lösen Sie das in den nächsten 30 Minuten, oder sie können was erleben!") > Ich glaube, Du siehst das Problem > nur noch aus einer speziellen Brille. > Wenn Du mit spontan mit so einer Idee wie so einem Tagebuch kommen > würdest, könnte ich nur den Kopf schütteln. Wenn ich mal unsere > Mitmenschen halbwegs richtig einschätze, würdest Du mindestens doppelt > soviele Mitarbeiter benötigen, die aber dann auch doppelt solange für > die wirkliche Arbeit benötigen. Sprichst du aus der Praxis? ich glaube nicht....
Michael Reinelt schrieb: > Diese Zweierteams haben wir t.w. eh, aber aus anderen Gründen: ein > "alter Hase" kriegt einen neuen MA zur Seite gestellt, um den > auszubilden und in die Praxis einzuführen. Dem neuen kann man aber die > Doku schwer umhängen, der ist schon bedient genug zu verstehen was da > gerade abgeht :-) Dafür hat er den alten Hasen, den kann er doch fragen (beim jour fix und nicht wann es ihm einfällt). Ich merke bei mir selbst, dass ich Vorgänge meiner täglichen Arbeit manchmal gar nicht so schnell beschreiben könnte wie ich sie umsetze. Klingt komisch, ist aber so ;) Versuch es so zu sehen: Der Neuling bringt dem alten Hasen wieder bei, für ihn einfache Zusammenhänge so zu formulieren, dass sie ein Einsteiger verstehen kann. Der Rest ist dann ein Selbstläufer. > Das weiss ich. Zweierteams wirds leider kurz- und mittelfristig nicht > spielen, dazu sind wir zu wenige, und haben (gottseidank) zu viele > Aufträge. (Ausnahme: neue Mitarbeiter als "Beiwagerl"). Schade, denn die "Beiwagerl" (super Begriff übrigens) fahren dann beladen mit ein paar Fetzen Know-How auf den nächsten Parkplatz statt sich bei euch weiter zu entwickeln, da geht mehr verloren als zu gewinnen ist. Die 2er Teams machen nur Sinn, wenn der Mehrwert (kommunikationsfreudigere Spezialisten und besser angelernte neue Kräfte) danach in der Firma bleibt. > ich persönlich empfinde die Doku (das "Tagebuch") auch überhaupt nicht > als Belastung, ganz im Gegenteil (und nochmal, ich mach im wesentlichen > den gleichen Job wie meine Kollegen). Aber ich hab auch kein Problem > damit, wenn die Kollegen dann nur mehr 90% Leistung bringen, weil 10% > fürs Tagebuch draufgehen (das kann man dann ja optimieren). Um das beurteilen zu können, müsste ich das mit eigenen Augen sehen. Ich nehme es mal so. > Aber dass das Tagebuch fast schon konsequent nicht geführt wird, > obwohl es eine sehr klare Anweisung der Führung gibt, damit kann ich > nicht umgehen. Das verstehe ich, du brauchst eine Lösung.
Michael Reinelt schrieb: > hat dich schon mal ein Kunde angerufen und gebrüllt > "unsere Beschaffung steht! Lösen Sie das in den nächsten 30 Minuten, > oder sie können was erleben! Ich erlebte einmal einen, bei dem in 20 Jahren die Anlage nur 3 Minuten ausgefallen war. Das war aber Teil unserer Arbeit, und abgesprochen. Dann kam im Umschaltemoment ein richtiger Tyrann raus auf die Straße gerannt, und brüllte, Hilfe, Überfall, Polizei Polizei, ich habe gerade durch Ausfall 10 Millionen verloren! Mein Kollege sagte nur, komm schnell weg in die Büsche, dieses Arschloch ist gefährlich!
Michael Reinelt schrieb: > ich persönlich empfinde die Doku (das "Tagebuch") auch > überhaupt nicht als Belastung, ganz im Gegenteil (und > nochmal, ich mach im wesentlichen den gleichen Job wie > meine Kollegen). Auch auf die Gefahr hin, mich zu wiederholen: Das ist ein Fehler. Kümmere Dich als Häuptling um die Häuptlingsthemen und lass' den Indianern die Indianerthemen. > [...] > Aber dass das Tagebuch fast schon konsequent nicht geführt > wird, obwohl es eine sehr klare Anweisung der Führung gibt, > damit kann ich nicht umgehen. Ich verstehe das sehr gut. Dennoch mein Rat: Versuche, von der persönlichen Kränkung wegzukommen und Deine Leute zu verstehen - wirklich zu verstehen. Das Beharren darauf, dass es Dein Recht ist, dies zu verlangen, hilft Dir nicht weiter. Hmm... ich zögere... hmm. Na gut: Lies Tom DeMarco.
Antimedial schrieb: > Ich würde dir Recht geben bei Aufgaben, die jeder als unangenehm > empfindet. Es ist aber so, dass es Leute gibt, denen dokumentieren > durchaus Spaß macht. Wieso also nicht diese Leute diese Aufgaben geben? Weil Person B nicht das dokumentieren kann, was bei Person A im Kopf ist. Dazu müsste B Gedanken lesen können. Haut nicht hin.
#Include Promille.h schrieb: > Es ist die selbe Krankheit, wie ein Draufloscodierer auch Flußdiagramme > und Struktogramme wie eine Pest scheut. Also doch 80er Jahre Stil :-) Structogramme und Flussdiagramme sind sinnvoll bei einfachen Ablaufsteuerungen und Projekten im Umfang von einer Mannwoche. Vieleicht solltest du dich mal mit uml, use cases, test driven development, extrem programming, scrum etc. beschäftigen. Es hat schon seinen Grund, daß z.B. Software von Großkonzernen oft noch aussieht, als stämme sie noch aus der Win3.11 Zeit. Da werden 400 Seiten Feinkonzept entwickelt und dann bleiben noch 15 Tage für die Implementierung. Und das Feinkonzept hat über 100 strukturelle Fehler, weil 5 Leute dran geschrieben haben und keiner die Ideen der anderen vier richtig verstanden hat. Alles schon gesehen. Im Endeffekt bläht dieser Versuch alles vorher schon wissen und bedenken zu wollen die Entwicklung um bis zu Faktor 5 gegenüber einem rundenbasierten System auf. Zumindest bei komplexeren Projekten. Auch 4 Augen Programmieren kann äusserst effektiv sein. Wer kennt das nicht man kommt nicht richtig weiter und holt mal einen Kollegen dazu mit dem man das Problem am Monitor durchspricht und gleich mal ein Stück implementiert. Oft hat man in 2 Stunden dann zu zweit das geschafft was man alleine in einem Tag nicht hingekriegt hätte. Allerdings muss man mit dem Kollegen auf einer Wellenlänge liegen. Und den ganzen Tag wäre mir das zu stressig, weil man nie mal 5min abschalten oder auch nur ruhig nachdenken kann.
@ Udo Schmitt (urschmitt) >Es hat schon seinen Grund, daß z.B. Software von Großkonzernen oft noch >aussieht, als stämme sie noch aus der Win3.11 Zeit. ;-) >Da werden 400 Seiten Feinkonzept entwickelt und dann bleiben noch 15 >Tage für die Implementierung. :-0 >Und das Feinkonzept hat über 100 strukturelle Fehler, weil 5 Leute dran >geschrieben haben und keiner die Ideen der anderen vier richtig >verstanden hat. >Alles schon gesehen. :-( >Im Endeffekt bläht dieser Versuch alles vorher schon wissen und bedenken >zu wollen die Entwicklung um bis zu Faktor 5 gegenüber einem >rundenbasierten System auf. Zumindest bei komplexeren Projekten. Mag sein, aber es ist kein Freifahrtschein für "Freestyle Hacking". Je größer das Projekt, umso strukturierter muss man vorgehen. Und dazu gehört auch Dokumentation. In welcher Art und nach welchem System ist eine andere Frage. >implementiert. Oft hat man in 2 Stunden dann zu zweit das geschafft was >man alleine in einem Tag nicht hingekriegt hätte. Allerdings muss man >mit dem Kollegen auf einer Wellenlänge liegen. Stimmt. Allein schon das Erklären des Problem einer anderen Person gegenüber bringt einen oft viel weiter, weil man plötzlich seine Betriebsblindheit sieht 8-0
Udo Schmitt schrieb: > Structogramme und Flussdiagramme sind sinnvoll bei einfachen > Ablaufsteuerungen und Projekten im Umfang von einer Mannwoche. Das, was man an einem Tag implementieren kann, hat relativ selten einen Umfang von mehr als einer Mannwoche. Achtung, mein Text könnte Sarkasmus oder Ironie enthalten. > Vieleicht solltest du dich mal mit uml, use cases, test driven > development, extrem programming, scrum etc. beschäftigen. Soweit mir bekannt ist, verbietet es keine der agilen Methoden, vor dem Implementieren den Kopf einzuschalten und nachzudenken. Wenn man das tut, kann man einige Kernpunkte dieses Denkens auch festhalten. Das käme einem Feinentwurf schon recht nahe. Und es hat obendrein den Vorteil, dass man sich nicht hinterher hinsetzen und Dokumentation schreiben muss. > [...] > Da werden 400 Seiten Feinkonzept entwickelt [...] Man kann jede beliebige Methode durch Übertreibung ruinieren, sowohl das Wasserfallmodell wie auch diverse agile Methoden. Das hat aber weniger mit der Methode, sondern mehr mit der Übertreibung zu tun.
Falk Brunner schrieb: >>Im Endeffekt bläht dieser Versuch alles vorher schon wissen >>und bedenken zu wollen die Entwicklung um bis zu Faktor 5 >>gegenüber einem rundenbasierten System auf. [...] > > Mag sein, aber es ist kein Freifahrtschein für "Freestyle > Hacking". Je größer das Projekt, umso strukturierter muss > man vorgehen. Da ist eigentlich kein Widerspruch. Rundenbasiertes System ist ja strukturiertes Vorgehen. Wie ein bestimmter Programmierer den Teil, der in der aktuellen Runde auf seinem Tisch liegt, im Detail bearbeitet, sollte ihm weitgehend selbst überlassen sein. Ob das nun "pair programming", "Freestyle Hacking" oder V-Modell ist, ist im Prinzip seine Sache. Das hängt von vielen Dingen ab. > Und dazu gehört auch Dokumentation. Ja, unbedingt. > In welcher Art und nach welchem System ist eine andere Frage. Dokumentation, die tatsächlich benötigt wird, muss gemacht werden. Dokumentation, die nicht benötigt wird, ist Verschwendung und daher zu unterlassen. Die Kunst liegt darin, festzustellen, was wirklich benötigt wird ;-)
Ich habe einen radikal anderen Vorschlag für die Auswahl von teams: Man sollte von Zeit zu Zeit für eine begrenzte Zeit gleiche Typen miteinander arbeiten lassen. Die Wahrscheinlichkeit, dass sich zwei "Nichtdokumentierer" auf die Nerven gehen ist nicht gering. Eben weil wahrscheinlich eine Situation entsteht, in der eine Dokumentation hilfreich wäre. Bei solch einer Aktion muss aber der Zügel kurz gehalten werden. Wenn Du als Häuptling weiter Indianerarbeit machst, dann bitte erst wenn der Chefjob getan ist und deine Mitarbeiter das auch mitbekommen, vorher nicht. Auf keinen Fall. Nie niemals nicht.
Michael Reinelt schrieb: > . Zweierteams wirds leider kurz- und mittelfristig nicht > spielen, dazu sind wir zu wenige, und haben (gottseidank) zu viele > Aufträge. Es stellt sich die Frage ob nicht irgendwo eine Überlastung vorliegt. Deswegen folgende Fragen: - Wie viel Zeit pro Tag sollte Deiner Meinung nach für die Doku verwendet werden - Wie viel Zeit pro Tag brauchen Deine Mitarbeiter Ihrer Meinung nach dazu um es ordentlich zu machen? - Steht diese Zeit zur Verfügung Um das Zeitproblem zu lösen, kannst Du ja sagen 16:30 final commit des Tages, danach 30 Minuten Doku (falls das Deiner Meinung und der Deiner Mitarbeiter reicht) Wenn Du sagst, nenene geht so nicht, zuviele Aufträge, dann weißt Du warum es die Doku nicht gibt Zweites (mögliches) Problem: Versteht jeder, was Du gerne hättest? Hast Du das nur zwischen Tür und Angel gemacht oder einen (halben) Schulungstag mit Handout? Wenn nicht : mach es
Finanzielle Anreize bieten oder jemanden einstellen/beauftragen der die Dokumentation zu seiner Hauptaufgabe macht. Als eigenständige Abteilung, z.B. Qualitätsmanagement könnte das funzen.
Logger schrieb: > oder jemanden einstellen/beauftragen Die wesentlichen Kleinigkeiten sollte schon DER dokumentieren, der sich damit auskennt. Von Dritten kann man nicht verlangen, daß sie den vollständigen Überblick haben. Dann stimmt evtl. nur Form und Rechtschreibung.
oszi40 schrieb: > Die wesentlichen Kleinigkeiten sollte schon DER dokumentieren, der sich > damit auskennt. Von Dritten kann man nicht verlangen, daß sie den > vollständigen Überblick haben. Dann stimmt evtl. nur Form und > Rechtschreibung. Genau, und so eine Doku nützt dann auch nichts.
Mark Brandis schrieb: > Weil Person B nicht das dokumentieren kann, was bei Person A im Kopf > ist. Dazu müsste B Gedanken lesen können. Haut nicht hin. Natürlich haut das hin, wenn zwei Leute als Team zusammen arbeiten. Neudeutsch auch "pair programming" genannt. Ob der eine jetzt mehr dokumentiert und weniger programmiert spielt dabei keine große Rolle. Wenn sich die beiden Leute gut ergänzen, ist das Ergebnis mehr als zwei Mal der Einzelleistung. Weit mehr. Ich arbeite seit etwa drei Jahren in einem ähnlichen Modus. Dabei geht es zwar weniger um Software, außerdem besteht das Team aktuell aus vier Leuten. Aber die Arbeitsweise ist vergleichbar. Das ist wirklich extrem effektiv und die Produktivität steigt enorm. Der riesige Vorteil ist, dass im Normalbetrieb jeder seine Stärken voll ausspielen kann, im "Notfall" (Urlaub, Krankheit, temporär andere Aufgaben, etc...) aber jeder jeden ersetzen kann. Bei einem anderen Zweierteam ist es tatsächlich so, dass der eine der kreative Entwickler ist, der die technischen Probleme löst, während der andere den ganzen Kram dokumentiert und das Requirement Engineering beisammen hält. Die Aufgabenteilung ist natürlich nicht ganz scharf, der Entwickler schreibt auch mal ein Dokument, während der "Dokumenteur" auch teilweise Hardware entwickelt, Messungen durchführt und so weiter. Das funktioniert wunderbar, weil sich die Charaktere ergänzen. Die einzige Voraussetzung ist, dass man menschlich sehr gut miteinander auskommt und die Leute aktiv Wissen teilen wollen. Einzelgänger und Geheimniskrämer kann man dabei nicht gebrauchen. Leider gibt es das unter Ingenieuren viel zu oft und wir manchmal sogar als Tugend angesehen.
Antimedial schrieb: > Natürlich haut das hin, wenn zwei Leute als Team zusammen arbeiten. > Neudeutsch auch "pair programming" genannt. Ob der eine jetzt mehr > dokumentiert und weniger programmiert spielt dabei keine große Rolle. > Wenn sich die beiden Leute gut ergänzen, ist das Ergebnis mehr als zwei > Mal der Einzelleistung. Weit mehr. > > Ich arbeite seit etwa drei Jahren in einem ähnlichen Modus. Dabei geht > es zwar weniger um Software, außerdem besteht das Team aktuell aus vier > Leuten. Aber die Arbeitsweise ist vergleichbar. Klingt ja alles gut. Gegenfrage: Wie groß ist die Firma, bei der Du angestellt bist? Ich könnte mir vorstellen, dass es bei Euch wesentlich mehr Entwickler gibt als die 10 - 2 = 8 Mann, die in der Firma des Themenerstellers in dieser Position arbeiten.
Michael Reinelt schrieb: > Was tut man in einer solchen Situation? ich bin ratlos... Ein Tagebuch halte ich für wenig sinnvoll. Zusatzaufwand ohne direkten Nutzen und hinterher muss man sich die wichtigen Einträge mühsam rausfummeln. Mercurial (oder jedes andere dezentrale SVN ) macht das genau anders herum. Eine man page, in 5 Minuten installiert und per Kommandozeile oder Grafikoberfläche bedienbar. Einarbeitungszeit 1-2 Stunden, es nervt nicht und der eigene Benfit ist sofort erkennbar. Die Doku entsteht dann fast von selbst. Kosten: 0 in Worten null.
Mark Brandis schrieb: > Klingt ja alles gut. Gegenfrage: Wie groß ist die Firma, bei der Du > angestellt bist? Ich könnte mir vorstellen, dass es bei Euch wesentlich > mehr Entwickler gibt als die 10 - 2 = 8 Mann, die in der Firma des > Themenerstellers in dieser Position arbeiten. 10 Entwickler. Die Firma selbst ist natürlich etwas größer. Das spielt aber auch keine große Rolle, das System funktioniert ja schon mit zwei Mann. Ob zwei Mann gemeinsam gleichzeitig an zwei Projekten arbeiten oder jeweils einer an einem spielt dann auch keine Rolle. Die Umschaltverluste werden nach meiner Erfahrung durch den Produktivitätsgewinn mehr als aufgehoben. Man sollte lediglich vermeiden, dass zwei Projekte gleichzeitig in die heiße Phase läuft. Dann müsste man nämlich wieder auf die 1:1-Methode zurück gehen, um Prioritätskonflikte zu vermeiden. Bei vernünftiger Planung ist das aber kein Problem.
Danke für die vielen Vorschläge. Die gehen aber zum Teil von falschen Voraussetzungen aus, ich hab das wohl nicht ganz klar formuliert: Wir sind keine klassische Software-Firma! SW-Entwicklung macht bei uns je nach Projekt und Projektphase zwischen 0% und 70% aus (wobei die 70% selten sind). Diesen teil haben wir aber mit Subversion recht gut im griff. Der Rest ist Konfiguration (diese wird in der Software durchgeführt, und ist damit für Subversion nicht greifbar) und klassisches Consulting im Sinne von Prozessdesign, Prozessoptimierung, Anpassung von Arbeitsabläufen, ...) Einer Änderung im Code (welche per Subversion dokumentiert ist) ist dann meist das Ergebnis einer (wochen-)langen Diskussion, und steht in Zusammenhang mit Prozessänderungen oder Änderungen im Arbeitsablauf. Im Commit-Komentar steht dann z.B. korrekt "Projektgruppe umgestellt von 'A' auf 'A1' oder 'A2'" Warum das so ist, was damit zusammenhängt, warum es kein A3 gibt, die verschlungenen Wege zur Entscheidungsfindung und die schlußendliche Beschlussfassung (durch wen?) steht dann im Tagebuch. (vielmehr "sollte stehen" :-) Der Umfang des "Tagebuchs" ist eher gering (natürlich auch abhängig von der projektphase). Wenn ich einen ganzen Tag damit verbringe an der ERp-Kopplung zu arbeiten, steht da vielleicht nur ein Einzeiler "Implementierung ERP-Kopplung". Wenn ich an 25 Themen arbeite, 25 Ein- oder Mehrzeiler. Wenn ich den ganzen Tag im Workshop sitze, das WorkshopProtokoll. Im Schnitt sag ich mal: eine bis zwei A4-Seite pro Tag. Passt auch gut zu meinen Tagebüchern von größeren Projekten: um die 300 Seiten. Also viel zu klein um einen eigenen Mitarbeiter für die Doku abzustellen.
:
Bearbeitet durch User
Ohne mehr als die Hälfte des Threads gelesen zu haben: - Führt eine Mailingliste ein, auf der alle sitzen die sich potentiell irgendwann mal durch so ein Tagebuch wühlen müssen. Dort postet dann jeder kurz vor Feierabend seinen Tagebucheintrag. Die Kollegen können diese dann schon lesen, bevor sie sich einarbeiten müssen. Rückfragen sind so auch möglich. - Fordere, wie schon angesprochen, sinnvolle Commit Texte. - Commits sollten immer nur eine einzige Sache fixen/verbessern, auch wenn sie dann womöglich nur aus einer Zeile bestehen. - Sorg dafür, dass sich die Konfigurationsänderungen im SCM abbilden lassen, und sei es nur als Dump des Windows Registry Zweiges.
Daniel schrieb: > Ohne mehr als die Hälfte des Threads gelesen zu haben: > > - Führt eine Mailingliste ein, auf der alle sitzen die sich potentiell > irgendwann mal durch so ein Tagebuch wühlen müssen. Dort postet dann > jeder kurz vor Feierabend seinen Tagebucheintrag. Die Kollegen können > diese dann schon lesen, bevor sie sich einarbeiten müssen. Rückfragen > sind so auch möglich. Gute Idee. > - Fordere, wie schon angesprochen, sinnvolle Commit Texte. Das funktioniert. > - Commits sollten immer nur eine einzige Sache fixen/verbessern, auch > wenn sie dann womöglich nur aus einer Zeile bestehen. Funkioniert auch. > - Sorg dafür, dass sich die Konfigurationsänderungen im SCM abbilden > lassen, und sei es nur als Dump des Windows Registry Zweiges. Schwierig. Die Software (nicht von uns) speichert die Konfiguration in der Datenbank, wie genau ist für uns nicht wirklich nachvollziehbar (aber außer zu Doku-Zwecken auch nicht notwendig zu wissen)
Michael Reinelt schrieb: > Was tut man in einer solchen Situation? ich bin ratlos... Dokumentation als Teil der Zielvereinbarung sehen und entsprechend entlohnen.
Michael Reinelt schrieb: >> - Sorg dafür, dass sich die Konfigurationsänderungen im SCM abbilden >> lassen, und sei es nur als Dump des Windows Registry Zweiges. > > Schwierig. Die Software (nicht von uns) speichert die Konfiguration in > der Datenbank, wie genau ist für uns nicht wirklich nachvollziehbar > (aber außer zu Doku-Zwecken auch nicht notwendig zu wissen) Und was macht ihr, wenn ihr auf einen alten Konfigurationsstand zurück müsst? Wie macht ihr Backups der Datenbank?
Daniel schrieb: > Michael Reinelt schrieb: >> Schwierig. Die Software (nicht von uns) speichert die Konfiguration in >> der Datenbank, wie genau ist für uns nicht wirklich nachvollziehbar >> (aber außer zu Doku-Zwecken auch nicht notwendig zu wissen) > > Und was macht ihr, wenn ihr auf einen alten Konfigurationsstand zurück > müsst? Wie macht ihr Backups der Datenbank? Schwierig. Backups gehen über die Standard-Mechanismen des SQL-Servers. Der Weg zurück hängt davon ab: Wenn nur einer/wenige Parameter geändert wurden, setzt man die halt wieder zurück (da ist wenigstens eine Art Protokoll in der (Fremd-)Software vorhanden) Wenns um komplexter Änderunge geht (z.B. Maskenänderungen) erfolgt das auch in mühsamer Handarbeit. Da greift leider das Prinzip der "normativen Kraft des Faktischen" (die Fremdsoftware ist da leider dämlich) Umso wichtiger ist eine Dokumentation was geändert wurde.
Michael Reinelt schrieb: > Umso wichtiger ist eine Dokumentation was geändert wurde. Ja WENN diese Spezialisten die nötige Zeit dazu bekommen UND noch ausreichend motiviert sind (was so ähnlich schon oben zu lesen ist).
Meiner Erfahrung nach wird eine nachträgliche Dokumentation IMMER unzureichend geführt. Selbst Skripe von Besprechungen lassen oft wichtige Entscheidungen aus, besonders wenn diese Begründungen enthalten, warum ein bestimmter Lösungsweg NICHT eingeschlagen wurde. Dagegen hilt eine Zeitnahe (sofortige) Dokumentation auf Stimmrecorder und nachtröglicher Abschrift. Eine nachträgliche Projektdokumentation (mit all ihren qualitativen Abstrichen) kann nur durch eine detaillierte VORHERIGE schriftliche Absichtserklärung (ähnich einem Pflichtenheft) ersetzt werden. Besteht zusätzlich noch die Pflicht, dieses Dokument VOR Ausführung der beschriebenen Arbeiten genehmigen zu lassen, ist der gewünschte Status erreicht. Die Dokumentation ist dann die Grundlage der auszuführenden Arbeiten und nicht mehr die (mangelhafte) Beschreibung der Ausführung. Jörg
Jörg Meier schrieb: > Die Dokumentation ist dann die Grundlage der auszuführenden Arbeiten und > nicht mehr die (mangelhafte) Beschreibung der Ausführung. Stimmt, Arbeit nach Doku sollte funktionieren. Nur die "kleinen" Änderungen, die zum funktionieren noch fehlen, sollten AUCH dokumentiert werden...
nein? schrieb: >>Ca. alle zwei bis drei Monate schau ich mal über diese > Tagebücher, > > Mach das taeglich. Bis es gut ist, auch wenn's kleinlich erscheint. Wenn > es ein Arbeitsziel ist, muss darauf geachtet werden. Nicht alle paar > monate einmal. Das halte ich für den besten Vorschlag. Mach das jeden Tag gleich als erste deiner Aufgaben am Morgen. Und kläre die Lücken unmittelbar danach mit den einzelnen Mitarbeitern direkt, nicht per Telefon oder E-Mail. Bei deinem jetzigen Vorgehen denken sich die Nicht-Dokumentierer: "Ah, hat er wieder seinen Doku-Rappel! Gottseidank geht das immer schnell vorbei und ich kann wieder in Ruhe meine Arbeit machen." Durch deine permanente Aufmerksamkeit vermittelst du, dass Dokumentation wichtig ist - und eben kein Rappel, der wieder vorübergeht. Das erfordert Disziplin, und zwar von dir! Auch darf deine Aufmerksamkeit nicht nachlassen, wenn es dann mal gut läuft. Die Vorschläge hinsichtlich Bonus/Malus halte ich für nicht zielführend. Die Mitarbeiter werden sich zwar anpassen, aber nur dahingehend, dass sie versuchen Punkte zu sammeln, statt gut zu dokumentieren. Sowas wirkt sich nicht gut auf das Arbeitsklima aus.
Michael Reinelt schrieb: > Der Rest ist Konfiguration (diese wird in der Software durchgeführt, und > ist damit für Subversion nicht greifbar) Wieso das? Auch eine Konfigurationsdatei kann man in Subversion einchecken und mit "diff" die Änderungen zu anderen Versionen vergleichen. Einzige Voraussetzung ist, dass man dafür ein vernünftiges Dateiformat nimmt, also sowas wie .xml oder .txt oder .csv. > Im Commit-Komentar steht dann z.B. korrekt "Projektgruppe umgestellt von > 'A' auf 'A1' oder 'A2'" Warum das so ist, was damit zusammenhängt, warum > es kein A3 gibt, die verschlungenen Wege zur Entscheidungsfindung und > die schlußendliche Beschlussfassung (durch wen?) steht dann im Tagebuch. > (vielmehr "sollte stehen" :-) So langsam glaube ich zu verstehen, wo das Problem liegt. Wie trackt Ihr denn, welche Anforderungen in welchem Projekt bzw. in welcher Software-Version umgesetzt werden? Gar nicht? ;-) Normalerweise verwendet man dafür ein Bugtracking-Tool wie z.B. Bugzilla. Dort schreibt man rein, was für Änderungen gemacht werden müssen und warum. Ein (noch) fehlendes Feature in der Software wird einfach ebenfalls wie ein "Bug" behandelt. Beim Einchecken einer Code-Änderung referenziert man dann auf einen bestimmten Eintrag im Bugtracking-System. Dadurch hat man das "wie" (nämlich die Code-Änderung an sich) mit dem "was" und "warum" verlinkt (was war der Auslöser für die Änderung). Et voilà! http://de.wikipedia.org/wiki/Bugtracker
:
Bearbeitet durch User
Mein bescheidener Vorschlag: Schau dir eine Stunde vor Arbeitsschluss die Tagebücher an. So weißt du auch Bescheid, was bzgl. der einzelnen Projekte passiert ist am Tag. Wenn ein Mitarbeiter das Tagebuch nicht/schlampig geführt hat, dann sagst du ihm, dass er es bitte jetzt sofort nachholen soll. Wenn du am Anfang vom Tag kontrollierst, dann wird es sowieso bis zum Ende aufgeschoben. Bonus/Malus halte ich für eher unangebracht, weil es zum normalen Arbeitspensum gehört, aber vielleicht würde etwas in der Größenordnung wie 10-min. früher Schluss, wenn Tagebuch ordentlich geführt wurde, oder ein kleiner Bonus zum Wochenende helfen. Ob sowas angebracht ist, musst du dir überlegen. Glaube aber kaum, dass das Kürzen eines Jahresbonus hilft. Es wäre natürlich gerechtfertigt, weil es eben zur Arbeit gehört eine ordentliche Dokumentation zu erstellen, aber Menschen denken da eher kurzfristig und wenn ein Mitarbeiter schon 5 Monate nicht dokumentiert hat und auf 0,- ist, dann wird er die restlichen 7 Monate wahrscheinlich überhaupt nicht kontrollieren. Wichtig ist mEn also die kurzfristige/taggleiche Kontrolle.
Wenn Du es ordentlich dokumentiert haben willst google mal nach "GAMP 5". Aber vermutlich willst Du das sowieso mit Deinem Tagebuch durchführen: Dann kontrolliere das jeden Tag und gib den Mitarbeitern mit ordentlicher Dokumnetation einen kleinen Bonus bar auf die Tatze, als Prämie für zukünfige Effizienz.
Hempel schrieb: > eine Stunde vor Arbeitsschluss > ... > am Anfang vom Tag Die Variante "eine Stunde vor Arbeitsschluss" hat aus meiner Sicht zwei Nachteile: - Als Kontrollierender ist man evtl. um diese Tageszeit mit "irgendwas Unaufschiebbarem" beschäftigt, das jetzt gemacht werden muss und die Kontrolle findet an dem Tag nicht mehr statt. - Bis alle Tagebücher kontrolliert sind, ist evtl. ein Mitarbeiter, den man sich schnappen müsste, schon nach Hause gegangen. Also muss man sich eine Notiz machen, dass man am nächsten Tag darauf zurückkommt. Das ist unnötiger Zusatzaufwand.
Exempel statuieren. Nichts ist schlimmer als MA, die wissen, dass sie sich alles erlauben können. Mal einen Abmahnen und wenn es sich nicht bessert, kündigen. Jeder MA ist ersetzbar.
ing² schrieb: > Exempel statuieren. Nichts ist schlimmer als MA, die wissen, dass sie > sich alles erlauben können. Toll, eine Terrorherrschaft. Wer sich nicht anders zu helfen weiß ist wirklich armselig und als Führungskraft nicht zu gebrauchen.
In Amiland ist das leider gang & gebe. Die nennen das "Management by fear". Soll ja auch hier vorkommen, aber das hat wohl wenig zukunft... Jörg
Antimedial schrieb: > ing² schrieb: >> Exempel statuieren. Nichts ist schlimmer als MA, die wissen, dass sie >> sich alles erlauben können. > > Toll, eine Terrorherrschaft. Wer sich nicht anders zu helfen weiß ist > wirklich armselig und als Führungskraft nicht zu gebrauchen. Eine Terrorherrschaft ist nicht gut, aber in einem Punkt hat er Recht: Die Geschäftsleitung muss Vorgaben machen können, die dann von den Angestellten einzuhalten sind. Wenn es zu den klar definierten Arbeitsaufgaben eines Angestellten gehört, unter anderem auch Dokumentation zu verfassen, dann hat der Angestellte hier nun mal eine Pflicht zu erfüllen. Unter anderem für diesen Teil seiner Arbeit wird er ja bezahlt. Wenn er nun wiederholt und trotz mehrerer mündlicher Ermahnungen diesen Teil seiner Aufgaben einfach nicht erfüllt, und keinerlei guten Willen zeigt dies in Zukunft zu ändern, dann würde ich in dem Fall eine schriftliche Abmahnung durchaus für gerechtfertigt halten.
Noch einmal: Für den Kunden wird ein Pflichtenheft als Grundlage für die Auftragsvergabe erstellt, warum dann nicht die Erweiterung des "Internen" Pflichtenhefts schaffen, in dem dokumentiert (in Form von QM-Arbeitsanweisungen) ist, WAS auszuführen ist. Wenn das in Papierform existiert, kann der betreffende Mitarbeiter "abhaken/abzeichnen" was er durchgeführt hat und bekommt gleichzeitig Raum für Notizen zu Besonderheiten. Werden später all diese Infos zusammengefasst (es arbeiten ja mehrere Leute parallel) so lässt sich nachvollziehen, wer wan was ausgeführt hat. Das entbindet den einzelnen MA von der Pflicht Aufsätze zu schreiben, schließlich hat er ja etwas anderes zu tun. Wird der Text, die äußere Form, der Raum für Ergänzungen und die Formulierungen dieses Pflichtenhefts von allen betroffenen MA (im Voraus!!!) gemeinsam erstellt, so fühlen sie sich auch stärker daran gebunden. Übernimmt nun auch noch eine Schreibkraft das Zusammenführen der geänderten / ergänzten Texte, so können zeitnah nach Projektschluss Lücken in der Doku erfragt und abgeglichen werden. Allemal besser als eine Abmahnung. Jörg
Michael Reinelt schrieb: > Im Commit-Komentar steht dann z.B. korrekt "Projektgruppe umgestellt von > 'A' auf 'A1' oder 'A2'" Warum das so ist, was damit zusammenhängt, warum > es kein A3 gibt, die verschlungenen Wege zur Entscheidungsfindung und > die schlußendliche Beschlussfassung (durch wen?) steht dann im Tagebuch. > (vielmehr "sollte stehen" :-) Und jetzt stell Dir mal einen Commit-Kommentar vor, der lautet "MODULA-1426 Projektgruppe 'A' umgestellt auf 'A1'." Und bei MODULA-1426 handelt es sich um die Ticketnummer, mit dem die Entwickler die Änderungen umsetzen sollen, und in diesem Ticket gibt es einen Verweis auf Ticket 'SUPPORT-95234', wo der erste Anruf des Kunden dokumentiert wurde. Ich arbeite ebenfalls als Entwickler in einer kleinen Firma. Wenn ich eine Code-Änderung mache (weil irgendein Kunde eine Änderung haben möchte), gibt es in mindestens zwei Tickets im firmenweiten Ticketsystem, im ganz extremen Fällen sogar ganz viele Issues: * Ticket vom Support-Team (und eigentlich noch eines im speziellen 1Level-Support+CRM-Ticketsystem) * ggf. Ticket vom Projektbereich, um das genaue Vorgehen zu klären (z.B. genaue Anforderungen, fällt das unter Pflege oder wird es separat abgerechnet, ...) * Das eigentliche Entwicklungsticket * ggf. das alte Entwicklungsticket, zur ersten Umsetzung einer jetzt anzupassenden Funktion Das heißt, einige der Dokumentationsangaben ("Warum muss ich hier was machen?") stehen schon ohne mein Zutun, bevor ich auch nur die IDE öffne. Wichtig ist: (a) Jeder (auch Entwickler) können auf alle diese Verwaltungstickets zugreifen, (b) man kann leicht von einem Issue zu einem anderen gelangen, diese sind also auch richtig verknüpft. Wir benutzen auch die schon erwähnte Kombi "JIRA + Fisheye + Subversion". -- Lass die Entwicklern fühlen, wofür die Doku relevant ist. Nimm ruhig mal einen der Entwickler relativ früh mit ins Boot (als Passagier!), wenn es um eine entsprechende Änderung geht, bzw. wenn man später mal Probleme aufklären muss. Damit sie auch sehen, warum das wichtig ist. -- Mal eine andere Frage: Wie dokumentierst Du eigentlich die Aufgaben und Anforderungen, welche Du den Entwicklern gibst?
Danke, Achim, und alle anderen. Aber: die meisten eurer Vorschläge gehen etwas in die falsche Richtung, weil ihr von falschen Voraussetzungen ausgeht. ich hab das schon mal versucht klarzustellen, die botschaft ist aber offensichtlich nicht ganz angekommen... Wir sind KEINE SOFTWARE-ENTWICKLER! Ja, wir programmieren im Zuge eines typischen Projektes auch die eine oder andere Kleinigkeit, aber das macht nur einen kleinen Teil der Projektarbeit aus. Und den Software-Teil haben wir auch recht gut im Griff. Die Probleme haben wir auch weniger nach Projektabschluß (Stichwort: Ticket-System), sondern während der Projektphase. Hier macht aus meiner Sicht ein Ticket-System keinen Sinn. Unsere Projekte sind auch durchaus komplex, trotzdem machen wir vorher keine detaillierten Pflichtenhefte (sondern wenden eher eine XP-ähnliche Methode an). Vorher werden mit dem Kunden ziele vereinbart, welche Funktionalität gegeben sein muss, welche Prozesse abgebildet werden sollen, welche Systeme angebunden werden sollen, welche Daten (Metadaten und/oder Dateien) urgeladen werden sollen. Das alles aber nicht im Detail, das wäre auch gar schwer möglich, bzw. würde uns das kaum ein Kunde zahlen, auch ist das für den Kunden meist unmöglich weil er einfach keine Erfahrung hat, was ein PDM/DMS für ihn tun kann. Die Projektphase ist dann ebenfalls recht agil: man macht zum thema einen (eintägigen) Workshop mit dem Kunden, erarbeit gemeinsam ein Thema, dann wird es umgesetzt, beim nächsten Workshop wird dieser teilbereich (meist ein grober Prototyp) gemeinsam beurteilt, Änderungen/Verbesserungen besprochen, und das nächste Thema erarbeitet. So ist der Kunde immer hautnah dran, er und wir erkennen frühzeitig das wir uns irgendwo verrannt oder mißverstanden haben, und das kann sofort ohne großen Aufwnad korrigiert werden. Es ist uns noch nie passiert, dass der Kunde nach größerem Aufwand unsererseits dann gesagt hat "Nein, so hab ich mir das nicht vorgestellt!" Diese Art Projekte abzuwickeln, mag etwas chaotisch klingen, aber das passt schon, weil es etwas chaotisch ist. Aber unglaublich erfolgreich! Wir kriegen immer wieder bestätigt, wie schnell und flexibel wir agieren, wenn der Kunde das z.B. mit einer ERP-Einführung vergleicht, werden da Faktoren von 10..100 genannt :-) Aber: diese chaotische Vorgehensweise erfordert Dokumentation. Das Tagebuch eben. Auch hier nochmal: das Tagebuch besteht nicht aus Romanen. Der Verlauf eines tages sollte halt auf ca. einer A4-Seite mitdokumentiert werden: Was wurdegemacht, warum wurde es gemacht, wie wurde es gemacht. Welche Entscheidungen kamen vom Kunden, welche problmee gab es wo, was war die ursache, wie wurden diese gelöst.
Michael Reinelt schrieb: > Der Verlauf > eines tages sollte halt auf ca. einer A4-Seite mitdokumentiert werden: Von wie vielen Mitarbeitern zusammen ergibt das 1 A4 Seite? Normalerweise ist 1 A4 Seite ca 2h Arbeit (doppelter Zeilenabstand).
Michael Reinelt schrieb: > Danke, Achim, und alle anderen. > > Aber: die meisten eurer Vorschläge gehen etwas in die falsche Richtung, > weil ihr von falschen Voraussetzungen ausgeht. ich hab das schon mal > versucht klarzustellen, die botschaft ist aber offensichtlich nicht ganz > angekommen... > > Wir sind KEINE SOFTWARE-ENTWICKLER! Und? darum geht es doch gar nicht. Es geht doch wohl darum: Du bist Chef/Vorgesetzter und deine Leute machen nicht was du ihnen sagst. Also ein Führungsproblem. Entweder überzeugst du deine Mitarbeiter durch Reden, Zuckerbrot und/oder durch Druck (Peitsche). Wenn die nichts mehr einfällt, dann wie schon erwähnt Druck: - Regelmäßige Kontrolle und Anschiss wenn nicht gemacht. - An den Bonus / die Leistungszulage koppeln. - Abmahnen wegen Nichtbefolgen ein Arbeitsanweisung (die Arbeitsanweisung zuvor natürlich klar, deutlich und arbeitsgerichtfest erteilen) - Kündigungen / Versetzen (auch hier natürlich gerichtsfest) Freunde machst du dir damit nicht. Aber dafür bekommst du den Chef-Gehalt. Keine Eier in der Hose es zu machen? Tja, dumm gelaufen.
Michael Reinelt schrieb: > (Stichwort: Ticket-System) Lös Dich mal von der Vorstellung, dass ein Ticket-System nur für Bugs benutzt werden darf. Bei uns ist auch die Freischaltung eines Kundenzugangs zum Online-Hilfesystem ein Issue, das kriegen wir Entwickler nie zu sehen. Oder auch die Änderungswunschliste eines Kunden.
dumdi dum schrieb: > Michael Reinelt schrieb: >> Der Verlauf >> eines tages sollte halt auf ca. einer A4-Seite mitdokumentiert werden: > > Von wie vielen Mitarbeitern zusammen ergibt das 1 A4 Seite? pro Mitarbeiter > Normalerweise ist 1 A4 Seite ca 2h Arbeit (doppelter Zeilenabstand). geh bitte! meisselst du das in Stein oder was?
Michael Reinelt schrieb: > geh bitte! meisselst du das in Stein oder was? Ernsthaft! Eine A4 Seite pro Tag Doku pro Person läuft nicht so einfach mit, das kostet Zeit. (und zwar mehr als Deine Jungs haben). Genau hier ist Dein Problem und nirgendwo anders. Falls Du jetzt anfängst Deinen Mitarbeitern den Bonus zu kürzen bist Du die guten zuerst los.
Michael Reinelt schrieb: > Wir sind ein kleines IT-Unternehmen (10 MA) und beschäftigen uns > hauptsächlich damit, eine Software zu verkaufen und zu implementieren. Michael Reinelt schrieb: > Wir sind KEINE SOFTWARE-ENTWICKLER! Ja, was denn nun?
dumdi dum schrieb: > Ernsthaft! Eine A4 Seite pro Tag Doku pro Person läuft nicht so einfach > mit, das kostet Zeit. (und zwar mehr als Deine Jungs haben). Genau hier > ist Dein Problem und nirgendwo anders. Nein, Einspruch! die Doku muss nicht "schön" ausformuliert und schön formatiert sein. Notizen halt. Eine A4-Seite Notizen kostet mich maximal 15 Minuten. Und die zeit ist vorhanden. Punkt.
Mark Brandis schrieb: > Michael Reinelt schrieb: >> Wir sind ein kleines IT-Unternehmen (10 MA) und beschäftigen uns >> hauptsächlich damit, eine Software zu verkaufen und zu implementieren. > > Michael Reinelt schrieb: >> Wir sind KEINE SOFTWARE-ENTWICKLER! > > Ja, was denn nun? Du kennst aber den Unterschied zwischen Software entwickeln und (fertige Fremd-)Software implementieren?
Michael Reinelt schrieb: > Notizen halt. Eine A4-Seite Notizen kostet mich > maximal 15 Minuten. Vielleicht ist da ein Missverständnis: Die Notizen werden getippt oder redest Du von einer Seite handschriftlich?
dumdi dum schrieb: > Michael Reinelt schrieb: >> Notizen halt. Eine A4-Seite Notizen kostet mich >> maximal 15 Minuten. > > Vielleicht ist da ein Missverständnis: Die Notizen werden getippt oder > redest Du von einer Seite handschriftlich? Natürlich getippt! Alleine schon deshalb weil tlw. per Copy&paste reinkopiert wird (Ausschnitte aus emails, SQL-Statements, Commands etc.)
:
Bearbeitet durch User
Michael Reinelt schrieb: > Natürlich getippt! > Alleine schon deshalb weil tlw. per Copy&paste reinkopiert Gut, dann sag ihnen doch, dass das Tagebuch zwar eine Seite sein soll, sie dafür aber nicht mehr Zeit verwenden dürfen als die Besagten 15 min. Dafür ist es auch erlaubt, Stichpunktartig mit Copy und Paste die Seite zu füllen. Dass dies später keiner mehr entziffern kann, weil nicht genügend Zeit vorhanden warum um ganze verständliche Sätze zu formulieren ist dann dein Problem. Oder du gibts ihnen, sagen wir mal, eine Stunde pro Tag zeit dafür. Dann musst du als Chef aber damit zu recht kommen, dass deine Projekte plötzlich um 12% langsamer ablaufen weil sie 1/8 ihrer Zeit mit Tagebuchschreiben opfern müssen. Ich sehe hier, wie schon angedeutet ein anderes Problem. Du bist Chef, und deine Angestellten machen nicht was du verlangst. Und du verlangst zusätzlich dass sie eine Tätigkeit "einfach so nebenher" machen, die garkeine Zeit kosten darf. Zusätzliche Tätigkeiten benötigen zusätzliche Zeit.
Daniel schrieb: > Und du verlangst zusätzlich dass sie eine Tätigkeit "einfach so > nebenher" machen, die garkeine Zeit kosten darf. > Zusätzliche Tätigkeiten benötigen zusätzliche Zeit. Woraus schließt du das? ich habe mehrfach klargestellt, dass die zeit dafür vorhanden ist. Auch wie der Inhalt aussehen soll (Stichworte, unvollständige Sätze, kein "Schul-Deutsch", Copy&Paste, Umfang) wurde mehrfach im Team definiert und abgesegnet (nicht von mir, sondern vom team)
Mark Brandis schrieb: > Die Geschäftsleitung muss Vorgaben machen können, die dann von den > Angestellten einzuhalten sind. Wenn es zu den klar definierten > Arbeitsaufgaben eines Angestellten gehört, unter anderem auch > Dokumentation zu verfassen, dann hat der Angestellte hier nun mal eine > Pflicht zu erfüllen. Unter anderem für diesen Teil seiner Arbeit wird er > ja bezahlt. Klar, das ganze klingt in der Theorie echt toll und würde perfekt funktionieren, wenn Menschen gefühlslose, gleichgeschaltete Maschinen wären, die Anweisungen einfach abarbeiten würden. Zum Glück sind die meisten Menschen eben doch fühlende Wesen, die sich eben nicht immer perfekt Verhalten und Anweisungen befolgen. Zum Glück, sonst wäre nämlich kein Platz für Kreativität (zugegeben: gerade in Konzernen ist Kreativität wegen genau solchen Vorschlägen schon fast ausgestorben). Doch da entsteht eben auch das Problem: Menschen tun nicht das, was sie gesagt bekommen, sondern in erster Linie das, was sie für sinnvoll halten und worin sie ihre Neigung sehen (lapidar: was ihnen Spaß macht). Wenn sie etwas anderes tun, werden sie extrem ineffektiv bis zu dem Punkt, dass es besser wäre, sie gleich raus zu schmeißen. Hirnlose Manager geben nur Anweisungen, weil sie diese Komponente einfach nicht verstehen können. Schlaue Führungskräfte erkennen das und stellen ihr Team so auf, dass jeder so viel wie möglich nach seinen eigenen Neigungen arbeiten kann. Und an Stellen, an denen es nicht funktioniert, muss man eine Lösung finden, wie man die Leute überzeugt, dass die "unliebsame" Tätigkeit so angenehm und sinnvoll wie möglich gestaltet wird. Hier können Tools helfen (sie können es aber auch schlechter machen). Hier kann aber auch ein gutes Vorbild helfen. Wenn ein Chef oder ein zentraler Mitarbeiter tagtäglich vorlebt, wie man gute Doku erstellt, mit der man sehr gut arbeiten kann, werden auch die größten Dokumuffel irgendwann einsehen, dass sie sich wenigstens etwas bemühen könnten. Man darf aber nie erwarten, dass die die gleiche Qualität abliefern wie der geborene Dokumenteur.
Antimedial schrieb: > Und an Stellen, an denen es nicht > funktioniert, muss man eine Lösung finden, wie man die Leute überzeugt, > dass die "unliebsame" Tätigkeit so angenehm und sinnvoll wie möglich > gestaltet wird. Hier können Tools helfen (sie können es aber auch > schlechter machen). Hier kann aber auch ein gutes Vorbild helfen. Wenn > ein Chef oder ein zentraler Mitarbeiter tagtäglich vorlebt, wie man gute > Doku erstellt, mit der man sehr gut arbeiten kann, werden auch die > größten Dokumuffel irgendwann einsehen, dass sie sich wenigstens etwas > bemühen könnten. Man darf aber nie erwarten, dass die die gleiche > Qualität abliefern wie der geborene Dokumenteur. Danke dir, das bringt mein Problem auf den Punkt. Ich hoffe ich bin ein einigermaßen brauchbares Vorbild, genauso wie einige andere Mitarbeiter. In gemeinsamen Reviews (die wir leider viel zu selten machen) holen wir uns da auch gegenseitig Anregungen, wie man das effektiver, effizienter, einfacher, schneller machen kann. Die "problematischen" (blödes Wort) Mitarbeiter arbeiten da auch mit, bringen sich ein, sparen auch nicht mit Kritik, die dann im Team aufgearbeitet wird. Natürlich greift dann von Fall zu Fall auch das "Ober sticht Unter" Prinzip, aber auch das im Wesentlichen im Konsens. So weit, so schön, so nett. Nur funktioniert es nicht. Ich hab immer noch zwei, drei Kandidaten, bei denen es einfach nicht funktioniert.
Konrad S. schrieb im Beitrag "Re: Wie kriegt man Mitarbeiter dazu, zu dokumentieren?" > Mach das jeden Tag gleich als > erste deiner Aufgaben am Morgen Und, schon mal darüber nachgedacht?
Michael Reinelt schrieb: > Nur funktioniert es nicht. Ich hab immer noch zwei, drei Kandidaten, bei > denen es einfach nicht funktioniert. Das klingt doch gar nicht so schlecht. Ein paar Ausreißer gibt es immer, damit muss man leben. Deinen Beschreibungen nach hätte ich eher mit > 50% gerechnet. So brauchst du noch nicht einmal einen halbe Arbeitskraft, um die zwei Leute in Griff zu bekommen (wie gesagt, insgesamt kommst du ja positiv raus, da die halbe Arbeitskraft effektiv mehr Gewinn heraus holt). Das lohnt sich allerdings nur, wenn die Leute sonst wirklich tauglich sind und nur nicht dokumentieren können. Ansonsten kannst du ja mal einen raus werfen und schauen was mit den anderen passiert.
Michael Reinelt schrieb: > Nur funktioniert es nicht. Ich hab immer noch zwei, drei Kandidaten, bei > denen es einfach nicht funktioniert. Sind das vielleicht dummerweise ausgerechnet die, die am meisten Arbeit wegschaffen?
Michael Reinelt schrieb: > Du kennst aber den Unterschied zwischen Software entwickeln und (fertige > Fremd-)Software implementieren? Auch wenn man Komponenten "zusammenschraubt" die von anderen entwickelt wurden, und diverse Parameter konfiguriert, kann man das durchaus noch mit einigem Recht als Softwareentwicklung ansehen. Jede einzelne Sache, die der Kunde haben will (besser noch: für die er bezahlen will), wird als Feature betrachtet. Ein fehlendes Feature ist ein Bug. Dieser Bug wird in einen Bugtracker eingetragen. Anschließend unternimmt man die nötigen Schritte, um den Bug zu beheben. Diese Schritte werden somit im Bugtracking-System dokumentiert.
Mark Brandis schrieb: > Jede einzelne Sache, die der Kunde haben will (besser noch: für die er > bezahlen will), wird als Feature betrachtet. Ein fehlendes Feature ist > ein Bug. Dieser Bug wird in einen Bugtracker eingetragen. Anschließend > unternimmt man die nötigen Schritte, um den Bug zu beheben. Diese > Schritte werden somit im Bugtracking-System dokumentiert. Klingt gut, ist aber praxisfern. ERP-Leute mögen das so machen (daher kommt vermutlich auch ihr "guter" Ruf), wir machen das nicht so.
> Kündigungsdrohung ist leider eine leere, weil unsere MA eigentlich einen > sehr guten Job machen, und sehr gut wissen dass sie nicht so einfach > gekündigt werden können. Schon mal das Ganze aus der Sicht Deiner Mitarbeiter gesehen? Sobald die anfangen gut zu dokumentieren, schaden die sich selbst, genau dann sind sie notfalls auch entbehrlich ... mal ganz abgesehen davon, daß sowas auch einiges an Zeit und Nerven (je nach Typ) der Mitarbeiter kostet ... mehr verdienen die deswegen nicht, da wäre ich auch nicht motiviert.
Michael Reinelt schrieb: > Mark Brandis schrieb: >> Jede einzelne Sache, die der Kunde haben will (besser noch: für die er >> bezahlen will), wird als Feature betrachtet. Ein fehlendes Feature ist >> ein Bug. Dieser Bug wird in einen Bugtracker eingetragen. Anschließend >> unternimmt man die nötigen Schritte, um den Bug zu beheben. Diese >> Schritte werden somit im Bugtracking-System dokumentiert. > > Klingt gut, ist aber praxisfern. Sehr schlecht formuliert :) Wie wäre es damit (habe einen Begriff ersetzt, nicht nur ein Wort): Jede einzelne Sache, die der Kunde haben will (besser noch: für die er bezahlen will), wird als Feature betrachtet. Ein fehlendes Feature ist ein Issue. Diese Issue wird in einen Issue-tracker eingetragen. Anschließend unternimmt man die nötigen Schritte, um das Issue einzubauen. Diese Schritte werden somit im Issuetracking-System dokumentiert. ---- Mal was anderes: Deine Mitarbeiter kriegen Papier-Pflichtenhefte. Haben die irgendeine halbwegs kurze eindeutige Kennzeichnung? So dass man diese im Commit oder sonstigen Einträgen kurz erwähnen kann? Wie können die Mitarbeiter auf alte Pflichtenhefte zugreifen, um dort nachzuschauen (z.B. warum man damals eine bestimmte naheliegende Lösung nicht genommen hat)? Papier hat halt den Nachteil, dass man es so schlecht "sharen" verschiedenen Orten gleichzeitig darauf zugreifen kann.
Michael Reinelt schrieb: > Klingt gut, ist aber praxisfern. > > ERP-Leute mögen das so machen (daher kommt vermutlich auch ihr "guter" > Ruf), wir machen das nicht so. Dein Wunsch nach Dokumentation klingt auch gut, ist aber praxisfern. Softwareentwickler machen das so (aber ihr entwickelt ja auch keine Software), ihr macht das nicht so. ;-)
Berlin-Fanclub schrieb: > Schon mal das Ganze aus der Sicht Deiner Mitarbeiter gesehen? > Sobald die anfangen gut zu dokumentieren, schaden die sich selbst, genau > dann sind sie notfalls auch entbehrlich ... Ich erlebe im Beruf das vollkommene Gegenteil davon! Immer wieder mal gibt es Leute, die mit diesem Argument ankommen. Und weißt Du, wer so argumentiert? Die schlechten Entwickler. Diejenigen, die sich auch krampfhaft weigern, ihren Code vernünftig zu dokumentieren. Die so programmieren, dass man sich für eine Funktion von zwanzig Zeilen Umfang erstmal eine Viertelstunde lang hinsetzen muss und sie mit Bleistift und Papier analysieren muss um sie zu verstehen, weil der Code so grottig schlecht geschrieben ist. Diejenigen, die Wochen brauchen um auf eine einfache Anfrage per E-Mail zu antworten. Ich habe noch nie erlebt, dass jemandem gekündigt wurde, weil er einen guten Job gemacht hat. Ganz so blöd sind die Arbeitgeber dann doch nicht. Die Leute, die gut dokumentieren, machen in der Regel auch ansonsten einen guten Job. Die Leute, die schlecht arbeiten, dokumentieren das nicht gerne, weil dann ja offensichtlich wird dass sie ihre Arbeit mit einer sehr begrenzten Qualität durchführen. Das ist jedenfalls meine persönliche Erfahrung mit mehreren Dutzend Entwickler-Kollegen. Gute Entwickler dokumentieren ihren Software. Sie schreiben keine Romane, das nicht, aber das verlangt ja auch niemand. Die Informationen, die sinnvollerweise da sein müssen, müssen da sein. Wer diese nicht bereitstellt, ist kein guter Entwickler. Punkt.
:
Bearbeitet durch User
Berlin-Fanclub schrieb: >> Kündigungsdrohung ist leider eine leere, weil unsere MA eigentlich einen >> sehr guten Job machen, und sehr gut wissen dass sie nicht so einfach >> gekündigt werden können. > Schon mal das Ganze aus der Sicht Deiner Mitarbeiter gesehen? > Sobald die anfangen gut zu dokumentieren, schaden die sich selbst, genau > dann sind sie notfalls auch entbehrlich ... mal ganz abgesehen davon, > daß sowas auch einiges an Zeit und Nerven (je nach Typ) der Mitarbeiter > kostet ... mehr verdienen die deswegen nicht, da wäre ich auch nicht > motiviert. Scheint ja ein sehr brisantes Thema zu sein. Wenn ich allein schon sehe, dass der TE eine -5 Bewertung hat, nur weil er dokumentieren lassen will. Das Thema ist ja definitiv lesenswert und die Frage berehchtigt, allerdings scheinen hier doch sehr viele Hacker rumzuhähngen, die den Sinn ihres Daseins darin sehen, ihr Knowhow nicht abzugeben sondern in die Produkte zu injizieren um sich unkündbar zu machen. Das ist genau so, als würden Schaltplanentwickler keine Schaltpläne mehr abgeben sondern nur noch Platinen und hinterher die Bestückunspläne verschwinden lassen. Von diesen "Programmieren" braucht die Industrie aber keinen einzigen. Erstens nicht, weil sie auf eigene Rechnung arbeiten und zweites nicht, weil ihre Ergebnisse nicht zu gebrauchen sind. Bei guten Projektleitern und QM-Verantwortlicnen gibt es sowas nicht. Raus mit den Hackern!
E. M. schrieb: > Von diesen "Programmieren" braucht die Industrie aber keinen einzigen. > Erstens nicht, weil sie auf eigene Rechnung arbeiten und zweites nicht, > weil ihre Ergebnisse nicht zu gebrauchen sind. > > Bei guten Projektleitern und QM-Verantwortlicnen gibt es sowas nicht. > > Raus mit den Hackern! Genau so sieht's aus.
Mark Brandis schrieb: > Immer wieder mal gibt es Leute, die mit diesem Argument ankommen. Und > weißt Du, wer so argumentiert? Die schlechten Entwickler. Soweit d'accord. Mark Brandis schrieb: > Diejenigen, die sich auch krampfhaft weigern, ihren Code vernünftig zu > dokumentieren. Hier allerdings nicht mehr. Es gibt immer noch Leute, die exzellente Arbeit abliefern, aber sich mit der externen Dokumentation schwer tun. Der Code wird meistens noch gut dokumentiert, aber Dinge wie Requirement Engineering und alles, was aus der QM-Welt kommt, wird es eben schwierig. Mark Brandis schrieb: > Die Leute, die gut dokumentieren, machen in der Regel auch > ansonsten einen guten Job. Da habe ich auch schon anderes erlebt. Nämlich Leute, die ihre nicht vorhandenen Ergebnisse hinter einem Berg von Pseudo-Dokumentation verstecken. Okay, jetzt kann man natürlich sagen, dass das nicht als "gut dokumentieren" zählt. Mark Brandis schrieb: > Gute Entwickler dokumentieren ihren Software. Sie schreiben keine > Romane, das nicht, aber das verlangt ja auch niemand. Die Informationen, > die sinnvollerweise da sein müssen, müssen da sein. Wer diese nicht > bereitstellt, ist kein guter Entwickler. Punkt. Leider gehen die Meinungen, was gebraucht wird, oft sehr stark auseinander. Vor allem wenn Nicht-Techniker im Projekt involviert sind. Dokumentation, die nur zum Generieren von Kennzahlen benötigt wird, ist überflüssig. Leider trotzdem häufig gefordert.
Berlin-Fanclub schrieb: > Schon mal das Ganze aus der Sicht Deiner Mitarbeiter gesehen? > Sobald die anfangen gut zu dokumentieren, schaden die sich selbst, genau > dann sind sie notfalls auch entbehrlich ... mal ganz abgesehen davon, > daß sowas auch einiges an Zeit und Nerven (je nach Typ) der Mitarbeiter > kostet ... mehr verdienen die deswegen nicht, da wäre ich auch nicht > motiviert. Sorry, aber die Argumentation krankt vorne und hinten. Jemand, der dokumentiert, macht sich nicht entbehrlich, ganz im Gegenteil. Aber das wurde von anderen ja schon ausführlich begründet. Und die Arbeit kostet Zeit und nerven? Stell dir vor, alles was ich (und die meisten anderen) den lieben langen Tag lang tue, um Geld zu verdienen, kostet zeit und Nerven...
Achim Hensel schrieb: > Jede einzelne Sache, die der Kunde haben will (besser noch: für die er > bezahlen will), wird als Feature betrachtet. Ein fehlendes Feature ist > ein Issue. Diese Issue wird in einen Issue-tracker eingetragen. > Anschließend > unternimmt man die nötigen Schritte, um das Issue einzubauen. Diese > Schritte werden somit im Issuetracking-System dokumentiert. nein, das funktioniert so auch nicht. Zumindest nicht in der Implementierungsphase. Das liegt daran, dass die Software bzw. unsere projekte nicht so funktionieren, dass man ein grundsätzlich funktionierendes Paket einspielt, welches der Kunde ändert (wie es bei vielen ERP-Systemen der Fall ist). Es gibt nicht "den Standard". Die Prozesse und die Konfiguration sind bei jedem Kunden anders, und müssen erarbeitet werden. Natürlich gibt es Ähnlichkeiten, best practices etc. Sehr sehr hinkender Vergleich: wir verkaufen und implementieren Kreissägen. Kunde will eine Hundehütte bauen. Welchen Issue nimmst du in deinen Tracker auf? (und NEIN, wir verkaufen kein Sharepoint :-) > Deine Mitarbeiter kriegen Papier-Pflichtenhefte. Haben die irgendeine > halbwegs kurze eindeutige Kennzeichnung? So dass man diese im Commit > oder sonstigen Einträgen kurz erwähnen kann? Wie können die Mitarbeiter > auf alte Pflichtenhefte zugreifen, um dort nachzuschauen (z.B. warum man > damals eine bestimmte naheliegende Lösung nicht genommen hat)? > > Papier hat halt den Nachteil, dass man es so schlecht "sharen" > verschiedenen Orten gleichzeitig darauf zugreifen kann. hey, wir machen (u.a.) in Dokumentenmanagement! "Papier" ist sowas wie ein "böses Wort" bei uns :-)
E. M. schrieb: > Scheint ja ein sehr brisantes Thema zu sein. Wenn ich allein schon sehe, > dass der TE eine -5 Bewertung hat, nur weil er dokumentieren lassen > will. Halleluja, das hab ich ja noch gar nicht bemerkt.... ich möchte wissen, was in dem geneigten leser vorgeht, der dieses Thema negativ bewertet... nun, Job bei uns wird er wohl keinen bekommen...
Michael Reinelt schrieb: > ich möchte wissen, was in dem geneigten leser vorgeht, der dieses Thema > negativ bewertet... nun, Job bei uns wird er wohl keinen bekommen... Das Bewertungssystem hier ist sowieso völlig Stulle. Mach Dir nichts draus.
Michael Reinelt schrieb: > Sehr sehr hinkender Vergleich: wir verkaufen und implementieren > Kreissägen. Kunde will eine Hundehütte bauen. Welchen Issue nimmst du in > deinen Tracker auf? Ich nehme mal an, dass bei einem einfachen Projekt (nur eine Hundehütte) auch keine großartige Doku notwendig ist. Da würde vielleicht das Issue "Kauf Standardprodukt 08/15" reichen :) Also mal auf eine Hundehüttenfabrik erweitert :) Das gibt mit der Zeit mehrere Issues (Nummern geben nicht unbedingt die tatsächliche Reihenfolge an): Issue 1: Projekt-Vorbesprechung "Hundehütte-ondemand.de GmbH" Issue 2: Technische Eigenschaften des speziellen, bisher nicht bekannten Hundehüttenholz ermitteln Issue 3: Erster Grobprojektplan Kreissägenstraße für Hundehüttenprofuktion aufgrund Gegebenheiten beim Kunden Issue 4: Finaler Plan für die Erweiterung der Elektroinstallation beim Kunden durch dessen Elektro-Partner Issue 5: Anpassung von Standardmaschine A17 auf dickere, aber faserigen Werkstoff Issue 6: Erneuter Workshop mit Kunde, ob Anforderung 13.II.02a leicht abgeändert werden kann, weil die erste Vorstellung des Kunden zu einem recht aufwändig zu lösendem Problem führen würde Issue 7: Zusammenstellung und Montage einer Anlage, zunächst für Testbetrieb Issue 8: Workshop Einarbeitung des Sägepersonals Issue 9: Umbau der Anlage an andere Zulieferstelle aufgrund neuer Erkenntnisse im Testbetrieb Issue 10: Auslieferung und Montage der auf Hundehüttenholz optimierten Sägeblätter Issue 11: Ersetzen der Absaugeanlage, weil erst im Betrieb gemerkt wurde, dass Hundehüttenholz den normalen Filter zu schnell zusetzt Issue 12: Projektvorbereitung Erweiterung der Sägemaschinenstraße um das Hobelmodul -- Andere Frage: Setzt Ihr Euer Produkt auch selbst ein? Vermutlich gibt es dort eine hierarchische Dokumentenorganisation? Kann man über eine sehr einfache eund kurze Kennung auf diese einzelnen Hierarchien referenzieren?
Michael Reinelt schrieb: > ich möchte wissen, was in dem geneigten leser vorgeht, der dieses Thema > negativ bewertet... nun, Job bei uns wird er wohl keinen bekommen... Vielleicht das mulmige Gefühl, dass die Öffentlichkeit dieses Forums nicht mehr der angemesssene Ort ist für die Lösung dieses Problems. Die grundlegenden Stellungnahmen sind abgegeben. Wenn es noch weiter diskutiert werden soll braucht es einfach mehr Vertraulichkeit und vielleicht einen Moderator.
Achim Hensel schrieb: > [ Issue tracker] Lass mal gut sein mit deinem Issue Tracker. gut gemeint, wir haben in die Richtung auch schon Versuche gemacht, hat sich einfach nicht bewährt, aus verschiedenen Gründen. > Andere Frage: Setzt Ihr Euer Produkt auch selbst ein? Ja. > Vermutlich gibt es dort eine hierarchische Dokumentenorganisation? Ja, gäbe es, verwenden wir aber sehr selten. (Wir wollen keinen "besseren Explorer" haben). Wir bevorzugen Beschlagwortung. > Kann man über eine sehr > einfache eund kurze Kennung auf diese einzelnen Hierarchien > referenzieren? Ja, könnte man. ich weiss worauf du hinauswillst. Hatten wir auch schon. Hat sich auch nicht bewährt. Außerdem: mein Problem wird sicher nicht durch die Tool-Frage gelöst
Michael Reinelt schrieb: > Außerdem: mein Problem wird sicher nicht durch die Tool-Frage gelöst Und tägliche Kontrolle der Tagebücher ist zu lästig, gell? ;-)
> Das Thema ist ja definitiv lesenswert und die Frage berehchtigt, > allerdings scheinen hier doch sehr viele Hacker rumzuhähngen, die den > Sinn ihres Daseins darin sehen, ihr Knowhow nicht abzugeben sondern in > die Produkte zu injizieren um sich unkündbar zu machen. Das ist genau > so, als würden Schaltplanentwickler keine Schaltpläne mehr abgeben > sondern nur noch Platinen und hinterher die Bestückunspläne verschwinden > lassen. Das ist völlig legitim, daß ich mir den Ast auf dem ich sitze nicht selbst absäge. > Von diesen "Programmieren" braucht die Industrie aber keinen einzigen. > Erstens nicht, weil sie auf eigene Rechnung arbeiten und zweites nicht, > weil ihre Ergebnisse nicht zu gebrauchen sind. > > Bei guten Projektleitern und QM-Verantwortlicnen gibt es sowas nicht. > > Raus mit den Hackern! Du siehst ja, daß der TO mit seinen Mitarbeitern, die ansonsten nach seiner Aussage sehr gut sind ein Problem hat ... und das hat tiefere Ursachen auf die sich der TO keinen Reim machen kann. Wenn man in der Lage ist - was hier offenbar niemand ist - das Ganze mal aus dem Blickwinkel des Mitarbeiters zu sehen, kommt man zu neuen Erkenntnissen. Schwache Führungsleistung, wenn man die Realität permanent ignoriert und hier rumjammert bzw. sich eine andere Realität herbeiwünscht und immer noch mehr an die Mitarbeiter delegiert - ist doch klar, daß die irgendwann dicht machen.
Konrad S. schrieb: > Michael Reinelt schrieb: >> Außerdem: mein Problem wird sicher nicht durch die Tool-Frage gelöst > > Und tägliche Kontrolle der Tagebücher ist zu lästig, gell? ;-) Nein, ganz im Gegenteil. Das ist einer der vielen Ratschläge die ich hier bekommen habe, welche ich umsetzen werde.
Berlin-Fanclub schrieb: > Das ist völlig legitim, daß ich mir den Ast auf dem ich sitze nicht > selbst absäge. Das tust du aber, wenn du absichtlich Arbeitsergebnisse verschwinden lässt oder Wissen zurück hältst.
> Gute Entwickler dokumentieren ihren Software. Sie schreiben keine > Romane, das nicht, aber das verlangt ja auch niemand. Die Informationen, > die sinnvollerweise da sein müssen, müssen da sein. Wer diese nicht > bereitstellt, ist kein guter Entwickler. Punkt. diese Schwarz-Weiß bzw. Gut-Schlecht Denkweise a la Ronald Reagan ist etwas abgegriffen. Das Ganze hat Gründe und die sind sehr unterschiedlich. Aber macht mal weiter mit der rosaroten Welt ;-)
Berlin-Fanclub schrieb: > Du siehst ja, daß der TO mit seinen Mitarbeitern, die ansonsten nach > seiner Aussage sehr gut sind ein Problem hat ... und das hat tiefere > Ursachen auf die sich der TO keinen Reim machen kann. Soweit richtig. > Wenn man in der Lage ist - was hier offenbar niemand ist - das Ganze mal > aus dem Blickwinkel des Mitarbeiters zu sehen, kommt man zu neuen > Erkenntnissen. Ok... > Schwache Führungsleistung Danke... > wenn man die Realität permanent ignoriert aha... > und hier rumjammert ach? > bzw. sich eine andere Realität herbeiwünscht echt? > und immer noch mehr an die Mitarbeiter delegiert ach so? Sorry, wer von uns hat grad ein problem mit der Realität?
> Das tust du aber, wenn du absichtlich Arbeitsergebnisse verschwinden > lässt oder Wissen zurück hältst. ich nicht, aber es unterschiedliche Motivationen und eigentlich sollte man die kennen ... last but not least gibt es auch sowas wie eine Delegationsgrenze und dann machen wie im Beispiel des TO offenbar auch die Mitarbeiter dicht, möglicherweise ?! Irgendwelche Gründe muß es ja wohl geben, oder?
Mal wieder zum ersten Post zurück: > ich hab schon so ziemlich alle Varianten durch, die ganze Bandbreite von > freundlichem Erklären warum wir das machen müssen bis hin zu (sehr > unkorrekten) Wutausbrüchen. Also nur alle Varianten, die das Problem aus einer (für die Mitarbeiter) extrem externen Sichtweise präsentieren. Hautnah und selbst die Folgen spüren tun die das erstmal gar nicht, sondern alles nur als "Gemecker vom Chef". > Ca. alle zwei bis drei Monate schau ich mal über diese Tagebücher, krieg > Magengeschwüre, es gibt mal wieder mehr oder weniger ernste Gespräche, > dann funktionierts wieder. Genau eine Woche lang :-( Wie schon gesagt: dann schau mal jede Woche (oder noch häufiger) über die Tagebücher. Oder frag in der zweiten Woche mal nach, warum diese Mitarbeiter wieder die Doku vernachlässigen, und versuche mit ihnen gemeinsam Wege zu finden, wie sie länger durchhalten. Vielleicht ist die von Dir vorgeschlagene Form auch für sie sehr ungünstig, und eine andere würde ebenfalls ausreichen allerdings viel einfacher für sie sein. > Soweit, so gut. Mein Problem: einige Mitarbeiter tun das einfach nicht, > oder nur extrem unvollständig = unbrauchbar. Sind die wirklich total unbrauchbar, oder nur sehr dünn und nicht in der gewünschten Form? Es kann auch sein, dass der betreffende Mitarbeiter die Lücken gar nicht als so groß sieht (z.B. weil er schon implizit gewisse weiteres mitdenkt, wie "Bei Arbeiten an Modul A müssen auch immer Module B und C berücksichtigt und angepasst werden, also reicht es, wenn ich nur A aufschreibe"). > Kündigungsdrohung ist leider eine leere, weil unsere MA eigentlich einen > sehr guten Job machen, und sehr gut wissen dass sie nicht so einfach > gekündigt werden können. Statt "Kündigung" könnte auch mal die "Straf"zuweisung von ungeliebter Arbeit, etwa Nachträgliches Erstellen der Dokumentation von Mitarbeitern X, Y, Z in Projekten A, B und C, angedacht werden (nach vorheriger Ankündigung). -- Mir klingt die Dokumentation nach etwas, was nach "lästig und unnütz" (aus Sicht der Mitarbeiter) schmeckt. Wenn es dann noch aufwändig wird, und sich als großen Block auftürmt, ist das "blöd". Andererseits: Muss wirklich alles und umfangreich dokumentiert werden? Wie häufig muss auf die Doku den zurückgegriffen werden? Reicht es vielleicht aus, das ganze zwar bruchstückhaft zu sichern, und nur bei Bedarf (dann zeitaufwändig) das ganze nachzurekonstruieren? Einer meiner Kollegen schreibt als Commit-Kommentar sogar nur die Issue-Nummer; was er genau gemacht und warum er es gemacht hat, kann man ja aus seinen Änderungen nachvollziehen (gut, dauert etwas; aber meistens braucht man das ja eh nicht). --- Ein Protokoll lässt sich halt am gemütlichsten erstellen, wenn man es während der Arbeit erstellt, man wenig einbringen braucht und es nicht als aufhaltend empfunden wird. Der Unterschied bei "als aufhaltend empfunden" kann schon sein, ob der Ctrl-PrtSc-Screenshot einfach schon im zweiten Fenster eingefügt werden kann, oder nach dem Crtl-PrtCr ein weiteres Programm geöffnet, dort der Screenshot als Bild erstellt, als Datei abgelegt, im Zielsystem die Datei ausgewählt und hinzugefügt und abschließend wieder das normale Arbeitsprogramm in den Vordergrund geholt werden muss. Das zweite mag vielleicht dreimal so lange dauern, ist aber gefühlte 10mal aufwändiger, und dann macht man sich nicht mehr die Mühe. --- Solche Probleme scheinen mir dann um so häufiger, wenn die Betroffenen kein Gespür für die Auswirkungen haben (etwa weil dies weit außerhalb ihres Arbeitsfeldes liegt). Da kann es helfen, diese mit den Prozess einzubeziehen, wo sie diese Auswirkungen auch selbst miterleben können.
> Sorry, wer von uns hat grad ein problem mit der Realität?
es soll ja eine sachliche Diskussion bleiben?
Irgendwelche tieferen Gründe für Deine ansonsten guten Mitarbeiter muß
es doch geben ???
Oder sind die völlig verblödet?
Berlin-Fanclub schrieb: > ich nicht Stimmt, du bist ja arbeitslos. Berlin-Fanclub schrieb: > aber es unterschiedliche Motivationen und eigentlich sollte > man die kennen ... Als Arbeitnehmer sollte man aber auch die Konsequenzen seiner Handlungen richtig einschätzen können. Und wenn man absichtlich Arbeitsergebnisse verschleiert, sägt man sich den eigenen Ast ab. Berlin-Fanclub schrieb: > Irgendwelche Gründe muß es ja wohl geben, oder? Ja, die habe ich ja schon geschildert. Die Möglichkeit, dass jemand absichtlich seine Arbeit sabotiert, habe ich allerdings erst einmal nicht in Betracht gezogen. Das wäre natürlich auch möglich.
Irgendwie sinkt zur Zeit die Qualität der Beiträge mit steigender Frequenz derselben. Ist jetzt Wochenende und die "Sonntagsfahrer", also alle die nicht selber in einer Firma führende Positionen bekleiden hier ihren Frust rauslassen? Macht doch mal konstruktive neue Vorschläge! Jörg
Achim Hensel schrieb: > Mal wieder zum ersten Post zurück: Gute Idee! > Also nur alle Varianten, die das Problem aus einer (für die Mitarbeiter) > extrem externen Sichtweise präsentieren. Hautnah und selbst die Folgen > spüren tun die das erstmal gar nicht, sondern alles nur als "Gemecker > vom Chef". Nein, nicht wirklich. Wir führen immer wieder Gespräche über die Notwendigkeit dieser Doku, welche sich auf zwei Punkte fokussiert: a) Projektleiter fällt aus (wir verwenden dafür den scherzhaften Begriff "von der Straßenwalze überfahren") und ein Kollege muss übernehmen. Anhand des Tagebuchs sollte der in der Lage sein, einigermaßen 8natürlich mit Reibungsverlusten) weiterarbeiten zu können. b) es kommt zu einer Eskalation seitens des Kunden: Dann ist anhand des Tagebuchs einigermaßen belastbar nachvollziehbar, was wann warum gemacht wurde, wo man sich im kreis gedreht hat, wo welche Informationen eingefordert wurden aber nie gekommen sind oder mehrmals falsch gekommen sind etc. Da im Falle einer solchen Eskalation immer der Projektleiter in der Schusslinie steht, tut er gut daran sich entsprechend abzusichern. Beide Punkte sind allen Mitarbeitern klar, und generell herrscht Konsens, dass und wie die Tagebücher zu führen sind. Es ist sich auch jeder daruber im klaren, dass ihn a) treffen kann (dass er für jemanden anderen einspringen muss) und b) dass er in die Schusslinie kommt. Das ist ja genau der Punkt der mich ratlos macht: jeder sagt "ja wir müssen das machen, das ist sinnvoll und notwendig...", aber keiner sagt "ich kann/will das nicht machen, weil..." > Wie schon gesagt: dann schau mal jede Woche (oder noch häufiger) über > die Tagebücher. Werd ich machen. > Sind die wirklich total unbrauchbar, oder nur sehr dünn und nicht in der > gewünschten Form? entweder zu dünn, oder total unvollständig (Ein Eintrag alle 4 Wochen hilft niemandem) > Mir klingt die Dokumentation nach etwas, was nach "lästig und unnütz" > (aus Sicht der Mitarbeiter) schmeckt. Wenn es dann noch aufwändig wird, > und sich als großen Block auftürmt, ist das "blöd". Ja eh. aber siehe oben: Eigentlich wissen alle warum wir das machen. > Andererseits: Muss wirklich alles und umfangreich dokumentiert > werden? Wie häufig muss auf die Doku den zurückgegriffen werden? > Reicht es vielleicht aus, das ganze zwar bruchstückhaft zu sichern, und > nur bei Bedarf (dann zeitaufwändig) das ganze nachzurekonstruieren? Ja, ich erwarte dass alles relevante dokumentiert wird. Aber eben nicht umfangreich. Zumindest soweit dass ein anderer daraus schlau wird. > Ein Protokoll lässt sich halt am gemütlichsten erstellen, wenn man es > während der Arbeit erstellt, man wenig einbringen braucht und es nicht > als aufhaltend empfunden wird. Genau so sehe ich es auch. ich mach das ganz automatisch, allein weil es für mcih eine Gedankenstütze ist. > Der Unterschied bei "als aufhaltend empfunden" kann schon sein, ob der > Ctrl-PrtSc-Screenshot einfach schon im zweiten Fenster eingefügt werden > kann, oder nach dem Crtl-PrtCr ein weiteres Programm geöffnet, dort > der Screenshot als Bild erstellt, als Datei abgelegt, im Zielsystem die > Datei ausgewählt und hinzugefügt und abschließend wieder das normale > Arbeitsprogramm in den Vordergrund geholt werden muss. Deshalb ist unser "Tagebuch" ein simples Word-Dokument, wo man mit Copy&Paste sowohl SQL-Statements als auch Email-Ausschnitte als auch Screenshots denkbar einfach reinkriegt. > Solche Probleme scheinen mir dann um so häufiger, wenn die Betroffenen > kein Gespür für die Auswirkungen haben (etwa weil dies weit außerhalb > ihres Arbeitsfeldes liegt). Da kann es helfen, diese mit den Prozess > einzubeziehen, wo sie diese Auswirkungen auch selbst miterleben können. Die Kollegen erleben die Auswirkungen, öfter als ihnen lieb ist. Nicht dass wir jetzt erhöhtes Straßenwalzen-Risiko hätten, aber Urlaubsvertretung kommt dauernd vor. Und Ratlosigkeit aufgrund fehlender Doke detto. Aus diesem Grund empfinde ich das Nicht-Dokumentieren nicht nur als Affront gegen mich, sondern auch als extrem unfair den kollegen gegenüber.
Such Dir jemandem im Betrieb als Moderator (zur Vermeidung von Hierarchie-Problemen). Dieser soll den Betroffenen helfen, dass diese selbst Maßnahmen entwickeln, um eine geeignete Dokumentierung/Protokollierung dauerhaft zu gewährleisten. Nach einer Weile die Maßnahmen anhand der Ergebnisse überprüfen, und ggf. ändern/abschaffen/neue finden. -- Schaffe eine Art interne Abnahmeprozess für die Abarbeitung (4-Augen-Prinzip), ähnlich des Tests in der Software-Entwicklung. Mache eine geeignete Doku zu einem Abnahmekriterium. Ein Thema ist erst dann fertig und auslieferungsreif, wenn auch die Doku steht. Die Mehr-Schleifen können am Anfang zu (hoffentlich erwarteten) Verzögerungen führen. Mit der Zeit sollte sich der Aufwand etwas verringern, aber auch mit in der Planung wiederfinden. Eine Qualitätssteigerung sollte niemals als Aufwandsneutral angesetzt werden. -- Konfrontiere die betroffenen Mitarbeiter mit den Auswirkungen. Manche Leute begreifen bestimmte Anforderungen besser und folgen diesen leichter, wenn sie die Konsequenzen "am eigenen Leib" spüren (z.B. mit in der Sitzung sitzen, wo Kunde X wegen Problem Y wettert, welches eigentlich auf sein Konto zuzuschreiben ist, man das aber nur schwer nachweisen kann).
Michael Reinelt schrieb: > a) Projektleiter fällt aus (wir verwenden dafür den scherzhaften Begriff > "von der Straßenwalze überfahren") und ein Kollege muss übernehmen. > Anhand des Tagebuchs sollte der in der Lage sein, einigermaßen > 8natürlich mit Reibungsverlusten) weiterarbeiten zu können. Kauf Straßenwalzen und überfahre Projektleiter. :) Besser: forciere das Problem (zu geeigneten Zeiten, wenn die Auswirkungen vertretbar sind). Ziehe einen Projektleiter ab und gibt ihm ein neu hereinkommendes Projekt. Mache aus einem "Ja, kann mich treffen." ein "Das wird mich treffen!" Suche Dir die richtigen Leute und Projekte sehr sorgfältig aus, das ist ja zum Lehren. > b) es kommt zu einer Eskalation seitens des Kunden: Dann ist anhand des > Tagebuchs einigermaßen belastbar nachvollziehbar, was wann warum gemacht > wurde, wo man sich im kreis gedreht hat, wo welche Informationen > eingefordert wurden aber nie gekommen sind oder mehrmals falsch gekommen > sind etc. Da im Falle einer solchen Eskalation immer der Projektleiter > in der Schusslinie steht, tut er gut daran sich entsprechend > abzusichern. Auch hier muss ja nicht unbedingt die Situation nur durch die Eskalation seitens eines Kunden ausgelöst werden. Wenn es gerade etwas ruhiger ist, kann ja mal der Ernstfall als Manöver durchgespielt werden: Könnte aufgrund der vorliegenden Doku ein gedachter Einwand eines Kundens abgewiesen werden?
kopfkratz Was ist denn nun das eigentliche Problem ? Im Projektmanagement geht man Top-Down vor, zuerst wird der Kunde nach seinen Vorstellungen befragt und das in einem Lastenheft erfaßt. Nachdem klar ist was das Ziel des Kunden ist geht man hin und konkretisiert das Lastenheft zum Pflichtenheft, wo detailliert beschrieben wird welche Umgebung, welche Software und welche Schnittstellen zu verwenden sind. Wenn man das nun flexibel haben möchte definiert man entsprechende Schnittstellen und Erweiterungen. Zur internen Dokumentation der daraus resultierenden Programme gibt man den Entwicklern entsprechende Vorgaben, z.B. das wie in doxygen zu den einzelnen Klassen eine detaillierte Definition als Kommentar vorgeschrieben ist in dem alle notwendigen Parameter und die Funktion der Klasse beschrieben sind. Man könnte nun sogar soweit vorarbeiten indem man für die Programmierer exakt diese doxygen Kommentare schreibt und sich der Programmierer nur um die Umsetzung kümmert. Wenn man das zentral erledigt hat das zwei Vorteile, erstens ist es immer konsistent da es von einer Quelle kommt, zweitens gibt es für den Programmierer keinen Interpretationsspielraum wegen Parametern oder Rückgabewerten. Wichtig ist das im Pflichtenheft alles detailliert erfaßt ist und in der Planung auch Ausstiegspunkte mit Testkriterien festgehalten sind die beide Parteien verbindlich anerkennen. Und meistens liegt es daran das die Auftraggeber selber das offensichtliche übersehen und nicht diejenigen mit einbeziehen die nachher täglich mit dem Programm arbeiten müssen. Nehmen wir als Beispiel eine Arztpraxis, man kann nun eine Eingabemaske in Tabellenform für das Rezept/Überweisung/usw. anlegen oder man scannt einfach eine Rezept/Überweisung ein und nimmt das als Eingabeformular. Was wäre da sinnvoller ? Um wieder auf das Programmieren zu kommen, verbindliche Kommentar was denn eine Funktion/Berechnung konkret tut sollten vorgeschrieben sein, genauso wie selbsterklärende Variablen-, Klassen- und Funktionsbezeichnungen.
> Ja, ich erwarte dass alles relevante dokumentiert wird. Aber eben nicht > umfangreich. Zumindest soweit dass ein anderer daraus schlau wird. aha - das ist allerdings sehr dehnbar je nach Kunden? Da wäre dann ein Musterbeispiel für Deine Mitarbeiter sinnvoll.
kopfkratzer schrieb: > kopfkratz > Was ist denn nun das eigentliche Problem ? > Im Projektmanagement geht man Top-Down vor, zuerst wird der Kunde nach > seinen Vorstellungen befragt und das in einem Lastenheft erfaßt. In manchen Situationen wird das aber schwierig: Vor allem, wenn der Kunde noch gar keine konkreten Vorstellungen hat, was er den eigentlich will und braucht, weil die gesamte Thematik ganz neu und ungewohnt ist. Da kann es passieren, dass sich Anforderungen und/oder Wünsche erst im Laufe des Betriebs herausstellen, weil der Kunde sich irgendetwas anderes vorgestellt hat oder plötzlich auf neue Ideen kommt, oder Probleme mitgelöst werden sollen, die eigentlich ganz woanders liegen, oder Eierlegende Wollmilchsäue vom Kunden beim ersten Gespräch gefordert wurden. Das Problem bei Software ist vor allem, dass auch für Ausnahmen Regeln definiert werden müssen. Kann ich mir bei der Einführung einem zentralen DMS sehr gut vorstellen. :( Welche Schlagworte, festgelegter Katalog oder freie Auswahl? Welche Beschreibungsfelder? Wie soll eine Hierarchie erstellt werden (vor allem bei den entgegengesetzten Wünschen von Abteilung A und Büro B)? Sind die überdetailierten Kategorisierungen von Person P wirklich notwendig, vor allem da Q damit nichts anfangen kann? Da geht es eben auch um einen gefühlten Eingriff in die eigene Organisation jedes Vorgesetzten und Mitarbeiters.
Achim Hensel schrieb: > kopfkratzer schrieb: >> kopfkratz >> Was ist denn nun das eigentliche Problem ? >> Im Projektmanagement geht man Top-Down vor, zuerst wird der Kunde nach >> seinen Vorstellungen befragt und das in einem Lastenheft erfaßt. > > In manchen Situationen wird das aber schwierig: Vor allem, wenn der > Kunde noch gar keine konkreten Vorstellungen hat, was er den eigentlich > will und braucht, weil die gesamte Thematik ganz neu und ungewohnt ist. > Da kann es passieren, dass sich Anforderungen und/oder Wünsche erst im > Laufe des Betriebs herausstellen, weil der Kunde sich irgendetwas > anderes vorgestellt hat oder plötzlich auf neue Ideen kommt, oder > Probleme mitgelöst werden sollen, die eigentlich ganz woanders liegen, > oder Eierlegende Wollmilchsäue vom Kunden beim ersten Gespräch gefordert > wurden. Deswegen definiert man ja die genannten Schnittstellen und Erweiterungen. Wenn der Kunde nicht weiß was er will und vor allem was er braucht bringt einfach darauflos Prototypen u.ä. gar nichts. Dann muß man halt die Gummihandschuhe anziehen und die Würmer einzeln aus der Nase des Kunden ziehen. Achim Hensel schrieb: > Das Problem bei Software ist vor allem, dass auch für Ausnahmen Regeln > definiert werden müssen. Das betrifft die genannte Planung in der Ausstiegspunkte und Prüfkriterien festgelegt sein müssen. Das hat alles NICHTS mit Programmierung zu tun, das ist Projektmanagement ! Ob es sich dabei um eine Brücke, eine Straße, Kraftwerk oder Babynahrung handelt, das vorgehen ist immer gleich. Achim Hensel schrieb: > Da geht es eben auch um einen gefühlten Eingriff in die eigene > Organisation jedes Vorgesetzten und Mitarbeiters. Darum geht es ja im Management, der Manager/Abteilungsleiter/Leiter/Chef ist die Schnittstelle zwischen der produzierenden Abteilung, dem Kunden und der Buchhaltung. Ich kenne mehr als genügend Beispiele wo das eben nicht korrekt gegeben ist. Dann passiert es z.B. das Vertriebi-Y bei Kunden-Z etwas verkauft was nicht da ist und dann Abteilungsleiter-X das bei RD einwirft. RD erledigt den Job und Kunde-Z ist super zufrieden, Vertriebi-Y hat seine Prämie und in der Buchhaltung gibt's rote Zahlen. Auch immer wieder gesehen, Betrieb läuft ohne Reibungsverluste, Topmanager-K liest was tolles im Managermagazin und bringt das in der nächsten Besprechung zur Rede und labert alle an die Wand. Fazit laufender Betrieb wird wegen angeblichen 5% mehr Gewinn/Effektivität/o.ä. komplett gestoppt, weil nun das tolle Ding eingeführt wird. Nach einem Jahr roter Zahlen findet man folgende Seite: http://scheissprojekt.de/ Um nochmal auf das eigentliche Problem zurück zu kommen: Klare Vorgaben seitens des Managements sind immer der bessere Weg als eine Laissez-faire-Politik, wenn es dann irgendwo klemmt kann man sich einfach einen Tag zusammensetzen und aufschreiben was denn nun der kleinste gemeinsame Nenner ist. Also einfach mal hinsetzen und sich eine Vorgabe überlegen, doxygen ist da schon der richtige Ansatz, es fehlt aber auch ein Verwaltungssystem für das Projektmanagement selber. Wenn man schön alles erfaßt und sichert was bei den Kundengesprächen so auf dem Tisch war spart man sich später länger Erklärungen vor dem Kadi wenn es gegen die Wand gefahren ist weil Kunde partout nicht mit dem Ausstieg einverstanden war bzw. nichts konkretes beigetragen hat. Aus den Dokumenten lassen sich dann auch recht einfach passende Benutzeranleitungen bauen, denn dazu dient ja der Kundenkontakt herauszufinden was der Kunde wie umsetzen will. Man kann sagen das bei einem Projekt gut zwei drittel darin besteht genügend Gummihandschuhe in diverse Nasen zu versenken um die Würmer alle zu finden als nachher das konkrete Projekt gezielt umzusetzen. Das wird leider in den meisten Fällen vor allem bei EDV nicht beachtet. Schönes Beispiel wie man es auf gar keinen Fall machen darf ist der BER. Keine Dokumentation, keine konkreten Pflichtenhefte, keine Kontrollen und was ist deswegen passiert ?
Antimedial schrieb: > Bei einem anderen Zweierteam ist es tatsächlich so, dass der eine der > kreative Entwickler ist, der die technischen Probleme löst, während der > andere den ganzen Kram dokumentiert und das Requirement Engineering > beisammen hält. Das ist exakt das, was NICHT gefragt ist und was auch nicht der Sinn des RE ist! Leider scheint das aber die Folge der in den Firmen verbreiteten QM-Politik und der Reaktion einiger Entwickler darauf zu sein. Ich nenne das Duales System. Entwicklen und parallel davon QM erfüllen. Die Doku ist aber nicht primär dafür da, dass irgendwann mal einer kommt und es formell prüft oder einer mal weiterentwickelt - das sind sekundäre Effekte - sondern dass man selber geradaus entwickelt und vor allem Teamarbeit möglich wird! In dem Zusammenhang möchte ich dann mal fragen, wie es sein kann, dass der o.g. "kreative" Entwickler überhaupt weiss, wonach er arbeiten muss und wie er das strukturiert und mit anderen koordiniert. Diese "kreative" Arbeitsweise ist letztlich nicht anderes, als Einzelkämpfer-Chaos-im-Kopf-Bewältigung indem man dranstürmt und beim Arbeiten ändert und sich überlegt, was man macht. Antimedial schrieb: > Es gibt immer noch Leute, die exzellente > Arbeit abliefern, aber sich mit der externen Dokumentation schwer tun. Alles erlernbar. Absolut erlernbar! Wer komplexe Software scheiben kann, der kann sie auch *be*schreiben. > Der Code wird meistens noch gut dokumentiert, aber Dinge wie Requirement > Engineering und alles, was aus der QM-Welt kommt, wird es eben > schwierig. Wieder zwei schwere Denkfehler: 1) Erstmal kommen requirements nicht von der QM. Von dort kommt der Prozess und die Vorgabe, a) DASS so formell und b) WIE genau vorzugehen ist. R's kommen aus verschiedenen Ebenen, sei es die GL, das PM und/oder physikalischen Randbedingungen oder auch Normen. All das muss berücksichtigt werden. Soweit ist das aber sicher klar, meine ich. 2) RE ist etwas, was der Entwickler tun muss. Wie bitte entwickelt denn derjenige überhaupt, wenn er kein RE betreibt? Faktisch betreibt doch jeder Ingenieur RE, auch wenn er es formell nicht so nennt. Der Punkt ist nur der, dass Viele glauben, alles im Kopf managen und intuitiv entscheiden zu könnnen, was nicht der Fall ist, sobald die Projekte grösser werden und von mehreren zu bearbeiten sind. Richtig gute Produkte sind das Ergebnis von mehreren Leuten, die Input geliefert haben und nicht das Ergebnis von einem Bastler, der vor sich hinwerkelt. Das "kreative" Gebastel klappt nur daheim, wenn man sich selber die Vorgaben, die Randbedinungen und die Termine macht und bei sehr kleinen überschaubaren Projekten.
E. M. schrieb: > allerdings scheinen hier doch sehr viele Hacker rumzuhähngen, die den > Sinn ihres Daseins darin sehen, ihr Knowhow nicht abzugeben sondern in > die Produkte zu injizieren um sich unkündbar zu machen. Falsch gedacht und lies Dir mal lieber vorher die Beiträge durch. Hier wurde schon mehrmahls auf die Notwendigkeit hingewiesen, etwas grundsätzlich an der bisherigen Struktur zu ändern. Aber das ist ja laut TO mal nicht notwenig, mal zu übertrieben und ein anderes mal komplett daneben. uswusf. > Von diesen "Programmieren" braucht die Industrie aber keinen einzigen. > Erstens nicht, weil sie auf eigene Rechnung arbeiten und zweites nicht, > weil ihre Ergebnisse nicht zu gebrauchen sind. > > Bei guten Projektleitern und QM-Verantwortlicnen gibt es sowas nicht. > > Raus mit den Hackern! Wie gesagt, lies Dir doch mal die Beiträge hier durch. Aber spätestens, nach diesem Absatz habe ich schon eine gewisse Vorstellung davon, auf welche Art und Weise Du Dir die Deine Brötchen verdienst. P.S.: ich kenne den Nutzen sinnvoller und tiefergehender Dokumentationen
:
Bearbeitet durch User
Jürgen Schuhmacher schrieb: > ie Doku ist aber nicht primär dafür da, dass irgendwann mal > einer kommt und es formell prüft oder einer mal weiterentwickelt In manchen Firmen ist das aber genau so. Jürgen Schuhmacher schrieb: > In dem Zusammenhang möchte ich dann mal fragen, wie es sein kann, dass > der o.g. "kreative" Entwickler überhaupt weiss, wonach er arbeiten muss > und wie er das strukturiert und mit anderen koordiniert. Auch der "kreative" Entwickler kann strukturiert arbeiten, auch wenn das von außen manchmal nicht so aussieht. Der "kreative" Entwickler arbeitet mehrdimensional und nichtlinear. Die Fähigkeit, diese Denkweise zu strukturieren unterscheidet ein kreatives Wesen von einem Chaoten. Dazu kommt noch die Teamdynamik. Wenn die Chemie auf persönlicher Ebene stimmt, ist ein Team aus kreativen Entwicklern und strukturierten Dokumenteuren/Projektleitern/Moderatoren unschlagbar. Jürgen Schuhmacher schrieb: > 1) Erstmal kommen requirements nicht von der QM. Von dort kommt der > Prozess und die Vorgabe, a) DASS so formell und b) WIE genau vorzugehen > ist. R's kommen aus verschiedenen Ebenen, sei es die GL, das PM und/oder > physikalischen Randbedingungen oder auch Normen. All das muss > berücksichtigt werden. Soweit ist das aber sicher klar, meine ich. Nur hat sich gezeigt, dass dieser Top-Down-Ansatz in der Praxis nicht funktioniert. Deshalb gibt es inzwischen ja agile Ansätze, die oftmals viel besser funktionieren. Jürgen Schuhmacher schrieb: > Wie bitte entwickelt denn > derjenige überhaupt, wenn er kein RE betreibt? Agile Entwicklung. Sie erfasst auch Anforderungen, gibt sich allerdings nicht dem Irrglauben hin, dass Requirements etwas unveränderbares, Gott gegebenenes ist. Jürgen Schuhmacher schrieb: > Richtig gute > Produkte sind das Ergebnis von mehreren Leuten, die Input geliefert > haben und nicht das Ergebnis von einem Bastler, der vor sich hinwerkelt. Richtig gute Produkte sind aber auch nicht das Ergebnis von formalem Requirement Engineering. Jürgen Schuhmacher schrieb: > Das "kreative" Gebastel klappt nur daheim, wenn man sich selber die > Vorgaben, die Randbedinungen und die Termine macht und bei sehr kleinen > überschaubaren Projekten. Das ist etwas, was sich die QM-Top-Down-Spinner in Konzernen erzählen. Die Wahrheit ist, dass viele hoch innovative Produkte nur durch freies, kreatives Experimentieren (herabwürdigend "Gebastel" genannt) entstehen.
kopfkratzer schrieb: > Wenn man schön alles erfaßt und sichert was bei den Kundengesprächen so > auf dem Tisch war spart man sich später länger Erklärungen vor dem Kadi > wenn es gegen die Wand gefahren ist weil Kunde partout nicht mit dem > Ausstieg einverstanden war bzw. nichts konkretes beigetragen hat. Genau. Und was macht man dann, wenn einige Mitarbeiter beim "schön alles erfassen und sichern" eben nicht mitziehen? Das ist der Punkt, um den es in diesem Thread eigentlich geht. kopfkratzer schrieb: > Deswegen definiert man ja die genannten Schnittstellen und > Erweiterungen. > Wenn der Kunde nicht weiß was er will und vor allem was er braucht > bringt einfach darauflos Prototypen u.ä. gar nichts. > Dann muß man halt die Gummihandschuhe anziehen und die Würmer einzeln > aus der Nase des Kunden ziehen. Hier geht es aber nicht um ein rein Kundenspezifisches Von-Grund-auf-Neues-Projekt, sondern um "Standardprodukt plus Customizing". Und wenn der Kunde das Produkt nicht kennt, dann kann er gar nicht wissen, welche Ausprägung und Erweiterungen, Anpassungen etc. er genau braucht. Deswegen neigt er dazu, eine eierlegende Wollmilchsau haben zu müssen. Da hilft es manchmal, ihm erstmal das (bereits fertige!) Standardprodukt vorzusetzen, mit einigen Einstellungen, die in seine Richtung gehen. Mit diesem Stand kann er erstmal Erfahrungen sammeln. Und auf Grundlage dieser Erfahrungen kann er dann viel besser entscheiden, was er wirklich braucht, was er sich dann doch spart, und wovon er vorher gar nicht geahnt hat, dass er es braucht.
Berlin-Fanclub schrieb: >> Ja, ich erwarte dass alles relevante dokumentiert wird. Aber eben nicht >> umfangreich. Zumindest soweit dass ein anderer daraus schlau wird. > aha - das ist allerdings sehr dehnbar je nach Kunden? Nein, nicht nach Kunde, sondern eher nach MA. Manche führen detaillierter Buch, manche weniger, manche (fast) gar nicht. ich möchte ein Mindestmaß. > Da wäre dann ein Musterbeispiel für Deine Mitarbeiter sinnvoll. Deren gibt es zur Genüge, und die sind auch bekannt. @Kopfkratzer: Das Pflichtenheft/Lastenheft-Spiel spielts bei uns nicht (hab ich weiter oben dargelegt warum nicht). Und doxygen schon gar nicht (nochmal - wir sind keine SW-Entwickler). Der von antimedial beschriebene "agile" Ansatz triffts viel mehr... > Wenn der Kunde nicht weiß was er will und vor allem was er braucht >bringt einfach darauflos Prototypen u.ä. gar nichts. Doch genau das bringts! Der Trick liegt in unserer Erfahrung, damit daraus nicht ein "einfach drauflos" Prototyp wird. In der Regel treffen wir da sehr gut
Michael Reinelt schrieb: > @Kopfkratzer: Das Pflichtenheft/Lastenheft-Spiel spielts bei uns nicht > (hab ich weiter oben dargelegt warum nicht). Und doxygen schon gar nicht > (nochmal - wir sind keine SW-Entwickler). Der von antimedial > beschriebene "agile" Ansatz triffts viel mehr... Ja, das klingt schon sehr nach agiler Entwicklung, was ihr da macht. Daraus kann man sich auch ein paar Methoden entleihen, um die Probleme von einem organisatorischen Standpunkt aus anzugehen. Die menschliche Seite sollte man aber trotzdem nicht vernachlässigen.
Antimedial schrieb: > In manchen Firmen ist das aber genau so. ich weiss:-) > Der "kreative" Entwickler arbeitet mehrdimensional und nichtlinear > Dazu kommt noch die Teamdynamik Schon richtig, aber je komplexer die Entwicklung, desto wichtiger ist Kommunikation und die kann nicht allein verbal erfolgen. Die Situation die wir täglich erleben ist doch die, dass es massenweise Besprechungen gibt, die wenig Wert haben weil parallele Entscheidungsprozesse laufen, die direkt Widersprüche aufwerfen. > Nur hat sich gezeigt, dass dieser Top-Down-Ansatz in der Praxis nicht > funktioniert. Deshalb gibt es inzwischen ja agile Ansätze, die oftmals > viel besser funktionieren. Es ist nicht notwendigerweise so, dass alles in einem Einmalprozess Top-Down gemacht wird. Im Gegenteil: Gerade eine saubere Planung ermöglicht, rasche und effektve Besprechungen, Planungen und Entscheidungen, wenn es ums Ändern geht. > Richtig gute Produkte sind aber auch nicht das Ergebnis von formalem > Requirement Engineering. Man muss nur entsprechende mile stones einhalten: Die R's, die von aussen eingetrieben werden, müssen eben stehen, bevor angefangen wird, umzusetzen. Und sie müssen GUT stehen. Und je nach Kompetenz derer, die formulieren, ist das eben mehr oder weniger brauchbar. Das System ist weniger das Problem: Es hapert an der Umsetzung! > Das ist etwas, was sich die QM-Top-Down-Spinner in Konzernen erzählen. > Die Wahrheit ist, dass viele hoch innovative Produkte nur durch freies, > kreatives Experimentieren (herabwürdigend "Gebastel" genannt) entstehen. Wir müssen hier mal differenzieren: Was Du hier beschreibst, ist forschendes Entwicklen mit entsprechenden Freiräumen, als ohne grosse formelle Vorgaben. Das dies zu Ergebnissen und Ideen führt wiederspricht nicht der Notwendigkeit einer strukturierten Produktentwicklung. Es hat ja mithin niemand festgelegt, dass dies strictly top down sein muss. Das tun nur die mit vereinfachter Sicht auf die Dinge, die mangels technischer Detailkenntnisse einfache PowerPoint-Methoden propagieren. Das muss aber nicht so sein. Kommen wir aber nochmal zum Thema, dem wie und wann Dokumentieren: Unabhängig davon, wer oder wieviele an einem Subthema werkeln, geht es nur mit einer gemeinsamen Zieldefinition. Und die ist - weil mehrdimensional (Dein Argument) - aufschreibepflichtig. Ich sehe keinen Mangel daran, sich hinzusetzen und saubere Konzepte der Lösung aufzusetzen und diese kommunizierbar zu machen, denn nur so sind Zeiten, Kosten und Kompatibilität zu anderen Subthemen abschätzbar und zu managen. Die ausgeklügelte Doku vorher ist die geeignete Gesprächs- und Planungsgrundlage. > Agile Methoden Richtig, aber auch das ist eine formelle Vorgehensweise, die Regeln unterliegt, denen alle folgen müssen und die Doku erfordert.
:
Bearbeitet durch User
Jürgen Schuhmacher schrieb: > Schon richtig, aber je komplexer die Entwicklung, desto wichtiger ist > Kommunikation und die kann nicht allein verbal erfolgen. Die Situation > die wir täglich erleben ist doch die, dass es massenweise Besprechungen > gibt, die wenig Wert haben weil parallele Entscheidungsprozesse laufen, > die direkt Widersprüche aufwerfen. Das ist aber rein eine Disziplinfrage und nicht der von klassischen Entwicklungsmodellen oder agiler Entwicklung. Jürgen Schuhmacher schrieb: > Es ist nicht notwendigerweise so, dass alles in einem Einmalprozess > Top-Down gemacht wird. Im Gegenteil: Gerade eine saubere Planung > ermöglicht, rasche und effektve Besprechungen, Planungen und > Entscheidungen, wenn es ums Ändern geht. So ist aber der Wunsch der QM-Heinis, die das Requirement Engineering als das Maß der Dinge verkaufen wollen. Jürgen Schuhmacher schrieb: > Man muss nur entsprechende mile stones einhalten: Die R's, die von > aussen eingetrieben werden, müssen eben stehen, bevor angefangen wird, > umzusetzen. Und sie müssen GUT stehen. Genau da sind wir wieder am sturen Top-Down-Ansatz. Jürgen Schuhmacher schrieb: > Das > tun nur die mit vereinfachter Sicht auf die Dinge, die mangels > technischer Detailkenntnisse einfache PowerPoint-Methoden propagieren. > Das muss aber nicht so sein. So ist es aber bei den Leuten, die diese Entwicklungsmethoden propagieren. Jürgen Schuhmacher schrieb: > Unabhängig davon, wer oder wieviele an einem Subthema werkeln, geht es > nur mit einer gemeinsamen Zieldefinition. Und die ist - weil > mehrdimensional (Dein Argument) - aufschreibepflichtig. Da ist der Knackpunkt. Viele Probleme sind so mehrdimensional, das man sie nicht in vertretbaren Aufwand schriftlich erfassen kann. Zumindest nicht im Vorfeld. Jürgen Schuhmacher schrieb: > Die ausgeklügelte Doku vorher ist die geeignete Gesprächs- > und Planungsgrundlage. Ein Konzept kann man auch knapp und effizient beschreiben. Ein Blockschaltbild reicht in vielen Fällen für einen kompetenten Entwickler, um beginnen zu können.
Ich kann meinen Vorrednern die die Dokumentation gerade im Softwarebereich bemängeln, nur Recht geben! Unabhängig von Arbeits und Entwicklungsmethoden ist es unabdingbar, seine Arbeit zu planen und zu strukturieren. Wer nur aus der Hand und dem Kopf werkelt, bringt nur das hin, was er selber kann und ist nicht der Lage andere in sein Denken zu involvieren. Das aber ist der entscheidende Schlüssel zum Teamerfolg. Anspruchsvolle Aufgaben lassen sich nur so bewältigen. Und jetzt mal Hand aufs Herz: Wer hat nicht schon Software gesehen, die er umarbeiten musste und sich an der falschen und nicht vorhandenen Doku gestossen? Wer hat nicht schon Anpassungen machen müssen, weil ein Teammitglied irgendwas zusammengestöpselt hat und die Vorgaben, die er indirekt vorgenmmen hat, nicht zu der eigenen Modulstrategie passten? In aller Regel ist es doch so, dass eher zu wenig gemacht wird, als zuviel! In Deutschland herrscht Dokumentationsmangel!
> Wer hat nicht schon Anpassungen machen müssen, weil ein Teammitglied > irgendwas zusammengestöpselt hat und die Vorgaben, die er indirekt > vorgenmmen hat, nicht zu der eigenen Modulstrategie passten? ganz einfache Lösung: Teammitarbeiter abmahnen und wenn das nicht fruchtet Kündigung und Neueinstellung ... jeder ist ersetzbar.
> In Deutschland herrscht Dokumentationsmangel!
das ist auch eher eine Arbeit für den Vorgesetzten - soll ich auch noch
als schlechtbezahlter Angestellter meinen Nachfolger ausbilden, ne
Danke.
Berlin-Fanclub schrieb: > das ist auch eher eine Arbeit für den Vorgesetzten Unsinn. > - soll ich auch noch als schlechtbezahlter Angestellter meinen Nachfolger > ausbilden, ne Danke. Was hat das eine mit dem anderen zu tun? Manche wollen anscheinend der Nachwelt nichts an Informationen hinterlassen, sind aber selber froh über jedes bisschen an Doku, das die Vorgänger verfasst haben. Das passt logisch nicht zusammen. Da braucht man kein Hochschulstudium, um das zu verstehen.
@ Berlin-Fanclub (Gast) >ganz einfache Lösung: >Teammitarbeiter abmahnen und wenn das nicht fruchtet Kündigung und >Neueinstellung ... jeder ist ersetzbar. Die Androhung der "Todesstrafe" muss das allerletzte Mittel sein, denn sonst hat man als Führungskraft versagt. Dann dieses Mittel ist ein reines Druckmittel, aber keine Überzeugung. >> In Deutschland herrscht Dokumentationsmangel! >das ist auch eher eine Arbeit für den Vorgesetzten - Blödsinn. >soll ich auch noch >als schlechtbezahlter Angestellter Du klingst eher nach schlechter Angestellter. Die Bezahlung orientiert sich daran. >meinen Nachfolger ausbilden, ne Eben solche Leute braucht keiner. Du wärst der Erste auf der Abschußliste.
einfach die Mitarbeiter in einem Leistungsdialog damit nerven, dass das genauso zu seinem Job gehört. Da muss man einfach penetrant sein und auch nach Gründen fragen, wieso der Mitarbeiter das nicht so macht, wie von ihm gefordert. Es ist sein Job bzw. ein Teil davon.
> einfach die Mitarbeiter in einem Leistungsdialog damit nerven, dass das > genauso zu seinem Job gehört. Da muss man einfach penetrant sein und > auch nach Gründen fragen, wieso der Mitarbeiter das nicht so macht, wie > von ihm gefordert. da das ja nur einen Teil der Mitarbeiter betrifft, könnte ich mir auch gut vorstellen, daß die innerlich schon gekündigt haben ... oder die sind wirklich zu doof und wollen Chefe absichtlich foppen. Irgendwelche Verhaltensgründe muß es ja wohl geben? Ich könnte mir auch gut Überforderung vorstellen, immer noch mehr "kleine" Aufgaben erfüllen, da schaltet doch jeder irgendwann auf Standbye und sagt sich, ja,ja, müssen wir tun. > Die Androhung der "Todesstrafe" muss das allerletzte Mittel sein, denn > sonst hat man als Führungskraft versagt. typisch Deutschland; anderswo ist eine Kündigung / Anstellung ein ganz normaler Vorgang ... hier nicht. > Blödsinn. Ist schon klar, daß das Aufgaben delegieren grenzenlos ist. > Du klingst eher nach schlechter Angestellter. Die Bezahlung orientiert > sich daran. Richtig, die Motivation steigt mit der Bezahlung und wenn die niedrig ist, dann mache ich auch nur das was notwendig ist ... wie jeder Beamter ja auch und der bekommt mehr Kohle. Bonusleistungen kosten Extra. Du darfst Dich aber gerne als "gut" oder Held der Arbeit fühlen, mehr Geld bzw. Freizeit bekommst Du deshalb nicht. > Eben solche Leute braucht keiner. Du wärst der Erste auf der > Abschußliste. das ist mir ziemlich egal, schlechtbezahlte Arbeit kann ich überall finden und die anderen Jobs sind sowieso schon vergeben ... an den Weihnachtsmann habe ich auch mal geglaubt, aber die Zeiten sind lange vorbei.
> Und jetzt mal Hand aufs Herz: Wer hat nicht schon Software gesehen, die > er umarbeiten musste und sich an der falschen und nicht vorhandenen Doku > gestossen? das Ganze muß ja auch schnell gehen, da hat man keine Zeit sich großartig mit Doku aufzuhalten, nur damit das auch jeder Idiot blickt. Wenn die Doku falsch war, noch schlimmer - dann mußte ganz schnell irgendwas aufs Papier gebracht werden nur um des Papieres willen. Hinzu kommt auch, daß jeder ein unterschiedlichen Verständnis hat - dann müßte dumpfbackenmäßig jede Kleinigkeit dokumentiert werden, damit das auch irgendein Umschüler rallt. Sowas kostet Zeit ohne Ende, weil einem selbst die Sache völlig klar ist (und genau das dokumentiert man dann auch nicht!) ... nicht jeder ist ein guter Lehrer, Doku ist was für Leute mit pädagogischen Background.
Antimedial schrieb: > Die Wahrheit ist, dass viele hoch innovative Produkte nur durch freies, > kreatives Experimentieren (herabwürdigend "Gebastel" genannt) entstehen. "Gute" Produkte sind vor allem "verkaufsfähige" und die entstehen nicht durchs Experimentieren, sondern dadurch, dass auch Kostenthemen, Machbarkeit und Produzierbarkeit in die Entwicklung mit einfließen und diese Informationen zu koordinieren und aufzubieten ist die eigentliche Leistung. Ohne das sinnvoll niederzulegen, geht da Garnichts. Der eine kreative Entwickler ist schon lange nicht mehr gefragt, weil alles, was einer allein im Kopf erdenken und durchplanen kann, bereits lange existiert. Komplexe Projekte gedeihen im Team und da ist Kommunikation das Entscheidende. Information richtig und verständlich aufzubereiten, ist genau so nötig, wie sie zu erzeugen und das macht den guten Mann aus. Erst das macht ein Projekt auch planbar, beurteilbar und durchführbar. Wenn es im Rahmen der Durchführung dann zu Problemen kommt, liegt das praktisch immer daran, dass sich einzelne querstellen und nicht mitspielen und ihr eigenes Süppchen kochen.
E. M. schrieb: > [1. Abschnitt] gefällt mir sehr. > Der eine kreative Entwickler ist schon lange nicht mehr gefragt, Ja. > weil alles, was einer allein im Kopf erdenken und durchplanen kann, > bereits lange existiert. Nein. Weil kaum eine Firma sich das noch leisten kann, weil man nicht mit Sicherheit weiß, was dabei heraus kommt. Unter anderem bei Bosch gab es einmal den Ansatz, dass jeder Mitarbeiter einen kleinen Teil seiner Zeit bewusst experimentieren soll. > Komplexe Projekte gedeihen im Team und da ist Kommunikation das > Entscheidende. Projekte gedeihen, wenn die Aufgabenverteilung klar definiert und die Definition immer wieder verfeinert wird. Komplexe Projekte gedeihen in Hierarchien. Kommunikation ist ein notwendiges Übel. Sie artet aus, wenn der Weisungsbefugte keine Ahnung von seinem Team, von Führung oder keine Ahnung von der Materie hat. Dann bekommt der Weisungsbefugte alles vorgekaut aber das ist eine optimierbare Kostenkomponente. Die einzige großzügig durchzuführende Kommunikation ist das Verhandeln mit dem Kunden. > Wenn es im Rahmen der Durchführung dann zu Problemen kommt, liegt das > praktisch immer daran, dass sich einzelne querstellen und nicht > mitspielen und ihr eigenes Süppchen kochen. Wohl kaum. Was ist denn ein Problem? Es gibt "verborgene Aufwände" und Änderungen. Für beides kann man Prozesse einführen und wenn die funktionieren, braucht man nicht bei jedem Problem erneut hektisch "herum zittern". Dann wird im Nachhinein auch transparent, ob fachlich die richtigen Entscheidungen getroffen wurden.
Ich hab auch mal ein kleines Team in Sachen Dokumentation beraten, inklusive Geschaeftsfuehrung. Am Wichtigsten. Jeder muss schnell ersetzbar sein, durch seinen Stellvertreter. Auch der Geschaeftsfuehrer, in diesem Fall durch seinen Sohn. Daher muss alles transparent dokumentiert sein. Seien das nun Treffen mit Kunden, Verhandlungen, Modul Spezifikationen, Modultests, Anforderungsaenderungen, Kundenwuensche, .. Schnell bedeutet je nachdem eine Woche, ein Monat. Wenn ein Neuer sich einarbeiten muss und 6 Monate braucht, ist der Laden schon geschlossen worden. Im besseren Fall ist ein Ausfall nur temporaer, im schlechteren Fall ein Totalausfall. Es kann alles passieren, mit Ankuendigung, oder ohne. Dabei ist anzumerken, das Team war extrem erfolgreich, eine Marktluecke. Da kamen Millionen rein, die Resourcen waren alle da. Ausser Zeit. Ihre Spezialitaeten waren wurze Lieferfristen und Flexibilitaet. Jede Anlage war kundenspezifisch. Das hat dann eingeleuchtet. Wie erfolgreich die Umsetzung war, weiss ich leider nicht. Auch wichtig .. keiner musste Angst haben aus Kostengruenden wegoptimiert zu werden.
Jetzt N. schrieb: > Das hat dann eingeleuchtet. Wie erfolgreich die Umsetzung war, weiss ich > leider nicht. Du hast also kein Feedback, ob Deine Beratung was genutzt hast? Wie willst Du wissen, ob Dein Ansatz richtig war?
Hallo Udo, Udo S. schrieb: > Einen Anreiz dafür schaffen, und zwar eher einen positiven als einen > negativen. > Zum Beispiel. Für gute Führung des Tagebuchs gibt es am Jahresende einen > Tausender als Extrabonus. > Pro Monat ungenügender Führung des Tagebuchs werden davon 200 abgezogen. > > Das Problem ist wie schaffst du eine objektive von möglichst allen > akzeptierte Bewertung was eine "gute Führung des Tagebuchs" ist und was > nicht. Entschuldige bitte, aber der Motivationseffekt von Geld wird gemeinhin stark überschätzt. Das funktioniert schon bei großen Gehaltserhöhungen und hohen Boni nicht, aber bei so überschaubaren Summen in ferner Zukunft dürfte der Effekt solcher Motivationsversuche nahe null sein -- wenn das nicht sogar kontraproduktiv ist, wenn de Mitarbeiter den Eindruck gewinnt, sich durch den Verzicht auf die paar Cents, die ihm am Ende übrigbleiben würden, von seinen Pflichten zur Dokumentation gefühlt "freikaufen " kann. Liebe Grüße, Karl
> Du hast also kein Feedback, ob Deine Beratung was genutzt hast? > Wie willst Du wissen, ob Dein Ansatz richtig war? Eigentlich wurden nur neue Gruende, resp Motivation zur Dokumentation aufgezaehlt. Wie die Dokumentation denn haette aussehen sollen wurde nicht erwaehnt.
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.