KAV 6.0
Alfa, el principio de “Seis”
Teniendo en cuenta que la fase de prueba y de desarrollo inicial fueron llevadas a cabo por un pequeño grupo, se tornó evidente que los enfoques de gestión del monstruoso proyecto no estaban funcionando para el equipo. Debido a esto, se puso en práctica un enfoque similar a SCRUM: los desarrolladores se sentaban en un espacio abierto, interactuando continuamente – de esta manera, podían cubrir fácilmente todos los aspectos del proceso de desarrollo. Esa fue la forma en que trabajó el equipo de desarrollo de “Seis”.
Perfil pequeño: SCRUM
SCRUM es un enfoque de gestión de proyectos para entornos ágiles de desarrollo de software. Se basa en el principio de que el cliente (usuario) no necesariamente sabe lo que necesita y que es posible que desee cambiar el requisito durante el curso del proceso. Eso significa que el proceso de desarrollo se caracteriza por la presencia de varios ciclos: creación, demostración, análisis de feedback y actualización de la versión.
La distribución de los puestos de trabajo de SCRUM fue significativamente revisada. Kaspersky había definido seis roles:
Arquitecto
Se trata de la persona que participa activamente en el proceso de codificación y que sabe específicamente qué construir y cómo hacerlo.
Diseñador técnico
No existe una definición clara para este papel, pero se trata de la persona que se encarga de garantizar que ciertas soluciones se traigan a la vida. Quizás su tarea más importante sea saber cómo no se deben hacer las cosas.
Inventor
El inventor aplica soluciones no convencionales para resolver los problemas. En el caso de “Seis”, los problemas eran incontables. La solución debía de ofrecer, en última instancia, el mayor nivel de protección consumiendo la menor cantidad de recursos informáticos.
Manager del Proyecto
El papel del Manager del proyecto en SCRUM no supone estrictamente la regulación de éste. El MP controla los fondos de recursos y plazos, pero no es el líder inmediato. El MP no les dice a los codificadores qué hacer, aunque sí los motiva a tomar la iniciativa ellos mismos.
“El equipo era pequeño, no tenía ni siquiera un jefe al principio”, dice Doukhvalov. “El Manager planea, presenta los informes, pero las decisiones que se toman en el proyecto son colectivas.”
Director Comercial
El producto había sido creado para los clientes y no para el equipo de desarrollo. Por eso, era vital contar con la comprensión de las expectativas de los usuarios y cómo lo iban a utilizar. Si bien los principios operativos son definidos por aquellos que entienden de la naturaleza de la funcionalidad anti-virus, un millar de pequeñas cosas como la configuración, los mensajes, la interfaz de usuario debían de tomar en consideración las necesidades de los consumidores.
Psicólogo
Trabajar bajo presión, con falta de sueño, conflictos en el grupo, inestabilidad… Alguien tenía que encargarse de que el ambiente sea agradable y productivo. Este papel fue asignado a Kaspersky en persona, por lo que debió combinarlo con el papel de padrino que proporcionaba los fondos y los recursos para el equipo y lo protegía de influencias externas.
Francamente, existe un papel más, que es de vital importancia para los proyectos SCRUM. Se trata del escriba que va tomando notas sobre todo el proceso. Pero dado que esta posición no fue ocupada por nadie, se generaron varios problemas.
“No sabíamos por qué habíamos hecho tal cosa o tomado tal decisión hacía apenas medio año,” afirmó Kaspersky.
De acuerdo con este principio, el número de roles no se corresponde necesariamente con el número de miembros del equipo. Una sola función puede ser distribuida entre varias personas y un solo miembro puede realizar varias funciones.
“Si bien manteníamos una organización formal, actuábamos como un solo equipo, así que la división de roles era borrosa. Particularmente, cuando se intercambiaban las ideas, la gente asumía diferentes funciones”, admitió Nikolay Grebennikov. “Por ejemplo, una persona se encargaba de la codificación, pero, a su vez, emitía su opinión sobre el diseño. Yo mismo era el Manager del Proyecto y también participaba de las discusiones, por lo que esas divisiones borrosas, en realidad, contribuyeron a nuestro éxito”.
Según De-Monderik, se produjeron grandes intercambios entre los codificadores: “Cada miembro del equipo era el Dios de su dominio, sin embargo, el 50% de sus habilidades se superponía con las de otra persona. Mike era capaz de codificar los controladores si Sobko no estaba presente, los especialistas de la interfaz de usuario podían manejar algunas tareas relacionadas con el motor y viceversa. Yo podía encargarme de los diseños cuando Max Yudanov no estaba, y Kolya Grebennikov a veces diseñaba los skins también. ”
En este punto, es crucial entender que cada uno de los roles era líder en una etapa específica de la ejecución del proyecto. Durante la fase inicial, el arquitecto es la figura central. El inventor entra en acción durante la etapa intermedia del proceso de desarrollo, cuando se crean y desarrollan las características. En la última etapa, la figura clave es el director, dado que el proyecto cuenta ahora con una gran cantidad de recursos que requieren una gestión ajustada para que el equipo sea capaz de cumplir con el plazo.
Detrás del ideal
Teniendo en cuenta el enfoque estilo-SCRUM y la ambición global del proyecto, “Seis” no tenía ninguna lista de requisitos estáticos. De acuerdo con los requisitos básicos, el producto tenía que incluir las siguientes características:
• Apoyo en toda regla contra las amenazas de seguridad actuales;
• Optimización del uso de los recursos de la PC;
• La infraestructura basada en componentes para una mejor escalabilidad;
• Fácil adaptación de los componentes a diferentes plataformas.
Los requisitos técnicos correspondientes a los productos fueron sometidos a una serie de cambios. En consecuencia, el lanzamiento del producto era constantemente pospuesto, pero el equipo fue capaz de desarrollar una solución revolucionaria que se adelantaba varios años a las necesidades del mercado en general y que era muy superior a la versión anterior en términos de velocidad.
Tras el lanzamiento de Kaspersky Anti-Virus 6.0, Maxim Yudanov, quien fue el responsable del diseño de la interfaz de usuario, dijo: “Uno de las distinciones clave del proyecto es la ausencia de una lista de requisitos “tallados en piedra”. Hicimos prototipos, discutimos el producto, actualizamos la lista de normas técnicas y características, apuntamos los principales puntos bajos en notas Post-It y las pegamos en nuestros monitores. ‘nos olvidamos tal cosa’, ‘recuerda tal otra’ y, una vez más, pedimos la ayuda del público (me refiero a la comunidad de beta test). Estoy seguro de que el producto final no hubiera sido lo que fue si hubiéramos basado el trabajo en una lista de requisitos tradicionales. Si ese hubiese sido el caso, hubiéramos terminado creando el producto que imaginamos al principio. Estoy seguro de que en ese caso, el producto hubiera sido muchísimo peor que lo que terminó siendo”.
Programación extrema
Hoy en día, este enfoque no es algo novedoso. Pero hace diez años, la aplicación de este método para proyectos de gran escala era algo revolucionario y poco convencional. La principal diferencia entre la llamada “programación extrema” (el término fue ampliamente utilizado entonces, ahora los métodos similares se unen bajo el paraguas de “desarrollo ágil de software ‘) y el burocrático CMM-coding approach (que ahora está prácticamente extinto) radica en la ausencia de una lista de requisitos tradicionales como una Santa Biblia una vez aprobado como base única de trabajo del proyecto para los próximos años. CMM puede ser un enfoque adecuado para proyectos de desarrollo externalizados, pero para proyectos comerciales es inútil.
Nikolay Grebennikov, ahora director de tecnología de Kaspersky Lab, está de acuerdo: “Debemos llegar primero a un conjunto fijo de características sin cambios. Dado el curso de aplicación, no habríamos tenido ninguna visión de lo que los usuarios realmente necesitaban y no esperábamos tal grado de apoyo de ellos. La primera versión de la construcción no era utilizable y tenía un montón de problemas. Para solucionar los problemas, invertimos un montón de tiempo: cinco trimestres entre la versión alfa y el lanzamiento técnico. En el mundo actual, este es un lujo que uno no se puede permitir, pero en ese momento, fue una experiencia muy útil. ”
La agenda de desarrollo (en ruso)
Kaspersky fue bastante directo acerca de esto: “Cuando decides desarrollar un producto innovador, prepárate para violar continuamente los plazos de entrega”.
La vida en el trabajo
Los miembros principales del equipo de desarrollo de KAV 6.0 recuerdan este período de su vida con nostalgia. La falta de sueño, la falta de tiempo dedicado a las familias, la falta de fines de semana libres, y el hecho de estar bajo una gran marea emocional, vio su recompensa en el progreso y la calidad de la obra.
Uno de los correos electrónicos que Nikolay Grebennikov escribió durante el período en que el proyecto estaba en marcha, proporciona una visión más poética del trabajo realizado:
“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 en 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 enganchabas otra vez al proyecto: estábamos en un juego donde era posible hacer cualquier cosa que pudiéramos imaginar”.
“Había llegado nuestro momento”, recuerda Kaspersky. “Nuestros ojos brillaban de entusiasmo, había Post-Its por todas partes, todos los miembros del equipo ya casi no dormían. Todo era una tormenta de ideas y acciones”.
Cuando el equipo se agrandó, el núcleo del grupo original de desarrolladores transmitió el espíritu de equipo a los recién llegados” recuerda De-Monderik:
“Con todos los miembros del equipo trabajando bien, teníamos que contar con la capacidad del ‘núcleo grupal’ de despertar el entusiasmo. El núcleo grupal tenía una idea general, tenían un reto: hacer el mejor producto de la historia. Era el objetivo clave para nosotros: Kolya [Grebennikov], Pavel Mezhuev, Doukhvalov, yo mismo, Mike Pavlyuschik … fuimos capaces de transmitir nuestro entusiasmo a los otros miembros del equipo. Cuando todo el mundo alrededor tuyo está trabajando duro y tú estás en la misma habitación, ves lo que realmente sucede, y sin saberlo, tratas de hacer lo mismo”.
Incluso la gestión del proyecto, siendo bastante informal, trajo sus frutos.
“Si no recuerdo mal, en un primer momento tuvimos reuniones de estado”, dijo De-Monderik. “En la mañana, cuando el grupo solía reunirse en la sala, Kolya acostumbraba realizar algún tipo de discurso resumen: tenemos los recursos, hoy haremos este tipo de cosas. Era tan bueno en eso. Teníamos una enorme pizarra donde escribíamos y dibujábamos nuestros hallazgos. Como no éramos un gran equipo, alcanzaba”.
Grebennikov reconoce que las reuniones de estado, que representaban un método formal de la organización del trabajo del proyecto, no era lo principal. Sólo se debía reunir al equipo si la reunión traía beneficios para el proyecto.
Beta: Ampliando el alcance
A medida que el proyecto evolucionaba, entre septiembre de 2003 y marzo de 2006, el equipo fue creciendo y, para día del lanzamiento, el grupo era ya de casi 30 personas. El equipo incluía a Maxim Yudanov, un diseñador y a Pavel Nechayev, Denis Guschin, Eugene Roschin y Andrey Gerasimov, ingenieros de software. Ellos trajeron una serie de características innovadoras, incluyendo una interfaz de usuario basada en skin y un firewall integrado. El grupo también incluyó a especialistas en instalación y supervisores de pruebas beta. Sin embargo, uno de los pasos más firmes adoptados para refinar KAV 6.0 fue un enfoque recién inventado por el equipo de desarrollo de los “Seis”: una prueba-beta basada en el foro.
Foro
Todos los accionistas admitieron que Kaspersky Anti-Virus 6.0 salió como un producto bien diseñado y testeado con gran cuidado, 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, ya que 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 participaban activamente en las discusiones del foro e interactuaban con los testers 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”, 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 sólo se recopilaron 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 click 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 usuarios 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 se 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.
Un lanzamiento exitoso
Como resultado final, nuestro equipo -que ya era un poco más grande que al principio, aunque todavía estaba bastante reducido- desarrolló un producto con un instalador extraordinariamente compacto y con una interfaz de usuario ágil basada en skins intercambiables. Era un producto que afectaba al mínimo las prestaciones del equipo y se caracterizaba por tener tanto funcionalidades innovadoras y potentes, como una 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, en gran medida, 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 éstos fueron los ingredientes de la receta del éxito que permitieron sacar a la venta Kaspersky Anti-Virus 6.0, un producto que garantizó 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 se aplicó también en otros ámbitos”, afirma Eugene Kaspersky. “Si durante el proceso de desarrollo nos enfrentamos a un elemento que ralentiza el trabajo, 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.
Traducido por: Guillermo Vidal Quinteiro
Consejos