Your address will show here +12 34 56 78
Allgemein
Mit der Digitalisierung werden Aufgaben, die vorher von Menschen vorgenommen wurden, vermehrt von Maschinen erledigt. Schon in den letzten Jahrhunderten haben sich Jobs verändert oder sind ausgestorben. Die wenigsten von uns dürften noch einen Perrückenmacher, Laternenträger oder Fasszieher im Bekanntenkreis haben. Durch die Digitalisierung setzt sich diese Entwicklung fort:
  • mit der E-Mail benötigt es weniger Briefträger
  • mit Wikipedia braucht es weniger Autoren für gedruckte Enzyklopädien
  • mit Onlineportalen ist die Anzahl von Reisebüros gesunken

Aufgaben von Programmieren werden wegdigitalisiert

Selbst Programmierer sind von dieser Entwicklung nicht ausgenommen. Neue Applikationen erledigen Aufgaben, die bisher von Programmierern übernommen wurden. Drei aktuelle Beispiele:
  • Mit wandelbots Roboter programmieren
    In der Produktion gibt es bereits jetzt tausende Roboter für vielfältige Aufgaben wie Autos montieren, Metallflächen schneiden oder Teile sortieren. Diese Roboter müssen mitunter für mehrere zehntausende Euro von Spezialisten manuell programmiert werden. Ändert sich der Produktionsablauf geringfügig, braucht es Programmierer, die die Roboter erneut anpassen. Ein teures und langsames Spiel.
    Das Dresdner startup wandelbots macht damit Schluss. wandelbots hat eine Software entwickelt, mit der Nicht-Programmierer mittels ihrer Kleidung oder eines Smartphones die Roboter programmieren. Dafür macht der Mensch die Bewegung vor, die wandelbot-Software wertet die Bewegungsdaten aus und wandelt sie in Befehle um, die den Roboter neu programmieren. Das ist schneller und günstiger, als extra einen Menschen die Roboter programmieren zu lassen.
     

     
  • Mit BPMN und Camunda Abläufe innerhalb einer Applikation verändern
    Wenn sich Prozesse in einem Unternehmen ändern, müsste oftmals auch die zugehörige Software angepasst werden. Doch bei knappen IT-Ressourcen ist das nicht immer möglich. So entstehen Schattenprozesse, bei denen zu oft Excel-Listen von einem System ins andere geschubst werden. Oder es dauert Monate, bis Programmierer freie Ressourcen für eine Anpassung haben.
    Mithilfe von Software wie Camunda ist das nicht mehr nötig. Camunda überführt formalisierte Prozessabläufe in ausführbaren Code – ohne Programmierer. Wie funktioniert das? Hierfür müssen die Programmabläufe vorher im BPMN-Format formalisiert sein – die sogenannte Business Process Modelling Notation (BPMN) ist ein Standard, mit dem Prozessabläufe beschrieben werden können. Dafür bedarf es keiner Programmierkenntnisse. Die in BPMN festgehaltenen Schritte werden automatisch von Camunda in Software konvertiert. Diese kann getestet und bei erfolgreichem Tests produktiv verwendet werden. 
     

     
  • Mit Zapier mehrere Applikationen miteinander verknüpfen
    In den meisten Unternehmen kommen mehrere Systeme zum Einsatz. Oftmals sollen diese miteinander kommunizieren und Daten austauschen. Dafür gibt es Schnittstellen. Nur mit der Schnittstelle alleine ist es noch nicht getan. Damit die Applikationen tatsächlich über Schnittstellen miteinander verbunden sind, mussten früher Programmierer ans Werk gehen. Mit APIs und Programmen wie Zapier ist das nicht mehr nötig.
    Zapier verbindet verschiedene Applikationen über ihre jeweiligen Schnittstellen. Hierfür muss die zu verbindende Applikation ihre Funktionen für Zapier frei schalten. Anwender ohne Programmierkenntnisse können nun auslösende Ereignisse von einem System definieren – z.B. ein neuer Mitarbeiter wird in den Stammdaten angelegt – und Folgeschritte in anderen Systemen festlegen. Diese kleinen Bots werden immer aktiv, sobald das auslösende Ereignis sie anstößt. Programmierer, die früher die Systeme durch manuelle Programmierung verbunden haben und bei jeder Prozessänderung selbige anpassen mussten, sind somit nicht mehr nötig.
     

Diese Liste lässt sich noch weit fortsetzen: mit Chatfuel können Laien Chatbots erstellen; mit IFTTT kann das Smart Home gesteuert werden; mit Mesosphere können ITler große Cloud-Systeme einfacher automatisch steuern, auch Microsoft setzt mit Flow auf Prozessautomatisierung – alles Anwendungen, die vorher nur mit Programmierung oder durch Experten realisiert werden konnten.

Werden Programmierer ihre Jobs verlieren?

Aufgaben, die früher Programmierer übernommen haben, werden zunehmend durch Nicht-Programmierer in Verbindung mit neuartiger Software übernommen. Aber was geschieht mit diesen Programmierern? Sie haben drei Optionen:
  1. Sie geben ihren Job auf
  2. Sie können die gleiche Aufgabe in Organisationen übernehmen, die noch nicht automatisiert haben
  3. Sie übernehmen neue Aufgaben
Auch wenn in der Realität alle drei Optionen vorkommen mögen, scheint Option 1 doch die unwahrscheinlichste. Eher ist davon auszugehen, dass Option 2 und Option 3 verfolgt werden. Doch auch Option 2 ist nur temporär. Denn die Automatisierung schreitet voran und früher oder später werden auch Late Adopter ihre Prozesse automatisieren müssen um wettbewerbsfähig zu bleiben.

Die Nachfrage nach IT-Personal ist hoch und auf absehbare Zeit muss man sich wenig Sorgen um die Jobchancen selbst von veränderungsphoben Programmierern machen.

Was bedeutet das für Nicht-Programmierer?

Für Nicht-Programmierer ergeben sich neue Aufgaben und neue Kompetenzanforderungen. Mithilfe von Applikationen können Systeme nicht mehr nur konfiguriert, sondern zunehmen auch von Laien programmiert werden.
Für Mitarbeiter bedeutet das:
  • Die Möglichkeiten steigen, die eigene Arbeit zu automatisieren
  • Es entstehen neue Aufgabenfelder, die übernommen werden können
  • Wer Computational Thinking beherrscht, dem fällt es leichter, diese Möglichkeiten auch zu nutzen

Auch Organisationen profitieren wirtschaftlich von dieser Entwicklung:
  • Änderungen an Systemen können schneller umgesetzt werden
  • Änderungen an Systemen werden günstiger
  • Knappe Programmier-Ressourcen sind für neue Tätigkeiten frei

Menschen und Organisationen können diese Change für sich nutzen. Es bedeutet Veränderung und oftmals auch Weiterbildung. Wie das für Sie konkret aussieht? Seien Sie am 17. Mai beim Hello Code Camp dabei. Das Ziel ist die Vernetzung, der Austausch und das Lernen rund um die Frage: Wie kann die Organisation Digitalisierung gestalten und die Mitarbeiter beim Erwerb der nötigen Kompetenzen unterstützen?

Details: www.hello-code.camp
0

Allgemein
Kennen Sie das: Sie wollen etwas von Ihrer internen IT oder externen Dienstleister und haben das Gefühl, nicht verstanden zu werden? Oder das Ergebnis ist ein anderes als gewünscht? Oder Ihnen fallen im Prozess des Produktmanagements neue Anforderungen ein?  

Um im Produktmanagement Abstimmungsprobleme zwischen Business und IT zu minimieren, haben wir für uns das Product Requirement Canvas entwickelt. Es enthält alle wesentlichen Dimensionen, die ein Nicht-ITler realistischer Weise bereit stellen kann, um als Produktmanager bzw. Product Owner seine Anforderungen auszudrücken. Die im Canvas enthaltenen Informationen helfen Software-Entwicklern dabei, ein klareres Bild von den Erwartungen zu bekommen. Und sie sorgen für eine gründliche Auseinandersetzung mit den tatsächlichen Anforderungen. Das Product Requirement Canvas für Anforderungen im Produktmanagement Das Product Requirement Canvas kann hier als PDF-Datei herunter geladen werden.  

Die vier Dimensionen

Das Canvas teilt sich in folgende Dimensionen:
  1. Die User-Stories stehen in der Mitte. Sie beschreiben die konkreten Probleme, die vom neuen Feature oder der Software gelöst werden sollen.
  2. Die Business-Dimension beschreibt das Warum der Anforderung und die Einbettung in den Kontext der Organisation. Sie findet sich in der oberen linken Seite mit den vier Feldern Goal, Examples, Constraints und KPI.
  3. Die Technik-Dimension beschreibt im Detail, welche Ausprägungen und Nebenbedingungen die User Stories haben. Sie findet sich in der oberen rechten Seite mit den vier Feldern Data Fields, User, Test Cases und Scenarios.
  4. Die Organisations-Dimension enthält Informationen über die Art und Weise, mit der die Anforderungen umgesetzt werden sollen. Sie bildet das untere Fundament mit den vier Feldern Open Questions, Dependencies, Stakeholder und Not Doing.
 

## User Stories

Die User Stories beschreiben die Bedürfnisse der Nutzer und ihre Motivation dahinter. Dabei geht es um die Probleme der Nutzer, nicht die Lösung der Probleme. User Stories ermöglichen es den Entwicklern, in die Welt der Nutzer einzutauchen und die Software aus ihrer Brille zu sehen. Oftmals sind mehrere User Stories hilfreich, um eine Anforderung zu erfassen. Das Konzept der User-Stories ist weit verbreitet, weshalb online zahlreiche Tipps zu deren Ausformulierung zu finden sind. https://www.mountaingoatsoftware.com/agile/user-stories   Beispiel: Als Kundenservice-Mitarbeiter möchte ich bei Anfragen die Kundennummer mitgeliefert bekommen, um die Anfrage schneller bearbeiten zu können.  

## Goals

Mit jeder Umsetzung einer Anforderung soll ein übergeordnetes Ziel erreicht werden. Dies ist kein Ziel des Users sondern des Anbieters der Software. Ziele können qualitativer oder auch quantitativer Natur sein und geben den Beteiligten Sinn und Verknüpfung zu den übergeordneten Ambitionen der Organisation.   Beispiel: Wir wollen erstklassigen Kundenservice.  

## KPI

Um den Nutzen einer umgesetzten Anforderung vorab zu definieren, sollte deren Auswirkung auf vorhandene KPI definiert werden. Wird die Software mit dem neuen Feature häufiger oder länger genutzt? Können Aufgaben schneller abgearbeitet werden? Wird eine Fehlerrate gesenkt? KPI einzubinden hilft dann, wenn im Unternehmen tatsächlich KPI verwendet werden und die Wirkung des neuen Features auch messbar zugeordnet werden kann.   Beispiel: Wir können die Bearbeitungszeit von Kundenanfragen per E-Mail um 20% reduzieren, da uns eine frühe Identifikation des Kunden schnell Zugriff auf seine Kundenhistorie ermöglicht.  

## Constraints

Jede Software Entwicklung geschieht unter wirtschaftlichen Erwägungen. Bei Beauftragung von externen Dienstleister aber auch oft von internen Abteilugnen, braucht es ein Budget für die Entwicklung. Anforderungen an den Fertigstellungs-Termin der Entwicklung sollten benannt werden, sofern sie vorliegen. Der Product Owner ist festzulegen. Dabei handelt es sich um die Person, welche für die Formulierung der Anforderungen verantwortlich ist. Im Zuge dessen sind Auswirkungen auf andere Geschäftsprozesse zu benennen – vorgelagerte Schritte, nachgelagerte Aufgaben oder Datenauswertungsvorgänge.   Beispiel: Das Feature sollte vor dem Verkaufsstart von XY umgesetzt sein, da dann wieder mit mehr Service-Anfragen gerechnet wird.  

## Examples

Umsetzungsbeispiele geben den Beteiligten eine Vorstellung davon, was mit den User Stories gemeint ist. Diese Beispiele können Screenshots von anderer Software, aber auch eigene Skizzen sein. Beispiele sind mit Vorsicht zu genießen und sollten deshalb dosiert eingesetzt werden. Sie helfen bei der Konkretisierung der Anforderung, da sie – im Gegensatz zu den User Stories – das “Wie” schon ausmalen. Gleichzeitig können sie auf das Projektteam einschränkend wirken, da die Kreativität in eine bestimmte Richtung gelenkt wird und sich der Product Owner frühzeitig auf eine Lösung festlegt.   Beispiele: Screenshot eines Kontaktformulars von Firma XY  

## Data fields

Neue Anforderungen betreffen oftmals die Datenstruktur der Software. Neue Datenfelder müssen womöglich geschaffen werden, existierende Datenfelder sind betroffen oder gar nicht mehr nötig. Das Hinzufügen oder Entfernen von Datenfeldern geht oft mit deutlich höheren Aufwand einher, als die ausschließliche Verwendung bereits vorhandener Datenfelder. Hier früh eine Klarheit über die Anforderungen zu schaffen, erleichtert die Prognose des Aufwands.   Beispiele: – im Kontaktformular braucht es ein neues Feld “Kundennummer” – in diesem Feld dürfen nur Zahlen eingegeben werden – Eingaben in Feld Kundennummer werden im CRM an “Cusomter-ID” überführt  

## Test Cases

Testfälle helfen dem Entwicklungsteam die Anforderungen genauer zu verstehen und auch Sonderfälle frühzeitig zu erkennen. Mit Testfällen wird eine Anwendung sehr konkret und erlebbar. Besonders wichtig sind so genannte Edge Cases. Sie beschreiben Fälle von Eingaben, die sehr unwahrscheinlich sind oder eine extreme Ausprägung annehmen, wie z.B. alte Daten oder erwartbare Fehleingaben der Nutzer.   Beispiele:
  • Kundennummer-Systematik vor Jahr 1995
  • Kunde gibt keine Kundennummer ein
  • Kundennummer ist zu lang
 

## User

Viele Systeme arbeiten mit Usern in unterschiedlichen Rollen. So haben manche User besondere Administrations-Rechte in einem Bereich, es gibt ggf. Premium-User oder nicht registrierte User. Es sollte beschrieben werden, welche User von den Änderungen betroffen sind und wovon dies abhängt.   Beispiele: Kundennummer wird nur bei nicht eingeloggten Seitenbesuchern erfasst; bei eingeloggten Usern wird die Kundennummer bereits automatisch übermittelt  

## Scenarios

Mithilfe von Szenarien wird der Kontext, in dem die User das Feature nutzen, beleuchtet. Software kann mittlerweile von verschiedenen Geräten (z.B. PC, Tablet, Smartphone, Smartwatch) in verschiedenen Situationen (z.B. am Arbeitsplatz, auf dem Sofa, im Zug) mit unterschiedlichsten Internet-Verbindungen (z.B. im Firmennetz, im Flugzeug) verwendet werden. Das Feature sollte so entwickelt werden, dass es in den Situationen vom User optimal genutzt werden kann.   Beispiele: Kunden nutzen das Formular zuhause vom Schreibtisch, Küchentisch oder Couch via Smartphone, Tablet oder Laptop.  

## Dependencies

Anforderungen sind eingebettet in einen Kontext von wirtschaftlichen, rechtlichen oder technischen Rahmenbedingungen. Womöglich müssen Gelder noch freigegeben oder Aufträge erteilt werden, eventuell sind Schnittstellen zu anderen Systemen nötig oder in Arbeit befindlichen Funktionen Voraussetzung für die Durchführung. Diese Abhängigkeiten gilt es zu benennen. Der Datenschutz ist ebenso zu wahren. Dabei geht es insbesondere um die Fragen: Welche personenbezogenen Daten werden erfasst? Zu welchem Zweck werden diese Daten erfasst? Wer hat darauf Zugriff? Wo sind diese Daten gespeichert?   Beispiele: Änderung wird von Dienstleister umgesetzt, interner Beauftragungsprozess nimmt vier Wochen in Anspruch  

## Stakeholder

Zum richtigen Zeitpunkt die richtigen Menschen einzubeziehen erleichtert eine erfolgreiche Umsetzung. Dies kann rechtliche oder politische Unterstützung wie auch die Freigabe der nötigen Entwickler-Kapazitäten sein. Besonders hilfreich ist Feedback von tatsächlichen Nutzern, um frühzeitig ihre Bedürfnisse zu berücksichtigen.   Beispiele: Freigabe bei Datenschutzbeauftragten einholen  

## Open Questions

Nicht immer kann sofort jede Frage entschieden werden, oftmals weil Auswirkungen nicht überblickt oder Experten noch nicht einbezogen sind. Deshalb sollten diese Fragen notiert und später bearbeitet werden.   Beispiele: Sollte das Feld Kundennummer verpflichtend sein?  

## Not doing

Festzulegen, welche Funktionen nicht entwickelt werden sollen, trägt zur Klarheit und schnelleren Umsetzung bei. Weil User Stories bewusst einen breiten Lösungs-Horizont zulassen, werden mitunter Ideen entwickelt, die nicht gewollt sind. Das führt später zu Diskussionen und ggf. verlorener Arbeitszeit.   Beispiele: Vorgangsnummer soll nicht zusätzlich miterfasst werden  

Wie kann ich mit dem Canvas arbeiten?

Das Canvas hilft Produktmanagern bzw. Product Ownern bei der Klärung der eigenen Anforderungen. Es kann auch in Teambesprechungen zum Einsatz kommen, um gemeinsam die Anforderungen im Rahmen des Produktmanagements zu erarbeiten und zu diskutieren. Gut eingesetzt ist es lebendige Digitalkompetenz.   Wir bei Skill Hero haben die Felder des Canvas in eine Online-Vorlage überführt. Als Projektmanagement-Tool nutzen wir JIRA und Confluence, dort können wir Vorlagen für neue Wiki-Seiten definieren. Für neue Features haben wir eine Vorlage eingerichtet, welche die für uns relevanten Felder des Product Requirement Canvas und noch andere Angaben enthält (z.B. welche Systeme mutmaßlich betroffen sind). Auf dieser Seite werden für alle jederzeit einseh- und bearbeitbar sämtliche Informationen zusammengetragen. Die Seite ist dann Ausgangspunkt für Aufwandsschätzungen, auf ihr werden Entscheidungen des Produktmanagements dokumentiert und Anmerkungen vorgenommen. So haben wir unseren Weg gefunden, zwischen Business und IT verständlich zu sprechen.

Dieser Beitrag erschien zuerst auf http://skillhero.com/
0