Hallo Markus, danke für Deinen Beitrag, fand ich sehr gut.
Smart Jeanie hat geschrieben: ↑Fr Jun 05, 2020 12:09 pmDie Nicht-Zählung fände ich keine gute Lösung. Besser fände ich es, die Umfrage zu ändern, so dass man erkennen kann in welchem Umfeld die Probleme lagen, z.B. mit den Docker-Containern.
Da kann man durchaus daran denken. Nur müssen wir eben auch realistisch bleiben. An den TWS kann man hunderte Geräte anschließen mit tausenden Funktionen. Wir kennen weder alle diese Geräte noch Funktionen der Kunden und mit Docker kommen dann auch nochmal völlig andere Geräteklassen und Möglichkeiten hinzu. Es ist unmöglich alles zu testen, was es auf der Welt gibt und angeschlossen werden kann.
Würden wir für alle damit zusammenhängenden Problemklassen eine Statistik erheben, könnte ein oberflächlicher Betrachter den Eindruck bekommen, beim TWS funktioniert nichts. Wir dürfen nicht vergessen, dass wir uns in einer Bewertungsgesellschaft befinden und zuviele "Dislikes" aka Negativbewertungen einen großen Schaden auslösen können. Nicht jeder Nutzer versteht, dass er in seinem Smarthome zum Integrator wird und manche Funktionen auch erobert und administriert werden müssen und das andauernde Einspielen von Updates und Firmware von der Kamera bis zum intelligenten Schlüsselbund das Szenario jeweils neu aufstellt und der Server zwar viel kann aber nicht jedes Kompatibilitätsproblem der Welt beheben kann.
Würden wir also jeden kleinen Schluckauf erfassen, könnte ein falscher Eindruck entstehen.
Daher plädiere ich dafür, dass in der Statistik der Updatequalität nur die direkten und supporteten Kernfunktionen gemessen werden, damit wir auch eine klare Kennzahl haben, nach der wir uns richten können, wenn wir entscheiden aus einer Insider Version eine Hauptversion zu machen.
Es bleibt dem Nutzer ja unbenommen, hier im Textteil zu berichten, welche Funktionen angeschlossener Komponenten womöglich Aufwand verursacht haben, wobei ich mir wünsche, dass erst geprüft und dann geschossen wird, weil in zwei Drittel der Fälle hatte es nicht mal indirekt mit dem Update zu tun, sondern ist ein zufälliges zeitliches Zusammentreffen (wobei es meistens nur an der erhöhten Aufmerksamkeit nach einem Update liegt).
Smart Jeanie hat geschrieben: ↑Fr Jun 05, 2020 12:09 pmAuf diese Weise kann ich mir als Anwender mit steigender Zahl an Rückmeldungen ein Bild davon machen, wo am ehesten Probleme zu erwarten sind und ob ich davon betroffen sein kann.
Gerade bei sehr speziellen Docker Problemen mit einem speziellen USB Device (wobei das gemeldete Problem in diesem speziellen Fall mit einem USB Device zusammen hängt, das im Forum schon öfters negativ aufgetaucht ist, weil der Hersteller den USB Chip nicht - oder nicht korrekt - initialisiert hat und dieses nun die Kunden selbst mit einem Tool vornehmen müssen und diese Initialisierung womöglich nicht perfekt verläuft). Mit anderen Worten: Kaum übertragbar auf andere Fälle und nichts was mit dem Timberwolf Server zu tun hat.
Smart Jeanie hat geschrieben: ↑Fr Jun 05, 2020 12:09 pm.... und primär auf TWS-native Funktionen setzen. Deren Bereitstellung verzögert sich. Ein Grund ist Euer Anspruch an Perfektion. Fehlerfreiheit ist schön, aber unwirtschaftlich. Und Perfektion ist auch nicht kundenfreundlich. Mein Swiss Mulitool kann 20 Dinge gut, aber nichts davon sehr gut. Für jedes dieser 20 Dinge habe ich ein perfekteres Werkzeug. Trotzdem benutze ich das Multitool häufig. So sähe ich den TWS auch gern.
Nun, nach meiner Analyse und dem was wir im Support erleben, deckt sich Deine Meinung nicht mit dem Wunsch der meisten anderen Kunden und den wirtschaftlichen Folgen.
Ich verstehe den Vergleich des Multitool hinsichtlich der vielen Eigenschaften des Timberwolf Servers. Aber so ein Multi Tool ist als Kompromiss gebaut worden, dessen Haupteinsatz der mobile ist. Es muss in die Tasche passen, dem ordnet sich alles unter. Und im Notfall ist ein schlechtes Messer im Wald besser als das tolle Messer das Zuhause liegt.
So ein Server muss dagegen den ganzen Tag funktionieren, optimalerweise Jahrzehnte lang mit einer extremen Verfügbarkeit von 99,99 % oder besser. Im Zusammenhang mit hunderten anderen Geräten. Die Kunden wollen dafür keinen Kompromiss, das muss einwandfrei funktionieren. Jedesmal. Ein mir bekannter KNX Entwickler ist mal auf eine fünfstellige Summe verklagt worden, weil in einer Handvoll Fälle ein Licht im Haus nicht angegangen war. Man darf ja nicht vergessen, dass es nicht nur nette Menschen gibt.
Ob man mit so einem komplexen Produkt am Ende auch Geld verdient, ergibt sich aus der Stückzahl und wie aufwändig der Support ist. Stückzahl erzielt man nur, wenn das Gerät eine gute Bewertung bekommt und vor allem die professionellen Kunden das Gerät zigmal für deren Kunden kaufen. Das Gerät muss also TOP funktionieren, einfach bedienbar sein, nicht ausfallen und auf gar keinen Fall darf es beim Endkunden Probleme machen für die dann der Integrator Ärger mit seinem Kunden hat. Weil dann kauft er es nie wieder. Support in dieser Komplexitätsklasse kostet uns um die 120.- EUR pro Stunde. Und es gibt Integratoren die für den Austausch fehlerhafter Komponenten oder Fehlersuche vom Hersteller bezahlt werden wollen (Schadensersatz).
Unser Anspruch an Perfektion entsteht durch die Anforderung der Kunden. Fehlerfreiheit IST definitiv wirtschaftlich, weil ein einzelner kleiner Fehler, den ein Integrator in einer Kundenanlage hat, er deswegen hinfahren, Fehler suchen und das problem eingrenzen muss, womöglich unseren Support bemühen, gemeinsam weiter an der Ursache suchen, kann gut und gerne 1000 EUR an Arbeitszeit kosten.
Wir hatten vor drei Monate so einen Fall. Integrator ruft aufgeregt an, der KNX Bus geht nicht, am Abend ist Vorführung und Abnahme, der Server funktioniert mit KNX nicht. Großes Theater, mehrere Mitarbeiter involviert, zuerst First Level, dann Second Level und wegen der Dringlichkeit den Entwickler hinzugezogen, zusammen nach dem Fehler gesucht, Traces ausgewertet, Messungen vornehmen lassen. Nach einigen Arbeitsstunden stellt sich heraus: Ursache war ein Adernbruch im KNX Kabel, dadurch intermittierende Aussetzer auf der Leitung. Vorführung gerettet, ein ansehnlicher dreistelliger Betrag im Support verloren.
Ergebnis: Wir haben eine diesbezügliche Meldung in den Stack eingebaut, der bei den KNX Interfaces nun angezeigt wird. Künftig kann der Kunde das selbst sehen, weil es im Log angezeigt wird. Auch weil viele Nutzer das so erwarten. Mancher Nutzer würde die Schuld nicht dem Adernbruch oder dem womöglich handwerklichen Fehler beim Abisolieren suchen, bei dem die dünne Ader so gekerbt wurde, dass diese nach mehrmaligen Knicken bricht und das womöglich so unter der leicht verschobenen Isolierung, dass man es nicht sieht. Es gibt nunmal eine gewisse Nutzerschicht, welche in solch einem Fall die die Schuld beim Server sieht, weil der dies nicht angezeigt hat.
Wir können es uns nicht leisten, dass ein Integrator unseren Server aus dem Programm nimmt und in den nächsten zehn Jahren womöglich nicht hundert Stück davon an seine Kunden verkauft, weil er vom Produkt enttäuscht wurde. In einer Welt mit großer Informationsflut und von einzelnen oft kaum noch überblickbaren technischen Details muss die Technik möglichst alles kompensieren und darf nicht nur keinen Frust machen, sondern muss auch für Begeisterung sorgen. Weil beim nächsten Mal, wenn der Kunde dann ein Problem schnell lösen kann, weil er eine tolle Anzeige bekommen hat, wird er das mit Begeisterung zur Kenntnis nehmen und die Begeisterung in das Verkaufsgespräch mit seinen Kunden führen.
Zumindest wenn Du als Hersteller "neu" auf dem Markt bist. Als alteingesessener Hersteller ist das was anderes. Da hast Du einen guten Ruf von früher auf der Basis der damals viel einfacheren Produkte und der beschert Dir laufende Umsätze aus guter Erfahrung. Wenn wir nun einen Integrator dazu bringen wollen, auf unseren Server zu wechseln, dann ist das mit großem Aufwand verbunden. Das macht der Integrator nur, wenn wir sehr sehr viel besser sind als das bisher eingesetzte Produkt, damit sich der Aufwand und das Risiko für ihn lohnt. Und um eben mit dem Server auch zu Punkten, müssen wir damit an allen Stellen richtig gut sein.
Kurz: Wir sind darauf angewiesen, dass die Integratoren unsere Server gerne an Ihre Kunden verkaufen. So wie ein Hersteller eines Milchproduktes darauf angewiesen ist, dass die Supermarktketten sein Produkt listen und im Markt verkaufen. Wenn die Kunden wegen Schimmel oder schlechtem Geschmack reklamieren, dann war es das für den Hersteller des Milchproduktes.
Anderes Beispiel: Letztens hatten wir einen Kunden, der hat in Docker was aufgesetzt und ist dann mehrere Monate beruflich ins Ausland gefahren. Die Anwendung in dem Container hat dem Server über die Monate hinweg die Platte vollgeschrieben. Klar ist das der Fehler des Kunden, aber sieht er das auch ein? Der diesbezügliche Supportfall hat uns mehrere Stunden gekostet. Könnten wir das abrechnen? Vermutlich ja, weil es steht im Vertrag. Aber wird der Kunde das auch akzeptieren? Vermutlich nein. Ergebnis sind stundenlange Diskussionen die - Du wirst es ahnen - uns nochmal 120.- EUR die Stunde kosten.
Darum bleibt uns am Ende nichts anderes übrig, als alles und jedes so perfekt wie möglich auszuführen, Analysen und Warnungen einzubauen und alle nötigen Bordmittel. damit die Kunden sich auch selbst helfen können. BTW: wenn der Kunde sich einen SSH Container gebaut hätte, hätte er sich auch selbst helfen können. Nur kann er argumentieren, dass ihm niemand das gesagt hat. Nun blenden wir einen Disclaimer ein und geben eine Hilfe mit und Kennzeichnen Werte - die so auch im Portainer stehen - nun farblich und alles auf einen Blick, damit es nicht übersehen wird. Weil wir wollen diese Supportfälle nicht mehr haben, bzw. brauchen eine Diskussionserleichterung wenn wir solcherlei Supportaufwand dann abrechnen wollen.
Smart Jeanie hat geschrieben: ↑Fr Jun 05, 2020 12:09 pmSo gesehen ärgert es mich ein wenig, wenn Du hier so ehrlich bist zu schreiben, dass die Quotierung von Docker-Containern bei den Hutschienenmodellen 2-3 Mannwochen benötigt.
Im schlechten Fall, womöglich ist es auch mit drei Manntagen zu schaffen, aber das wissen wir erst danach. Wenn immer was am Kernel machen muss, kann das einen Rattenschwanz nach sich ziehen.
Smart Jeanie hat geschrieben: ↑Fr Jun 05, 2020 12:09 pmDa ich selbst Container vermeiden möchte und selbst wenn ich sie nutzte, dieses Feature nicht erwarte, fände ich es als "normaler" TWS-Nutzer besser, diese Entwicklerkapazitäten würden nicht in eine perfekte Docker-Verwaltung gesteckt, sondern in TWS-native Funktionen, also in die nächsten Dinge, die der TWS wie ein Multitool gut kann.
Ja. Aber es ist nun mal der Wunsch einiger, dass eine solche Quotierung erfolgt.
Schau Dir bitte mal die Dynamik von Change Requests an. Wenn ich einen solchen Request "ablehnen" würde, dann folgt, das ist die allgemeine Erfahrung, dass anschließend umso vehementer um den CR gekämpft wird. Es ist wirklich jedesmal so. Wenn ich nur ein wenig den CR zurückweise, setzt diese Dynamik ein. Es hat eben jeder seinen Herzenswunsch. Am Ende bekomme wir dann hier im Forum durchaus seitenlange Plädoyers für die jeweilige gewünschte Funktion. Am Ende stehen wir (ElabNET) nach solchen Pladoyers ungut dar. Gerade so, als wären wir die letzten auf der Welt, die einfach nicht kapieren wollen, wie wichtig diese gewünschte Funktion für den Betrieb des Servers ist und dass wir den Nutzer um eine wichtige Sache bringen würden, weil wir das Feature abgelehnt haben. Mancher würzt einen CR durchaus mit den abschließenden Worten, dass man den Server ja gerne den Bekannten beim Hausbau empfehlen würde, aber ohne das Feature würde das schwer fallen bzw. der Server ist nicht reif für ein Release.
Nicht zu vergessen, sehr viele der CRs kommen von den sehr aktiven Schreibern hier. Das sind Meinungsführer auf die wir auch angewiesen sind. Wir müssen die Beziehungen zu unseren Kunden schließlich auch pflegen, wobei das auch unsere besondere Stärke ist. Zudem laufen im nächsten Jahr viele Care Verträge aus und wir müssen dann um Verlängerung bitten.
Am Ende bleibt uns meist gar nichts anderes mehr übrig, als dieses und jenes Feature dann auch umzusetzen, damit der / die Nutzer glücklich sind. Wobei dabei dann auch ein besserer Server heraus kommt, es sind ja durchaus gute Ideen.
Mittlerweile haben wir auf diese Weise an vielen - nicht allen - Stellen einen ziemlichen Perfektionsgrad erreicht, allerdings erwarten die Kunden nun von neuen Leistungsmerkmalen mindestens die gleiche Umsetzungsqualität oder besser noch, das wir immer noch eines drauflegen. Weil nichts verbraucht sich so schnell wie Begeisterung und die brauchen wir eben auch für den Verkauf.
Das geht es uns wie den Spieleentwicklern. Jedes neue Spiel muss noch bombastischer werden als das vorhergehende. Mit all dem unguten Druck auf die Entwickler die das auslöst.
Smart Jeanie hat geschrieben: ↑Fr Jun 05, 2020 12:09 pmSorry, aber wer mit Containern "experimentiert", dem muss es dann auch mal reichen, wenn er für sich bei Problemen die Dinge bewertet, die Ihr ihm heute bereits anzeigt. Ihr seid nicht die Hausmeister des Universums. Ihr müsst nicht jeden selbst verursachten Dreck aufräumen. Wenn jemand Admin spielen möchte, dann muss er es irgendwann auch sein. Deswegen für mich wenig Docker. Mehr und schneller TWS-nativ und gerne auch weniger perfekt.
Wenn es nach mir geht, wäre die Reihenfolge der Umsetzung mancher Leistungsmerkmale auch eine andere gewesen in den letzten einundeinhalb Jahren.
Mit der Version 1.6 haben wir die neue native Unterstützung für ekey herausgebracht. Danach wollten wir intensiv Modbus fertig stellen.
Jedoch entstanden dann eine Menge Supportfälle hinsichtlich KNX und wir haben die Interfaceseite getuned um den Kunden mehr Infos und Rückmeldungen zu geben. Damit konnten die Kunden nun genau messen und mitloggen, dass es Verbindungsabbrüche mit Software in Containern gab. Also mussten wir anschließend mit zig Entwicklern fremder Software kommunizieren, damit die deren Fehler in deren KNX Tunnel implementierung beheben, nur damit wir keine Supportfälle mehr mit Containern und der KNX Schnittstelle hatten. Haben wir geschafft, aber es war Aufwand an dieser Stelle Ruhe ins System zu bekommen.
Damit wollten wir dann eigentlich die V 1.6 funktional abschließen. Nur gab es dann - rein zufällig - viel Support wegen Docker Containern und zwei mal Server mit zugemülltem Speicher. Ein voll geschriebener Server ist in der heutigen Bewertungsgesellschaft eine sehr schlechte Publicity. Ob das nun in die Sphäre des Herstellers oder des Anwenders fällt, ist für die Schlagzeilen erstmal egal.
Am Ende müssen wir stets zusehen, dass wir ALLE Nutzer zufrieden stellen und eine gute Bewertung von ALLEN bekommen. Es reicht keine einfache Mehrheit oder eine absolute. Wir brauchen eine sehr hohe Zustimmungsrate um fünf Sterne zu bekommen.
Ich würde mir auch manchmal etwas weniger an Anforderungen wünschen, damit wir besser mit den eigentlichen Hauptthemen voran kommen, aber das liegt eben auch ein gut Stück weit in der Hand der Nutzer und das man akzeptieren möge, wenn wir nicht jedem CR nachkommen können.
Bislang konnten wir uns dem Druck nur dadurch entziehen, dass wir dem Wunsch nachgegeben und das gewünschte implementiert haben. Das damit länger geplante Leistungsmerkmale auf der Strecke geblieben sind, muss man eben akzeptieren, wobei ich darüber nicht glücklich bin.
Allerdings ist mittlerweile viel geschafft und die bestehenden Leistungsmerkmale haben eine sehr hohe Qualität, so dass die Menge an Wünschen zuletzt stark zurück gegangen ist. Es sind zwar noch viele FRs offen und die werden wir auch einer nach dem anderen berücksichtigen, aber wir haben den Eindruck, dass wir das parallel zum Ausrollen neuer Funktionen einflechten dürfen, so dass wir nun deutlich schneller im Plan voran kommen, als noch vor einem halben Jahr. Die Aussichten sind also gut, dass wir bald eine Menge neuer starker Leistungsmerkmale bekommen, auch diejenigen großen Merkmale, auf die viele schon lange warten.
lg
Stefan