OTA 1.3.2 - Update smart #1 bugfix

  • Aber wir können auch Druck auf Smart erzeugen, diese Dinge schnellstens zu beseitigen. Dazu ist die Offenlegung im Forum hilfreich, meiner Meinung nach.

    Smart weiß das ja und wird auch Abhilfe schaffen. Man braucht sich doch nur mal den 'Wunschzettel' hier im Forum anschauen, da ist schon vieles von Smart abgearbeitet worden. Ich finde einzelne Sachen auch ärgerlich, aber ich finde das die Software für 1 Jahr Deutschland schon recht gut ist. Dafür sind Updates ja da und ich kenne keinen Hersteller der von Anfang an alles zu 100% erfüllt. Ich von meiner Seite aus freue mich immer, wenn neue Sachen implementiert sind und Fehler abgestellt werden. Ja klar ist es ärgerlich, wenn dann mal neue Bugs auftauchen. Das passiert selbst bei Updates von Apple, aber vielleicht arbeiten da auch nur unfähige Programmierer wie bei Smart auch? :/ ;) ^^

  • selbst bei Updates von Apple,

    🤔 Ich verstehe dich. Bis zu einem gewissen Punkt würde ich auch so argumentieren, doch ein Auto kostet geringfügig mehr als, bspw. ein PC, auch mit Leasing.

    Um bei dem Beispiel zu bleiben... Von einem Hochleistungsrechner inklusive Software erwarte ich schon mehr, als von einem NoName vom Discounter.

    ...

    Smart #3 Premium

    OTA 1.3.2 - 1.4.0 - 1.4.1 - 1.5.0

  • Heute morgen, hat der Fuchs zu seinen Pfoten, ein silbernes 50er Jahre Mikrofon gehabt, ungefähr für 5 Sekunden 😳, das hab ich bisher noch nicht gesehen.

    Hat das schon jemand gesehen ?

    Ist natürlich nicht so wichtig, wollte es aber mal erwähnen.

    Gruß

    Ja jedes mal nach dem Starten wenn das Radio schon läuft.

    #1 Premium in Quantum Blue Metallic, Dark Matter bestellt, als Leasing. Am 31.03.2023 endlich geklappt, dank Hilfe von marco79cgn :thumbup: . ALD okay am 03.04.23., DAD Mail am 24.05.2023, LT: 12.06.2023 war als erster Termin möglich. Fahrzeug am 25.05.2023 beim Händler eingetroffen, Zulassung 09.06.2023, Übergabe 16.06.2023, Bilder von Fuchsi und seinem Smart #1 etc, Update 1.5.0

  • Um bei dem Beispiel zu bleiben... Von einem Hochleistungsrechner inklusive Software erwarte ich schon mehr, als von einem NoName vom Discounter.

    ...

    Das sind Vergleiche vom Schlag Äpfel und Birnen. Was kostet ein Auto gegenüber einem smartphone? Gut. Aber wieviele smartphones eines Herstellers werden verkauft? Das sind alles Skaleneffekte. Beim Fahrzeug kommen sicher noch Freigaben seitens der Behörden und Dokumentationspflichten hinzu, da geht es unmittelbar um Sicherheitsaspekte. Wir lassen auf der Autobahn mal herrlich das Lenkrad los - guck mal, der lenkt von alleine. Aber: ein falsches Bit zur falschen Zeit - und die ganze Familie landet im Graben.

    Solange allerdings Zeit für lustige Fuchsanimationen ist, solange sollte sich smart aber Zeit für ausgiebige usability-Tests und -Verbesserungen nehmen. Das sollten wir einfordern und nicht - muss sich ja jetzt keiner angesprochen fühlen - abwiegeln und nach Fehlern bei der Konkurrenz suchen. Die helfen uns nicht weiter, höchstens um uns herzerwärmend selbst weiszumachen, wir hätten uns für das richtige Auto entschieden. Haben wir, keine Sorge, guckt Euch den Volvo an: less for more 😊.

  • Man darf sich das mit der Priorisierung von Softwareanpassungen auch nicht so einfach vorstellen. Zunächst unterscheidet man diese üblicherweise kategorisch nach

    • Bugfixes: Anpassung zur (Wieder-)herstellung einer bereits ausgelieferten Funktionalität
    • Change Request: Veränderung des Umfangs / Verhaltens einer bereites ausgelieferten Funktionalität
    • Feature Requests: Hinzufügen einer neuen Funktionalität
    • Refactorings: Anpassungen ohne Auswirkungen auf die Funktionalität (z.B. Code-Optimierungen, allgemeine Softwarepflege, damit das Artefakt auch künftig noch wartbar)


    Die Kategorie selbst gibt eine gewisse Priorität vor und zusätzlich werden alle Anforderungen innerhalb einer Kategorie zusätzlich priorisiert. Welche Kriterien dabei angesetzt werden, ist höchst unterschiedlich. Auch ist eine Abgrenzung zwischen den Kategorien nicht immer so leicht, weil die Frage „was war eigentlich genau Bestandteil der versprochenen Funktion“ nicht immer eindeutig beantwortet werden kann. Und damit verbunden auch die Frage, ob es sich um eine Fehlerbehebung handelt oder um eine neue Funktion. Prinzipiell sollten Bugfixes immer Vorrang vor neuen Funktionen haben, nach dem Motto: „bring erstmal den versprochenen Sche*ß zum Laufen, ehe du was neues anfängst“. Aber so einfach ist das leider nicht. Da gibt es Vorgaben und Erwartungen vom Management oder anderen Stakeholdern und ehe man sich versieht, hat man für Bugfixes bestenfalls genauso viel Zeit wie für neue Funktionen, für die das Marketing schon die Folien und Presseberichte fertig hat, obwohl die Liste an zu behebenden Fehlern (Backlog) vielleicht deutlich länger ist.


    Da braucht es dann ein wirklich gutes Produktmanagement, das auch das Standing hat, sich mal gegenüber der Geschäftsleitung durchsetzen zu können. Dabei dürften auch definierte Kennzahlen (KPIs) eine entscheidende Rolle spielen und das ist dann der Punkt an dem wir Nutzer dann auch indirekt die Möglichkeit haben, etwas zu bewegen. Wenn Ticketaufkommen oder negative Presse sich entsprechend auswirken.


    Aber selbst wenn das Management zu Zugeständnissen bereit wäre, die Roadmap aufgrund dringender Bugfixes anzupassen und einzelne Funktionen zu verschieben, ist es mit einem einzelnen fähigen Produktmanager leider nicht getan. Software ist heutzutage oftmals derart komplex, dass Entwicklungen von verschiedenen Teams erledigt werden. Jedes Team mit seinem eigenen Produktverantwortlichen und eigener Priorisierung der Aufgaben. Spannend wird es dann, wenn ein gemeldetes Problem zwischen den Teams herumgereicht wird, weil die Zuständigkeit vielleicht zunächst falsch bewertet wurde oder sich diese nach einer ersten Fehleranalyse anders darstellt. Und noch spannender wird es, wenn die Behebung eines Fehlers nicht innerhalb eines Teams erfolgen kann, sondern verschiedene Teams involviert sind. Da prallen dann direkt die Prioritäten der Beteiligten aneinander und machen eine intensive Abstimmung erforderlich. Besonders herausfordernd ist es dann, wenn es externe Abhängigkeiten gibt, man selbst also keinen Einfluss auf alle relevanten Bestandteile hat. In einem Auto könnte ich mir gut vorstellen, dass eine Firma wie Smart die Software einzelner Steuergeräte nicht selbst verantwortet. Zumindest von deutschen Autobauern wissen wir, dass da auch Zulieferer wie Bosch eine Rolle spielen. Und da wird es dann schon manchmal schwierig. Da ist der Autohersteller dann auch nur Kunde.


    Das mal als kleinen Einblick in die Komplexität verteilter Systeme und den damit verbundenen Herausforderungen. Das erklärt dann hoffentlich auch, weshalb zuweilen als unnütz empfundene Funktionen veröffentlicht werden, obwohl es doch eigentlich gerade viel dringendere Baustellen gäbe. Gut möglich, dass das Ticket gerade bei einem anderen Team liegt, der Zulieferer auf sich warten lässt oder Konzernvorgaben die Entscheidung beeinflusst haben. Das muss weder für Smart noch die Automobilbranche als solches zutreffen, aber das sind meine Erfahrungen in 20 Jahren im Bereich der Softwareentwicklung.

    #3 BRABUS | Laser Red Metallic + Eclipse Black | Continental AllSeasonContact 2

    iOS und CarPlay-Nutzer, Wenigfahrer, Smarthome-Enthusiast