In den letzten Monaten habe ich in vielen Beispielen erlebt, warum Entwickler enge Zeitvorgaben bekommen. Das ist natürlich nicht repräsentativ und beruht auf meiner ganz subjektiven Wahrnehmung. Ich will damit auch nicht unterstellen, dass ein Vorgesetzter wirklich so denkt. Ich vermute aber dass wenigstens unterbewusst folgende Faktoren eine Rolle spielen. Erschwerend kommt hinzu, dass ich selber Entwickler bin… also bitte nichts Objektives erwarten.
Aber erst mal Hand aufs Herz: Entwickler machen den Job, weil er ihnen Spaß macht, oder? Ich kenne nur wenige Entwickler, denen es keinen Spaß macht Software zu entwerfen und zu schreiben. Gerade das autonome Arbeiten an kleinen überschaubaren Programmen (meist "Werkzeuge" genannt) ist beliebt.
Die meisten Entwickler haben eine deutliche Technik-Affinität. Dazu gehört auch der Einsatz und der Test von neuen Programmiertechniken. Entwickler sind fast ausnahmslos sehr genaue und präzise Menschen, die auch vor Details nicht zurückschrecken. Ist ja auch klar: Wenn man dem Blechkasten nicht genau sagt, was zu tun ist, dann läuft es nicht. Es soll sogar Entwickler geben, die von Betriebswirten als pedantisch empfunden werdenn. Die oben genannten Eigenschaften führen gerne dazu, dass Entwickler etwas einseitig wahrgenommen werden.
Meiner Erfahrung nach haben Entwickler aber auch noch eine andere hervorragende Eigenschaft: Sie können sich beliebig lange mit einem Problem/Programm beschäftigen ohne dass ihnen die Arbeit ausgeht…
Als Beispiel fällt mit das kleine Kaffee-Programm ein, dass jahrelang in unserer Abteilung zum Einsatz kam: Wer sich eine Tasse nahm, rief das Programm auf und auf dem Server wurde für die Person eine Tasse Kaffee gezählt. Bald wurde ein "Tassenfaktor" eingeführt, der den Preis je nach Größe der Tasse berechnete (einige Kameraden hatten vielleicht Schüsseln!). Natürlich ist das ein schlechtes Beispiel, weil Kaffee für Entwickler eine sehr hohe Bedeutung hat… ;.)
Ich habe es aber oft genug erlebt, dass ein Entwickler im Bemühen seine Aufgabe gut zu machen, wirklich viel Arbeit in eine ansonsten eher unbedeutendes Detail steckte. Danach ist das Programm echt klasse und sehr beeindruckend. Für die Aufgabe hätte aber eine ganz einfache Ausführung genauso gute Dienste geleistet. Aber wäre der Entwickler dann mit seiner Leistung zufrieden gewesen? Hätte ihm auch nach einem Jahr noch jemand auf die Schulter geklopft und sich beeindruckt gezeigt?
Jedem Chef dem es einmal passierte, dass ein Mitarbeiter aus seiner Sicht für so etwas seine Zeit "verplemperte", der wird seine Lehre daraus ziehen.
Ein anderes Beispiel: Ich erlebte mehrfach, dass ein Entwickler mit seiner Aufgabe so ausgelastet war, dass er keine Zeit mehr hatte, um die Doku auch noch zu machen. Dann müsse der Termin um drei Tage verschoben werden oder das Feature XY wegfallen werden, das gehe schließlich nicht. Also wurde vorerst keine Doku gemacht. Nach Ablauf der Frist war das Programm tatsächlich fertig, aber aus ganz dringenden Gründen war mal eben noch diese und jene Funktion eingebaut worden. Und das ohne Terminverschiebung oder etwas weglassen zu müssen.
Was wird ein vernünftiger Chef das nächste Mal machen, wenn er die Aufgabe und Termine verteilt? Wird er großzügige Puffer einbauen und das den Entwicklern sagen?
http://www.heise.de/foren/go.shtml?read=1&msg_id=12489666&forum_id=39795
Dieses Thema ist in der Tat sehr heikel. Wie du richtig angemerkt hast, sind die meisten Entwickler sehr genaue Menschen, wenn nicht sogar Perfektionisten. So enthält eine Klasse (oder ein gesamtes Framework oder wie auch immer) schnell mal zusätzliche Funktionen zwecks Zukunftssicherheit, einfacherer Weiterarbeit, oder weil dadurch einfach etwas schöner gelöst werden kann. In den meisten Fällen erhöht sich dadurch (laufenden Arbeiten daran um es weiter zu verbessern) der zeitliche Aufwand, wodurch das Projekt eventuell auch nicht in der gewünschten Zeit fertiggestellt werden kann (man muss beachten, dass viele Projekte ohne solche Spielereien ohnehin nicht in der Zeit fertiggestellt werden können).
Was muss also her? Auf jeden Fall muss das Projektmanagement passen. Die einzelnen Tasks müssen genau und mit möglichst wenig Spielraum definiert sein. Laufende Fortschrittsüberprüfung ist definitiv Pflicht. Wenn der Entwickler (ich bin ja selbst einer) zuviel Freiraum besitzt wird gerne an der Kristallkugel gearbeitet, was zwar das Produkt verbessert, aber dafür den Aufwand gewaltig erhöht. Und der Kunde zahlt nun mal das Ergebnis, welches auch zeitgerecht abgeliefert werden sollte/muss.
In meinem letzten Projekt wurde viel darüber dieskuitiert, wie man das Projektmanagement verbessern könnte. Die meisten Entwickler sträubten sich aber so vehement gegen die Einführung von genaueren Werkzeugen, dass es schlißelich gelassen wurde. Dabei haben mich die Möglichkeiten des Team-Systems vom MS-Visual-Studio ziemlich beendruckt. Ein IBM-Fan sagte mir, dass es sowas von IBM auch schon lange gibt. Aber verwendet wird es bei uns auch nicht… 😉
> Ein IBM-Fan sagte mir, dass
> es sowas von IBM auch schon lange gibt.
In dem Artikel
Stefan Papp
IBM Rational Software Development Platform
versus Microsoft Team System
dotnetpro 4/2007, Seite 40
wird die Auszeichnung
Bug & Feature Tracking
IBM Rational ClearQuest
http://www.ftponline.com/mediakit/magazines/vsm/
genannt.
Rhetoriktraining für Softwareentwickler
http://www.prodevcollege.de/produkte-sprechertraining.html
Reklame
c't 21/07, Seite 48
Johannes Heuft
Der Weg zurück zur Software-Produktivität
ISBN 978-3-937446-88-2
http://www.federkultur.de/software.php
-
Frank Möcke (fm)
Kurze Geschichte der Informatik
Buchkritik, Friedrich L. Bauer, Wilhelm Fink Verlag
c't 21/07, Seite 230
ISBN 978-3-7705-4379-3
http://www.fink.de/katalog/list/abteilung/medienwissenschaft.html
Maik Schmidt (fm)
Smart & Gets Things Done
Buchkritik, Joel Spolsky, Apress
c't 25/07, Seite 232
ISBN 978-1-59059-838-2
http://www.apress.com/book/view/1590598385
http://www.joelonsoftware.com/
Maik Schmidt (fm)
Der Weg zurück zur Software-Produktivität
Antithesen zu gängigen Dogmen in der Softwareentwicklung
Buchkritik, Johannes Heuft, F.S. Friedrich Verlag
c't 26/07, Seite 218
(siehe oben)
Zur Rezension "Der Weg zurück zur Software-Produktivität"
in der c't 2007, Heft 26/07, Seite 218, von Maik Schmidt.
Als ich das Buch einigen Bekannten vor der Veröffentlichung
zum Lesen gegeben habe, haben diese mich vor solchen Reaktionen,
wie man sie nun in der c't nachlesen kann, gewarnt: Wenn man
Dogmen hinterfragt, dann sollte man vorbereitet sein auf die
Gemeinheiten, die diejenigen verbreiten, deren Lebensgrundlage
eben diese Dogmen darstellen.
Es ist mir klar, dass das Buch mit seinen klaren Aussagen
polarisiert. So hatte ich vor der Rezension privat Kontakt
mit mehreren Entwicklern, die Ruby oder Ruby-on-Rails
propagieren, über die Inhalte des Buches und bin erstaunt,
wie fanatisch und aggressiv von diesen argumentiert wurde.
Außerdem gab es Ressentiments wegen meiner Einschätzung zu
gewissen "Moden" und zu Quereinsteigern.
In dem Buch beschreibe ich in der Tat die Vorzüge und Nachteile
von einzelnen Programmiersprachen und einige Kriterien,
nach denen eine Programmiersprache ausgewählt werden sollte,
die außerdem im Sinne einer Kosten-Nutzen-Analyse verifizierbar
sein sollten. Obwohl ich Ruby nicht ausdrücklich erwähne, scheinen
diese Kriterien den Ruby-Vertretern ein Dorn im Auge.
In der Rezension werden mit keinem Wort die Axiome (Kosten-
Nutzen-Prinzip) und die meiner Meinung nach darauf aufbauende,
geschlossene Argumentationskette rund um die Softwareentwicklung
erwähnt. Statt dessen wird behauptet, ich wolle die Rückkehr
der "… wahren Helden im Alleingang …", habe eine
"Performance-Bessenheit" und die agile Softwareentwicklung
sei meinen Vorstellungen um Längen voraus.
Wer die Abschnitte über die Zusammensetzung und Zusammenarbeit
von Teams gelesen und verstanden hat, der weiß, dass von
Alleingang nicht die Rede sein kann und ich das "heroic
programming", das ich erwähne, nicht empfehle.
Zu Performance: Bei allen von mir bisher mitgestalteten
Projekten, egal ob Embedded, Betriebssystem, Compiler oder
Applikation, stellte sich früher oder später die Performance-
Frage. Performance hat etwas zu tun mit der guten Verwendung
von Ressourcen. Letzendlich gibt es dann auch einen Bezug
zum Energiebedarf. Vertreter der "Performance ist egal"-Fraktion
müssen aufpassen, das sie und ihre Produkte nicht aus den
zukünftigen "grünen Rechenzentren" verbannt werden. Auch hier
sollte wieder die von mir durchgängig empfohlene
Kosten-Nutzen-Analyse angewendet werden. Nicht zuletzt
unterzieht c't allen möglichen und unmöglichen Dingen einer
Performance-Analyse.
Zu "agile": Das ist mittlerweile ein Schlagwort, das zu viele
Leute für sich in Anspruch nehmen. Dem "Agile Manifesto" stehe ich
positiv aber kritisch gegenüber, weil es ohne weitere Erläuterungen
zu Missverständnissen führt. Weiterhin wird die Diskussion darüber
von zu vielen Vertretern aus der Lehre und von zu wenigen Praktikern
geführt, die (wie ich) dazu nur wenig Zeit aufbringen können.
Wo "agile" draufsteht, ist zu oft kein "agile" drin.
Ich bin gerne bereit, über alle diese und andere Dinge rund um
die Software-Entwicklung in einem eigenen Forum zu diskutieren,
das ich abseits von dem Zugriff der Suchmaschinen halte möchte,
weil ich auch Lesern, die sich kritisch über Zustände in ihren
Betrieben äußern, eine gewisse Anonymität garantieren möchte.
Dazu kann sich jeder Leser an die im Buch angegebene E-Mail
Adresse wenden.
Zum Schluss noch ein wenig Eigenwerbung (und damit zurück zum Thema):
Wer als Softwareentwickler Probleme in seinem Betrieb sieht, sollte
das Buch lesen. Das gilt besonders, wenn das Problem im Management
zu suchen ist.