Homepage Ralf BürgerSSEKonstruktion > Rollen Ralf Bürger SSE Rollen Inhaltsverzeichnis Index Vorseite Folgeseite  
 
 

"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.

Sichten

 

BMBF-Spezialisten

 
 

Psychologische Rollen

 
 

Spezialrollen

 

Spezialistengruppen

 

Software Developer

 
 

Coordinator

 
 

Solution Developer

 
 

Technician

 
 

Administrator

 
 

Advisor

 

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.

153 KB

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.

 

  Homepage Ralf Bürger Ralf Bürger SSE Rollen Konventionen/Hilfe Änderungen/Neues Inhaltsverzeichnis Index Vorseite Folgeseite Seitenanfang