In Fachbereichen klassischer Industrieunternehmen herrscht nach wie vor fast vollständiges Unverständnis darüber, wie die Werkzeuge entstehen, die sie täglich benutzen.
Es dominieren unrealistische Vorstellungen davon, wie lange Softwareentwicklung dauert und warum. Sie rufen Dir heute eine "Anforderung" zu und fragen, ob Du es nächste oder erst übernächste Woche liefern wirst..
Das führt natürlich regelmäßig zu Enttäuschungen. wenn der Releaseplan "angepasst" wird. Schwierig ist es, wenn die Stakeholder ranghöher sind, als die Projektleitung des Softwareprojektes.
Man landet dann immer schnell beim "Management der Erwartungshaltung". Und es stimmt, dass man Erwartungen der Anspruchsgruppen besser selbst lenkt, als von ihnen gelenkt zu werden. Es ist aber fast immer schwierig, dies von Anfang zu tun. Denn meistens ist man selbst neu in einer eingespielten Szenerie. Man kommt gerade aus irgendeiner Art von Bewerbungsprozess und will nicht als erstes die zugesagte Leistungsfähigkeit zurücknehmen.
Was aber helfen kann, sind Analogien. Wie lange dauert es, bis SAP eine populäre Anforderung seiner Kunden umsetzt? Wie lange dauert es, bis Apple Betriebssysteme so aktualisiert, wie es sie auf seiner Entwicklerkonferenz gezeigt hat?
Manche Stakeholder haben in ihrer Jugend oder im Studium mal selbst programmiert. Hier ein Excelmakro, dort ein Fortran- oder C-Programm. Codiert, kompiliert, von Fehlern bereinigt, neu kompiliert, fertig. Alles auf ihrem PC. Von diesen eigenen "Programmiererfahrungen" schließen sie dann darauf, wie lange so etwas bei Unternehmenssoftware "dauern kann".
Außer Acht lassen sie: die Periodisierung von Anforderungen, die Verfeinerung, die Abhängigkeitsanalysen, das Testen.
Begründet wird der Druck meist mit: "Wir brauchen das jetzt." Wenn ich sie aber vor einem Jahr nach ihren Prozessen oder Aktivitäten fragte, kam da nichts bis wenig. "Wir sind ja selbst neu, das Thema ist neu, wir müssen uns erst mal selbst finden. Aber fangt schon mal an. Wir brauchen ja nur eine editierbares Tabelle. Was wir machen ist nicht so kompliziert." Tja, und dann entstehen halt solche Außenwirkungen wie: Der Produktionsstart verzögert sich, wir wissen nicht, ob das Produkt überhaupt kommt usw.
Meine Erkenntnis ist: Es hat keinen Sinn, so zu tun, als sei es diesmal anders. Sage niemals zu, dass Du so schnell wie möglich, einen laufenden Prozess "schon bald" unterstützen kannst. Dass Sie Excel schon bald ablösen können. Sag ihnen zu, dass Du im danach folgenden Zyklus etwas liefern wirst. Nimm Dir und Deinem Team die nötige Zeit, tiefer zu verstehen, worauf sie eigentlich hinaus wollen. Gehe Top-Down vor, auch wenn sie Dir Bottom-Up oder nur Bottom anbieten. Frage nach den Topzielen, zu denen sie beitragen sollen (Was?) und den bestehenden Prozessen (Wie?). Du wirst dann die Frage beantworten "Womit?".
Obwohl Du ein "Lieferant" bist, muss Du die "Bestellungen" einfordern: Beschreibungen der Abteilungen, die Strategie, die Hauptprozesse. Welche Unternehmensziele wollen sie operativ wie erreichen? Erst dann kommt: Und wie kann IT dabei helfen?
Viele untere und mittlere Manager verstehen selbst nicht, wozu sie eigentlich beitragen sollen. Sie reichen Dir einfach das Genörgel ihrer Mitarbeiter weiter und nennen das "Anforderung". Wenn Du solche nach Prozessen fragst und als Antwort "Papierkrieg brauchen wir nicht" bekommst, weißt Du, dass der Weg bis zum ersten Sprint noch weit und steinig ist.
Wie auf einer Reise musst Du wissen, wo Du ankommen willst. Und zwischen A und B planst Du eine sinnvolle Route. Wenn man Dir das Ziel verschweigt und sagt "plane erst mal nur bis Wanne-Eickel, wir sind ja agil" muss die Warnlampe angehen.
Ferne musst Du die Systemstruktur kennen, in der Du Dich bewegen kannst. Rede mit dem oder den Architekten. Jeden Tag. Sitzt am besten im gleichen Büro und beschreibt die Whiteboards. Macht Euch alles klar.
Wenn Du das Ziel kennst und die Route, kannst Du das richtige Transportmittel auswählen.
Keine Kommentare:
Kommentar veröffentlichen