Taskfokusiertes arbeiten oder Wie wir die Zeit anhalten

Wer kennt das Problem nicht. Man sitzt im Büro, eigentlich hätte man ja genug Arbeit, aber irgendwie kommt man mit der zu erledigenden Arbeit nicht weiter.

Das hat natürlich unterschiedliche Gründe:

  • Arbeit muss immer wieder unterbrochen werden
  • Ständig kommen neue Anforderungen dazu
  • Wir können uns schwer auf eine Sache konzentrieren
    Oft liegt es aber auch daran wie unsere Arbeit an uns heran getragen wird. Die Arbeiten sind geprägt von verschiedensten Daten, die Arbeit muss da begonnen werden und da muss sie fertig sein. In den seltensten Fällen geht es dabei um Einzelaufgaben, vielmehr geht es um eine ganze Menge von Aufgaben, die dann als ein gesamtes zu einem Termin fertig sein muss.

Zu alle dem gibt es auch noch Routine-aufgaben die auch zu erledigen sind. Diese Aufgaben sind oft nicht klar aufgelistet und dennoch müssen wir diese Aufgaben erledigen, und selbstverständlich haben auch diese einen Fertigstellungstermin.

Auf jeden Fall scheint alles Zeit getrieben. Somit muss es einen nicht verwundern wenn einige die Ansicht vertreten, sie hätten zu wenig Zeit.

Jedoch hängt die Sichtweise auf das offensichtliche Problem immer vom Blickwinkel des Betrachters ab. Wir sollten unsere Ansicht zu dem Thema gründlich überdenken.

Halten wir doch einfach einmal die Zeit an!

Nicht das wie es am Ende aussieht sollte uns im Moment wichtig sein, sondern die nächste Aufgabe welche wir erledigen müssen um das Endergebnis zu erreichen.

Die Umstellung von dem zeit getriebenen Arbeiten auf Aufgaben fokussiertes Arbeiten hilft uns hierbei.

Machen sie sich frei, schnappen sie sich eine Aufgabe und arbeiten sie diese ab. Haben sie die Aufgabe erledigt haben sie sich eine Pause verdient. Dann geht es wieder weiter.

Es gibt verschiedene Techniken wie man einen konstanten Durchsatz beim Aufgaben fokussierten Arbeiten erreicht.

Auch gibt es unterschiedlichste Techniken wie Aufgaben priorisiert und somit auf die Reise geschickt werden können. Denn am idealsten ist es natürlich wenn sich jemand anderer Gedanken macht welche Aufgabe als nächstes zu erledigen ist.

Technologischer Sex-Appeal

In der Entwicklung arbeiten wohl immer unterschiedlichste Charaktere, und so sagte mir unlängst ein Kollege, er hätte sich in einer Firma als Java Entwickler beworben, nun ist er jedoch Cobol Entwickler geworden. Er ist froh, dass er dort gelandet sei.

Gerade Unternehmen müssen bei Ihren Produkten den Fokus auf die Nachhaltigkeit ihrer Produkte legen. Nachhaltigkeit ist jedoch in der Softwareentwicklung ein dehnbarer Begriff. Oft mach es hier einen Unterschied in welcher Brache man sich bewegt. Schreibt man Software für mobile Endgeräte, kann es schon vorkommen, dass man die Software nicht nur einmal implementiert. Dabei würde man die Nachhaltigkeit in den Konzepten und in Programmiersprachen unabhängigen Algorythmen suchen. Bei Legacy Anwendungen würde man die Nachhaltigkeit dann wohl eher in der Änderbarkeit oder Wartbarkeit vermuten.

Aber gerade bei Legacysystemen kann es vorkommen, dass ein und das selbe Stück Code während seiner Lebensdauer von verschiedensten Personen angegriffen werden muss. Wie kann man dann Mitarbeiter dazu motivieren sich immer wieder in ältere Codeartefakte einzuarbeiten und diese zu verändern.

Es zeigt sich, dass diese Bereitschaft mit der Zeit einfach sinkt. Es werden immer wieder neue Technologien entwickelt, Sprachen werdern vereinfacht bzw. wieterentwickelt, auch die Entwicklungsprozesse entwickeln sich weiter. Es fängt schon bei so banalen Dingen wie einem Sourcerepository an, wo auch schon der Zahn der Zeit nagt.

Potentielle Bewerber suchen sich Ihren Job nicht mehr nur nach den Sozialen- und Intrinsischen- Merkmalen eines Unternehmens aus, nein es spielt mittlerweilen auch schon viel mehr der Technologischesexappeal des Unternehmens eine Rolle.

Wie siehts mit Ihrem Sex-Appeal aus?

Groovy: Analyse Accesslogs

Analyse access logs with groovy. Compare a special behaviour on two different files.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
pattern = ~/.*\\/(.*\.jsp).*/
data = new HashMap()
calculate("c:/P7_ARCTIS_access_log.2012_01_31%2336[1]", 0);
calculate("c:/P7_ARCTIS_access_log.2012_03_23%2336[1]", 1);
def calculate(filename, i) {
def file = new File(filename);
file.eachLine{line ->
if(line.contains(".jsp")) {
m = line=~pattern
def jsp = m[0][1]
if(!data.containsKey(jsp)) {
data.put(jsp, [0,0]);
}
int[] werte = data.get(jsp);
werte[i] = werte[i]+1;
data.put(jsp, werte);
}
}
}
println data

Here we are!

escalation of commitment

Wer mich kennt weiß, dass ich mich nicht nur gern mit Software beschäftige, sondern auch mit Bergsteigen und Klettern. Darin bin ich zwar nicht richtig gut, aber man muss sich ja mit irgendwas in seiner Freizeit beschäftigen :-).
Beim Bergsteigen beschäftigt man sich sehr viel mit Risikomanagement. Bei jeder Tour die man plant versucht man natürlich das Risiko zu minimieren. Jedoch weiß man auch, dass man es nicht vollständig eliminieren kann. Denkt man darüber mal genauer nach spielt man vielleicht des öfteren mit seinem Leben, und wenn einem das bewusst ist, ist dies ja auch ok.

Vor längerem bin ich über den Ausspruch "escalation of commitment" gestoßen, und er lässt mich nicht mehr los. Ich finde einfach so viele parallelen von dem Risikomanagement am Berg zum Risikomanagement beim Software Entwickeln. Und nicht nur das, ich lerne damit auch Leute und deren Reaktionen auf Kritik besser zu verstehen.

Aber nun zuerst einmal zu dem Zitat:

Je mehr wir in eine Entscheidung investiert haben (zB in Form von Geld, Aufstiegsmühen, Vorbereitungszeit, usw.), desto stärker fühlen wir uns dieser Entscheidung verbunden bzw. verpflichtet. Wir sind auch dann noch bereit, weitere Energien, Mühen und erhebliche Risiken in die getroffene Entscheidung zu stecken, wenn für einen neutralen Beobachter längst erkennbar ist, dass die Entscheidung unsinnig bzw. hoch riskant ist. entscheidungsfindung aus bergundsteigen 3/04

Ich selber konnte diese Reaktionen auch öfters bei Softwareprojekten erkennen, welche nicht ganz rund liefen. Die beteiligten Personen gehen oft in Tauchmodus und sind für Veränderungen nur sehr schwer zu motivieren. Änderungen werden dann oft als negativ bzw. als Zugeständnis von Fehlverhalten gesehen. Etablierte und oft bewährte Techniken, Vorgehensweisen oder auch Tools werden dann in Frage gestellt.

Verinnerlicht man sich das Zitat und denkt genauer darüber nach, kann man das auch verstehen. Umso mehr Respekt muss man dann doch jenen Menschen schenken, welche in solchen Momenten im wahrsten Sinne des Wortes die "Kurve kriegen" bzw. umdrehen.

Die Softwareentwicklung hat sich in den letzten Jahren extrem weiter entwickelt. Wir sind im Zeitalter der objektorientierten Sprachen, Skript-Sprachen versuchen gerade mal den Markt zu erobern. Was wir nun brauchen sind Projektmanager die jahrelang oder jahrzehntelang aufgebaute Weisheiten über Bord werfen und neue (agile) Techniken versuchen. Oder Entwickler die bereit sind sich neue Problemlösungsstrategien anzueignen und neue (agile) Vorgehensweisen umsetzen.

Charlie Poole meinte in seinem Vortrag immer wieder: Separation of concern is one of the main principle from object oriented programming. Was für mich ein synonym dafür ist, dass man sich einem Paradigmen wechsel unterziehen muss, wenn man von einer prozeduralen auf eine objektorientierte Sprache umsteigt.

Die Einführung von Agilen Methoden in ein Unternehmen kann oft einem Kulturschock gleich kommen. Das selbige kann einem auch passieren wenn man direkt von der Uni in einem konservativ geführtem Unternehmen Fuß fasst.

escalation of commitment hat im Agilen eigentlich keinen Platz. Dort wird versucht Entscheidungen so spät wie möglich zu treffen, also mit dem Maximum an Wissen.

Führung

"Führung ist Dienstleistung am Mitarbeiter." Unbekannt

Oft sieht es so aus als ob unsere Manager immer nur gut Laune haben, um 16:00 aus dem Büro verschwinden. Aber meist ist die Führung am besten die man kaum merkt, und trotzdem spürt. “Ich weiß nicht was da so besonders war, aber es hat Spaß gemacht und funktioniert.”

Strategic Decisions

Strategische Entscheidungen zeichnen sich nicht dadurch aus, dass sie unbedingt sehr schwierig sind, aber sie haben einen großen Impact für folgenden Aktivitäten.

Einmal getroffen sind sie oft schwer zu ändern.

Spielräume

Spielräume brauchen wir um kreativ zu sein. Spielräume bedeuten jedoch nicht, dass man nicht geführt wird, genau so wenig wie Führung heisst, dass man keine Spielräume haben kann.

Um großangelegte Veränderungen umzusetzteen, müsste darüberhinaus ein breiter Konsens zwischen unterschiedlichen Interessensgruppen gefunden werden. Dafür sind sowohl Visionen als auch eine charismatische Führung notwendig.

Tom DeMarco
spielräume