| |
"Frauen in großen Rollen sind böse."
(aus Sexismus auf
Captain Kirks Enterprise)
Rollen
Wussten Sie schon, dass Projekte von Teams gemacht werden, und nicht von Unternehmen? Sicherlich,
denn in den letzten Jahren wurden ja die "Human Resources" von den Unternehmen immer
so schön in den Vordergrund gestellt und die Chefs waren immer so stolz auf das unglaubliche Potential
und die phantastische Motivation ihrer Mitarbeiter - zumindest so lange gute Leute am Markt schwer
zu finden und noch schwerer zu binden waren. Mit schlechter werdender Auftragslage, zunehmender
Umschulung auf IT, Einführung von Green Card und Zerbrechen der New Economy hat sich da wieder was
geändert. Dennoch steht und fällt ein Projekt mit dem Team und damit vor allem mit den Leuten, aus
denen es sich zusammensetzt: Gute Projekte werden von guten Leuten gemacht; noch bessere Projekte
werden von guten Leuten unter Anwendung guter Prozesse gemacht!
|
Nun, in der Praxis steht "Team" leider oft für die Abkürzung: "Toll,
ein anderer machts!" Aber zumindest in der Theorie sollte ein Team sich
aus verschiedenen ineinandergreifenden ergänzenden Rollen zusammensetzen, und dabei gibt es nicht nur
technische Arbeitsrollen, sondern auch Positionen oder besser Charaktere oder noch besser Mentalitäten,
die durch einzelne Menschen innerhalb der Gruppe vertreten werden und so ein erfolgreiches Ganzes
ausmachen.
|
|
|
|
Das noch recht neue IT-Weiterbildungssystem des BMBF (Bundesministerium für Bildung und Forschung) sieht
29 Spezialisten als Weiterbildungsprofile für Fachkräfte der IT-Branche vor
[L30]. Diese sollen sich im Laufe der Zeit in Deutschland, Europa und sogar
weltweit als Berufsbezeichnungen etablieren und durch Zertifizierungen bis hin zum Stellenwert eines
Bachelors oder Diplom-Informatikers gestützt werden. Diese Spezialistenprofile sind in sechs Gruppen
gegliedert, decken den gesamten Softwareentwicklungslebenszyklus ab und enthalten alle Rollen, die in der
Branche bisher so üblicherweise bezeichnet wurden.
|
Software Developer
(dt.: Softwareentwickler)
|
Analysieren Anforderungen,
entwerfen und implementieren
Systeme oder Module. Führen die Entwicklung eines softwareintensiven IT-Systems operativ durch.
|
IT Systems Analyst
(dt.: IT-Systemanalytiker)
|
Modelliert Geschäftsprozesse,
analysiert die daraus resultierenden
Anforderungen an IT-Systeme und bildet diese in Form von
Anforderungsmodellen ab. Agiert als Analytiker am Ende einer Beratung oder zu Beginn eines Projekts.
|
IT Systems Developer
(dt.: IT-Systemplaner)
|
Plant IT-Systeme, beschreibt sie durch ein formalisiertes Systemdesign
und begleitet ihre Umsetzung. Übliche Bezeichnungen sind auch "Architekt" oder "Designer".
|
Software Developer
(dt.: Softwareentwickler)
|
Konzipiert und implementiert einzelne Software-Bausteine
(Komponenten und Module), deren Schnittstellen und führt Entwicklertests
(Unit-Tests) durch. Wird oft auch als "Software Engineer", "Codierer",
"Implementierer" oder "Realisierer" bezeichnet.
|
Database Developer
(dt.: Datenbankentwickler)
|
Konzipiert, implementiert, optimiert und migriert Datenbanken.
Unterstützt Schnittstellenentwickler und entwirft Sicherungskonzepte.
|
User Interface Developer
(dt.: Nutzerschnittstellenentwickler)
|
Konzipiert und implementiert Schnittstellen für die Interaktion zwischen IT-Systemen und deren Anwendern.
Entwirft Prototypen unter ergonomischen
Aspekten.
|
Multimedia Developer
(dt.: Multimediaentwickler)
|
Konzipiert und implementiert interaktive Multimedia-Anwendungen für die Online- und Offline-Nutzung.
Integriert dabei unterschiedliche Medienarten in die Lösung.
|
Coordinator
(dt.: Koordinator)
|
Unterstützen und koordinieren den Entwicklungsprozess von Systemen und Software sowie die Arbeit der Developer,
übernehmen also Querschnittsaufgaben im Entwicklungsprozess und sind daher Mitglieder des Entwicklungsteams.
|
IT Project Coordinator
(dt.: IT-Projektkoordinator)
|
Leitet IT-spezifische Projekte oder Teilprojekte mit
vorgegebenen Zielsetzungen und Ressourcenrahmen.
|
IT Configuration Coordinator
(dt.: IT-Konfigurationskoordinator)
|
Organisiert das Konfigurations- und Änderungsmanagement,
indem er Softwareentwicklungsprozesse und -ergebnisse strukturiert, verwaltet und dokumentiert. Dazu gehören
auch Code, Builds und Fehlermeldungen.
|
IT Quality Management Coordinator
(dt.: IT-Qualitätsbeauftragter)
|
Erstellt Qualitätsmanagementkonzepte und -handbücher, setzt Vorgaben und überwacht die Einhaltung von
Qualität und Prozesse durch Audits.
|
IT Test Coordinator
(dt.: IT-Testkoordinator)
|
Konzipiert Testfälle für Unit-, Integrations-, Funktions-, System- und
Akzeptanztests, stellt die Testumgebungen auf und führt die Tests durch.
|
IT Technical Writer
(dt.: IT-Dokumentationsentwickler)
|
Erstellt und pflegt Dokumentvorlagen und Dokumente von IT-Projekten
und IT-Produkten.
|
Solution Developer
(dt.: Lösungsentwickler)
|
Anforderungsanalyse und Lösungsvergleich sowie Systemanpassung und
Datenmigration kennzeichnen die Lösungsentwickler. Im Unterschied zu den Developern, die etwas produzieren,
kauft ein Lösungsentwickler ein vorhandenes System oder Produkt am Markt und passt es als Domain-Spezialist
an die speziellen Bedürfnisse des eigenen Unternehmens an.
|
Business Systems Advisor
(dt.: Anwendungssystemberater)
|
Analysiert Geschäftsprozesse, konzipiert Anwendungen
und begleitet deren Einführung als Standard.
|
E Marketing Developer
(dt.: E-Marketingentwickler)
|
Konzipiert, implementiert und pflegt den Online-Bereich für die externe Unternehmenskommunikation.
|
E Logistic Developer
(dt.: E-Logistikentwickler)
|
Konzipiert, implementiert und pflegt IT-Lösungen für logistische Aufgabenstellungen.
|
Knowledge Management Systems Developer
(dt.: Wissensmanagemententwickler)
|
Konzipiert, implementiert und pflegt IT-Lösungen für den effizienten Umgang mit Wissen in Unternehmen
und Organisationen.
|
IT Security Coordinator
(dt.: IT-Sicherheitskoordinator)
|
Konzipiert, implementiert und pflegt IT-Sicherheitslösungen entsprechend geltender technischer Standards,
Gesetze und Vorschriften.
|
Network Developer
(dt.: Netzplaner)
|
Konzipiert, implementiert und pflegt Netze oder Teilnetze bedarfsgerecht und wirtschaftlich.
|
Technician
(dt.: Techniker)
|
Entwickeln Lösungen mit Hardwarekomponenten für die industrielle Produktion, Verfahrenstechnik und in der
Sicherheitstechnik.
|
Component Technician
(dt.: Komponentenentwickler)
|
Entwickelt und realisiert Hardwarekomponenten oder Geräte mitsamt der Firmware und Treiber. Erstellt
die Betriebsanleitungen und leistet Support.
|
Industrial IT Systems Technician
(dt.: Industriesystemtechniker)
|
Konzipiert, implementiert und wartet industrielle Automatisierungs- und Prozessleitsysteme, Steuerungen,
Roboter und Sicherheitskonzepte. Führt Einweisungen von Bedienpersonal durch.
|
Security Technician
(dt.: Sicherheitstechniker)
|
Beurteilt, konzipiert und implementiert sicherheitsrelevante Anlagen des Facility Managements eines
Unternehmens oder einer Organisation und bringt sie mit IT-Systemen in Einklang.
|
Administrator
|
Betreiben, Überwachen und Optimieren von vorhandenen Systemen und Infrastrukturen sind Kerntätigkeiten der
Administratoren. Kontinuierliche, immer wieder durchzuführende Prozesse unterscheiden die Tätigkeit von
den projektbezogenen Aufgaben der anderen Spezialisten.
|
Network Administrator
(dt.: Netzwerkadministrator)
|
Konfiguriert, betreibt, überwacht und pflegt Netze für Computer, Telefonie, Videokommunikation oder Funk.
|
IT Systems Administrator
(dt.: IT-Systemadministrator)
|
Konfiguriert, betreibt, überwacht und pflegt vernetzte Systeme sowie System- und Anwendungssoftware.
|
Database Administrator
(dt.: Datenbankadministrator)
|
Installiert, konfiguriert, betreibt, optimiert, überwacht und pflegt
Datenbanken. Führt Releasewechsel durch, erstellt
Scripte für Backup/Restore und leistet 2nd-Level-Support.
|
Web Administrator
(dt.: Webadministrator)
|
Entwickelt, konfiguriert, überwacht, betreibt und pflegt Websites sowie Web- und Applikationsserver.
Verwaltet die Statistiken der Website.
|
Business Systems Administrator
(dt.: Anwendungssystemadministrator)
|
Konfiguriert, betreibt und pflegt Unternehmensanwendungen. Kümmert sich um Pilotanwender und führt
die Lieferung sowie Migration durch.
|
Advisor
(dt.: Betreuer)
|
An den Schnittstellen unterschiedlicher Prozesse und Tätigkeitsprofile stehen die Produkt- und Kundenbetreuer.
Sie stellen im technischen oder kaufmännischen Bereich durch Beratung und Service die Verbindung zwischen
Herstellern und Anwendern her.
|
IT Service Advisor
(dt.: IT-Kundenbetreuer)
|
Analysiert komplexe Probleme und Anfragen von Kunden zu
IT-Produkten und Erarbeiten sowie Implementieren Problemlösungen. Leisten Support für die Anwender und
nehmen Fehlermeldungen entgegen.
|
IT Trainer
(dt.: IT-Lehrer)
|
Plant, erstellt, unterrichtet und evaluiert IT-Aus- und Weiterbildungsprogramme sowie Personalentwicklungs-
und Qualifizierungskonzepte.
|
IT Product Coordinator
(dt.: IT-Produktkoordinator)
|
Entwickelt und optimiert marktgerechte Produkte sowie Dienstleistungen. Begleitet den Lebenszyklus von
der Marktanalyse bis zum Vertrieb.
|
IT Sales Advisor
(dt.: IT-Vertriebsbeauftragter)
|
Berät Kunden bei der Auswahl von Leistungen und Produkten
und entwickelt gemeinsam mit dem Kunden (auch Key Account) individuelle Ansätze. Verwaltet die Kundenbeziehung
mit einem CRM-Tool.
|
Neben diesen fachlichen Einteilungen der Rollen in den Lebenszyklus eines Softwareentwicklungsprojektes gibt es
aber auch die - oft unterschätzte - psychologische Sicht auf die Teamrollen. Rob Thomsett hat in der Zeitschrift
"American Programmer" in der Ausgabe July-August 1990 den Artikel "Effective Project Teams: A Dilemma,
a Model, a Solution" geschrieben, in dem er folgende Rollen herausgearbeitet hat:
Chairman
|
überwacht die optimale Nutzung der Stärken der Teammitglieder, kontrolliert Einsätze
|
Shaper
|
fokussiert das Team immer wieder auf die Probleme und Ziele, hält die Vision aufrecht
|
Plant
|
sucht neue Lösungsansätze und neue Ideen, auch Technical Miner oder Scout
|
Monitor-Evaluator
|
bewertet kritisch und praktisch die Entscheidungen
|
Company Worker
|
produziert den Code zu den Lösungsansätzen, der Fließbandarbeiter
|
Team Worker
|
der Diplomat, Kommunikator und Sozialarbeiter im Team
|
Resource Investigator
|
Organisation des Teams zur Außenwelt, von Autos bis Zuschläge
|
Completer
|
macht Druck, damit auch mal was Zuende gebracht wird
|
Diese Aufstellung spiegelt Charaktere wider, die sich häufig in Teams finden. Es gibt da eben immer Leute,
die auf die effiziente Lösung des Problems nach bewährten Mustern vergangener Projekte pochen (Shaper). Denen stehen
auch immer wieder die Leute gegenüber, die an diesem Problem jetzt mal den super duper neuen Ansatz ausprobieren
wollen (Plant). Wenn Sie ein Projekt erstmalig auf einer neuen technischen Plattform realisieren müssen, werden
Sie ein Problem bekommen, wenn das Team nur aus Shapern besteht; genauso schwierig wird es in einem unternehmenskritischen
Projekt, das nur aus Plants besteht. Wenn beide Charaktere im Team vertreten sind, sollten Sie auch mindestens einen
Monitor-Evaluator dazwischen haben, der Allem immer neutral und objektiv, aber auch ein wenig skeptisch gegenüber
steht. Bei technisch intensiven Projekten verlieben sich die Entwickler oft in ihr Projekt wie in eine Modelleisenbahn
und die ganze Geschichte bekommt womöglich ein Eigenleben. Dann muss mindestens ein Completer im Team sein, der die
Leute mal wieder auf den Boden holt.
Wenn Sie mal in einem Team von mehreren - oder auch dutzenden - Entwicklern einige Monate oder Jahre mitgewirkt haben,
dann wissen Sie, dass schon nach relativ kurzer Zeit die Fronten zwischen den Leuten geklärt werden und
die Bedeutung der Leute im Team dann auch für alle Zeiten manifestiert ist. Danach wird meist sehr offen und direkt
miteinander umgegangen, was nicht immer nur angenehm ist. Daher achten erfahrene Projektleiter immer auf ein
Profil der psychologischen Rollen im Team, das auch Erfolg versprechen kann. Man sollte auch akzeptieren, dass
Männer und Frauen verschieden sind, was Sie sehr schön in dem Buch [B33]
(und dessen Vorgänger) nachlesen können (s. auch Spruch oben auf der Seite ;-). Als Projektleiter werden Sie schnell
feststellen, dass bereits die Anwesenheit einer einzigen Frau im Team verhindert, dass das Kommunikationsniveau der
Männer unter aller Anstand und Würde sinkt (ich habe allerdings auch schon von Frauen gehört, dass der Umgang in einem
Sekretariat mit ausschließlich Mädels auch nicht gerade ohne sein soll). Männer und Frauen sind aufgrund ihrer
Verschiedenheit auch unterschiedlich gut für die Rollen im Team geeignet: meiner Erfahrung nach sind Frauen beispielsweise
die besseren Completer und Männer die besseren Plants. Meines Erachtens liegt dies daran, dass Männer, die sich in
die IT stürzen, oft technik- oder detailverliebt sind und gerne lange vor sich hin prockeln (halt wie an einer
Modelleisenbahn); Frauen dagegen wollen wissen, was zu erledigen ist und werden auch tatsächlich mal damit fertig!
Dies ist übrigens der einzige Aspekt, in dem ich nicht mit [B33] übereinstimme:
dort heißt es, dass Männer ergebnisorientiert sind, Probleme lösen und ihre Ziele treffen wollen. Dies passt wegen
der großen Ähnlichkeit von IT und Modelleisenbahnen scheinbar irgendwie nicht vollständig in unser Thema. Es gab mal
in den USA eine Untersuchung zur Zufriedenheit von PC-Kunden. Dabei zeigte sich, dass die Käufer des IBM PC recht
unzufrieden waren, weil an ihrem teuren Gerät des Markenherstellers tatsächlich mal nach zwei Jahren das
Diskettenlaufwerk streikte. Die Käufer des billigen Packard-Bell hingegen waren extrem zufrieden, obwohl sich zwei von
drei Geräten bereits nach dem Auspacken gar nicht einschalten ließen! Diese Kunden frickelten aber mit ihren Nachbarn
und Freunden die ganze Nacht an der Kiste rum, bis sie endlich lief und waren dann so glücklich über ihr Erfolgserlebnis,
dass sie später tatsächlich eine extrem hohe Zufriedenheit mit dem Gerät angaben. Bei diesen Käufern handelte es sich
allesamt um Männer! Genauso kenne ich etliche Männer, die eine tolle Photoausrüstung gut sortiert im Schrank stehen haben,
aber nicht ein einziges vernünftiges Photo vorweisen können; das werden Sie bei Frauen nicht finden! Soviel zum Thema
Ergebnisorientierung bei Männern im Zusammenhang mit technischen Themen!
Gerade in großen Projekten großer Unternehmen etablieren sich schnell noch die Spezialrollen, die von der
Komplexität oder Spazialität des Projektes getrieben werden. So werden Sie schon in einem Team von 20 Entwicklern
einen "DevLead" (Development Leader, dt.: Entwicklungsleiter) finden, der diese ganze Truppe repräsentiert.
Der "Technical Evangalist" vertritt die reine Lehre einer Technologie oder Methode und ist immer für eine
Predigt gut. Das "Build Team" generiert jeden Abend einen neuen Programmstand, der nachts vom
"Burning Team" auf CDs gebrannt wird, die dann ganz früh morgens an die hunderte von Testern verteilt
werden. Ich hatte letztes Jahr mal einen "International Escalation Manager" kennen gelernt, der nur für die
kontrollierte Eskalation der international auftretenden Projektprobleme an das Headquarter zuständig war.
|
Die nebenstehende Graphik zeigt das USDP-Diagramm
mit einem möglichen Rollenprofil gemäß der BMBF-Weiterbildungsprofile. Ein
wesentliches Merkmal des USDP ist der Umgang mit
Änderungsanforderungen während der
Iterationen: Oft entscheiden Lenkungskreise
oder CCB (Change Contol Boards, dt.: Änderungskontrollgremien) über die Behandlung der Änderungsanforderungen,
die dann durch den Projektleiter in das Team weiter gereicht
werden. Dabei kann das Rollenspiel leicht anders sein, als bei der regulären geplanten Behandlung der
ursprünglichen Anforderungen. Das Rollenprofil des Projekts
sollte frühzeitig definiert, mit konkreten Namen hinterlegt und spätestens auf dem
Kick-Off-Meeting dem Team vorgestellt werden.
|
Im Zusammenhang mit den Rollen sollte immer auch die Entwicklung der Mitarbeiter betrachtet werden: wer
mehrfach in Projekten als Programmierer tätig war, eignet sich irgendwann vielleicht als DevLead und später
als Anforderungsanalytiker und schließlich nach zusätzlicher Qualifizierung als Projektleiter. Aktiv betrieben
kann dies als "Personalentwicklung" betrachtet werden, wie es früher bei größeren Unternehmen mal
üblich war und ältere Leute noch kennen ;-) Die mögliche Evolution eines Programmierers wird - sicher nicht ganz
ernst gemeint - sehr nett auf dieser
Site
beschrieben.
|
|