Gründe warum Projekte in der Softwareentwicklung scheitern
Dieser Artikel ist für unterschiedliche Leser wichtig zu verstehen. Es kann sein das du dich in der Situation eines Unternehmers, IT-Leiters oder Projektleiters befindest, dessen Softwareprojekt nicht von der Stelle kommt und Aufgrund von veralteten oder mangelhaft erstellten Anforderungskatalogen rückabgewickelt werden muss.
Ein weiteres Szenario kann sein, dass du als Leser dieses Artikels ein Softwareentwickler bist, der sich mit seinem Projekt in einer Sackgasse befindest.
Ganz häufig werden die kleineren Softwareprojekte, welche schief gelaufen sind einfach in Prototypen umbenannt. Verständlich wenn es um die Gesichtswahrung der verantwortlichen geht, jedoch nicht immer zielführend.
Angst ist meist keine gute Motivation für gute Entscheidungen. Gerade bei verteilten, großen Projekten ist es selten die Schuld eines individuellen Softwareentwicklers.
Gerade bei komplexen und internationalen Applikationen werden im Anforderungsmanagement sehr häufig die englischen Begriffe einfach nachgenutzt, um dann von Beteiligten unterschiedlich interpretiert zu werden.
Dann wird gerne versäumt zu erklären warum in der Softwareentwicklung bestimmte Dinge so umgesetzt werden müssen wie vereinbart und nicht anders. Zuerst muss es immer darum gehen zu begreifen was die Software können soll. Man geht stattdessen viel zu schnell in Themen wie Farbe, Form und welche IT-Systeme müssen angebunden werden.
Man geht zu schnell in Details und nimmt sich nicht die Zeit ein MVP (Minimum Viable Produkt) zu entwickeln. Stattdessen legt man sich von Beginn an auf eine Art „eierlegende woll mich Sau“ fest, die wiederum ihren eigenen Rattenschwanz von Problemen mit sich bringt.
Kundenzentrische Softwareentwicklung
Gerade auch bei den großen Unternehmen und auch im öffentlichen Sektor ist es so, dass Software nicht unbedingt für die Kunden entwickelt werden, sondern um bereits vorhandene und teilweise veraltete Prozess in das neue System zu pressen und abzubilden.
Es gibt also eine Menge Mitarbeiter, die bereits an bestimmte Abläufe gewohnt sind und diese sollen jetzt in eine Software eingebaut werden, ohne dabei die Frage in den Mittelpunkt zu stellen: „Was will eigentlich der Kunde?“
Häufig haben Stakeholder größerer Industrieunternehmen nicht den Mut mal loszulassen und den Kunden entscheiden zu lassen welche Funktionen gewollt werden.