http://www.caseconsult.com/info/H.Sneed/de/

http://www.computerwoche.de/index.cfm?pageid=257&artid=38958

(Siehe auch TeamarbeitDerGroßeMythos, ein weiterer Artikel derselben Zeitschrift, der verwandte Aussagen enthält.)

(Siehe auch FührenUndLeiten.)

Was sagt Sneed wirklich?

Kann mir mal jemand sagen, wo Sneed - wie Ilja meint - (immer wieder) feststellt, dass in seinen Teams nur 25% der Entwickler wirklich produktiv sind? Bitte das Zitat nennen (vollständige Sätze, keine Halbsätze), danke. -- VolkerGlave

"In der Regel werden 75 Prozent der Teamleistung von 25 Prozent der Mitglieder erbracht." Gleich der erste Satz im Artikel. Und der Verweis auf das Forum der Computerwoche (Kasten am Ende des Artikels) beinhaltet im zweiten Satz: "IT-Guru Harry Sneed ist der Meinung, dass 75 Prozent der Programmierer überflüssig sind." -- bs

Ich finde, Herr Sneed wird sehr deutlich, wenn er schreibt: "Die meisten, die in der Entwicklung tätig sind, werden von den wenigen, die es wirklich können, mitgeschleppt." Und später: "[...] stelle ich fest, dass in allen Projekten, an denen ich beteiligt war, immer nur eine oder zwei Personen die Hauptlast der Entwicklung getragen haben. Die anderen haben zum Endergebnis kaum etwas beigesteuert, und es wäre oft besser gewesen, sie gar nicht dabeigehabt zu haben." -- ip

Ja, doch, das belegt wohl doch, dass Deine obige Zusammenfassung (Einleitung) angemessen ist.

...wenn auch weniger, als die anderen 25%... um genau zu sein: die wirklich produktiven Mitglieder sind um den Faktor 9 produktiver nach dieser Rechnung...; da kann man natürlich schon behaupten, dass die anderen (jeder einzeln betrachtet) vergleichsweise nix tun... [ Aber natürlich: Kleinvieh macht -in genügender Anzahl- auch Mist... ]

Es geht im Sneed-Artikel [...] um eine eingeschätzte Verteilung von Arbeitseffektivität in Gruppen. --hs

Es erstaunt mich, wie kleinlich Du ob des oben angewandten Sprachgebrauchs bist. Aus meiner Sicht gibt es gar keinen Grund, den Ilja-Satz korrigieren zu wollen.--hs

Genau das nach "Andererseits" meine und meinte ich auch. Desweiteren handelt es sich um einen sogenannten Schlagsatz. Da sollte man nicht eine Präzisionsmeßlatte anlegen; das ist IMO falsches Sprachverständnis.--hs

Bezieht sich das jetzt auf meinen Satz, oder auf den von Herrn Sneed??? -- ip

Auf den Satz von IljaKuryakin?.--hs

Pro

Ich stimme seinen Aussagen zu 100% zu!
Seine Aussagen passen eigentlich zur gesamten Berufswelt recht gut.
Ich stimme ihm übrigens aus mehrfacher eigener Erfahrung zu. --HelmutSchellong

Volle Zustimmung, habe ich auch schon erlebt (und zwar in einem "wissenschaftlichen Institut" mit ca. 10 aktiven Mitarbeitern. Ich darf da mal ohne jede falsche Bescheidenheit sagen, dass ich einer der 2-3 Mitarbeiter war, die (zeitweise) ca. 75% der wirklich produktiven Arbeit geleistet haben. Man glaubt gar nicht, wie geschäftig manche Leute ihre Zeit damit rumbringen können, nichts (wirklich Relevantes) zu tun...; erstaunlicherweise klag(t)en gerade diese Leute besonders oft und lautstark über ihre schier unerträgliche Arbeitsbelastung... [ Alles erlebt! ]

Und rate mal, wer (zuerst) entlassen wird, wenn gemäß falsch verstandenem Lean-Management Entlassungen im großen Stil angeordnet werden? - Genau die Leistungsknoten in den jeweiligen Abteilungen!--hs

Kontra

Dem kann ich mich nicht anschliessen ... ich betrachte mich selbst aber auch nicht als einen Softwareguru, wie Herr Sneed einer zu sein scheint ... in allen Teams, in denen ich gearbeitet habe, haben mind. 85% der Mitglieder Ihren eigenen speziellen Beitrag zu der gesamten Teamleistung mit eingebracht. Kontraproduktive Positionen kenne ich grossteils von Leuten aus Sales und Management - da erlebe ich eigentlich die meisten Trittbrettfahrer, die einem Projekt aktiv oder passiv sehr grossen Schaden zufügen. Insofern schliesse ich mich der Meinung von IP an :-)

Wenn Herr Sneed eine solche Aussage macht, hat er noch nie die unglaubliche Kraft eines Teams erlebt ... ( und wenns in einem Projekt nicht so läuft, sind ja die anderen 75% schuld ...). Im Ernst, es gibt Umfelder in denen ich mir solche Aussagen vorstellen kann, da nenn ich jetzt keine Beispiele. Aber auch in unwirtlichen Umgebungen wachsen Teams, man muss sie nur erkennen und pflegen ! -- MichaelJerger

Michael, wir liegen hier voll auf einer Wellenlänge! :-)

IMO entstehen die Probleme nicht durch die selbstverständlich vorhandenen Leistungsunterschiede im Team, sondern dadurch, dass diese *gepflegt* werden und zu einer Zerstörung des Teams führen. Wenn die "Gurus" von den anderen genervt sind und gegen deren Arbeit ankämpfen, statt ihnen zu helfen ihre Arbeit besser zu verrichten (z.B. durch ProgrammierenInPaaren) ist es kein Wunder, dass ein Großteil des "Teams" unproduktiv ist! Wenn man es jedoch schafft, aus diesen Leuten wirklich ein Team zu bilden das zusammenarbeitet, wird man möglicherweise feststellen, dass jeder etwas zum Projekt beitragen und von jedem noch etwas lernen kann. Allerdings erfordert das von den "Gurus" die Einsicht, dass auch sie noch Hilfe gebrauchen können, dass es gut ist, wenn ihre genialen Konzepte ab und zu durch eine "dumme Frage" in Frage gestellt werden - und die Bereitschaft darauf zu verzichten, zum Schluss als heldenhafter Retter des Projektes dazustehen ... -- ip

Helmut, führt nicht genau die Einstellung "wer unproduktiv ist hat hier keinen Platz" zu dem Phänomen, dass jeder möglichst hohe Produktivität vortäuschen muss, auch wenn er sie gar nicht erbringen kann? Wozu bräuchte es Trittbrettfahrer, wenn die Produktivität gar keine so hohe Rolle spielen würde? -- ip

Ich war schon oft in grossen Firmen tätig und da gibt es viele Abteilungen, in denen keine Gurus zu finden sind. Ich hab aber noch nie eine Abteilung getroffen, in der kein Team schlummert :-) -- mj

Ungeordnet

Ob er Führungskraft ist oder nicht, ist eigentlich völlig egal. Ich beziehe mich auf seine Aussagen - und die sind schlicht richtig: Kreativität, Disziplin, Konzentrationsfähigkeit, Abstraktionsfähigkeit, Ausdauer, Konzeptfindungskraft, Qualität, Problemerfassung, Strategie/Abwicklung. Das sind Eigenschaften, die einen richtig guten Entwickler/Programmierer ausmachen, die aber höchst selten alle zusammen in jeweils hohem Grade vorhanden sind. Meist ist nur wenig davon vorhanden.--hs

Du hast sicherlich recht, dass jede dieser Eigenschaften einen Entwickler wertvoller für ein Team macht. Und Du hast auch recht, dass es recht unwahrscheinlich ist, alle diese in einer Person anzutreffen. Ich wage sogar die Behauptung aufzustellen, dass selbst keiner der 25% "Gurus" *alle* diese Eigentschaften in ausreichendem Maße mit sich trägt. Die Lösung ist daher für mich, ein ausgewogenes Team zusammenzustellen und dafür zu sorgen, dass sie zu 100% zusammenarbeiten - und nicht, 75% des Team zu feuern ... -- ip

So ein Quatsch, es reicht einen zu haben, der kreativ ist, einen mit Abstraktionsfähigkeit, einer der die Probleme des Kunden kennt und einer der alles organisiert und dafür sorgt, dass die anderen in Ruhe arbeiten können. Disziplin brauchen alle ... das lässt sich aber lernen. Es kann schon sein, dass nicht so viele Leute Software entwickeln können. Das liegt daran, dass Sie nicht die Möglichkeit haben in einem Team zu lernen und an Ihren Aufgaben zu wachsen. --mj

1. phantasiebegabte Visionäre/Spinner, die die entscheidenden neuen Grundideen entwickeln,
2. realistische Macher/Tüftler, die mit sämtlichen Beinen fest auf dem Boden der machbaren Realität stehen und die Spinner auf diesen Boden zurückziehen,
3. begabte Verkäufer/Redner/Schreiber, die das Projekt und seine Haupt-Konzepte erfolgreich nach außen propagieren und verkaufen können,

Ja, dem kann ich nur zustimmen. Als Beispiel: vor zwei Jahren habe ich mit einem guten Freund an einem Projekt zusammengearbeitet, wo wir das zentrale Datenmodell umgestellt haben um eine gewisse Erweiterung zu ermöglichen. Ohne seinen praksis-orientierten Ansatz wäre mein objekt-orientierter Ansatz nicht implementierbar gewesen. Andererseits wäre ohne die objekt-orientierte Neustrukturierung des bisherigen Pointerwaldes drei Monate später eine neuerliche Generalsanierung angestanden. Ohne die enge Zusammenarbeit unserer verschiedenen Ansätze wäre das Design nicht so erweiterbar, stabil und einfach zu implementieren gewesen.

Das kannst du höchstens vermuten, nicht wissen. Möglich (im Sinne der Redensart "Man hat schon Pferde kotzen sehen"), dass ohne die Zusammenarbeit das Design ebenso (oder sogar noch mehr) erweiterbar, stabil und einfach zu implementieren gewesen wäre. -- vgl

Ich finde auch: Aus meiner Erfahrung - in diversen Teams - trifft Herr Sneed den Nagel auf den Kopf. Auch wenn das viele Entwickler nicht gerne hören. -- dat.r0x@gmx.net

Kann man nach Euren Erfahrungen denn nichts tun, um daran etwas zu ändern? Was habt Ihr bisher probiert, um die Produktivität Eurer Kollegen (und damit des gesamten Teams) zu erhöhen? Was hat funktioniert und was nicht (und warum)?

Daran kann man nichts tun - man kann es nur bemerken. Wenn das Denkvermögen nicht da ist, sind Hopfen und Malz verloren. Leider können sich solche Leute lange durchmogeln und sind auch nicht selten ausgerechnet die Lieblinge der Vorgesetzten. --hs

Das ist aber traurig. Wer nichts mehr verändern will, für den wird sich auch nichts mehr verändern ... -- mj

Ja. Diejenigen, die nichts ändern wollen, sind ja die, denen das notwendige Denkvermögen/Talent fehlt. Das einzige, was die tun können ist es, einen anderen Beruf auszuüben - von seltenen Ausnahmen mal abgesehen.
Wer sich den falschen Beruf ausgesucht hat, verursacht gewaltige Kosten und Zeitverschwendungen. Allein schon deshalb, weil er beim Austausch innerhalb der Kollegengruppe Dinge erst nach der achten Erklärung versteht, oder gar nie nicht versteht und daher einen Dummy programmiert, den andere dann anschließend nochmals programmieren müssen, so daß es kein Dummy mehr ist. Aber dann ist der gewaltige Projektschaden (Termine!) bereits passiert.--hs

Eignetlich bezog sich meine Aussage auf Daran kann man nichts tun ...

Bei dem Projektschaden liegt meiner Ansicht nach der Fehler übrigens nicht bei den Dummy-Programmierern, sondern bei der Projektleitung (falsche Leute ausgesucht) oder im fehlenden Teamgeist (ein Team funktioniert auf Dauer nur, wenn alle ihren Teil der Arbeit leisten). -- mj

Statt den Kollegen etwas programmieren zu lassen, von dem man eh ausgeht, es hinterher durch eine eigene Implementierung ersetzen zu müssen, könnte man möglicherweise die Zeit besser nutzen, um mit ihm zusammen eine Lösung zu implementieren? Möglicherweise könnte man dabei sogar feststellen, dass der Kollege *so* dumm gar nicht ist, und dass jeder von jedem noch etwas lernen kann - möglicherweise... -- ip

Ich stelle fest, daß offensichtlich niemand von Euch konkrete Erfahrungen mit einem solchen Kollegen hat. Stellt Euch vor, er brauchte 34 Stunden netto, um eine einfache Schleife mit 5 Zeilen zu verstehen. Das heißt, er hatte 34 Stunden lang auf die Schleife gestarrt, bis er in der Lage war, sie einzufügen. Seine Arbeitsweise war gekennzeichnet durch Probieren, Auswendiglernen und extremes {Beispiele in Büchern anschauen}?. Oft standen Trauben von Leuten um ihn herum, um etwas zu erklären, wobei ein und dasselbe in einer Traubensitzung bis etwa 10-fach erklärt wurde. Und dann war's später oft dennoch falsch implementiert. Er wurde erst nach etwa 1.5 Jahren gekündigt, weil er ein recht netter Kollege war und weil seine jeweiligen Aufgaben an Projekten stets erheblich weniger komplex waren als die der anderen, so daß sein extremer Zeitbedarf nicht so auffiel. Und immerhin war er ja ein Kollege, der auch beschäftigt werden mußte. Sein Nachfolger begreift die ihm übergebenen Aufgaben vielleicht 100-fach schneller und benötigt maximal eine Erklärungswiederholung und implementiert dann stets richtig. Ich weiß wirklich nicht, was das (IMO dusselige) Team-Wesen hierbei helfen kann. --hs

Ich kann ja verstehen, daß Du da einen wirklich sehr begriffsstutzigen Kollegen am liebsten auf den Mond, mindestes aber aus Deinem Arbeitsbereich geschossen hättest/hast, aber warum das Team-Wesen (Du meinst damit doch den Teamgeist, oder?) deswegen dusselig ist, kann ich nicht nachvollziehen. Es gibt die ulkigsten Gründe, warum manche Menschen sich alleine schwer tun und bereits mit einem Kollegen zusammen hervorragende Ergebnisse erzielen, die beide für sich nicht hätten erzielen können. Reduktionismus, im Gegensatz zu Holismus, scheint mir hier die falsche Sichtweise auf Mitarbeiter zu sein. -- bs

Zudem: Ich sage ja gar nicht, dass es solche Kollegen, die lieber einen anderen Beruf ergriffen hätten, nicht gibt (ich habe auch einmal mit einem solchen gearbeitet - wenn es da auch nicht ganz so extrem war, wie Du schilderst). Die These des Herrn Sneed ist jedoch, dass dies die Regel ist, und die fähigen Entwickler die Ausnahme! Und das entspricht nun wirklich nicht meinen Erfahrungen. Sicher ist nicht jeder Entwickler gleich fähig - aber in einem gut funktionierenden Team, in dem man sich gegenseitig ergänzt statt miteinander zu konkurrieren, sollte das meiner Erfahrung nach kein Problem darstellen.

Daß in der Regel 75% aller Kollegen unbrauchbar sind, glaube ich auch nicht. Ich interpretiere das als absichtliche Überspitzung des Herrn Sneed.--hs

"Oft standen Trauben von Leuten um ihn herum, um etwas zu erklären, wobei ein und dasselbe in einer Traubensitzung bis etwa 10-fach erklärt wurde. Und dann war's später oft dennoch falsch implementiert." - hat sich denn nie jemand zu ihm gesetzt und ist mit ihm zusammen das Problem angegangen? -- ip

Doch, das tat man - 1.5 Jahre lang.--hs

niemand von Euch konkrete Erfahrungen doch ich hatte einen solchen Kollegen in meiner Firma ... und weist du was ? Er kann zwar nicht so schnell programmieren ist dafür aber das absolute Mathe Genie ! Das habe ich nach 4 Jahren herausgefunden als er mit einem kleinen Nebensatz eine ganze Tonne Steine von meinem Projektherzen genommen hat. Aber:

*Solche Kollegen (Faktor 100) sind IMHO die absolute Ausnahme

*Jeder Mensch kann etwas nützliches leisten, wenn er will

*Wenn ich einem Mitarbeiter nichts beibringe, kann ich keine Wunder von Ihm erwarten

Es gibt Leute die ich ohne Umschweife entlassen würde, z.B. wenn einer nichts lernen will oder wenn einer auf Kosten v. anderen lebt. Kollegen mit dem Faktor 100 gehören für mich nicht zur Entlass-Kategorie ! -- mj

...Wer kannte Harry Sneed? - Also ich kenne ihn auch jetzt noch nicht. Und habe auch keinerlei Ambitionen, das zu ändern: mit anderen Worten, bei mir ist dieser (vermutlich angestrebte) Werbe-Effekt definitiv nicht eingetreten.

Ich kenne ihn. Er war gut vor 30 Jahren. Ich arbeitete für ihn doch war ich weder in 25 noch in 75 - es war kaum Team-arbeit (ich war einfach gut). Ich löste meine Aufgabe und das war dann eingesetzt - (jedoch nicht 100prozentig bezahlt). RoGa

Eine verständliche Reaktion. Wenn die meisten so denken, dann liegt Helmut vielleicht falsch mit seiner Meinung, der Aktikel würde sich sicher positiv auf Sneeds zukünftige Beratertätigkeit auswirken. -- vgl

"Diese Seite hat allerdings mit großem Abstand beständig ...": Hat sie nicht, mittlerweile ist sie 'raus.

Wer bitte ist Herr Sneed? :-)

http://www.uni-koblenz.de/FB4/Institutes/IST/AGEbert/Teaching/SS04/SoftwareTesting/SneedCV

http://www.anecon.com

Was aber, wenn die Aussage stimmt? Dann wäre alles ja ganz einfach: Man schmeisst einfach die 75% schlechte Entwickler raus, und hat sofort eine viel produktivere Mannschaft. Selbst wenn man nur die Hälfte der Projektkosten einstreicht, hat man einen Riesengewinn gemacht. Warum bin ich da nur nicht drauf gekommen?

Bleibt die Frage: Wer hat die 75% eigentlich eingestellt? Wahrscheinlich können die meisten der Vorgesetzten auch gar nicht führen. Zu welcher Gruppe gehört Herr Sneed wohl?