Seite 2: "Wissen statt glauben" [--] mit realen Daten von Anfang an

Inhaltsverzeichnis

Leider wird in Projekten oft halbherzig gearbeitet. Das betrifft vor allem Livedaten und -umgebungen. In der Produktion kann das auf der Zielgeraden katastrophale Folgen haben, die sich, wären sie im Vorfeld erkannt worden, in Ruhe und ohne Chaos hätten bearbeiten lassen. Doch insbesondere die Datenmenge und ihre tatsächlichen Eigenschaften werden häufig zu wenig oder gar nicht betrachtet. Dabei kann man solche Modelle nicht einfach nur hochrechnen und bei einem Import nicht beliebig die Laufzeit erhöhen und hoffen, dass alles gut geht. Das gilt ebenso für die Ausgabe.

Bestimmte Requests, beispielsweise für Übersichtsseiten, können und müssen auch nicht alle voll aufgelösten Eigenschaften für die jeweiligen Datensätze holen. Hier ist es keine gute Idee, einfach nur darauf zu vertrauen, dass man alles mit einem Caching rausholt. Denn zu glauben ist nicht wissen, und langsame Applikationen sorgen nun einmal für ernste Probleme und Frust.

Da sich Daten ständig ändern – und das nicht nur einmal pro Nacht, ist es umso wichtiger, fehlerhafte oder falsche Informationen sofort korrigieren zu können. Das muss gewährleistet sein, denn etwa ein falscher Preis kann nicht 24 Stunden auf ein Update warten. Das Gleiche gilt für Headlines und viele andere Inhalte.

Ein gutes Projektmanagement besorgt die Daten daher so früh, wie es nur irgendwie geht. Und wenn die Daten noch nicht vollständig vorhanden sind, ist eben ein Puffer von mindestens einer Woche für das Projekt einzubauen. Alles andere ist riskant, gefährlich und verantwortungslos.

Automate All the Things: Automatisierungen und Tests nutzen

Alle Dinge, die sich automatisieren lassen, sollten auch automatisiert abgebildet werden – vor allem Tests. Investieren Unternehmer indes nicht in eine solche Infrastruktur, sparen sie am falschen Ende. Denn so erhöhen sie in Projekten den Zeitaufwand und belasten durch die zusätzliche Arbeitszeit und Unzuverlässigkeit. Schlechte Softwarequalität bringt Kunden und den eigenen Mitarbeitern kein Vertrauen. Die Folge sind Eskalationen, die sich negativ auf das Projekt auswirken. Mitarbeiter kommen unzuverlässiger zur Arbeit, feiern krank und bauen viel Frust auf. Die Folge sind Ängste, Zwangsgedanken, Vermeidungsverhalten, Depressionen, Burn-out, psychosomatische Beschwerden und all die anderen Symptome von Stress und dauerhafter Überforderung. Die Folge ist, dass Arbeit nicht mehr locker von der Hand geht und die nervliche Belastung zunimmt. Das macht auf Dauer krank und niemand dankt es einem – ein Teufelskreis.

Die Entscheider in Unternehmen und Agenturen tun somit gut daran, an dem Punkt für mehr Nachhaltigkeit zu sorgen und mehr Verantwortung zu übernehmen. Das für automatisierte Tests benötigte Know-how ist zunächst einmal zu erarbeiten und aufzubauen, was einen langfristigen Prozess erfordert. Auch gibt es hierbei keine einfache Fertiglösung, die alle projektspezifischen Probleme auf einen Schlag löst. Aber die Investition lohnt sich spätestens mittelfristig. Denn Projekte werden dadurch planbarer und verlaufen reibungsloser, da die Entwickler effizienter arbeiten können und nicht wieder und wieder auf der Zielgeraden überbelastet werden.

Aus Sicht der Programmierer sind automatisierte Test noch aus einem weiteren Grund vorteilhaft: Das entsprechende Wissen ist wertvoll und auf dem aktuellen Arbeitsmarkt gefragt. Insofern lohnt sich die Weiterbildung hierzu. Außerdem machen automatisierte Prozesse viel Spaß und motivieren, was wiederum für Arbeitgeber von Interesse ist, auch um sich im Markt als guter Arbeitgeber zu positionieren

Ziele vereinbaren, um gute Vorsätze umzusetzen

Gute Vorsätze gibt es selbstverständlich auch in der IT. Damit es keine leeren Versprechen bleiben, sind Ziele gemeinsam zu vereinbaren. Geht es dabei aber um Softwarequalität, ist auf beiden Seiten der innere Schweinehund oftmals das größte Hindernis, mit der Folge, dass wichtige und nötige Änderungen gerne aufgeschoben werden. Deswegen muss die Geschäftsführung dafür Sorge tragen, dass die Ziele erreicht werden. Und sie darf die Verantwortung nicht in die Teams tragen, da diese in der Regel ohnehin schon am Limit produzieren und nicht noch mehr schaffen können.

Softwarequalität ist außerdem nichts, das man mal eben so an einem Freitagnachmittag einführt. Vielmehr gilt hier als Faustregel, dass dafür mindestens 20 Prozent der Wochenarbeitszeit, also etwa ein ganzer Tag pro Woche, zu investieren sind, und zwar über mehrere Monate. Sonst kommt man aus dem Sumpf nicht raus. Wenn sich Programmierer jedoch über Jahre nicht aus diesem Sumpf befreien konnten, sollten sie schleunigst die nötigen Konsequenzen daraus ziehen und sich nach einem anderen Arbeitgeber umsehen. Sonst droht ein Burn-out.