Das Ponemon-Instituts hat im Auftrag von Compuware eine Untersuchung mit dem Titel „Test Data Insecurity: The Unseen Crisis“ durchgeführt. Dem Bericht zufolge gefährden 62% der untersuchten Unternehmen vertrauliche Kundendaten, indem sie diese in Anwendungsstests oder bei der Software-Entwicklung benutzen. Die meisten geben vertrauliche Daten sogar an ihre Outsourcing-Partner weiter, die zudem teilweise im Ausland sitzen und hinsichtlich Datenschutz lascheren Gesetzen unterstehen. Die Hälfte der untersuchten Unternehmen, die mit ihren Kundendaten testen, unternimmt keinerlei Anstrengungen, diese gegen Missbrauch zu schützen. Testumgebungen werden normalerweise nicht annähernd so gut bis gar nicht gegen unbefugten Zugriff gesichert wie produktive Umgebungen, obwohl sie oft die gleichen Daten beherbergen.
IT-Alltag und Szenen-News
Schreiben mit Zehnfingersystem
Ich hatte das Glück, bereits im zarten Alter von fünfzehn Jahren in der Schule kostenlos an einem Schreibmaschinenkurs teilnehmen zu dürfen. Damals konnte sich noch niemand einen privaten Computer leisten und ich wusste noch nicht, wofür das einmal gut sein soll. Wahrscheinlich ging ich mit, weil praktisch die ganze Klasse geschlossen an diesem Fakultativkurs teilnahm. Wir dachten: „Schaden kann’s ja nicht“. Von meiner späteren IT-Karriere wusste ich noch nichts. Heute bin ich froh, mit zehn Fingern schreiben gelernt zu haben. Wenn ich einigen meiner Kollegen zuschaue, wie sie sich immer noch mit „System Arafat“ (jede Stunde ein Anschlag) abmühen, bekomme ich Krämpfe. Dabei gibt es heute eine ganze Anzahl wirklich guter Software, um das Zehnfingersystem innert kurzer Zeit zu erlernen. Manche sind sogar kostenlos.
Eines dieser Angebote ist Schnell-schreiben.de von Christian Strang. Die Benutzung des Lernprogramms ist auch ohne Registrierung möglich! Ob wirklich 5 Stunden genügen, um das Zehnfingersystem zu erlernen, wage ich zu bezweifeln. Trotzdem ist die Webseite sehr empfehlenswert. Die Bedienung ist äusserst einfach und die Benutzerfreundlichkeit hoch. Auch Kinder und Senioren dürften keine Mühe damit haben. Mit dem Speedtest können auch Profis ihre Virtuosität auf der Tastatur unter Beweis stellen.
Was passiert, wenn das Netz kollabiert?
Stellen wir uns vor, das Internet bricht zusammen! Bereits beim Gedanken daran bekommen viele Zeitgenossen ein mulmiges Gefühl. Zu sehr haben wir unsere Geschäftsmodelle von diesem Kommunikationsmedium abhängig gemacht, als dass wir einfach darauf verzichten könnten. Das Internet funktioniert bis auf wenige Ausnahmen meist recht gut und wir betrachten dies als eine Selbstverständlichkeit. Aber spätestens wenn das Netz einmal (wenn auch nur für kurze Zeit) nicht verfügbar ist, wird manch einem Geschäftsleiter, Informatikleiter, Risikomanager oder COO bewusst, dass es sich lohnen könnte, sich etwas mehr mit Krisenmanagement zu befassen.
So fürchtet zum Beispiel das Government Accountability Office (GAO) einen weltweiten Internet-Knockout aufgrund physischer Vorfälle wie einer Naturkatastrophe oder einem Angriff auf die Rechneranlagen von Internet-Knotenpunkten. Das GAO hat deshalb aufgrund einer aktuellen Studie das Department of Homeland Security (DHS) aufgefordert, einen Reaktionsplan auszuarbeiten. Auch gemäss Lawrence G. Roberts (ehemaliger Leiter des Entwicklungsteams beim Internet-Vorläufer Arpanet, heute Gründer und CEO von Anagran Inc.) ist die Wahrscheinlichkeit, dass das Netz kollabiert, relativ hoch, denn der Kapazitätsbedarf steigt schneller als die Preise sinken und längst machen Filesharing über Peer-to-Peer-Netze, Spam, Anfragen von Suchrobotern und Denial Of Service Attacken den Hauptanteil des Datenverkehrs aus. Wenn dann auch noch bandbreitenhungrige IP-TV Provider wie Zattoo ihre Infrastrukturkosten auf die Peer-to-Peer-Netze auslagern, ist der Punkt nicht mehr weit, an dem wir über neue Finanzierungsmodelle für die Infrastruktur des Internets verhandeln müssen.
Kommunikationsflut wegen „Cover-your-ass“
Das Gesicht zu wahren ist in der asiatischen Kultur das oberste Gebot und wird auch bei uns zunehmend wichtig. Nur wer sein Hinterteil genügend deckt, ist vor Angriffen im Geschäftsleben geschützt. Die steigende Angst vor dem Verlust des Arbeitsplatzes tut das ihre dazu. Deshalb geben wir uns kommunikativ und teamfähig, indem wir alle Entscheidungen breit abstützen und alle Betroffenen informieren. Dieser Informationsaustausch erfolgt meist per E-Mail. Viele E-Mails werden deshalb nur an andere weitergeleitet, um bei der Lösung eines Problems möglichst nicht alleine dazustehen und sich auf andere ausreden zu können – ganz nach dem Motto „geteiltes Leid ist halbes Leid“. Die Folge dieser so genannten „Cover-your-ass-Strategie“ ist eine Kommunikationsflut innerhalb der Unternehmen, die zu teilweise massiven Produktivitätseinbussen führt, was die neusten Studien bestätigen.
Leider erlebe ich dies seit mehreren Jahren und kann mehr als nur ein Lied davon singen. Ich staune deshalb über alle die sich untentbehrlich fühlenden Jungmanager, die auch in der Freizeit ihr Blackberry ständig im Visir haben und ihr Auge kaum fünf Minuten davon lösen können. Jedes eintreffende E-Mail wird unverzüglich gelesen und beantwortet. Ob sie das wirklich brauchen, um ihre vier Buchstaben zu decken? Ich erlaube mir, mein Mobiltelefon (auf eine Schwarzbeere kann ich verzichten) am Abend und am Wochenende auszuschalten, und gönne mir lieber etwas mehr Lebensqualität.
Bullshit Bingo by IBM
Bullshit Bingo (oder auch Buzzword Bingo) gestaltet Meetings und Präsentationen spannend und lässt die Mitarbeiter aktiv zuhören. IBM bedient sich des beliebten Bürolistenspiels für seine Werbung:
Übrigens habe ich das auch schon an schwierigen Workshops gespielt – mit vollem Erfolg! Niemand schlief ein oder langweilte sich. Alle nahmen aktiv am Workshop teil und hingen dem, der das Wort hatte, förmlich an den Lippen.
Wenn IT-Projekte in Zeitnot geraten
… dann wird meist einfach durchgewurstelt bis zum bitteren Ende. Und die Letzten beissen die Hunde. Das sind die Tester, welche die zu prüfende Software regelmässig zu spät erhalten, aber trotzdem termingerecht fertig getestet abliefern müssen – einschliesslich der nötigen Korrekturen der Entwickler, versteht sich. Da aber die Erstellung des Prüflings mehr Zeit in Anspruch genommen hat als ursprünglich geplant war, steigt naturgemäss entsprechend auch der Testaufwand proportional, der sich bei finanztechnischer Individualsoftware üblicherweise in der gleichen Grössenordnung wie der Entwicklungsaufwand bewegt. Wenn gegen Ende der Entwicklungszeit die Liefertermine ohnehin schon überfällig sind, wird alles noch schnell-schnell codiert und dann ohne Vortests zur Sicherstellung der Lauffähigkeit und Grundfunktionalität durch den Entwickler an die Tester weitergereicht. Dadurch stecken dann noch mehr Fehler in der Software als wenn sie unter Einhaltung der Regeln der IT-Kunst erstellt worden wäre.
Die Gründe für den höheren Entwicklungsaufwand sind meist in den vorgelagerten Phasen zu suchen. Ungenaue, unklare und unvollständige Spezifikationen führen zu Fehlern und Mehraufwänden in den nachgelagerten Projektphasen. Entweder hat der Analyst die Sache selber nicht richtig analysiert und verstanden oder er ist nicht in der Lage, die Anforderungen so zu beschreiben, wie sie von den Entwicklern und Testern verstanden werden können und erwartet werden. Der Entwickler setzt die Modelle aus der Analyse in Programmcode um. Das ist Handwerk, das der Kreativität relativ wenig Freiheit lässt. Entsprechend sind die meisten Fehlerursachen auch nicht hier zu suchen.
Es gibt schon seit längerem Standards zur systematischen Beschreibung von Anforderungen und Modellen (z.B. die Unified Modeling Language UML), die aber in der Praxis oft nur pro forma eingehalten werden. Zum Beispiel mag ein Use Case (d.h. die Beschreibung eines Geschäftsanwendungsfalls) auf den ersten Blick aussehen wie einer, inhaltlich ist er aber nicht selten unvollständig und zu ungenau oder beschreibt nicht das, was er eigentlich sollte. Das kennen wir ja aus dem Alltag schon: aussen hui, innen pfui – aussen straffe Haut und volle Brüste, innen Silikon, abgesaugtes Fett und künstlich gelähmte Nervenzellen. Unvermögen mangels Ausbildung oder Unwille zur Kommunikation und Zusammenarbeit zwecks politischer Machtspiele, indem wichtige Informationen bewusst vorenthalten werden? Oder ganz einfach nur Schlamperei? Die Ursachen sind vielfältig. Das Resultat ist aber immer das selbe: Reibungsverluste, Mehraufwände, Terminverschiebungen und eine schlechte Qualität der Software. Und der CIO ist meist viel zu weit von der Materie entfernt, als dass er gezielt den Hebel ansetzen könnte, um die nötigen Veränderungen in der Arbeitskultur und bei den Prozessen zu initiieren und voran zu treiben. Von der Basis her sind solche Veränderungen unmöglich, weil sie einen starken Führer benötigen, der nicht bloss dahinter steht, sondern den Karren selber zieht.
Erst kürzlich las ich in einem Protokoll eines Projektstatus-Meetings (sinngemäss): „Die Situation wurde durch die Parallelisierung von Design und Codierung entschärft“. Das heisst im Klartext: mit der Umsetzung wurde schon begonnen, bevor klar war, was und wie es eigentlich realisiert werden sollte. In der Maschinenindustrie wäre so etwas kaum vorstellbar. Wenn das bloss wieder einmal gut geht …
Aus dem IT-Alltag
Wenn man in der Informatik-Branche arbeitet, widerfährt einem so mancherlei Kurioses – nicht nur in technischer Hinsicht sondern auch zwischenmenschlich. Diese Erlebnisse sind oft symptomatisch für die gesellschaftlichen Veränderungen durch die Informationsgesellschaft. Um auch Nicht-Informatikern einen Einblick in den „computergesteuerten“ Alltag zu ermöglichen, werde ich künftig vermehrt auch über meine Erlebnisse und gewonnenen Einsichten aus dem Berufsalltag in IT-Projekten berichten. Selbstverständlich erfolgt dies unter Wahrung der Anonymität aller Beteiligten Firmen und Personen. Analogien zum 08/15-Alltag von Otto Normalverbraucher werden für mehr Verständnis und den einen oder anderen Aha-Effekt sorgen.
Zudem werde ich für alle, die sich für IT-Projektmanagement und verwandte Themen interessieren, auch Verweise auf interessante Quellen im Web veröffentlichen. Den Anfang macht der PROJEKTMANAGEMENT BLOG.