IT-Projekt
Phase: Anforderungsmanagement
Anforderungsquelle: Mitarbeiter
Anforderungserhebung: Geschäftsprozess-Workshops
Lektion:
Je hierarchischer die Organisation, desto mehr tendieren die Mitarbeiter dazu, ihre Tätigkeit anhand des Altsystems zu beschreiben.
Mitarbeiter: "Ich tue im System XY dies und das."
Product Owner: "Und zu welchem Zweck?"
Mitarbeiter: "Damit die Daten im System sind."
P.O.: "Ja, aber zu welchem Zweck. Und was bedeuten die Daten?"
Mitarbeiter: "Da müssen Sie den Chef fragen."
Daraus folgen Anforderungen, die sich sehr nah am Altsystem orientieren. Genauer: An dessen Design, Bedienoberfläche usw. Nicht an dem Zweck, der mit der Systembedienung erzielt werden soll. Auf diese Weise entstehen weder aussagekräftige Prozesse noch Datenmodelle.
Anders in Organisationen, in denen die Mitarbeiter nach Zielen geführt werden:
Mitarbeiter: "Ich als Kampagnenplanerin aktualisiere die xy-Daten mit den Eingaben von xy, um für die nächste Marketingkampagne aktuelle Adress- und Profildaten zur Verfügung zu haben."
Aha! Damit lässt sich schon wesentlich mehr anfangen. Hieraus kann man im weiteren Verlauf einen Prozess und ein Datenmodell ableiten.
Nebenbei: Die agile Methode nimmt Anforderungen ja in dieser Syntax auf: "Ich als ROLLE will TUN um ZWECK zu erreichen."
Diese Formulierung fällt um so leichter, je selbstverantwortlicher bzw. zielorientierter die Mitarbeiter geführt werden.
Dienstag, 30. Mai 2017
Dienstag, 2. Mai 2017
IT-Modernisierung
Wer früher (70er) gut in Mathe und Physik war, beschäftigte sich auch gerne mit Computern und Taschenrechnern. Der Zusammenhang war klar: Informationstechnik beschleunigt das Rechnen, bzw. nimmt es dem Menschen ganz ab. Der Mensch muss nur wissen oder herausfinden, was berechnet werden soll. Einige dieser Schüler wurden später Programmierer. Sie entwickelten Großrechnerprogramme, mit denen Telefonrechnungen und Rentenansprüche berechnet werden. Bis heute.
Die Programmiersprachen entwickelten sich weiter, weil Innovationen die IT-Architekturen weiter entwickelten. Wir bekamen Hochsprachen, in denen es weniger ums richtige Rechnen ging, als um eine kluge Begriffsbildung für Objekte und Methoden und um benutzerfreundliche Dialoge und Oberflächen. Man muss eher ein guter Philosoph oder Linguist sein, um auch gut mit objektorientierten Sprachen umgehen zu können.
Diese Leute versuchen heute, die Altsysteme der Großrechnerprogrammierer durch moderne Architekturen abzulösen. Und stoßen gegen Decken und Wände.
Über die Gründe kann man genug im Social Web nachlesen und hören:
- Die Altsysteme, insbesondere die Anforderungen die sie erfüllen, sind nur in den Köpfen der damaligen Programmierer "dokumentiert".
- Dokumentation, die "nur" dem Teilen von Wissen dient bzw. jemand anderen als den bisherigen Eigner zu einer Neuentwicklung zu befähigen, gilt bei den Althasen als nutzlos, oder als Risiko.
- Arbeitsteilung zwischen Auftraggeber (Fachbereich) und Auftragnehmer (IT) gab es in den 70ern nicht. Man hatte eine Abteilung, die sich vom Nachbarbüro erklären ließ, was das System können soll.
Die heutige Generation denkt komplett anders:
- Arbeitsteilung heißt für sie: jeder macht, was er oder sie am besten kann. So macht es Spaß.
- Für Arbeitsteilung muss man Wissen teilen. So kommt man als Team voran in Richtung eines gemeinsamen Zieles.
- Anwendungen müssen dem Anwender nützen, nicht den Programmierer auszeichnen.
- Kompliziertheit ist kein Hinweis auf Genie sonder auf kompliziertes Denken.
Das Problem ist: Die Altsystemprogrammierer sind die Chefs. Die Jungen werden sie in absehbarer Zeit beerben. Sie erben dann Objekt- und Sourcecode und müssen sehen wo sie bleiben. Das ist in etwa so, als würden einem die Eltern als Testament ein unleserliches Notizbuch hinterlassen.
Die Programmiersprachen entwickelten sich weiter, weil Innovationen die IT-Architekturen weiter entwickelten. Wir bekamen Hochsprachen, in denen es weniger ums richtige Rechnen ging, als um eine kluge Begriffsbildung für Objekte und Methoden und um benutzerfreundliche Dialoge und Oberflächen. Man muss eher ein guter Philosoph oder Linguist sein, um auch gut mit objektorientierten Sprachen umgehen zu können.
Diese Leute versuchen heute, die Altsysteme der Großrechnerprogrammierer durch moderne Architekturen abzulösen. Und stoßen gegen Decken und Wände.
Über die Gründe kann man genug im Social Web nachlesen und hören:
- Die Altsysteme, insbesondere die Anforderungen die sie erfüllen, sind nur in den Köpfen der damaligen Programmierer "dokumentiert".
- Dokumentation, die "nur" dem Teilen von Wissen dient bzw. jemand anderen als den bisherigen Eigner zu einer Neuentwicklung zu befähigen, gilt bei den Althasen als nutzlos, oder als Risiko.
- Arbeitsteilung zwischen Auftraggeber (Fachbereich) und Auftragnehmer (IT) gab es in den 70ern nicht. Man hatte eine Abteilung, die sich vom Nachbarbüro erklären ließ, was das System können soll.
Die heutige Generation denkt komplett anders:
- Arbeitsteilung heißt für sie: jeder macht, was er oder sie am besten kann. So macht es Spaß.
- Für Arbeitsteilung muss man Wissen teilen. So kommt man als Team voran in Richtung eines gemeinsamen Zieles.
- Anwendungen müssen dem Anwender nützen, nicht den Programmierer auszeichnen.
- Kompliziertheit ist kein Hinweis auf Genie sonder auf kompliziertes Denken.
Das Problem ist: Die Altsystemprogrammierer sind die Chefs. Die Jungen werden sie in absehbarer Zeit beerben. Sie erben dann Objekt- und Sourcecode und müssen sehen wo sie bleiben. Das ist in etwa so, als würden einem die Eltern als Testament ein unleserliches Notizbuch hinterlassen.
Abonnieren
Posts (Atom)