Erst Schreiben, dann tun...

In einem größeren Projekt arbeite ich als Ürojektleiter für drei Teilprojekte. Da komme ich nicht mehr selbst zum Programmieren. Vielmehr gehören Abstimmungen mit diversen Kunden, Tracking, Teambildung, Abrechnungsgefummel etc. zu meinen Aufgaben. Um herausfinden, ob ich was von meinen Tätigkeiten sinnvoll delegieren kann, habe ich jetzt eine Weile lang ein Log-Buch geführt. In dem Log-Buch habe ich jeweils mit Uhrzeit kurz aufgeschrieben, was ich gemacht habe. Die Log-Buch-Einträge sind zwischen 3 Minuten ("Smalltalk mit Entwickler XYZ") und 3 Stunden ("Releaseplanungsmeeting für ABC") lang.
Dabei habe ich ein paar interessante Dinge gelernt:

1. Ich mache viel zu selten Pause.
   
2. Das Führen des Log-Buchs ist fast kein Overhead (das hatte ich zunächst befürchtet).
   
3. Ich habe irgendwann angefangen, erst aufzuschreiben, was ich als nächstes tun werde und dann habe ich es getan. Das diszipliniert ungemein. Kein rumgetrödel mehr, kein E-Mail-Checken alle 15 Minuten, kein planloses Browsen im Internet. Das hat zu einer deutlichen Effizienzsteigerung bei meiner eigenen Arbeit geführt. Allerdings ist das auch anstrengender. Mehrere 10-Stunden-Tage am Stück kann ich so nicht durchhalten. Brauche ich jetzt aber auch nicht mehr. Mal sehen, wie sich diese Technik für mich in der Zukunft weiter bewährt.
   

Post bewerten

Verantwortung in der Softwareentwicklung

Das kennt man als Softwareentwickler: Der Chef oder Projektleiter kommt ins Büro und braucht unbedingt ganz schnell noch Feature XYZ für das anstehende Release. Also bauen die Entwickler das geforderte Feature mehr schlecht als recht ein. Es tut ungefähr das, was gefordert ist. Die interne Struktur ist aber äußerst bescheiden. Theoretisch kann man die interne Qualität später bereinigen. Es weiß aber jeder, dass man die Zeit dafür nicht bekommt. Also bleibt alles, wie es ist und das System degeneriert Stück für Stück. Für die meisten Entwickler ist das der unvermeidliche Gang der Dinge.
Die Entwickler sind also die Opfer ihrer chaotischen Chefs. Möglich. Allerdings ist diese Sichtweise weder nützlich noch ermutigend. Ich jedenfalls sehe mich ungern als Opfer. Und die Psychologen lehren uns, dass wir andere Menschen nicht ändern können. Wir können nur unser eigenes Verhalten ändern. Also brauchen wir gar nicht erst darauf zu hoffen, dass unsere Chefs zur Vernunft kommen. Was also können wir als Entwickler tun, um unsere Situation zu verbessern?
Ich schlage vor, dass Entwickler Verantwortung für ihre Arbeit übernehmen. Kein Entwickler darf Code programmieren, der seinen eigenen Qualitätsansprüchen nicht genügt. Auch dann nicht, wenn ein Chef oder Projektleiter Druck ausübt. Häufig bekommen die Chefs/Projektleiter dadurch genau das Feedback, dass ihnen bisher gefehlt hat. Sie konnten ja gar nicht einschätzen, wie stark sich ihre Sonderwünsche auf die interne Qualität des Systems ausgewirkt haben.
Und was ist, wenn der Chef/Projektleiter unbedingt auf der Quick-Hack-Umsetzung seiner Features besteht? Dann bedeutet das einfach nur, dass Entwickler und Chef/Projektleiter nicht zusammenarbeiten können.

Post bewerten