Laden...

Wie ist/lebt ihr den Untersschied zwischen Projektleiter und Teamleiter?

Erstellt von multitasker vor 3 Jahren Letzter Beitrag vor 3 Jahren 2.875 Views
M
multitasker Themenstarter:in
91 Beiträge seit 2008
vor 3 Jahren
Wie ist/lebt ihr den Untersschied zwischen Projektleiter und Teamleiter?

Hallo zusammen,
ich würde mich gerne mit euch austauschen zu Verantwortung und Aufgaben von Projekt- und Teamleitern.
Wir machen in unserer Abteilung klassisches Projektgeschäft. D.h. es gibt ein Standardsoftwareprodukt und in unserer Abteilung wird die Standardsoftware um von unseren Kunden angeforderte Anpassungen erweitert. In unserer Abteilung gibt es ca. 5 Teams a 5 Entwickler. Jedes Team hat einen Teamleiter. Dann gibt es noch 4 Projektleiter. Von jedem Team werden ca. 10 Projekte betreut. Diese Projekte befinden sich in verschiedenen Projektphasen. Wie manche Projekte sind nur noch im "Wartungsbetrieb", an manchen werden noch gelegentlich weiterentwickelt und manche Projekte sind gerade erst in der Startphase etc.
Die insgesamt 50 Projekte werden etwa unter den 4 Projektleitern aufgeteilt, so dass jeder ~12 Projekte hat. Die Projekteiter sind also keinem festen Team zugeordnet sondern ist im Prinzip quer gemischt.
Wir arbeiten in keinem Team mit Scrum - also es gibt kein Produktowner, etc. - aber wir verwenden diverse agile Ansätze, wir kurze Sprints etc.
Die Projektleiter sind reine Projektleiter und kennen sich mit Softwareentwicklung nicht oder wenig aus. Sie machen Budgetpläne, Meilensteinpläne, Arbeitspakete und letztere Punkte i.d.R. zusammen mit dem Teamleiter, da Ihnen das nötige Fachwissen fehlt.
Wichtig ist noch, dass die Teamleiter auch noch selbst einige Tage im Monat programmieren.
So jetzt zum Kern.
Die Projektleiter sind nun diejenigen, die von unserem Vertrieb oder Bestandskunden neue Aufträge oder Change Request bekommen. Unser Management verfolgt nun den Ansatz, dass die Projektleiter eine neue Aufgaben an einen der Teamleiter weitergeben soll und dieser dann dafür sorgt, dass die Aufgabe im Team umgesetzt wird. D.h. der Teamleiter ist für die Planung, Umsetzung, Qualität und auch das Einhalten der Deadlines verantwortlich.
Ich sehe schon auch Vorteile daran, dies so zu machen. Jedoch finde ich den Gedanken von selbstorganisierten Teams auch sehr gut und dies widerstrebt mir im Moment an dieser Stelle und ich habe noch nicht für mich selbst den richtigen Weg gefunden, so dass ich eine Vorschlag kundtun kann.
Am Anfang eines Projektes zur Planung des oder der Entwickler muss der Teamleiter involviert sein. Aber dann sollte m.E. so direkt wie möglich kommuniziert werden.

Folgendes gefällt mir nicht an dem Ansatz, dass der Teamleiter die volle Aufgabenfülle hat:

  • Der Teamleiter ist in vielen Fällen nur ein Proxy. Der Projektleiter ist die Person, die den Kundenkontakt hat. Verschiebt sich etwas von Kundenseite etc., dann fände ich es besser, wenn der Projektleiter direkt mit dem Entwickler spricht.
  • Ist der Teamleiter krank, verhindert etc. dann ist die Kommunikation gestört, da der Teamleiter derjenige ist, über den die ganze Kommunikation in der Regel geht.
  • Direkte Kommunikation von Kunde zu Entwickler sollte auch üblich sein, da dadurch keine Informationen verloren gehen können und man häufig effizienter an's Ziel kommt.
  • es gibt verschieden Studien die belegen, dass selbstorganisierte Teams glücklicher und erfolgreicher sind.

Gerade auch das prüfen der Meilensteine und rechtzeitiges Ausliefern ist aus meiner Sicht typische Projektleitungstätigkeit. Soll aber bei uns die Aufgabe des Teamleiters sein.

Wie ist eure Meinung dazu und wie wird dies bei euch gelebt?

16.807 Beiträge seit 2008
vor 3 Jahren

Du beschreibst im Endeffekt ein als eher historisch organisierten Hierarchie-Verlauf.
Ich pick mir mal paar Dinge raus:

Scrum

Scrum ist primär mal eine Organisation von Teams, die den Ursprung in der Inhouse-Entwicklung hat und oft im Projektgeschaft aka Beraterhäuser irgendwo Probleme machen; bzw einfach nicht alles nach Scrum so wirklich funktioniert.
Daher gibt es da immer irgendwelche Abwandlungen.

Schwer wird es, wenn man neue agile Projekte hat und dann noch alte Projekte pflegen muss.
Das ist mit einer einzigen agilen Methode eines Teams nach Papier nich umsetzbar => Abwandlung notwendig.

Noch schwerer wird es, wenn das Management im Kopf immer noch in der Wasserfall-Welt unterwegs ist aber die Teams nach agilen Methoden leben sollen.

Je mehr Teilnehmer in einer Kette sind, desto mehr gilt Expectations VS Reality of Client + Business Analyst+Developer=Coding

Projektleiter vs. Teamleiter

Die klassische Aufgabenbeschreibung eines Projektleiters gibt es eigentlich nur noch in der Wasserfall-Welt; und offenbar arbeitet ihr auch danach, wenn ich die Beschreibung dazu lese:

Die Projektleiter sind reine Projektleiter und kennen sich mit Softwareentwicklung nicht oder wenig aus. Sie machen Budgetpläne, Meilensteinpläne, Arbeitspakete und letztere Punkte i.d.R. zusammen mit dem Teamleiter, da Ihnen das nötige Fachwissen fehlt.

Viele Firmen versuchen aber auch in agilen Teams Projektleiter zu integrieren; ganz oft sogar in der Position des Scrum-Masters.
Der Trugschluss: die meisten agilen Coaches und Co sehen den Job als Projektleiter als aussterbend an (ich auch), weil Du heutzutage einfach in der schnellen Entwicklerwelt einfach Fachwissen (damit meine ich die Domäne, nicht die Technik) brauchst, um irgendwas planen zu können.
Alles andere ist Dart-Werfen; nicht mehr - nicht weniger.

Dann gibts wieder so Artikel wie "Projektleiter sind kein Auslaufmodell": doch sind sie. Ein Projektleiter ist "Command and Control" - und das gibt es in einer agilen Welt nicht mehr.
Die klassischen Projektleiter sind Auslaufmodelle. Sie müssen sich in der agilen Welt verändern; verlieren den Aufgaben-Fokus und haben mehr und mehr einen
Prozess-Fokus.

Ein Teamleiter hingegen ist eigentlich ein vollständiger Teil des Teams; hat zusätzlich jedoch die disziplinarische Verantwortung; kann also in einer Agilen- wie auch in einer Wasser-Fall-Welt existieren.

Unser Management verfolgt nun den Ansatz, dass die Projektleiter eine neue Aufgaben an einen der Teamleiter weitergeben soll und dieser dann dafür sorgt, dass die Aufgabe im Team umgesetzt wird. D.h. der Teamleiter ist für die Planung, Umsetzung, Qualität und auch das Einhalten der Deadlines verantwortlich.

Das ist halt die Wasserfall-Welt. Das ist genau das, was in der Breite ja eben nicht wirklich gut funktioniert und es daher neue Ansätze gibt.
Wenn euer Management nicht hinter euch steht, dann wird das immer schwer und ein Konfliktpunkt bleiben.

Ist der Teamleiter krank, verhindert etc. dann ist die Kommunikation gestört, da der Teamleiter derjenige ist, über den die ganze Kommunikation in der Regel geht.

Davor gibt es eigentlich kaum einen Schutz; egal ob die Position nun Projektleiter, Team-Leiter oder Scrum-Master heisst.
Es gibt eigentlich immer irgendwo einen Flaschenhals.
Es ist ineffizient jede Position doppelt zu halten.

In großen Strukturen gibt es dann Prince2 oder Scrum of Scrum, sodass ein Scrum-Master einspringen kann, wenn jemand anderes ausfällt.
Aber das geht halt nicht in jeder Struktur.

Direkte Kommunikation von Kunde zu Entwickler sollte auch üblich sein, da dadurch keine Informationen verloren gehen können und man häufig effizienter an's Ziel kommt.

Hier muss man aufgrund eurer Konstellation vorsichtig sein:
Der Gedanke ist gut; birgt für die Firmen aber Risiken. Bei solch einer Kommunikation muss man darauf achten, dass der Entwickler keine fixen Commitments macht, weil diese sonst - auch mündlich! - als Lieferungsbestandteil gelten.
Das muss man so organisieren, dass das niemals passieren kann; sonst haftet ihr natürlich.

es gibt verschieden Studien die belegen, dass selbstorganisierte Teams glücklicher und erfolgreicher sind.

Das ist definitiv so; trotzdem muss sich das Team an Spielregeln orientieren: Ziele vorgeben, Constraints vorgeben, Team muss diszipliniert und homogen sein.

49.485 Beiträge seit 2005
vor 3 Jahren

Hallo multitasker,

Kunde <-> Projektleiter <-> Teamleiter <-> Entwickler

hat schon was von Stille Post.

  • Direkte Kommunikation von Kunde zu Entwickler sollte auch üblich sein, da dadurch keine Informationen verloren gehen können und man häufig effizienter an's Ziel kommt.

Anderseits bedeutet es, dass der Kunde nur einen Ansprechpartner für Alles hat und das hat schon auch Vorteile. Vor allem, wenn es jemand ist, der die Sprache des Kunden spricht. Und das ist sicher nicht bei allen Entwicklern so. Daher bin ich da nicht ganz auf deine Seite. Und direkter Kundenkontakt ist sicher auch aus anderen Gründen nicht jeder(entwickler)manns Sache.

  • Der Teamleiter ist in vielen Fällen nur ein Proxy. Der Projektleiter ist die Person, die den Kundenkontakt hat. Verschiebt sich etwas von Kundenseite etc., dann fände ich es besser, wenn der Projektleiter direkt mit dem Entwickler spricht.

Auch hier gilt natürlich, dass der Projektleiter nur einen Ansprechpartner hat, was seine Vorteile hat. Hier sehe ich aber eher Möglichkeiten, denn das ist ja alles firmenintern. Und wenn der Projektleiter eh die Pläne macht, weiß er ja auch vermutlich wen er für was ansprechen müsste. Hier könnte man also eine (Stille Post-)Station einsparen.

  • Ist der Teamleiter krank, verhindert etc. dann ist die Kommunikation gestört, da der Teamleiter derjenige ist, über den die ganze Kommunikation in der Regel geht.

Das wäre dann nicht mehr der Fall. Allerdings könnten sich die Teamleiter dadurch auch übergangen oder abgewertet fühlen. Also überleg dir genau, wen du dir durch einen entsprechenden Vorschlag vielleicht zum Feind machst.

Ich finde einen Teamleiter für fünf Leute allerdings sogar eher ganz entbehrlich, gerade wenn die eigentliche Planung sowieso der Projektleiter macht. Bei 25 Leuten würde aus meiner Sicht ein Abteilungsleiter als (direkter) Personalverantwortlicher reichen. Aber das ist natürlich eine noch klarere Kampfansage gegen die Teamleiter.

herbivore

M
multitasker Themenstarter:in
91 Beiträge seit 2008
vor 3 Jahren

Vielen Dank für die wertvollen Beiträge Abt und herbivore. Ich muss das jetzt erst mal wirken lassen und mir nochmal Gedanken machen.