Wie man 50.000 Euro Projektkosten einspart

Machen wir uns nichts vor: Wir haben 2014 und die Tagessätze für Berater, Softwareentwickler und dergleichen sind nicht mehr dieselben wie noch vor zehn Jahren. Auch im Großkundensegment sind Tagesätze von deutlich unter 1.000 Euro mittlerweile Gang und Gebe. Die Ursachen hierfür sind vielfältig und liegen nicht allein darin begründet, dass Zwischenhändler, Subgeschäft und Rahmenverträge die Margen auf nicht mehr nur ein Unternehmen verteilen. Häufig sind es auch schlicht die Kosten, die so unverhältnismäßig gestiegen sind, dass der Kunde knapper kalkulieren muss, damit sich ein Projekt rechtfertigen und damit auch beauftragen lässt.

Gestiegene Komplexität

Um Beispiele aus der Windows Welt und im Speziellen der Softwareentwicklung aufzugreifen: Früher gab es zwar weniger Auswahlmöglichkeiten, dafür war die Welt aber auch deutlich weniger komplex. Es gab Windows Forms für clientbasierte Anwendungen mit Benutzeroberflächen und ASP.NET für den Browser. Natürlich gab es auch zu der Zeit bereits Hersteller von Drittlösungen, die das .NET Framework für diese Plattformen ergänzten, aber im Wesentlichen ließ sich mit Boardmitteln bereits fast alles umsetzen. Parallel existierte noch die alte Welt der Visual Basic 6 Entwickler, die ebenfalls mehr oder weniger komfortabel Lösungen auch ohne Informatikstudium bereitstellen konnten (wir sprechen hier noch nicht über Evolvierbarkeit & Co… das kam erst später).

Heute gibt es allein in der Windows Welt nicht mehr nur Windows Forms und ASP.NET. Hinzugekommen sind u.a. Silverlight, WPF, ASP.NET MVC, jQuery, HTML5, nicht zu vergessen die SharePoint Apps, Office Apps, Windows Store Apps, Windows Phone Apps und sogar die guten alten nativen MFC Anwendungen feiern ein Comeback. Ein Trend, der hierbei sichtbar wird: Die Anwendungen werden mehr und mehr ins Internet verlagert und seit neuestem setzt sich auch die Anforderung durch, dass sie möglichst plattformunabhängig funktionieren müssen. Der Begriff BYOD (bring your own device) hat sich zwar – so scheint es auf den ersten Blick – als Rohrkrepierer erwiesen, trifft uns nun aber von hinten wie ein Bumerang: Schließlich wollen Kunden die Anwendungen meist auf allen Plattformen umgesetzt haben.

Gestiegene Kosten

Immer mehr SDKs und APIs ermöglichen die Entwicklung eben solcher Multi-Device Apps, was aber ebenfalls auffällt, ist, dass immer mehr gewohnte Standardkomponenten aus den Boardmitteln verschwinden. Ein Beispiel: Sog. Line of Business (LOB) Anwendungen drehen sich i.d.R. immer um das Verwalten von Stammdaten. Hierbei werden Informationen erfasst, gespeichert und weiterverarbeitet. Im Zentrum steht dabei meist die tabellarische Darstellung der Daten.

Genügt dazu folgende Oberflächengestaltung aus?

image

 

In den meisten Spezifikationen sehen die ersten Roh-Entwürfe tabellarischer Darstellungen tatsächlich so oder so ähnlich aus.

Hier ein Gegenbeispiel:

image

 

Was sich hieraus erkennen lassen sollte sind folgende Funktionen:

  • Gruppierung (hier z.B. nach der Stadt)
  • Sortierung
  • Inline-Bearbeitung (hier z.B. zu erkennen an der TextBox in der Spalte “Name”)
  • Filterung (hier z.B. nach Datum; möglich wären auch komplexe Filter wie beispielsweise Von/Bis/Enthält/Enthält Nicht/Kleiner/Größer/etc.)
  • Paging (bei extrem vielen Einträgen evtl. sinnvoll)
  • Vertikales Scrolling (ob Scrolling UND Paging gleichzeitig sinnvoll sind, darüber lässt sich streiten)
  • Darstellung von Boolean-Werten (hier: Aktiv) als CheckBox
  • Farbliche Unterscheidung (in diesem Fall unbekannt, ob bei der Selektion, aufgrund fachlicher Kriterien oder einfach nur beim Drüberfahren mit der Maus)

Kundenprojekte laufen hier Gefahr, in diese Falle zu tappen: Ohne die Abstimmung mit denjenigen, die die Anforderungen letzten Endes umsetzen (die Entwickler) gelangen Darstellungen wie die zuerst abgebildete in die Spezifikation. Während des Projektes aber kristallisiert sich i.d.R. immer mehr die zweite Abbildung heraus. Dass es sich bei der Umsetzung um eine komplexe und umfangreiche Entwicklung eines Steuerelements handelt (das es so übrigens weder in HTML5, noch JavaScript, Windows Forms oder ASP.NET MVC gibt), steht außer Frage.

Und so steigen die Projektkosten aufgrund der Entwicklung von Steuerelementen problemlos (und exponentiell) um das x-fache. Denn zu der reinen Umsetzung der Anforderungen kommen Fragen nach Wartung, Dokumentation, Plattformunabhängigkeit und vermutlich auch Auslagerung in eigene Bibliotheken für den projektübergreifenden Einsatz.

Selbst im simpelsten Fall wäre es nicht ungewöhnlich für ein Gedankenspiel anzunehmen, zwei Entwickler würden 50 Projekttage mit der Implementierung eines einfachen Tabellen-Steuerelementes für eine ASP.NET MVC Web-Anwendung benötigen, das einen Teil der oben beschriebenen Funktionen implementiert. Weiterhin angenommen, ein Projekttag kostet pro externem Entwickler um die 500 Euro (was nicht viel ist), hat den Kunden dieses Control nun etwa 50.000,00 Euro gekostet. Folgekosten nicht eingerechnet (Bugfixing, Support, etc.)

Kosten einsparen

Wir versuchen, unseren Kunden diese Zusammenhänge wo es geht zu vermitteln und neben der Softwareentwicklung selbst auch beratend in den Projekten zu unterstützen. Natürlich sind auch wir in der Lage, spezifische Anforderungen in Form oben beschriebener Controls umzusetzen und freuen uns über entsprechende Aufträge. Allerdings werden die meisten unserer Projekte eher zentral durch die Umsetzung fachlicher Anforderungen bestimmt. Der Rest ist Mittel zum Zweck.

Daher:

Erfinde nicht das Rad neu,… es sei denn, Du willst etwas über Räder lernen.

Soll heißen: Falls man nicht gerade ein Produkthersteller ist, der sich auf die Entwicklung von Steuerelementen spezialisiert hat, oder Anforderungen hat, die schlicht von keinem solchen umgesetzt werden, dann gibt es keinen vernünftigen Grund, die Kosten für die Entwicklung derartiger Basiskomponenten selbst zu tragen, geschweige denn, externe Entwickler damit zu beauftragen.

Es gibt eine große Anzahl von Herstellern, die bereits Produkte vermarkten, die nicht nur über umfangreiche Unterstützung verschiedenster Plattformen verfügen, sondern auch entsprechenden Support mitbringen und umfassende Dokumentationen. Schließlich leben sie davon. Nach einem Vergleich zwischen den Kosten für Einzelplatz, Mehrfach- oder Firmenlizenzen mit den möglichen Kosten, die bei einer Eigenentwicklung entstehen können, lässt sich die Erkenntnis, dass der Preis in keinem Verhältnis zum Nutzen steht, nur noch schwer abstreiten.

Sinnvoller ist es also, zum Projektstart genaue Überlegungen hinsichtlich der UI-Anforderungen anzustellen, dabei die Softwareentwickler und deren Kompetenzen einzubeziehen und im Anschluss daran ganz regulär unterschiedliche Frameworks zu evaluieren, die einer Entscheidungsmatrix nach passen könnten. Selbst die Anpassung der eigenen Anforderungen an das dann ausgewählte Zielframework (falls dieses nicht alle Kriterien erfüllt) ist in den meisten Fällen noch immer sinnvoller, als stattdessen den Eigenbau zu bevorzugen.

Fazit

Wenn die Antwort auf folgende Fragen Ja lautet, spricht das für die Entwicklung eigener Steuerelemente:

  • Ist das Ziel, die Steuerelemente an andere Unternehmen zu lizenzieren?
  • Gibt es keine Steuerelemente von Drittherstellern, die die (kritischen) Anforderungen unterstützen?
  • Ist geplant, unternehmenseigene Bibliotheken langfristig zu entwickeln und in jedem Fall unabhängig von Drittherstellern zu sein?

Wenn die Antwort auf folgende Fragen Ja lautet, spricht das gegen die Entwicklung eigener Steuerelemente:

  • Handelt es sich bei den Anforderungen weitestgehend um Standards?
  • Liegt der zentrale Fokus in der Implementierung fachlicher Anwendungen?
  • Ist Multi-Plattformfähigkeit ein Thema?

Falls Sie an einem Punkt sind, an dem Sie sich entscheiden müssen, ob sie in den Erwerb von Lizenzen eines Drittherstellers investieren, oder lieber selbst Hand anlegen und dabei Unterstützung benötigen, sprechen Sie uns bitte an.

Sehr gerne helfen wir Ihnen bei der Entscheidung und stehen auch für die Evaluation möglicher Lösungen zur Verfügung. Wir verkaufen weder Lizenzen noch verdienen wir daran, kennen dafür aber verschiedenste Frameworks, haben Experten im Requirements Engineering, der Softwareentwicklung und dem Lizenz-Management. Damit sind wir der richtige Ansprechpartner für Sie, um nachhaltig Ihre Projektkosten zu optimieren und die Softwareentwicklung mit hoher Effizienz auf den Kern Ihrer Anforderungen zu lenken: Dem Bau von Fahrzeugen,… ohne zuvor das Rad neu erfinden zu müssen.

Pingbacks and trackbacks (1)+

Comments are closed

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS