Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsBlizzard: Activision legt Fokus auf Spieleentwicklung
Wer hat weiter oben angefangen den anderen erzählen das sie keine Ahnung haben ohne mal was zum Background zu erfragen
Projektmanager = Excel und PowerPoint Spezialist ohne oder nur mit rudimentären Fachkenntnissen. In Teams mit gut qualifizieren und selbstständigen Mitarbeitern benötigt man solche Leute eigentlich gar nicht. Viele Projekte sind Overmanaged.
+1 Und der Knaller ist, dass vor allem das Management genau das nicht versteht.
Allein wenn ich mir vorstelle, alleine welchen Meta-Aufwand wir uns sparen könnten, wenn wir konsequent Kanban einsetzen würden ...
Projektmanager = Excel und PowerPoint Spezialist ohne oder nur mit rudimentären Fachkenntnissen. In Teams mit gut qualifizieren und selbstständigen Mitarbeitern benötigt man solche Leute eigentlich gar nicht. Viele Projekte sind Overmanaged.
Er hat doch recht, ein vernünftiges Team managedt sich selbst. Kenne ich noch aus der Schulzeit. In vernünftigen selbst gewählten Gruppen gab es keinen Chef. Statt das einer alles koordiniert kamen die Ideen und Arbeitsaufteilung von jedem selbst. Vielleicht hat der eine mal irgendwas angestoßen von wegen "wie machen wir das jetzt?", aber ansonsten. Irgendwer hats ausgedruckt/Stick mitgebracht usw. Am Ende eine Eins kassiert und fertig war das Ding. Selbe auch in Sport: "Ich geh ins Tor" - und wir wussten ganz genau, es lief.
Wenn du von kleineren Projekten redest, gebe ich dir Recht.
Wie managen sich denn 8 verschiedene Teams (zB Client, Security, Design, Marketing,..) selbst?
Jeder für sich? Alles alleine?
Wenn alle Mitarbeiter perfekt arbeiten würden, könnte das sogar klappen. Viele Techniker sind schon überfordert wenn ein paar Tasks offen sind und müssen stets erinnert werden.
Zudem sind mir keine PM bekannt, die keine fachliche Ahnung haben. Ich selbst war Systemadmin und wechselte später ins PM. Die Erfahrung hilft enorm. Ansonsten könnte man ja Kreise mit den Budgets und Lieferzeiten ziehen und keiner wäre ehrlich, right?
Aber Projektmanager als Excel/Powerpoint Junkies darzustellen ist komplett daneben. Man hätte MS Visio und Project erwähnen können.
Ach wozu rede ich, mich und andere PM einfach kündigen, die Stellen sind ja eh unnötig :-)
Projektmanager = Excel und PowerPoint Spezialist ohne oder nur mit rudimentären Fachkenntnissen. In Teams mit gut qualifizieren und selbstständigen Mitarbeitern benötigt man solche Leute eigentlich gar nicht. Viele Projekte sind Overmanaged.
Bin mir gerade nicht sicher, ob das nicht einfach Getrolle ist. Es gibt mehr als genug PM-Stellen bei denen ein Informatikstudium, mehrjährige Erfahrung als Enwickler und Systemarchitekt, sowie Erfahrung in der Führung von Menschen vorausgesetzt wird. o_O
Davon abgesehen ist es als kleiner Entwickler vielleicht schwer zu verstehen, jedoch ist bereits das Vermitteln zwischen den Stakeholdern oft schon eine eigene Stelle für sich, die der PM bei größeren Projekten noch nebenbei machen muss.
Wenn alle Mitarbeiter perfekt arbeiten würden, könnte das sogar klappen. Viele Techniker sind schon überfordert wenn ein paar Tasks offen sind und müssen stets erinnert werden.
Viele Entwickler sind sogar überfordert, die Klappe aufzumachen, wenn ihnen eine Anforderung unklar ist. Von daher wundert es mich warum Tek9 so sehr gegen Projektmanager wittert. Selbstregulation innerhalb eines Teams funktioniert nur bei kleinen Projekten, mit einem einzigen Team. Spätestens wenn man zwei Teams hat, die parallel an aufeinanderbauenden Komponenten entwickelt hat man den Salat. In der Richtung hat Caramelito vollkommen recht!
Der Thread hat bereits einen Splitt hinter sich. Das reicht fürs erste.
PM sind wichtige Leute ohne die ein Projekt nicht funktioniert. Logisch.
Schlechte PM sind allerdings dann auch wieder dafür verantwortlich das Projekte schlecht laufen.
Natürlich nur im Rahmen ihres Wirkungsbereich. Wenn von weiter oben wirre Vorgaben kommen, sind der PM Truppe die Hände gebunden. Auch logisch.
Die Zankerei ist weiter oben lediglich losgegangen weil ein einzelner der Meinung war das andere zu wenig Erfahrung hätten um das treiben bei der Blizzard zu kommentieren. Sowas führt dann halt zu angeregten Diskussionen
Ergänzung ()
Airbag schrieb:
Selbstregulation innerhalb eines Teams funktioniert nur bei kleinen Projekten, mit einem einzigen Team.
Diese Aussage wirkt unlogisch. Innerhalb eines Team können die Leute sich nicht selber organisieren weil es mehrere Teams gibt?
Im Fahrzeug- und Flugzeugbau wird das seit Ende der 1960er so gehandhabt...
Es kommt mmer auf die Leute im Team an. Ich habe zwei Arten von Devs erlebt. Die einen wollen nur entwickeln und machen genau das was man ihnen sagt. Diese anderen brauchen keinen Vorarbeiter/PMO/BPL der in täglichen Standups den Leuten erzählt was sie zu tun haben.
IIn meiner Firma geht es man stark in die Richtung, das dieses Leute sich selber organisieren. Das ist die Zukunft und die wird auch von jeder Strategieberatung empfohlen.
WWenn die Leute dafür nicht geeignet sind, müssen sie halt ausgetauscht werden
Dann hast du das falsch verstanden. Ich habe nicht gesagt, ihr hättet keine Erfahrung und ich wüsste wie es läuft. Ich habe gesagt, dass es in der Realität komplett anders aussieht, egal was in den Artikeln und Berichten steht.
Siehe Finanztyp, der einfach raus ist.
Die können sagen was sie wollen, es gab/gibt immer einen anderen Grund.
Und wenn Blizz sagen würde, dass sie Scrum, Kanbsn oder was auch immer leben, gibt es sicher Top Manager die von heute auf morgen alles aufn Kopf stellen.
Und dann fingst du an mit PM seien Excel Junkies oder whatever.
Was Airbag schreibt isz, dass sich ein kleines Projektteam selbst managen kann. Aber wenn sie von anderen Teams abhängig sind oder Teil eines größeren Projekts sinds, ists dann wieder vorbei.
Abgesehen davon, sind Budgets und zeitliche Ziele nicht gerade die Stärke von Technikern und Entwicklern. Sie hätten am liebsten alles perfekt in Qualität, was ich gut finde. Aber Zeit und Budget sind für Top Manager meist wichtiger. Und hier alles so hinzubiegen ist eben eine Herausforderung. Manchmal nicht einmal möglich.
In einem staatlichen Projekt (alte Firma) hatten wir eine GF die einfach mal so 6 Monate früher live gehen wollte wegen den Wahlen. Die App war mist, obwohl bestmögliche Arbeit der Entwickler geleistet usw. - Aussen stand „agil“ drauf ;-)
Es gibt mehr als genug PM-Stellen bei denen ein Informatikstudium, mehrjährige Erfahrung als Enwickler und Systemarchitekt, sowie Erfahrung in der Führung von Menschen vorausgesetzt wird. o_O
Dann ist ja alles okay, weil wir im Grunde genommen das gleiche meinen
Ja ich war auch schon in Projekten unterwegs wo die GF unbedingt ein ganz bestimmtes (ungeignetes) Tool haben wollten und dann solange Leute rausgeworfen wurden bis keiner mehr da war der Widerstand geleistet hat. Das Ergebnis nach dem Go Live war dann dementsprechend ernüchternd.
Wo ich nicht zustimme ist das Geschichte das immer irgendwer den Fachleuten sagen muss was und insbesondere wie sie es zu tun haben. Das "wie" können die besser unter sich ausmachen weil sie die Fachleute sind.
Wenn die Fachleute und Devs ihre Entscheidungen selber treffen, geht es auch deutlich schneller und man braucht weniger hauptberufliche Entscheider.
Das Hören die PM Kollegen natürlich nicht so gerne weil dann ihre Jobs weg sind. Das sollte nicht falsch verstanden werden. Ich war in Projekten unterwegs in denen es mehr administrative Leute als Techniker gab und eine Deadline nach der anderen gerissen wurde weil einfach zu wenig Macher und zu viele Manager da waren. Es waren schlichtweg zu wenig Techniker Stellen vorhanden. Es wurde aber immer fein säuberlich Reported und in Meetings diskutiert das die technische Umsetzung noch nicht fertig wäre XD
Das Konzept (von den Technikern) oder der Plan wird dem Steering vorgelegt, die entscheiden dann wegen dem Budget. Wenn es mehrere Lösungen gibt dann werden Vor- und Nachteile aufgezeigt.
Das „Wie“ entscheidet kein PM der Welt und wenn, wozu hat er Techniker?
Das kann man gar nicht wissen. Unsere Client Kollegen zB haben Jahrzehnte Erfahrung und arbeiten eng mit MS zusammen und tauschen sich aus. Woher soll ich dann besser wissen wie etwas funktioniert?
Kenne mich aus, befasse mich privat damit, aber auf Firmen oder Konzern-Ebene ist das etwas anderes.
Hatten schon im Steering eine Diskussion, wo Top Manager (unsere und die vom „Kunden“) auf einmal wussten, dass das gescheiterte doch gehen muss. Auf die Frage von mir, ob denn deren und unsere Experten unqualifiziert seien, erhielt ich leider keine Antwort
Nochmal ne Anekdote die ich mit den selbsternannten Experten aus der Leitung erlebt habe:
Im Meeting in dem die Entscheidung getroffen werden sollte ob ein Tool weit genug wäre um damit produktiv zu arbeiten, habe ich verkündet das lediglich die Kernfunktionen rudimentär getestet wurden und ich keine Verantwortung für einen gesicherten Betrieb übernehmen kann.
Der Product Owner hat dann entscheiden das wir Live gehen und alle Fehler binnen von X Wochen ausgemerzt werden. Mangels Tests waren die Fehler nicht vollumfänglich bekannt und die angesetzte Zeit für die das Bugfixing völlig illusorisch. Es hat dann tatsächlich ein Jahr gedauert bis die meisten Probleme bereinigt wurden.
Natürlich wollen die Techies immer alles auf hübsch machen, was dann oft zu teuer wird. Was sollen sie sonst machen außer auf zu erwartende Probleme hinzuweisen
Inwiefern hilft das der Diskussion weiter? Es stand im Raum, dass PMs grundsätzlich keine fachliche Expertise besitzen und nur xls und ppt - Dateien hin- und herschieben. Das hat sich ja nach nach weiteren Aussagen von tek9 relativiert. Das es vereinzelt absolut unfähige Leute gibt, bezweifle ich nicht, jedoch nehme ich es nicht als Normalfall an...
Der Product Owner hat dann entscheiden das wir Live gehen und alle Fehler binnen von X Wochen ausgemerzt werden. Mangels Tests waren die Fehler nicht vollumfänglich bekannt und die angesetzte Zeit für die das Bugfixing völlig illusorisch. Es hat dann tatsächlich ein Jahr gedauert bis die meisten Probleme bereinigt wurden.
Grundsätzlich nicht das Problem und auch nicht unüblich. Fragt sich halt wie gut es dann kommuniziert wurde und wie realistisch das Ausfallrisiko kalkuliert ist.
Bei gesetzlichen Anforderungen gibt es beispielsweise oft keine Wahl, ob man etwas Unfertiges live nimmt oder nicht.
Ein GUTER PM hört im übrigen mehr zu, insbesondere außerhalb des Teams damit eben kein Overhead an Kommunikation für alle entsteht. Ebenfalls muss ein PM nun mal priorisieren und da ist er in der Regel auf Expertiese aller Abteilungen angewiesen auch wenn diese den „DEVs“ nicht immer schmeckt.
Gutes Beispiel:
- Miserables Logging.
— den DEVs oft egal, da sie es meist nicht besser wissen und „größere Probleme“ haben. Dass zB Logs gestreamt gehören und dazu ein paar Regel vorher eingehalten werden müssen ist dem PM dann wieder nicht egal, da „sein Produkt“ vollumfänglich betreut werden will.
Mit nem Tool live zu gehen das noch nicht fertig und ausreichend getestet ist, ist nunmal Bullshit. Das kann man mit nem AAA Game machen aber mit ERP Systemen ist das Bullshit.
Die Kosten die das unfertige Tool im Fachbereich erzeugt sind höher als die Kosten für die Fertigstellung.
Als Berater der auch Programmieren kann, bin ich halt nicht mit solchen Sachen wie Budgetplanung beschäftigt.
Wenn ich das nicht mehr könnte, würde ich wohl auch PM machen. Zum Glück darf ich noch was selber machen, was heute nun wirklich nicht mehr selbstverständlich ist. /no offense
Die Diskussion wird immer interessanter weil hier anscheinend eine Vielzahl von Leuten mit völlig unterschiedlichen Rollen unterwegs ist. Jeder hat natürlich seine ganz eigene Sichtweise auf das Geschehen.
Wie bei CB üblich, weiß es aber auch wieder jeder besser als der andere.
Tja, so ist das. Meinungen entstehen aus Erfahrung und/oder Hörensagen. Da hier niemand bei Blizz arbeitet befinden wir uns bei den Gründen beim Hörensagen.
Meine Erfahrung ist für das „recht kurze“ Berufsleben von 14 Jahren schon recht weit gefächert.
- Gelernter Entwickler
- Jahrelang System Engineer
- Ebenfalls IT-Architekt
- Consulting
- QA
- TL
- Eine Art PM, wenn man so will. (Kein Klassisches Produkt, eher sowas wie technischer key accounter)
Das ganze seit Anbeginn im „DevOps“ Style, schon bevor es das Buzzword gab. Und bei all dem technischen Krams den ich so geleistet habe gabs eine Erkenntnis: Ohne die Prozesse dazu ist das alles Perlen vor die Säue. Um Prozesse durch zu bekommen braucht man Gewicht, was man in der Regel durch Positionen bekommt, meist dann (leider, oder auch nicht) nun mal auf Managementebene.
Mein Ziel ist es, immer technisch soweit auf der Höhe zu bleiben um Diskussionen im Team auch selbst zu verstehen, da gerade bei Technologieentscheidungen es oft zum Tauziehen im Team kommt.
Ob ich damit die Ausnahne oder die Regel bin, will ich nicht beurteilen, dennoch wird der technische Teil zwangsläufig immer weniger. Ist der Lauf der Zeit. Man wird entweder Principal oder Manager.
Genau dadurch werden auch mal Dinge „von Oben“ entschieden, weil man das große Ganze kennt. Die Kunst ist es eigentlich Gründe ausreichend zu kommunizieren ohne das es das Team belastet Bzw soweit es halt Sinn macht (Es sind am Ende halt Fachtechniker und sollen sich auch primär darum kümmern, das meine ich nicht von oben herab aber wenn es nicht so wäre dann macht halt keiner mehr was auf der technischen Ebene. Sowas wie Wertschätzung fehlt leider viel zu oft)
Auch das ist richtig, die Leute brauchen jemanden der ihnen den Rücken freihält damit sie sich um ihre Arbeit kümmern können.
Allerdings ist der Trend halt da die Leute zu Engagement und Empowerment zu erziehen. Ein Management Layer der Entscheidungen fällt die gut ausgebildete Leute auch selber treffen ist dann nicht mehr nötig. Idr wissen die Leute die umsetzten auch am besten wie und was zu machen ist. Aber genug der Buzzwords.
Die PM Truppe soll sich um außen und oben kümmern und ihren PM Kram machen. Das können sie am besten und dafür sind sie da
