3. Wie kann man Wissenstransfer bei Projektübernahme am besten durchführen?

Wie kann man Wissenstransfer bei Projektübernahme am besten durchführen?

  • C

    Hallo Forum,

    ich habe jetzt die Aufgabe bekommen, die Anwendung eines Kollegen (der in 6 Monaten in Rente geht) zu übernehmen. Ich habe:

    - kein Domänenwissen über das Gebiet, für das die Software geschrieben wurde
    - (mittlerweile) einen kleinen/groben Überblick über die Anwendung (Tabellen / Module)
    - kein spezifisches Projektwissen (Details zu der Arbeitsweise der Module, Sonderfälle, Workarounds / technische Schulden)

    Am Ende soll ich das Projekt voll übernehmen und weiter pflegen. Das heißt, dass ich auch Domänenwissen (neben der Softwarearchitektur und dem üblichen "Programmierstil") aufbauen muss. Tja und im Moment weis ich noch nicht so richtig wie ich das ganze machen soll. 😕

    Es gibt zur Zeit einige Visio-Diagramme für die Programmabläufe und ein paar Worddokumente, die ganz grob die Arbeitsweise der einzelnen Module beschreiben. Ich arbeite außerdem noch an einem anderen Standort, so dass ich den Kollegen eigentlich nur alle 2 Monate sehe. Nebenbei muss ich auch noch andere Projekte bearbeiten, so dass ich nicht die volle Zeit zur Einarbeitung zur Verfügung habe.

    Frage: Habt ihr vielleicht irgendwelche hilfreichen Tipps um sowas so effektiv wie möglich zu machen? Vielleicht kennt ihr ja auch ein Tool, mit dem man geeignet eine Doku aufbauen kann. Vielleicht gibt es ein Werkzeug, mit dem man Dokumentationen (Visio, Word, Wiki, E-Mails) irgendwie "vernetzen" kann.

    Ich hab mir bisher folgendes überlegt:
    - Mich regelmäßig (z.B. täglich ein Stunde) mit dem Thema beschäftigen.
    - Vom Groben ins Feine durcharbeiten (welche "Bereiche" gibt es, Wie heißen die Tabellen zu diesen Bereichen, welche Programme gehören dazu, welche "Workflows/Prozesse" gibt es).
    - Irgendwie eine "geeignete" Doku aufbauen. Im Grunde muss diese ja die allgemeinen Informationen (Prozesse, Abläufe, beteiligte Module/Programme) abbilden aber auch wichtige Details enthalten (Sonderfälle x, y und z).
    - Danach Schritt für Schritt eines von den Modulen vornehmen und den Code anschauen.

    Vielleicht hat ja einer von euch sowas schonmal gemacht? Bin für jeden Tipp dankbar!

    0
  • M

    Wie umfangreich/komplex ist das Projekt?

    Das größte Problem wäre für mich wahrscheinlich das Domänenwissen. Ich würde versuchen, mich übers Debugging in die Software selber einzuarbeiten, so komme zumindest ich gut zurecht. Wenn man paar Workflows durchdebuggt, sieht man welche Module wie benutzt werden und vielleicht fallen einem auch schon mal irgendwelche Spezialitäten auf, die man kennen sollte.
    Aber wenn dir nicht genau klar ist, was das Ganze machen soll und warum etwas so gemacht wurde, wie es eben gemacht wurde, dann wirds schwierig.
    Ich habe auch schon mehrere große Projekte von Kollegen übernommen, die uns im Laufe der Zeit verlassen haben. Aber ich habe das Domänenwissen und ich arbeite in einer größeren Firma, da kann ich noch mit anderen Leuten über die Projekte reden und wenn nicht mehr genau klar ist, was da eigentlich passieren sollte, dann habe ich noch Ansprechpartner, mit denen man zumindest sinnvolle Lösungen ausdiskutieren kann, wie wir das haben wollen.

    0
  • A

    Das schwierigste ist immer das Fachwissen, nicht die Technik. Die Technik (Code, Server, DBs usw.) kann man ja alleine durch die Source-Projekte selbst analysieren.

    Aber das Fachwissen steckt meistens in den Köpfen der Entwickler und der Benutzer! D.h. wenn du den Entwickler nur selten siehst, und er dir deshalb nicht umfangreich helfen kann, musst du an die Benutzer ran. Die kennen die Anwendung mindestens genauso gut. Und meistens gibt es ja unter den Benutzern sogenannte Key-User. Also die Sorte Benutzer die total motiviert und begeistert von der Software ist und sich sehr gut in der Benutzung und somit dem Fachwissen der Abteilung auskennt.

    Versuche also die Namen der Key-User zu bekommen und lass dir von denen erzählen und zeigen, wie die Software funktioniert. Und was noch wichtiger ist: lass dir deren Fachgebiet erklären. Denn das musst du ja kennen, um die Software weiter entwickeln zu können.

    Code, Konfiguration usw. ist doch Pille Palle, das ist ja DEIN Fachgebiet! 🙂

    0

  • Artchi schrieb:

    Code, Konfiguration usw. ist doch Pille Palle, das ist ja DEIN Fachgebiet! 🙂

    Ne also da bin ich ganz anderer Meinung. Quasi kein grösseres Programm ist frei von mehr oder weniger grossen Überraschungen. Die Unkenntnisse der Eigenheiten eines Programms als Pille Palle zu bezeichnen ist da mMn. schon etwas ... stark 🙂

    0
  • C

    Danke für eure Anworten.

    @Mechanics
    Also das Projekt umfasst ca 100 Programme/Module. Ich schätze mal das es ca. 100-150 Prozesse/Workflows/Abläufe gibt, welche diese Programme/Module nutzen. Also vom Umfang her noch überschaubar. (wobei es natürlich auch hier ein paar neuere strukturierte Programme und ein paar Mega-Monster gibt).

    Ansonsten glaube ich mittlerweile auch, dass das Fachwissen das schwierigste ist. Wenn ich das nicht kenne, dann kann ich gar nicht verstehen warum manche Dinge so programmiert sind, wie sie sind. Also muss ich mir Fachwissen und Programmeigenheiten parallel aneignen.

    - Ich werde mir erstmal alle Prozesse/Workflows zeigen lassen. Wenn ich weis wie alles genutzt wird, dann habe ich auch ein paar Einstiegspunkte.
    - Dann will ich herausfinden, welche die 5-10 wichtigsten Programme sind und mir diese mal etwas näher anschauen. (Eigenheiten, allgemeine Denkweise in den Programmen usw.)
    - Und dazu halt das Fachwissen aufbauen.
    - Dann wieder weiter mit Punkt 3.

    Habt ihr vielleicht noch Erfahrungen, welche Tools sich gut zum Dokumentieren eigenen? Wiki's haben sich hier bei uns nicht wirklich durchgesetzt (wir haben eins, aber das nutzt niemand). Ansonsten benutze ich in anderen Projekten NVU/KompoZer als WYSIWYG HTML-Editor. Der ist aber Buggy und wird nicht wirklich weiter entwickelt. Und es gibt auch nur 3 Leute die den für Nutzer- und Entwicklerdokus nehmen.

    Im Grunde möchte ich mehrere Seiten (strukturiert nach Themen/Module, mit Inhaltsverzeichnis auf jeder Seite) schreiben und diese irgendwie untereinander verlinken. Schlagworte usw. wären auch super. Diagramme kann man ja mit Word oder PowerPoint malen. Wir haben hier bei uns aber noch keine wirkliche gute Lösung zum Dokumentieren von Projekten gefunden. Vor allem für langfristige Wartungsprojekte und in Verbindung mit einem Bugtrackingsystem.

    0
  • N
    Mod

    Das Wichtigste dürfte sein, sich so schnell wie möglich einen Überblick zu verschaffen und dabei gleich anfangen, einen Fragenkatalog zu erstellen, vor allem, weil man den Kollegen ja nicht so oft sieht.

    Dokumentation ist so einfach wie möglich am besten, d.h. für Windows z.B. Notepad und für Programmiersprache->Programmmodul.

    Hervorragende Programmiersprachenlösung ist die Haskell Literate Programming Möglichkeit https://www.haskell.org/onlinereport/literate.html

    Ein gutes Rezept gegen Chaos und Wahnsinn ist Standardisierung.

    0
  • ?

    In welcher Programmiersprache/Branche?
    dann kann man sich besser ein Bild von der Komplexität machen und bessere Tips geben

    du solltest auf jeden Fall so schnell wie möglich eine lokale Testinstallation einrichten - (vielleicht mit simulierten Komponenten, eigenen Datenbanken usw.) - es gibt nicht schlimmeres als beim Analysieren/Probieren vorsichtig sein zu müssen

    0
Anmelden zum Antworten