Einer der wichtigsten Meilensteine auf dem Weg von Kaspersky Lab zu einem anerkannten, globalen Mitspieler der Sicherheitsbranche, war die Veröffentlichung der revolutionären Version 6.0 von Kaspersky Anti-Virus. Das Produkt, das im Jahr 2006 vorgestellt wurde, entwickelte sich auf dem weltweiten Antivirus-Markt zu einem riesigen Erfolg und machte Kaspersky Lab für Jahre zum Technologieführer der Branche. Es wäre nicht gerade bescheiden, wenn wir unser Produkt als beste Antivirenlösung der Welt bezeichnen würden, aber das haben schon zahlreiche Magazine und unabhängige Tests für uns erledigt. Der Weg zum Erfolg war durchwachsen und verrückt – und hoffentlich wird eines Tages ein Hollywood-Autor ein Drehbuch daraus machen, doch jetzt versuchen erst einmal wir selbst, die Erfolgsgeschichte mit Fotos, persönlichen Notizen und Erinnerungen des Original-Entwicklerteams zu erzählen. Wir hoffen, dass diese Geschichte auch ein Beispiel für junge Entwickler ist, die heute neue Apps und Services aufbauen – vorausgesetzt, sie sind ebenso besessen von der Idee, das Beste zu erschaffen. So wie es auch die Entwickler der „Sechs“ waren.

Problem 2003

Der Erfolg der „Sechs“ wurzelte in der totalen Katastrophe der Vorgängerversion. Diese Version hat nie das Tageslicht gesehen – zumindest nicht in ihrer ursprünglichen Form.

Um diese Katastrophe zu verstehen, müssen wir ins Jahr 2002 zurückreisen: Windows XP kam gerade auf den Markt, CPUs hatten endlich die 1 GHz-Grenze erreicht und die noch relativ junge Antiviren-Industrie stand kurz davor eine komplett neue Art von Bedrohungen zu entdecken. Alle Antivirus-Hersteller erweiterten die Fähigkeiten ihrer Produkte: Eine konkurrenzfähige Lösung musste damals eine Firewall, eine ständig laufende Systemüberwachung und Dutzende anderer Funktionen bieten.

Das Kaspersky-Team musste zugeben, dass die Lösung mit der starken Scan-Engine, die in den 1990er Jahren entwickelt wurde, beim Hinzufügen vieler neuer Funktionen unerträglich langsam werden würde – auch schon die bis dahin verkaufte Version 4.0 wurde von den Anwendern verdammt (alle möglichen Behauptungen, dass „Kaspersky langsam ist“ gehörten damals zur PC-Folklore). Deshalb wurde der Entwicklungsprozess für die neue Version 5.0 unter Berücksichtigung der wichtigsten Business-Grundlagen sorgfältig geplant: Es wurden ein neuer CTO, ein neues Entwicklungs-Framework und eine neue Antivirus-Architektur gewählt.

Die Firma stellte alle Ressourcen für dieses Projekt ab. Allerdings war nach einem Jahr klar, dass auch das Befolgen aller neuen Entwicklungsregeln nicht unbedingt ein wettbewerbsfähiges Produkt ermöglichen würde. Das resultierende System, das Unternehmens-Apps im Client-Server-Bereich nachahmte (die Architektur, die der CTO auswählte), schaffte es nicht, die Anforderungen des Markts an Antivirus-Produkte zu befriedigen. Die Software war langsam und schwerfällig, und die Zahl der Bugs sank während der Tests nicht – sie stieg sogar an.

„Ich begann, einige Leute – unserer Firmen-Veteranen – zu fragen, was sie darüber denken. Sie sagten, die Architektur sei das Entscheidende. Wie bei einem Kartenhaus: Verschiebt man an einem Element, fällt das ganze Haus in sich zusammen“, gibt Eugene Kaspersky zu. Also war es nicht sinnvoll, mit dem Projekt so weiter zu machen. Es musste komplett eingerissen und von Grund auf neu aufgebaut werden.

We can do it!

Das Entwicklungsteam von Kaspersky Lab wurde in zwei Gruppen aufgeteilt: eine, die versuchte, das Produkt unabhängig von der unglücklich gewählten Architektur zu reparieren, und eine zweite, die die Vorgängerversion 4.0 zu einem passenden neuen Produkt aufpolieren sollte.

Gleichzeitig beschloss eine Vierergruppe, ein komplett neues Produkt zu entwickeln, das nicht nur mit den Marktanforderungen Schritt halten, sondern auch für die Zukunft gerüstet sein sollte. Das Ziel, das sich das Entwicklungsteam der „Sechs“ gesetzt hatte, ist einfach zu erklären, aber schwer zu erreichen. Die neue Version sollte alle Viren davon abhalten, in den Computer einzudringen. Dafür musste sie schnell, gewandt, transparent und… nun ja, gutaussehend sein.

„Wir wollten einfach das beste Produkt erschaffen“, sagt das Team dazu. Der Rest der 200 Mitarbeiter sah ein sehr kleines Team, das vor einer monumentalen Aufgabe stand. Doch das kleine Team mit seiner herausfordernden Aufgabe konnte optimistisch sein, denn die Firmengründer Eugene Kaspersky und Alexey De-Monderik waren zu dieser Zeit auf der Suche nach einer Alternative für die Programmarchitektur – und sie entdeckten bald, dass es so eine Alternative gab, und dass diese von niemand anderem als dem Kaspersky-Team entwickelt worden war.

Hilfe aus Prag

Man muss kurz erwähnen, dass unter der Haube der Version 4.0 zwei Antivirus-Kerne (so genannten „Engines“) arbeiteten. Die Prüfung von Dateien wurde durch die alte, sehr zuverlässige (und durch zahlreiche international tätige Firmen, etwa G-Data und F-Secure, lizensierte) Version-3.0-Engine erledigt, die im Jahr 1996 entwickelt worden war. Die neuere Aufgabe des Filterns des Web-Verkehrs wurde durch den brandneuen und kraftvollen Mechanismus erledigt, der bei einem Brainstorming in Prag im Jahr 1998 erfunden worden war.

Diese Engine wurde „Prag“ genannt, auch wenn sie von Andrey Doukhvalov in Moskau entwickelt wurde, der bei dem Brainstorming in der tschechischen Hauptstadt nicht dabei war. Die Schlüsselideen wurden aber in Prag entwickelt und Andrey kam zum Team hinzu, um die Ideen zu optimieren und das Prag-Konzept umzusetzen.

Prag sollte ein reiner Antivirus-Kern sein, doch die dafür gesetzten Ziele waren so hoch, dass die neu entwickelte Engine so flexibel und genial war, dass sie auch kompliziertere Aufgaben übernehmen konnte. Die Frage war aber, ob es möglich sei, das ganze Produkt basierend auf Prag zu implementieren. Diese Frage beschäftige Eugene Kaspersky sehr, als er zu den Entwicklern sprach. Er erinnert sich noch gut daran:

„Ich fragte Victor Matyushenko, wie sich Prag im Produkt schlägt, und er sagte ‚Wie ein Fels in der Brandung!‘. Das war der Wendepunkt. Ich habe dann die Frage gestellt. Ich bin in das Büro gegangen, in dem Graf (De-Monderik) und Petrovich (Doukhvalov) arbeiteten und stellte ihnen die Frage: ‚Warum basieren wir das Produkt nicht komplett auf Prag?‘ Graf sagte etwas wie ‚Unmöglich, Prag ist dafür nicht gedacht‘, doch Petrovich zögerte. Am nächsten Morgen kam er mit einem kleinen Papierstapel in das Büro und sagte zu mir ‚Weißt du, ich habe ein paar Anwendungsfälle für Prag erstellt‘. Graf sah in an und sagte ‚Wir müssen reden‘. Danach kamen sie wieder zu mir und bestätigten, dass es wert sei, es zu versuchen.“

Wir starteten den Versuch mit einem sehr kleinen Team, das die ersten Code-Zeilen schrieb, aus denen später die „Sechs“ wurde.

„Wir sahen uns um, um Kollegen zu finden, die kreativ waren und etwas zu dem Projekt beitragen konnten, und haben dann ein erweitertes Team aufgebaut“, erinnert sich De-Monderik. „Da war zum Beispiel Pavel Mezhuev, ein Programmierer. Er war neu in der Firma, aber sehr schlau.  Dann Mike Pavlyuschik, mit dem wir schon lange zusammengearbeitet hatten. Er konnte fertige Ideen und Konzepte abliefern. Ich dachte damals schon, dass er einer der talentiertesten und fleißigsten Entwickler in unserem Bereich ist.“

 

Nach zwei Monaten des offenen, experimentellen Programmierens kamen wir zu der Überzeugung, dass aus dem Projekt eine kommerzielle Lösung werden würde. Nun brauchten wir nur noch einen Projektmanager.

Andrey Doukhvalov erinnert sich an ein Gespräch, das er mit De-Monderik führte:“Kennst Du Nikolay Grebennikov aus dem Büro nebenan? Er liest viel, ist jung und neu im Unternehmen. Nehmen wir doch ihn!“ Etwas später kam noch Andrey Sobko, ein Treiber-Programmierer, hinzu.

Was ist „Prag“

Dieses Kapitel ist vor allem für Software-Ingenieure interessant. Wenn Sie möchten, können Sie es gerne überspringen.

Sogar Anfang der 1990er Jahre, als die Antiviren-Branche gerade erst startete, gab es Viren, die mit normalen Signaturen nicht entdeckt werden konnten. So ist zum Beispiel ein polymorpher Virus, der seinen Code bei jeder Infizierung neu verschlüsselt, damit nicht erkennbar. Und als Software immer komplexer wurde, immer mehr Menschen das Internet nutzten und Schadprogramm-Autoren nicht mehr zum Spaß Viren programmierten, sondern ihre Dienste gegen Geld anboten, wurden Schadprogramme immer anspruchsvoller und vielseitiger. Selbst mit einer Engine, die neben der Signatur-basierten Entdeckung weitere Möglichkeiten bot, so wie es bei Kaspersky Lab der Fall war, mussten die Entwickler laufend die Antivirus-Engine aktualisieren, nicht nur die Signatur-Datenbanken, wenn sie ein Schadprogramm entdeckten, das neue Möglichkeiten nutzte. Das verbesserte die Reaktionszeit auf neue Viren, und dass Kaspersky Lab als erstes Unternehmen mit dem berüchtigten CIH-Virus (Chernobyl) fertig wurde, bewies, dass das Verringern der Reaktionszeit den Aufwand wert ist.

Damit sagte Eugene Kaspersky im Jahr 1998 den Kollegen, dass es Zeit sei, eine neue Antivirus-Engine zu entwerfen. Doch wo sollten sie das tun?

„Die Firma hatte nicht viel Geld“, so Kaspersky dazu, „und wir mussten den günstigsten Ort in der Nähe von Moskau finden, so dass wir die Stadt verlassen und abseits des Lärms und der Hektik über das Problem nachdenken konnten. Es sollte ein abgekoppleter Ort sein. Damals gab es noch kein WLAN. Als günstigster Ort stellte sich Prag heraus.“

Beim Nachdenken über die neue Antivirus-Engine kam das Kaspersky-Team zu dem Ergebnis, dass ein objektorientierter Ansatz die beste Lösung für die Engine-Ebene ist, denn jede zu analysierende Datei und jedes Objekt musste basierend auf seiner Struktur auseinandergenommen werden, und die Objekte darin mussten entdeckt, analysiert und geprüft werden. Das Objektmanagement musste komplett auf Laufzeitebene durchgeführt werden.

Alle existierenden Objektumgebungen wurden diskutiert und wieder verworfen, da sie zu unflexibel, zu speicherhungrig oder zu langsam waren. Doch eine Idee kam während der Diskussionen auf: die Entwicklung einer eigenen Umgebung, die Möglichkeiten zum Speichermanagement und weitere Service-Prozesse enthalten sollte, die dem Antivirenprogramm die Möglichkeit geben würden, potenzielle Schadprogramme schnell und effizient auseinanderzunehmen und zu analysieren.

Diese grundlegende Idee wurde von De-Monderik und Andrey Krykov in Prag geboren und durch die ersten Code-Zeilen von Doukhvalov und Kryukov unterstützt.

Dann hat sich vor allem Doukhvalov über ein Jahr mit Prag beschäftigt – das war ja auch der Grund, warum er bei Kaspersky Lab eingestellt worden war. Mit seiner Erfahrung in Software-Architektur, konnte Doukhvalov sicherstellen, dass Prag flexibel, skalierbar und einfach in das Produkt zu integrieren war, ohne irgendwelche architekturelle Beschränkungen zu verursachen. Das eigentliche Ziel war, eine Multiplattformlösung zu entwickeln.

Die Objekt-Hierarchie war eine Herausforderung beim Debugging, doch ein praktisches Nachrichten-Austauschsystem zwischen den Objekten und eine minimalistische Programmieroberfläche machten Prag zu einer einfach integrierbaren Architektur, die On-Demand genutzt werden konnte, wenn es passte.

„Das war als Komponente gedacht“, sagt Doukhvalov dazu. „Das bedeutet, dass die Komponente zu einem existierenden Programm hinzugefügt werden konnte. Das System war sehr offen, mit der Möglichkeit, Elemente hinzuzufügen und Verhaltensmuster zu ändern.“

Eine Komponenten-basierte Architektur, kompakt und Ressourcen-schonend, war allgemein als Basis für die Einführung radikal neuer Technologien in Kaspersky Anti-Virus 6.0 anerkannt. Diese konnten einfach implementiert werden. Und als Prag so angepasst wurde, dass es zur Basis für das ganze Produkt wurde, und nicht nur für die Antivirus-Engine, hat Pavel Mezhuev viel zur Feinabstimmung der Architektur beigetragen:

„Wir haben eine weitere Architektur-Lösung implementiert und ein Modell zur Trennung der Logik sowie ein Interface hinzugefügt. Zudem haben Doukhvalov und Mezhuev einen Task-Manager erstellt, der jeden einzelnen Prozess im Produkt kontrollieren konnte und die Wechselwirkung zwischen Prozessen war sehr einfach,“ so Nikolay Grebennikov, der Projektmanager für Kaspersky Anti-Virus KAV 6.0.

Das Prinzip der „Sechs“

Da die Experimentier- und erste Entwicklungsphase von einem kleinen Team ausgeführt wurde, war klar, dass ein mönströses Projektmanagement hier nichts bringen würde. Daher wurde ein Ansatz ähnlich SCRUM implementiert: Die Entwickler saßen in einem offenen Bereich und sprachen laufend miteinander – dadurch konnten sie alle Aspekte des Entwicklungsprozesses abdecken. So hat das Team der „Sechs“ gearbeitet.

Kurzprofil: SCRUM

SCRUM ist ein Ansatz des Projektmanagements für eine flexible Software-Entwicklungsumgebung. Das System basiert auf dem Prinzip, dass der Kunde (Anwender) nicht unbedingt weiß, was er braucht und die Anforderungen während des Prozesses ändern könnte. Das bedeutet, dass der Entwicklungsprozess durch konsequente und zahlreiche Zyklen gekennzeichnet ist: Aufbauen – Vorführen – Feedback analysieren – das Programm aktualisieren. Doch die Rollenverteilung von SCRUM wurde genau betrachtet. Kaspersky Lab hatte sechs Rollen:

Architekt

Der Architekt – aktiv in den Programmierprozess involviert – weiß, was gebaut wird und wie es gebaut wird.

Technischer Designer

Für diese Rolle gibt es keine einfache Definition. Der Technische Designer ist dafür verantwortlich, dass bestimmte Lösungen zum Leben erweckt werden. Noch wichtiger ist vielleicht, dass der Technische Designer wissen muss, wie Dinge NICHT gemacht werden sollen.

Erfinder

Der Erfinder nutzt ungewöhnliche Lösungen, um Probleme zu lösen. Bei der „Sechs“ gab es zahllose Probleme. Die Lösung sollte jeweils den besten Schutz bei der geringsten Ressourcen-Nutzung bieten.

Projektmanager

Die Rolle des Projektmanagers ist in SCRUM nicht strikt für die Steuerung vorgesehen. Er kontrolliert die Ressourcen und Abgabetermine, aber ist nicht unbedingt der Chef des Teams. Er sagt den Programmieren nicht, was sie zu tun haben, sondern motiviert sie, sich selbst zu führen. „Das Team war klein und wir hatten am Anfang nicht einmal jemanden, der der Chef war“, so Doukhvalov. „Der Manager plante und berichtete, doch die Entscheidungen zu dem Projekt wurden kollektiv getroffen.“

Marketing-Manager

Das Produkt wird für Kunden entwickelt, nicht für das Entwicklungsteam. Es ist also wichtig, zu verstehen, mit welchen Erwartungen die zukünftigen Anwender das Produkt beurteilen und wie sie es benutzen werden. Während die operativen Prinzipien von den Leuten definiert werden, die die Antivirus-Funktionen genau verstehen, so müssen bei Tausenden kleinen Dingen, etwa Einstellungen, Benachrichtigungen oder der Benutzeroberfläche, die Anwenderbedürfnisse berücksichtigt werden.

Psychologe

Unter Druck arbeiten, mit wenig Schlaf, Konflikten im Team, Unsicherheit… Irgendjemand muss sicherstellen, dass das Klima im Raum freundlich und produktiv bleibt. Diese Rolle wurde Eugene Kaspersky selbst zugewiesen, also kombinierte er sie mit der Rolle des Sponsors, der Geldmittel und Ressourcen für das Team zur Verfügung stellt und es von äußeren Einflüssen schützt.

Ehrlich gesagt, gibt es noch eine weitere Rolle, die für SCRUM-Projekte enorm wichtig ist – der Schreiber, der während des Prozesses Notizen macht. Doch diese Position blieb unbesetzt, und das führte zu Problemen.

„Wir wussten nicht, warum wir das so machten oder warum wir ein halbes Jahr vorher diese Entscheidung getroffen hatten“, bestätigt Eugene Kaspersky.

Prinzipiell muss die Zahl der Rollen nicht der Zahl der Teammitglieder entsprechen. Eine Rolle kann unter mehreren Personen aufgeteilt werden, während ein einziges Teammitglied mehrere Rollen übernehmen kann.

„Während wir eine formelle Organisation wahrten, haben wir als ein Team gearbeitet. Also waren die Grenzen zwischen den Rollen verwischt: Vor allem beim Brainstorming haben die Personen unterschiedliche Rollen eingenommen“, gibt Nikolay Grebennikov zu. „Es konnte immer sein, dass jemand eigentlich Programmierer war, aber seine Meinung zum Design sagte – und das zählte auch. Ich selbst war Projektmanager, habe aber auch an den Diskussionen teilgenommen – diese unscharfen Abgrenzungen haben wirklich zum Erfolg beigetragen, da wir uns um jeden einzelnen Aspekt des Projekts kümmerten.“

Laut De-Monderik konnten die Programmierer sehr gut ausgetauscht werden: „Jedes Teammitglied beherrschte seinen Bereich, doch 50 Prozent seiner Fähigkeiten überschnitten sich mit den Fähigkeiten von jemand anderem. Mike konnte Treiber programmieren, wenn Sobko nicht da war. Spezialisten für die Benutzeroberfläche konnten Aufgaben bei der Engine übernehmen und anders herum. Ich konnte statt Max Yudanov Designs machen und Kolya Grebennikov konnte manchmal Skins entwerfen.“

Wichtig ist, zu verstehen, dass jede Rolle zu einem bestimmten Zeitpunkt im Projekt die führende Rolle ist. Während der Anfangsphase ist der Architekt die zentrale Figur. Der Erfinder kommt in der Mitte des Projekts zu seinem großen Einsatz, wenn die Funktionen entworfen und entwickelt werden. Und in der Schlussphase ist der Manager der wichtigste Mann, denn nun enthält das Projekt viele Ressourcen, die ein strenges Management erfordern, so dass das Team den Abgabetermin halten kann.

Das Streben nach dem Ideal

Durch den SCRUM-ähnlichen Ansatz und die allgemeine Ehrgeizigkeit des Projekts, hatte die „Sechs“ keine statische Anforderungsliste. Die grundlegenden Anforderungen zeigten nur, welche Fähigkeiten das Programm haben sollte:

• Vollwertigen Schutz vor allen aktuellen Bedrohungen
• Optimierte Nutzung der PC-Ressourcen
• Komponentenbasierte Infrastruktur für bessere Skalierbarkeit
• Leichte Adaptierung der Komponenten für verschiedene Plattformen

 

Mit diesen Meta-Anforderungen durchliefen die dazugehörigen technischen Anforderungen der Produkte einige Änderungen. Dadurch wurde die Veröffentlichung immer wieder verschoben, doch das Team schaffte es, eine revolutionäre Lösung zu entwickeln, die den generellen Anforderungen des Markts einige Jahre voraus und auch schneller als die Vorgängerversion war.

Nach der Veröffentlichung von Kaspersky Anti-Virus 6.0 sagte Maxim Yudanov, der für das Design der Benutzeroberfläche verantwortlich war: „Ein wichtiges Unterscheidungsmerkmal des Projekts war, dass es keine ‚in Stein gemeisselte‘ Anforderungsliste gab. Wir haben Prototypen erstellt, das Produkt diskutiert, die Liste der technischen Anforderungen und Funktionen aktualisiert, die wichtigsten Punkte auf gelben Post-It-Zetteln aufgeschrieben und diese an unsere Monitore geklebt, haben Dinge vergessen, haben uns an andere Dinge erinnert, und unser Publikum um Hilfe gebeten (damit meine ich die Gemeinschaft der Beta-Tester). Ich bin sicher, das finale Produkt wäre nicht das geworden, was es wurde, wenn wir nur mit einer traditionellen Anforderungsliste gearbeitet hätten. Denn dann hätten wir eine Lösung entwickelt, wie wir sie uns zu beginn vorgestellt hätten. Ich bin sicher, dass das Produkt in diesem Fall viel schlechter gewesen wäre.“

Extrem-Programmieren

Heute ist dieser Ansatz nichts Neues mehr. Doch vor zehn Jahren war das bei so einem großen Projekt revolutionär und unkonventionell. Der Hauptunterschied zwischen dem so genannten ‚Extreme Programming‘ (damals wurde dieser Begriff oft verwendet, heute nennt man ähnliche Methoden meist ‚Agile Software Development‘) und dem bürokratischen CMM-Coding-Ansatz (der heute fast ausgestorben ist), liegt im Fehlen einer traditionellen Anforderungsliste, die – einmal genehmigt – als einzige Basis für die jahrelange Projektarbeit genutzt wird. CMM mag für ausgelagerte Entwicklungsprojekte passen, für kommerzielle Projekte ist es aber nutzlos.

Nikolay Grebennikov, heute CTO von Kaspersky Lab, stimmt dem zu: „Hätten wir mit einer festgelegten Zahl von Funktionen ohne Änderungsmöglichkeiten angefangen, hätten wir niemals mitbekommen, was die Anwender wirklich benötigen, und hätten auch nie deren Unterstützung in diesem Ausmaß erhalten. Die erste Version dieses Builds war kaum nutzbar und hatte viele Probleme. Für die Lösung dieser Probleme brauchten wir viel Zeit – fünf Quartale lagen zwischen der Alpha-Version und dem technischen Release. Heute kann man sich so einen Luxus nicht mehr leisten, aber damals war es eine nützliche Erfahrung.“

Eugene Kaspersky sagt ganz deutlich: „Wenn man Innovationen entwickelt, muss man auf laufende Verletzungen von Abgabeterminen gefasst sein.“

Das Leben bei der Arbeit

Die Hauptmitglieder des Entwicklungsteams denken nostalgisch an diese Zeit zurück. Wenig Schlaf, wenig Zeit für die Familie, kaum freie Wochenenden und emotionale Achterbahnfahrten – doch dafür schafften sie große Fortschritte und hohe Qualität.

Eine E-Mail, die Nikolay Grebennikov in dieser Zeit geschrieben hat, bietet einen recht poetischen Einblick:

„Irgendwann hörte es auf, einfach nur ein Projekt zu sein. Es war, wie wenn man in einem Spiel riesigen Ausmaßes mitmacht, in das man sich stürzt und es vom Anfang bis zum Finale durchlebt. In der U-Bahn auf dem Weg zur Arbeit ruft man sich die Gewinne und Verluste des zuletzt gespeicherten Spielstands in Erinnerung, dann macht man sich an die Arbeit und denkt man darüber nach, wie man zum nächsten Level kommen kann. Wenn man sein Kind ins Bett gebracht hat, lebt man wieder im Spiel, wo man alle möglichen erträumten Dinge machen kann, und in dem alles möglich ist.“

„Das war tatsächlich die beste Zeit meines Lebens“, erinnert sich Eugene Kaspersky. „In den Augen leuchtete der Enthusiasmus, überall klebten Post-It-Zettel, die Teammitglieder haben wenig geschlafen. Es war ein Hexenkessel voller Ideen und Action.“

Als das Team größer wurde, übertrug sich dieser Teamgeist vom Kern des Entwicklerteams auf die Neuankömmlinge, wie sich De-Monderik erinnert:

„Alle Teammitglieder arbeiteten gut, aber wir mussten uns auf den ‚harten Kern‘ verlassen, den Enthusiasmus anzufeuern. Dieser ‚harte Kern‘ hatte die zugrunde liegende Idee und stand vor der Herausforderung, das beste Produkt aller Zeiten zu entwickeln. Das war für uns das Hauptziel: Kolya (Grebennikov), Pavel Mezhuev, Doukhvalov, ich selbst, Mike Pavlyuschik… wir konnten unsere Begeisterung auf die anderen Teammitglieder übertragen. Wenn jeder um dich herum hart arbeitet und jeder im gleichen Raum sitzt, wenn man sieht, wie das alles passiert, und auch du selbst unbewusst alles gibst.“

Sogar das Projektmanagement trug Früchte, selbst wenn es recht informell gestaltet war.

„Wenn ich mich recht erinnere, hatten wir zu Beginn Status-Meetings“, so De-Monderik. „Das Team traf sich am Morgen und Kolya hielt eine kleine zusammenfassende Rede: Wir haben folgende Ressourcen, wir müssen heute diese Dinge erledigen… Darin war er richtig gut. Wir hatten ein riesiges Whiteboard, auf dem wir unsere Erkenntnisse aufgeschrieben und aufgezeichnet haben. Da wir kein großes Team waren, reichte das.“

Grebennikov räumt ein, der wichtigste Punkt dieser ganzen Erfahrung sei, dass ein Status-Meeting als formelle Methode der Projektorganisation nicht die Hauptsache ist. Man sollte das Team nur zusammenrufen, wenn das Meeting wirkliche Vorteile für das Projekt bringt.

Die größere Reichweite

Als sich das Projekt vom September 2003 bis zum März 2006 entwickelte, wurde das Team größer und am Veröffentlichungstag gehörten der Gruppe fast 30 Leute an. Mit mehr Anforderungen und dem Übergang in die Alpha-Phase, gehörten zum Team auch der Designer Maxim Yudanov sowie die Software-Ingenieure Pavel Nechayev, Denis Guschin, Eugene Roschin und Andrey Gerasimov. Sie brachten einige innovative Funktionen in das Produkt, etwa die Skin-basierte Benutzeroberfläche und die eingebaute Firewall. Zudem gehörten nun auch Installations-Spezialisten und Beta-Test-Betreuer zum Team. Doch einer der wichtigsten Schritte, die gemacht wurden, um Kaspersky Anti-Virus 6.0 zu modifizieren und zu verbessern, war der vom Entwicklerteam neu erfundene Ansatz, einen Forum-basierten Beta-Test zu starten.

Forum

Alle Beteiligten sind sich einig, dass das engagierte Tester-Forum dafür verantwortlich ist, dass Kaspersky Anti-Virus 6.0 zu so einem gut gestalteten und sorgfältig getesteten Produkt wurde. Der offene Beta-Test (der bei Kaspersky Lab seitdem immer gemacht wird) war damals eine echte Neuheit und ein Risiko, denn die Mitbewerber hatten dadurch ebenfalls eine Möglichkeit, sich schon vor der Veröffentlichung über die Produktfunktionen zu informieren.

„Wir haben das Risiko sehr ernst genommen, denn der Beta-Test enthüllt im Grunde den Beta-Code für Hacker und Mitbewerber“, so Grebennikov. „Daher war die Meinung dazu gespalten. Die Gegner konnten ihre Meinung sagen, ihre Argumente sind oben dargestellt. Doch auch die Befürworter haben solide Argumente für ihren Standpunkt präsentiert. Unsere Ressourcen waren beschränkt, da wir nur zwei Tester zur Verfügung hatten, während die restlichen Test-Kollegen dem Test der Version 5.0 zugewiesen waren. Unsere Lösung wurde von Null an entwickelt und wir benötigten eine große Gruppe, um die Tests durchzuführen. Zum ersten Mal nutzten wir den regelmäßigen Build-Update-Ansatz, zunächst wöchentlich, dann täglich. Der Test dieser Builds im Forum erlaubte es uns, qualitativ hochwertige Tests zu machen, ohne viele interne Ressourcen zu belasten.“

Alle Entwickler waren aktiv an den Forumsdiskussionen mit den Testern beteiligt.

„Während dieser Forums-Testphase gehörten über tausend Anwender zu den Beta-Testern, mit etwa 500 sehr aktiven Teilnehmern“, fügt Nikolay Grebennikov hinzu. Jede Nacht verbrachte er einige Stunden im Forum, manchmal schlief er sogar am Computer ein. Die Tester brannten darauf, einen neuen Build zu erhalten und diesen jeden Abend auszuprobieren – ohne Kosten für die Firma.

Die Forumsteilnehmer gaben sowohl Informationen zu Bugs weiter, als auch Vorschläge, wie das Produkt besser gemacht werden könnte. Ein Großteil dieses Feedbacks wurde berücksichtigt und hat zu Kaspersky Anti-Virus 6.0 beigetragen. Aber Vorschläge wurden nicht ausschließlich online gesammelt. Eugene Kaspersky erinnert sich daran, dass die Entwickler regelmäßig durch das ganze Bürogebäude gegangen sind und jeden – vom Sales Manager bis zu Support-Mitarbeitern – in den Test der Beta-Version einbezogen haben. Basierend auf den Rückmeldungen der Mitarbeiter, wurden weitere Verbesserungen vorgenommen: So wurde aufgrund eines Vorschlags des Support-Teams die Möglichkeit eingebaut, die Sprache mit einem einzigen Klick auf Englisch zu wechseln.

Doch die Verbesserungen, die von den Forumsdiskussionen kamen, hatten ihren Preis – vor allem in weiteren Verletzungen von Abgabeterminen.

„Basierend auf dem Feedback der Forumnutzer erhielten wir eine riesige Liste mit Verbesserungsvorschlägen, doch zu diesem Zeitpunkt merkte ich, dass wir nicht mehr hinzufügen können, als wir schon hinzugefügt haben, selbst wenn mancher Vorschlag verlockend war. Wir standen unter einer engen Planung und mussten die Version im zweiten Quartal 2006 veröffentlichen. Das haben wir gerade noch geschafft: am 31. März um 6:30 Uhr abends“, erzählt Nikolay Grebennikov.

Veröffentlichung

Erfolg

Unter dem Strich hat es das immer noch recht überschaubare Team geschafft, ein Produkt mit einem phänomenal kompakten Installer, einer tollen Benutzeroberfläche mit austauschbaren Skins, geringen Ressourcenanforderungen für den PC und – ganz wichtig – vollgepackt mit starken und innovativen Funktionen zu entwickeln. Unter anderem einem proaktiven Schutz, der verdächtige Programme basierend auf deren Verhalten blockieren konnte.

„Bei Symantec waren sie baff, als uns amerikanische Magazine mit goldenen Sternen auszeichneten. Wir haben überall Bestnoten bekommen“, freut sich Eugene Kaspersky.

Dank etablierter Partnernetzwerke in Europa, den USA und China war das erfolgreiche Produkt sofort überall erhältlich, und die Bestseller-Regale in den Läden füllten sich mit grünen Schachteln.

Der Erfolg der „Sechs“ kam durch die gut gewählte Architektur, die es erlaubte, ganz einfach technische Innovationen einzuführen, und die eine hohe Leistung ermöglichte, aber auch durch den Entwicklungsansatz, der zu hundert Prozent zu dem kleinen, enthusiastischen Team passte. Das ist wahrscheinlich die wichtigste Erkenntnis der ganzen Arbeit: Um ein Projekt absolut erfolgreich zu machen, müssen Architektur und die Entwicklungstechniken gut abgestimmt sein, um zum Entwicklungsteam und dem Ausmaß des Projekts zu passen.

Sechs Rollen und eine Kaffeemaschine

„Im SCRUM-Manuskript, das wir damals nutzten, habe ich eine interessant Regel entdeckt, die ich nun auch in vielen anderen Bereichen außerhalb der Software-Entwicklung anwende „, so Kaspersky. „Wenn sich etwas in den Weg des Entwicklungsprozesses stellt, sollte es sofort eliminiert werden. Punkt. Egal, um was es sich handelt. Das bedeutet aber auch, dass wenn ein Entwickler etwas benötigt, er es sofort bekommen sollte. Eines Tages habe ich gefragt: ‚Was braucht ihr unbedingt?‘ Petrovich antwortete ‚Eine Kaffeemaschine‘. Am nächsten Morgen hatten sie eine teure Luxus-Kaffeemaschine. Und wir haben es geschafft!“