Kategorien
Die Leute die sagen es kann nicht klappen, sollen denen nicht im Wege stehen, die es gerade tun!
Nachdem ich jetzt zwei Tage in einer Scrum Master Schulung saß, schreibe ich heute mal wieder selbst einen Artikel. Dabei geht es mal wieder um eine Erfahrung, die ich in den letzten Jahren Teamarbeit gemacht habe. In wieweit ihr die gleichen Dinge erlebt habt, würde mich interessieren.
Das Thema ist eigentlich ganz einfach. Jeder von uns hatte schon mal eine tolle und innovative Idee. Diesen Einfall will man natürlich gleich dem ganzen Team erzählen. Oft stößt man dann aber an eine Mentalität, die ich gar nicht mag. Nennen wir sie mal die „Das-kann-nicht-klappen“ Mentalität. Die Personen, denen man berichtet, versuchen einen zu überzeugen, dass man das neue Vorgehen gar nicht probieren braucht, weil es ja nicht klappen kann. So was wie „das wird unser Teamleiter nicht zulassen“, „der Kunde wird so nicht arbeiten“ oder „das haben wir noch nie so gemacht“ hört man da gerne.
Meine Erfahrung ist aber, dass es doch klappen kann. Teamleiter und Kunden sind meisten auch dankbar für frische Ideen. Und so konservativ wie man sie einschätzt sind sie auch nicht. Lasst euch also nicht von euren Kollegen einreden, dass ihr eine Idee nicht laut aussprechen braucht, nur weil irgendjemand glaubt, dass es nicht klappen kann. Wer nicht wagt, der nicht gewinnt.
Vielleicht denkt ihr ja mal an die Worte, wenn ihr mal wieder sagt, dass es nicht geht oder wenn euch jemand sagt, dass eure Idee nicht klappen kann. Ich habe mich zum Beispiel gestern dabei ertappt wie ich jemanden in seine Schranken weisen wollte und musste mir auf die Zunge beißen, damit ich es doch nicht tue.
Das kann nicht klappen neue, innovative Ideen den Kunden / dem Chef zu vermitteln!
Ups, sorry! 😉
Die Aussage „Das kann so nicht klappen“ höre ich öfters, gestern hatte wir sogar noch einen Fall, wo die Aussage „das haben wir noch nie so gemacht“ kam.
Ich bin in unserem Team einer der Entwickler, der gerne mal neues ausprobiert. Natürlich fällt man dabei auch mal auf die Nase und man merkt, die Kollegen hatten Recht, aber immer wieder schafft man es doch und dann sind sie plötzlich sehr interessiert an der Umsetzung und was man dadurch nun alles vereinfachen kann.
Diese Jungs musst du nicht überzeugen sondern den Chef! Viel Spaß dabei 😉
ABER: das Gegenteil ist viel schlimmer. Wenn jemand einfach etwas tut, nur weil es möglich ist. Man muss (nicht nur in einem Scrum-Team) Selbstdisziplin üben und darf nicht jede Idee umsetzen, nur weil es technisch möglich ist.
Ganz typische Sache: Kollege zeigte mir gestern seine „Lösung“ für ein Problem. Er wollte ein Bild in ein Formular einbinden. Zwischen Formulardaten und Bildern besteht eine 1:n-Beziehung – Kollege wollte aber die „Frontansicht“ (Formular ist ein Expose).
Was hat er gemacht? Er hat die Speicherroutine der Bildergalerie so verbogen, dass alle Bilder in einem bestimmten Verzeichnis landen, hat einen Compound-Primary-Key eingeführt und hat dafür gesorgt, dass alle Bilder im Dateisystem landen und die Frontansicht immer einen festen Dateinamen hat. Dann ist er – ohne über eine Datenbankabfrage zu prüfen ob das Bild existiert oder der Nutzer dafür überhaupt Rechte hat – über einen relativen, im Quellcode hart-gecodeten, Pfad im Dateisystem direkt auf die Datei gegangen. Wiederum unter Ignorieren sämtlicher Sicherheitsrichtlinien, denn dazu muss ja das Upload-Verzeichnis vom Browser aus aufrufbar sein.
Er war mächtig stolz. Ich dagegen sagte: das sei ein ganz finsterer Hack, der mehr Probleme bringt als er löst.
Deshalb bin ich strikt dagegen, Kollegen einfach „Ideen“ umsetzen zu lassen.
1. Selbstdisziplin! 2. alles absprechen. 3. korrekt einplanen! und sich im Review ordentlich durch den Wolf drehen lassen, bis die Lösung dem Stand der Technik entspricht.
Sprichst mir aus dem Herz. Nur weil einer sagt, es geht nicht, heisst das noch lange nicht, dass es so ist. Keiner kann wirklich die Zukunft vorraus sagen.
Ich habe einen ähnlichen Artikel – http://daraff.ch/2010/01/bewusstsein-schaffen-fur-neue-ideen/ – vor kurzer Zeit selbst verfasst.
Ich habe mir eine ähnliche Sichtweise angewöhnt: „Nichts ist unmöglich!“ – Ich höre mir lieber Lösungsvorschläge an und wenn diese, bereits gemachten Erfahrungen nahe kommen, sage ich das auch gerade heraus, z.B. wenn ein Problem auftritt, dass ich vor kurzem gelöst habe, dann höre/schaue ich mir erstmal den Vorschlag des Kollegen an und gebe meinen Senf dazu und dann schauen wir was dabei heraus kommt. Interessant ist es mit Kunden, die freuen sich meistens über konstruktive Vorschläge und ich hatte es bis jetzt eher selten mit Leuten zutun denen es mehr ums Geld als um eine Innovation ging.
Oh ja! Wer kennt das nicht?
Die Erfahrung habe ich in meinem letzten Unternehmen fast täglich machen müssen. Die Reaktionen kamen fast ausschließlich von alten Hasen, die sich einfach an einen bestimmten Tagesablauf und Strukturen gewöhnt haben. Neue Ideen wurden aus Prinzip nicht gutgeheißen, weil ein anderer (und dann noch ein Neuer) gar nicht wissen kann, wie man etwas besser machen kann.
Die erste Frage nach einer Featureanfrage war immer: „Geht das?“. Meine Antwort war immer: „Bis wann brauchst Du’s?“
Mein Motto: „Geht nicht gibt’s nicht!“
Ich kenne noch die 2. Antwort, die auch sehr beliebt ist: „Dafür ist keine Zeit“.
Aber in der Not erinnert sich so mancher Teamleiter und Chef auch mal an die unkonventionellen Ideen … nur so zur „Beruhigung“
Sowas kenn ich nur zu gut 😉
das fällt mir auch der Spruch von Henry Ford ein: „Wer immer tut, was er schon kann, bleibt immer das, was er schon ist.“
Die Aussage „das haben wir noch nie so gemacht“ ist nur nicht in der IT ein Armutszeugnis, meiner Meinung nach, sondern im Leben generell.
Frei nach dem Motto: Fragen kostet nichts, kann man den Kunden, sofern man ihn nicht irgendwann „nervt“ ruhig mal mit einer spannenden Idee konfrontieren. Vielleicht kommt ja auch eine Win-Win-Beziehung dabei hervor.
Das, was Du, lieber Niels, zitierst, hört man oft von „IT-Dogmatikern“, und meiner Meinung nach hat Dogmatik rein gar nichts in einer der schnelllebigsten Branchen überhaupt zu suchen.
@Tom: +1
Man sollte schon zwischen kritischem Nachfragen und Abweisung unterscheiden lernen. Ein „Geht das?“ ist nicht zwangsläufig anti und andererseits ist ein „Alles geht!“ auch Bullshit. Klar geht (fast) alles – aber oft um welchen Preis?
Etwas kritischer sollte man allerdings den allgemeinen Wachstums- und Erneuerungswahn sehen. Wie Tom sagte, nicht alles was gamcht werden kann, sollte auch gemacht werden. Die Nachteile daraus haben wir in der Technik schon oft gesehen, wo man einfach nicht daran denkt, welche Folgen oder Spätschäden neu geschaffen werden und ganze Industriezweige von den Problemen leben, die sie selbst oder andere erst neu geschaffen haben.
Und in der IT löst man schließlich auch nur größtenteils Probleme der realen Welt mit Hilfe von Software. So viele neue reale Probleme gibt es eigentlich aber gar nicht. Es sei denn, man erschafft sie zuerst durch Software, Technik oder Neues und sie dann lösen zu müssen.
Einen kritischen Geist sollte man niemals abschalten (na gut außer beim…)
Die anderen Punkte sind klar („das haben wir schon immer…“), darüber muss man sich nicht wirklich unterhalten.
Neue Ideen einbringen ist bei uns kein Problem. Allerdings scheitern wir oft aus Zeitmangel an der Umsetzung.
Was ich jedoch gar nicht mag ist, wenn neue Kollegen in der ersten Woche alle unsere eingespielten Wege in Frage stellen und alles besser und anders machen wollen. Das empfinde ich schon irgendwie als unhöflich 😉
Im Normalfall haben deine Kollegen dann das Problem noch nicht erkannt.
Du kommt mit einer Lösung nur dann durch, wenn es ein Problem gibt, das du löst.
Grad in der Software tut man sehr gut daran, Dinge nicht ohne Grund zu ändern.
Irgendwas geht immer schief… wenn man ein neues Framework ausliefert (zu wenig Plattenplatz)… eine neue Architektur einführt…
Es ist auch wirklich nicht schön, wenn man mal einen 10 Jahre alten Quellcode hat der (meist pro Gruppenleiter) nach anderen Konventionen programmiert wurde.
Ein einheitlicher Standard ist einfach zeitsparend, erleichtert das zurechtfinden, und unvorhergesehene Überraschungen werden seltener.
Und… jede Vorgehensweise hat ihre Schwächen… hat mal verschiedene Vorgehensweisen im Projekt muss man auch mit allen Schwächen zurechtkommen. (Die Fremdkomponente zickt mit dem neuen Betriebssystem, das selbstgehäkelte Teil kommt mit dem zweiten Bildschirm nicht zurecht und der Zugriff über die API klappt nur mit dem neuen Servicepack) Alles in einem Programm ist der Horror für den Support.
Also:
Erst mal das Problem identifizieren.
Und kommunizieren: Alle müssen wissen, wir haben da ein Problem.
Achtung: die Leute brauchen Zeit dafür, das zu verdauen. Du denkst schon ewig über das Problem nach… dein Kollege hatte vielleicht gar kein Problem und muss sich jetzt umstellen. Er will und soll selbst darüber nachdenken, was die beste Lösung dafür ist.
Dann die Lösung vorstellen (die tunlichst auch dieses Problem lösen sollte und nicht viele zusätzliche schaffen sollte)
Dann wird die neue Lösung noch auf Schwachstellen geprüft und dann sollte man die Leute auch überzeugen können.
Das ist dann schon aufwändig und lohnt sich also nur, wenn es wirklich eine Verbesserung bringt.
Wenn ihr Änderungen nur deshalb einführt, weil das jetzt schick und neu ist, verschwendet ihr Geld eures Arbeitgebers.