Ein Wunsch wird sich erfüllen //2274

Führungskräftemeeting ist nicht jede Woche, und bei weitem nicht jedes Führungskräftemeeting liefert verblogbare Ergebnisse. Manchmal aber doch.
Es war der Kundenwunsch an uns herangetragen worden, die Gerätesoftware nicht vollständig lizenzieren zu müssen, sondern nur die Teile, die der jeweilige Kunde tatsächlich benötigt. Offenbar erhoffen sie sich dadurch eine größere Einsparung.

Ich stellte erst mal klar, dass die Kosten deshalb nicht wesentlich geringer würden. Schließlich ist der Hauptkostenfaktor der Geräte die Hardware der Geräte selbst. Dazu käme in jedem Fall ein Basismodul der Software, die die grundlegende Funktionalität beinhaltet. Erst danach könne man die einzelnen Features aufteilen, um sie modular von Kunden lizenzieren lassen. Das sei aber ein ziemlicher Aufwand. Schließlich sei die ursprüngliche Software nicht so konzipiert gewesen [BTW möchte ich darauf hinweisen, dass ich die Softwareentwicklung erst übernommen habe, als sie bereits funktionsfähig seit Jahren lief. Seither habe ich zwar einige erhebliche Verbesserungen veranlasst, aber die gehen nicht in die hier nötige Tiefe. Mein Baby Evalyze dagegen ist von vornherein so aufgesetzt, dass man es leicht vom Rest separieren kann.]
Außerdem müsse man auch Sicherheitsaspekte berücksichtigen. Die modulare Trennung müsse so implementiert sein, dass der Kunde die nicht bezahlten Module nicht einfach freihacken kann. Anderseits müsse es aber technisch leicht und ohne bürokratische Formalitäten möglich sein, gewünschte Features nachzulizensieren, aber auch wieder zurückzuziehen bzw. zu deaktivieren. Und keinesfalls dürfe es passieren, dass Features, die Kunden rechtmäßig lizenziert haben, ihre Arbeit verweigern.
Bisher fungierten unsere Geräte selbst quasi als eine Art Dongle. Eine zusätzliche Überprüfung, ob die Software ausreichend lizenziert war, war deshalb gar nicht nötig. Aber wenn jetzt einzelne Module laufen sollen, und andere nicht, und das abhängig davon, wofür der Kunde bezahlt hat, reicht die Bindung an die Hardware nicht aus.
Das sei insgesamt ein enormer Aufwand, der die Gesamtkosten in die Höhe treiben würde. Unausgesprochen ließ ich die Mühseligkeit der Zertifizierung sowie behördliche Prüfungen und Auflagen. Das sollte allen Anwesenden eh bewusst sein.

„Die Kunden wollen es so“, erwiderte der Chef, „also machen wir es. Dann kostet halt die einfachste Grundversion bereits so viel wie jetzt das Gesamtpaket.“ Und die speziellen Features werden besonders teuer, weil die Entwicklungskosten dann nur noch auf wenige Kunden umgelegt werden, statt wie bisher auf alle. Für die zusätzlichen Programme, die über die reine Firmware hinausgehen, und die bisher im Gesamtpreis inbegriffen waren, zahlen die Kunden dann ebenfalls extra.
„Das lässt sich nicht von heute auf morgen so aus dem Ärmel schütteln. Das ist ein tiefer Eingriff in die Architektur“, gab ich zu bedenken.
„Wie lange schätzt du?“
Das sind solche Unwägbarkeiten, so viele unbekannte Variablen, .. Möglicherweise wäre es zweckmäßiger, das Grundgerüst völlig von vorn neu und ohne Altlasten .. äh .. historisch gewachsener Strukturen zu implemetieren, in das man dann die einzelnen Module einhängen kann oder auch nicht. Ich erklärte, dass ich keine Aufwandabschätzung aus dem Stegreif machen könne, sondern dafür zumindest einiges vorklären müsste. Außerdem sei das SW-Team aktuell noch großteils mit Evalyze beschäftigt [parallel stehen jetzt umfangreiche CBTs an]. Nach dem Evalyze-Release (hoffentlich noch im ersten Halbjahr 2020) wären dann wieder genügend Personalkapazitäten frei, um mit einem neuen großen Software-Projekt zu beginnen. Aber diese Modularisierung würde sich hinziehen.

„Wieso dauert das so lange? Die Entwicklung der ersten Version der Gerätesoftware hat nicht viel länger als ein halbes Jahr gedauert.“
Ich schluckte irritiert. „Willst du ernsthaft wissen, warum eine neue Software erheblich länger dauert?“
„Ja, allerdings!“ Er lehnte sich in seinem Drehsessel zurück, Hände hinter dem Kopf verschränkt. „Ich höre.“
„Die Geräte selbst hatten anfangs nur eine sehr einfache Funktionalität“, begann ich die Aufzählung, „die war relativ einfach zu steuern. Das User Interface war minimal. Es gab weder Konfigurationsmöglichkeiten noch sonstige Funktionen, mit denen der Nutzer hätte interagieren können. Die ursprüngliche Software war trotzdem stark fehlerbehaftet. Fehler, die dann im Laufe der späteren Jahre mehr oder weniger umständlich bereinigt werden mussten. [Und was die Code-Qualität betrifft, war es wirklich nur so quick’n’dirty hingeschludert. Getestet wurde auch nicht sorgfältig und gründlich.] Damals musstet ihr euch noch nicht mit so strengen Reglementierungen und Zertifizierungen herumschlagen. Und inzwischen ist die Funktionalität stark erweitert worden, beispielsweise was das Handling der Permanent Interoperability Virtualization mit dem Persistent Efficiency Notification Intrinsic Stack [nur Buzzwords, die realen Begriffe kann ich euch aus Annenühmisierungsgründen nicht nennen] betrifft, und es gibt mehrere Produktlinien. Es gibt viel mehr Optionen und Einstellungen als früher. Die alle muss man berücksichtigen und das erhöht den Entwicklungsaufwand enorm. Die erste Version war eher ein Prototyp als eine ausgereifte Software. Das waren die ersten 20% Aufwand, die nach Pareto zu 80% Ergebnis führen. Heutzutage käme das Produkt so nicht mehr durch die Zulassung.“ [Dagegen sind die Äpp oder die Sprachsteuerung OTask nur aufgepfropfte Nutzerschnittstellen, die unabhängig vom Backend sind.]
„Hm ..“ stimmte er mir missmutig zu.

Wir kamen dann überein, erst mal Evalyze fertigzustellen, und danach die Modularisierung anzugehen. Mit Vorüberlegungen und Spezifikation darf ich bereits anfangen. Ich muss mir auch schon überlegen, wie ich die einzelnen Arbeiten auf die anderen Standorte aufteile und koordiniere.
Die anfragenden Kunden lassen wir wissen, dass die Planung für das modulare Lizensierungsmodell begonnen hat.