Samstag, 31. Oktober 2020

Kommentierte Links (LXVII)

Bild: Unsplash / Dayne Topkin - Lizenz
  • Jez Humble: OK, apparently this still needs saying

    Es gibt ja für alles ein erstes Mal, so auch hier: erstmalig verlinke ich in den kommentierten Links nicht zu einem Artikel sondern zu einem Twitter-Thread. Was Jez Humble hier schon leicht genervt ankündigt ist eine in acht Teilen ausgeführte Widerlegung des verbreiteten Vorurteils, dass DevOps und agile Produktentwicklung nicht mit staatlichen Regulierungen wie PCI DSS, FISMA und SOX vereinbar wären. Twitter-typisch sind die im Text selbst enthaltenen Informationen eher komprimiert, der wahre Mehrwert ergibt sich aus verschiedenen weiterführenden Fallstudien und Artikeln die im Thread verlinkt sind. Ein eher trockenes Thema aber ein wichtiges für jeden der im Geltungsbereich dieser und ähnlicher Vorschriften agil arbeiten will.

  • Barry O'Reilly: Systemic Effects - the Overlooked Key to Effective Strategic Planning

    Ein weiterer Beweis dafür, dass einem die neu zu lernenden Themen nie ausgehen werden. Seit 1971 gibt es die Futures Wheel-Methode, mit der man direkte und indirekte Konsequenzen von Entscheidungs- und Umgebungsfaktoren visualisieren kann - und erst jetzt erfahre ich davon, durch diesen Artikel von Barry O'Reilly. Letzten Endes ein mit der Mind Map verwandtes Konzept, mit dem grossen Unterschied, dass die Themen sich nach aussen nicht nur weiter ausdetaillieren sondern sich dort auch gegenseitig beeinflussen und voneinander abhängen können. Vom ersten Eindruck her würde ich sagen, dass verschiedene Einsatzgebiete möglich sind, z.B. neben der von O'Reilly genannten nichtlinearen strategischen Planung auch Ist-Analysen. Spannend.

  • András Juhász: Technical Debt Is Overhyped. Let’s Talk about Product Debt

    Mir fällt gerade auf, dass ich eigentlich schon seit Jahren etwas zum Thema technische Schulden schreiben will aber nie dazu gekommen bin. [Edit: mittlerweile doch] Dann eben zuerst zu den "Produkt-Schulden". Laut András Juhász sind das voreilig eingebaute (oder nach Erkennung nicht entfernte) Features die nicht (mehr) zur Produktvision passen - was nochmal unterstreicht, dass man natürlich eine haben sollte. Eine ähnliche Definition kommt von Luke Gallimore: auch für ihn entstehen Produkt-Schulden durch die fehlende Ausrichtung auf ein übergeordnetes Ziel (statt Produktvision spricht er von Produktstrategie), er fügt aber noch eine weitere Dimension hinzu - auch die fehlende Validierung von Annahmen über die Akzeptanz und Nutzung neuer Features führt für ihn zu Produkt-Schulden. Beides sehr bedenkenswerte Überlegungen.

  • Ron Jeffries: Working Software

    Das hier ist sehr Oldschool. Ron Jeffries, einer der Verfasser des Manifests für agile Softwareentwicklung, geht auf einen von dessen zentralen Sätzen ein: "Working software is the primary measure of progress." Nach einem kurzen Exkurs zur Frage was eigentlich "working Software" ist (Antwort: es kommt darauf an) liefert er eine sehr schön differenzierte Antwort warum sie das Hauptkriterium für Fortschrittsmessungen sein sollte, und zwar sowohl für einzelne Entwickler, als auch für Entwicklungsteams, als auch für Manager. Ein Artikel den man ausdrucken und in vielen Entwicklungsabteilungen dieser Welt an die Wand hängen sollte.

  • Ken Schwaber: SCRUM Development Process

    Apropos Oldschool. Vor fast genau 25 Jahren (also sogar deutlich vor dem Manifest für agile Softwareentwicklung) stellten Jeff Sutherland und Ken Schwaber auf der OOPSLA-Konferenz ihre Version von Scrum vor, und obwohl es damals bereits noch ältere gab hat sich ihre durchgesetzt und nach langer Evolution zu dem entwickelt was wir heute unter diesem Namen kennen. Das bedeutet, dass heute Software-Entwicker nach Scrum arbeiten die noch nicht geboren gewesen sind als dieses Paper veröffentlicht wurde. Um so bemerkenswerter, dass dieses Framework in manchen Firmen noch immer als neumodisch gilt.

Mittwoch, 28. Oktober 2020

Die Testautomatisierungs-Falle (und wie man ihr entkommt)

Bild: Flickr / Karen Rustad Tölva - CC BY 2.0

In den Diskussionen um Psychologische Sicherheit, Kultur, "Agile Mindset" und Change Management geht es manchmal unter, aber zumindest im IT-Kontext hat Agilität auch immer eine sehr technische Seite, ohne die schnelle Reaktions- und Lieferfähigkeit weder denkbar noch umsetzbar ist. Einer der wichtigsten Aspekte ist dabei die Automatisierung der Software-Tests, also der Qualitätssicherung der neu erstellten Funktionalitäten. Und wie so oft gilt auch hier - es reicht nicht es zu machen, man muss es auch richtig machen.


Zur Erinnerung: während die Abnahme-Tests im Sprint noch irgendwie mit manueller Arbeit zu stemmen sein können ist das bei den Regressionstests nicht mehr der Fall. Unter denen versteht man das regelmässige Überprüfen aller (!) älteren Funktionen, womit sichergestellt wird, dass diese nicht versehentlich durch neuere Entwicklungen beschädigt wurden. Bei grösseren IT-Systemen kann das eine fünfstellige Anzahl an Tests erfordern, was bei manuellem Durchklicken Wochen und Monate dauern kann.


Die einzige Lösung wenn man schnell sein will ist das Automatisieren möglichst aller Regressionstests. Erst wenn diese von einem Computerprogramm ausführbar sind können die erforderlichen Mengen und Geschwindigkeiten erreicht werden die nötig sind um Fehler schnell entdecken und beheben zu können. Ohne Testautomatisierung kommen bei grösseren Systemen die Jahres- und Quartals-Releases zurück. Aber (Ironie der Geschichte): auch eine falsch durchgeführte Testautomatisierung kann den selben Effekt haben.


Um aussagekräftig zu sein müssen die automatisierten Testsuiten immer dem aktuellen Stand der jeweiligen Anwendungsentwicklung entsprechen, sonst geben sie Fehlermeldungen aus sobald ein Feature verändert wurde, die Aktualisierung der Tests aber noch nicht stattgefunden hat. Das Risiko ist schnell erkennbar: wenn bei grösseren Änderungen hunderte von Tests aktualisiert werden müssen kann das einen Pflegeaufwand bedeuten, der wieder Wochen und Monate dauert - damit ist man wieder bei den Zeiträumen die man vorher hatte.


Um diesem Phänomen (der so genannten "Testautomatisierungs-Falle") zu entgehen müssen Erstellung und Struktur der automatisierten Tests an die agilen Entwicklungsprozesse angepasst werden. Wie das im Einzelfall aussieht kann von Fall zu Fall anders aussehen, folgende Grundsätze sind aber sehr häufig: Zusammenlegung von Test- und Entwicklungsteam, Modularisierung und Parametrisierung.


Die Zusammenlegung von Test- und Entwicklungsteam ist die einfachste, weil eher organisatorische Massnahme. Statt zwischen Entwicklung und Test einen kleinen Wasserfall aufzubauen werden die Tests jetzt gleich vom Entwicklungsteam erstellt, wodurch sie schneller fertig und aktueller sind. Ein unterschätzer Nebeneffekt kommt dazu: die "Tester" können in diesem Vorgehen selbst programmieren, was die Voraussetzung für Automatisierung ist.


Die Modularisierung sorgt dafür, dass der Instandhaltungsaufwand sinkt. Wenn z.B. nicht mehr in jedem von 100 Tests die Login-Schritte separat ausgeführt werden, sondern diese Schritte nur noch aus einem einzigen zentral gepflegten Modul abgerufen werden, muss ein geänderter Login-Vorgang nur noch einmal geändert werden statt 100 mal. Der Instandhaltungsaufwand sinkt damit auf 1% seines Umfangs (!).


Ähnliche Auswirkungen hat eine Parametrisierung. Bei ihr werden veränderbare Variablen (Testumgebungen, Browser, Testdaten, etc.) nicht mehr hart in den Test gecodet sondern ebenfalls zentral gepflegt. Bei der Test-Suite einer Web-Anwendung reicht es dann eine einzige zentrale Einstellung zu ändern und hunderte Tests laufen auf Firefox statt auf Chrome. Auch hier sinkt der Instandhaltungsaufwand immens.


Es ist offensichtlich, dass (und warum) die Testautomatisierungs-Falle und die dazugehörenden Gegenmassnahmen von zentraler Bedeutung für agile Software-Entwicklung sind. Und ganz nebenbei ergibt sich aus ihnen übrigens auch ein brauchbarer Lackmustest für Agile Coaches und Scrum Master. Die müssen nicht selbst Tests automatisieren können, sie sollten die Testautomatisierungs-Falle aber beschreiben können. Wenn das nicht geht sind sie (noch) zu technikfern.

Montag, 26. Oktober 2020

Der Product Owner als Key Account Manager

Bild: Pexels / Christina Morillo - Lizenz

Eine der zentralen Vorraussetzungen von agiler Produktentwicklung ist die Etablierung von so genannter Product Ownership. Um für den eigenen Fortschritt nicht auf andere angewiesen zu sein wird eine möglichst starke Focussierung angestrebt. Ein einziges crossfunktionales Team exklusiv für ein Produkt, mit allen Berechtigungen es verändern und modifizieren zu dürfen. Nur so ist das schnelle Inspect & Adapt möglich, das den Kern aller agilen Vorgehensweisen bildet.


Der de facto Standard dieser Umsetzungen ist mittlerweile Scrum, das in seinen Teams sogar eine explizite Rolle für Product Ownership hat, sinnigerweise Product Owner genannt. Richtig umgesetzt ist der nicht nur ein einfacher Business Analyst oder Anforderungsmanager sondern er entwickelt sein Produkt langfristig und strategisch weiter, hat den Überblick über vergangene Entscheidungen und hält Kontakt zu dessen Anwendern und Stakeholdern.


Soweit die Theorie. In den meisten Fällen ist sie anwendbar, in einigen allerdings nicht. Im Agentur-Umfeld kommt es beispielsweise vor, dass Teams für einzelne Sprints an Kunden verkauft werden um an dessen Systemen zu arbeiten, in Konzernen kann es sein, dass die Zuordnung eines Teams zu einem Produkt nur so lange anhält wie die dahinterstehende Fachabteilung Projektbudget hat. In diesen und vergleichbaren Fällen springen Teams und Product Owner regelmässig von Produkt zu Produkt.


Um die negativen Effekte dieser ständigen Wechsel zumindest in Grenzen zu halten findet man in manchen Unternehmen eine Ausgestaltung der Product Owner-Rolle die in Teilen einem Key Account Manager entspricht, also dem Hauptbetreuer eines wichtigen Kunden oder Auftraggebers. Für diesen ist der jeweilige Product Owner dann der primäre Ansprechpartner in der Anwendungsentwicklung, selbst dann wenn es um verschiedene (weiter)zu entwickelnde Produkte geht.


Was in einer solchen Konstellation weiterhin möglich ist, ist eine dauerhafte Beziehung zu wichtigen Anwender- und Stakeholdergruppen. Andere Auswirkungen können zumindest abgeschwächt werden: die Kontextwechsel werden tendenziell weniger, da die Wahrscheinlichkeit steigt auch zukünftig wieder mit den Produkten zu tun haben, und vergangene Erfahrungswerte können in diesen Fällen wiederverwertet werden.


Ganz ersetzen kann eine solche Konstellation echte Product Ownership nicht (alleine deshalb nicht weil zwischendurch andere Teams daran arbeiten können), in den oben genannten Konstellationen ist sie aber eine gute Möglichkeit dem zumindest so nah zu kommen wie möglich.

Donnerstag, 22. Oktober 2020

Der Agile Song

Auf die Gefahr hin in diesem Monat eine leichte Schlagseite in Richtung "agile Netzfundstücke" zu bekommen - das hier ist dann doch zu bemerkenswert um es hier nicht einzubetten. Der "Agile Song"  von Adam Janosch wurde gestern auf dem kölner Scrumtisch zwischen den Sessions gespielt und zumindest bei mir ist er direkt im Ohr hängen geblieben.


 


Um es auf eine Meta-Ebene zu hieven: dass es Werke wie dieses Lied gibt würde ich in ein Phänomen einordnen, dass ich einmal The Soft Power of Scrum genannt habe. Viele Umsetzungen dieses und anderer Frameworks sind bewusst verspielt, bunt und geekig gehalten, und das nicht etwa als von oben verordnetes Image-Programm sondern weil die an der Umsetzung Beteiligten sich über das rein Berufliche hinaus mit dem Vorgehen identifizieren und ihre Energie und Kreativität einfliessen lassen. Das ist etwas was nur sehr wenige andere Projekt-, Produkt- oder Prozessmanagement-Ansätze über sich sagen können.


Nachtrag 12.12.2020:

Jetzt auch in einer Weihnachts-Version.

Dienstag, 20. Oktober 2020

Agile Bauprojekte (IV)

Bild: Wikimedia Commons / Michael Wolf - CC BY-SA 3.0

Die Zukunft hat bereits begonnen. Noch vor kurzem galten agile Vorgehensweisen bei Bauvorhaben als etwas hochgradig Theoretisches, mittlerweile können wir eines mitten in Deutschland beobachten. Die Tesla-Gigafactory 4 bei Berlin wird iterativ-incrementell gebaut (nachzulesen bei der SZ): zuerst werden kleinere, schnell fertigzustellende Gebäude errichtet, deren Konstruktionsgeschichte wird ausgewertet und die Erkenntnisse fliessen als Verbesserungen in die nächstgrösseren Bauvorhaben ein, und das in Rekordzeit. Wie ist das möglich?


Ein lesenswerter Artikel der Zeit (leider hinter einer Paywall) liefert einige Antworten. Es beginnt mit den bekannten Faktoren, die z.T. auch den schnellen Bau der chinesischen Corona-Kliniken geprägt haben: Einfachheit, Standardisierung, Modularisierung, Entbürokratisierung und wenn möglich Wiederverwendung der Pläne von bereits erfolgreich abgeschlossenen vergleichbaren Bauvorhaben. Im Mittelpunkt stehen aber zwei weitere, bei Bauprojekten hochgradig unübliche: Risiko-Toleranz und Fehlerkultur.


Um nachvollziehen zu können warum das ein Paradigmenwechsel ist muss man auf das Risikomanagement klassischer Bauprojekte schauen. In ihm wird versucht Risiken dadurch zu begrenzen, dass die Beteiligten in möglichst detaillierten Verträgen regeln was welcher der beteiligten Geschäftspartner zu welchem Zeitpunkt zu erbringen hat. Gelingt einem von ihnen das nicht hat er für die entstehenden Mehrkosten aufzukommen, die anderen aber nicht.


In der Theorie mag das wie eine sinnvolle Umsetzung der Verursacherprinzips aussehen (wer Aufwände und Verzögerungen verursacht zahlt), in der Realität führt es aber zu ausufernden Vertragsverhandlungen, absurd detaillierten Vertragswerken, dem Zweckentfremden von Flexibilitätsreserven, extrem aufwändigen Prozessen bei nachträglichen Anpassungen und oft auch zu erbittert ausgefochtenen Rechtsstreitigkeiten. Die dadurch entstehenden Kosten und Aufwände gehören dann zu den stärksten Treibern von Budget- und Zeitplan-Überschreitungen.


Um derartige Entwicklungen gar nicht erst aufkommen zu lassen werden beim Bau der Gigafactory 4 bewusst Risiken eingegangen: statt der üblichen Festpreis-Verträge für bestimmte Gewerke erhalten die Baufirmen pauschale Aufwandsvergütungen, wenn für den schnellen Baufortschritt mehr Geld benötigt wird als initial geplant ist der Freigabeprozess unbürokratisch und wenn derartige Mehraufwände entstehen liegt das Hauptinteresse nicht auf dem Finden und Bestrafen von Schuldigen sondern auf dem schnellen Reagieren auf die geänderten Rahmenbedingungen.


Letztenendes wird hier ein systemischer Ansatz sichtbar. Natürlich kann es sein, dass bei diesem Vorgehen Teile des Gesamtvorhabens teurer werden als gedacht. Durch den bewussten Verzicht auf Detailregelungen, Prozessverflechtung und (juristische) Konflikte wird die Umsetzungsdauer aber derartig verkürzt, dass die frühe Betriebs- und Wertschöpfungsfähigkeit (und das dadurch mögliche frühere Erwirtschaften von Gewinnen) das bei weitem ausgleichen dürfte.


Für alle die das nicht so ganz glauben können hält der deutsche Standort von Tesla übrigens noch eine schöne Pointe bereit. Nur 30 Minuten Autofahrt entfernt kann man begutachten wohin klassisches Management eines Bauprojektes führen kann. Die Rede ist vom neu gebauten Berliner Flughafen, der jetzt endlich eröffnet wird - neun Jahre nach dem ursprünglich geplanten Termin und deutlich teurer.

Donnerstag, 15. Oktober 2020

Ein Bild sagt mehr als 1000 Worte (XXX)

Quelle: Twitter

Wow. Einfach wow.

Montag, 12. Oktober 2020

Everything I know about teams, I learned from computers

Das ist ein wundervoll nerdiger und ganz anderer Ansatz auf Teams zu schauen als der den man meistens vorfindet. Andrew Harvey nimmt sein Wissen über verteilte Systeme, überträgt sie auf die Zusammenstellung und das Managen von Teams - und das funktioniert erstaunlich gut.




Was ausserdem hervorzuheben ist sind die im Vortrag enthaltenen Anregungen sich in weitere Themen einzuarbeiten. Von den Neurowissenschaften bis zu den acht Irrtümern über verteilte Systeme ist Einiges dabei was sich zu erforschen lohnt.

Donnerstag, 8. Oktober 2020

Altsysteme (III)

Screenshot: Flickr / Josiah Ritchie - CC BY-SA 2.0
Legacy Software ist immer ein ergiebiges Thema, so auch im folgenden aktuellen Fall. Im Rahmen der Nachverfolgung von Coronavirus-Infektionen ist den britischen Gesundheitsbehörden eine massive Datenpanne unterlaufen: die Daten von fast 16.000 Tests gingen verloren, und das zunächst unbemerkt, mit unabsehbaren Folgen für die Verbreitung der Pandemie. So einzigartig wie dieser Fall erscheinen mag, seine Ursache ist weit verbreitet - das Verwenden einer hoffnungslos veralteten Standardsoftware.


Die ganze Geschichte kann man bei der BBC nachlesen: der die Tests durchführende Dienstleister trug die Ergebnisse zuerst in eine CSV-Datei ein und schickte diese dann an die Behörde Public Health England (PHE). Diese übertrug sie in das dort bevorzugte Tool, Excel von Microsoft. Und bei dieser Übertragung kam dann es zum unbemerkten Datenverlust. Der Grund dafür - die verwendete Excel-Version war zu alt. Warum das ein Problem ist lässt sich einfach erklären.


Bis zum Jahr 2007 speicherte Excel seine Dateien im XLS-Format ab, das bereits im Jahr 1987 eingeführt worden war. Neben anderen Problemen hat dieses alte Format eine Grössenbegrenzung auf genau 65.536 Zeilen, werden mehr eingegeben werden diese einfach nicht gespeichert. Seit 2007 sind daher neuere Excel-Versionen im Einsatz, die Dateien im XLSX-Format abspeichern, mit bis zu 1.048.576 Zeilen (die Erklärung dieser scheinbar krummen Zahlen findet sich hier).


Dem die Testergebnisse zuliefernden Dienstleister dürfte nicht bewusst gewesen sein, dass der PHE seit mindestens 13 Jahren nicht mehr in der Lage gewesen ist sein Excel auf die aktuelle Version upzudaten (warum das so sein dürfte steht hier) und vermutlich wusste der PHE auch nicht, dass seine alte Version die oben erwähnte Beschränkung hatte. Ohne zu ahnen, dass das ein Problem war wurde also eine viel zu hohe Menge an Datensätzen geliefert1, von denen dann alles ab Zeile 65.537 aufwärts beim Übertragen in Excel verloren ging.


Die grundlegenden Phänome die man aus dieser Geschichte ableiten kann: wenn veraltete Versionen einer Standardsoftware im Einsatz bleiben nehmen Anwender oft ohne darüber nachzudenken an, dass Eigenschaften der neuen Versionen (z.B. hohe Speicherkapazität) auch in der alten bereits vorhanden sind. Ausserdem geraten Probleme der alten Version (z.B. ausbleibende Warnungen bei Datenverlust) in Vergessenheit, da sie in der neuen unbekannt sind.


Um nicht den damit verbundenen Risiken ausgesetzt zu sein empfiehlt sich ein permanentes Updaten aller Standardsoftwares auf die jeweils neueste Version. Wenn zu starke Anpassungen vorgenommen wurden kann das zwar aufwändig werden, dass es trotzdem Sinn macht dürfte aber spätestens seit der Datenpanne des PHE offensichtlich sein.



1Da jeder Datensatz mehrere Zeilen enthält konnten pro Datei nur 1.400 gespeichert werden

Montag, 5. Oktober 2020

Geht zur nächsten Windows-Schulung!

Bild: Pixabay / Escola Espai - Lizenz

Würde man nach Veranstaltungen suchen die in der IT hochgradig unbeliebt sind, dann gäbe es sicher eine die weit vorne dabei ist: die verpflichtende Microsoft Windows-Schulung, die in vielen Unternehmen für jeden Mitarbeiter vorgesehen ist der neu ist oder der eine neue Windows-Version erhält1. Jeder der in der Softwareentwicklung tätig ist wird alleine bei der Ankündigung genervt fragen was er da noch lernen kann. Die überraschende Antwort - sehr viel, vorausgesetzt eine Sache ist gegeben. Der eigene Arbeitskontext muss einer sein bei dem Anwendungen für den internen Gebrauch entwickelt werden.


Was sich in diesem Fall hier gewinnen lässt ist ein gutes Verständnis der eigenen Zielgruppe, schliesslich sind die Kollegen in dieser Schulung im Zweifel auch die, die später auch die Software benutzen werden an der man selbst arbeitet. Und selbst wenn es um diese in dem Moment nicht geht - man kann trotzdem beobachten wie die Interaktion mit neuen Funktionen und Benutzeroberflächen vor sich geht und Rückschlüsse daraus ziehen.

 

Die offensichtlichste Erkenntnis betrifft die EDV-Affinität. Kennen die Schulungsteilnehmer die Fachbegriffe ("Was ist ein Browser?"), wissen sie wie man durch Dateien navigiert ("Im C-Laufwerk ist nichts") und sind ihnen die wichtigsten Troubleshootings bekannt ("Das Programm hatte sich aufgehängt, ich hab es mit dem Task-Manager geschlossen")? Basierend auf diesen Informationen kann entschieden werden wie kompliziert die eigene Anwendung sein darf und wie gut sie dokumentiert sein muss.


Auch über die Bereitschaft sich in neue Funktionalitäten einzuarbeiten und neue Designs zu akzeptieren kann man hier viel lernen. Gibt es Beschwerden darüber, dass Outlook nicht mehr gelb ist? Wird Freude darüber geäussert von Skype auf Teams-Calls umzusteigen? Abhängig davon kann entschieden werden ob Bedienelemente oder Styleguide sich eher an bisherigen Standards orientieren sollten oder ob man Neues ausprobieren kann.


Ein weiterer Aspekt sind die Hilfsmittel die üblich sind und ggf. erwartet werden. Reicht eine Beschreibung in Textform? Werden Anleitungen mit kommentierten Screenshots erwartet? Gibt es eine Akzeptanz für Wikis, Chatbots und Schulungsvideos oder wird ein Kursleiter erwartet der Fragen beantworten und bei Problemen helfen kann? Für das Rollout der eigenen Features kann später auf dieses Wissen zurückgegriffen werden.


Eine oft vernachlässigte Erkenntnis bezieht sich auf den Grad des Austausches zwischen den Kollegen. Bitten sie sich gegenseitig um Hilfe oder bieten sie sich diese sogar von selbst untereinander an? Oder sitzt jeder still vor seinem Rechner und ruft nur den Kursleiter per Handzeichen zu sich? Je nachdem was der Fall ist kann es für das eigene Produkt ausreichend sein nur jeweils einem "Multiplikator" pro Team Neuheiten vorzustellen oder besser alle einzuladen.


Nicht zu unterschätzen ist auch, dass man lernen kann wie gerne überhaupt in Schulungen gegangen wird. Von "endlich mal was Neues" bis "während wir hier Zeit verschwenden türmt sich bei uns die Arbeit" sind alle möglichen Reaktionen denkbar, und aufbauend darauf kann entschieden werden ob man zukünftig eher häufig oder eher seltener zu Demonstrationen und Hands on-Sessions einlädt.


Zuletzt, und vielleicht ist das sogar das Wichtigste, kann man auf Windows-Schulungen auch etwas über sich selbst lernen. Kommen einem bestimmte Dinge vielleicht selbstverständlicher vor als sie sind (um das Naheliegendste zu nennen - geht man z.B. davon aus, dass eigentlich jeder weiss wie Windows funktioniert)? Und kann es sein, dass man in die eigene Zielgruppe viel von sich selbst hineinprojiziert? Die Antwort auf diese Fragen kann ernüchternd sein, sie verhindert aber, dass man Anwendungen versehentlich für sich selbst entwickelt statt für die Menschen für die sie eigentlich gedacht sind. 


1In vielen Firmen ist die Umstellung auf Windows 10 noch nicht abgeschlossen. Ein eigenes Thema.