So etwas hab ich schon mal kennengelernt, ich hab tatsächlich den Bericht noch gefunden:
Zitat von
Interner Bericht:
Fachliche Mängel
Hält sich nicht an vereinbarte Konventionen
Checkt Programme nicht aus vor dem Bearbeiten. Folge: Von anderen Programmierern durchgeführte Änderungen werden rückgängig gemacht.
Verwendet nicht die vorgegebenen Werkzeuge
Weigerte sich lange, einen Debugger zu benutzen. Folge: Findet seine Programmierfehler nicht oder braucht unangemessen lange dafür. Die eingebauten Bildschirmnachrichten zur Fehlersuche werden nach Beendigung der Arbeiten teilweise nicht entfernt und erscheinen dann auch im fertigen Produkt.
Benutzt einen eigenen Editor
Setzt undokumentierte Fremdprogramme ein, die dann auch in die Produktion gelangen, informiert aber erst auf Rückfrage, worum es sich bei diesen handelt.
Testet nicht
Folge: Der Funktionale Test muss durch die Endbenutzer erfolgen. In einigen Fällen auch durch die Kollegen, wenn diese von ihm fehlerhafte geänderte oder erstellte Programmroutinen mitbenutzen.
In einem Fall ließ sich ein von Ihm geändertes Programm nicht einmal mehr compilieren.
Dokumentiert mangelhaft
Es ist teilweise nicht nachvollziehbar (außer durch Vergleich mit einem RCS) welche Änderungen wann und von wem durchgeführt wurden. Andere Programmierer haben dadurch Probleme, von ihm bearbeitete Programm zu verstehen. Dies resultiert evtl. in Folgefehlern, mindestens aber in einem erhöhten Zeitaufwand.
Übersieht nicht den Arbeitsumfang
Verschafft sich keinen Überblick über die Art und Auswirkung der übernommenen Aufgaben. Betreibt keine Forderungsanalyse. Dadurch kommt es z.B. in vom ihm überarbeiteten Programmteilen zu Verlusten in der Funktionalität im Gegensatz zu vorher: Bei der Überarbeitung eines Programmes ließ er die Hälfte aller Bearbeitungsoptionen weg. Das läßt darauf schließen, dass er den zu ändernden Sourcecode vor der Bearbeitung nicht analysiert.
Arbeitet schlampig
Korrigiert nicht die von anderen übernommenen Testdaten und Konfigurationen. Dadurch verändert er ggf. dann Daten anderer Programmierer oder in der Produktion.
Kommunikative Mängel
Berichtet nicht über seinen Arbeitsfortschritt, dies verunsichert die Leitung. Nimmt Vorschläge und Kritik nicht auf, dadurch macht er mehrmals die gleichen oder gleichartige Fehler.
Zeigt offen sein Desinteresse
Bei fachlichen Gesprächen, die normalerweise sein Interesse wecken sollten, hört er, wenn überhaupt, nur sehr kurz zu und beschäftigt sich dann mit etwas anderem. Ist er gezwungen, weiterhin teilzunehmen, z.B. in einem per Termin angesetzen Meeting, so kann er sein Schlafbedürfnis kaum zügeln.
Sitzt oft mit auf die Hand gestütztem Kinn vor seinem Rechner und tut beobachtbar nichts für längerere Zeit.
Übernimmt generell keine Supportfälle, wird er dazu genötigt so läßt er den Hilfesuchenden zuerst aufwändig sein Problem schildern und gibt dann den Hörer ohne Reaktion an einen Kollegen weiter.
Übernimmt keine Telefonate, auch wenn er allein im Büro ist.
Beispiele
7.2.2xxx Schläft während der Arbeit. Durch Abspielen einer sehr lauten Trompete auf dem Computer wird er durch die Kollegen geweckt.
1.3.2xxx Kompiliert Programm und sieht Fehlermeldung auf dem Bildschirm. Kopiert danach ohne Überprüfung die alte Version. Dies wurde dann vom Fachbereich beim Testen festgestellt.
12.3.xxx Hat die geringste Anzahl an Programmänderungen bearbeitet, aber die höchste Anzahl an Fehlern. Insgesamt 47 Fehlermeldungen, davon 26 für ihn. Alleine eine Anforderung musste 8 mal korrigiert werden und läuft bis heute nicht. Die in den Routinen enthaltenen Fehler führten im Test zu einem nahezu kompletten Datenverlust, so daß der Test komplett neu aufgesetzt werden musste. Alle von den Fachabteilungen erarbeiteten und vorbereiteten Daten gingen verloren bzw. wurden unbrauchbar gemacht.