read

Im Spiegel gab es kürzlich einen Artikel über „Architektenhäuser: Besonders - und besonders günstig“. Während des Lesens musste ich das eine oder andere Mal daran denken, dass eigentlich viele Parallelen zur Softwareentwicklung bestehen. Da ich zudem schon lange einmal die mir im Umgang mit den Kunden aufgefallenen Punkte niederschreiben wollte, beschloss ich diesen Artikel zu portieren. Wer also mit dem Gedanken spielt, sich eine Software entwickeln zu lassen und seine persönliche Elbphilharmonie vermeiden möchte, der sollte folgende Dinge berücksichtigen:

1. Konzept aus der Sicht ALLER Nutzerrollen

Würde ich ein Haus bauen wollen, so würde ich mir wahrscheinlich zuallererst Gedanken darüber machen, was ich denn überhaupt bauen möchte. Brauche ich eine Garage, ein Kinderzimmer, ein Bad? Brauche ich mit Kindern zwei Bäder? Brauchen meine Hunde noch ein drittes Bad und mein Trabi eine zweite Garage?

All dieses sind elementare Fragen, die ich mir als Voraussetzung für die Umsetzung meines Hauses stellen muss – und, wenn ich nicht alleine wohnen möchte, das nicht nur von meinen Bedürfnissen ausgehend. Einen Kostenvoranschlag wird mir auf dieser Basis wahrscheinlich trotzdem kein Architekt erstellen können – ihm fehlen schließlich noch die Maße, Materialien und die kleinen aber feinen Besonderheiten. Genauso wäre das sogar bei einer einfachen Webseite: Da die Inhalte normalerweise auch irgendwo eingetragen werden müssen, sollte eben auch berücksichtigt werden, wie z.B. der Editor aussehen soll und ob bestimmte Funktionen (Gästebuch, Forum etc.) wirklich Sinn machen.

2. Entwurf eines Flow-Charts, Mockups oä.

Um – wie bereits erwähnt – einen möglichst genauen Kostenvoranschlag über meine Entwürfe zu bekommen, muss ich meine Überlegungen verschriftlichen. Am besten jedoch fange ich auch grob an zu zeichnen und verknüpfe all die kleinen Details. Wo kann ich welche Informationen erneut verwenden? Benutze ich die gleichen Fenster im ganzen Haus? Dann sollte ich wahrscheinlich auch die gleichen Buttons in der ganzen Software verwenden.

Nun aber erst einmal den Stift zur Seite packen: Um Programmierern einen guten Überblick zu geben sollte man sie mit Flow-Charts oder ähnlichem füttern. Gerade wenn die ersten Informationen bei den Softwareingenieuren eintreffen kann es nicht schaden, wenn sofort Probleme beim logischen Aufbau der Software durch geschulte Augen erkannt werden. Kein seriöser Architekt würde bei einem stümperhaften Grundriss sofort anfangen zu bauen. Planung ist das A und O und der wohl am meisten vernachlässigte Bereich. Ein Beispiel, das ich oft nenne, ist der Pool im Keller: Baue ich ein Haus und beschließe nachträglich im Keller einen Pool zu errichten, wird es deutlich teurer als hätte ich das vorm Baubeginn mit eingeplant. Habe ich nicht einmal einen Keller und möchte dieser ausheben und dann dort einen Pool einbauen, werden die Kosten wahrscheinlich explodieren.

3. Kommunikation über PM-Tools

Stille Post kennt jeder – und wer glaubt, das sei ein Kinderspiel, der täuscht sich gewaltig!

In der Softwareentwicklung sieht man dieses Spiel quasi täglich. Nicht, weil einige Programmierer ggf. andere Sprachen sprechen, nein. Vielmehr dadurch, dass kreuz und quer kommuniziert wird. Es wird angerufen und es werden E-Mails geschrieben. Von einer Person, von einer anderen Person. An eine Person, an mehrere Personen. Zu Thema A, zu Thema B. Und im Zweifel sind alle Personen CC.

Wer seine Wichtigkeit über die Anzahl erhaltener E-Mails pro Tag definiert, der wird voll auf seine Kosten kommen. Derjenige, der aber wirklich etwas erreichen möchte, der wirft die Hände über den Kopf und schreit. Oder er hält sich die Ohren zu und spielt Spielverderber.

Projektmanagementtools gibt es heutzutage wie Sand am Meer. Wir nutzen bei empuxa activeCollab, das wir lokal installieren können und das alle Daten auf unseren Servern speichert. Als SaaS-Lösungen gibt es aber unter anderem noch Basecamp, Quassum, Pivotal Tracker, Podio und gefühlte hundert andere. Auf welches System sich die Personen einigen ist Jacke wie Hose – Hauptsache sie einigen sich schnell.

Erfahrungsgemäß werden die Projekte später erfolgreicher sein, an denen von Anfang an von allen Parteien zentral und strukturiert mitgearbeitet wurde. Mitarbeiter können wechseln oder auf Tickets hinzugebucht werden und trotzdem ist der gesamte Verlauf eines Tickets oder Meilensteins sofort nachvollziehbar. Dateien können zentral abgelegt werden und Diskussionen erreichen die Personen, die wirklich betroffen sind. Benachrichtigungen erfolgen zudem meist über E-Mails.

Zu vergleichen wäre dieser Schritt beim Hausbau wahrscheinlich damit, dass alle Dokumente, Genehmigungen und Rechnungen an einem zentralen Ort aufbewahrt werden und es eine Sprache gibt, in der man sich verständigt. Zugegeben, der Vergleich hinkt ein wenig, nur werden auf dem Bau nicht so viele Computer wie in der IT parallel verwendet.

4. Schreiben von Tests

Tests kosten Zeit. Zeit ist Geld. Abgelehnt.

So oder so ähnlich habe ich schon des Öfteren Gespräche mit Kunden über die Implementierung von Tests geführt. Baue ich mein besagtes Haus und lasse elektrische Leitungen verlegen, so teste ich später auch, ob diese funktionieren – und das wahrscheinlich nicht nach einem halben Jahr, wenn der Elektriker kaum noch zu erreichen ist. Baue ich ein Hochhaus, so kann ich gar nicht alles auf einmal testen. Ich brauche Helfer, die diese Aufgaben für mich erledigen und die Komplexität durchschauen.

Es ist Unfug zu behaupten, dass eine größere Software dauerhaft stabil ohne automatisierte Tests laufen kann. Spätestens, wenn ein anderes Team diese übernimmt oder zum x-ten Mal ein finales Feature doch nicht final ist, dann muss die gesamte Software überprüft werden. Das Klicken in der Weboberfläche kann die ersten drei Male noch Spaß machen, danach ist es nur noch nervig, fehleranfällig und zeitraubend. Tests sorgen dafür, dass bestimmte Bereiche automatisiert überprüft werden und Fehler frühzeitig bemerkt werden könne. Sie sollten somit IMMER mit ins Budget eingeplant werden. Im Endeffekt steigen die Kosten durch manuelles Testen eher als durch eine Entwicklung auf Testbasis.

5. Final ist final

Eigentlich logisch, aber Menschen können sich oftmals nicht auf etwas festlegen. Habe ich ein Haus in Auftrag gegeben und möchte ein Schloss, so kostet mich der Umbau Geld. Möchte ich ein gelbes Haus und begann mit dem roten Haus, so kostet mich die Änderung Geld. Umso später die Änderung, umso teurer der Spaß. Dateien mit Namen á la „menu_final_final.png″ darf es nicht geben!

6. Bugs sind unvermeidbar

Ist eine Software fehlerfrei, so ist sie veraltet.

Dieses Zitat eines unbekannten Verfassers trifft den Nagel auf den Kopf. Bugs sind nicht gewollt, aber unvermeidbar. Umso komplexer die Software, umso eher können Querverbindungen im Code ungewollte Ergebnisse erzeugen. Was aber sind eigentlich Bugs?

Meiner Ansicht nach gibt es verschiedene Fehlertypen:

  1. Konzeptionelle Fehler
    Fehler, die meistens durch mangelhafte Planung entstanden sind. Ein Haus ohne Tür ist wahrscheinlich nicht einfach zu betreten und kann wohl in der Regel als Fehlplanung bezeichnet werden.
  2. Programmiertechnische Fehler
    Geschenkt. Kann – wie oben erwähnt – passieren und entweder an mangelnden Fähigkeiten des Programmierers, falschen Auffassungen oder Spezifikationen oder der Komplexität der Software liegen.
  3. Design- / UI-Fehler
    Es soll schon vorgekommen sein, dass weiße Schrift auf hellgrauem Hintergrund für barrierefreie Webseiten verwendet werden sollte…
  4. Bedienungsfehler
    Manchmal sind Bugs keine Bugs. Sondern Nutzer einfach nur zu doof um zu gucken, lesen oder verstehen. Nicht jedes Feedback ist automatisch ein Fehler. Schreibt ein Softwareentwickler während der Testphase, dass Funktion XYZ nicht funktionieren wird, so ist davon auszugehen, dass Funktion XYZ nicht läuft.

7. Kritik von Softwareentwicklern annehmen und verarbeiten

Die meisten Entwickler, die ich kenne, sind ehrliche Menschen. Äußern sie bereits Kritik an einer Funktion, die ihrer Meinung nach nicht gut bedienbar ist, so sollte man auf sie hören. Entwickler sind quasi die Poweruser der Plattform und die ersten Tester. Wer würde in ein Haus ziehen, vor dem er vom Maurer aufgrund der instabilen Wände gewarnt wurde?

8. Testen, testen, testen

Warum müssen Kunden eigentlich dazu gezwungen werden, dass sie ihre Software testen? Es werden Mengen an Euros ausgegeben und erst ganz am Ende wird überhaupt geguckt, was denn entstanden ist. Ich persönlich würde immer so früh wie möglich so viel wie möglich testen wollen – eben auch, ob das Dach kein Regen durchlässt und die Stromleitungen funktionieren. Sind meine Möbel zu diesem Zeitpunkt bereits in dem Haus, habe ich ein Problem!

9. Deadlines einhalten

Das Gejammer ist in der Regel groß, wenn es denn heißt, dass das Projekt pausieren muss, weil andere Projekte nun erst einmal abgearbeitet werden. Dieses Verhalten hat nichts damit zu tun, dass der Kunde nicht mehr gemocht wird oder geärgert werden soll. Meist ist es so, dass zuvor Deadlines nicht eingehalten wurden. Ähnlich dem Punkt „Final ist final″ ist eine fehlende Kommunikationsbereitschaft durch den Kunden tödlich. Die Entwickler warten und warten und… widmen sich anderen Aufgaben. Dass nach Lieferung der benötigten Informationen nicht sofort gesprungen werden kann ist eigentlich auch logisch, oder? Ein Maurer, der tagelang (meist unbezahlt) auf seine Steine wartet und sich dann anderen Häusern widmet wird schließlich auch nicht sofort alles stehen und liegen lassen, nur weil nun die Steine nun endlich geliefert wurden.

Marco Raddatz

Marco Raddatz

Published

Image
Marco Raddatz #TechnicalProjectManagement #SoftwareDevelopment #Berlin Back to Overview