Software hat auf den ersten Blick wenig Menschliches, obwohl sie im Leben viel Raum einnimmt und das entweder direkt (PC, Smartphone) oder indirekt in Haushaltsgeräten, Flugzeugen, Autos und der öffentlichen Infrastruktur.
Tatsächlich sind aber Menschen involviert in der Entwicklung und Benutzung von Software und damit Stakeholder mit den unterschiedlichsten Rollen. Sei es als zahlender Kunden, Entwickler, gesetzgebende Institutionen oder sogar Hacker. Wir wollen an dieser Stelle auf die Lieferantenseite mit folgenden Rollen blicken: Entwickler:innen im weiteren Sinn (z. B. Programmierer, SW Architekten, Tester, …), Projektleiter:innen und Vertriebsmitarbeiter:innen.
Menschliche Eigenschaften/Skills
In diesem Artikel soll es um die menschlichen Eigenschaften und nicht um die technischen Skills der Stakeholder im Softwareentwicklungsprozess gehen. Die menschlichen Eigenschaften unter-scheiden wir in Charaktereigenschaften, kulturelle Prägungen und Gefühle.
Charaktereigenschaften, z. B. Entschlussfreudigkeit oder Temperament, sind meistens unveränderbar. Sie lassen sich „von außen“ nicht beeinflussen. Neigt eine Person beispielsweise charakterlich zur Vermeidung von Entscheidungen, sollte sie besser keine Tätigkeit haben, wo sie permanent Entscheidungsaufgaben auf dem Tisch hat. Eine ungeduldige Person mit starkem Temperament ist wiederum bei Aufgaben mit viel Bürokratie und Formalitäten fehl am Platz. Eine gute Projektplanung bzw. Teamleitung sollte die unterschiedlichen Charaktere berücksichtigen.
Kulturelle Prüfungen entstehen durch das kulturelle Umfeld der Personen: Ihre Städte oder Länder, ihre Familien, ihren Freundeskreis und die Unternehmen, für die sie arbeiten. Das kulturelle Umfeld belohnt/sanktioniert Handlungen und Haltungen. Die Neigung zu Eigeninitiative kann in einem dynamischen Unternehmen ein notwendiger Beitrag zum Erfolg sein, in einem hierarchisch geprägten, aber negativ auffallen. Wenn sich die prägenden Umstände ändern, ändert sich auch langsam die kulturelle Pädagogik. Wer von einem Start-up zu einem globalen Player wechselt, steht erst einmal einer anderen Unternehmenskultur gegenüber und wird sie mit der Zeit aufsaugen – hoffentlich.
Gefühle sind zeitlich begrenzt, meist auf aktuelle Ereignisse zurückzuführen und daher durch andere Personen beeinflussbar. Gefühle wie Langeweile, Neid oder Angst beeinträchtigen die Produktivität eines Teams. Hat ein Mitarbeiter Angst, sein Pensum nicht zu schaffen, dann sollte die Teamleitung den Grund für die Angst erkennen und beseitigen, ebenso wenn Mitarbeiter:innen neidisch oder wütend sind. Worauf sind sie neidisch oder wütend?
Menschliche Faktoren und Aufgaben im Projekt
In der Gestaltung eines Teams bzw. eines Projekts sollten von vornherein menschliche Faktoren berücksichtigt werden. Dies zeigt sich in unterschiedlichen Bereichen:
Rollenverteilung
Bei der Rollenverteilung spielen neben technischen Skills menschliche Eigenschaften entscheidend. Von ihnen hängt die Eignung für Rollen ab:
Unangenehme oder scheinbar überflüssige Aufgaben, wie die Erstellung von Statistiken oder Meetingprotokollen, sollten grundsätzlich rotieren.
Planung und Planverfolgung
Wo ein Plan ist, muss er auch regelmäßig auf Soll/Ist geprüft werden. Die Planverfolgung sollte auch die menschlichen Faktoren einbeziehen. Wo laufen Mensch und Rolle auseinander? Wo werden Neid oder Unfairness empfunden? Wo drohen die Risiken „Perfektionismus“, „Selbstüberschätzung“ und „TEAM“, die Projektziele zu gefährden?
Kommunikation
In der menschlichen Kommunikation spielt das „Wie“ die entscheidende Rolle. Ein Ziel der Kommunikation in Projektmeetings ist die Motivation der Mitarbeiter:innen und das Verhindern „negativer“ Gefühle. Haben Teammitglieder Angst, wenn sie unvollständige Ergebnisse liefern oder Verzug melden, dann werden sie das vermeiden. Was erst recht Probleme schafft. Unvollständige Ergebnisse sind besser als keine. Verzug rechtzeitig zu melden ist besser als keine Meldung. Die Projektleitung muss die Gewissheit vermitteln, dass kein Grund zur Angst besteht. Auch andere „negative“ Gefühle sollten vermieden werden. Ein Lob vor der Runde ist in Ordnung, aber extremes Lob oder Heruntermachen können Neid oder empfundene Unfairness hervorrufen. Aufbau von menschlichen Skills Fehlen Kolleg:innen technische Skills, dann kann der Arbeitgeber sie weiterbilden (lassen). Das Gleiche sollte auch für die menschlichen Skills gelten. Für Kollegen mit Kundenkontakt (Projektleiter, Requirements Engineer, Vertrieb) ist ein Kurs in Kommunikationstechniken die richtige Entscheidung.
Beispiel: “Make or Buy”
Ein Unternehmen möchte ein Software-intensives System entwickeln und hat dabei mehrere Möglichkeiten: Selber machen, beauftragen oder etwas dazwischen. Auch hier spielen menschliche Faktoren eine Rolle.
Unternehmensinterne Entwicklung
Verfügt das Technologieunternehmen über eigene Software Development Center, dann können diese die Entwicklung übernehmen. Die Mitarbeiter:innen haben meistens die gemeinsame Firmenkultur, befolgen gleiche Prozesse und haben die gleichen Vorgesetzten oder Projektleiter. Sie sind ein eingespieltes Team mit viel Routine. Hier sehen wir auch menschliche Faktoren, die sich negativ bemerkbar machen können. Bei einem Team ohne große Änderungen an Personal und Projekten kann eine gewisse Abgrenzung zu neuen Technologien, Prozessen, Produkten entstehen („Wir haben das schon immer so gemacht.“). Ein potenzielles Problem in der schnelllebigen SW-Branche. Wegen dieser Routine könnten bei Kollegen andererseits Langeweile oder Unterforderung entstehen („Immer das Gleiche!“). Beides kann die Projektarbeit negativ beeinflussen.
Standortübergreifende Entwicklung
Global Player können für die Entwicklung meistens auf mehrere Standorte zurückgreifen, auch auf Low-Cost Standorte. Bei verteilter Entwicklung sind unterschiedliche Zeitzonen, Sprache und Kultur zu beachten. Wer in Deutschland mit Partnern aus Fern-Ost zusammenarbeitet und Online Regeltermine auf den Nachmittag legt, greift diese Kollegen an. Die Bereitschaft, nach 20 Uhr Ortszeit ein Meeting zu beginnen, hält sich in Grenzen. Also besser am frühen Morgen, was die Kollegen in Deutschland vielleicht stört. Unverständnis auf beiden Seiten entsteht bei unterschiedlichen Entwicklungskulturen, wenn deutsche Gründlichkeit auf ein flexibles Arbeitsmodell trifft. Bei Großunternehmen kommt ein weiterer Faktor dazu. Das Outsourcing/Offshoring an Low-Cost-Standorte kann den Betriebsrat auf den Plan rufen, der hier den Verlust von Wohlstand, Arbeitsplätzen und eigenem Einfluss sieht. Das kann bei den Mitarbeiter:innen im Stammhaus ein Gefühl von Ungerechtigkeit hervorrufen. AM Low Cost Standort entsteht umgekehrt das gleiche Gefühl: “Wir erledigen die gleiche Arbeit, aber für weniger Geld!”. Das Gegenargument vom Stammhaus: “Wir brauchen auch höhere Gehälter, weil bei uns das Leben teurer ist.” Liegt hier ein menschliches Konfliktpotenzial vor, welches den Projektfortschritt beeinträchtigen könnte? Urteilen Sie selbst.
Beauftragung einer externen Firma
Wird die Entwicklung bei einer oder mehr Firmen beauftragt, dann sind, wie bei jeder Auftragsvergabe, klare Absprachen, z. B. „Definition of ‚Done‘“ notwendig. Wann gilt ein SW-Paket als „done“? Wenn alle Requirements umgesetzt sind? Wenn alle Tests grün sind? In dem Fall wäre es ratsam, nicht zu viele Tests zu schreiben. Der Auftraggeber kann die Entwicklung an zwei oder mehrere Unternehmen vergeben, z. B. Feindesign, Programmierung, Integration an Zulieferer A und den Test an dessen Konkurrenten, Zulieferer B. Damit kann er die Konkurrenz von A und B ausnutzen. A wird versuchen, möglichst fehlerfreie Software zu liefern und B wird versuchen, möglichst viele Fehler zu finden. Der Auftraggeber profitiert hier von der Konkurrenz zwischen A und B und damit vom menschlichen Ehrgeiz der Kollegen der Zulieferer A und B.
Verstärkung der eigenen Abteilungen durch externe Mitarbeiter:innen.
Das Unternehmen entscheidet, die eigene Softwareabteilung durch externe Entwickler zu verstärken, z. B. im Rahmen der Arbeitnehmerüberlassung (AÜ). Bei spürbarem Gehaltsgefälle oder unterschiedlichen Wochenarbeitszeiten kann es zum gleichen Problem kommen, wie beim oben genannten Konflikt Stammhaus/Low Cost Standort. Hier bei der AÜ spielen weitere Faktoren eine Rolle: Die Externen haben meistens einen Zusatz wie “extern” in den E-Mail-Adressen. Sie tragen andere Firmenausweise und haben Schilder mit der Aufschrift “External” auf dem Schreibtisch. Weitere Unterschiede können sein: weniger Benefits (subventionierte Kantine, Zuschuss für ÖPNV-Ticket, Zugang zum Firmenparkplatz). Externe sind als “Andere” sichtbar und sollten sich dessen bewusst sein. Externe sind außerdem Diener zweier Herren, des Kunden und des Arbeitgebers. Der Kunde erwartet “gute Arbeit für sein Geld”, der Auftragnehmer “gutes Geld für die Arbeit der AÜ Kollegen”. Externe Mitarbeiter:innen müssen darauf achten, beide Interessen im Lot zu halten: Gute Arbeit abliefern und dabei das Budget einhalten. Bei den üblichen Fiebereisprojekten trägt der Verleiher das größere finanzielle Risiko. Externe stehen nicht nur unter Beobachtung von Vorgesetzten oder Projektleitern, sondern auch von internen Mitarbeiter:innen. Externe Mitarbeiter:innen werden weniger als Individuum und mehr als Aushängeschild ihres Arbeitgebers gesehen. Ihre Leistung hat Auswirkung auf die Reputation des Verleihers. Benötigen die Externen eine Entscheidung (Alternative A oder B), dann lautet die falsche Frage: “Was soll ich machen? A oder B?”. Das klingt nach Unwissen und wenig Entschlusskraft. Fragt er dagegen: “Herr PL, ich habe mich mit den Alternativen A und B beschäftigt. Für die Alternative A sprechen diese Argumente, für B dagegen jene. Ich brauche eine Entscheidung von Ihnen”, klingt das nach Kompetenz und Kundenorientierung. Zusätzlich befinden sich Externe auch in einer Vertriebsposition. Augen und Ohren müssen offen-gehalten werden für Folgeaufträge. Hat der Kunde ein Problem, könnte sich daraus ein Auftrag entwickeln. Der Externe ist also mehr als Entwickler. Er ist auch Vertriebler und PL in eigener Sache und sollte über die entsprechenden menschlichen Faktoren (Kommunikation, Zeitmanagement, wirtschaftliches Denken) verfügen.
Fazit
Wie das Beispiel und die Übersicht zeigt, sind menschliche Faktoren entscheidend für den gesamten Lebenszyklus von Software – von der Beauftragung und Entwicklung über die Nutzung bis hin zur Bewertung ihres Werts. Denn Software soll letztlich den Menschen dienen. Auch wenn sie auf „unmenschlichen“ Geräten wie Computern, Servern, Smartphones oder Steuergeräten läuft, ist ihr eigentlicher Nutzen immer auf den Menschen ausgerichtet. Auch die Arbeit an und mit Software funktioniert trotz rasanter Entwicklungen in Digitalisierung und Künstlicher Intelligenz nicht ohne den Menschen. Schließlich bestimmt auch der menschliche Bedarf, ob und welche Software es gibt. Technologische Fortschritte sind stets an die Bedürfnisse und Ziele der Menschen geknüpft.
Über Stefan Meerwald:
Stefan Meerwald (Dipl.Inf.) ist Software Engineer und Trainer bei Alten GmbH Deutschland. Er hat Erfahrung in den Bereichen Telekommunikation, Defense Systems, Aerospace und Auto-Motive mit Schwerpunkt Requirements Engineering. Er ist für die BMW AG Speaker der Autosar Arbeitsgruppe WG-SAF, die sich mit funktionaler Sicherheit in Fahrzeugen befasst, z. B. sichere Kommunikation, Laufzeitüberwachung und Safety Architektur.
