Spricht diese Liste von Verwaltungsverhalten tatsächlich Softwareentwickler an? [geschlossen]

Ich bin auf diese Liste von Managementverhalten gestoßen ( http://suven.posterous.com/dos-and-donts-leading-software-development-te ).

Ich denke, es hat einige Edelsteine, aber ich bin nicht 100% auf einige von ihnen. Ich habe diese mit Kursivschrift und meinem Namen markiert.

Denken Sie als Softwareentwickler, dass diese ansprechend sind? Welche drei wären Ihre TOP-Artikel von Ihrem Management?

Tu es nicht

Skalieren Sie Teams nicht vertikal, indem Sie mehr Personen hinzufügen
Bilden Sie kein Team mit mehr als 10 Personen
Nennen Sie keine Leute Ressourcen, es ist nicht cool und ist wirklich beleidigend
Gehen Sie nicht davon aus, dass Personen in Teams austauschbar sind
Vergleichen Sie Teams nicht miteinander, wenn Sie Schwächen hervorheben
Stellen Sie keine Teams gegeneinander auf
Erstellen Sie keine falschen Fristen
Erzwingen Sie keine teamübergreifende Standardisierung von Tools und Prozessen (ich denke, dies kann für einige Situationen argumentiert werden - Todd)
Stellen Sie keine Produktmanager ein, die keine Ahnung von Softwareentwicklung haben
Verwenden Sie KPIs nicht ausschließlich, um Ihre Teams zu steuern (dies ist nicht nur ineffektiv, sondern Entwickler finden auch Möglichkeiten, die KPI-Metriken zu steuern - "Sie möchten Codezeilen? Ich habe Ihre Codezeilen!" - Todd)
Zwingen Sie Ihre Teams nicht dazu, Überstunden zu machen, auch wenn Sie fragen, kann dies zu Spannungen führen
Gehen Sie nicht davon aus, dass das Doppelte der Menschen der Hälfte der Zeit entspricht

Tun

Skalieren Sie horizontal, indem Sie mehr Teams mit ca. 5-8 Personen erstellen
Haben Sie eine Vision für das Produkt und das Team
Schätzen Sie, dass jedes Team anders ist, und weisen Sie die Projekte entsprechend zu
Motivieren Sie Ihre Teams (Wow - das ist eine rutschige, schwer zu definierende. Ich stimme dem Gefühl zu, aber es ist, als würde man ohne Richtlinien "Effektiv sein" sagen. -Todd)
Erlauben Sie den Leuten, sich zwischen Teams zu bewegen
Besprechen Sie die Produktvision, Strategie, Technologie und den Prozess
Beziehen Sie das Team in die Bestimmung des Team- / Produktnamens ein
Erlauben Sie Ihren Teams, ihre eigenen Entscheidungen zu treffen, insbesondere wenn sie über das Fachwissen verfügen
Beziehen Sie Ihr Team in Entscheidungen ein, die sich darauf auswirken, wie oder woran sie arbeiten
Fördern Sie eine Entwicklungsmethode, die zum Team und zum Projekt passt
Achten Sie auf den persönlichen Entwicklungsplan jedes Einzelnen

management

— Todd Williamson
quelle

Ich habe wirklich ein Problem damit, das Team mit dem Produktnamen einzubeziehen. Dies ist ein Thema, zu dem jeder eine Meinung hat, aber es gibt tatsächlich Leute im Marketing (oder zumindest in anständigen Marketingabteilungen), die mehr darüber wissen als nur eine Meinung zu haben. Wenn Sie möchten, dass Ihre Fähigkeiten respektiert werden, sollten Sie auch die Fähigkeiten anderer respektieren.

— Jon Hopkins

Dies ist eine großartige Liste! Aus welchem Science-Fiction-Roman stammt das?

— Rob

Ich vermute, diese Liste spricht tatsächlich Softwareentwickler an, weil sie ihr Selbstbild als verwöhnte kreative Diven und nicht als nagelharte Problemlöser (a là Winston Wolf) bestätigt und erwartet, dass sie als Ergebnis professionell behandelt werden.

Ich vermute auch, wenn wir die Softwareentwicklungstechniken so weit verbessern würden, dass unser Beruf wie der von Architekten, Anwälten, Medizinern und dergleichen zertifizierbar wäre, könnten wir besser steuern, wie Softwareentwickler verwaltet werden.

— Huperniketes
quelle

Es scheint eine Dichotomie zwischen der Wahrnehmung der Entwickler, die sie von sich selbst haben, und den Managern zu bestehen. Ich denke, dass Sie in beiden Fällen die Entwickler als Individuen betrachten und die individuellen Unterschiede mehr erkennen müssen, als Sie umfassende Verallgemeinerungen über eine Gruppe vornehmen müssen. Ich denke, Sie haben Recht mit verbesserten Techniken, aber ich glaube nicht, dass Sie jemals eine allgemeine Zertifizierung sehen werden, die allgemein anerkannt ist. Diejenigen, die es gibt, sind herstellerbasiert oder konzentrieren sich auf eine bestimmte Art von Entwicklung.

— Todd Williamson

Stereotype oder umfassende Allgemeingültigkeiten sind Teil unserer Denkprozesse. Aus diesem Grund werden Stereotypisierungssysteme wie Berufsbezeichnungen und Zertifizierungsprogramme (z. B. Hochschulabschlüsse) verwendet. Bei der Zertifizierung einer Branche geht es jedoch nicht darum, Unterschiede zwischen Einzelpersonen zu bewältigen, sondern darum, bestimmte Produkte herzustellen.

— Huperniketes

Ich vermute, wenn es möglich wäre, Softwareentwicklungstechniken bis zu einem Punkt zu verbessern, an dem unser Handwerk zertifizierbar war (z. B. ein "bekanntes ideales" Regelwerk), wäre es auch möglich, Software zu schreiben, die Software entwickelt (unter Verwendung derselben). bekanntes ideales "Regelwerk") und unser Handwerk würde wertlos werden.

— Brendan