Facebook
0
Twitter
0
Google+
1
Kommentare
1

Versuch’ es doch einfach mal.

Das Metier in dem wir arbeiten ist eines der jüngsten. Softwareentwickler können nicht auf eine tausendjährige Tradition zurückschauen, wie es andere Handwerker können. Unsere Standards und Traditionen sind nicht so gefestigt, wie bei anderen. Trotzdem gibt es Richtlinien und Best-Practices, die sich über die letzten Jahre geformt haben. Dies haben wir nicht zuletzt Personen zu verdanken, wie Martin Fowler, der das Refactoring standardisiert hat, Robert C. Martin mit seinem Klassiker zum Thema Clean Code oder der Viererbande, die die Entwurfsmuster niedergeschrieben haben.

Standards scheinen auch in der Softwareentwicklung ein gerne angenommenes Geschenk zu sein, doch leider gibt es immer wieder den Trend zu sagen, dass Standards toll sind, sie aber leider nicht auf die aktuelle Situation passen. Dies ist ein wiederkehrendes Muster bei Bibliotheken [Die Bibliothek], aber noch häufiger sträuben sich Softwareprofis, wenn es um Prozesse geht.

In traditionellen Unternehmen sind es nicht die Entwickler, die die Prozesse machen, sondern das Management oder die Projektverantwortlichen. Wenn die Personen an der organisatorischen Spitze gut und erfahren sind, ist dies auch von Vorteil, da sie sich stärker mit der Materie befasst haben. Leider besteht häufig eine anscheinend natürliche Spannung zwischen Projektmanagement und Softwareentwicklung.

Programmierer neigen dazu Prozessfragen erst einmal sehr kritisch zu sehen. Jede Vorgabe, die einen daran hindert genau so zu arbeiten, wie es für einen als Individuum am besten ist, wird primär als Behinderung wahrgenommen.  Jeder Mensch ist einzigartig, warum sollte es eine funktionierende Methode geben alle möglichst produktiv zu steuern. In dieser Aussage stecken gleich zwei „Fehler“. Sind wir wirklich so unterschiedlich? Als Person betrachtet mag dies natürlich stimmen, wenn man aber die Person in ein Unternehmensumfeld steckt, so achtet man darauf, dass ein Team homogen zusammengestellt wird. Man ähnelt seinen Kollegen mit der Zeit immer mehr – so wie es bei Ehepaaren auch zu beobachten ist. Auch ein Teamleiter ist gut damit beraten sein Team so zusammenzustellen, dass ein ähnliches Gedankengut vorhanden ist. Die zweite falsche Annahme ist, dass es wichtig ist, dass man als einzelner maximal Produktiv sein muss. Natürlich arbeitet man gerne so optimiert wie möglich, das steht außer Frage. Einem Projektverantwortlichen ist es nicht wichtig, dass ein bestimmter  Mitarbeiter produktiv ist, sondern das Team muss maximale Leistung bringen. Wenn dies bedeutet, dass einer der Kollegen nicht sein ganzes Potential ausschöpfen kann, dann muss man damit umgehen können. Einfach ist dieses Umdenken sicher nicht, denn man muss sein egozentrisches Weltbild liegen lassen und das Gesamte sehen. Hat man dies geschafft, kann es einfacher sein, das Projektmanagement und seine Methoden zu verstehen.

Ein Paradebeispiel und gerade derzeit sehr aktuell ist die Einführung von agilen Prozessen, wie zum Beispiel Scrum. Obwohl es eine enorme Erleichterung für den Softwareentwickler bedeutet, ist er häufig sehr kritisch dem gegenübergestellt. Zu viele Unbekannte gilt es zu verstehen. Gewiss sollte man in einer solchen Situation nicht beginnen die neue Methodik zu bekämpfen. Den Gedanken, dass das eigene Projekt so individuell und das Team so besonders ist, dass dieses Vorgehen bei anderen klappen kann, aber leider bei einem selbst nicht, sollte man fürs erste unterdrücken.

Standards entstehen nicht einfach. Die meisten wurden von Experten erstellt, die sich mit der Thematik auskennen und die jahrelange Erfahrungen haben. Standards befinden sich bei anderen auch im täglichen Einsatz und dort funktionieren sie. Wenn man die Personen anspricht, die vor der Einführung kritisch waren, so werden die meisten sicher zurückrudern und sich eingestehen, dass es vielleicht doch eine gute Idee war.

Wichtig bei der Einführung neuer Standards ist, dass die Betroffenen offen mit dem Thema umgehen. Bedenken dürfen ausgesprochen werden, dürfen einen aber nicht dabei behindern es auszuprobieren. Wenn nur genügend Leute versuchen unterbewusst ein System zu sabotieren, dann werden sie es auch schaffen – egal wie gut das System ist. Klar ist auch, dass der Aspekt des Ausprobierens ein wichtiger ist.

Wir leben in einer agilen Welt. Entscheidungen, die getroffen wurden können revidiert werden. Wenn nach ein paar Wochen klar ist, dass der Standard wirklich nicht zu einem passt, dann hat man kaum etwas verloren. In den meisten Fällen wird man aber überrascht sein, dass es sich bei einem doch gut in das Gesamtsystem einbetten lässt.

„Leute, die sagen es kann nicht klappen, sollen denen nicht im Wege stehen, die es gerade machen.“

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

1 Comments

  1. Alles zu 100% Richtig – Das Problem liegt in der Umsetzung.
    Hier ist gefühlvolles Change Management für Organisationen/ organisationsteile gefragt: 1.) Veränderungen vorbereiten (Strukturen “weichmachen”). Jede Veränderung ruft Ängste hervor. Diese gilt es abzubauen. 2.) Neue Prozesse (oder Änderungen allgemein) einführen. Dabei darauf achten, die einzelnen Mitarbeiter “mitzunehmen”. GGf. Power Sponsoren benennen, die hinter der Sache stehen und die neuen Prozesse immer wieder vorleben. 3.) Neue Prozesse festigen. Üben, üben, üben und Feedback einfordern, um die gelebten, neuen Prozesse in den Tagesablauf optimal zu integrieren. 4.) Änderungen besprechen und das Team loben. Jeder sollte das Gefühl haben, selbst etwas bewirkt zu haben, was dem ganzen Team geholfen hat. Sehr wichtig für zukünftige Veränderungen und die Motivation. Im Idealfall entsteht soetwas wie eine offene “Optimierungskultur” im Team.

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen