IT Management

Der Erfolgreiche Programmierer

1

Gestern habe ich auf dem PHP World Kongress 2010 einen Vortrag mit dem Namen „Der Efolgreiche Programmierer” gehalten. In diesem Vortrag ging es weniger um Software-Entwicklung und mehr darum, welche Eigenschaften und Methoden man bei sich selbst fördern sollte, um eine erfolgreiche Laufbahn als Software-Entwickler einzuschlagen. Erfolgreich muss dabei nicht unbedingt bedeuten, dass man die Karriereleiter aufsteigt oder kontinuierlich mehr Geld verdient, sondern kann z.B. auch bedeuten, langfristig einen interessanten Job zu haben.

Doch genug der Worte, hier sind die Slides des Vortrags:

Das war mein erster Vortrag, in dem nun weder Code, noch konkrete Empfehlungen für Tools zu finden sind. Ist eine ganz neue Erfahrung, auch in diesen Bereichen nun mein Wissen weiterzugeben.

PHP World Kongress 2010

0

PHP World Kongress 2010 - SpeakerWie schon letztes Jahr werde ich auch dieses Jahr wieder als Speaker auf dem PHP World Kongress vom 09.11. bis 11.11. in München vertreten sein. Dieses Jahr ist nicht nur Holger Rüprich wieder dabei (um wieder mit mir zusammen einen Workshop zu veranstalten), sondern auch Nico Steiner wird zum ersten Mal auf dem PHP World Kongress dabei sein und einen Vortrag zu Frontend-Performance zu halten. Nico ist Experte für Frontend-Technologien und -Architektur in meiner Abteilung bei der 1&1 Internet AG. Meine Session am ersten Tag der Konferenz steht dieses Jahr unter dem Motto „Der erfolgreiche Programmierer”, wie bereits letztes Jahr wird es weniger um PHP-Code und dafür mehr um persönliche Entwicklung und Zusammenarbeit gehen.

Was macht einen Programmierer erfolgreich? Nicht nur fachliche Kompetenz und eingesetzte Methodologien sind verantwortlich. Dazu gehören auch Soft Skills, die Wahl eines geeigneten Mentors, das Verfolgen einer eigenen Version und vieles mehr. Erfolgreiche Programmierer sind leidenschaftlich, pragmatisch und produktiv – dieser Vortrag zeigt, warum.

Am zweiten Tag laden Holger und ich dann zum dreistündigen Workshop mit dem Thema „PHP im Unternehmenseinsatz” ein, in dem wir einen Überblick über die aus unserer Sicht wichtigen Bereiche für die Erstellung unternehmenskritischer Applikationen geben.

PHP wird heutzutage fast schon selbstverständlich im professionellen Bereich eingesetzt. Doch auch die verwendeten Tools und Methodologien müssen professionellen Ansprüchen genügen. Dieser Workshop zeigt direkt wie PHP in großen Projekten eingesetzt wird und wirft einen Blick auf die Themen verwendete Methodologien, Software, Build-System, Projektmanagement, Teamführung und weitere Aspekte.

Die nächsten zwei Wochen werde ich jetzt nutzen, die Folien mit dem letzten Feinschliff zu versehen.

Webinale / IPC 2010 in Berlin

0

Eine PHP Konferenz in Berlin war für mich die ideale Kombination, endlich mal wieder meinen Koffer zu packen, in einen Zug zu sitzen und mich vier Tage in einem Hotel mit einer Menge Entwickler aufzuhalten.

Berlin fand ich spitze, aber da das hier kein Blog über Städtereisen ist, schreibe ich heute „nur” eine kurze Zusammenfassung dessen, was ich mit Nico und Frank auf der International PHP Conference Spring Edition 2010 und der Webinale 2010 erlebt und gelernt habe.

Die Workshops

Begonnen hat die Konferenz für mich mit einem Workshop am Sonntag nachmittag (morgens hatten wir eine Stadtrundfahrt, aber dazu wollte ich ja hier nichts schreiben). Der Workshop „Softwarearchitektur vs PHP” von Johann-Peter Hartmann war sehr unterhaltsam und mit der Vorstellung von ATAM (Architecture Tradeoff Analysis Method) habe ich auch etwas neues gelernt. Ich hatte zwar mit etwas mehr Inhalten zum Thema Architektur gerechnet und hätte auf den interaktiven Teil auch verzichten können, aber alles in allem war es ein interessanter Vortrag.

Montag

Der Montag startet mit zwei eher durchwachsenen Keynotes: Während der Vortrag „Die Mensch-Maschine-Beziehung und ihre Folgen” von Ibrahim Evsan unterhaltsam war, obwohl er nichts Neues erzählt hatte, war die Google-Keynote „Die Zukunft liegt in der Cloud” einfach nur langweilig. Der Gipfel war, dass Petra Sonnenberg zeigen wollte, wie in Zukunft alle unsere Applikationen in der Cloud laufen, gleichzeitig aber eine Präsentation mit Google Docs erstellt hatte, die aussah wie die ersten Gehversuche mit Power Point. Geendet hat die Keynote mit einem Werbevideo von Google. Nicht gerade das, was ich mir von einem Unternehmen wie Google versprochen hatte.

Danach kam das Highlight des Tages: Julian Koschwitz hat in seiner Session zu „Augmented Editorial Design” gezeigt, wie man klassische Printmedien mit dem Web verbinden kann und Magazine um dynamischen Content wie Videos oder Sound anreichern kann. Eine Webcam und ein Browser ist ausreichend. Ähnlich gut war die erste Session der IPC, die ich danach besucht habe. David Soria Parra hat sehr anschaulich dargestellt, wie „Git für Fortgeschrittene” Probleme beseitigt, die viele von uns mittlerweile mit Subversion haben.

Nachmittags ging es mit einem Vortrag zu „Continuous Integration und Continuous Deployment” von Manuel Pichler weiter, von dem ich mir auch mehr erhofft hatte. Manuel hat die zwar Bewegründe für CI und wie man es schrittweise einführt schön zusammengefasst, der Teil über Deployment ist leider sehr kurz ausgefallen und war für mich leider nicht hilfreich, da wir täglich und nicht nur wöchentlich deployen.

Abgeschlossen habe ich den Tag mit der für mich langweiligsten Session der Webinale: „Positive User Experience durch User Centered Web Design”. Meine Experience war in diesem Vortrag nicht sehr positiv, was zum Teil auch an der fortgeschrittenen Uhrzeit gelegen haben mag.

Dienstag

Der Dienstag morgen begann mit einem Vortrag zu „Frontend Performance mit PHP” von Frank und Nico, der sehr gut besucht war und mir auch noch ein paar neue Impulse gegeben hat, obwohl ich natürlich wußte, was auf mich zu kommt.

Da sich Jung von Matt für die aktuelle 1&1 Kampagne verantwortlich zeigt, habe ich mir danach die Session „Künftig entscheidend für den Erfolg (fast) jeder Marke: Produktinfo und -inszenierung” von Michael Behrens angeschaut. Die Beispiele, die er gezeigt hat, waren interessant, jedoch weit weg von dem, was JvM für 1&1 macht. Deutlich cooler waren auch die Beispiele, die Michael Chaize in seiner Session „Ten Innovative Projects for the Flash Platform” gezeigt hat. Von 3D-Grafiken über Gesichtserkennung bis hin zur Emulation von Spielekonsolen war da für jeden was dabei. Flash scheint (leider) trotz HTML5 immer noch nicht tot zu sein.

Durch das ständige Vertauschen von Sessions habe ich leider mittags einige Sessions verpasst und die Zeit genutzt, was für’s Büro zu programmieren. Abgeschlossen habe ich den Tag mit einer spontanen Session zu YQL von Yahoo!, in der leider nur die Standard-Beispiele gezeigt wurden.

Mittwoch

Den Mittwoch habe ich nach dem Hotel-Checkout wieder mit zwei Keynotes auf der Webinale begonnen. David Carr hat in seiner Keynote „The Speed of Now” den Namen zum Programm gemacht und ist extrem schnell durch eine Masse an Slides gegangen, so dass man ihm kaum noch folgen konnte. Ossi Urchs Keynote „Social Web oder Die neue Macht der Nutzer” klang eher nach einer Keynote von 2008 als nach einer Keynote in der man Trends für 2011 erfahren hätte. Das allgegenwärtige „Twitter, Facebook und Smartphones beherrschen unser Leben!” wurde am dritten Tag der Webinale dann doch etwas alt.

Danach fand die Panel Diskussion „Holy Code, holy Shit! – Die Developer-Designer-Hölle” statt, an der ich auch beteiligt war. Leider war es organisatorisch nicht möglich, dass sich alle Teilnehmer vorher treffen, so dass hier keine wirkliche Diskussion entstand und es eher bei „Thema verfehlt” einzuordnen war. Sollte ich jemals wieder an einer Panel-Diskussion teilnehmen, dann nur, wenn es vorher auch möglich ist, sich mit den anderen Teilnehmern und vor allem dem Moderator abzustimmen.

Nach der Mittagspause war ich dann mit meinem Vortrag „23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten” dran.

Der Vortrag lief gut, ich habe mir auch meinen „Cowboy/Indianer”-Witz merken können und das Feedback war durchweg positiv. Abgeschlossen habe ich den Tag mit einem Vortrag von Frank zum Thema „A better Approach for File System dependent tests”, in dem Frank sein Projekt vfsStream vorgestellt hat.

Zusammenfassend hat sich der Besuch der Konferenzen für mich mehr gelohnt, als das in den letzten Jahren der Fall war. Tatsächlich habe ich während der Konferenz jedoch festgestellt, dass mich die Themen der Webinale mittlerweile mehr fesseln als die Sessions auf der PHP Conference.

Aufwand schätzen, ohne Aufwand zu haben

8

„Haben Sie ein neues Projekt und der Kunde möchte möglichst schnell wissen, was es kosten wird? Wollen Sie agil arbeiten, aber Ihre Entwickler müssen das Geld ranschaffen und haben keine Zeit für langwieriges Planning Poker? Sind sie auch der Meinung, dass aufwändiges Planen überflüssig ist?”

Dann gibt es jetzt die Lösung: Verwenden Sie einfach „Planning Dice”. Mit „Planning Dice” können Sie jede Aufgabe innerhalb kurzer Zeit abschätzen, ohne dass Sie dafür wertvolle Entwickler-Ressourcen von der Software-Entwicklung abziehen.

Wie funktioniert „Planning Dice”?

Drucken Sie sich den „Planning Dice”-Bausatz aus und schneiden die Vorlage aus. Falten Sie den Bausatz an den vorgegebenen Linien und nutzen Sie die Klebeflächen, um den „Planning Dice”-Bausatz zu fixieren. Verwenden Sie dazu handelsüblichen Papierkleber oder bestellen Sie das Original-„Planning Dice”-Klebeset.

Nun sind Sie nur noch Sekunden davon entfernt, langwierigen Planungsmeetings Adieu zu sagen. Um den Aufwand einer Aufgabe zu schätzen, denken Sie einfach fest an die Aufgabe und lassen Sie den „Planning Dice” aus Ihrer Hand auf einen Tisch gleiten. Der „Planning Dice” wird Ihnen den Aufwand auf der zum Himmel gewandten Fläche anzeigen. „Planning Dice” paßt sich automatisch an die Größe Ihrer Aufgaben und das Know-How Ihrer Entwickler an, so dass die Werte als Stunden, Tage, Wochen oder Mannmonate zu interpretieren sind. Sollten Sie streng nach Scrum implementieren, so zeigt Ihnen „Planning Dice” natürlich Story Points an.

Sollte „Planning Dice” ein „?” anzeigen, so hat „Planning Dice” noch nicht all benötigten Informationen für eine verläßliche Schätzung. Fokussieren Sie sich erneut auf die zu schätzende Aufgabe und wenden Sie danach den Planning Dice erneut an.

Der Bausatz

Probieren Sie „Planning Dice” noch heute aus und überzeugen Sie sich von den beeindruckenden Ergebnissen. Laden Sie dazu „Planning Dice” hier herunter.

Planning Dice - Jetzt NEU!„Planning Dice” und große Projekte

Wir erhalten oft Anfragen von Projektmanagern, die die Vorteile von „Planning Dice” auch in großen Projekten einsetzen möchten und Planungen auf Vorstandsniveau in Sekunden erstellen wollen. Auch dies ist natürlich mit „Planning Dice” möglich.

Laden Sie sich dazu einfach einen zweiten „Planning Dice” herunter und befragen Sie gleichzeitig beide „Planning Dice”. Die angezeigten Werte müssen dabei einfach miteinander multipliziert werden und Sie erhalten die korrekte Schätzung für Ihr Projekt.

Natürlich skaliert „Planning Dice” noch weiter und Sie können die komplette Ressourcenplanung für das nächste Jahr mit Hilfe von zehn „Planning Dice” innerhalb weniger Sekunden erledigen. Vorbei ist die Zeit, in der Sie mühsam die Roadmap durcharbeiten mussten, um die Grobschätzung der benötigen Projektpersonentage für das nächste Jahr zu ermitteln.

Vielen Dank an Sebastian Lorenz, der diese nette Idee mit mir gesponnen hat.

Es gibt immer eine Alternative

1

Nachdem ich in letzter Zeit häufig Politiker zitiert habe, die etwas sinnvolles getan oder geleistet haben, macht dieser Trend mit einem Zitat der eisernen Lady Margaret Thatcher eine Kehrtwende. Die britische Premierministerin hat häufig die Floskel „There is no alternative.” verwendet. Ein Zitat, das bei mir keine positiven Gefühle auslöst.

Dieser Satz ist ein bequemer Weg, um eine Entscheidung zu begründen. So unwahr dieser Satz in der Politik ist, genauso unwahr ist es, wenn es um Software-Entwicklung oder das Management von Entwicklungs-Teams geht. Wenn jemand Ihnen glauben machen will, dass Sie unbedingt eine Rules Engine/Scala/PHP/einen Application Server einsetzen müssen, um ein Problem zu lösen und das damit begründet, dass das der einzige Weg ist, das Problem zu lösen, dann schauen Sie besser genauer hin.

Statt des einzigen Wegs ist es meistens eher der einzige Weg, den die entsprechende Person kennt, oder der, bei dem er nichts neues lernen muss oder sogar der, der einem Consultant das meiste Geld bringt.

Die Gründe für die scheinbare Alternativlosigkeit werden Ihnen natürlich nicht mitgeteilt. Mit dem Satz „Es gibt keine Alternative.” wird nur versucht, eine Diskussion über mögliche Wege von Anfang an zu unterbinden.

Der französische Soziologe Pierre Bourdieu hat für dieses Muster den Begriff „TINA-Prinzip” geprägt, in Anlehnung an die Anfangsbuchstaben von „There Is No Alternative.” Passend dazu hat die Politikwissenschaftlerin und ehemalige Greenpeace-Vorstandsmitglied Susan George dem TINA-Prinzip den Aufruf „TATA!” entgegengestellt:

There Are Thousands of Alternatives!

Ob Sie dem TINA- oder dem TATA-Prinzip folgen, liegt bei Ihnen, Sie haben die Alternative.

Verbotene Wörter

3

Vor kurzem hat mir Frank von einem Team erzählt, in dem man auf Fragen nur mit drei Antworten reagieren darf: „Ja.”, „Nein.” und „Ich weiß nicht.”. Sätze wie „Das sollte so funktionieren.” oder „Wenn alles glatt geht, müsste das klappen.” sind in diesem Team verboten.

Das wollte ich mal zum Anlass nehmen, eine Liste von Wörtern und Redewendungen aufzustellen, die ich (zumindest im Berufsleben) nicht mehr hören möchte, besonders wenn es um Aufwand, Lösungen oder Termine geht.

sollten”, „müssten”, etc.

Der Konjunktiv ist der Feind einer jeden Projektplanung. Meistens verrät er einem nicht, unter welchen Bedingungen ein Arbeitspaket rechtzeitig fertig wird, oder unter welchen Bedingungen der Code wie erwartet funktioniert. Wenn Sie den Konjunktiv im Berufsleben hören, dann nehmen Sie so schnell wie möglich Reißaus.

sollen

Sollen” ist der kleine Bruder von „sollten” aber fast genau so schlimm. Was machen Sie, wenn Sie in einem Anforderungsdokument einen Satz wie „Die Antwortzeit des Service soll unter 200 Millisekunden liegen.” vorfinden? Ist das eine freundliche Bitte oder eine zwingende Anforderung? Was passiert, wenn diese Anforderung nicht erfüllt wird? Beim Einsatz des Verbs „sollen” bewegen Sie sich in einer Grauzone.

einfach”, „nur”, etc.

In der Software-Entwicklung gilt nicht „Weil einfach einfach einfach ist.”. Zwei Situationen sind fast nie identisch, das heißt, wenn heute etwas funktioniert hat, haben Sie keine Gewißheit, dass es morgen genau so funktioniert. Die Vokabeln „einfach” oder „nur” werden meistens eingesetzt, um einen Sachverhalt zu verharmlosen oder die Komplexität zu verstecken. Wenn Sie diese Wörter hören, dann schauen Sie besser genau so hin. Aber vielleicht sehe ich das einfach nur zu eng.

prinzipiell”, „eigentlich”, „normalerweise

Ist der aktuelle Fall der Normalfall, oder wird jetzt gerade gegen das Prinzip verstoßen? Ich möchte nicht wissen, wann ein Arbeitspaket unter anderen Umständen eigentlich fertig wird, sondern wann genau in diesem konkreten Fall mit der Fertigstellung des Arbeitspaketes zu rechnen ist. Vor Jahren habe ich mit einem guten Freund gearbeitet, dessen Shop-Projekt monatelang „normalerweise nächste Woche fertig werden sollte”.

Was ist daran schlecht?

Warum möchte ich diese Wörter nicht hören? Sie machen es mir schwer, zu reagieren. Wenn das Projekt normalerweise pünktlich fertig gestellt werden sollte, dann sagt mir das das selbe, als würde das Projekt wahrscheinlich nicht rechtzeitig fertig und damit bin ich wieder genau so schlau wie vorher.

Ein „Wir hatten Probleme mit den Unit-Tests und werden nicht zum geplanten Termin fertig. Es dauert eine Woche länger.” zeigt mir klar, woran ich bin und ermöglicht mir (und dem Team) Maßnahmen zu ergreifen. Es geht hier um Verbindlichkeit, die nötig ist, um entsprechend reagieren zu können. Ob dies bedeutet, einfach Funktionalitäten außen vor zu lassen, um den Termin zu halten, oder stattdessen den Termin zu verschieben, hängt vom Projekt ab.

Aber warum hört man diese Wörter trotzdem so oft, wenn es darum geht, einen Termin zu bestätigen oder frühzeitig abzusagen? Meistens möchte man damit schlechte Nachrichten vermeiden und hofft, den Termin doch noch irgendwie zu halten. Damit wird die schlechte Nachricht in den meisten Fällen jedoch nur verschleppt, wenn der Termin nicht doch noch, wie durch ein Wunder, gehalten werden kann.

Wie kann man es verhindern?

Erschießen Sie nicht den Überbringer der schlechten Nachricht und schaffen Sie eine Kultur, in der man eigene Fehler zugeben und schlechte Nachrichten überbringen kann, ohne mit Sanktionen rechnen zu müssen. Belohnen Sie Verbindlichkeit und signalisieren Sie so, dass es Ihnen lieber ist, früh die schmerzhafte Wahrheit zu erfahren, anstatt sich lange in trügerischer Sicherheit zu wiegen.

Probieren Sie einfach, dann sollte das eigentlich auch in Ihrem Team funktionieren.

Jeder ist entbehrlich – außer John Rambo

2

In Rambo II – Der Auftrag wird John Rambo von seinem ehemaligen Vorgesetzten aus dem Gefängnis (in das man in nach Rambo – First Blood gesteckt hat) geholt und nach Vietnam geschickt. Dort soll er Photos von Kriegsgefangenen machen, die auch viele Jahre nach dem Vietnamkrieg dort festgehalten und gefoltert werden.

Unterstützt wird John Rambo dabei von der Vietnamesin Co Bao, in die er sich während seines Einsatzes verliebt und von Captain Vinh getötet wird. Rambo schwört Rache und befreit die Kriegsgefangenen unter Einsatz seines eigenen Lebens aus den Klauen des Vietcong.

Vor ihrem Tod führen Rambo und Co Bao die folgende Unterhaltung.

Rambo: „Ach weißt Du, ich bin entbehrlich.”
Co Bao: „Was bedeutet entbehrlich?”
Rambo: „Das ist so, als wenn man zu einer Party eingeladen wird, und dann nicht hingeht. Es spielt einfach keine Rolle.”
Co Bao: „Rambo, Du bist nicht entbehrlich.”

John Rambo ist also nicht entbehrlich. Doch was hat er davon? Immer wieder, wenn es Probleme gibt, muss Rambo sein Leben einsetzen, um diese Probleme zu lösen. Was das aus ihm gemacht hat, sieht man sehr gut im ersten Film der Rambo Reihe: In First Blood kommt Rambo aus dem Krieg zurück in eine Kleinstadt und ist so traumatisiert, dass er sich vom Sheriff provozieren läßt und einen Kleinkrieg anfängt. Am Ende des Films wird er von der Armee eingesperrt und erst wieder auf freien Fuß gesetzt, als man ihn bei einem Todeskommando braucht. Ähnlich ergeht es Rambo in den Jahren danach, statt Vietnam muss er in Rambo III nach Afghanistan. Selbst als er sich in „John Rambo” einen Altersruhesitz in Thailand aufbauen möchte, und wirklich keinen Ärger mehr sucht, kommt er nicht zur Ruhe. Stattdessen muss er eine Gruppe Missionare aus Burma retten, die nicht auf ihn hören wollten. Sein Leben wiederholt sich immer wieder.

Viele Software-Entwickler wollen so sein, wie John Rambo: unentbehrlich. Sie sind glücklich, wenn sie die einzigen sind, die wissen, wie man mit einer bestimmten Datenbank oder einer Legacy-Applikation umgeht. Wenn es Probleme mit dieser Datenbank oder dieser Anwendung gibt, dann muss man beim einzigen Entwickler vorsprechen, der sich damit auskennt und ihn bitten, diese Probleme zu lösen. Wenn man so manchen „unentbehrlichen” Entwickler reden hört, dann lassen sich diese Probleme auch nur, wie von John Rambo, unter „Einsatz des eigenen Lebens” lösen.

Auch wenn es anfänglich schmeichelt, immer dann gerufen zu werden, wenn es Probleme gibt, bringt diese Unentbehrlichkeit auch negative Seiten mit sich. Einem solchen Entwickler wird die Möglichkeit genommen, sich weiter zu entwickeln. Er bleibt auf der aktuellen Position sitzen, weil er ab und zu an dieser Stelle dringend gebraucht wird. So wie Rambo in Friedenseiten langsam zu einem Relikt aus alten Zeiten wird, geht es auch diesen Entwicklern. Und wenn die Systeme des Entwicklers sterben, so stirbt auch der Entwickler mit ihnen. Und wie John Rambo in Thailand, möchte ein Entwickler sich später einmal neu orientieren. So lange er in seinem alten Job nicht entbehrlich geworden ist, wird er dort immer zu jeder Tages- und Nachtzeit gerufen werden.

Falls Sie also ein „unentbehrlicher” Entwickler sind, lauet mein Rat an Sie: „Seien Sie nicht John Rambo, machen Sie sich entbehrlich.

Dringlich vs Wichtig

4

Wenn Sie ein Team oder eine Abteilung von Software-Entwicklern leiten, dann landen jeden Tag eine unglaubliche Menge an Todos auf Ihrem Tisch. Das Tagesgeschäft wird erdrückend und Sie sind nicht mehr in der Lage, die strategische Planung zu machen, die eigentlich eine Ihrer Hauptaufgaben sein sollte. Sie müssen also das Tagesgeschäft reduzieren, aber wie entscheiden Sie, welche Aufgaben Sie selbst erledigen und welche Sie delegieren?
Machen Sie doch dazu das, was vor Ihnen schon Dwight D. Eisenhower (Präsident der Vereinigten Staaten von Amerika von 1953 bis 1961) gemacht hat und wenden Sie das Eisenhower-Prinzip an.

Bei diesem Prinzip prüfen Sie für jede Aufgabe, die es zu erledigen gilt, wie wichtig und wie dringlich diese ist. Doch bedeutet dringlich und wichtig nicht das selbe? Sehen Sie sich dazu die folgenden Definitionen der Begriffe an.

Dringlichkeit: die Notwendigkeit, eine wichtige Handlung kurzfristig zu erledigen, also die (zeitliche) Priorität.

Wichtigkeit: die schwerwiegende (wichtige) Bedeutung eines Gegenstandes.

Die Dringlichkeit einer Aufgabe bezieht sich also auf die Zeit, die zur Verfügung steht, um die Aufgabe zu erledigen, während sich die Wichtigkeit der Aufgabe immer auf den Inhalt der Aufgabe bezieht. Wenn Sie auf die Toilette müssen, so ist das meistens eine dringliche Angelegenheit, es kann hier schnell zu spät sein und dann noch auf die Toilette zu gehen, bringt Ihnen keinen Nutzen mehr. Einen guten Schulabschluss zu schaffen ist eine wichtige Aufgabe, die auch noch Nutzen bringt, wenn Sie sie ein oder zwei Jahre später abschließen, als dies geplant war.

Das Eisenhower-Prinzip

Wenn Sie nun Ihre Aufgaben nach deren Dringlichkeit und Wichtigkeit bewertet haben, dann nehmen Sie sich das folgende Koordinatensystem vor und platzieren Ihre Aufgaben auf den Achsen wichtig und dringlich.

Jede Ihrer Aufgaben sollte nun einem der Bereiche A-D zugerdnet worden sein. Manche Aufgaben sind wichtig aber nicht dringlich, manche sind dringlich jedoch nicht wichtig, manche sind beides und so einige sind wahrscheinlich weder wichtig noch dringlich. Mit dieser Einteilung ist die Entscheidung leicht, wie mit den einzelnen Aufgaben verfahren werden soll.

A-Aufgaben: Diese Aufgaben sind wichtig und sie müssen schnell erledigt werden. Das bedeutet, Sie erledigen die Aufgaben sofort und selbst. Die Delegation und die Kontrolle der Aufgabe würden zu viel Zeit beanspruchen.

B-Aufgaben: Diese Aufgaben sind wichtig, jedoch nicht dringlich. Definieren Sie schon jetzt, wann Sie diese Aufgaben erledigen werden und tragen Sie sich einen Blocker in Ihren Kalender ein. Stellen Sie auch sicher, dass Sie die Aufgaben zum geplanten Termin erledigen.

C-Aufgaben: Diese Aufgaben müssen schnell erledigt werden, es sind aber keine wichtigen Aufgaben. Delegieren Sie sie! Das sind genau die Aufgaben, die Sie von den wichtigen B-Aufgaben abhalten, wodurch diese plötzlich neben wichtig auch noch dringlich sind. Also sorgen Sie dafür, dass die C-Aufgaben von jemand anderem erledigt werden.

D-Aufgaben: Diese Aufgaben sind weder wichtig, noch dringlich. Das bedeutet also, sie bringen keinen Nutzen. Diese Aufgaben werden also weder sofort noch später erledigt, sondern gehören einfach nur in den Papierkorb.

Wenn Sie Ihre Aufgaben regelmäßig mit dem Eisenhower-Prinzip priorisieren, dann können Sie sicher sein, dass Sie Ihre Zeit und die Zeit Ihrer Mitarbeiter sinnvoll einsetzen. Besonders hervorheben möchte ich hierbei das regelmäßige Priorisieren: Wichtige Aufgaben, die letzte Woche nicht dringlich waren, werden es wahrscheinlich werden, wenn Sie nicht bearbeitet werden.

Kleine Schritte sind besser als keine Schritte

1

Eigentlich hatte unter diesem Titel geplant, einen Eintrag über die Pfadfinder-Regel zu schreiben, die Robert C. „Uncle Bob” Martin in seinem Buch Clean Code vorstellt:

Leave the campground cleaner than you found it.

Genau an dem Tag, als ich den Eintrag schreiben wollte, kamen mir jedoch Nils und Holger zuvor. Mein erster Impuls war, meinen Eintrag einfach zu löschen und das Thema zu den Akten zu legen. Doch Schritt für Schritt (wer findet hier den Wortwitz?) bin ich wieder zu der Idee zurück gekehrt.

Die Überschrift „Kleine Schritte sind besser als keine Schritte” war das Motto von Willy Brandt (dt. Bundeskanzler von 1969 bis 1974), der damit seine Ostpolitik der langsamen Annäherung beschrieben hat.

Willy Brandt hat bei diesem Zitat sicher nicht an Uncle Bob, Coding Standards und kleine Refactorings gedacht. Sehr viele Entwickler, die sich die Pfadfinder Regel auf die Fahne schreiben, beschränken diese jedoch zu stark auf den Quellcode und wenden diese nicht ganzheitlich auf die eigene Arbeit und das Umfeld an. Richtig aufgefallen ist mir das auch erst in den letzten Wochen, in denen ich ausführlich mit Holger über Clean Code und die Einührung der Prinzipien in unseren Teams gesprochen habe.

Wenn Willy Brandt diese Regel auf eine Ostpolitik angewandt hat und damit eine Annäherung an Polen und die damalige Sowjetunion damit geschafft hat, dann sollten wir diese Regel auch in unserem täglichen Arbeitsumfeld anwenden können.

Ein gutes Beispiel ist, dass ich auf Konferenzen, auf denen ich über Clean Code, Testgetriebene Entwicklung und eine Menge andere „gute Dinge” geredet habe, am Ende immer gefragt werde, wie man diese in Teams einführt. Für die Teilnehmer sieht das immer nach einem großen Schritt aus, ein Team, das kein Verständnis für eine geminesame Code-Basis, Qualität und Entwicklungsmethodik hat, in ein Team zu transformieren, das bei der Entwicklung und der Pflege des Codes harmonisiert. Meine Antwort ist auch hier immer die selbe: Man muss es in kleinen Schritten angehen. Sie werden es nicht schaffen, das Bewußtsein für neue Entwicklungsmethodiken bei allen Teammitgliedern sofort zu wecken, also wecken Sie es bei einem und schauen Sie, wie es sich danach entwickelt.

Ähnlich verhält es sich bei der klassischen Beförderung vom Entwickler zum Leiter eines Entwicklungsteam. Sie können planen, wie Sie als perfekter Teamleiter sein könnten und diesen Plan dann in einem Jahr umsetzen. Oder Sie fangen morgen an und erledigen eine Teilaufgabe Ihres neuen Jobs mit Bravour und gehen dann die nächste an.

Sei es also ein neues Projekt oder ein neuer Job, der eine große Veränderung bedeutet, so ist der erfolgsversprechende Weg der, der mit vielen kleinen Schritten auf ein Ziel führt, das sich vielleicht sogar während des Wegs verändert.

Und wäre das nicht zu dramatisch für das Ende eines Blog-Artikels, würde ich jetzt schreiben:

Danke Willy Brandt. Danke Uncle Bob. Danke Holger.

Meeting Manieren

0

Meetings – Man kann nicht ohne sie arbeiten, aber auch nicht mit ihnen.

Leider sind Meetings unter Entwicklern oft verpöhnt und haben den Ruf, dass dort nicht gearbeitet, sondern nur heiße Luft produziert wird. Das muss aber nicht so sein. Dass Meetings oft unproduktiv sind, liegt nicht in der Natur der Meetings, sondern daran, wie diese durchgeführt werden. Dabei gibt es ein paar einfache und logische Regeln, deren Befolgung die Ergebnisqualität von Meetings positiv beeinflussen.

Keine ad-hoc Meetings.

Wenn Sie wollen, dass die Teilnehmer Ihres Meetings sich vorbereiten können (und ich ich hoffe, dass Sie das wollen), dann müssen Sie Ihnen Zeit dafür geben. Also kündigen Sie Ihr Meeting nicht erst 30 Minuten vor geplantem Beginn an, sondern besser eine Woche. Das ermöglicht allen Teilnehmern, sich in das Thema einzuarbeiten, und somit auch, im Meeting etwas beizutragen.

Natürlich wird es Situationen geben, in denen Sie nicht die Möglicheit haben, eine Woche zu warten (Ihr Projekt  fährt gegen die Wand, Sie müssen ein Vorstandsreporting abgeben, etc.), aber das sollten Ausnahmefälle sein und nicht die Regel.

Setzen Sie sich ein Ziel.

Natürlich sind Sie schon selbst darauf gekommen, dass ein Meeting ohne Ziel keinen Sinn macht. Das ist nicht das Problem. Das Problem ist, dass viele Meetings nicht ein Ziel haben, sondern gleich drei oder vier oder zwölf. Das führt dazu, dass Sie sich im Meeting an zu vielen Zielen orientieren müssen und meist keines der Ziele erreichen oder zumindest nicht das Wichtigste.

Setzen Sie sich also ein Hauptziel, wie zum Beispiel „Nach dem Kick-Off sollen alle Teammitglieder die Vision unseres Projektes verstanden haben.” oder „In diesem Meeting klären wir, in wessen Verwantwortung der Datenbank-Import gehört.

Verschicken Sie eine Agenda.

Eigentlich sollte man meinen, dass eine Agenda zu jedem Meeting gehört. Nur leider bin ich persönlich in mehr Meetings gewesen, zu denen es keine Agenda gab, als in Meetings, zu denen ich vorab eine Agenda erhalten habe. Mittlerweile verweigere ich die Teilnahme an agendalosen Meetings. Wenn jemand nicht in der Lage ist, zusammenzufassen, wozu er meine Zeit benötigt, kann es aus meiner Sicht auch nicht wichtig sein, dass ich am Meeting teilnehme. Das Erstellen und Versenden einer Agenda hat noch weitere Vorteile:

  • Der Organisator des Meetings muss sich Gedanken machen, was im Meeting alles besprochen werden soll.
  • Jeder geplante Teilnehmer kann entscheiden, ob seine Teilnahme wichtig und sinnvoll ist, oder ob es besser wäre, einen Vertreter zu entsenden.
  • Bei langen Meetings hat jeder Teilnehmer die Möglichkeit, partiell nur zu seinen Themen teilzunehmen.
  • Jeder Teilnehmer kann sich entsprechend auf die Themen vorbereiten.
  • Die Agenda kann bereits im Vorfeld zu einer Diskussion führen, sie muss nicht in Stein gemeißelt sein, sondern kann nach dem Feedback der Teilnehmer angepasst werden.

Es versteht sich von selbst, dass die Agenda das zuvor definierte Ziel Ihres Meetings stützen sollte.

Eröffnen Sie das Meeting.

Auch die Eröffnung eines Meetings gehört zu den Selbtverständlichkeiten, die leider viel zu oft ignoriert werden. Wenn Sie zu einem Meeting einladen, dann sagen Sie auch zumindest den ersten Satz im Meeting. Punkt. Sie können das Wort gerne an einen Experten weitergeben, der dann detailliert in das Thema einführt, aber zumindest die Begrüßung muss der Organisator übernehmen. Bei der Eröffnung des Meetings sollten Sie auch folgende Regeln berücksichtigen:

  1. Beginnen Sie mit einer Vorstellungsrunde. Gehen Sie nicht davon aus, dass sich alle Teilnehmer bereits kennen. Auch wenn dies der Fall sein sollte, so sind die Teilnehmer in anderen Rollen und anderen Aufgaben anwesend, als die vielleicht in anderen Projekten der Fall war. Bieten Sie also allen Teilnehmern die Möglichkeit zu erklären, warum sie ein „Eisen im Feuer” dieses Meetings haben.
  2. Bringen Sie alle Teilnehmer auf den selben Stand. Als Organisator haben Sie sich am bestmöglichsten mit dem Thema des Meetings vertraut gemacht. Treffen Sie nicht die Annahme, dass auch alle anderen Teilnehmer genau wissen, wie der aktuelle Stand des Projektes ist. Das die Agenda den Teilnehmern die Möglichkeit gibt, sich vorzubereiten, bedeutet nicht, dass alle vorbereitet sind.
  3. Beginnen Sie das Meeting mit einem lockeren Gespräch und ermöglichen Sie allen Teilnehmern anzukommen, bevor Sie hart ins Thema einsteigen. Der Wechsel von einem Thema in ein anderes benötigt ein paar Minuten.

Die Eröffnung des Meetings kann sehr kurz gehalten werden und muss nicht mehr als zwei bis drei Minuten in Anspruch nehmen.

Verfolgen Sie das Ziel.

Niemandem hilft ein Ziel, das nicht erreicht, oder zumindest aktiv verfolgt wird. Wenn Sie sich ein Ziel gesetzt haben, dann prüfen Sie auch im Meeting regelmäßig, ob Sie noch in der Richtung des Ziels unterwegs sind. Wenn nicht, so greifen Sie korrigierend ein.

Die Überschrift dieser Regel lautet mit Absicht nicht „Halten Sie die Agenda ein”. Die Agenda ist ein Hilfsmittel zur Erreichung des Ziels, sie ist nicht das Ziel. Auch das mittlerweile beliebte Timeboxing, bei dem Sie zwar alle Agendapunkte ansprechen, hilft Ihnen nicht per se Ihr Ziel zu erreichen.

Erstellen Sie ein Protokoll.

Wenn Sie wollen, dass die Ergebnisse des Meetings dauerhaft bestehen, dann halten Sie sie fest. Schreiben Sie ein kurzes Protokoll, machen Sie Photos der erstellten Flipcharts oder nehmen Sie die Flipcharts mit und hängen Sie in Ihr Büro. Wichtig ist, dass Sie die Ergebnisse auf irgendeine Weise dokumentieren. Wichtig ist dabei nicht, in welcher Form Sie das machen. Es muss kein Protokoll sein, in dem genau festgehalten wird, dass RG zusammen JR die E Muss im Detail besprochen werden” getroffen haben und daraus für EW das TTermin suchen” entstanden ist. Leider sind die meisten Protokolle hauptsächlich eine Sammlung von Abkürzungen und unwichtigen Informationen und genau deshalb so unbeliebt. Protokollieren Sie nicht, wer in welcher Reihenfolge mit wem gesprochen hat, sondern halten Sie die Ergebnisse fest.

Nur wenn Sie ein Meeting mit einer Agenda und einem Ziel, das Sie verfolgen, früh genug ankündigen und entsprechend nachbereiten, wird aus einem Treffen mehrerer Personen in einem Raum auch ein echtes Meeting, das einen Mehrwert bietet.

nach oben