Ich habe vor zwei Monaten als Absolvent eine neue Stelle angetreten und
soll dort einen langjährigen Mitarbeiter ersetzen, der das Unternehmen
verlässt (Ruhestand).
Im Moment werde ich eingearbeitet. Ich mag das Unternehmen, die Kollegen
sind nett und hilfsbereit und die Atmosphäre entspannt. Aber die
Einarbeitung selber ist einfach nur hart und lutscht mich echt aus.
Ich arbeite in der der Entwicklung. Das Produkt an dem ich mitarbeite
ist technisch gesehen nicht sehr komplex, aber es gibt viele Varianten,
mit Details, auf die man achten muss und für die man erstmal ein Gefühl
entwickeln muss. Das Ganze ist auch kein Standardprodukt, zu dem es
Literatur gibt, sondern es basiert auf über Jahrzehnte aufgebauten
Know-How, das nur intern und großteils nur in den Köpfen der anderen
Ingenieure existiert. Ich kann mich also nicht großartig selbständig in
die Materie einarbeiten, sondern muss immer nachfragen. Mein Fragen
werden zwar immer beantwortet, aber ich habe das Gefühl, dass ich
anfange zu nerven.
Das größte Problem ist, dass ich kaum Chancen habe, in einem Bereich mal
wirklich Kompetenzen aufzubauen, weil ich von anderen Abteilungen
ständig mit neuen Aufgaben zugeschüttet werde. Besonders vom
Projektmanagement. Die kommen mit Anfragen und Aufgaben zu mir, als wenn
ich noch nie etwas anderes gemacht hätte. Dass ich den Kollegen, der
dort 15 Jahre gearbeitet hat nicht innerhalb von 2 Monaten ersetzen
kann, scheint eine Idee zu sein, die denen garnicht erst kommt.
Wenn die mit neuen Sachen kommen, kümmere ich mich natürlich darum,
frage die Kollegen, bitte um Hilfe. Nur bevor ich dazu komme an der
Sache weiterzuarbeiten, an der ich ursprünglich gearbeitet habe, habe
ich an drei anderen Sachen gearbeitet und wieder die Hälfte von dem
vergessen, was ich bis dahin dabei gelernt habe. Und dann kriege ich
noch Mails in denen ich nach dem Stand des Projekts gefragt werde, dass
ich zu gunsten der anderen Sachen erstmal habe liege lassen...
Habt ihr so etwas auch schon erlebt? Wie lief die Einarbeitung bei euch?
Eingearbeiteter schrieb:> Und dann kriege ich noch Mails in denen ich nach dem Stand des Projekts> gefragt werde, dass ich zu gunsten der anderen Sachen erstmal habe liege> lassen...
Hast du lediglich einen Projektmanager, bzw arbeitest du an lediglich
einem Projekt?
Eingearbeiteter schrieb:> Habt ihr so etwas auch schon erlebt? Wie lief die Einarbeitung bei euch?
Du hast es gut.
Ich war schon der zweite, der den in die Pension gehenden Kollegen
ersetzen sollte. Der soll wohl mit der chaotischen Arbeitsweise der
Firma nicht klargekommen sein.
Damit hatten wir 2 Wochen zur Projektübergabe. wovon man vielleicht 3
Tage nutzen konnte.
Dokumentiert hat mein Vorgänger generell nicht. Es gab nur einen wirren
Zettelhaufen - den habe ich nach 5 Jahren ungenutzt entsorgt. Das Ende
vom Lied ist, dass ich mir Details über die Schaltpläne zusammenreimen
darf. Die sind obendrein meistens falsch, weil niemand hat sich die Mühe
gemacht Änderungen nachzuziehen.
Wenn was daran zu machen ist, geh ich halt her und ziehe erst mal alle
Änderungen im Schaltplan nach. Danach kann man meist vom Schaltplan auf
die Funktion Rückschlüsse ziehen. Hat man das verstanden, kann man das
betreffende Problem suchen oder die betreffende Änderung machen.
Die positive Seite ist, dass mir keiner in meine Arbeit reinquatscht,
weil sich in der ganzen Firma keiner auskennt.
--> Willkommen in der Praxis ;-)
Eingearbeiteter schrieb:> Habt ihr so etwas auch schon erlebt? Wie lief die Einarbeitung bei euch?
Wo liegt dein Problem? Du beschreibst einen ganz normalen Arbeitsalltag.
Dir scheint daran irgendetwas nicht zu gefallen und stellst es so dar,
als ob es nach deiner Einarbeitung anders weiterginge. Nein, tut es
nicht.
Eingearbeiteter schrieb:> Habt ihr so etwas auch schon erlebt? Wie lief die Einarbeitung bei euch?
Joa, so ähnlich war das bei mir auch. Das ist völlig normal. Du musst
denen halt vermitteln, dass du dich erstmal einarbeiten musst, das geht
in zwei Monaten einfach nicht.
Normalerweise muss die Aufgabenverteilumg innerhalb der Abteilung
abgesprochen werden (mit deinem Scheff), du bekommst dann ein zeitliches
Budget fuer die verschiedenen Projekte. Der Projektleiter bekommt dich
als Ansprechpartner, du haelltst dich aber an die abteilungsinternen
Vereinbarungen. Diese duerfen an den PL auch kommuniziert werden:
"Uebernaechste Woche fang ich mit deinem Projekt an, vorher geht
nichts."
Ist der PL damit nicht einverstanden, muss er sich an deinen Scheff
wenden mit der Begruendung warum er Prioritaet haben soll. Gibt es keine
zeitlichen Vorgaben von deinem Scheff, so musst du deine Aufgabenplanung
selbst durchfuehren. Prinzipiell gilt aber das gleiche. Du kannst auch
nur in so weit priorisieren, wie du auch Einblicke hast. D.h. eine
hoehere Prioritaet muss von deinem Scheff als solche angezeigt werden.
Nur weil der PL vom einen Projekt penetranter ist, heisst das ja nicht,
dass sein Projekt tatsaechlich wichtiger ist.
Fuer dich wichtig ist aber, dass du Aufgaben auch tatsaechlich
erledigst, dich also nicht dauernd unterbrechen laesst. Ein Taskwechsel
braucht ja immer Zeit.
Ihr habt's alle gut. Mein Vorgänger hatte sich aus dem Staub gemacht,
bevor ich die neue Stelle angetreten habe - meine jetzige Position.
Zwei Monate sind doch eine super Zeit, eine halbe Ewigkeit. Dafür, dass
Du frisch von der HS/Uni kommst, kann erst einmal keiner was für.
Lass Dich nicht verheizen, guck Dir das erstmal in Ruhe an. Vll. findet
Ihr ja irgendwann einen Modus, wie das ganze klappen kann.
Auch mal den Mund aufmachen, am besten rechtzeitig - viele Grundlagen
erscheinen den alteingesessenen alss Simpel und Easy, da - wie Du
richtig schon erkannt hast - diese in der Materie drin stecken.
Dir wird es überall anders vmtl. ähnlich ergehen. Bleib an einer Sache
dran, dafür bleibt halt mal was anderes liegen. Wenn die Firmenkultur
150% Einsatz erfodert, finde dich damit ab und krempel die Ärmel hoch
oder such Dir was anderes.
Ich gebe immer 100% - 20% montags, 20%Dienstags usw...;-)
Mimimimi schrieb:> Dir scheint daran irgendetwas nicht zu gefallen und stellst es so dar,> als ob es nach deiner Einarbeitung anders weiterginge. Nein, tut es> nicht.
Das nicht.
Aber die Einarbeitung sollte dazu da sein, sich mit der (technischen)
Komponente auseinander zu setzen, so dass man diese im Projekt zum
fertigen Produkt weiter verarbeiten kann.
Ist dies nicht gegeben, weil ständig von allen Seiten andere Aufgaben
(teilweise sogar für andere Projekte) kommen, so ist die Einarbeitung
m.E. schlichtweg fehl gelaufen.
Ich kann den TO jedenfalls gut verstehen. Ist aber leider oftmals der
Fall, dass kaum Einarbeitung statt findet. Ging mir damals genau so. Ich
habe eine technische Komponente bereits am ersten Tag im Job übernehmen
müssen.
Gruß,
Eingearbeiteter schrieb:> Habt ihr so etwas auch schon erlebt? Wie lief die Einarbeitung bei euch?
Ja, die Situation kenne ich gut. Sitze gerade auch an der Einarbeitung
nach einem Jobwechsel.
Mein Senf dazu (bezogen auf Embedded Software. Hardware funktioniert
sicher anders):
Software-Entwicklung in einem recht großem, komplexem System in C. Wurde
unter Zeitdruck geschrieben. Dokumentation gibt es, ist aber nicht
sonderlich hilfreich um sich einzuarbeiten.
Nun habe ich schon über 20 Jahre Berufserfahrung in dem Bereich, und es
ist nicht das erste mal, das ich so ein Projekt übernehme. Ich habe
daher schon einiges an Erfahrungen im Einarbeiten gesammelt.
Mein Ansatz: Lesen, lesen, lesen. Stell Dir einfach vor, Du machst ein
Code-Review. Such Dir einen Aspekt der Software raus und versuche zu
verstehen wie er funktioniert und wie er mit dem Rest des Systems
interagiert. Hab keine Angst in die Tiefe zu gehen. Wenn Du feststeckst,
dann frag die Kollegen, aber versuche es erst mal selbst.
Mit jedem Tag, den Du den Code liest wirst Du ein Stück mehr verstehen.
Irgendwann fällt der Groschen und Du siehst wie sich die Puzzelteile
zusammenfügen. Das geht dann mit jedem Tag schneller.
Ich lese jetzt etwa 1 Monat an dem Code und hab so etwa 50% der
Zusammenhänge gerafft. Damit bin ich fit genug um aktiv am Code zu
arbeiten.
Mach Dir Notizen. Wenn sich die Gelegenheit bietet dann kannst Du daraus
später eine Architektur Doku schreiben. Das macht es Deinem Nachfolger
bzw. Deinem kommenden Kollegen einfacher sich einzuarbeiten.
Notiere Dir auch, wenn Du Ecken findest die Dir unnötig komplex
erscheinen oder schlicht und ergreifend falsch sind. Du bist neu und
blickst unvoreingenommen auf den Code. Die alten Hasen (und später auch
Du) können das nicht mehr, weil sie den Code vermeintlich kennen. So
findest Du Fehler, die die alten Hasen gar nicht mehr sehen.
Ich hab so schon in einem Monat zwei dicke "Zeitbomben" gefunden die
ganz klar falsch sind aber durch "Glück" bislang nicht aufgefallen ist.
Alexander schrieb:> Ich> habe eine technische Komponente bereits am ersten Tag im Job übernehmen> müssen
Ja und? Dann warst du damit doch eingearbeitet, bzw. du hast danach
begonnen, dich einzuarbeiten.
Was erwartet ihr? Wollt ihr die ersten drei Jahre im Job einen Betreuer
neben euch sitzen haben, der euch jedes Problem aus der Welt schafft,
und ihr tut, was euch Spaß macht? Das nannte sich S-T-U-D-I-U-M, und das
ist leider leider irgendwann zuende.
Gibt im Übrigen auch gute Tools - grad in Sachen SW o.ä. Understand for
C/C++ fällt mir da ein. Super Sache, erstellt Graphen aus deinem Code.
Die Zusammenhänge werden dann doch noch ersichtlich, wenn die
Komplexität des Codes ansonsten einen erschlagen würde.
Understand ist jetzt ein Beispiel, gibt auch andere und sicherlich auch
kostenlose Tools. Wobei dieses einen Probemonat beinhaltet.
Feldstecher schrieb:> Normalerweise muss die Aufgabenverteilumg innerhalb der Abteilung> abgesprochen werden (mit deinem Scheff), du bekommst dann ein zeitliches> Budget fuer die verschiedenen Projekte. Der Projektleiter bekommt dich> als Ansprechpartner, du haelltst dich aber an die abteilungsinternen> Vereinbarungen. Diese duerfen an den PL auch kommuniziert werden:> "Uebernaechste Woche fang ich mit deinem Projekt an, vorher geht> nichts."> Ist der PL damit nicht einverstanden, muss er sich an deinen Scheff> wenden mit der Begruendung warum er Prioritaet haben soll. Gibt es keine> zeitlichen Vorgaben von deinem Scheff, so musst du deine Aufgabenplanung> selbst durchfuehren. Prinzipiell gilt aber das gleiche. Du kannst auch> nur in so weit priorisieren, wie du auch Einblicke hast. D.h. eine> hoehere Prioritaet muss von deinem Scheff als solche angezeigt werden.> Nur weil der PL vom einen Projekt penetranter ist, heisst das ja nicht,
Oh, das hast Du schön aus dem Lehrbuch abgeschrieben.:) Genauso ist die
Theorie, die Praxis in den meisten Unternehmen ist eine andere. Da wird
nicht vom Chef priorisiert, dafür hat der Chef gar keine Zeit, sondern
es wird erwartet, dass alle Projekte/Projektmanager zufriedenstellend
bedient werden. Gleichzeitig versteht sich. Kleiner Tipp: Oft reicht es,
wenn die Projekmanager das Gefühl bekommen, dass an ihrem Projekt
intensiv gearbeitet wird.
@Eingearbeiteter: Es ist klar, dass die Anfangsphase für Dich stressig
ist und besonders hohen Zeiteinsatz erfordert. Denn während Du mit 100 %
Aufgaben eines normalen Mitarbeiters belastet bist, für die Du in der
Regel auch noch länger brachst, musst Du Dich nebenbei noch einarbeiten.
Du musst also in der ersten Zeit richtig ranklotzen. Das ist aber völlig
normal.
Christian schrieb:> Genauso ist die Theorie, die Praxis in den meisten Unternehmen ist eine> andere.
Dann sollte man meiner Ansicht nach dennoch versuchen, Theorie und
Praxis miteinander zu verbinden.
Ich wurde für das Projekt X eingestellt, um an Komponente X zu arbeiten.
Der Vorgänger von Komponente X kommt auch in älteren Projekten zum
Einsatz. Wenn der Vorgänger in der Produktion oder im. Einsatz
explodiert etc, kommt der entsprechende Projektmanager sofort zu mir,
damit ich das Problem für ihn löse.
Ich sage dem entsprechenden Projektmanager direkt, dass ich dafür zu
diesem Zeitpunkt nicht zuständig bin, weil ich ab Projekt X arbeite, und
dass er das mit meinem Chef absprechen soll, dass er für seine
Komponente entsprechend Unterstützung benötigt.
Manchmal kam das Problem wieder direkt zu mir, manchmal an einen
Kollegen.
Die Projektmanager mögen meine klaren und direkten Aussagen
verständlicherweise nicht.
Allerdings müssen sie es akzeptieren, denn sie können mich nicht dazu
zwingen, an anderen Projekten zu arbeiten.
Insofern würde ich definitiv den Weg über den Chef gehen.
Man darf auch gerne mal seinen Mund aufmachen und die Grenzen zeigen.
Nur weil man Angestellter ist, muss man nicht ja zu allem sagen.
Gruß,
Le X. schrieb:> Bin ich der einzige der den Text hier schon mal 1:1 hier gelesen hat?
Wahrscheinlich nicht, denn das ewig gleiche Gesülze wiederholt sich doch
im Intervall eines Monats.
Eingearbeiteter schrieb:> Wie lief die Einarbeitung bei euch?
gemütlich, aber ich kannte die Aufgabe schon auswändig (weil ich vorher
schon hobbymäßig sowas tat)
CBM Rechner HW erweitern programmieren.
Es lief in etwa so: "erweitere die Ports nach aussen, schreibe eine ASM
Routine zur Mittelwertbildung"
Nebenbei konnte/wollte/musste ich dem anderen neuen Kollegen noch CBM
Basic Nachhilfe geben, eigentlich ihm sein Programm schreiben.
Hat Spass gemacht.
Als wir nach 2 Monaten! unsere Ergebnisse vorstellen sollten war meine
und seine Probezeit beendet, ich blieb dann 13 Jahre.
Eingearbeiteter schrieb:> Wenn die mit neuen Sachen kommen, kümmere ich mich natürlich darum,> frage die Kollegen, bitte um Hilfe.
Völlig falscher Ansatz. So lässt du dich verheitzen.
Frag bei jeder Aufgabe nach einem Termin und erkläre was du gerade
machst.
Wenn was absolut HOHE Prio hat frag was liegen bleiben soll.--Nennt man
Prioritäten setzen.--
Mails werden einmal am Tag, max. zweimal am Tag bearbeitet!--Ablenkung
vermeiden--
Wie steht denn dein "Alter Kollege" und die anderen Mitarbeiter zu
deinem Problem?
Springen die auch sofort wenn ne Anfage reinkommt??
p.
Hallo,
Eingearbeiteter schrieb:> Das Ganze ist auch kein Standardprodukt, zu dem es Literatur gibt,> sondern es basiert auf über Jahrzehnte aufgebauten Know-How, das nur> intern und großteils nur in den Köpfen der anderen Ingenieure existiert.> Ich kann mich also nicht großartig selbständig in die Materie> einarbeiten,
Meistens existieren Schaltpläne und Code noch irgendwo. Selbst wenn sie
falsch sind, enthalten sie einen Großteil der Information und sind gute
Anker.
Eingearbeiteter schrieb:> Die kommen mit Anfragen und Aufgaben zu mir, als wenn ich noch nie etwas> anderes gemacht hätte. Dass ich den Kollegen, der dort 15 Jahre> gearbeitet hat nicht innerhalb von 2 Monaten ersetzen kann, scheint eine> Idee zu sein, die denen garnicht erst kommt.
Fragen Sie? Nach Terminen und Aufwand? Das müssen sie, wer sollte sonst
Auskunft geben.
Oder kritisieren sie Deine Zeiten oder Leistung? Nur dann wäre Deine
Aussage sinnvoll.
Sei bei Abschätzung niemals optimistisch. Was Du in 10 Minuten
programmieren kannst, wird am Ende 1 Tag dauern und frühestens in einer
Woche fertig sein, wenn es kein Notfall ist.
Eingearbeiteter schrieb:> wieder die Hälfte von dem vergessen, was ich bis dahin dabei gelernt> habe.
Das ist ein echtes Problem. Notieren konsequent und versuche Ordnung da
rein zu bringen. Wenn möglich schlage Zeit für Dokumentation raus. 99%
aller interner Dokumentation (also nicht für andere Abteilungen) nutzen
eh nur dem, der sie erstellt.
Eingearbeiteter schrieb:> Habt ihr so etwas auch schon erlebt? Wie lief die Einarbeitung bei euch?
So oder so ähnlich war es auch bei mir. Ich habe aber super Kollegen und
Vorgesetzte die immer gerne alle Fragen ausführlich beantworten. Als
frischer Absolvent weiß man noch nicht viel, die Lernkurve ist steil und
ich schätze nach zwei Jahren "Berufserfahrung" ist man auf einer ganz
anderen Ebene. Ich lese nebenher gerne, wenn es die Zeit zulässt,
fortgeschrittene Fachbücher zum Thema aktueller Projekte. Ich merke
leider dass ich nahezu keine Zeit habe mich mit neuen Technologien zu
beschäftigen. Mal sehen, ob es in nächsten Jahr besser klappt...
petman schrieb:> Völlig falscher Ansatz. So lässt du dich verheitzen.> Frag bei jeder Aufgabe nach einem Termin und erkläre was du gerade> machst.> Wenn was absolut HOHE Prio hat frag was liegen bleiben soll.--Nennt man> Prioritäten setzen.--> Mails werden einmal am Tag, max. zweimal am Tag bearbeitet!--Ablenkung> vermeiden-->> Wie steht denn dein "Alter Kollege" und die anderen Mitarbeiter zu> deinem Problem?> Springen die auch sofort wenn ne Anfage reinkommt??
Oben ist die übliche Arbeitsweise deutscher Ingenieure beschrieben.
Genau darum sind Osteuropäer, Amerikaner und bald auch Chinesen deutlich
schneller. Und u.A. darum werden Jobs ausgelagert.
Nichtsdestrotz bringt es nichts gegen den Strom schwimmen zu wollen.
Dieses Zitat oben ist eigentlich die halbe Einarbeitung und für die
Arbeit in Deutschland goldwert.
1. Daumenregel: Mit 30% vom Aufwand lassen sich 70% der Arbeit
fertigstellen. Oftmals reicht das völlig aus. Wenn du z.B. mit einem
chinesichen Kunden arbeitest, merkst du, dass die Zeitpläne meist viel
zu optimistisch und damit nutzlos sind. Auch andere Zulieferer packen
das nicht, aber du bist der Blöde, wenn du zuerst die Hand hebst. Dann
versucht man diesen Ansatz mit 30%-Aufwand. Anschließend ist der Kunde
glücklich, sein Leute haben was zutun und du kannst dich auf andere
liegengebliebene Aufgaben fokussieren.
2. Was es nicht irgendwo schriftlich nachlesbar gibt, brauchst du gar
nicht bearbeiten. Mündliche Absprachen sind ohne ein an alle versendetes
Meetingprotokoll wertlos.
Außer Chef oder Chef-Chef hat eine Aufgabe mit hoher Prio mündlich
vorgegeben.
3. Zeitabschätzungen erfolgen nicht direkt auf die Anfrage, sondern erst
nachdem man sich alles durch den Kopf gehen lassen hat. Am besten 70%
Zeit oben aufschlagen. Da viele Kunden das wissen, nochmal 80%
zusätzlich, also 150% drauf. Wenn du schneller fertig wirst, feiern dich
alle, wenn nicht, bist du wenigstens nicht um Welten daneben.
Eingearbeiteter schrieb:> Wenn die mit neuen Sachen kommen, kümmere ich mich natürlich darum,> frage die Kollegen, bitte um Hilfe. Nur bevor ich dazu komme an der> Sache weiterzuarbeiten, an der ich ursprünglich gearbeitet habe, habe> ich an drei anderen Sachen gearbeitet und wieder die Hälfte von dem> vergessen, was ich bis dahin dabei gelernt habe
ähh..... das ist nicht Dein Ernst oder?
Dass man als Anfänger mit viel Dreck zugeladen wird, ist ja normal, aber
am Ende wechseln für jeden die Projekte und etwas Wissen behalten sollte
man sich schon, oder?
Eingearbeiteter schrieb:> Alexander schrieb:>>> Hast du lediglich einen Projektmanager, bzw arbeitest du an lediglich>> einem Projekt?>> Nein, mehrere Projekte und Projektmanager.
Als Absolvent? Naja, da stimmt was nicht. Entweder ein Freitagstroll
oder ziemlich chaotische Zustände. Falls die Schilderung wirklich
zutrifft, würde ich mit dem Chef reden. Das ständige hin- und her
wechseln ist suboptimal und wahrscheinlich unnötig. Besser ist eine
klare Trennung, zum Beispiel Montags Projekt A, Dienstags Projekt B usw.
Zumindest die ersten paar Monate bis Du sattelfest bist. Selbst dann ist
es immer problematisch, wenn man mehrere Projektmanager hat, weil der
eine nicht weiß, was andere von Dir will und niemand am Ende einen
Überblick hat, zu welchem Grad Du ausgelastet bist.
Selbst für erfahrene Leute ist das schwierig zu handhaben, wenn Sie zum
Beispiel zu scheu sind, um Nein zu sagen oder sich zu wehren.
Geheim schrieb:> Als Absolvent? Naja, da stimmt was nicht. Entweder ein Freitagstroll> oder ziemlich chaotische Zustände.
Doch, in manchen Horrorfirmen gibt es das.
Die finden aber auch keine Leute mehr.
Eingearbeiteter schrieb:> Nur bevor ich dazu komme an der Sache weiterzuarbeiten, an der ich> ursprünglich gearbeitet habe, habe ich an drei anderen Sachen gearbeitet> und wieder die Hälfte von dem vergessen, was ich bis dahin dabei gelernt> habe.
Alles alles alles irgendwo aufschreiben.
Damit ist es auch schonmal halbwegs Dokumentiert. Habt Ihr
Projektbezogene und allgemeine Wissensbasis-Wikisysteme? Da gehört das
rein.
Das in einem Schwesterthread angesprochene Problem, dass sich ein
Bastler durch nicht-dokumentieren unersetzbar macht, wird damit auch
beseitigt. Verkauf das deinem Cheffe gleich als "Schulungsunterlagen für
Neulinge erstellen". Dann wird das auch gleich bei der ersten
Leistungsbeurteilung honoriert werden.
Eingearbeiteter schrieb:> Und dann kriege ich noch Mails in denen ich nach dem Stand des Projekts> gefragt werde,
An zuständigen Projektleiter weiterleiten, der muss den Status kennen ;)
mfg mf
minifloat schrieb:> Alles alles alles irgendwo aufschreiben.
ja genau
> Damit ist es auch schonmal halbwegs Dokumentiert.
wofür woghl sonst das aufschreiben, damit im Kopf wieder Platz wird?
> Habt Ihr Projektbezogene und allgemeine Wissensbasis-Wikisysteme?
????
> Da gehört das rein.
nach meiner Meinung nach eben nicht
> Das in einem Schwesterthread angesprochene Problem, dass sich ein> Bastler durch nicht-dokumentieren unersetzbar macht, wird damit auch> beseitigt.
"Bastler" machen sich damit nicht unersetzbar, sonst wären sie ja wohl
keine Bastler
> Verkauf das deinem Cheffe gleich als "Schulungsunterlagen für Neulinge> erstellen".> Dann wird das auch gleich bei der ersten Leistungsbeurteilung honoriert> werden.
du glaubst auch noch an den Weihnachtsmann?
In einem Frickelladen ohne Doku gräbt man sich nicht sein eigenes Grab,
aber genau das willst du wohl von ihm?
Man passt sich an und wurschelt mit, und passt auf dass man sich nicht
selber zu entbehrlich macht.
Als junger Mitarbeiter ist man aber noch nocht so weit um das so
vorhersehen zu können.
