Ninja oder Zauberer?
(Bild: Remko de Waal/AFP/Getty Images)
Von Maja Hoock veröffentlicht am
Wenn IT-Projekte scheitern, liegt das oft am Ärger zwischen allzu verschiedenen Köpfen im Team. Zwei Informatiker haben Charakterprofile für Entwickler geschaffen, die helfen sollen.
Wittum betreut potenzielle Mitarbeiter für einen großen Internetanbieter. Dabei ist ihm aufgefallen, wie wichtig gute Persönlichkeitseinschätzungen sind. Passen die Charaktere nicht zusammen, hakt die Arbeit. "Man kennt das von Meetings, nach denen man sich fragt, warum es schon wieder diese zermürbenden Endlosdiskussionen gab. Das hat uns dazu bewogen herauszuarbeiten, in welchen Designtypen Unterschiede verankert liegen, um sie greifbar zu machen", erklärt Matthias Wittum. Mit dem Entwickler Christian Rehn hat er zwei Jahre lang in der Freizeit daran gearbeitet, bestimmte Typen, die ihnen immer wieder im Beruf begegnet sind, unter 16 passenden Namen zusammenzufassen. Über ihren Fragebogen kann man kostenlos herausfinden, ob man etwa eher der eigensinnige Ninja oder der flexible Magician ist.
Wenn Pragmatiker auf Idealisten prallen
Vier Gegensatzpaare haben Rehn und Wittum als Basis dafür herausgearbeitet und sich dabei an der Teamrollen-Theorie von Meredith Belbin und am Myers-Briggs-Typenindikator orientiert. Das Ergebnis ist detaillierter als die Liste von sieben Entwicklertypen, die Webdesignerdepot.com schon 2010 veröffentlicht hat. "Wir haben anhand unserer eigenen Erfahrungen und Befragungen von Pilotgruppen schließlich vor allem technische Unterschiede herausgearbeitet, die Entwickler in Designfragen präferieren", erklärt Rehn. So kamen diese Gegensatzpaare heraus: Simple vs. Powerful, Abstract vs. Concrete, Pragmatic vs. Idealistic und Robust vs. Technologic.
Plant man ein Team, ist es gut zu wissen, wer sich in diesen Dimensionen ergänzt oder behindert. Auch bestehende Teams könne man so entsprechend umgruppieren: "Habe ich etwa nur Leute, die zum robusten Typ zählen, also auf Stabilität aus sind und wollen, dass Systeme robust laufen, aber nicht offen für neue Technologien sind, würde es Sinn ergeben, einen Kollegen mit der Technologic-Attitüde hinzuzuholen. Er würde frischen Wind mitbringen, weil er moderne Ansätze favorisiert", sagt Matthias Wittum.
Für Wittum ist es darum sogar denkbar, dass die Selbsteinschätzungen Teil des Lebenslaufs für Jobbewerbungen werden: "Anhand von einigen Fragen ordne ich selbst auch Bewerber bei Vorstellungsgesprächen grob in die Typen ein, um herauszufinden, wer vor mir sitzt und ob er oder sie in ein bestehendes Team passt. Es gibt auch unternehmensspezifische Vorlieben und manche Firmen stellen nur drei unterschiedliche Typen ein." Gibt man bereits im Lebenslauf eine Selbsteinschätzung an, könnten Recruiter schneller sehen, wer passt und wer nicht. Nur freiwillig solle das bleiben, findet Wittum.
Je nachdem, in welche dieser Kategorien ein Entwickler nach dem Selbsttest fällt, wird ihm einer von 16 Typen zugeordnet. Sie ergeben sich aus den Kombinationen der Faktoren in den Gegensatzpaaren. Jede dieser Kombinationen tendiert zu bestimmten Designprinzipien, die Stärken und Schwächen mit sich bringen: Es gibt den Construction Manager, Technician, Space Probe Engineer, Author, Fire Fighter, Ninja, Gardener, Craftsman, Engineer, Magician, Architect, Scientist, Sorcerer, Chef, Clockmaker und Artist.
Bei den 3.000 Teilnehmern, die den Test anonym gemacht haben, kam mit 15 Prozent am häufigsten der Technician heraus: ein effizienter Entwickler, der sich auf seine Tools verlässt, zügig arbeitet und das Gesamtbild im Blick behält. Sein Code ist einfach zu lesen. Laut Wittum soll keiner der 16 Entwicklertypen negativ klingen. "Wir haben versucht, alle Typen in der Selbsteinschätzung komplett wertneutral zu definieren. Ein bestimmter Typ ist also nicht besser als ein anderer. Es hängt immer von der Situation und der jeweiligen Aufgabe ab", sagt Wittum, der nach eigenen Angaben der Typ Construction Manager ist. Die Teilnehmer des Selbsttests scheinen das anders zu sehen: Mit nur einem Prozent ist der Clockmaker am seltensten. Er kennt das kleinste Detail seines Codes wie ein Uhrmacher seine Rädchen; verliert aber das Gesamtbild aus den Augen.
Man kennt es von anderen psychologischen Tests, dass Angaben nicht immer der Wahrheit entsprechen und manchmal der Wunsch Vater des Testergebnisses ist. Natürlich wollen die meisten Coder sich selbst lieber als elegant betrachten denn als plump. Und niemand möchte Aufträge verlieren, weil er einem negativ klingenden Entwicklertypus zugeordnet wurde. Dabei liegt nur im ehrlichen Ergebnis für Wittum die Chance. Daran sieht man, welche Designentscheidungen der Entwicklertyp bevorzugt, was er oder sie kann und wo die Schwächen liegen: "Man sieht, wo man blinde Flecke hat und was man verbessern könnte." Im Anschluss bekommt man deshalb auch passende Coding-Konzepte zu seinen Lücken im Principles-Wiki angezeigt. Wer ausschließen möchte, dass er sich selbst beschummelt, kann Kollegen um ihre Fremdeinschätzung bitten: Schreibt der Kollege viele kleine Klassen und Methoden? Kopiert er seine Code-Schnipsel vorwiegend aus dem Netz und ist darüber hinaus nicht kreativ? Ist es eine Herausforderung, seinen Code zu lesen?
Was tun mit dem Ergebnis?
Wenn die Teammitglieder ihr jeweiliges Ergebnis ermittelt haben, können sie es zum Beispiel ausdrucken und zu Beginn eines Projekts an ihren Arbeitsplatz kleben. Oder auf ein T-Shirt drucken, als eine Art Hinweis an die Kollegen. Mit Hilfe der Profile können sie feststellen, warum sie sich mit bestimmten Kollegen reiben und wie sie das beheben können. "In meinem aktuellen Team gibt es beispielsweise einen eher pragmatischen Kollegen. Da ich zur idealistischen Seite tendiere, bedeutet das, dass wir nicht immer einer Meinung sind", erklärt Entwickler Christian Rehn. "Die Profile helfen mir zu erkennen, dass keine der beiden Positionen falsch ist. Würde mein Kollege alleine an der Software arbeiten, würde ihre Wartbarkeit leiden. Wenn ich alleine an der Software arbeiten würde, würden wir Deadlines nicht einhalten. Trotz der Meinungsverschiedenheiten ärgere ich mich deshalb nicht über meinen Kollegen. Das klingt banal, aber gegenseitiges Verständnis verbessert die Zusammenarbeit im Team ungemein."
Hat man einmal einen Persönlichkeitstest mit Freunden gemacht, kann man sich das gut vorstellen: Plötzlich leuchtet einem Verhalten ein, das einen vorher zum Verzweifeln gebracht hat. Weitere Beispiele für die Praxis könnten für Rehn so aussehen: "Ich zeige der eher konkret denkenden Kollegin lieber etwas direkt im Code, statt mich ans Whiteboard zu stellen und ein Diagramm zu malen. Und meinen pragmatischen Bereichsleiter überzeuge ich mit anderen Argumenten als meine technologischen Frontend-Kollegen."
Tatsächlich kann man sich vorstellen, dass man so den einen oder anderen Konflikt zwischen einem Ninja und einem Zauberer vermeiden kann. Denn weiß der Ninja erstmal, dass er es mit einem Zauberer zu tun hat, können sie über ihren Code sprechen, ohne die Dinge persönlich zu nehmen. Um ihnen das Reden noch einfacher zu machen, haben Wittum und Rehn Design Cards entwickelt, die man in Endlosdebatten ziehen kann: Kommt man mal wieder auf gar keinen Nenner, spielt man einfach eine der Karten aus und lässt sie für sich sprechen. So können auch ganz mundfaule oder schwierige Entwicklertypen harmonisch über ihr Projekt kommunizieren. Und wer weiß, vielleicht wird das Prinzip bald auf andere Branchen übertragen - wenn Politiker und Beamte solche Typen-Karten im Büro hängen hätten, könnte man sich auch einiges leichter erklären.
IT-Profis finden individuelle Coaching und Beratung via Online-Video zu Themen rund um Job & Karriere bei Shifoo, dem Service von Golem.de.