La regla del “Seis”

Uno de los momentos más importantes que llevaron Kaspersky Lab a ser una de las empresas protagonistas en el campo de la seguridad TI fue el lanzamiento de la revolucionaria versión de Kaspersky Anti-Virus 6.0. Presentado oficialmente en 2006, el producto fue un verdadero éxito en el mercado global de antivirus; a partir de entonces y en los años que siguieron, Kaspersky Lab se convirtió en empresa líder en el sector. Decir que nuestro producto es la mejor solución antivirus en el mundo sería pecar de presunción, pero es lo que opinaron muchas revistas especializadas y portales independientes.

El camino hacia el éxito fue duro y lleno de imprevistos y tal vez un día alguien de Hollywood hará una película sobre nosotros; de momento, os contaremos nuestra historia de éxito con fotos, notas y recuerdos proporcionados por el equipo original de desarrolladores. Esperemos que esta historia sea un ejemplo para los jóvenes desarrolladores que hoy en día crean servicios y aplicaciones, para que aspiren a ser los mejores, como fueron los que crearon la versión “Seis”.

Una foto histórica, sacada el día del lanzamiento técnico de la versión “Seis”

2003: un año difícil

El éxito de “Seis” se debió a la versión anterior del producto, que fue un desastre total. De hecho la quinta versión nunca vio la luz del sol tal y como se pensó al principio.

Para entender la razón de este fracaso, tenemos que volver al año 2002: Windows XP acababa de salir, por fin las CPU podían llegar al 1 GHz de memoria de reloj y la industria antivirus, relativamente joven, todavía no era capaz de detectar muchas amenazas. Todas las empresas antivirus extendían las funcionalidades de sus productos: por entonces, una solución competitiva tenía que comprender un firewall, un monitor de sistema de archivos en continuo funcionamiento y otra decena de características.

Con un potente sistema de análisis construido en los años 90, el equipo de desarrolladores de Kaspersky admitió que una solución con más características habría sido demasiado lenta (ya la versión 4.0 no había gustado nada a los usuarios, sus comentarios de que “Kaspersky era lento” estaban a la orden del día). Por eso durante el proceso de desarrollo de la versión 5.0 se analizaron todos los más mínimos detalles y en particular se prestó mucha atención y se hicieron algunos cambios: se nombró a otro Director de tecnologías de la información, se adoptó un nuevo sistema de desarrollo y se eligió una nueva arquitectura antivirus.

La empresa invirtió todos sus recursos en este proyecto. Después de un año, se llegó a la conclusión que todas las nuevas reglas en el desarrollo no habrían garantizado la creación de un producto competitivo. El sistema, que recordaba a las aplicaciones cliente-servidor (fue ésta la línea establecida por el Director de tecnologías), no era capaz de cumplir con los requisitos que otros productos antivirus del mercado cumplían. Se trataba de un software lento y pesado y, pese a las pruebas llevadas a cabo frecuentemente, el número de bug seguía creciendo.

“Empecé a pedir opinión a los veteranos de la empresa. Me contestaron que todo dependía de la arquitectura. Era como un casillo de naipes, cuando arreglabas una cosa, se venía abajo toda la estructura”, admitió Eugene Kaspersky. No tenía sentido continuar con el proyecto de esa forma: había que volver a empezar desde cero.

¡Lo conseguiremos!

El equipo de desarrolladores de Kaspersky Lab se dividió en dos grupos: uno intentaba arreglar el producto aunque la arquitectura elegida no fuera la más adecuada, otro intentaba mejorar la versión 4.0 para que pudiera valer como nuevo producto.

Al mismo tiempo, un grupo de cuatro personas decidió crear un producto completamente nuevo que no solo pudiera satisfacer los requisitos del mercado, sino que pudiera hacer de referente en el futuro. El objetivo establecido por los desarrolladores de la versión “Seis” era fácil de explicar pero difícil de concretar. La nueva versión tenía que bloquear todos los virus y las amenazas que pudieran entrar en el sistema, tenía que ser rápida, ágil, transparente y… también agradable a la vista.

“Solo queríamos hacer el mejor producto”, recuerda el equipo de “Seis”. Un equipo muy reducido que iba a enfrentarse a un reto enorme: era esto lo que pensaba el resto de los 200 empleados de la empresa. No obstante, el equipo tenía sus razones para ser optimista acerca esta misión tan desafiante: los fundadores de la empresa, Eugene Kaspersky y Alexey De-Monderik estaban buscando alternativas para una nueva arquitectura y habían descubierto que existía una alternativa válida, que solo el  equipo de Kaspersky Lab había encontrado.

Ayuda desde Praga

Hay que decir que en la versión 4.0., los dos núcleos antivirus (los “motores”) trabajaban juntos. Los archivos se controlaban a través del antiguo y todavía activo motor desarrollado en 1996 de la versión 3.0 (cuya licencia se vendió a muchas compañías internacionales, desde G-Data a F-Secure). El nuevo objetivo de hacer más eficaz el proceso de filtro del tráfico Web estaba en las manos de un nuevo y potente mecanismo ideado durante una sesión de brainstorming que tuvo lugar en Praga en 1998.

En honor de la ciudad, se bautizó el motor con el nombre de “Praga” (Prague en inglés), no obstante Andrey Doukhvalov, que no acudió a las reuniones en la capital de la República Checa lo desarrolló en Moscú. De todas formas, las ideas más importantes nacieron en Praga y Andrey entró en la empresa para aportar más ideas e implementar el proyecto.

Praga tenía que ser únicamente un núcleo anti-virus, pero su flexibilidad y genialidad podía suportar incluso los sistemas más complicados. La duda más importante, es decir, si era posible crear un producto entero con Praga como base, era la que más preocupaba  a Eugene Kaspersky. Él mismo nos cuenta:

“Una vez pregunté a Victor Matyushenko si Praga podía encajar bien con el producto y él me contestó que el núcleo era “¡sólido como una roca!”, lo que era el nudo de la cuestión. Entonces hice la pregunta. Entré en la habitación donde trabajaban Graf [De-Monderik] y Petrovich [Doukhvalov] y les hice la pregunta: ‘¿Por qué no basamos el producto entero en Praga?’ Graf dijo algo como ‘imposible, no hemos diseñado Praga por esto’, mientras Petrovich dudó. Al día siguiente vino con una pequeña pila de hojas y me dijo: ‘he pensando en algunos casos de uso para Praga’. Graf le miró y dijo ‘tenemos que hablar’. Luego los dos vinieron hacia mí y me confirmaron que valía la pena intentarlo”.

El ensayo empezó con un equipo muy reducido de personas, que escribió las primeras líneas del código; ésta fue la base  de lo que luego fue la versión “Seis”.

“Empezamos a buscar personas que pudieran aportar ideas creativas y organizamos un grupo más extenso”, nos cuenta De-Monderik. “Estaba Pavel Mezhuev, un programador que acababa de llegar pero era muy bueno. Luego estaba Mike Pavlyuschik, con quien trabajábamos desde hacía tiempo, capaz de sacar ideas y conceptos de la nada. Era uno de los creadores más prolíficos y con más talento en el sector”.

Después de dos meses de investigación y experimentos libres sobre los códigos, decidimos que se podía pensar en un producto para la venta. En ese punto solo necesitábamos un gestor de proyectos.

“¿Te acuerdas de Nikolay Grebennikov del despacho de al lado? Lee mucho, es joven y es nuevo en la empresa. ¡Le elegimosl!” nos cuenta Andrey Doukhvalov sobre una conversación que tuvo con De-Monderik.  Andrey Sobko, ingeniero de driver software, entraría en el equipo un poco más tarde.

Qué es ‘Praga’

Esta sección interesará sobre todo los ingenieros de software. El resto de los lectores puede saltarla tranquilamente.

A principios de los años 90, como la industria antivirus acababa de mover sus primeros pasos, había algunos virus que no se podían detectar por su firma. Por ejemplo no se puede individuar un virus polimorfo que cifra su código analizando las firmas. Con el tiempo, los software antivirus llegaron a ser más complejos y también los virus: si al principio crear piezas de malware era una especie de juego, con el tiempo pasó a ser un mercado muy lucrativo. Incluso después de integrar más funcionalidades al algoritmo capaz de detectar las firmas (como hacía Kaspersky), los desarrolladores se vieron obligados a actualizar constantemente el antivirus, y no solo las bases de datos de las firmas, sino también su estructura para encontrar un nuevo método de detección de las amenazas. De este modo se ralentizaba de manera significativa el tiempo de reacción frente a los nuevos virus: el éxito que Kaspersky Lab obtuvo después de ser la primera empresa capaz de curar el peligroso virus CIH (Chernobyl), demostró que merecía la pena esforzarse para reducir estos tiempos de reacción.

Considerando esta situación, en 1998 Eugene Kaspersky dijo a sus compañeros que había llegado el momento de crear un nuevo motor antivirus. ¿Adónde habría llevado todo esto?

“La empresa no tenía dinero”, nos cuenta Eugene Kaspersky “y teníamos que encontrar un lugar no tan lejos de Moscú, el más barato posible, donde alejarnos de todo y concentrarnos. El sitio tenía que ser lo más aislado posible. Por entonces no había redes WiFi en los alrededores. El lugar más barato resultó ser una capital europea, Praga”.

Después de reflexionar sobre una nueva versión del motor antivirus, el equipo de Kaspersky Lab llegó a la conclusión de que lo mejor para el motor era mejor utilizar una programación orientada a objetos; eso quiere decir que cada archivo u objeto tenía que ser diseccionado en todas las partes que formaban su estructura. Luego se detectaban, analizaban y verificaban los diferentes objetos en su interior. La gestión total del objeto tenía que realizarse en tiempo de ejecución.

Se analizaros todos los entornos orientados a objetos disponibles y todos fueron rechazados porque eran poco flexibles, utilizaban mucha memoria o eran muy lentos. Durante varias reflexiones surgió una idea: desarrollar un nuevo entorno, capaz de incluir funcionalidades para la gestión de la memoria y otros procedimientos, para que el antivirus pudiera diseccionar y analizar cualquier potencial código malicioso de manera rápida y eficaz.

Esta idea innovadora se debe a Andrey Kyrkov y De-Monderik en Praga, soportada por las primeras líneas del código de Doukvalov y Kryukov.

Durante más de un año, sobre todo Doukhvalov continuó trabajando sobre Praga, de hecho Kaspersky Lab lo contrató por esto. Gracias a su experiencia en el campo de la arquitectura, Doukhvalov hizo que Praga fuera un sistema flexible, escalable y que se pudiera insertar en los productos sin limitaciones desde el punto de vista de la arquitectura. Finalmente, el objetivo fue construir una solución multiplataforma.

Fue bastante difícil remover la jerarquía de los objetos pero, gracias a un cómodo sistema de intercambio de mensaje entre los objetos y a una interfaz de programación minimalista, Praga llegó a ser una arquitectura integrada y lista para usarse.

“Ideamos un sistema basado en componentes”, nos especifica Doukhvalov con orgullo. “Esto significa que se pueden añadir componentes a un programa existente. Se trata de un sistema muy abierto que ofrece la posibilidad de añadir elementos  y modificar los esquemas de comportamiento”.

Una arquitectura basada en componentes, compacta y que no utilizase muchos recursos constituía los requisitos fundamentales para introducir unas tecnologías totalmente nuevas en KAV 6.0. La implementación fue fácil. Además, cuando se decidió que Praga iba a ser la base del producto entero y no solo un motor antivirus, Pavel Mezhuev se esforzó mucho en refinar la arquitectura:

“Implementamos otra solución para la arquitectura, utilizando un modelo con lógica de negocio e interfaz separadas. Además, Doukhvalov y Mezhuev crearon un administrador de tareas capaz de controlar cada proceso del producto, y también la reciprocidad de los procesos era muy sencilla”, nos explica Nikolay Grebennikov, el gestor de proyecto de entonces para KAV 6.0.

El principio de “Seis”

Ya que un pequeño grupo de personas se ocupó del ensayo y de la fase inicial de desarrollo, una gestión del proyecto a lo grande no encajaba bien con un equipo tan reducido. Así que se decidió adoptar un marco de trabajo similar al modelo SCRUM: los desarrolladores trabajaban en un espacio abierto e interactuaban continuamente; así se podían cubrir todos los aspectos del proceso de desarrollo. De este modo el equipo trabajó en el “Seis”.

Definición: SCRUM

SCRUM es un modelo de gestión de proyectos para el desarrollo de software. Se basa en la idea de que el cliente (usuario) no sabe exactamente lo que necesita y podría cambiar sus peticiones en el acto. De ese modo, el proceso de desarrollo está caracterizado por la presencia de diferentes fases: construcción, demonstración, análisis de respuestas, y finalmente actualización de la versión.

La distribución de los roles de SCRUM cambió de manera significativa. Eugene Kaspersky defino seis roles principales:

Arquitecto

Es la persona (involucrada activamente en el proceso de creación de códigos) que sabe qué construir y cómo hacerlo.

Diseñador técnico

No hay una definición única para este rol, de todas formas es una persona que se ocupa de hacer realidad algunas ideas y soluciones. Tal vez lo más importante es que el diseñador técnico sabe cómo NO se deben hacer las cosas.

Inventor

El inventor encuentra  soluciones no convencionales a los problemas. En el caso de “Seis” siempre surgían nuevos problemas. La cuestión más importante era proporcionar a los usuarios el mejor nivel de protección intentando utilizar la menor cantidad de recursos del sistema.

Gestor de proyectos

En el SCRUM el rol del gestor de proyectos no sigue reglas establecidas. Se ocupa de controlar los recursos y que se respeten los tiempos de entrega, pero no es un jefe. No da órdenes a los que se ocupan de crear los códigos pero les anima para que tomen sus decisiones y hagan bien su trabajo.

“Como se trataba de un equipo pequeño, al principio ni teníamos un jefe”, recuerda Doukhvalov. “El gestor de proyectos se ocupaba de organizar y hacer informes, pero tomábamos todas las decisiones de manera conjunta”.

Gestor de marketing

Un producto se crea para los clientes y no para el equipo de desarrolladores. Por eso es fundamental saber lo que los usuarios esperan del nuevo producto y como lo van a utilizar. Si los expertos se ocupan de todos los aspectos técnicos del producto antivirus, es necesario también pensar en otros detalles como definir las opciones de configuración, los mensajes y crear una interfaz de usuario intuitiva. Todas estas características tienen en consideración las necesidades del usuario y el gestor de marketing se ocupa de entender estas necesidades.

Psicólogo

Trabajar bajo presión, dormir muy poco, conflictos entre algunos miembros del grupo, inestabilidad… Es necesario que alguien cree un ambiente relajado y productivo. De todo esto se encargó Eugene Kaspersky que, por un lado proporcionaba a su equipo apoyo y recursos para que pudiera y, por el otro, le protegía de influencias externas.

Hay que decir que, en los proyectos SCRUM, existe otro rol fundamental, o sea quien se ocupa de tomar nota de todo lo que ocurre durante el proceso de desarrollo. Pero no había nadie con este cargo y eso fue un problema.

“En serio, no sabemos el porqué, pero introducimos este rol solo hace un año”, nos dice Kaspersky.

Teóricamente, un rol puede estar cubierto por más personas y, viceversa, una persona sola puede ocupar roles diferentes.

“Aunque teníamos una organización formal, actuábamos como un equipo, así que no había una distinción exacta entre los diferentes roles: en particular, todo se mezclaba durante las sesiones de brainstorming”, confiesa Nikolay Grebennikov. “Por ejemplo, una persona que se ocupaba de crear los códigos podía expresar su opinión sobre el diseño de la aplicación y esta opinión se tomaba muy en cuenta. Yo era Gestor de proyectos pero participaba activamente en los debates; a esta flexibilidad debemos el éxito del proyecto, porque todos juntos nos preocupábamos de cada detalle”.

Según De-Monderik, los roles eran intercambiables: “Cada miembro del equipo era el mejor en su campo, pero el 50% de las habilidades de cada uno coincidían con las de alguien más en el equipo.  Mike podía ocuparse de los códigos si Sobko no estaba, los especialistas que se ocupaban de la interfaz podían ocuparse de algunas tareas de ingeniería y viceversa. Yo podía ocuparme del diseño en lugar de Max Yudanov y a veces Kolya Grebennikov podía ocuparse del diseño también”.

Es importante decir que cada rol se ocupaba de una fase específica del proyecto. Durante la fase inicial, el arquitecto es la figura más importante. Luego llega el inventor en la fase intermedia del proceso de desarrollo cuando se crean las nuevas funcionalidades. Durante la fase final, es el gestor de proyecto el que tiene el papel más importante porque gestiona diferentes recursos para que todo el equipo respete los tiempos de entrega establecidos.

En búsqueda de la perfección

Con el modelo SCRUM y un proyecto tan ambicioso, para “Seis” no se había establecido un listado fijo de requisitos pero sí existían unas especificaciones básicas. El producto tenía que:

• Defender el equipo de las amenazas en constante evolución;
• Aprovechar los recursos del PC de la mejor manera posible;
• Disponer de los componentes necesarios para una mejor escabilidad;
• Tener unos componentes capaces de adaptarse fácilmente a las diferentes plataformas.

Con estas características generales, los requisitos técnicos correspondientes necesitaban cambios continuos. De ahí que la publicación del producto se pospuso muchas veces, pero el equipo consiguió desarrollar una solución antivirus revolucionaria con una ventaja de un par de años en comparación con el resto del mercado, un resultado superior a cualquier expectativa.

Después del lanzamiento de Kaspersky Anti-Virus 6.0, Maxim Yudanov, responsable de la interfaz de usuario, dijo: “una de las peculiaridades del proyecto era la ausencia de un listado establecido de requisitos. Creamos prototipos, analizamos todos los detalles del producto, actualizamos el listado de las características y de los requisitos técnicos, nos apuntamos los detalles que faltaban cada vez que surgían en unos pósits que pegábamos a las pantallas de los ordenadores y pedimos ayuda a los usuarios para que nos dijeran lo que echaban en falta en el producto (es decir, la comunidad que testeaba las versiones beta). Estoy seguro de que el resultado final no habría sido el mismo si hubiéramos utilizado el sistema tradicional de requisitos fijos e inmutables. Con este método habríamos creado un producto anclado a la idea original y seguramente habría tenido características menos eficaces que las que hay en nuestro producto final.

Programación extrema

Hoy en día este método es el usual. Pero hace diez años se trataba de  algo no convencional y revolucionario. La diferencia más relevante entre la llamada “programación extrema” (un término ampliamente utilizado por entonces, ahora los métodos similares se reagrupan bajo la definición de “desarrollo ágil de software”) y el tradicional Modelo de capacidad y madurez o CMM (que prácticamente ya no existe) está en la ausencia de un listado de requisitos que constituya una referencia sólida para el proyecto durante los años de desarrollo. El modelo CMM puede ser adecuado para los proyectos de desarrollo externos, pero no funciona para proyectos realizados con fines comerciales.

Nikolay Grebennikov, ahora Director de tecnologías de la información de Kaspersky Lab, opina lo mismo: “Si hubiéramos tenido que establecer una serie de características fijas sin posibilidad de aportar ningún cambio, no hubiéramos tenido una visión acertada de lo que los usuarios necesitaban exactamente y no hubiéramos tenido su apoyo. La primera versión del producto daba un montón de problemas y para solucionarlos tardamos mucho tiempo, pasó más de un año y medio entre la versión alpha y el lanzamiento técnico. Hoy en día ya no podemos perder todo este tiempo pero entonces se trató de una experiencia verdaderamente constructiva”.

La agenda de desarrollo (en ruso)

Eugene Kaspersky es muy directo sobre este tema: “Cuando desarrollas productos innovadores, prepárate para no respetar casi nunca los tiempos establecidos”.

Vida en el trabajo

Los miembros más importantes del equipo que desarrolló la versión KAV 6.0 recuerdan con nostalgia esa época de sus vidas. Dormían poco, no pasaban mucho tiempo con sus familias, no tenían fines de semana libres, vivían una marea de emociones diferentes pero todos sus esfuerzos hacían avanzar el trabajo.

Uno de los mails que Nikolay Grebennikov escribió durante el proyecto nos da una visión poética de la historia:

“Llegamos a un punto en que ya no era sólo un proyecto. Era como formar parte de un juego que se hacía cada vez más grande y potente, que te enganchaba hasta llegar al final. Cuando estabas en el metro, te ponías  a pensar en los logros y de los fallos de la última partida; luego llegabas al trabajo y pensabas en cómo jugar para llegar al siguiente nivel. Ponías tus hijos a dormir y te enganchabass otra vez al proyecto: estábamos en un juego donde era posible realizar cualquier cosa que podíamos imaginar”.

“Había llegado nuestro momento”, recuerda Kaspersky. “Nuestros ojos brillaban de entusiasmo, había pósits por todas partes, todos los miembros del equipo ya casi no dormían. Una tormenta de ideas y acciones”.

Con un equipo ahora más grande,  el espíritu y el entusiasmo de los veteranos pasaron a los nuevos miembros, como recuerda De-Monderik:

“Ya que todo el equipo trabajaba bien, era el grupo “núcleo” el que tenía que encargarse de mantener vivo el entusiasmo. La idea principal del núcleo, y un desafío al mismo tiempo, era realizar el mejor producto antivirus nunca antes hecho. Era nuestro objetivo primario: Kolya [Grebennikov], Pavel Mezhuev, Doukhvalov, Mike Pavlyuschik, yo… éramos capaces de transmitir nuestro entusiasmo a todos los otros miembros del equipo. Cuando todo el mundo trabaja muy duro, estás en el mismo despacho con los otros y ves lo que está pasando, también te comprometes a hacerlo lo mejor que puedas”.

Aunque la gestión del proyecto fuera bastante informal, se obtuvieron los resultados esperados.

“Si no recuerdo mal, al principio teníamos reuniones de estatus, dice De-Monderik. “Por la mañana, cuando llegaba todo el grupo, Kolya nos hacía un resumen de los recursos que teníamos, el trabajo hecho etc. Lo hacía muy bien. Teníamos una pizarra blanca enorme donde escribíamos y dibujábamos nuestros descubrimientos. Como éramos un equipo bastante reducido, sólo nos hacía falta esto”.

Grebennikov reconoce que estas reuniones para organizar el trabajo tenían sentido no sólo  porque representaban una manera formal de llevar a cabo el proyecto. También eran importantes porque cada vez se salía de ahí con algo nuevo, y esto era muy bueno para el proyecto.

Ampliar el límite

Con la evolución del proyecto, desde septiembre de 2003 a marzo de 2006, el equipo creció cada vez más hasta llegar a casi 30 personas el día del lanzamiento del producto.  Ya que surgieron otros requisitos que cumplir y a causa de la transición a la etapa “Alpha”, el equipo incluyó también a Maxim Yudanov, diseñador, Pavel Nechayev, Denis Guschin, Eugene Roschin y Andrey Gerasimov, ingenieros de software. Ellos introdujeron otras funcionalidades innovadoras, incluso una interfaz de usuario más ligera y un firewall interno. En el grupo entraron también especialistas de instalación y supervisores del beta testing. De todas formas, el equipo de “Seis” introdujo una novedad que ayudó a modificar y refinar la estructura de KAV 6.0: un foro de  beta testing.

Foro

Todos los accionistas admitieron que Kaspersky Anti-Virus 6.0 salió como un producto bien diseñado y testeado con atención gracias a la aportación del foro en la fase de beta testing. El testeo público de la versión beta (que llegó a ser una práctica habitual en Kaspersky Lab) en aquel momento fue una verdadera innovación y al mismo tiempo un riesgo: también los competidores podían conocer las características del producto antes de su lanzamiento.

“Tomamos este aspecto muy en serio ya que el beta testing exponía el código beta a las acciones de hackers y competidores”, dijo Grebennikov.  “Cada uno tenía su opinión al respecto. Los que se oponían proponían los argumentos que acabamos de mencionar. Pero los que estaban a favor también propusieron sus buenos puntos de vista. Nuestros recursos eran limitados, sólo teníamos dos personas a disposición para testear el producto mientras todos los demás estaban ocupados en analizar la versión 5.0. Habíamos creado el producto desde cero, necesitábamos un grupo bastante grande para llevar a cabo los tests. Por primera vez, adoptamos la costumbre de lanzar actualizaciones regularmente, primero una vez a la semana, luego diariamente. Utilizar el foro para testear el producto nos garantizaba la máxima calidad de trabajo sin involucrar a muchos trabajadores internamente.

Todos los desarrolladores participaron activamente en las discusiones del foro e interactuaron con los que testeaban el producto.

“En la fase de test con el foro, contábamos con la ayuda de miles de usuarios y más o menos 500 personas formaban parte del núcleo más importante”, nos cuenta Nikolay Grebennikov. Cada noche, Nikolay pasaba horas y horas en el foro, incluso a veces se quedaba dormido delante de la pantalla. Los usuarios querían probar nuestro nuevo producto a toda costa y normalmente lo hacían por la noche y sin ningún coste para la empresa.

Los participantes del foro informaban de la presencia de bugs y daban consejos sobre cómo mejorar el producto. Los desarrolladores tomaron en cuenta una gran parte de estos comentarios, que fueron muy útiles para perfeccionar KAV 6.0. Además, no se recopilaron sólo sugerencias a través de Internet. Kaspersky recuerda que los desarrolladores involucraron prácticamente a todos los que trabajaban en la empresa, desde los comerciales a los empleados del servicio de atención técnica. Gracias a sus aportaciones se pudo mejorar mucho el producto: por ejemplo, gracias a la sugerencia del equipo de atención técnica, se decidió dar la posibilidad de cambiar con un sólo clic el idioma al inglés.

Como ya hemos dicho, para que todas estas mejoras se hicieran realidad se necesitaba tiempo, así que no se respetaron las fechas de entrega establecidas.

“Gracias a las sugerencias de nuestros usuario en el foro, teníamos un listado importante de mejoras que teníamos que hacer, pero me di cuenta de que no podíamos añadir funcionalidades sobre lo que ya había hecho, incluso cuando había un petición de cambio muy urgente. Estábamos obligados a lanzar el producto en los primeros meses de 2006. Utilizamos todo el tiempo que teníamos a nuestra disposición y lo lanzamos a las seis y media de la tarde del 31 de marzo”, nos cuenta con énfasis Nikolay Grebennikov.

Lanzamiento

Éxito

Como resultado final nuestro equipo, un poco más grande que al principio pero todavía bastante reducido, desarrolló un producto con un instalador extraordinariamente compacto, una interfaz de usuario ágil basada en skins intercambiables; un producto que afectaba al mínimo las prestaciones del equipo y caracterizado por funcionalidades innovadoras y potentes como la protección proactiva, capaz de bloquear las aplicaciones sospechosas mediante el análisis de sus comportamientos.

“Los de Symantec se quedaron de piedra cuando las revistas americanas empezaron a dar valoraciones muy altas a nuestro AV 6.0. Recibimos las mejores puntuaciones prácticamente en todas las revistas”, Eugene Kaspersky afirma con orgullo.

Gracias a nuestra red de colaboradores en Europa, EE.UU y China, este producto de éxito llegó enseguida a las tiendas y se ganó su sitio entre las soluciones antivirus más vendidas.

El éxito de “Seis” se debe a su arquitectura cuidadosamente diseñada, gracias a la cual se introdujeron innovaciones técnicas y se pudo llegar a alcanzar prestaciones de gran nivel; además, el modelo de desarrollo encajó perfectamente con las necesidades de un equipo seleccionado y al mismo tiempo muy ilusionado con el proyecto. Podemos decir que estos fueron los ingredientes de la receta del éxito que permitieron sacar a la venta Kaspersky Anti-Virus 6.0, un producto que garantiza a sus usuarios el 100% de protección.

Seis roles y una máquina de café

“Entre las reglas del modelo SCRUM que establecimos, hay una que aplico también a otros ámbitos”, afirma Eugene Kaspersky. “Si durante el proceso de desarrollo nos enfrentamos a un elemento que pueda ralentizar el proceso, lo primero que hay que hacer es eliminar este elemento. Y punto. Da igual lo que sea. Esto significa que, si un desarrollador necesita algo, lo que sea, lo tendrá enseguida”.

“El primer día del proyecto pregunté: ‘¿Qué necesitáis antes que nada?’ Petrovich me contestó ‘Una máquina de café’. Al día siguiente, tuvieron la mejor máquina de café que había a la venta. ¡Y lo conseguimos!”

Este tótem, que estuvo presente en todas las fases del proyecto, fue la primera máquina de café de Kaspersky Lab. Ahora ya no funciona, pero se puede admirar en toda su gloria en el despacho de Andrey Petrovich Doukhvalov.