Mann am Computer

Bugfix vs. Change Request – Unterschied für Kunden relevant?

Programme ohne Bugs – schön wär’s!

„Bug“ bedeutet übersetzt „Käfer” und bezeichnet einen Fehler in einem Programm. Bugs können überall vorkommen, wo etwas programmiert wird. Sie können z. B. als technische Bugs zu Störungen und auch Abstürzen führen. Funktionale Bugs äußern sich dadurch, dass ein Programm-Feature nicht so arbeitet, wie es sollte. Zu Darstellungsfehlern kommt es, wenn sich Fehler in der Benutzeroberfläche einschleichen. Das kann bei Betriebssystemen, Games oder auch bei Webseiten der Fall sein. Je komplexer das Programm, desto anfälliger ist das Betriebssystem für Bugs. Die Frage ist aber, ob es sich immer um Bugs handelt, oder ob die Grundlage in einem Change Request liegt.

Welche Bugs bergen eine Gefahr?

Die sogenannten funktionalen Bugs und Darstellungsfehler können störend sein, sind aber für das Programm nicht wirklich gefährlich. Bei technischen Bugs, die auf eine Unsauberkeit in der Programmierung hinweisen können, sieht das schon anders aus! Hier können leicht Sicherheitslücken entstehen und sich Schlupflöcher für Malware bilden.

Deshalb sollte man, vor allem in größeren Unternehmen, die Software regelmäßig auf Bugs testen. Das kann durch Informatiker oder durch sogenannten „Bug Bounties“ geschehen. Bei Bug Bounties werden Hacker und Softwarespezialisten aus aller Welt dazu aufgerufen, Programme des Unternehmens zu testen. Google, Microsoft oder die Telekom veranstalten solche Bug Bounties. Eine bessere Methode zum Aufspüren von Angriffsflächen kann es nicht geben, ist aber für kleinere Unternehmen meistens keine Option, da eine Herausforderung für Hacker weltweit gegeben sein muss.

Bugfix – was ist das?

Wo ein Fehler ist, gibt es meist eine Lösung. Bei Bugs heißt diese Lösung Bugfix oder auch Patch. Updates enthalten oft schon Bugfixes für bekannte Probleme. Der Nutzer muss nach einer Fehlerbehebung nicht die gesamte Software neu herunterladen und installieren, da die fehlerhaften Programmteile durch implementierte Bugfixes korrigiert wurden.
Beispiel Zero-Day-Lücke

Eine Zero-Day-Lücke ist die entscheidende Schwachstelle im IT-System einer Firma. Der Fehler in der Software, Hardware oder Firmware mit dem potenziellen Angriff (Zero-Day-Exploit) erfolgt am selben Tag, an dem die Security-Lücke überhaupt entdeckt wurde. Oft wird sie erst durch diesen Angriff überhaupt entdeckt. Zero-Day-Lücke deshalb, weil zwischen Entdeckung und Angriff auf die Sicherheitslücke Null Tage liegen.

Bug oder Change Request – Programmierer vs. Kunde?

Kunden lösen manchmal einen Disput mit dem Programmierer aus. Handelt es sich nun um einen Defekt, da sich die Software nicht ganz so verhält wie im Briefing vereinbart oder handelt es sich um eine Änderungsanfrage des Kunden? Also macht die Software eigentlich schon das, was man von ihr verlangt und ist das, was sich der Kunde denkt, eine neue oder erweiterte Funktionalität?

Je komplexer ein IT-Projekt ist, desto eher verlangt der Projektablauf, dass man in den ursprünglich vereinbarten Leistungsverlauf Änderungen nicht mehr so einfach umsetzen kann. Das hat vielfältige Ursachen und kann auf beiden Seiten entstehen, sowohl beim Kunden als auch bei der Agentur.

Mögliche Ursachen für einen Change Request

  • Änderungen der Gesetzeslage
  • Technische Weiterentwicklungen
  • Lernprozesse des Kunden im Laufe der Zusammenarbeit
  • Änderungen im Unternehmen des Kunden
  • Änderungen in der Ausrichtung des Marketings oder von Vertriebsprozessen des Kunden

Lösungsorientiert denken!

Es ist nicht immer klar zu definieren, ob etwas, was der Kunde möchte, ein „Bug” oder ein „Feature” ist. Das ist manchmal besonders ärgerlich, weil es in den meisten Kontexten, in denen es diskutiert wird, gar keinen bedeutungsvollen Unterschied gibt. Denn während einer Projektentwicklung stößt man immer wieder auf Neues, Unglaubliches, nicht zu Ende Gedachtes, sich Widersprechendes, aber letztendlich zu Implementierendes.

Im Team mit dem Kunden bespricht man das weitere Vorgehen und die eventuellen Verfeinerungen. Eine erweiterte Feinkonzeption braucht in ihrer Entwicklung einen kostenpflichtigen Change Request. Es ist nicht immer ein Fehler, wenn sich die Implementierung von den nötigen Spezifikationen unterscheidet. Arbeitselemente sollte man basierend auf ihrem Wert priorisieren und sie können den Umfang der definierten Projektanforderungen erweitern, verändern oder auch reduzieren.

Nach der Identifizierung des Problems liegt der nächste Schritt darin, eine Lösung zu finden, die hauptsächlich darin liegt, jegliche Überraschungen in der Benutzererfahrung zu vermeiden! Eventuelle Begleiterscheinungen, die mit der beauftragten Änderung einhergehen können, sollte man unbedingt im Vorfeld klären!

Die Unerlässlichkeit des Workshops

Am Anfang jedes größeren Projekts ist eine Analyse am Anfang unabdingbar. Und zwar mit allen relevanten Abteilungen des Unternehmens. Die von econsor anfänglich durchgeführten Workshops minimieren das Risiko von Überraschungen erheblich. Weiterhin braucht man eine ständige und qualifizierte Kommunikation mit dem Kunden.

Fragen der Entwickler muss der Kunde weiterhin zu jeder Zeit beantworten. Verständnis von Seiten des Kunden ist wichtig, damit der Programmierer gegen jeden Zweifel fragen kann, anstatt Annahmen zu treffen. Die Zeit, die man für eine Klarstellung benötigt, wird immer kürzer (und weniger nervenaufreibend) sein als die Debatte darüber, wer jetzt was vermasselt hat.

Achtung! Falle „Nachvollziehbarkeit“

Oft entsteht das Problem, dass man viele „kleinere Zusatzleistungen” schnell mal per E-Mail oder sogar am Telefon von verschiedenen Ansprechpartnern des Auftraggebers in Auftrag gibt. Der einheitliche Prozess zur Beauftragung dieser Leistungsänderungen, der sogenannte Change Request, fehlt. Dies hat zur Folge, dass es gerade für den Kunden zum Zeitpunkt der Abnahme nicht mehr nachvollziehbar ist, welche Change Requests beauftragt und somit Gegenstand der Abnahme sind oder wie Stunden bei der Programmierung der Software entstanden sind.

Fazit

Änderungen innerhalb eines Projektes sind genau zu strukturieren. Dazu ist ein im Vorfeld definierter Änderungsprozess nötig, der alle enthaltenen Schritte dann für den Kunden einleuchtend dokumentiert. Bei econsor kann der Kunde zu jeder Zeit nachvollziehen, an welcher Stelle des Projektes man sich befindet und wie viele Stunden für welchen Prozess gebraucht wurden.

Wir weisen bei Vertragsschluss darauf hin, dass sowohl Anforderungsänderungen oder -erweiterungen üblich und im Budget einzuplanen sind. Das gilt auch für noch unerkannt im Programm implizierte Bugs, die der Programmierer zumindest in jedem Fall überprüfen sollte, da bei jedem Template oder jeder Extension Programmierarbeiten vorgenommen werden müssen, die Bugs nie ausschließen. Das ist im Projekt als üblich und realistisch anzusehen und bleibt nicht aus.

Und unabhängig davon, ob es sich um einen Bug oder eine Änderungsanfrage handelt, der erforderliche Aufwand ist derselbe und eine professionelle Lösung ist notwendig. Im Hinblick darauf verliert die Debatte ihre Bedeutung, sodass sich das gesamte Team einfach auf ein perfektes Endergebnis konzentrieren kann.

Diesen Beitrag bewerten

0 Kommentare

Dein Kommentar

Möchtest du mitdiskutieren?
Fühl dich frei, beizutragen!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden .