Ein neues Projekt kommt nicht vom Fleck. Kleine Anpassungen sind zu teuer. Zum wiederholten Mal wird zu spät geliefert. Zu viele Beteiligte mit unklaren Kompetenzen. Kommt Ihnen das bekannt vor? Ein paar Tipps zur Abhilfe bei Ärger mit Software-Lieferanten.
Neue Projekte
Kommt ein neues Projekt nicht vom Fleck, gibt es verschiedene Gründe:
- Die Anforderungen sind nicht klar, unvollständig oder erst teilweise bekannt.
- Offeriert wird ein Ferrari, auch wenn ein VW Golf reicht.
- Zu komplizierter Prozessablauf mit zu vielen Diskussionsschlaufen.
- Zu hohe Kosten.
- Zu starker Fokus auf künftige Erweiterungen.
Beim 1. Punkt ist der Software-Lieferant in der Pflicht: Er muss nachfragen, damit er eine Anforderungsspezifikation sowie einen Mockup / Prototyp als Diskussionsgrundlage.
Jeder Software-Lieferant versucht, so effizient wie möglich zu sein. Werden verschiedene Anwendungen entwickelt, die eine gemeinsame Funktionalität haben, ist es sinnvoll, eine sog. Plattform zu entwickeln. Eine neue Anwendung ‚bekommt‘ automatisch die gesamte Funktionalität der Plattform. Auf diese Weise können neue Anwendungen schneller entwickelt werden.
Die Gefahr vom Ferrari entsteht, wenn der Lieferant auf einer solchen Plattform aufbaut oder aufbauen muss. Wenn der Kunde nur einen Bruchteil der gesamten Funktionalität benötigt, bezahlt er dennoch den vollen Preis. Beim Einsatz einer proprietären Plattform ist es für den Kunden praktisch unmöglich, den Quellcode zu übernehmen und die Anwendung bei einem anderen Lieferanten weiter zu entwickeln. Ein späterer Wechsel des Lieferanten heisst, die Anwendung von Grund auf neu zu entwickeln.
Die Projektverantwortlichen des Lieferanten koordinieren die Software-Entwicklung. Sie müssen Einiges von IT resp. Software-Entwicklung verstehen. Sonst entsteht ein grosser Informationsverlust. Es ist wie beim Telefonspiel: Der Input beim ersten Glied (Projektleiter Kunde unterscheidet sich stark zum Output des letzten Glieds (Entwickler Lieferant). Jedes Glied, das weggelassen werden kann, reduziert den Informationsverlust.
Zu hohe Kosten entstehen, wenn ein Ferrari anstelle eines VW Golf geliefert wird. Oder die Entwickler etwas Falsches entwickeln, weil der Output beim letzten Glied falsch war. Hier hilft ein Hinterfragen der eingesetzten Produkte / Frameworks beim Lieferanten.
Sinnvoll ist es, künftige Erweiterungen von Anfang an in der Architektur zu berücksichtigen. Zu viel Gewicht sollte dennoch nicht beigemessen werden. Bei einem neuen Projekt ist es oft schwierig, mögliche Erweiterungen zu kennen.
Bestehende Projekte
Bei Ärger in einem bestehenden Projekt respektive einer existierenden Anwendung ist das primäre Ziel, mit dem Lieferanten einen Weg zu finden, um die Probleme zu lösen. Das ist am Einfachsten und Effizientesten. Ein Wechsel ist immer mit zusätzlichen Kosten und Zeitverlust verbunden und erst der letzte Ausweg.
Häufigste Probleme sind:
- Offerierte Kosten für die Weiterentwicklung sind zu hoch.
- Lieferverzug oder zu lange Lieferzeit.
Versteht der Kunde wenig von IT, lohnt sich der Einbezug eines Spezialisten in den Bereichen Architektur und Entwicklung. So können beim Lieferanten die richtigen Fragen gestellt werden. Es ist ein Gespräch auf Augenhöhe. Der Lieferant merkt, dass seine Aussagen und Offerten kritisch hinterfragt werden. Es ist vergleichbar mit dem Einholen einer ärztlichen Zweitmeinung.
Der Quellcode gehört dem Kunde. Ein Code-Review seitens Kunde hat folgende Vorteile:
- Der Lieferant weiss, dass er keine überhöhten Aufwände offerieren kann.
- Der Kunde hat einen Überblick über die Architektur und die Qualität der Software. Bei grösseren Mängeln ist ein Refactoring (Überarbeitung der Software bei gleicher Funktionalität) sinnvoll, besonders bei einem langfristigen Projekt.
- Schwachstellen können behoben werden und künftige Lieferungen sind schneller und günstiger.
Um die Kosten für den Review so gering wie möglich zu halten, reicht meist eine grobe Übersicht.
Zusammenfassung
Sie haben folgende Möglichkeiten, Termine und Kosten ihres Software-Lieferanten in den Griff zu bekommen:
- Klare Definition der Anforderungen, damit der Lieferant weiss, was er machen muss.
- So wenig Ansprechpersonen wie möglich, damit die ursprüngliche Information möglichst unverändert bleibt.
- Hinterfragen der eingesetzten Produkte / Frameworks, falls ein Lieferantenwechsel geplant ist.
- Beizug eines Software-Spezialisten, um die richtigen Fragen zu stellen.
- Durchführung eines Code-Reviews, um den Druck auf den Lieferanten zu erhöhen und sich einen Überblick über die Software-Qualität zu beschaffen.
