In dieser Episode besprechen unser Gastgeber und Experten zwei Faktoren aus dem „Standish Group Report“, die eine große Auswirkung auf den Erfolg eines Projekts haben könnten.
Unsere Gäste, Daria Polończyk und Paweł Pukocz, treffen nicht nur eine klare Aussage über Anforderungen und Benutzerbeteiligung, sondern auch über zwei sehr beliebte Projektmanagement-Methoden.
Unsere Gäste:
Daria Polończyk – Analysis & Design Manager bei Future Processing. Sie ist für die Entwicklung der Geschäftsstrategie verantwortlich und muss in diesem Rahmen hoch angesetzte Ziele erreichen und detaillierte Ziele der Abteilung definieren. Daria ist eine erfahrene Geschäftsanalystin mit großem Interesse am Softwaredesign und dem IT Servicemanagement.
Paweł Pukocz – ist Future Processings Line Manager & PMO Mitglied und spielt daher eine aktive Rolle in dem fortlaufenden Verbesserungs- und Enwicklungsprozess der Teamleiter des Unternehmens. Paweł verfügt über umfangreiche Erfahrungen in der Softwareentwicklung und der Leitung von Programmierteams, jedoch auch im Bereich des Mentoring und der Supervision.
Michał Grela ist Future Processing’s Relationship Manager, der mit der Marketingabteilung zusammenarbeitet, um Beziehungen mit potenziellen Kunden aufzubauen und das Unternehmensnetzwerk an Kontakten auszudehnen. Er glaubt stark daran, dass sich das Geschäft um den Menschen dreht und dass es letztendlich eher um die Beziehung Mensch-zu-Mensch als Geschäft-zu-Geschäft geht.
Das Transkript der Episode
Michał Grela (MG): Hallo, mein Name ist Michal Grela. Willkommen zu “Erkenntnisse der IT-Führung” von Future Processing. Ich möchte diese Episode mit einem Verweis zu einem Bericht der Normengruppe beginnen. Dieser Bericht nennt die drei wichtigsten Faktoren, die den größten Einfluss auf das Endergebnis von IT-Projekten haben, und diese Faktoren sind eine klare Darstellung der Anforderungen, Einbeziehung der Nutzer und Unterstützung der Geschäftsleitung. Aber bevor wir tiefer gehen und uns intensiver mit den Deatils befassen, möchte ich meine heutigen Gäste vorstellen, Daria und Pawel. Es ist schön, dass Sie hier sind. Bitte erzählen Sie uns etwas mehr über sich.
Daria Polończyk (DP): Danke für die Einladung. Ich leite die Analyse- und Designabteilung bei Future Processing. Es ist ein Team von äußerst kreativen Mitarbeitern und hochqualifizierten Fachleuten aus den Bereichen des benutzerorientierten Designs und der Unternehmensanalyse. Wir unterstützen unsere Kunden bei der Gestaltung ihrer digitalen Produkte, manchmal das gesamte Servicedesign. Auf der anderen Seite unterstützen wir die Projektabwicklung durch Anforderungserhebung und benutzerorientiertes Design.
Paweł Pukocz (PP): Ich arbeite für das Projektmanagementbüro bei Future Processing, wo wir unsere Projekte überwachen, kontinuierlich an Verbesserungen für unseren Lieferprozess arbeiten, sowie an der Einführung von Änderungen in unserer Organisation und unsere Projektleiter und Teamleiter weiterbilden.
MG: Danke sehr. Beginnen wir die Diskussion mit dem ersten im Bericht genannten Faktor, die klare Darstellung der Anforderungen. Was können wir tun, um die positive Wirkung dieses Faktors, dieses Elements zu maximieren? Wie können wir es nutzen, um die Effizienz des gesamten Projekts zu maximieren? Wie fangen wir an?
DP: Nun, Anforderungserhebung ist ein komplexer Prozess. Es gibt einige Maßnahmen, die man ergreifen sollte, bevor man mit der Entwicklung beginnt. Zuerst einmal sollte man ein solides Fundament für Anforderungen, detaillierte Anforderungserhebung aufbauen. Ich meine, man sollte Antworten auf wichtige Fragen geben, wie z.B.: Welchen Nutzen erwarten Sie von Ihrem Projekt? Wie werden Sie dies messen? Was sind Ihre Unternehmensziele? Sind sie klar definiert? Was sind die wichtigsten Daten, was steckt dahinter und so weiter. All dies sollte man zusammenfassen und an alle Teammitglieder weitergeben, wenn Sie möchten, dass sie sich mit der Entwicklung Ihres Produkts in die richtige Richtung bewegen, von Anfang an. Das Nächste, was wichtig ist, ist die Analyse der Interessengruppen. Sie sollten Gruppen von Personen unterscheiden, die einen Einfluss auf Ihre Produktleistung haben oder Menschen, die Ihr Produkt an sich beeinflusst haben.
PP: Ja, und diese Stakeholder-Analyse ist Teil des Projektmanagements in der allgemeinen Methodik. Und im Bericht der Normengruppe steht auch, dass der dritte Faktor die Unterstützung durch die Geschäftsleitung ist. Deshalb beziehen wir auch Interessengruppen mit ein, sowie die Stakeholder aus den Kundenorganisationen und die Personen, die Einfluss auf das Projekt haben und von diesem Projekt profitieren werden. Außerdem gibt die Stakeholder-Analyse dem Entwicklungsteam ein Gefühl in weiteren Phasen des Projekts dafür, dass sie die Interessengruppen kennen, wissen, wer welche Rolle im System spielt, wer von dem System profitiert, etc.
DP: Und auch dafür, wie man mit ihnen kommuniziert.
PP: Ja, und es ist eine wichtige Sache, die Kommunikation zu erleichtern.
DP: Aus Sicht der Anforderungserhebung, brauchen wir im Grunde genommen eine Gruppe von wichtigen Interessengruppen. Das heißt Personen, die über das richtige Wissen und die geeignete Autorität verfügen, um uns Informationen zur Anforderungserhebung zu vermitteln und die wesentlichen Entscheidungen für das Projekt zu treffen. Wenn Sie die richtigen Leute in Ihrem Projekt haben, können Sie mit der Bearbeitung von Anforderungen beginnen. Also, normalerweise beginnen wir mit einer übergeordneten Vision für Ihre Lösung und tauchen dann tiefer in die Details ein. An diesem Punkt, kann die Anforderungserhebung auf verschiedene Weise durchgeführt werden, abhängig z.B. von der Projektmethodik.
MG: Oh, ich bin froh, dass Sie das angesprochen haben. Zwei der beliebtesten Methoden: Agile im Vergleich zu Wasserfall. Wie funktionieren diese Methoden? Auf welche Weise sind sie von diesem Ansatz betroffen?
DP: Beginnend mit der Wasserfallmethodik: Sie hat ihre Nachteile, insbesondere im Hinblick auf die Reaktion zu Veränderungen im Geschäftsumfeld. Aber natürlich braucht man manchmal ein festes Budget für das Produkt. Und in solchen Situationen, müssen Sie so viele Anforderungen wie möglich ermitteln, bevor Sie mit der Entwicklung beginnen. Dazu arbeiten wir in der Regel interaktiv mit unseren wichtigsten Interessengruppen zusammen, indem wir Workshops durchführen wo wir die Details intensiver beleuchten, was in dieser Phase sehr wichtig ist, um ein gutes Verständnis unter den Teilnehmern zu haben. Um das zu erreichen, verwenden wir visuelle Methoden zur Vermittlung von Informationen, auf die sich während der Besprechung geeinigt wurde. Zum Beispiel die Ausarbeitung von Geschäftsprozessen, die Erstellung einer Anforderungskarte, die Ausarbeitung von Anwendungsfall-Diagrammen und Papier-Prototypen. Ja, wenn man über all diese Informationen verfügt, hat man einen Input für die Anforderungsspezifikation, die man dann als Anlage zum RFI verwenden kann. Und wenn die Anforderungsspezifikation nicht klar oder nicht detailliert genug ist, wird man die Ergebnisse entweder mit unnötigen Puffern zur Ankündigung erhalten oder in begrenztem Umfang, was natürlich nicht alle Ihrer Geschäftsanforderungen erfüllen wird.
PP: Und der Wasserfall, es ist sehr wichtig, diese Anforderungen bereit zu haben und von hoher Qualität gleich zu Beginn, denn basierend auf diesen Anforderungen, muss der Anbieter ein Angebot abgeben. Bessere Anforderungen führen zu einem besseren Angebot, einem genaueren Angebot, sowie besserer Planung und Terminierung des Projekts. Außerdem erwähnte Daria die Workshop-Treffen mit den anderen Interessengruppen, was ebenso zur Analyse der Interessengruppen führt, jedoch während dieser Treffen, gibt es viele Diskussionen über das gesamte Projekt. Sie können die Erkenntnisse aus diesen Treffen vom Risikomanagement bis hin zur Stakeholder-Analyse nutzen, vielleicht auch einen anderen Bereich des Projektmanagements.
MG: Das ist der Wasserfall. Aber eigentlich ist Agile der beliebteste Weg der Projektleitung. Was kann man hierzu sagen?
PP: Ja, Agile ist heutzutage eine gängige Methode, um dem Kunden einen Mehrwert zu bieten. Die beiden wichtigsten Faktoren, zwei wichtige Faktoren bei Agile sind, Änderungen zu übernehmen und zu akzeptieren. Und bei diesem Ansatz, bereitet der Businessanalyst den Backlog für den ersten Durchlauf oder zwei Durchläufe vor, sowie das Geschäftsziel, den übergeordneten Plan und das übergeordnete Geschäft, wie z.B. einen Strategieplan für das Projekt, der später vom Entwicklungsteam verwendet wird. Und während des Entwicklungszyklus, ist der Businessanalyst weiterhin im Prozess involviert und arbeitet an weiteren Anforderungen. Bei diesem Ansatz können Sie also sofort loslegen. Bereiten Sie einfach diesen Backlog für die erste Phase und die weitere Entwicklung vor.
MG: Danke. Daria, zuvor erwähnten Sie, dass ein klares Verständnis und das Sprechen der gleichen Sprache sehr wichtig ist. Wie stellen wir das sicher? Wie stellen wir sicher, dass alle die gleiche Sprache sprechen? Wie stellen wir sicher, dass alle diese Anforderungen klar definiert und umsetzbar sind?
DP: Ja, der erste Aspekt kann das Verständnis während des Workshops sein, den ich zuvor erwähnt habe, und es zu verbessern, indem möglichst viele visuelle Methoden verwendet werden. Das nächste, was aus meiner Erfahrung sehr wichtig ist, ist ein Glossar. Denn wenn wir mit verschiedenen Domains arbeiten, manchmal kann das einfache Wort definitiv…
MG: Ja, das ist wahr.
DP: …eine andere Bedeutung haben. Hinsichtlich des Verständnis der Anforderungen für Ihr Entwicklungsteam, ist es wichtig, Akzeptanzkriterien zusammen mit einer Anforderung einzubringen. Denn dank der Akzeptanzkriterien, wird Ihr Team wissen, wie Sie es überprüfen werden, wenn die Anforderung erfüllt ist. Und zu guter Letzt, würde ich sagen, ein Design der Benutzeroberfläche. Denn wenn Sie mehr CUPS Ihres Interfaces haben, können Sie auf dem direktesten Weg zeigen, was Sie vom Bereich der Kooperation mit dem Benutzer erwarten.
PP: Außerdem möchte ich die Bedeutung der Rolle des Produktinhabers im gesamten System unterstreichen. Diese Person übersetzt die Bedürfnisse des Benutzers, die Anforderungen des Kunden, die später im Entwicklungsprozess verwendet werden. Und diese Person sollte verfügbar sein. Die Verfügbarkeit dieser Person sollte hoch sein. Das muss sein. Diese Person sollte während des gesamten Entwicklungszyklus anwesend sein. Ich erinnere mich an eine Situation, in dem sich der Produktinhaber auf der Kundenseite unseres Teams engagierte. Er war jedoch nicht verfügbar genug, und das führte zu schlechten Anforderungen pro Auftragsbestand. Außerdem war es frustrierend für das Team, weil die Entwickler nicht wussten, was sie tun und in welche Richtung sie gehen sollten.
MG: Als Blocker?
PP: Ja, als Blocker. Wir schlagen dem Kunden eine Art Proxy-Produktinhaber vor. Also der Business Analyst auf unserer Seite, der der Hauptkontaktpunkt zwischen dem Team war…
MG: Das ist eine tolle Lösung.
PP: …und dem Kunden. Und es führt schließlich zu den besseren Anforderungen und einem Backlog voller guter Qualitätsprodukte. So kehrte die Entwicklung schnell zur bisherigen Kapazität zurück.
MG: Kommen wir nun zum zweiten Faktor aus dem Bericht, die Einbeziehung der Nutzer. Letztendlich will man heutzutage eine Lösung, die brauchbar ist und mit der sich die Menschen gerne beschäftigen und interagieren. Und das ist heutzutage das wesentliche Ziel der Stakeholder. Wie stellen wir sicher, dass dies abgedeckt ist?
DP: Ich würde sagen, je mehr Ihr Projekterfolg von der Benutzerfreundlichkeit und Attraktivität für zukünftige Nutzer abhängt, umso wichtiger ist es, sie während des Prozesses einzubeziehen. Hierzu sollten Sie Schlüsselgruppen Ihrer zukünftigen Benutzer definieren und ihre Bedürfnisse und Schwierigkeiten erforschen sowie ihre Erwartungen an das System um dann mit der Konstruktion auf dem System für sie überzugehen, gemäß der benutzerzentrierten Entwurfsmethodik und natürlich den Geschäftsanforderungen entsprechend. Wir hatten das Vergnügen, die Lösung für die Schwerindustrie vor einigen Monaten zu entwerfen. Eines der Hauptziele dieses Projekts war es, eine Optimierung der Geschäftsprozesse zu erreichen und zugleich die Kosten für Anwenderschulungen zu senken. Nachdem wir die Benutzergruppen definiert hatten, entschieden wir uns, herauszufinden, wie sie im Alltag arbeiten. Sie arbeiteten unter schlechten Lichtverhältnissen mit Handschuhen und schweren Werkzeugen und die Software sollte für Tablets entwickelt werden. Deshalb war es extrem wichtig, die beste Verwendungsmöglichkeit der Lösung zu gewährleisten. Im Rückblick kann ich sagen, wenn wir nicht ihre wahren Schwierigkeiten in ihrem Arbeitsumfeld erlebt hätten, hätten wir keine Chance gehabt, eine Lösung zu entwerfen, die sie wirklich unterstützen würde.
MG: Das ist wahr, und es klingt nach Mehrwert, aber es klingt auch nach zusätzlichen Kosten, nach zusätzlichem Aufwand, zusätzliche Investitionen zu Beginn dieses Unterfangens. Ist es das wert?
PP: Das ist es. Ich würde vielmehr sagen, dass dieser zusätzliche Aufwand eine Investition ist. Da man Zeit mit dem Klienten verbringt, mit den Stakeholdern, besprechen wir den Projektumfang, und so kristallieren sich einige Risiken und Chancen für das Projekt heraus, was noch vor der Projektdurchführung geschieht. Je später wir erforderliche Änderungen im Projekt entdecken, desto teurer werden diese Änderungen. Also ja, es lohnt sich, auf diese Art zu verfahren. Ich empfehle, dass dieser Teil nicht ausgelassen wird, und ich würde die Lösung empfehlen.
MG: Obwohl es großartig klingt, scheint es für größere Projekte den meisten Sinn zu machen. Aber was ist mit kleinen Investitionen, für die man das Konzept einer bestimmten Idee schnell überprüfen möchte? Wie würden Sie das angehen?
DP: Bei derartigen Herausforderungen und Projekten wo am Anfang ein kleineres Budget vorhanden ist, empfehlen wir die Durchführung eines kleinen Workshops, wo man einfach die übergeordnete Vision für die zukünftige Lösung entdeckt und das MVP definiert, das für ein minimal tragfähiges Produkt steht, was eine Kernfunktionalität für die zukünftige Lösung ist. Und dieser Workshop beschäftigt sich intensiv mit Anforderungen nur im Bereich dieses MVPs. Es ist interessant, dass Sie kein Entwicklungsteam involvieren müssen, um einen Konzeptnachweis zu erstellen. Denn wenn Sie User Experience-Designer in Ihrem Team haben, können Sie einen anklickbaren Prototyp vorbereiten, interaktiv, der Ihnen einen Eindruck und das Gefühl für eine zukünftige Lösung vermittelt. Sie können ihn dazu verwenden, um Feedback von Ihren Investoren und vom Markt zu erhalten.
MG: Okay, aber was kann schief gehen? Was sind die Risiken?
DP: Nun, eine der größten Bedrohungen, ist z.B., wenn ein wichtiger Stakeholder nicht miteinbezogen wird. Sie könnten jemanden übersehen, der in Ihr Team aufgenommen werden sollte. Was noch? Nun, die Anforderungen: Sie sollten nicht verschlossen und nur in Dokumenten aufbewahrt werden. Sie sollten über sie sprechen und sie entwickeln, wenn Sie ein gutes Verständnis für das gesamte Projekt haben wollen.
MG: Okay und was sind die Vorteile?
PP: Die Vorteile für Sie liegen in klaren und verständlichen Anforderungen. Sie erhalten einige Erkenntnisse für das weitere Projektmanagement wie Risikomanagement, Stakeholderanalyse. Sie könnten zudem einen genaueren Plan haben und über bessere Zeitplanung verfügen. Wenn Sie den Anbieter fragen, sollte er in der Lage sein, genauere Details zum Projekt, den Workshops, den Treffen zu liefern. Die gemeinsam verbrachte Zeit schafft eine positive Haltung und Loyalität der Stakeholder. Sie fühlen sich wichtig, weil man sie um ihre Meinung bittet. Später erleichtert es die Kommunikation mit ihnen, mit dem Entwicklungsteam.
MG: Und dieses Gefühl, an dieser Sache gemeinsam zu arbeiten.
PP: Ja, Ja.
MG: Was ist Ihr bester Ratschlag für diejenigen, die diesen Ansatz in Betracht ziehen?
DP: Wenn Sie die Durchführung eines IT-Projekts in Betracht ziehen und Sie ein Unternehmen brauchen, das es entwickelt und für Sie ausliefert, sollten Sie nach einem Unternehmen suchen, das Ihr IT-Partner wird, nicht nur Ihr Lieferant. Ich meine hiermit eine Organisation, die sich um den Geschäftswert kümmert, den Sie sich von dieser Lösung versprechen. Wenn ich einen solchen Partner habe, auch Sie können ihn haben, haben Sie ebenso einen Berater im Bezug auf Technologie und die Erreichung Ihrer Unternehmensziele.
PP: Mein Ratschlag ist, wenn Sie sich für diesen Ansatz entscheiden, behandeln Sie diese Phase nicht nur als Input für die Spezifikation. Nutzen Sie all diese Workshops, diese Treffen und andere Aktivitäten, um Einblicke zu erhalten, als Input für das weitere Projektmanagement.
MG: Man kann also sagen, dass eine bessere Berücksichtigung der Anforderungen zu einem besseren Verständnis dieser Anforderungen führt, und das bedeutet dann eine effizientere Zusammenarbeit im Team und gleichzeitig geringere Kosten und weniger Nacharbeit.
DP: Ja, natürlich.
MG: Wunderbar, es war ein sehr aufschlussreiches Gespräch. Vielen Dank, dass Sie sich uns heute angeschlossen haben.
PP: Vielen Dank.
DP: Vielen Dank.
MG: Und vielen Dank an unsere Zuschauer, dass sie sich diese Episode “Erkenntnisse in der IT-Führung” angesehen haben. Wenn Sie diese als hilfreich erachten, zögern Sie bitte nicht, dies in Ihrem sozialen Netzwerk zu veröffentlichen, und bitte senden Sie uns eine Nachricht, falls Sie ein Thema in einer der nächsten Episoden behandelt haben möchten. Das war “Erkenntnisse in der IT-Führung” von Future Processing. Vielen Dank.