Zum Inhalt wechseln

Low-Code Projekte:  Aus der Sicht eines Project Managers

Technology

25 Oktober 2021 - 5 Minuten lesen

2027 Low Code Projects Blog 416X300
Objectivity Innovativer Technologieführer
Unser Spezialgebiet ist das Entwerfen, Bereitstellen und Unterstützen von IT-Lösungen, um unseren Kunden zum Erfolg zu verhelfen. Jeder unserer Schritte gehen wir innerhalb unserem ethischen Rahmen. Laut unserer Philosophie sollte jedes Kunden-Engagement zu einer Win-Win-Situation führen, unterstützend durch unsere vier Werte: Menschen, Integrität, Exzellenz und Agilität. Unsere Kunden stehen im Mittelpunkt und wir sind stolz darauf langjährige Beziehungen zu pflegen – wobei die längste bereits seit 29 Jahren hält. Unser Ziel ist es unser Geschäft weiter auszubauen und dabei den ethischen Rahmenbedingungen und Werten, auf denen wir basieren, treu zu bleiben.
Alle Beiträge von Objectivity anzeigen

1394 DE Resources Thumbs

Teilen

Inhaltsverzeichnis

  1. Uber Low-Code 
  2. Low-Code Projekte aufbauen & erfolgreich abschließen
  3. Häufige Tücken
  4. Low-Code Team Set Up & Kommunikation
  5. Kundenwahrnehmung
  6. Zusammenfassung
  7. Uber die Autoren

Uber Low-Code 

Die Low-Code Technologie wird auf dem Softwareentwicklungsmarkt immer beliebter. Gartner schätzt, dass bis 2024 die Low-Code-Entwicklung für mehr als 65% der Anwendungen verantwortlich sein wird. Laut der neuesten Prognose von Gartner, wird im Jahr 2021der weltweite Markt 13,8 Milliarden US-Dollar betragen. Das wäre ein Anstieg von 22,6% gegenüber 2020.

 Bei Objectivity liefern wir Projekte, die zwei marktführende Low-Code-Plattformen nutzen: Mendix und Power Apps. In diesem Artikel werden wir unsere Erfahrung nutzen, um die Perspektive eines Projektmanagers bei der Arbeit mit Low-Code zu diskutieren.

 Low-Code Projekte aufbauen & erfolgreich abschließen

Auf den ersten Blick scheinen Low-Code-Plattformen die perfekte Wahl für das Prototyping und die Erstellung von Proof of Concepts (PoC) zu sein. Auch wenn dies Ihr erster Eindruck ist, sind diese Plattformen auch großartige Werkzeuge, um voll funktionsfähige Lösungen zu erstellen. Die Ergebnisse werden schnell und kostengünstig erreicht und liefern dem Kunden einen handfesten Beweis dafür, ob die App-Idee funktioniert und in ein Entwicklungsprojekt übergehen wird.

Bei der Planung Ihres Projekts sollten Sie die Länge der Sprints und die Intervalle zwischen den Demos berücksichtigen. Die schnelle Bereitstellung von Low-Code bedeutet, dass neue Funktionen schnell für eine Demo bereitstehen. Daher kann es eine gute Option sein die Sprintdauer von zwei Wochen auf eine Woche zu verkürzen. Darüber hinaus reduziert die Verwendung von mehr als einer Demo innerhalb eines Sprints die Benutzer-Feedback-Schleife. Alternativ können Ad-hoc-Synchronisierungen mit dem Product Owner oder KMU-Unternehmen ein Weg sein, um sie durch neue Funktionen zu führen. Ein solcher Ansatz wird Ihnen helfen, diese von Beginn des Entwicklungsprozesses an mit einzubinden, solange sie sich mit weniger strukturierten Zeremonien wohl fühlen.

Häufige Tücken

Unsere Erfahrung zeigt, dass die Untersuchung von Problemen eine der problematischsten und zeitaufwendigsten Aktivitäten in einem Low-Code-Projekt sein kann. Nachdem man 2-3 Tage mit der Untersuchung verbracht und das Problem schließlich dem Plattformanbieter gemeldet hat, stellt sich normalerweise heraus, dass das Problem tatsächlich plattformbezogen ist. Daher ist es wichtig, im Team darauf aufmerksam zu machen, dass die Ursache eines Problems innerhalb der Plattform liegen kann. Dies im Hinterkopf zu behalten, zahlt sich aus, da solche Fälle frühzeitig erkannt werden und die Untersuchung nicht zu viel Zeit Ihrer Teammitglieder in Anspruch nimmt. 

 Low-Code Team Set Up & Kommunikation

Low-Code-Softwareerstellung bedeutet nicht immer weniger Arbeit an der Softwareentwicklung insgesamt. Es ist wichtig, die richtige Balance zwischen Teamreife, Lösungskomplexität, Anzahl der User Stories und der Geschwindigkeit, mit der diese erstellt werden, zu finden. Es ermöglicht Ihnen, den erforderlichen Detaillierungsgrad zu definieren, der für jedes Projekt von entscheidender Bedeutung ist.

Damit Entwickler schneller und ohne unnötige Hindernisse oder Blocker arbeiten können, muss der Business Analyst (BA) die Anforderungsbeschreibung so schnell wie möglich zur Verfügung stellen. Ein ausgereiftes Entwicklungsteam kann jedoch auf der Grundlage weniger formaler und allgemeiner beschriebener Anforderungen effektiv arbeiten.

Manchmal reicht ein einfaches Mock-Up, das z. B. in MIRO oder einem ähnlichen Tool (oder sogar auf Papier) erstellt wurde, um eine Anforderung umzusetzen. In vielen Fällen reichen auch Mock-Ups, die von Entwicklern direkt auf der Low-Code-Plattform als Ergebnis ihrer Gespräche mit dem BA oder sogar während solcher Gespräche erstellt werden.

Je weniger ausgereift und erfahren das Entwicklungsteam ist, desto detaillierter und genauer ist die Beschreibung erforderlich. Die Geschäftskomplexität ist ein weiterer Indikator, der die Dokumentation der Anforderungen erschweren oder vereinfachen kann.

Das schnelle Entwicklungstempo (bekannt als Rapid Development) wirkt sich auch auf die Tester aus. Sie sind fast von Beginn jedes Sprints an beschäftigt, da Funktionen dynamisch bereitgestellt werden und User Stories im Vergleich zur traditionellen Entwicklung weniger Inhalte/Anforderungen enthalten.

Aus diesem Grund besteht unser optimales Scrum-Team aus etwa 4 MX-Entwickler, 1,5 BA und 1-1,5 Tester.

Kundenwahrnehmung

Wenn unsere Kunden vor der Entscheidung stehen, welche Plattform für ihr Projekt die bessere ist: eine traditionelle oder eine Low-Code-Plattform, berücksichtigen sie in der Regel einige Faktoren. Erstens die potenziellen Kosten des Projekts und zweitens der Zeitplan, insbesondere wenn sie ein komplett neues System bestellen, mit dem sie ihre Prozesse automatisieren können.

Wir haben festgestellt, dass es keinen signifikanten Unterschied in der Wahrnehmung der Kunden gibt, die bereits Erfahrungen mit Low-Code-Plattformen gemacht haben und denjenigen, die diese zum ersten Mal verwenden. Sie erwarten oft, dass alle Funktionen „aus der Standardbox“ implementiert werden können. Sollten jedoch Anpassungsbedarfe festgestellt werden, sind diese mit zusätzlichen Kosten verbunden. Daher ist es besser, den Kunden auf ein solches Szenario vorzubereiten und ihm zu helfen, eine unangenehme Überraschung zu vermeiden.

In den meisten Fällen gibt es keine Möglichkeit, die Anpassung zu umgehen. Es kommt oft vor, dass die Verwendung von Standardkontrollen Änderungen in den Prozessen des Kunden erfordert – und das kann einfach inakzeptabel sein. Deshalb sollte das Team einen erfahrenen Product Owner (PO) beim Kunden vor Ort haben, der nicht nur die Geschäftsprozesse kennt, sondern auch die Vorteile und Grenzen von Low-Code-Plattformen versteht. Somit sollten Sie in der Lage sein, den Wert der Anpassung zu beurteilen und stark genug zu sein, um das Unternehmen davon zu überzeugen, Anpassungsideen abzulehnen, wenn sie dem Produkt nicht den erwarteten Wert bringen.

Während der Kundenverhandlungen lohnt es sich auch, die verschiedenen Arten von Verträgen hervorzuheben, die unterzeichnet werden können. Wir weisen darauf hin, dass der Kunde, wenn er einen Time & Material-Vertrag bevorzugt, mögliche Eventualitäten auf seiner Seite berücksichtigen sollte, um unangenehme Überraschungen während der Lieferphase zu vermeiden.

Zusammenfassung

 Unter Berücksichtigung aller Vor- und Nachteile von Low-Code versuchen manche zu beurteilen, ob Low-Code-Projekte einfacher oder schwieriger zu verwalten sind als die traditionellen. Wir glauben, dass es keine einfache Antwort gibt, da es zu viele Variablen beinhaltet, die das Urteil beeinflussen können. Dazu gehören die bereits erwähnte Teamreife oder die Erfahrung des Projektleiters. Aus diesem Grund ist es sehr wichtig, mit der Projektteam-Konfiguration sorgfältig umzugehen, da nicht jeder gerne in einer schnelllebigen Bereitstellungsumgebung arbeitet.

Auf der anderen Seite schätzen die Kunden die Tatsache, dass sie die Ergebnisse ihre Feedbacks schnell sehen, nach einer Demo mit diesen experimentieren und Kommentare oder Anfragen stellen können, die im nächsten Sprint berücksichtigt werden. All dies gibt dem Kunden einen echten Einfluss auf die endgültige Lösung und den Umsetzungsumfang.

Aus Sicht eines Projektmanagers geben uns solche Situationen viel Zufriedenheit und das Gefühl, dass wir die Dinge richtig und schnell erledigen und das Leben unserer Kunden einfacher machen können.

Mit einem Wort können wir sagen, dass der Low-Code-Ansatz für beide Seiten viele Möglichkeiten bietet.

Uber die Autoren

Renata Woda  

Senior Project Manager 

Renata ist eine erfahrene Projektmanagerin mit Erfahrung in Softwarehäusern und Bankinstituten.

Privat ist sie ein Fan von Outdoor-Aktivitäten, besonders wenn diese mit Reisen und Tauchen verbunden sind. 

Wojciech Paryna 

Project Manager 

Er ist ein Projektmanager mit über 8 Jahren Erfahrung, der es genießt, Teams mit einem Servant-Leader-Ansatz zu unterstützen.

In seiner Freizeit ist Wojtek als ehemaliger Spieler ein großer Handball-Fan und liebt es Kochserien von Robert Makłowicz anzusehen.

1394 DE Resources Thumbs
Objectivity Innovativer Technologieführer
Unser Spezialgebiet ist das Entwerfen, Bereitstellen und Unterstützen von IT-Lösungen, um unseren Kunden zum Erfolg zu verhelfen. Jeder unserer Schritte gehen wir innerhalb unserem ethischen Rahmen. Laut unserer Philosophie sollte jedes Kunden-Engagement zu einer Win-Win-Situation führen, unterstützend durch unsere vier Werte: Menschen, Integrität, Exzellenz und Agilität. Unsere Kunden stehen im Mittelpunkt und wir sind stolz darauf langjährige Beziehungen zu pflegen – wobei die längste bereits seit 29 Jahren hält. Unser Ziel ist es unser Geschäft weiter auszubauen und dabei den ethischen Rahmenbedingungen und Werten, auf denen wir basieren, treu zu bleiben.
Alle Beiträge von Objectivity anzeigen

Was Sie noch interesieren könnte

Kontakt

Starten Sie Ihr Projekt mit Objectivity

CTA Pattern - Contact - Middle