Pair Testing

Pair Testing

Als eine Variante der notwendigen Tests für neu programmierte Softwareanwendungen entspricht das Pair Testing an vielen Stellen den Arbeitstechniken der populären Pair Programmierung. Wie dieser Programmieransatz steht auch das Pair Testing im Kontext einer agilen Softwareentwicklung mit Frameworks wie Scrum und zielt auf eine Verschlankung und Beschleunigung der Prozesse abseits der üblichen umfangreichen Verfahrensstandards. Das Pair Testing-Verfahren ist wesentlich älter als das Pair Programming, erfuhr seinen entscheidenden Aufschwung aber erst durch die breite Akzeptanz gegenüber der neuen Entwicklungsmethodik und wird gelegentlich auch als Buddy Test umschrieben.

Wie funktioniert Pair Testing?

Das Szenario für einen Pair oder Buddy Test ist denkbar simpel. Zwei Team-Mitglieder und ein Computer mit der zu testenden Anwendungsversion bilden die Testumgebung. Das Duo kann sich aus einem Tester und einem Entwickler zusammensetzen oder ein Business Analyst wird zum Buddy des Testers. Alternativ kann das Pair Testing auch genutzt werden, um das Wissen eines erfahrenen Testers an junge Nachwuchskollegen weiterzugeben.

Einer der beiden Pair Tester arbeitet dabei mit dem Rechner und der Anwendung, während sein Mitstreiter für die Protokollierung zuständig ist, durch Test-Szenarien in der Business-Software führt oder mit spontanen Fragen weitere Aspekte im Zusammenhang mit der Anwendung und ihrer Bedienung beleuchtet. Die Rollenverteilung muss dabei nicht für den gesamten Test fixiert sein und kann im Verlauf wechseln. Für einen einzelnen Pair Test wird dabei gewöhnlich eine Dauer von 30 bis 60 Minuten festgesetzt. Der Austausch zwischen den beiden Testpersonen, ein Wechsel der Perspektiven, ihre unterschiedlichen Gedanken, Beobachtungen und Ideen stehen im Mittelpunkt des Pair Testings. Agil, schnell, effizient und ohne die Hilfe von eigens entwickelten Test Cases, Plänen oder Szenarien will das Pair Testing den expliziten Fehlern und latenten Schwachstellen einer neuen Anwendung zu Leibe rücken.

Vorarbeit zum Pair Testing

Auch wenn beim Pair Testing ohne die gewohnt ausgefeilten Testvorgaben gearbeitet wird, benötigt diese Methode einige Vorarbeiten. Die Tester sollten um das Ziel und die Perspektive Ihres Tests wissen und diese klar definieren. Der Test kann auf einen einzigen, schwer greifbaren Anwendungsfehler, die generelle Workability neuer Funktionen oder die vom Kunden geforderten Nutzungsmöglichkeiten gerichtet sein. Gewisse Zielvorgaben dürfen also auch in diesem agilen Test-Szenario nicht fehlen.

Was bringt das Pair Testing?

Natürlich hat das Pair Testing primär die generelle Usability einer Anwendung und Identifizierung spezifischer Anwendungsfehler im Auge, folgt dabei aber auch übergeordneten Zielen. Pair Testing soll nicht nur für den Endabnehmer der Anwendung Vorteile bringen, sondern auch das eigene Team stärken. Entwickler lernen dabei von Testern und umgekehrt. Business Analysts oder Consultants bringen ihre Erfahrungen in den Entwicklungsprozess einer Anwendung ein und lernen die Besonderheiten der Entwicklerseite kennen. Diese Austauschmöglichkeiten machen das Pair Testing wertvoll und nachhaltig für das ganze Team.

Dabei ist das Pair Testing eine exzellente Option, wenn gegen Projektende Zeitplan oder Budgetrahmen drücken. Auch bei einem unklaren Testszenario kann Pair Testing helfen. Hier braucht es keine ausgefeilten Testpläne und Cases, die zusätzlich Zeit oder Geld verschlingen. Pair Testing kann spontan und kostengünstig organisiert werden, aber trotzdem zuverlässige Ergebnisse und Ansatzpunkte für Verbesserungen oder Debugging bei einer ERP-Software und anderen Business Solutions liefern.

Wann sollte man die Finger vom Pair Testing lassen?

In einer automatisierten Testumgebung mit vorgegebenen Fällen und Szenarien braucht es kein zusätzliches Pair Testing. Hier reicht ein Tester, der die Vorgaben abarbeitet. Auch eigens entworfene Cases können von einem Einzeltester absolviert werden, ohne dass ein Team im Pair Testing bemüht werden muss.

Das Pair Testing sollte auch nicht als Umweg dienen, um zwei bekanntermaßen unverträgliche Kollegen in ihren Social Skills zu trainieren, denn ohne eine Grundharmonie oder neutrales und respektvolles Miteinander kann Pair Testing nicht funktionieren.

Pair Testing bringt also nicht immer Vorteile, bleibt aber, richtig genutzt, ein mächtiges und multifunktionales Testwerkzeug.

Kosten von Pair Programming

Pair Programming – höhere Kosten machen sich bezahlt

Extreme Programming (XP) gehört zu den wichtigsten Ansätzen moderner Programmiertechniken, welche nach neuen Wegen suchen, Projekte schnell und möglichst fehlerfrei zu einem erfolgreichen Abschluss zu bringen. Unter den Techniken des Extreme Programming sticht die Paarprogrammierung (Pair Programming) besonders hervor.

Bei diesem Ansatz bearbeiten zwei Programmierer gleichberechtigt ein gemeinsames Projekt. Die beiden Partner agieren dabei wie Pilot und Navigator an Bord eines Flugzeugs: Ein Programmierer schreibt den eigentlichen Code, während sein Kollege permanent den Kurs kontrolliert und ein Auge darauf hat, dass alle Abläufe im Cockpit korrekt eingehalten werden. Nach dem Prinzip „vier Augen sehen mehr“ sollen mögliche Probleme so früher erkannt und dank der geballten Kompetenz zweier Programmierer im Team beseitigt werden.

Zwei gleichberechtigte Programmierer verursachen natürlich auch doppelt soviel Kosten wie ein einzelner Entwickler. Daher stellt sich dem Auftraggeber die berechtigte Frage: „Ist Pair Programming die höheren Kosten wert?” Erste praktische Erfahrungen mit der Paarprogrammierung sowie Studien anerkannter Fakultäten, wie dem Karlsruher Institut für Technologie, sprechen dafür. Allerdings sind einige wichtige Eigenheiten dieser Methode zu beachten, auf die wir im Folgenden eingehen werden.

Zunächst gilt es, aus den zur Verfügung stehenden Programmierern die geeigneten Kandidaten für das gemeinsame Arbeiten auszuwählen. Zwischenmenschliche Spannungen können zu einer ernsthaften Behinderung des Workflows führen. Auch sollten die Partner, was ihre Fähigkeiten angeht, ungefähr auf Augenhöhe liegen. Besteht ein zu großes Leistungsgefälle zwischen den beiden Kandidaten, so ist das Pair Programming sehr gut dazu geeignet, Know how bei dem schächeren Programmierer aufzubauen.

Zeit einplanen

Außerdem sollte ein gewisser Zeitraum eingeplant werden, währenddessen sich die Programmierer aneinander gewöhnen und einen gemeinsamen Arbeitsstil finden. Auf lange Sicht geht die Arbeit in der Paarprogrammierung jedoch deutlich schneller vonstatten, als in der Einzelarbeit. Gleichzeitig erreichen Programmierpaare höhere Qualitätsstandards und schreiben einen effizienteren Code. Diese gesteigerte Leistungsfähigkeit ist auf die gegenseitige Kontrollfunktion der Entwickler zurückzuführen. Solisten neigen vor allem unter Zeitdruck dazu, Änderungen an ungünstigen Stellen des Codes vorzunehmen oder kleinere Fehler zu übersehen. Paarprogrammierer hingegen motivieren sich gegenseitig, einen sauberen Code hinzulegen und können untereinander jederzeit Hilfestellung leisten. Herrscht also ein großer Marktdruck mit einer entsprechend hohen Auftragslage, macht sich das Pair Programming mit eingespielten Teams definitiv bezahlt. Deren Geschwindigkeit – bei einer geringen Fehlerquote – relativiert die höheren Kosten. In schwachen Zeiten ohne großen Auftragsdruck macht die Einzelentwicklung womöglich finanziell mehr Sinn.

Qualitätssteigerung durch Pair Programming

Was jedoch die Qualität der geschriebenen Programme angeht, hat die Paarprogrammierung in jedem Fall die Nase vorn. Ihren Nutzen entfaltet sie besonders im Zusammenspiel mit modernen Philosophien wie der testgetriebenen Entwicklung. Dort werden Tests meist schon vor dem entsprechenden Systemteil geschrieben, um die Voraussetzungen zu schaffen, welche das fertige Programm erfüllen soll. Eine spätere Testphase nach Vollendung der Software fällt weitestgehend weg, da bereits während der Entwicklung permanent Korrekturen gemacht werden können. Dabei wird eine möglichst umfassende Automatisierung dieser Tests angestrebt. Diese sind dann quasi auf Knopfdruck innerhalb kürzester Zeit ausführbar. Ein eingespieltes Programmierer-Paar kann sich bei dieser Methode hervorragend ergänzen: Ein Partner schreibt den Code, während sein Kollege sich um das permanente Testen kümmert. Die testgetriebene Entwicklung setzt einen sauberen, effizienten Code voraus. Und im Pair Programming ist dies für gewöhnlich eher der Fall, als bei einzelnen Programmierern. Langfristig ist es also deutlich wirtschaftlicher, diese Art der Entwicklung von fähigen Teams erledigen zu lassen.

Vermittlung und Austausch von Wissen sind in der Programmierung unerlässlich. Durch die unmittelbare Zusammenarbeit zweier Programmierer wird der Wissensaustausch enorm beschleunigt. Zudem eignen sich die Partner gemeinsam entwickelte, bewährte Arbeitsweisen an und werden so auch als einzelner Programmierer gestärkt. Um diesen Effekt zu maximieren, empfiehlt es sich, mehrere Zweierteams zu bilden und deren Besetzung durch regelmäßige Rotation zu verändern. Auf diese Art profitieren auch in größeren Programmierabteilungen alle Mitarbeiter von der entstehenden Schwarmkompetenz. Die Gefahr, dass zwei Programmierer gemeinsam am Rechner sitzen und nur einer von ihnen tatsächlich arbeitet, wird ebenfalls reduziert. Denn wenn erst einmal mehrere Partnerrotationen stattgefunden haben, wird sich herauskristallisieren, welche Kollegen aufgrund ihrer Leistungsfähigkeit sowie ihres Wissensstandes am besten zusammenpassen.

Motivierte Mitarbeiter

Mehr Spaß an der Arbeit und gesteigerte Motivation sind weitere erfreuliche Nebeneffekte des Pair Programming. Teamgeist und Zusammenhalt werden gestärkt, weil jeder Entwickler weiß, dass seine Kollegen im Zweifel für ihn da sind. Und stets motivierte Mitarbeiter sind unbezahlbar, selbst wenn je zwei von ihnen sich ein Projekt teilen.

Abschließend bleibt zu sagen, dass das Pair Programming sich auch im wirtschaftlichen Sinne lohnt. Voraussetzung sind genug fähige Entwickler im Team, welche charakterlich miteinander auskommen und auf vergleichbarem Leistungsniveau liegen. Die hochwertigen und schnell produzierten Programme sorgen in Zeiten großer Nachfrage für hohe Profite. Dem sparsam denkenden Auftraggeber sagen wir: „Ja, Pair Programming ist die höheren Kosten wert.“

Pair Programming – vier Augen sehen mehr als zwei

Pair Programming

Die meisten Programmierer sind es gewohnt, allein an einem Rechner zu sitzen und ihre Aufgaben eigenverantwortlich zu lösen. Planung, Durchführung und Kontrolle stammen aus einer Hand. Ebenso liegt die gesamte Verantwortung auf den Schultern des Solo-Programmierers. Mit der Methode des Pair Programming (Paarprogrammierung) wird diese Last auf mehrere Schultern verteilt, da zwei Programmierer sich eine Arbeitsstation teilen und das Projekt gemeinsam bewältigen. Dieses Prinzip entstammt dem Bereich des Extreme Programming, wo die Fertigstellung eines Projektes im Vordergrund steht – unabhängig von der gewählten Methode, dieses Ziel zu erreichen.

Der Hauptgrund für das paarweise Programmieren liegt auf der Hand: Durch die gegenseitige Kontrolle sollen Fehler möglichst schon im Vorfeld vermieden und teure nachträgliche Änderungen ausgeschlossen werden. Doch praktische Erfahrungen mit der Paarprogrammierung haben gezeigt, dass diese Methode noch weitere Vorteile bietet.

Für gewöhnlich findet die Arbeit in wechselseitigem Rhythmus statt, wobei einem der beiden Programmierer jeweils die Rolle des Aufpassers und Unterstützers zukommt, während sein Partner den Code schreibt. Dies führt zu einer im Schnitt um 15 Prozent reduzierten Fehlerquote gegenüber Einzelprogrammierern, da ein neutraler Beobachter meist sofort auf Fehler aufmerksam wird, die dem aktiven Programmierer im Workflow entgehen könnten. Durch die gegenseitige Kontrolle wird auch die allgemeine Disziplin gesteigert, was zu einem weitaus effektiveren Arbeiten führt. So wird auch der Faktor der Bequemlichkeit weitestgehend ausgeschaltet, da vor allem bei der Fehlerbehebung stets an der korrekten Stelle des Codes gearbeitet wird. Der gesamte Programmcode wird auf diese Weise effizienter gestaltet, was einen besseren Code und durchschnittlich 20 Prozent kleinere Programme hervorbringt. Darüber hinaus können die Teammitglieder sich gegenseitig motivieren und antreiben, was zu deutlich kürzeren Pausen, weniger Unterbrechungen und einem allgemein höheren Arbeitstempo führt.

Jeder Programmierer hat seine Fachgebiete, Stärken und Schwächen. Im Pair Programming ergänzen sich die Partner somit gegenseitig und verhindern weitestgehend, dass ein einzelner Entwickler an einem unvorhergesehenen Problem hängenbleibt. Die permanente gegenseitige Absprache sorgt gleichzeitig für einen laufenden Wissensaustausch. Neben dem Lerneffekt ist somit sichergestellt, dass alle Beteiligten über den gleichen Wissensstand bezüglich der Codebasis verfügen.

Ein Großteil der Programmierer, welche bereits Erfahrung mit der Paarprogrammierung sammeln konnten, gab an, mehr Spaß an der gemeinsamen Arbeit zu haben. Da in größeren Firmen meist auch die Besetzung der Programmierpaare von Zeit zu Zeit geändert wird, kann das Pair Programming im ferneren Sinne sogar als Instrument für effizientes Teambuilding angesehen werden. Interessanterweise hat sich auch gezeigt, dass Programmier-Paare seltener von anderen Kollegen unterbrochen werden, als Entwickler, die allein am Rechner sitzen.

Natürlich ist das Pair Programming keine Wunderlösung für jeden Zweck. Bei besonders kleinen oder einfachen Projekten macht es womöglich keinen Sinn, zu zweit zu arbeiten. Gegenseitige Antipathie bringt Streit hervor und kann die Idee hinter der Paarprogrammierung ins Gegenteil verkehren und das gesamte Team lähmen. Es ist also sehr wichtig, dass die Partner auch auf menschlicher Ebene miteinander auskommen, damit ein professionelles Arbeitsklima gewahrt bleibt. Auch sollten die Teammitglieder sich auf einen gemeinsamen Programmierstil einigen. Treffen hier völlig unterschiedliche Philosophien aufeinander und ist keiner bereit auf den anderen zuzugehen, macht ein paarweises Arbeiten womöglich keinen Sinn.

Abschließend bleibt festzuhalten, dass das Pair Programming zwar eine gewisse Vorbereitung erfordert, da sich neue Partner zunächst aneinander gewöhnen und ihre Vorgehensweise planen müssen – jedoch ein weitaus effektiveres und schnelleres Arbeiten möglich ist, sobald sich das Paar eingespielt hat. Gesteigerte Produktivität, eine geringere Fehlerquote und saubere Codes sind die Früchte gelungener Paarprogrammierung.

Zeitmanagement mit der Pomodoro-Technik

Pomodoro-Technik: Arbeiten Sie mit der Uhr (statt gegen sie)

In einer Welt voller Ablenkungen kann agiles Zeitmanagement eine Herausforderung sein. E-Mails, Telefonanrufe, soziale Netzwerke und Ähnliches verhindern, dass wir uns iStock_000000586460Smallwirklich auf eine einzige Aufgabe konzentrieren können. Genau hier setzt die Pomodoro-Technik an. Probieren Sie sie einfach einmal aus, wenn Sie einen einfachen und entspannten Zugang zum Zeitmanagement suchen und wenn minutiös geplante Aufgabenlisten Sie eher abschrecken. Ein weiterer Vorteil: Regelmäßige Kaffeepausen sind ein fester Bestandteil dieses Zeitmanagement-Systems!

Die Pomodoro-Technik wurde in den späten 1980er Jahren von Francesco Cirillo erfunden. Er erkannte, dass definierte Zeitspannen hochkonzentrierter Arbeit und darauffolgende kurze Pausen die Produktivität beträchtlich erhöhen konnten. Diese Intervalle von jeweils 25 Minuten plus 3 bis 5 Minuten Pause nannte er „Pomodoros“ – zu Ehren des tomatenförmigen Küchentimers, den er zur Zeiteinteilung verwendete („Pomodoro“ ist das italienische Wort für „Tomate“).

Durch den Timer und die kleinen Intervalle zwingen Sie sich zu Single-Tasking und verringern die menschliche Neigung, wichtige Aufgaben vor sich herzuschieben. Sie verbessern Ihre Konzentration und können Stress leichter bewältigen.

Heute lehrt Cirillo sein Zeitmanagement-System auf der ganzen Welt. Es hat sich in den verschiedensten Bereichen verbreitet und wurde vielfältig abgewandelt. Ein ähnliches Konzept verfolgt etwa die Timeboxing-Technik in der agilen Software-Entwicklung.

Erste Schritte mit der Pomodoro-Technik

Der Kern der Pomodoro-Technik ist ganz einfach: Arbeiten Sie 25 Minuten lang konzentriert und ohne Ablenkungen an Ihrer Aufgabe, machen Sie fünf Minuten Pause – und wiederholen Sie diesen Vorgang. Nach vier 30-Minuten-Intervallen (oder Pomodoros) gönnen Sie sich eine längere Pause von 15 bis 30 Minuten. Auf diese Weise arbeiten Sie jede Aufgabe komplett ab.

Cirillo empfiehlt die Verwendung eines Küchentimers, da das Einstellen der Zeit und das anschließende Ticken nicht nur ein Gefühl der Dringlichkeit schaffen, sondern allmählich mit konzentrierter und produktiver Arbeit assoziiert werden. Alternativ gibt es jedoch auch zahlreiche Computerprogramme und Online-Anwendungen, die Pomodoro-Timer auf Ihrem Rechner simulieren.

So geht es:

  1. Wählen Sie eine Aufgabe aus.
    Fertigen Sie eine Liste der notwendigen Tätigkeiten an und übertragen Sie die Aufgaben, die an diesem Tag erledigt werden müssen, in eine To-Do-Liste. Größere Aufgaben, die länger als ca. 2 bis 3 Stunden dauern, zerlegen Sie in Unteraufgaben. Kleinere Aufgaben, die kürzer als 25 Minuten dauern, fassen Sie zu einer einzigen Aufgabe zusammen. Wählen Sie die wichtigste Aufgabe aus der Liste.
  2. Stellen Sie den Timer auf 25 Minuten.
    Sobald die Zeit läuft, beginnen Sie ohne Verzögerung mit der gewählten Aufgabe.
  3. Bearbeiten Sie die Aufgabe, bis der Timer Alarm gibt.
    Unterbrechen Sie die Arbeit sofort. Anderenfalls haben Sie später eine praktische Ausrede, um während der nächsten Pomodoro zu schummeln – Sie können sich dann einreden, dass Sie über die letzte Pomodoro hinausgearbeitet haben und Ihre nächste Pomodoro deshalb durch überflüssige Handlungen unterbrechen können.
  4. Legen Sie eine Pause von 3 bis 5 Minuten ein.
    Stellen Sie den Timer für diese Pause ein. Anschließend stellen Sie den Timer wieder auf 25 Minuten ein und arbeiten weiter.
  5. Nach vier Pomodoros gönnen Sie sich eine längere Pause von 20 bis 30 Minuten.

Protokollieren Sie Ihre Aktivitäten

Die Überprüfung und Aufzeichnung Ihrer Bemühungen ist für den Erfolg des Zeitmanagements mit der Pomodoro-Technik entscheidend – Sie fordern quasi Rechenschaft von sich selbst.

Am Ende jedes Arbeitstages notieren Sie deshalb alle erledigten Aufgaben und die Anzahl Pomodoros, die Sie dafür benötigt haben. Der tatsächliche Zeitaufwand für die Ausführung einer einzelnen Aufgabe ist irrelevant; es zählt nur, wie viele Pomodoros Sie an einem Tag insgesamt benötigt haben. Jede Pomodoro ist eine eigene Zeiteinheit – nicht einfach Zeit im Allgemeinen, sondern produktive, konzentrierte Zeit. Dadurch verändert sich Ihre Wahrnehmung von Zeit entscheidend – weil die „normale“ Zeit keine Rolle spielt, stellt sie auch keine Quelle von Angst und Stress mehr dar.

Ähnliches gilt für externe und interne Unterbrechungen. Externe Unterbrechungen sind beispielsweise spontane Meetings, Fragen von Kollegen oder Telefonanrufe. Interne Unterbrechungen – Tagträumereien, der Wunsch nach einer Tasse Kaffee, der Blick ins soziale Netzwerk – sind besonders schwer zu kontrollieren, auch wenn sie eigentlich bis zur geplanten Pause warten sollten. Markieren Sie solche Unterbrechungen oder Versuchungen auf ihrer Liste, um sie wöchentlich zu analysieren und Ihr Zeitmanagement auf diese Weise langfristig zu verbessern.

Wissensarbeiter, die im Team arbeiten

Gemeinsam geht mehr

Unsere Gesellschaft, vor allem die Wirtschaft, befindet sich in einem kontinuierlichen Entwicklungsprozess von einer industriellen Prägung hin zu einer Wissensgesellschaft. Der Anteil Wissensarbeitermanueller Routinetätigkeiten in der Arbeitswelt geht stetig zurück und macht heute schon deutlich weniger als ein Viertel der Gesamtprozesse aus. Im gleichen Maß steigt der Anteil der Wissensarbeiter in den Unternehmen. Über ein Drittel der Tätigkeiten kann heute diesem Bereich zugeordnet werden. Ein Trend, der sich fortsetzen wird, die Wissensarbeit ist ein unerlässlicher Faktor, damit die Unternehmen mit Produktqualität oder individuell erstellten Lösungen ihre Marktstellung behaupten können. In manchen Organisationen wie etwa High-Tech-Firmen oder bei Softwareentwicklern, Forschungsinstituten und Finanzdienstleistern dominiert die Wissensarbeit längst alle Strukturen und Prozesse.

Produktionsfaktor Wissen

Wissensarbeit gründet in erster Linie auf individuellen Denkprozessen, stellt aber auch weitere Anforderungen an den Menschen. Sie ist kein einmaliger, abgeschlossener Lernvorgang wie ein Studium, sondern fordert von ihren Protagonisten kontinuierliches Revidieren und Verbessern ihrer Wissensbasis. Diese Entwicklung findet individuell statt, im Sinne des Erfolgs und wegen der Komplexität jedes Fachbereichs aber auch in einem produktiven Wechselspiel mit den Kollegen oder in der Gesamtheit eines Unternehmens. Obwohl Wissensarbeiter Individualisten sind, die nicht wie Arbeiter am Fließband ohne Weiteres miteinander oder nacheinander ein gemeinsames Produkt herstellen können, lassen sich aus ihnen effektive Teams formen.

Vor allem aus dem Zusammenspiel unterschiedlicher Experten oder dem Einbezug externer Wissensarbeiter ergeben sich immer neue Impulse für eine Problemstellung oder ein Projekt. Dabei werden klassische, starre Unternehmensstrukturen wie Abteilungen oder pyramidale Hierarchien immer durchlässiger und verschwinden schließlich ganz. Wissensbasierte Unternehmen sind flach organisiert und bilden agile Systeme aus. Managementaufgaben werden von der Unternehmensspitze an die Basis umverteilt. Jeder einzelne Wissensarbeiter ist gleichzeitig auch Manager seines Bereichs und Kommunikator im Team und im gesamten Unternehmen.

Ansätze zur Umsetzung von Wissensarbeit in Teams

Die großangelegte Hays-Studie zur Wissensarbeit in Unternehmen hat es 2012 sehr deutlich gemacht. Beim Austausch zwischen Wissensarbeitern und ihrer Vernetzung sahen die Befragten noch erheblichen Nachholbedarf für die Unternehmen. Datenbanken zum übergreifenden Wissensmanagement scheinen etabliert, während Social Media in diesem Bereich oft noch auf Skepsis stößt.

Zeitlich oder thematisch abgegrenzte Projektarbeit hat sich als wesentliches praktisches Werkzeug für eine organisierte Wissensarbeit bewährt. Sie erreicht ihre größte Effektivität, wenn die Teams aus Mitarbeitern mit unterschiedlichen Alters- und Qualifikationsstufen und aus verschiedenen Abteilungen oder Hierarchieebenen gebildet werden. Ein möglichst breiter Einbezug der vorhandenen Wissensressourcen fördert den Projekterfolg. Aus einzelnen Spezialisten wird ein schlagkräftiges Allround-Team.

Die Arbeitsorganisation ist nach der Hays-Studie immer noch sehr traditionell geprägt. Wer heute Teams von Wissensarbeitern organisieren will, sollte sich eher an globalen, rein virtuell interagierenden Unternehmen, ihrer Kommunikation und ihrem Workflow orientieren, statt die Konzeption von Altunternehmen nur leicht zu modernisieren. Genau an dieser Stelle stecken viele Firmen noch in ihrem Wandel zu einem knowledge-driven Business fest. Auch in Projekten wird noch überwiegend einzeln und über den Betrieb verteilt gearbeitet. Meetings und Kommunikation per Mail oder Telefon bilden das Bindeglied zwischen den Wissensarbeitern und lenken in der Praxis noch vornehmlich den Workflow. Eine Vielzahl an weiteren Möglichkeiten bleibt häufig ungenutzt und so wird viel Potential bei der teamgebundenen Wissensarbeit verschenkt.

Die wirklich effektive Organisation von Wissensarbeit nutzt auch Media-Sharing-Plattformen, Wikis oder Blogs, setzt auf die Integration von Collaboration-Tools und filtert jene Prozesse heraus, für die tatsächlich noch eine Face-to-Face-Kommunikation erforderlich ist. So können sich viele Branchen fit für eine Zukunft machen, die immer mehr von diesem wissensorientierten Ansatz bestimmt wird. Der IT-Bereich ist hier sicherlich bereits am stärksten entwickelt, aber auch für Marketing, Sales, Kundenberatung, Personal oder Forschung und Entwicklung kann die Wissensarbeit neue Impulse anbieten.

Flow im Beruf

Flow im Beruf

Mihaly Csikszentmihalyi (geb. 1934) ist Professor für Psychologie an der University of Chicago und ein renomierter Fachbuchautor. Er bezeichnet sich als »Glücksforscher« und hat während seiner Schaffenszeit die sogenannte Flow-Theorie aufgestellt. Das englische Wort Flow (dt. fließen) steht in diesem Zusammenhang für Tätigkeitsrausch oder Tätigkeitslust.
Flow
Die Flow-Theorie besagt, dass ein Mensch während einer (z. B. beruflichen) Tätigkeit, die ihm ein bestimmtes Maß an Konzentration abverlangt, in eine Art »Flow-Zustand« geraten kann, der sich durch mehrere körperliche und psychische Merkmale beschreiben lässt, darunter beispielsweise

  • dass der Betroffene fähig ist, sich auf sein Tun/seine Arbeit zu konzentrieren
  • Anforderung und Fähigkeit stehen in einem ausgewogenen Verhältnis, sodass einerseits keine Langeweile durch Unterforderung und andererseits keine Angst oder Blockade durch Überforderung entsteht
  • Handlung und Bewusstsein verschmelzen – oftmals mit dem Effekt, dass dem Betroffenen Sorgen oder Belange, die nichts mit dem gerade bearbeiteten Thema zutun haben, während des Flow-Zustandes in Vergessenheit geraten
  • das Zeitgefühl verändert sich (»man bemerkt nicht, wie schnell die Zeit vergeht«).

Als körperliches Merkmal sei zu erwähnen, dass in der Vergangenheit Untersuchungen an mehreren Probanden eine mögliche Veränderung der Pulsfrequenz belegen konnten.

Ein Flow-Zustand, auch kurz: Flow, im Berufsleben sorgt in aller Regel für eine effektive Arbeitsweise.Der »Arbeiter« ist agil aber dennoch sicher (geringe Fehlerwahrscheinlichkeit).

Eine wichtige Voraussetzung, um in einen Flow geraten zu können ist, dass die Aktivität deutliche Ziele hat. Sie muss zum einen

  • unmittelbare Rückmeldungen liefern und zum anderen
  • autotelisch sein.

Eine unmittelbare Rückmeldung erfährt man zum Beispiel beim Rasenmähen. Mit jedem Quadratmeter erkennt man einen Fortschritt an seiner Arbeit – »man sieht sofort, was man geschafft hat« -, während beim Sähen von Pflanzen keine unmittelbare Rückmeldung erfolgt, denn erst nach einigen Tagen kann man sehen, was dabei herausgekommen ist.

Autotelisch bedeutet, dass die Tätigkeit ihre Zielsetzung bei sich selbst hat. Ein Unternehmer, der ein Werbekonzept ausarbeitet und den Druck von Flugblättern in Auftrag gibt, verfolgt das primäre Ziel, seine Umsätze zu steigern, nicht aber schöne Flugblätter hervorzubringen. Die Druckerei, die die Flugblätter produziert, hat dagegen sehr wohl das primäres Ziel, hochwertige Ware (Flugblätter) zu produzieren. Für sie hat die Tätigkeit ihre Zielsetzung bei sich selbst.

Die meisten Aufgabenstellungen, die an Software-Entwickler gestellt werden, begünstigen einen Flow-Effekt. Denn die Arbeitsweise eines Informatikers erfolgt zumeist derart, dass er anhand eines Pflichtenheftes (das ist im Prinzip ein Anforderungsprofil, in dem beschrieben ist, was ein Programm »können« muss) ein Rechnerprogramm oder einen Programmteil entwickelt, indem er den Quelltext (Programm-Code) in seinen PC eintippt und anschließend überprüft, ob dieser – entweder überhaupt oder seinen Vorstellungen entsprechend – funktioniert. Im Regelfall stellt er dann fest, dass sein erstelltes Programm noch verbesserungswürdig ist, nimmt im Quelltext (kleine) Veränderungen vor, lässt das Programm daraufhin wieder »laufen« und stellt unmittelbar eine Veränderung fest, die sich als Verbesserung der vorherigen Version ausweisen aber dennoch weiter optimiert werden kann, sodass der Entwickler weitere Nacharbeiten an seinem Produkt vornimmt usw. (Dies lässt vermuten, dass Entwickler iterativ arbeiten…)

Die Zeitintervalle, in denen er die Qualität seiner Programmierarbeit überprüfen kann, sind in der Regel »kurz genug«, um dem Entwickler eine Rückkopplung seiner Arbeitsqualität in kurzen Zeitabständen zu gewährleisten. Er kann also schnell erkennen, was er »geschafft« hat. Dieser Effekt ist, wie bereits erwähnt, eine der wichtigsten Voraussetzungen, in einen Flow zu geraten. Somit ist das Ziel der unmittelbaren Rückmeldung erreicht.

Ferner hat Programmierarbeit die Zielsetzung bei sich selbst (Autotelie). Der Informatiker will ein funktionierendes Programm entwickeln (primäres Ziel). Er muss jedoch nicht das Ziel verfolgen zu erfahren, zu welchem Zweck, von wem oder wie effektiv sein Produkt letztlich genutzt wird.

Ausgehend davon, dass Software-Entwickler als Fachkräfte nicht überfordert sind von gewöhnlichen Aufgabenstellungen aber auch keine Langeweile empfinden, denn selbst in einer einfachen Programmieraufgabe verbirgt sich eine gewisse Herausforderung, ist eine weitere wichtige Bedingung erfüllt, einen Flow-Effekt zu erleben.

Abschließend lässt sich sagen: Es gibt etliche berufliche Tätigkeiten, die für den Anwender die Voraussetzungen für einen Flow erfüllen. Die Arbeit eines Software-Entwickler ist hier als Beispiel für eine dieser Tätigkeiten beschrieben.