{"id":85,"date":"2015-02-11T20:20:14","date_gmt":"2015-02-11T20:20:14","guid":{"rendered":"http:\/\/techblog.auchmonoabspielbar.de\/?p=85"},"modified":"2015-02-11T20:20:14","modified_gmt":"2015-02-11T20:20:14","slug":"management-mythen","status":"publish","type":"post","link":"http:\/\/techblog.auchmonoabspielbar.de\/?p=85","title":{"rendered":"Management Mythen"},"content":{"rendered":"

Heute bin ich durch Zufall \u00fcber einen \u00e4lteren Blog Beitrag von Steven Sinofsky<\/a> gestolpert: „Management Clich\u00e9s That\u00a0Work<\/a>„. Da er auf diesem Gebiet als (ehemaliger) verantwortlicher Manager f\u00fcr Windows und Office viel Erfahrung haben sollte, habe ich den Beitrag nat\u00fcrlich gelesen. Ein paar Punkte daraus m\u00f6chte ich hier aufgreifen.<\/p>\n

Sinnvollerweise liest man erst den Beitrag von Steven Sinofsky. Anschlie\u00dfend geht es hier weiter…<\/p>\n

Promise and deliver<\/b>: F\u00fcr den Teamleiter ist es wichtig, dass die Entwickler realistische Sch\u00e4tzungen abgeben. Deshalb bin ich genauso wie er der Meinung, dass die Masche \u201cunder promise and over deliver\u201d (weniger zusagen als man leisten kann und am Ende des Projekts deshalb mehr abliefern als gefordert wurde) schlecht ist. Seine Begr\u00fcndung finde ich nur unzureichend. Das Problem bei dieser Vorgehensweise liegt f\u00fcr den Manager darin, dass er nur schlecht planen kann. Das Problem f\u00fcr den Entwickler wiegt noch schwerer: \u00fcber fast die gesamte Projektlaufzeit wird er als wenig leistungsf\u00e4higer Mitarbeiter eingestuft. Die Erleichertung am Ende – „er hat ja doch einiges abgeliefert“ macht meiner Meinung nach die \u00fcber l\u00e4ngere Zeit aufgebaute Meinung nicht wett.<\/p>\n

Richtig ist es (meiner Meinung nach), eine m\u00f6glichst realistische Sch\u00e4tzung \u00fcber die erreichbaren Ziele abzugeben. Gemeinsam mit einer Risikoabsch\u00e4tzung, was mindestens erreicht werden kann. Es ist die Aufgabe des Managers, sich Gedanken dar\u00fcber zu machen, welche Zahlen nach au\u00dfen kommuniziert werden. Dazu muss er aber m\u00f6glichst realistische Zahlen haben. Wenn der Entwickler sich durch \u00fcberm\u00e4\u00dfig hohe Sicherheitszuschl\u00e4ge vor Entt\u00e4uschungen sch\u00fctzen will, ist das unaufrichtig gegen\u00fcber der Firma und dem Team.<\/p>\n

Diese Forderung funktioniert nat\u00fcrlich nur dann, wenn der Manager im Falle unerwarteter Probleme und nicht erreichter Ziele seine Verantwortung nicht einfach auf den Entwickler abschiebt. Er hatte die Zahlen und kannte die Risiken. Wenn er das nicht passend nach au\u00dfen kommuniziert, muss er daf\u00fcr auch selber die Verantwortung \u00fcbernehmen.<\/p>\n

Make sure bad news travels fast<\/b>: dieser Punkt geht Hand in Hand mit dem bereits gesagten. Wenn die Sch\u00e4tzung aufgrund unerwarteter Gr\u00fcnde nicht aufgeht, dann muss man es auch so fr\u00fch wie m\u00f6glich kommunizieren. Nur dann hat der Manager die M\u00f6glichkeit Ver\u00e4nderungen vorzunehmen. Im schlimmsten Fall, dass der Releasetermin fr\u00fchzeitig verschoben wird.<\/p>\n

F\u00fcr den Entwickler ist es hier wichtig, dass er sich nicht selber bel\u00fcgt. Der lustig gemeinte Satz „ein Softwareprojekt ist \u00fcber 80% der Laufzeit fast fertig“ hat einen ernsten Hintergrund. Wenn ich nicht erkennen will, dass ich mit meinen Terminen im Verzug bin, kann ich es auch nicht weiterleiten. Mittelfristig ist so etwas f\u00fcr einen Entwickler ein ernsthaftes Karrierehindernis – er wird von seinem Manager st\u00e4ndig als Projektrisiko angesehen. Und dieses negative Gef\u00fchl \u00fcberdeckt einen Teil der Leistungen.<\/p>\n

Writing is thinking<\/b>: es ist meiner Meinung nach offensichtlich, dass man beim Niederschreiben von Gedanken und Pl\u00e4nen gezwungen ist, tiefer \u00fcber ein Problem nachzudenken. Wenn man einen Plan nur „im Kopf“ hat, kann man sich leichter selber beschummeln und offensichtliche L\u00fccken leichter \u00fcbersehen. Sobald man es schreibt, bekommt es eine andere Qualit\u00e4t. Damit ist nicht gemeint, dass man st\u00e4ndig umfangreiche Reports schreibt und nicht mehr zum Arbeiten kommt. Einfach in ein paar S\u00e4tzen die wichtigen Punkte aufschreiben und bei Bedarf noch ein paar Handskizzen reichen oft schon aus.<\/p>\n

Noch besser ist es, wenn man es jemand anderen erkl\u00e4rt. Wenn ich es nicht erkl\u00e4ren kann, habe ich es auch nicht verstanden. Damit ich es erkl\u00e4ren kann, muss ich besser dar\u00fcber nachdenken. Ich glaube, dass ein Teil des Erfolgs von Teamarbeit darin liegt, dass man seine Gedanken st\u00e4ndig erkl\u00e4ren muss.<\/p>\n

Practice transparency within your team<\/b>: ein Softwareentwickler ist kein Einzelk\u00e4mpfer in einer dunklen H\u00f6hle. Er ist ein Teamplayer – andere sind auf ihn angewiesen und er ist auf andere angewiesen. Und schon eine einzige Primadonna kann ein ganzes Team zerst\u00f6ren.<\/p>\n

Don\u2019t ask for information or reports unless they help those you ask to do their jobs<\/b>: eine wichtige Aufgabe des Manager liegt darin, daf\u00fcr zu sorgen, dass sein Team m\u00f6glichst gute Arbeitsm\u00f6glichkeiten hat und somit die maximale Leistung bringen kann. Das ist keine reine Menschenfreundlichkeit sondern auch ganz egoistischer Selbstzweck. Ein egozentrischer Manager, der seine Eitelkeiten bedingungslos \u00fcber sein gesamtes Team stellt, ist ein unf\u00e4higer Manager und geh\u00f6rt ausgetauscht.<\/p>\n

Don\u2019t keep two sets of books<\/b>: den Vorgesetzten \u00fcber den Projektfortschritt zu t\u00e4uschen ist ein Verhalten, welches fast zwangsl\u00e4ufig zu Problemen f\u00fchrt. Ich glaube nicht, dass man das noch weiter erl\u00e4utern muss.<\/p>\n

Never vote on anything:<\/b> hier bin ich abweichender Meinung. Vielleicht ist seine Einstellung auch der amerikanischen Eigenart geschuldet, dass man ein offenes Nein vermeiden sollte weil es unh\u00f6flich ist. Es gibt nun mal Situationen in denen alle Argumente ausgetauscht wurden, jeder hat die Position der anderen verstanden und trotzdem kommt man zu unterschiedlichen Ansichten. Hier kann es schon sinnvoll sein, einfach mal abzustimmen. Die Mehrheit hat nicht immer recht – aber wenn viele kluge Leute anderer Ansicht sind als ich es bin, dann ist es ein Grund, die eigene Position nochmal ernsthaft zu \u00fcberdenken. Am Ende muss der Leiter entscheiden – er muss es schlie\u00dflich auch verantworten.<\/p>\n

When presenting the boss with n<\/i> alternatives he\/she will always choose option<\/b> n+1<\/strong>:<\/i> Autsch – das geht gegen die „pointy haired bosses<\/a>„. Wenn der Vorgesetzte nicht in der Lage ist, die M\u00f6glichkeiten zu beurteilen, ist das eine Nothilfe. Ein normaler Manager m\u00f6chte hier lieber eine ehrliche Liste der M\u00f6glichkeiten und Risiken haben. Niemand m\u00f6chte gerne manipuliert werden, die Entwickler nicht – und die Manager auch nicht.<\/p>\n

Products don\u2019t ship with a list of features you thought you\u2019d do but didn\u2019t:<\/b> wenn ein Feature so unwichtig ist, dass es st\u00e4ndig von anderen (neueren) wichtigen Features verdr\u00e4ngt wird, dann sollte man auch konsequent sein und es streichen. Sonst kommt man irgendwann in die Verlegenheit, dass man an unwichtigen Dingen arbeitet, „weil sie schon so lange da liegen“ – statt an den wichtigen Themen zu arbeiten. Es ist auch ehrlicher gegen\u00fcber dem Stakeholder dieses Features – lieber ein Ende mit Schrecken als ein Schrecken ohne Ende. Die Ausnahme hier: wenn es dem Einreicher mehr um pers\u00f6nliche Eitelkeiten als um das Produkt geht, kann es „humaner“ sein, den Featurewunsch in einer dunklen Ecken verschimmeln zu lassen als einen Grabenkrieg zu f\u00fchren.<\/p>\n

 <\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Heute bin ich durch Zufall \u00fcber einen \u00e4lteren Blog Beitrag von Steven Sinofsky gestolpert: „Management Clich\u00e9s That\u00a0Work„. Da er auf diesem Gebiet als (ehemaliger) verantwortlicher Manager f\u00fcr Windows und Office viel Erfahrung haben sollte, habe ich den Beitrag nat\u00fcrlich gelesen. Ein paar Punkte daraus m\u00f6chte ich hier aufgreifen. Sinnvollerweise liest man erst den Beitrag von […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-85","post","type-post","status-publish","format-standard","hentry","category-menschen"],"_links":{"self":[{"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=\/wp\/v2\/posts\/85","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=85"}],"version-history":[{"count":1,"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=\/wp\/v2\/posts\/85\/revisions"}],"predecessor-version":[{"id":86,"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=\/wp\/v2\/posts\/85\/revisions\/86"}],"wp:attachment":[{"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=85"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=85"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/techblog.auchmonoabspielbar.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=85"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}