Vor allem dumm

Man kann das verwerflich finden, man kann eine Sklavenhalter-Mentalität darin enttdecken. Das ist auch alles richtig. Vor allem ist die Einstellung von Erika Nardini aber eines: dumm.

Für mich ist das ein Anlass, mal grundsätzlich etwas zu den Erwartungen zu sagen, die ich an Mitarbeiter normalerweise habe. Und warum.

Ich habe nicht die Erwartung, dass Mitarbeiter mehr als acht Stunden täglich und mehr als 5 Tage in der Woche fürs Unternehmen da sind. Nicht etwa, weil ich so menschenfreundlich bin – das vielleicht auch, aber es ist nicht entscheidend. Vor allem, weil kein Mensch mehr als acht Stunden täglich effektiv und konzentriert arbeiten kann. Das kann in Ausnahmefällen mal klappen, aber nur, wenn die Menschen insgesamt so erholt sind, dass sie genug Reserven haben, um im absoluten Ausnahmefall mal eine „Sonderschicht“ einzulegen.

Softwareentwicklung brauch Qualität

Bei uns arbeiten Softwareentwickler, die höchste Qualität liefern müssen. Unsere Kunden lassen uns Software programmieren, weil sie diese für ihre Geschäftsprozesse dringend brauchen. Dass diese Software funktioniert, ist für unsere Auftraggeber wichtig. Diese Systeme kann ich nicht von chronisch überarbeiteten und übermüdeten Programmierern erstellen lassen, die sich nur mit Kaffee und Cola oder Energy-Drinks wachhalten.

Wir schulden unseren Kunden, dass ausgeschlafene und zufriedene Softwarearchitekten, Programmierer und Tester für sie arbeiten. Diese Leute kommen morgens munter zur Arbeit, arbeiten acht Stunden konzentriert und machen dann Feierabend. Und am Wochenende erholen sie sich.

Und wir brauchen kreative Mitarbeitet, die auch mal an was anderes denken als ans Codieren. Was das ist und wieviel Zeit sie dazu brauchen, geht mich nichts an. Vielleicht trainieren sie für den Ironman und sitzen am Sonntag sechs Stunden auf dem Fahrrad, vielleicht haben sie einen alten Traktor, den sie hegen und pflegen und mit dem sie am Samstag an Treckerrennen teilnehmen. Vielleicht spielen sie mit ihren Kindern oder bauen ein Gartenhaus.

Gut fürs Unternehmen und die Kunden

Das alles ist am Ende gut für das Unternehmen, in dem sie arbeiten, denn sie bringen Ideen und Kreativität aus der Freizeit mit ins Büro. Ich hoffe nicht, dass meine Mitarbeiter abends und an Wochenenden ununterbrochen aufs Smartphone starren und darauf warten, dass ich ihnen eine Mail schreibe.

Das heißt nicht, dass ich niemals nach Feierabend eine Mail an einen Mitarbeiter schreibe. Und es kommt auch vor, dass ich hoffe, dass er sie in den nächsten Stunden liest. Wenn nicht, hab ich Pech gehabt. Wenn das Wohl des ganzen Unternehmens davon abhängen würde, dass die Mitarbeiter jederzeit erreichbar sind, hätte ich schon viel früher was Entscheidendes falsch gemacht.

Der Beitrag Warum ich keine Rund-um-die-Uhr-Erreichbarkeit will erschien zuerst auf INDAL Software-Spezialist.

Peer Review, die Qualitätskontrolle durch Kollegen, durch Fachleute, die den gleichen Job machen wie der Autor selbst, ist mehr als dass einer zum anderen sagt: “Hey, schau dir doch mal an, was ich da gemacht habe und sag mir mal, ob dir irgendwelche Fehler auffallen”. Peer Review ist ein organisierter und weitgehend formalisierter Prozess, und nur als solch ein Prozess ist er eine Methode zur Qualitätssicherung im Projekt.

Peer Review kann für die Qualitätsprüfung aller Lieferbestandteile eines Projektes eingesetzt werden, seien es Anforderungsdokumente, Spezifikationen, Projektpläne, Software-Module oder Handbücher. Besonders effizient ist es allerdings bei Anforderungsdokumenten und Spezifikationen, deren Qualität nicht wie bei Software im Black-Box.Verfahren getestet werden kann und bei denen (im Gegensatz zu Projektplänen und Handbüchern) meist eine ausreichende Zahl von Peers, also von Kollegen, die ebenfalls Dokumente dieses Typs schreiben, zur Verfügung stehen.

Ähnlich wie beim wissenschaftlichen Peer Review sollte sich auch im IT-Projekt der Autor nicht selbst seine Peers zur Kontrolle aussuchen, dazu wird die Rolle des Editors eingeführt. Der Editor wählt für jedes Dokument wenigstens zwei Peers aus, die dieses begutachten. Die Gutachter geben ihre strukturierten und formalisierten Gutachten (dafür gibt es entsprechende Templates) zum vereinbarten Termin an den Editor, möglicherweise mit einem Vorschlag zum weiteren Verfahren. Der Editor entscheidet dann, ob das Dokument freigegeben wird oder ob es nach Überarbeitung entweder direkt freigegeben werden kann oder erneut durch den Review muss.

Wie das Peer Review genau durchgeführt wird, hängt von einer reihe von Projektparametern ab, danach ist auch zu entscheiden, ob gemeinsame Sitzungen der Peers mit dem Autoren durchgeführt werden, was Vor- aber auch Nachteile hat. Wirklich effizient wird der Peer Review erst durch die Anpassung des Verfahrens an die konkrete Projektsituation.

Peer Review im Softwareprozess ist eine zeitsparende Methode zur Qualitätssicherung, die gleichzeitig das Projektwissen gut verteilt.

Der Beitrag Peer Review im Softwareprojekt erschien zuerst auf INDAL Software-Spezialist.