Bestehende Formen, die gemeinsame Arbeit zwischen einem Softwareentwicklungs-Dienstleister und dessen Auftraggeber zu organisieren, fangen die unterschiedlichen Interessen der Beteiligten nur noch bedingt ein. Sie funktionierten besser in einer Zeit, in der Softwareentwicklung ausschließlich ein Thema für die IT-Abteilung war. Und in der technologische Innovationszyklen eher in Jahren als Wochen gemessen wurden.
Foto: goodluz - shutterstock.com
IT-Dienstleistungsverträge - Status Quo
Am Anfang ist selten ganz klar, was am Ende herauskommen soll. Und am Ende ist es dann nicht das, was am Anfang eigentlich gewünscht war. Dies beschreibt überspitzt die paradoxe Situation in Softwareentwicklungs-Projekten mit IT-Dienstleistern. Auf dem Markt etablierten sich die folgenden zwei Arten der Vertragsausgestaltung, um dieser Ausgangslage Herr zu werden:
Abrechnung nach Times and Material (TxM)
Berechnung eines Festpreises
Beide Varianten funktionieren in bestimmten Projektkonstellationen gut. Aber beide können auch Probleme mit sich bringen.
Wenn ein Dienstleister unter TxM-Bedingungen jede geleistete Stunde in Rechnung stellt, kann dies eine ungünstige Anreizstruktur schaffen. Statt möglichst effizient „schlanke“ Software zu entwickeln, ist die Versuchung groß, hier und da noch Funktionen zu ergänzen, gelegentlich eine Extrarunde zu drehen und vorhandene Spielräume auszuschöpfen. Am Ende können dann dann „fette“ Software, überzogene Budgets und ein unzufriedener Kunde stehen.
Softwareprojekte zum Festpreis
Festpreisprojekte verhindern, dass Budgets aus dem Ruder laufen. Schließlich sind die Kosten gedeckelt. Aber – und das kann man kaum genug betonen – das Schaffen von exakten Voraussetzungen für Festpreise ist bei komplexeren Projekten schwer bis unmöglich. Denn in der Praxis sind die Anforderungen an die neue Software nur selten wirklich zu 100 Prozent definierbar. Dies hat drei Gründe:
Softwareprojekte haben häufig das Ziel, Informationssysteme zu entwickeln. Solche Informationssysteme sind sogenannte soziotechnische Systeme. Das bedeutet, sie verfügen über Schnittstellen zu Menschen. Entsprechend enden sie nicht am Bildschirm, sondern an der hinteren Schädeldecke des Anwenders. Aus diesem Grund lassen sich solche Systeme vorab nicht vollständig beschreiben – zumindest nicht, ohne absurd hohe Kosten in Kauf zu nehmen.
Entwicklungsprozesse für Informationssysteme sind erkenntnisgetriebene Prozesse. Neues Wissen über Einsatzszenarien und -möglichkeiten entsteht, während das Projektteam gemeinsam an Lösungen arbeitet. Daraus ergeben sich im Laufe der Entwicklung zwangsläufig neue Anforderungen.
Auf Internet folgt Cloud, folgt Mobile, folgt Künstliche Intelligenz (KI): Der Wandel beschleunigt sich. Diese Phase der technologischen Verdichtung schlägt unmittelbar auf Softwareentwicklungs-Projekte durch. Denn Anwendern fällt es immer schwerer, lösungsbezogene Anforderungen zu formulieren. Ihnen mangelt es häufig an der Sachkenntnis, um die Möglichkeiten neuer Technologien richtig bewerten zu können.
All dies kann für Interpretationsspielräume, Unschärfen und Doppeldeutigkeiten beim Erfassen der Anforderungen sorgen, die der Grundstein für Probleme im späteren Projekt sein können. Beispiele dafür sind weitere Spezifikationen, die während des laufenden Projektes neu aufgenommen werden oder eine Änderung der Priorisierung bestehender Spezifikationen. Entsprechend müssen die Verantwortlichen die Rahmenbedingungen nachjustieren. Was als vermeintlich klar definiertes Projekt mit festem Budget begann, zerfasert in Änderungsorgien. Dies engt die Einsatzmöglichkeiten von Festpreisprojekten deutlich ein.
- Produkt- & Projektmanager
Ganz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. <br /><br /> Dazu hat auch David Fox von devRant eine Meinung: "Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die 'Besitzer' von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen." - Chefs
Genau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. <br /><br /> "In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben", merkt Fox an. - Recruiter
Softwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden - dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. <br /><br /> David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: "Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe - selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt - etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen." - Dokumentation
Gibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. <br /><br /> An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: "Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation - aber selber machen wollen sie es nicht." - Meetings
Meetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift 'I survived another meeting that should have been an email' erhältlich. - Coworking Spaces
Mit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden - insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen - sagen zumindest die Zahlen von devRant. <br /><br /> David Fox erklärt: "Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten - oder eben das Gegenteil davon." - Kollegen
Selbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. <br /><br /> Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis. - Vorstellungsgespräche
Wenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: <br /><br /> "Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht", so Fox. - Fehler & Bugs
Softwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: <br /><br /> "Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an." - Quality Assurance
Die Quality Assurance (QA) - oder Qualitätssicherung - ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. <br /><br /> "Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten."
Diese Aussagen über Vertrags- und damit Partnerkonstellationen treffen seit Jahr und Tag auf Softwareprojekte zu. Viele gehen glatt oder mit vertretbarem Knirschen über die Bühne. Aber immer wieder reißen sie auch die gesteckten Ziele. Die Wurzel vieler Probleme liegt in den beschriebenen Formen, die Zusammenarbeit zwischen Entwicklungsdienstleister und Auftraggeber zu organisieren. Konstrukte wie TxM oder Festpreisprojekte funktionierten besser in einer Zeit, in denen IT eine Abteilung hinter einer Tür war – und nicht eine der Grundlagen für den Unternehmenserfolg. Diese Zeiten sind vorbei.
Gute Software ist so wichtig wie nie
Die Digitale Transformation bestehender Prozesse zieht sich quer durch alle Branchen. Eine Folge davon ist, dass die fest umrissenen Einsatzgebiete von Software kaum noch erkennbar sind. IT sitzt nicht mehr nur im Keller und sorgt dafür, dass die Leute arbeiten können. IT sitzt mit am Tisch, wenn Entscheider die Weichen für die Zukunft des Unternehmens stellen.
Damit einher geht ein veränderter Umgang mit Technologie in Projekten: Die oben bereits beschriebene technologische Verdichtung mit ihrem hohen Tempo an Innovationen erfordert einen experimentelleren Denkansatz. Schnell auszuprobieren, ob etwas funktioniert, schlägt immer häufiger das konsequente Verfolgen einer langfristigen Planung. Denn die Beteiligten müssen Technologien oder Verfahren bewerten, die es am Anfang eines Projektes vielleicht noch gar nicht gab.
Lesetipp: Agile Projektarbeit richtig orchestrieren
Beispiele für diese Innovatinsgeschwindigkeit sind Oberflächentechnologien: Zu Beginn eines längerfristigen Projektes ist es unmöglich zu entscheiden, welche Ansätze am Ende State of the Art sind. Besonders deutlich tritt diese neue Ungewissheit in Projekten hervor, in denen KI- beziehungsweise Machine Learning-Technologien eine Rolle spielen. Der Erfolg solcher Lösungen steht und fällt mit der Datengrundlage, mit der die Beteiligten arbeiten können. Ob diese Datenbasis ausreicht, um die konkrete Fragestellung mit KI/ML zu lösen, lässt sich im Vorfeld häufig nicht feststellen. Auch hier müssen findige Köpfe herausfinden, was funktioniert und was nicht.
Diese findigen Köpfe sind – unabhängig von konkreten Technologien und Projekten – der entscheidende Erfolgsfaktor. Sie zu finden, an das Unternehmen zu binden und dauerhaft so weiterzubilden, ist eine der zentralen Managementaufgaben. Unternehmen bewegen sich hier in einem schwierigen Umfeld. Der Arbeitsmarkt für IT-Fachkräfte ist angespannt. In kurzer Zeit und in ausreichender Anzahl Experten mit einem bestimmten Fähigkeitsprofil zu finden ist schwer, die Konkurrenz unter Unternehmen groß. Potenzielle Arbeitgeber mit strahlenden Namen mitten in urbanen Zentren haben eine große Sogwirkung. Das gleiche gilt für die Start-up-Szene.
Ein Ausweg aus der angespannten Situation kann das Einbinden von externen Kräften – über IT-Dienstleister oder als Freelancer – in die eigenen Softwareentwicklungs-Projekte sein. Allerdings kann es durchaus eine komplexe Aufgabe sein, die Regeln des Arbeitnehmerüberlassungsgesetzes, die auch im Kontext von IT-Projekten greifen, angemessen in die eigenen Compliance-Prozesse einzubinden.
Technologien, die sich rasant entwickeln, Fachleute, die nur schwer zu finden sind, Vertragsmodelle – TxM oder Festpreisprojekte – die für Unmut sorgen können. In dieser Gemengelage müssen die Verantwortlichen in Unternehmen die Arbeit in Softwareprojekten optimieren. Es gilt, die Kooperation mit Softwareentwicklern in unterschiedlichen Organisationsformen, in unterschiedlichen kommerziellen Ausgestaltungen und das flexible Einbinden von Personal zu koordinieren.
Mal sind es gemeinsame Projekte zwischen internen und externen Beteiligten, mal liegt ein größerer Teil des Risikos beim Dienstleister. Manchmal geht es um das gemeinsame Ausprobieren von Technologien und Konzepten – die schon angesprochene Experimentierfreudigkeit. Und all diese Formen der Zusammenarbeit ändern sich abhängig von Technologien, von Recruiting-Erfolgen und neuen Anforderungen schnell wieder.
Softwareentwicklung auf Augenhöhe
Fast ebenso wichtig, wie eine konkrete Ausprägungen der Zusammenarbeit mit externen Partnern, ist die generelle Geisteshaltung der beiden beteiligten Unternehmen. Sie sitzen in einem Boot – und diese Tatsache ist allen Beteiligten sehr bewusst. Gemeinsam profitieren sie von den Erfolgen der Zusammenarbeit, sie leiden aber auch beide unter Misserfolgen.
Alle sind dem Ziel schlanker und wertschöpfender Software verpflichtet. Dies erreichen die beteiligten Unternehmen beispielsweise durch den geeigneten Mix aus agilen und plangetriebenen Instrumenten in Projekten – Stichwort gezähmte Agilität. Dieser Ansatz erlaubt es Projektpartnern, von den Vorteilen agiler Entwicklung zu profitieren, ohne mögliche Planungsunsicherheiten bezüglich Budgets oder Terminierung in Kauf nehmen zu müssen.
Lesetipp: Value Proposition Design - So finden Entwickler innovative Lösungen für ein Anwenderproblem
Ein IT-Partner sollte nicht nur das technische Wissen einbringen, sondern sich auch in der Branche des Auftraggebers auskennen. Nützliche Software und Konzepte entstehen nur, wenn das Anwendungswissen des Unternehmens in den ganzen Entwicklungsprozess einfließt.
Eine Möglichkeit, einer strategischen Partnerschaft Gestalt zu geben, kann der Aufbau eines Projekthauses sein: Auf Basis einer klar definierten Steuerung kombinieren die Partner hier unter einem Dach verschiedene Einsatzszenarien von agilen Festpreisprojekten bis hin zu Arbeitnehmerüberlassungsmodellen. Ein solches Projekthaus ist nicht nur ein Symbol für den Umfang und die Tiefe gemeinsamer Initiativen. Es kann auch die dauerhafte Verfügbarkeit passender Mitarbeiter aus dem Personalpool des Softwareentwicklungs-Dienstleisters für den Einsatz in laufenden Projekten sichern. (bw)
- Zeitfresser
Mehr als sechs Stunden pro Arbeitswoche verliert jeder Mitarbeiter in kleinen mittelständischen Unternehmen aufgrund mangelhafter oder fehlender Technik. So lautet eines der Ergebnisse einer repräsentativen Umfrage durch OnePoll unter 1.000 Angestellten in Unternehmen mit einer Größe von bis zu hundert Mitarbeitern. Teamleader hat zudem untersucht, bei welchen tagtäglichen Aufgaben Mitarbeiter besonders viel Zeit verlieren.
Mit einem professionellen Projekt- und Rechnungsmanagement samt einer vernünftigen Kommunikationsplattform würden Mittelständler die meiste Zeit einsparen: Vor allem die Abstimmung von Angeboten, Konzepten, oder Verträgen mit Kunden frisst unnötig Zeit. Mehr als ein Viertel der Befragten (26%) sieht ein bis zwei Stunden Einsparpotenzial pro Woche, fast ein Fünftel (19,5%) sogar drei bis fünf Stunden.
Wer über ein professionelles Customer Relationship Management-Tool verfügt kann in der Woche im Schnitt eine Stunde und 20 Minuten einsparen – in 15 Prozent der Unternehmen gar drei bis fünf Stunden.
Weiteres Optimierungspotenzial sehen die Befragten beim Terminmanagement, bei der Zeiterfassung und beim Dateimanagement (jeweils mehr als eine Stunde pro Woche).
Viel Zeit könnten Mittelständler auch einsparen, wenn sie mehr Aufgaben automatisieren würden. Genau ein Drittel der Belegschaft verbringt ein bis zwei Stunden pro Woche damit, Aufgaben manuell zu erledigen, für die es technische Lösungen gäbe.
Fehlende Schnittstellen zwischen Anwendungen kosten fast eben so viel Zeit: 31 Prozent verbringen ein bis zwei Stunden mit dem Übertragen von Daten.
Weil Software nicht nutzerfreundlich genug ist, geht im Schnitt mehr als eine Stunde pro Woche pro Mitarbeiter verloren.
Ebenfalls mehr als eine Stunde könnten Mittelständler einsparen, wenn sie Anwendungen auch mobil bereitstellen würden. „Chefs müssen ja nicht alles auf einmal angehen“, so Jeroen De Wit, CEO von Teamleader. „Wer aber seine Software nach und nach optimiert, kann mehr als einen halben Tag pro Woche herausholen.“