12 Tipps für das Scheitern in einem WPF Projekt
Clements Lutsch hat in seinem XTOPIA Vortrag eine Anleitung in Form von wertvollen Tipps aufgestellt, um ein Designprojekt in den Sand zu setzen. Leider hatte ich keine Gelegenheit, seinen Vortrag zu besuchen, da ich einen Termin nach dem anderen hatte. Somit schaue ich mir mal die Tipps an und versuche sie zu verstehen und von der Sicht der Software-Ersteller zu kommentieren - für mich ist es eine kleine Rateübung, die ich aber meinen Bloglesern nicht vorenthalten will:
- Das falsche Designprojekt wählen
Keine Ahnung was damit gemeint ist. Muss ich wohl mal Clemens fragen.
- Verwendung von undefinierten Zielgruppen
Das ist allgemein ein typischer Fall von Fehler. Wenn diejenigen nicht bekannt sind, die im Endeffekt von den Eigenschaften inhaltlicher, haptischer oder optischer Art des Endprodukts profitieren sollen, dann ist die gesamte Erstellung ein Grüntischgebilde, das wenig Bezug zu den Anforderungen und Wünschen der Nutzer hat.
- Vermeidung klaren Zuständigkeiten
Entscheidungswege und -abläufe sind oft in einem Projekt schlecht definiert. Im Bereich einer Software mit einer ansprechenden Oberfläche, die neben fachlicher Leistung entsprechend Interaktivität aufweisen soll, sind die Zuständigkeiten unklar. Abteilungen wie Marketing, Corporate Desgin sprechen über das Erscheinungsbild und die Wirkung der Anwendung, während die Fachabteilungen über die Features der Software entscheiden sollen. Die auseinanderlaufenden Entscheidungswege werden umso komplizierter, wenn die Budget-Töpfe entsprechend verteilt sind und sich mehrere Dienstleister an einem Projekt beteiligt sind.
Menschliche Schnittstellen, Einzelpersonen und Gremien sollten von Anfang an in einem durch die Verteilung komplexen Projekt festgelegt werden. Jeder sollte wissen, was er zu entscheiden hat. Dabei sollte man den Fachleuten für Gestaltung auch durchaus mal freie Hand lassen, die Menschen wissen oft genau, was sie tun.
- Machen aber nicht erklären
Das Vorführen von Entwürfen oder Endprodukten wird ohne die Erläuterung des Entwerfenden nur auf Gegenvorschläge stoßen, die sich im Kreis sehr lange bewegen werden, bis dann am Ende ein Viel-Köche-Brei entsteht, der mit dem Konzept nur noch wenig zu tun hat, weswegen man ursprünglich sich zusammen setzen wollte. Im Grunde sollte die Aufforderung in "Erst erklären, dann machen und zeigen" umgewandelt werden. Dabei sollte der Prozess des Machens auch nicht intransparent bleiben.
- Regelmäßige Änderungen der Anforderungen
Die Gefahr von Anmutungen liegt in der Ansicht des betrachtenden Auftraggebers, dass die Ziele leicht zu erreichen wären und somit weitere Leistungen leicht einforderbar sind. Dabei wird durch die vorgeführte Anmutung oft ein Prozess angestoßen, der einfach wie bei einem kleinen Kind bei dem Bild eines Schokoriegels den Wunsch nach Bonbons weckt. Der Prozess des Entwerfens und der Umsetzung sind jedoch oft anstrengende und aufwändige Angelegenheiten und dies sollte auch beim Auftraggeber klar sein.
Eine weitere Gefahr der ersten Entwürfe sind die typischen "Das habe ich aber nicht so gemeint"-Effekte. Es bedeutet, dass die Spezifikation der Anforderungen nicht sorgsam durchgeführt wurde - oft an dem Endnutzer vorbei, und nun durch die Visualisierung oder prototypische Entwicklung genau das spezifizierte bildhaft oder erfassbar gemacht wurde. Dementsprechend groß ist der Schreck, wenn der Endnutzer im ersten Usability Test die Anwendung zerreist. Solche Effekte sind oft auch bei Vorstandsvorführungen zu sehen.
Eine Folge schlecht ermittelter Anforderung ist die häufige Anpassung an die tatsächlichen Bedürfnisse der Nutzer, was wiederum zu einer Vielzahl von Iterationen im Design, aber auch in den Features der Software führt. Besser wäre in manchen Fällen, die Entwicklung und den Entwurf zu stoppen und mit den Anforderungen neu zu beginnen. Aber das traut sich auf Grund vertraglicher Bindung kaum jemand.
- Vermeidung von Rückendeckung
"Zeigen Sie mal, was Sie da gemacht haben" - vor höheren Gremien führt nicht selten zur unvermuteten Distanzierung bisheriger Ansprechpartner zu dem abgesprochenen Ergebnis. Entwürfe müssen gestärkt und nicht geschwächt aus Abstimmungsrunden kommen.
Auch ist es wichtig, dass der Gestaltung - sofern ihr im Endprodukt eine Geltung zugerechnet wird - sie auch im Erstellungsprozess eine entsprechend gewichtige Rolle spielt.
- Auf mangelnde Qualifikation achten
Dies ist im Zusammenhang von XAML und WPF ein schwieriger Aspekt. Beginnt es doch damit, dass sich nun Software-Entwickler im Bereich der Gestalter austoben können und umgekehrt, Designer auf die Idee kommen könnten, Software-Erstellung wäre eine Kleinigkeit, wenn man doch schon weiß wie die Oberfläche und die Funktionalität auszusehen hat. Die Gefahr, die davon ausgeht, ist weitaus größer als man auf den ersten Blick vermutet. Denn die Lust und Chance, den eigenen Markt zu vergrößern, wird keiner sich gerne entgehen lassen.
- Projektplanung ohne Design
Gerade der Entscheid über gestalterische Eigenschaften erfolgt recht spät und kann jederzeit umgeworfen werden, wenn ein hohes Gremium den Daumen senkt. Man wird bei einer EMail-Software sehr schnell die möglichen inhaltlichen Features festhalten können. Doch die optische und interaktive Gestaltung kann sehr aufwändig und langwierig beschlossen werden. Dies ist bei der Projektplanung unbedingt zu beachten.
- Designer soll sich selbst überprüfen
Grundsätzlich nicht nur Designer. Enthusiasmus und Kreativität sind ein hohes Gut, doch wer sich die Gebäude der Coop Himmelb(l)au in Wien anschaut, der wird schnell verstehen, dass nutzbare Software so nicht entstehen kann.
- Kontrollverlust durch Design
Diesen Punkt muss ich bei Clemens unbedingt abfragen. Der ist mir zu vieldeutig.
- Erwartungshaltung ignorieren
Kunden sind Wunschmaschinen wie kleine Kinder, aber es ist wohl kaum opportun, die eine oder andere Gruppe in ihren Erwartungen komplett zu enttäuschen.
- Isolation der Designer im Unternehmen
Designer im Unternehmen sind oft zentralisiert und haben ihren Segen einem fertigen Produkt zu geben, sofern es einigermaßen den Corporate Design Guides entspricht. Eine kaum wünschenswerte Situation, wenn es schon eine Designtruppe gibt, sollte man diese einbeziehen.
Soweit mein Rätselraten zu den Punkten. Ich werde mir mal die Slides und evtl. die Video-Aufzeichnungen von Clemens nehmen und vergleichen. Wird spannend.