Nadelöhr Software-Entwickler – Methoden und Hingabe

Wie erwähnt, mache ich mir zur Zeit zusammen Herrn Eßers Gedanken zu der Frage, was man aus der Sicht unserer jeweiligen Profession gegen den Mangel von Ingenieuren tun kann.

Herr Eßers betreut den Blog der Firma Apliki, über die ich hier schon früher berichtet habe.

Auf seinem Blog hat er eine Tabelle begonnen, die etwas Ordnung in das Brainstorming bringt (siehe „weiterführende Informationen“).

Nadelöhr Software-Entwickler

In seinem Blog hat Herr Eßers eine Tabelle begonnen, die die identifizierten Maßnahmen und Ideen im Detail auflistet und bewertet. Dies sind die folgenden Themen (hier nur Schlagworte):

  • Klare Formulierung von Anforderungen
  • Sicherstellen, daß Anforderungen ein Kundenproblem lösen
  • Automatisiertes Testen
  • Mitarbeiterförderung
  • Softwareentwickler unterstützen durch psychologisch versierte Projektteilnehmer
  • Usability Tests
  • Produktvisionen

Mir fallen hierzu Ergänzungen ein, die ich heute kurz umreißen will. Auf der einen Seite handelt es sich um Maßnahmen, die i.w.S dafür sorgen, daß Software Entwickler effizient arbeiten können.

Auf der anderen Seite sind es Ideen, die überhaupt dafür sorgen, daß es genügend Software-Entwickler gibt.

Der effiziente Entwickler

Ein Volkswirt würde sagen: Eine Möglichkeit, die einen dabei hilft, mit dem knappen Gut („Software-Entwickler“) umzugehen ist es, dafür zu sorgen dass man dieses „Gut“ möglichst effizient einsetzt.

Hierfür dienen die folgenden Ideen.

Mockups und Designguidelines

In der Praxis treten zwei Effizienzkiller immer wieder auf:

  • Man redet zu spät, und „ungeeignet“ mit Kunden und kommt daher zu spät an die Stelle ab der man versteht, welche Merkmale eines Produktes wirklich wichtig sind.
  • Man denkt zu viel über Designentscheidungen im User Interface nach, die eigentlich gegeben sein sollten.

Mockups (Modelle) sind sehr gut geeignet, um frühzeitig, und produktiv mit Kunden sprechen zu können. Solche Modelle sollten so einfach sein, daß man sie zur Not auch wegwerfen will, wenn sie sich als falsch erweisen. Hierbei sollten Mockups in eine Methode eingebettet werden.

Usability-Untersuchungen sind wichtig. Genau so wichtig ist es aber, dafür zu sorgen, daß einmal getroffene Designentscheidungen überall (gleichartig), und ohne große Diskussion umgesetzt werden.

Hierbei sind Guidelines und „Normen“ meiner Meinung nach sehr wichtig, und sind „Frameworks“ ein approbates Mittel, um die Umsetzung zu vereinfachen.

Designthinking

Bei dem Designthinking handelt es sich um eine sehr mächtige Methode, die einem Team aus unterschiedlichen Experten dabei hilft, die einzelnen Elemente des Entwurfsprozesses so zu organisieren, daß sie ineinandergreifen. Eine solche Methode ist sehr wichtig, um effizient arbeiten zu können, und sollte überall zum Standard werden.

Insbesondere die Mockups spielen in dieser Methode eine wichtige Rolle. Das Designthinking selbst macht nicht nur Spass, sondern erlaubt sehr schnelle Iterationen – viel schneller und viel einfacher, als dies mit herkömmlichen Methoden möglich wäre. Die Methode ist damit „effizient“.

Ausbildung

Die bisherigen Ansätze waren „nachfrageorientiert“, d.h darauf ausgerichtet, die Ingenieure gut einzusetzen, über die man verfügt. Ein anderer Ansatz wäre dafür zu sorgen, daß sich mehr Leute für technische Ausbildungsgänge interessieren, weil sie die Attraktivität der Berufe wahrnehmen.

Entwicklungsprojekte = Modenschau

Viele Themen in der Produktentwicklung sind überaus spannend, und machen Spass. Vielleicht sind sie nicht immer so glamourös wie eine Modenschau, oder nicht immer so aufregend wie eine Runde im Formel I Wagen – aber nahe dran.

Wer gerne mit Menschen umgeht, offen für neue Entwicklungen ist, und vielleicht noch gerne designorientiert arbeitet, findet hier viele spannende Projekte – Ausbilden lohnt sich daher.

Entwicklungsfähige Ausbildung

In einem weiteren Artikel bin ich auf einen konkreten Studiengang eingegangen (siehe „weiterführende Informationen“).

Dieser Artikel macht deutlich, daß die Berufsfelder, die die Fachbereiche der Technik allgemein zu bieten haben, weiterentwicklungsfähig sind. Hierbei kann man sowohl als Experte arbeiten, wie auch in einer Hierarchie aufsteigen.

Das beiliegende Video von Herrn Gunter Dueck gibt auf unterhaltsame Art und Weise einen Einblick in diese Praxis.

Weiterführende Informationen

Das Original dieses Artikels ist auf Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

One Response to “Nadelöhr Software-Entwickler – Methoden und Hingabe”

  1. Steffen sagt:

    Ihre Anregungen zu Mockups und Designguidelines habe ich unter dem Stichwort Artefakte mitgedacht. Diese und weitere Gedanken habe ich wie angekündigt aus Sicht effizienter Kommunikation fortgeführt: http://www.apliki.de/usability-engineering/mit-7x-kommunikation-dem-nadelohr-software-entwickler-begegnen/