Direkt zum Hauptbereich

Arbeit und Leistung muss neu definiert werden


In der Physik ist Arbeit definiert als Kraft (zum Bewegen einer Masse) mal Weg und Leistung Arbeit durch Zeit.
In unserer Arbeitswelt war es über Jahrzehnte oder Jahrhunderte hinweg möglich daran angelehnt die erbrachte Leistung eines Arbeitnehmers (oder auch Auftragnehmers) in Zeit zu messen.

So erbrachte ein Arbeiter am Fließband eine gewisse Leistung messbar in gefertigten Teilen in einer gewissen Zeit.

In dem Zusammenhang ist es auch nachvollziehbar die dem Arbeitgeber (Auftraggeber) vertraglich geschuldete Arbeit in Zeiteinheiten z.B. Wochenstunden zu definieren. Diese Arbeit kann auch dann direkt gesehen werden. Steht der Arbeiter am Fließband und geht seiner Tätigkeit nach so erbringt er die geschuldete Arbeit. Tut er was anderes so erbringt er sie nicht. (Natürlich vereinfacht gesehen)

Aktuell findet ein Wandel in der Art der Arbeit statt. Es gibt immer mehr sogenannte "Wissensarbeit". Dabei ist wie z.B. in der Softwareentwicklung das Ergebnis der erbrachten "Arbeit" gar nicht mehr so greifbar und vor allem ist die Tätigkeit, welche zu dem Ergebnis führt nicht mehr so einfach definierbar. Eine "fertige" Software ist nicht das reine Ergebnis von physischer Tätigkeiten wie z.B. dem Tippen von Tasten. Sondern vielmehr von angewendetem und richtig kombiniertem Wissen. Das Tippen der Codezeilen ist nur noch die Nutzbarmachung der bereits erbrachten Arbeit. Dies ist mittlerweile auch so weit akzeptiert das wohl die wenigsten die Leistung ihrer Softwareentwickler in geschriebenen Codezeilen messen. (Was auch Kontraproduktiv für ein gutes Ergebnis sein kann).

Wenn die "Arbeit" nun aus dem aufbauen, anwenden und verknüpfen von Wissen also lernen, Kreativität, Problemlösen und kombinieren von Wissen, kurz denken und Kommunizieren besteht, dann fühlt sich das erfassen der "Arbeit" oder der erbrachten "Leistung" in Zeiteinheiten falsch an.




Denn ich kann nur schwer definieren wann und wo nun die entscheidende Denkarbeit statt findet. Wie ich ja hier schon erwähnt habe ist eine Pause oder Spielen und Mindwandering oft produktiver als das pure vor dem Computer sitzen und grübeln. Aber welche Zeit erfasse ich nun als Arbeitnehmer und wie schreibe ich darauf basiert eine Rechnung? Erfasse ich nur die Zeit vor dem PC in der ich mehr oder weniger produktiv zuordnbar an der Software / der Aufgabe arbeite? Auch wenn ich hier überhaupt nicht weiter komme? Und wenn ich nun einen Kaffee mit Kollegen trinke und beim informellen Austausch auf eine Idee komme oder anderswie weiter komme? Ist die Pause nun Arbeitszeit oder nicht? Interessant wird das vor dann wenn ich erst im Nachhinein feststelle dass dabei etwas "klick" gemacht hat.

Hinzu kommt, dass ich mein Gehirn nicht mit verlassen des Arbeitsplatzes in den Feierabend schicken kann. So arbeitet es auch zu Hause also Streng genommen in der Freizeit weiter. Erfasse ich dabei die Arbeitszeit auch? Was ist wenn die Idee Nachts oder am Wochenende kommt? Gibt es dann Zulagen? In wie weit ist das Lesen von Fachartikeln, Büchern und Blogs oder der Austausch in UserGroups der Arbeit zuzurechnen?

Das alles sind Hinweise, dass das Konzept der Arbeitszeiterfassung irgendwie nicht mehr passt. Und dennoch basieren die Arbeitsverträge auf Wochenarbeitszeiten. OK meist ist erkannt worden dass das so nicht ganz passt und es ist der Flatrate-Zusatz hinzugefügt worden, dass Arbeitszeit darüberhinaus auch mit dem Gehalt abgegolten ist. Aber ist es das? Wie "messe" ich dann, das ich meine mindest Arbeitszeit erbracht habe? Und warum wird dann im Büro noch seltsam geschaut wenn man mal nicht vor den Tasten sitzt?

Auch wenn es erste Bewegungen gibt, welche das veränderte Arbeiten aufgreifen und neue Wege weg vom nicht mehr passenden Tylorismus beschreiten, habe ich noch keine wirkliche Lösung hierfür gesehen.

Wie weise ich erbrachte Leistung nach, die nicht greifbar ist und wie berechne ich dies meinen Kunden? Diese bezahlen immer noch oft auf Stundenbasis. Und selbst bei Festpreisen wird versucht für die Firma über die Stundennachweise sicher zu stellen, dass nicht mehr Kosten entstehen als der Kunde bezahlt. Also muss am besten vor der Lösungsfindung schon irgendwie die Zeit geschätzt werden.

Ich habe aktuell keine Lösung. Aber wenn Software kein Selbstzweck ist, so löst sie ein Problem oder erleichtert am Ende eine "echte" Arbeit. und hier kann man ihren Wert wieder messen. Und ist das dann nicht die erbrachte Leistung?

Kommentare

Beliebte Posts aus diesem Blog

Eine Retro im Kreis

Für die letzte Retro habe ich die Tische und Stühle alle beseite gestellt um dann mit Klebeband (Malercrep) drei unterschiedlich große Kreise um einen Mittelpunkt zu kleben. Der innerste Ring war groß genug, dass das gesamte Team da drin Platz finden konnte. Für die erste Phase der Retro habe ich Kärtchen mit den Zahlen 50, 40, 30, 20 in den Ringen ve rteilt. Die 50 in der Mitte und dann absteigend nach außen. Um so eine Zielscheibe anzudeuten.

Mit dem Rücken am Tellerrand

Es ist gut auch mal über den Tellerrand zu schauen. Manchmal sind wir so in "unserer Welt" gefangen, dass wir den Rest gar nicht mehr wahr nehmen. Zum Beispiel muss ich mich immer wieder daran erinnern, dass nicht alle Menschen mindestens ein Smartphone haben. Oder das agile noch lange nicht Mainstream ist. Nur weil wir uns in einem Umfeld bewegen, in dem die Dinge so scheinen wie sie sind, heißt das noch lange nicht, dass dem auch so ist. Ein Typisches Beispiel für den Unterschied von Realität und Wahrnehmung der Realität. Aber auch um neuen Ideen eine Chance zu geben, welche scheinbar nicht funktionieren können, weil sie nicht in unsere Gedankenwelt passen ist es sinnvoll ab und an über den Tellerrand zu schauen. Heute habe ich noch einen Tweet, welcher darauf hinweist gesehen: Wenn uns das einmal bewusst geworden ist, dann neigen wir (oder zumindest geht es mir so) dazu möglichst oft über diesen Tellerrand zu schauen. Dabei kann es aber passieren, dass wir so

Der Wasserfall ist immer noch vorherrschend in der Softwareentwicklung

In den letzten Jahren sind viele "neue" Bewegungen auf der Bildfläche des Mainstream-Bewusstseins der Softwareentwicklung erschienen. Und viele aktuelle Studien berichten, dass die Agilität den Wasserfall abgelöst hat. In allen Softwareunternehmen und viele der Entwickler die ich treffe reden zumindest viel über Agilität. Wenn aber mal einen Schritt zurück macht sieht das (ideal) Bild eher so aus: Die neue Lösung wird mit Design Thinking gefunden und definiert. In der Entwicklung ist dann eher die Rede von agile (meist Scrum) und selten SoftwareCraftsmanship. Von der Betriebsseite heißt es nun DevOps. Aber dazwischen gibt es immer noch Brüche und es existiert keine Ganzheitlichkeit. Jahrzehnte lang haben wir in der Softwareentwicklung geglaubt und es so auch allen Kunden beigebracht, dass die "Cost of Change Curve" gilt und daher der Wasserfall als Vorgehen perfekt ist. (Was nun was bedingt, lass ich mal dahingestellt) Dadurch haben sich natürlich auch di