{"id":3573,"date":"2021-01-29T15:35:05","date_gmt":"2021-01-29T15:35:05","guid":{"rendered":"https:\/\/blog.tchop.io\/?p=3573"},"modified":"2024-08-19T06:13:47","modified_gmt":"2024-08-19T06:13:47","slug":"was-kostet-die-entwicklung-eines-neuen-features-wirklich","status":"publish","type":"post","link":"https:\/\/blog.tchop.io\/de\/was-kostet-die-entwicklung-eines-neuen-features-wirklich\/","title":{"rendered":"Was kostet die Entwicklung eines neuen Features wirklich?"},"content":{"rendered":"\n
\"Hand<\/figure>\n\n\n\n

Als Software Plattform entwickeln wir die meisten neuen Features und Funktionen anhand Ihrer Anforderungen und Ideen gemeinsam mit unseren Kunden. Dabei sind wir immer bem\u00fcht das Produkt sowohl f\u00fcr unsere Partner als auch f\u00fcr deren Nutzer\/Innen zu verbessern, effizienter zu machen und den Mehrwert zu erh\u00f6hen. Tats\u00e4chlich ist es so, dass die Kosten im Zusammenhang mit der Implementierung von neuen Features fast immer – meist auch von einem selbst – untersch\u00e4tzt werden. Oft zahlt man langfristig „die Zeche“ wie man so sch\u00f6n sagt. Und besonders bei neuen Dingen, die dann letztlich nicht wirklich intensiv genutzt werden, sind die damit verbunden Kosten schnell \u00e4rgerlich und wirtschaftlich schlicht unn\u00f6tig.<\/p>\n\n\n\n

Software-Entwickler und technisch Verantwortliche kennen das Thema ausreichend, denn sie tragen die Verantwortung daf\u00fcr, dass alles reibungslos funktioniert. Mit diesem Beitrag wollen wir auch weniger technisch versierten Kunden und Kollegen einen Einblick in die tats\u00e4chlichen Kosten der Entwicklung neuer Features geben. Nur wer die wahren Kosten kennt, kann absch\u00e4tzen ob sich die M\u00fche lohnt. <\/p>\n\n\n\n

Spoiler: Oft sind die eigentlich Entwicklungskosten dabei nur der kleinere Faktor. Problematisch sind die indirekten Kosten. <\/em><\/p>\n\n\n\n

Hier einmal die 10 Kostenfaktoren, welche es eigentlich bei der Planung eines neuen Features zu beachten gilt:<\/p>\n\n\n\n

  1. Opportunit\u00e4tskosten \u00fcber alle Team-Mitglieder und Bereiche hinweg. Jede Organisation – auch unsere – hat begrenzte Ressourcen, d.h. wenn wir ein Feature entwickeln, haben wir daf\u00fcr keine Zeit ein anderes voranzutreiben. Und der Backlog an Ideen ist selten zu klein, meist eher schon gro\u00df genug.
    <\/li>
  2. Kosten, um die Anforderung genau zu verstehen, zu diskutieren und schriftlich auszuarbeiten. Diese Kosten fallen an bevor die eigentliche, technische Implementierung beginnt. Dies kann bereits oft einige Tage dauern. In der Regel m\u00fcssen mehrere Experten aus unterschiedlichen Bereichen involviert werden.
    <\/li>
  3. Direkte Kosten zur Implementierung der neuen Funktion. Damit sind dann wieder meist mehrere Leute im Team besch\u00e4ftigt. Oft sind sowohl die beiden Apps (iOS und Android) als auch das Backend mit den notwendigen Schnittstellen direkt betroffen. Bevor die Entwickler starten k\u00f6nnen, braucht es oft auch noch Konzept und Design.
    <\/li>
  4. Kosten im Zusammenhang mit dem technischen Rollout des Features. Das sogenannte „Deployment“ einer neuen Entwicklung gestaltet sich komplexer als es ist (Nein, wir laden da nicht einfach etwas Code hoch…\ud83d\ude42 ), denn es m\u00fcssen unterschiedliche Komponenten auf verschiedenen Servern aktualisiert und ver\u00e4ndert werden. Ausserdem m\u00fcssen andere Teile (bspw. das Monitoring) erweitert werden, ggf. braucht es andere, zus\u00e4tzliche technische Ressourcen oder Tools.
    <\/li>
  5. Die Funktion muss am Ende „feingeschliffen“ und bis zum endg\u00fcltigen Rollout optimiert werden, denn am Ende sind oft die letzten Prozent entscheidend, ob etwas aus der Sicht der Nutzerin bzw. des Nutzers reibungslos wirkt. Produktmanager, Entwickler und Test-Engineers sind damit besonders ganz am Ende oft l\u00e4nger besch\u00e4ftigt als man das geplant hat.
    <\/li>
  6. Das Feature muss laufend gepflegt werden. Software ist wie eine Pflanze, die man hegen und pflegen muss. Um so l\u00e4nger sie ohne Liebe und Zuneigung „herumliegt“, desto schneller geht es bergab mit ihr. Das Team muss dauerhaft sicherstellen, dass die neue Funktion l\u00e4uft und keine Probleme bereitet. Sprich: selbst die einfachste Erweiterung erh\u00f6ht die Komplexit\u00e4t des Gesamtsystems. Immer.
    <\/li>
  7. Kosten im Zusammenhang mit der Kommunikation des neuen Features, nicht in Richtung Kunden, aber in Richtung des internen Support-Teams. Alle Beteiligten m\u00fcssen die notwendigen Details verstehen und weiter kommunizieren k\u00f6nnen. Kommunikationsmaterial muss aktualisiert werden, Sprachregelungen angepasst oder neu verfasst.
    <\/li>
  8. Kosten, um das Tracking mit dem Analytics Dashboard anzupassen. Neue Funktionen verkomplizieren oft das Tracking oder sollen selbst explizit erfasst werden (besonders, um zu sehen ob bzw. wie sie angenommen werden). Tracking ist komplex und das erg\u00e4nzen von neuen Punkten erzeugt unmittelbaren Aufwand.
    <\/li>
  9. Kosten durch die Erh\u00f6hung der Systemkomplexit\u00e4t im Ganzen. Einer der am meisten untersch\u00e4tzten Punkte! Die Entwicklung neuer Funktionen wird mit der steigender Komplexit\u00e4t des Gesamtsystems aufwendiger. Dies betrifft nicht nur Maintenance und Support, sondern auch ganz konkrete neue Features. Eine gr\u00f6\u00dfere Code-Basis ist viel schwerer beherrschbar als eine kleine. Eine gr\u00f6\u00dfere Code-Basis erfordert mehr Erfahrung, Weitsicht und F\u00e4higkeiten von einem Entwickler. Allein dadurch wird die Entwicklung dann auch insgesamt teurer.
    <\/li>
  10. Kosten zur Aktualisierung von FAQs und Schulungsmaterialien. Neue Features m\u00fcssen auch hier aufgenommen, erl\u00e4utert und erkl\u00e4rt werden. Die interne Dokumentation muss erweitert werden damit auch zuk\u00fcnftig alle Details klar sind und schnell gefunden werden k\u00f6nnen. <\/li><\/ol>\n\n\n\n

    Die Gesamtkosten, die sich aus diesen Punkten ergeben werden in neun von zehn F\u00e4llen untersch\u00e4tzt. Wie hat ein namhafter Gr\u00fcnder so sch\u00f6n gesagt:<\/p>\n\n\n\n

    \u201cMost people overestimate what they can do in one year and underestimate what they can do in ten years.\u201d<\/p>Bill Gates<\/cite><\/blockquote>\n\n\n\n

    Gleiche Logik gilt f\u00fcr die Kosten neuer Features in der Software Entwicklung. Selbst, wenn wir die kurzfristigen Kosten manchmal vielleicht \u00fcbersch\u00e4tzen. So untersch\u00e4tzen wir fast immer die langfristigen bzw. darauf folgenden.<\/p>\n\n\n\n

    Inspiriert wurde dieser Beitrag \u00fcbrigens von diesem<\/a> Blog Post von John Cutler. Er schreibt:<\/p>\n\n\n\n

    „One of the fundamental challenges of product development is understanding the true cost of releasing a new feature. The benefits feel concrete. Shipping feels great. Talking costs is a downer.“<\/p>John Cutler<\/cite><\/blockquote>\n\n\n\n

    Verstehen Sie uns nicht falsch: wir lieben die Entwicklung neuer Features und gehen dies jeden Tag mit gro\u00dfer Energie an. Aber grunds\u00e4tzlich sollte man sich bewusst werden, wie die konkreten Auswirkungen aussehen. Daher sollte man sich auf Features fokussieren, die einen gro\u00dfen Mehrwert haben, aber hinsichtlich Ihrer direkten und indirekten Kosten begrenzt sind. <\/p>\n\n\n\n

    Dahinter sollte auch immer die Frage stehen: Ist dies den Aufwand wert, wenn man sich ehrlich \u00fcber den gesamten Aufwand Klarheit verschafft? \ud83d\ude0e Nicht immer ist die Antwort darauf „ja“. Und ganz oft ist dann auch ein „nein“ eine gute, professionelle Antwort.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Als Software Plattform entwickeln wir die meisten neuen Features und Funktionen anhand Ihrer Anforderungen und Ideen gemeinsam mit unseren Kunden. Dabei sind wir immer bem\u00fcht…<\/p>\n","protected":false},"author":3,"featured_media":3048,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[65,64],"tags":[],"coauthors":[134],"class_list":["post-3573","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-die-plattform","category-tchop-apps-de"],"_links":{"self":[{"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/posts\/3573","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/comments?post=3573"}],"version-history":[{"count":3,"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/posts\/3573\/revisions"}],"predecessor-version":[{"id":3579,"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/posts\/3573\/revisions\/3579"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/media\/3048"}],"wp:attachment":[{"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/media?parent=3573"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/categories?post=3573"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/tags?post=3573"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.tchop.io\/de\/wp-json\/wp\/v2\/coauthors?post=3573"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}