Kennt ihr dieses Kommunikationsproblem?
-
Ich versuche mal ein Problem zu beschreiben, das mir mehrmals begegnet ist.
Es gibt zwei Akteure: Der Bestimmer und der Umsetzer. Der Bestimmer erzählt dem Umsetzer, was er haben möchte. Er möchte es natürlich schnell haben. Seine Anforderungen sind oft zu schwammig, aber oft auch zu spezifisch. Der Umsetzer kann die Entscheidungen des Bestimmers oft nicht nachvollziehen. Der Umsetzer möchte den Bestimmer nicht verärgern, also widerspricht er nicht. Er hat das schon versucht, aber es bringt nichts. Da die Anforderungen oft zu ungenau sind und keine fruchtbare Diskussion möglich ist, muss der Umsetzer häufig selber entscheiden.
Der Umsetzer versucht zu erraten, was dem Bestimmer gefallen würde. Er entscheidet sich erstaunlich oft für eine besonders schlechte Variante. Bei den besseren Varianten geht er davon aus, dass sie dem Bestimmer nicht gefallen würden. Er wählt lieber etwas, das ihm selber nicht gefällt. Die schlechte Variante nimmt dann besonders viel Zeit in Anspruch, weil sie so schwachsinnig ist und oft hohen Folgeaufwand mitbringt. Am Ende wundert sich der Bestimmer darüber, dass der Umsetzer sich für so einen Unsinn entschieden hat. Das bestärkt ihn darin, dass er mit selektivem Micromanagement so etwas in Zukunft verhindern muss. Die zu spezifischen Anforderungen werden noch unsinniger. Der Umsetzer gewöhnt sich an noch schwachsinnigere Ideen vom ahnungslosen Bestimmer. Der Bestimmer vernachlässigt die schwammigen Anforderungen noch mehr und lässt damit weiter Raum für Fehlentscheidungen des Umsetzers.
So ein System hält sich also selbst am Leben. Wie hält man das auf?
-
Einfach das Problem direkt ansprechen?
-
Ja, ich kenne dieses Kommunikationsproblem.
Kann aber keine Silver-Bullet anbieten.
Was ich in der Rolle des Ausführenden/Umsetzenden auf jeden Fall nicht mehr mache, ist Sachen die ich für total beknackt halte einfach so kommentarlos umzusetzen.
Nachfragen und Klarheit schaffen ist gut. Ansonsten: Dinge so umsetzen wie man es selbst für sinnvoll hält.
Schliesslich muss man das was man da implementiert hat auch vor dem Chef verantworten. "Ich weiss dass das Scheisse ist, aber ich habe vermutet dass du so dämlich bist dass du es genau so so haben willst" kann man dann ja schwer sagen. Also drängt man sich dadurch selbst in die Situation, eine Entscheidung, die man selbst für total bescheuert hält, verteidigen zu müssen. Womit man sich im Endeffekt selbst als Deppen abstempelt. Was man dann genau genommen auch irgendwie ist.
-
Dieser Thread wurde von Moderator/in nman aus dem Forum Themen rund um die IT in das Forum Neuigkeiten aus der realen Welt verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Ich verkaufe ganze Schulungen zu diesen Thema:
Kostprobe gefällig:
Agile Management And Development – Consequences And (Dis)advantages
This means stress and personal consequences in conservative and less self-confident environments or organizations in crisis situations.
That’s why we independent contractors are often hired. We have nothing to lose when we challenge concepts, procedures, responsibilities and authorities even by superiors to clean up mess very professional and efficient in organizations – no internal career, no personal own agenda in organization, no made long term enemies etc. We do our job and move on to next contract in next company and leave a company behind made progress by a decade where some people are pleased don’t need see us any longer, but rest celebrate us as heroes two years later.
Many employees don’t understand the reason why we can and must dare disturb harmony for change. We seem to be arrogant, harsh and loud by people who are trained to follow strict chain of command and protocols, not to interfere with competences and authorities by others, risk woes of personal relationship by that and who don’t understand rigorous progressive perspective in crisis situations - not to fight just symptoms, but also roots. Therefore we are actually ultimate team players.Don‘t use progressive aspects as excuse to act like a jerk! Use your authority in crisis and stress situations short term, but explain or justify yourself always post mortem to everyone middle term. Start with your children for practice.
It’s a good sign for high profession and self confidence constantly join your political or conceptual enemies for a drink, go back to meeting room, take morning star out of cloakroom and battle for your convincement to the last and vice versa.
You must always be prepared that there some people who are not interested in project success and follow own agenda (personal career, being right about own forecast, internal intrigues, imply own concepts etc). Try first Win-Win approach and consider their objections. If not possible, accept some collateral damage and force showdown as soon as possible in crisis situations. Sometimes they are right and project is nonsense. Then try redefine your role or resign after informing clients or superiors.
**„Only the best working together with best! – Someone who is second class is just working with third class people!“
**(former Microsoft employee)
I can sign this statement thousand times and in opposite to common believe it’s much worse as independent contractor then as employee. Skills, experiences and self confidence are working hand-in-hand, produce an enhancement cascade and a lot of people never had experienced it. The main reason why this happens is lack of self confidence, conservative perspectives, fear you find some ‘bodies in cellar’, assumption you are not ground standing enough to put off your white gloves and mock in, fear your implied enlightenment will crunch concepts already established and the ‘Ego Thing’ (explained later) by people you try to convince or work with.„A new scientific truth doesn’t break through by way its opponents stand up and declared themselves be converted ,but by they got more and more extinct over time!“
(About Guerilla tactics by Max Planck 1858-1947)„In science it’s custom to say it once and you don’t repeat it before if there is something new. In politics you say it over and over again; and when you have finally gave it up, just the first one got it.”
(Chancellor Angela Merkel. She uses to be Professor of Experimental Physics.)„It seems that humiliation must always precede success !“
(own theory)
Small comfort, even Einstein must faced the ignorance after famous publications in 1905 over six years and rot in patent office in Bern (1905-1911) and if Planck hadn’t recognized him our science could be decades behind current days. Take these scares with pride, because those are highest honours a real nerd can ever get when he will succeed. The difference between stubbornness and persistence is success, but not when.
-
Sind deine Schulungen so schlecht wie das Englisch in der "Kostprobe"?
-
Das kann nur getrollt sein.
We do our job and move on to next contract in next company and leave a company behind made progress by a decade where some people are pleased don’t need see us any longer, but rest celebrate us as heroes two years later.
-
Ich bin mal fies.
Aber irgentwie erscheint mir Prof wie eine Standheizung. Viel heiße Luft um nichts.
-
TyRoXx schrieb:
So ein System hält sich also selbst am Leben. Wie hält man das auf?
So besonders ungewöhnlich ist das ja nicht, das hat jede Branche als Problem. Software ist nur anders insofern, als dass man Aenderungen leichter einbauen kann als z.B. in eine Maschine oder ein Gebäude. Entsprechende Analysen von anderen Projektdesastern (Berlin Flughafen, Hamburg Oper) zeigen aber ja deutlich, dass dieses Problem systeminhärent ist.
Typischerweise gelingt es der Ausführung auch nicht das beim Management zu plazieren, da diese Argumente leicht sehr detailbehaftet und komplex werden - das kann man in der Kommunikation nur noch schwer transportieren. Zudem hat das Mgmt noch ein anderes Problem - der Auftraggeber hat das Geld. Den muss man primär befriedigen, also auch zuhören.
Ich bevorzuge es daher in solchen Fällen die Kosten für diese Aenderungen transparent zu machen, es ist also zunächst mal wichtig, dass die Entwicklung Stunden bucht und auch vermerkt, auf welche Projekte/Module/Objekte/Function Points diese Zeiten laufen. Wenn nun diese Dinge überarbeitet werden, explodieren Kosten für diese Elemente. Und andere erscheinen nicht mehr im Projekt, weil sie benötigt wurden, die Kosten wurden zur reinen Blindleistung (Stichwort "internal project taxes").
Die Methodik von SCRUM enthält hier einige exemplarische Modelle, wie man das für Kostenerfassung bei SCRUM tun kann. Das lässt sich aber sehr gut auch allgemein im Alltag anwenden.
Vor allem darf ein entsprechender Report - wie viel Leistung ging wofür in das Projekt, und was wird davon benutzt - nicht in Stunden rechnen, sondern immer in EUR (einen entsprechenden Stundensatz kann Dir Dein Controller nennen) - damit es fühlbar wird. 200 Stunden Fehlleistung, was heisst das. 30000 EUR Fehlleistung, das ist verständlich. Man erhält damit auch Waffengleichheit mit dem Kunden, da dieser primär seinen Einfluss über Geld geltend macht, und man nun die Auswirkungen auf der gleichen Dimension darstellen kann.
Die alte Sache: erst messen, dann kontrollieren, dann minimieren.
-
Da die Anforderungen oft zu ungenau sind und keine fruchtbare Diskussion möglich ist, muss der Umsetzer häufig selber entscheiden.
Da steht doch was das Problem ist. Wieso legt der Umsetzer dann trotzdem los?
-
Cpp_Junky schrieb:
Da die Anforderungen oft zu ungenau sind und keine fruchtbare Diskussion möglich ist, muss der Umsetzer häufig selber entscheiden.
Da steht doch was das Problem ist. Wieso legt der Umsetzer dann trotzdem los?
Was ist denn bei größeren Projekten, wo ein Detail etwas ungenau ist?
Aber dann genau dieses Detail spät bei der Umsetzung sehr viel über den Haufen wirft?
-
Skym0sh0 schrieb:
Was ist denn bei größeren Projekten, wo ein Detail etwas ungenau ist?
Aber dann genau dieses Detail spät bei der Umsetzung sehr viel über den Haufen wirft?Wenn man die Software nicht so entwerfen kann, dass bestimmte "Details" später leicht änderbar sind, oder es einen signifikanten Mehraufwand bedeuten würde sie so zu entwerfen und zu implementieren, dann sollte man diese Details abklären bevor man loslegt.
