Erfolgreiche Softwareprojekte im Web: 100 Gedanken zur Webentwicklung

Entwicklerkonferenzen.

1 Scrum löst eure Probleme nicht

Starke Worte für einen der größten Verfechter der agilen Herangehensweise. Scrum löst die meisten Probleme, die ein Unternehmen hat, nicht, aber es zeigt sie auf. Nehmen wir das klassische Beispiel der Priorisierung. In den meisten Softwareunternehmen werden Task-Tracking-Tools eingesetzt. Betrachtet man dort die Art, nach der priorisiert wird, existiert meist eine Handvoll Einstufungsmöglichkeiten. Blocker, sehr wichtig, wichtig, muss irgendwann mal gemacht werden usw. Was passiert in solchen Unternehmen mit der Priorität? Natürlich ist alles erst einmal sehr wichtig. Es könnte ja das nächste große Ding dabei sein, und wenn wir das nicht alles sofort umsetzen, haben wir ein Problem. Wenn aber alles eine sehr hohe Einstufung bekommt, dann haben wir im Endeffekt gar keine Bewertung vorgenommen. Was ist denn jetzt wichtiger? Feature A oder Feature B? Meist weiß es der Produktverantwortliche selbst nicht. Dieses Vorgehen ist nicht optimal, aber verstößt auch gegen keine Regel des Wasserfallmodells oder anderer veralteter Standards.

Bei Scrum ist es anders. Es wird vom Product Owner verlangt, alle Features in eine Reihenfolge zu setzen. Es ist eine einfache Liste mit Wünschen, und wie bei allen Listen gibt es keine Einträge, die auf derselben Position verharren. Das Team, welches das Projekt technisch betreut, weiß also immer genau, was als Nächstes ansteht und was zum jetzigen Zeitpunkt das Potenzial hat, bald umgesetzt zu werden.

Wo war aber das eigentliche Problem? Im ersten Beispiel war es der Produktverantwortliche, der sich nicht entscheiden konnte, was denn momentan das Wichtigste ist und wie die verschiedenen Features untereinander gewichtet werden sollen. Hilft uns Scrum dabei, dieses Problem zu lösen? Die Antwort ist ein klares Nein. Das Gute an Scrum ist aber, dass es uns als Rahmenwerk dazu zwingt, unser Projekt besser zu verstehen. Es zwingt uns, eine klare Reihenfolge zu definieren. Der Product Owner muss sich Gedanken darüber machen, in welcher Reihenfolge die Punkte abgearbeitet werden sollen. Er reflektiert sein Produkt immer und immer wieder, spricht mit anderen Stakeholdern und stimmt sich mit ihnen ab.

Oft ist einem gar nicht klar, was dies eigentlich bedeutet, und es wird als pure Schikane empfunden. Das ist aber nicht der Fall. Die Entwickler haben auf einmal nicht mehr den riesigen unsortierten Berg an Arbeit vor sich liegen und können strukturierter mit der Arbeit beginnen. Wünsche, die ganz hinten auf der Liste stehen, müssen erst einmal gar nicht in Betracht gezogen werden, und es wird nur das entwickelt, was gerade relevant ist. Auch wird den Verantwortlichen klar, was es vielleicht nicht in das nächste Release schaffen wird, und man kann sich frühzeitig darauf einstellen. Es handelt sich also keinesfalls um Schikane.

Nehmen wir ein zweites Beispiel: Bei Scrum gibt es täglich ein aktuelles Sprint Burndown Chart, das dazu verwendet wird, den Fortschritt im aktuellen Sprint zu visualisieren.

Die optische Aufbereitung hilft den Entwicklern zu erkennen, wann sie mit ihrer Arbeit hinterherhinken und wann sie nahe an der erhofften Geschwindigkeit liegen. Man könnte jetzt meinen, das Burndown Chart löst das Problem des faulen Entwicklers und ist dazu da, ihn immer wieder darauf hinzuweisen, dass er härter arbeiten soll. Viele Arbeitgeber sehen das genau so. Zum Glück ist es aber falsch.

Das Burndown Chart ist ein Werkzeug, um Probleme aufzuzeigen. Sobald etwas Unerwartetes im Diagramm zu sehen ist, heißt es, dass man nachforschen muss, um herauszubekommen, was der Grund dafür ist. In den allermeisten Fällen ist es nicht das faule Team, sondern es sind die Rahmenbedingungen, die nicht stimmen. Häufig sind es unaufgelöste Abhängigkeiten, ungenaue Schätzung durch zu viele unbekannte technische Voraussetzungen oder zu ungenaue Beschreibung der eigentlichen Features.

Scrum gibt auch in diesen Fällen nicht vor, wie die Probleme zu lösen sind, es hilft einem aber, zeitnah festzustellen, dass dort Probleme existieren. Wie sie zu lösen sind, muss das Team entscheiden.

Probleme in Unternehmen sind zwar häufig ähnlich, aber doch immer wieder ein wenig anders. Ein Projektmanagementframework, das alle möglichen Probleme löst, ist also fast unmöglich zu konzipieren, ohne dass das Regelwerk den Umfang einer Enzyklopädie annimmt. Scrum geht also den richtigen Weg, indem es einem die Werkzeuge an die Hand gibt, Probleme aufzudecken und sich bei der Lösung im Groben erst einmal heraushält.

Leider verstehen Projektverantwortliche nicht immer, welche Ideen hinter den einzelnen Bestandteilen des agilen Vorgehensmodells stehen, und streichen sie einfach, sobald sie unliebsam werden. Das Burndown Chart sieht immer problematisch aus? Dann machen wir einfach keins. Wir haben keine Zeit für die Retrospektive? Gestrichen. Viele Unternehmen behaupten von sich, dass sie nach Scrum arbeiten. Tatsächlich nehmen sie einige Bestandteile, die sie verstehen, und lassen den Rest weg, wundern sich aber dann, warum das System für sie nicht funktioniert. Für dieses Vorgehen wurde der Begriff ScrumBut [http://www.scrum.org/ScrumBut] geprägt. „We use Scrum, but Retrospectives are a waste of time, so we don't do them". Leider versteckt man auf diese Art nur ein Problem, das über Scrum aufgezeigt wird. Gelöst wird es sicher nicht.

2 Der Anwalt des Teufels

Dank regelmäßiger Reviews und der Einführung von Pair Programming steht man recht gut da, wenn es um die Qualität einer Anwendung geht. Es gibt aber noch weitere Vorgehensweisen, die dazu verwendet werden können, Entscheidungen zu verbessern. Der Anwalt des Teufels ist ein solches Vorgehen.

Auch wenn behauptet wird, dass Testen die einzig destruktive Disziplin in der Softwareentwicklung ist, gibt es noch weitere Wege, zerstörerisch vorzugehen, um damit die Qualität eines Produkts zu verbessern. Der Anwalt des Teufels kann immer dann eingesetzt werden, wenn es um die Bewertung von Ideen oder Entscheidungen geht. Leider ist es in nicht eingespielten Teams oft der Fall, dass Kritik etwas ist, was man nicht offen aussprechen sollte. Und wenn man es doch tut, sind die bösen Blicke des Kollegen sicher. Trotzdem ist es häufig notwendig, Ideen anderer zugunsten besserer Vorschläge anzugehen.

Um ein solches Aufeinandertreffen von einer scheinbar persönlichen Ebene auf eine fachliche zu heben, ist es wichtig, eine Formalisierung vorzunehmen. Es muss dediziert die Aufgabe vergeben werden, das vorgestellte System niederzumachen. Die Person, die diesen Auftrag bekommt, ist der Anwalt des Teufels.

Der Ausdruck „Anwalt des Teufels" stammt aus der katholischen Kirche. Dieser Anwalt wird bei der Selig- und Heiligsprechung eingesetzt, um Gründe vorzubringen, die gegen die Kanonisation sprechen. Auch wenn der Anwalt selbst nicht der Meinung ist, dass die Heiligsprechung unrechtmäßig ausgerufen wird, so hat er doch die Aufgabe, alles ihm Mögliche zu tun, sie zu verhindern. Sollten die gefundenen Gründe nicht ausreichen, das Verfahren zu stoppen, so wird die Person in den Kreis der Heiligen aufgenommen.

Genau diesen Prozess gilt es zu adaptieren, wenn die Qualität eines Produkts oder einer Idee gesteigert werden soll. Nimmt man zum Beispiel ein Architektur-Review [Vier Augen und die Architektur], in dem ein Entwickler seine Ideen für eine neue Struktur vorstellt: Es kann schwer sein, diese in einer Diskussionsrunde so anzugreifen, dass sich der Entwickler nicht persönlich angegriffen fühlt. Man darf dabei nicht vergessen, dass die Gedanken und der Entwurf, den er sich gemacht hat, sein Baby ist, und wer mag es schon gern, wenn man auf seiner Familie rumhackt. Sicherlich wäre es fachlich sinnvoll, wenn erst einmal alle Review-Beteiligten das Optimierungspotenzial ausschöpfen, das kann aber leicht in Demotivation ausarten. Aus diesem Grund muss die Rolle des „Miesmachers" explizit verteilt werden.

Wenn ein Team merkt, dass Kritik zu sehr auf der persönlichen Ebene angenommen wird oder es junge Programmierer verunsichert, so muss der Anwalt des Teufels eingesetzt werden. Vor einem Review wird diese Rolle verteilt, und eine Person versucht, das Vorgestellte schlecht zu machen. In den meisten Fällen hilft das bereits, um wieder auf der fachlichen Ebene zu diskutieren. Richtig gespielt, kann dieses Vorgehen auch neue Energie und Kreativität in Termine bringen.

Ein weiterer Vorteil bei diesem Vorgehen ist es, Kollegen, die gerne kritische Fragen stellen, besser zu unterstützen. Oft werden die Fragen und Anmerkungen von solchen Personen als negativ aufgefasst und stellen diese in ein Licht, in das sie nicht gehören. Nur weil jemand Dinge hinterfragt und auch mal Entscheidungen als falsch erachtet, heißt das nicht, dass er das Projekt sabotieren will. Leider wird das von der Außenwelt nicht immer so wahrgenommen. Wenn man hier wieder explizit die Aufgabe verteilt, Kritik zu äußern, kann diese Sichtweise nicht mehr auf eine Person projiziert werden.

3 Messen, was wichtig ist

von Bastian Hofmann

Mein größtes Learning der letzten Jahre ist es, erkannt zu haben, wie wichtig es für die Entwicklung einer Webanwendung ist, nicht nur technische Metriken im Blick zu haben, um sicherzustellen, dass die eigene Anwendung und die Server laufen, skalieren und die eigene Anwendung so schnell wie möglich ist. Auch Businessmetriken und Key-Performance-Indikatoren, die für das Produkt wichtig sind, müssen erhoben werden und die Produktentwicklung muss zum Teil daran ausgerichtet werden. Das heißt natürlich nicht, dass innovative Ideen nicht mehr wichtig sind, vielmehr kann man sein Produkt und seine Features auf Grund dieser Zahlen validieren und perfektionieren. So kann es zum Beispiel sehr hilfreich sein, zum Start der Entwicklung festzulegen, was man mit einem neuen Feature verändern möchte und welche Indikatoren sich verbessern sollen. Dadurch merkt man nach dem Abschluss der Entwicklung schnell, ob die eigenen Nutzer eine neue Funktion annehmen und wie sie sie benutzen. Nach dem Launch des Produkts oder eines neuen Features sollte daher die Entwicklung noch lange nicht abgeschlossen sein, die spannende Phase der Optimierung fängt damit gerade erst an. Ein sehr effektives Mittel hierfür ist es, verschiedene Varianten einer Funktion in Experimenten mit einem A/B- oder Bandit-Testing-Algorithmus gegeneinander zu testen. Das kann bei der Farbe und Beschriftung eines Buttons anfangen und mit vollkommen unterschiedlichen Klickpfaden wie zum Beispiel in der Registrierung enden. Ich finde es immer wieder bemerkenswert zu sehen, wie stark man hierdurch Indikatoren und Konversion eines Features verbessern kann.

Damit das Ganze auch wirklich Spaß macht, ist es lohnenswert, sich einmal grundlegend mit den Themen „Erfassen von Businessmetriken und „Testen mit Experimenten zu beschäftigen und dies in seiner Anwendung so einfach wie möglich zu machen. Für Metriken gibt es zum Beispiel zahlreiche Open-Source-Tools (Graphite: http://graphite.wikidot.com/), StatsD: https://github.com/etsy/statsd ...) oder Platform-as-a-Service-Anbieter (Librato: https://metrics.librato.com/), die das Erfassen der Metriken und die Darstellung und Auswertung dieser Zahlen zu einem Kinderspiel machen. Beim Testen mit Experimenten ist es etwas komplizierter, denn das ist stark abhängig von der Architektur der eigenen Anwendung und der verwendeten Programmiersprache oder des verwendeten Frameworks. Man sollte aber den Einsatz von Experimenten so einfach und unaufwändig wie möglich machen, zum Beispiel durch die Kapselung der Logik zur Entscheidung, welche Variante dem Nutzer angezeigt wird. Aber auch hierfür gibt es Platform-as-a-Service-Anbieter, die einem Teile der Implementierung abnehmen können (Myna: https://mynaweb.com/), Visual Website Optimizer: http://visualwebsiteoptimizer.com usw.).

Allerdings gilt es, bei der Erhebung und Nutzung von Metriken sowie bei Entwicklung mit Experimenten einige potenzielle Stolpersteine im Auge zu behalten:

Neben der schon oben genannten Gefahr, dass man innovative Produktentwicklung gerade in der Anfangsphase komplett von Metriken abhängig macht, hängen sie vor allem mit der Entscheidung zusammen, welche Metriken für das eigene Produkt eigentlich wichtig und wie diese Zahlen zu interpretieren sind. Selbst bei einem vermeintlich einfachen Beispiel wie einem Onlineshop kann das mehr sein als nur Gewinn oder Umsatz. So könnten auch Umsatz pro Kunde, Anzahl der Neukunden, Anzahl der wiederkehrenden Kunden etc. wichtige Indikatoren für den Erfolg des Shops sein.

Ebenso kann es bei Experimenten zu Situationen kommen, durch die Testergebnisse verfälscht und invalide werden. Das fängt damit an, dass man das Ziel eines Experiments sehr genau definieren muss: Ist es zum Beispiel nur der Klick auf den „In den Warenkorb legen"-Button oder der darauf hoffentlich folgende Kaufabschluss? Eventuell ist hier je nach Definition des Ziels die bessere Variante eine ganz andere. Aber auch Faktoren außerhalb des eigentlichen Experiments können das Ergebnis beeinflussen. So haben wir zum Beispiel bei ResearchGate herausgefunden, dass bei unterschiedlichen Einstiegspunkten in die Benutzerregistrierung unterschiedliche Anordnungen der Schritte, die zu einer Registrierung notwendig sind, unterschiedliche Konversionen erzielen. Um solche Effekte zu vermeiden, lohnt der Blick auf Experimentalgorithmen, die über das klassische A/B-Testen hinausgehen (weiterführende Blog-Posts und Diskussionen gibt es hier http://news.ycombinator.com/item?id=4040022 und hier http://news.ycombinator.com/item?id=4052997).

Zusammengefasst: Die konsequente Erhebung und Nutzung von Businessmetriken sowie das Testen mit Experimenten ist aufwändig (viele erfolgreiche Webfirmen haben zum Beispiel ganze Teams, die sich nur darum kümmern). Der Aufwand lohnt sich aber auf jeden Fall.

Über den Autor

Bastian Hofmann (bashofmann@gmail.com) arbeitet als Software Engineer bei ResearchGate, dem sozialen Netzwerk für Forscher und Wissenschaftler, und ist dort vor allem für die Softwarearchitektur des Web-Frontends und APIs verantwortlich. Davor hat er bei den VZ-Netzwerken maßgeblich die Spiele- und App-Plattform sowie die APIs der Plattformen entwickelt. Neben seiner Entwicklertätigkeit spricht er häufig auf internationalen Konferenzen über Softwarearchitektur, Skalieren von Webanwendungen und offene Standards und Protokolle.

4 Klassisches Vorgehen

Um ein Projekt erfolgreich abzuschließen, gilt es, strukturiert die anfallenden Aufgaben zu erledigen. Diese Struktur kann durch ein konkretes Vorgehensmodell in eine Richtung gelenkt werden. Früher waren klassische Modelle wie Wasserfall und V-Modell das Mittel der Wahl, denn sie hatten bereits in vielen Disziplinen bewiesen, dass sie Erfolg bringen können.

In den letzten Jahren kam immer häufiger der agile Ansatz zum Tragen, der in vielen Unternehmen dabei ist, den Wasserfall zu verdrängen. Um zu verstehen, warum der agile Weg in vielen Fällen die bessere Wahl ist, muss man verstehen, wie die herkömmlichen Methoden kranken.

Herangehensweisen wie das Wasserfall- und V-Modell wurden in den letzten Jahre häufig eingesetzt, und si e können auch funktionieren - aber leider nicht in der Softwareentwicklung bei Webanwendungen. Das Internetbusiness ist viel zu schnelllebig und unberechenbar, als dass starre Modelle zum Erfolg führen würden. Betrachtet man die Gesamtheit der begonnenen Anwendungen, erkennt man diverse Muster, die immer wieder bei gescheiterten Projekten auftreten.

Die Welt dreht sich weiter

Baut man ein Haus, so ist das Vorgehen klar. Man engagiert einen Architekten, der entwirft das Anwesen und es wird im Anschluss von der Baufirma erstellt. In einem solchen Fall würde Wasserfall das Projekt zum Ziel bringen. Es ist verständlich, dass man nach dem Abschluss des Kellers nicht mehr auf die Idee kommen sollte, dass man vielleicht doch einen Indoor-Pool haben möchte.

Bei Internetanwendungen ist das aber Gang und Gäbe. Sobald ein Feature fertig ist, stürzen sich die Projektmanager und Konzepter darauf und verbessern bzw. erweitern es. Und das ist auch gut so, denn die Welt hat sich in der Zwischenzeit weitergedreht. Neue Ideen sind entstanden, und die Konkurrenz ist mittlerweile auch ein Stück weitergekommen. Alles gute Gründe, auch weiter zu denken.

Im klassischen Wasserfall sind Änderungen während der Entwicklung nicht geplant. Kostspielige Änderungsanforderungen müssen eingekippt und wahrscheinlich muss der Auftrag geändert werden, da der Umfang, der am Anfang geplant wurde, nicht mehr aktuell ist.

80-Prozent-Syndrom

Projekte haben viele Teilaufgaben. So viele Teilaufgaben, dass es eine gute Idee erscheint, zu parallelisieren. Das ist auch bedingt richtig. Wenn man viele Teammitglieder hat, kann man es probieren. Die Bedeutung für das Projekt ist leider häufig sehr ähnlich. Von den 20 gleichzeitig angegangenen Aufgaben sind 15 offen, aber zu 80 Prozent fertig. Leider kann man erst wirklich etwas damit anfangen, wenn es 100 Prozent sind.

Misslungene Schätzungen

Sich das fachliche Feinkonzept zu Gemüte zu führen und danach eine präzise Schätzung abzugeben, hat noch nie geklappt. Trotzdem passiert es immer wieder, dass ein Projektmanager oder ein einzelner Entwickler diese Aufgabe zugeschustert bekommt. Dass dies im Normalfall bis zu 500 Prozent danebenliegen kann, ist empirisch belegt [DKDIP]. Bei besonders hartnäckigen Projektleitern kann es auch vorkommen, dass diese Schätzung bereits in einem frühen Projektstadium in Stein gemeißelt wird und die TV-Werbung für den Launch sozusagen schon auf den Tag genau gebucht wird. Eine Anpassung des Zeitplans ist somit nicht mehr möglich.

Priorisieren

Fragt man den Auftraggeber, welches Feature besonders wichtig für den Erfolg des Projektes sei, dann ist die Antwort oft die gleiche. Alle. Viele. Für das Priorisieren ist dies recht kontraproduktiv. Das Team muss entscheiden, was zuerst angegangen wird. Wenn dann aber an einem bestimmten Meilenstein das Falsche fertig ist, wird es den Entwicklern vorgeworfen.

Projektabschlusshektik

Das Gute an klassischen Projekten ist, dass auch sie irgendwann einmal ein Ende finden. Nur leider ist das Ende meist mit Überstunden, Druck und Stress verbunden. Alles, was man bis kurz vor dem Abschluss noch nicht implementiert hat, muss jetzt in kürzester Zeit nachgeholt werden. Meist wird in einer solchen Phase auch auf Qualität keinen großen Wert mehr gelegt. Erfahrungsgemäß sind Unit Tests das Erste, das gestrichen wird, wenn ein Projekt unter Stress zu Ende geführt wird.

In einer solchen heißen Phase wird das Produkt meist nicht mehr strukturiert unter Kontrolle gehalten, sondern in Wild-West-Manier drauflos programmiert. Auf Entwickler wird in dieser Zeit ebenfalls keine große Rücksicht genommen. Der große Vorteil bei uns Menschen ist, dass wir uns nach so einer Zeitspanne wieder erholen. Die einen schneller, die anderen langsamer. Das Projekt wird nicht von alleine genesen. Die oft geforderte Refactoring-Phase wird häufig auf unbestimmte Zeit verschoben, da im Betriebsmodus auch keine Zeit mehr vorhanden ist.

5 Spezialisierung ist böse

Spezialisierung als böse zu bezeichnen, ist sicherlich eine recht provokante These. Ohne Spezialisierung würden viele neue Werkzeuge nicht existieren und technische Innovationen wären nicht so häufig in der Presse wie heute. Spezialisierung ist wichtig. Trotzdem muss man bewerten, in welchem Kontext Spezialisierung sinnvoll ist. In den meisten Webprojekten geht es darum, einfache Anwendungen zu basteln, die in ihren Einzelteilen nicht sonderlich innovativ sind. Das Große und Ganze letztendlich kann dies dennoch sein.

Analysiert man ein solches Projekt, kommen nicht selten folgende Bestandteile zum Vorschein:

Backend-Code (z.B. PHP)

HTML und CSS

JavaScript

MySQL

Jetzt könnte man ein Team zusammenstellen, indem man aus jedem Bereich einen ausgewiesenen Experten nimmt, der sich genau auf diese eine Technologie spezialisiert hat. Solche Spezialisten sind zumeist recht teuer und verlassen ihre Domäne nur ungern.

Analysiert man in einem Projekt nun die einzelnen Technologiebestandteile, so fällt auf, dass im Normalfall die Spezialisierung nicht nötig ist. 80 Prozent der zu lösenden Anforderungen und häufig auch mehr können ohne jahrelange Beschäftigung mit der Sprache oder Technologie gelöst werden. Hierbei handelt es sich um Standardaufgaben. Natürlich kann es nicht schaden, auch diese Aufgaben von einem Spezialisten gelöst zu bekommen, kosteneffizient wird diese Lösung aber nicht sein.

Der Ansatz, dass jeder Mitarbeiter in einem Projekt genau einer Domäne zugeordnet ist, funktioniert auch nur so lange, wie die Domänen vom Aufwand her gleich verteilt sind. Sollte es Phasen geben, in denen die gewählte Technologie nicht zum Einsatz kommt, ist Däumchendrehen an der Tagesordnung, da beispielsweise die Unterstützung eines reinen JavaScript-Entwicklers meist nicht geschätzt wird, wenn es um die Erstellung von SQL Queries geht.

Geht man weg von dem Ansatz der Spezialisierung hin zu den Generalisten, so wird schnell der Vorteil sichtbar, dass 80 Prozent eines Projekts, nämlich die Standardaufgaben, von jedem Teammitglied erledigt werden können. Skalierbarkeit über alle Teammitglieder ist somit einfach möglich. Für die Planbarkeit eines Projekts ist sowas sicherlich auch interessant, da nicht mehr jede Domäne oder Technologie für sich betrachtet werden muss, sondern das gesamte Projekt in den Vordergrund tritt.

Ein Phänomen, das häufiger zu Projektende beobachtet werden kann, ist das Ungleichgewicht der Aufgaben in Bezug auf die Spezialgebiete. In einer solchen Phase werden kaum neue funktionale Anforderungen gestellt, und es wird nur noch an der Optik und der Usability gefeilt. Backend-Entwickler können in dieser Zeit eher unnötig sein. Projiziert man diese Situation auf ein Team von Generalisten, wird das Risiko eines Flaschenhalses durch das Frontend-Team minimiert, wenn nicht sogar komplett verhindert.

Was passiert aber mit den 20 Prozent, die eben doch keine Standardaufgaben sind? Hier kann man versuchen, gemeinsam eine Lösung zu finden. Oft sind viele Generalisten ebenso kreativ und effizient wie einzelne Spezialisten. Wenn kein Konsens gefunden wird und keine Lösung gemeinsam konzipiert werden kann, so besteht immer noch die Möglichkeit, genau für diese eine Anforderung externes Wissen einzukaufen. Der Markt ist voll von Spezialisten, die sich genau für solche kniffligen Probleme anheuern lassen.

Jetzt kann man natürlich einwenden, dass Spezialisten schneller ihre Aufgaben lösen können, als Generalisten dies bewerkstelligen. Seine Gültigkeit hat die Aussage mit Sicherheit in den 20 Prozent, die man in Speziallösungen investiert. Bei Standards wird das aber nicht lange der Fall sein. Genau in diesen Aufgaben stellt sich schnell Routine ein und somit steigt die Effizienz auf einen hohen Wert.

Ob man nun mit einem Team von Spezialisten oder mit einer Team von Generalisten besser fährt, kann natürlich nicht pauschal beantwortet werden. Vor Projektbeginn sollte auf jedem Fall analysiert werden, wie außergewöhnlich die Aufgaben sind und wie stark man spezialisiert sein muss, um 80 Prozent der gestellten Aufgaben lösen zu können.

6 Baue nichts, was du nicht messen kannst

Neue Features sind etwas Tolles. Das denken nicht nur die Produktverantwortlichen, sondern auch die Kunden und sicherlich auch die Entwickler, die es umsetzen dürfen. Vergeht einige Zeit im Lebenszyklus des Produkts, hat man eine Menge Features gebaut, die alle als Erfolg eingeplant wurden, aber nur vielleicht zehn Prozent dürfen diesen Status für sich in Anspruch nehmen. In einer idealen Welt würde das Produktteam die erfolglosen Erweiterungen nehmen und sie wegwerfen, denn alles, was uns nichts bringt, verwirrt nur den Kunden. Mir ist kein Kunde bekannt, der eine Webseite aufgrund ihrer vielen nutzlosen Besonderheiten liebt.

Warum passiert das aber nicht? Schaut man sich den Großteil der vorhandenen Portale an, findet man jede Menge Nutzloses. Oft ist man als Seitenbetreiber selbst schockiert, dass eine Funktionalität schon seit einer Weile nicht mehr funktioniert, und niemand hat den Fehler gemeldet. Irgendetwas scheint also nicht zu stimmen mit der Wahrnehmung des Featurepaten bei dem Begriff „Erfolg".

Sicherlich ist es sehr schwer, sich einzugestehen, dass ein Konzept nicht gezündet hat, wenn es erst einmal live ist, denn schließlich kostet es ja auch nichts, wenn man es nicht weiterentwickelt, und es tut auch nicht weh. Im Nachhinein zu definieren, was Erfolg bedeutet, ist also keine Option, weil man sich hier zu leicht selbst hinters Licht führen kann und die Grenzen so tief ansetzt, dass man gerade noch im grünen Bereich ist. Dass dies nicht Sinn und Zweck sein kann, ist einem Außenstehenden klar. Das Prozedere muss also am Anfang, bereits bei der Konzeption, durchgeführt werden. Der Produktverantwortliche muss sich in seiner kreativen Phase fragen, was er sich von diesem Feature erwartet.

Mögliche Ziele könnten