Mozilla QA: Bug Days

Revisando el blog de Mozilla encontré una muy interesante invitación al Thunderbird Bug Day. Me pareció cómico el nombre y comencé a buscar más información al respecto, en pocos clicks descubrí que es un concepto originalmente desarrollado por el grupo de QA de Mozilla en 1999 y que, a pesar de ciertos obstáculos en los años que le siguieron, actualmente se lleva a cabo todos los martes. Se puede encontrar mucha información sobre el Thunderbird Bug Day en su wiki, incluyendo la planificación de las próximas jornadas.

Por un momento me sumergí en la lectura y llegué a un corto párrafo, muy sencillo, pero cargado con una verdad inevitable para toda empresa, gerencia o grupo que se dedica al desarrollo de software. No traduciré el texto pero si listaré las frases contenidas en él que reflejan el karma de todo desarrollador.

• Muchos (MUCHOS!) errores [reportados].
• Algunos [errores] se encuentran en un estado que los hace difíciles de solucionar.
• Podrían no ser verdaderos errores y necesitamos su confirmación.
• Algunos [reportes de errores] están mal redactados.

Estas frases karmáticas son muy familiares para todos aquellos que han trabajado en el desarrollo de software. Sin embargo el concepto del Bug Day va más allá de la simple lista de errores, el Bug Day es una forma de acercar la comunidad de usuarios y el equipo de desarrollo. A mi parecer, esta frase extraída del wiki del grupo de QA de Mozilla revela el verdadero sentido del Bug Day:

"No importa si usted ha estado involucrado con Mozilla durante años o si este es su primer paso en nuestra increíble comunidad de código abierto. Cualquiera puede participar y ser un valioso contribuyente"

Una asombrosa jugada del equipo de QA de Mozilla, probablemente sean muchos los beneficios de aplicar este concepto, sin embargo se pueden identificar claramente dos beneficios muy atractivos para cualquier empresa que desarrolla software, bien sea para consumo interno o para la venta. Estos beneficios son: Incrementar la cantidad de testers y aumentar la identidad del usuario con la aplicación.

Cada usuario es un tester en potencia, al fin de cuentas son ellos los que diariamente usan la aplicación y son ellos quienes sufren las consecuencias de los errores. ¿quién mejor que ellos para reportar los errores de la aplicación? Además el hecho de estar involucrados en el proceso de depuración de los errores de la aplicación, hará que los usuarios se sientan más identificados con la misma ya que finalmente sentirán la aplicación con suya y posiblemente aumenten su compromiso y colaboración para lograr la aplicación perfecta para sus necesidades. Y ni hablar de la reducción del fenómeno de "resistencia al cambio" para aquellos casos en los que sustituye completamente una aplicación por otra.

Una vez más solo consigo ventajas y beneficios imaginando cómo sería aplicar este concepto en esas empresas de servicio que necesitan incorporar la tecnología a sus procesos de negocios para hacerlos más eficientes buscando siempre la ventaja en el mercado.

Una gran lección de un gran maestro!

Filosofía Google

Comenzaré este blog con algo que me ha llamado la atención desde el primer instante que leí sobre el tema; la filosofía Google.

Resulta que los panas de Google deben distribuir sus labores semanales en un 80-20. 80% de la semana trabajan en un proyecto fijo y el 20% restante lo tienen libre para trabajar en cualquier proyecto que deseen, bien sea para desarrollar una nueva funcionalidad del Blogger o para ayudar en el diseño del proyecto que dará una nueva dimensión a las aplicaciones web.

Ahora bien, ¿Se podría aplicar esta filosofía en una empresa venezolana que no se dedica al desarrollo de tecnología? por ejemplo, empresas grandes que llevan años en el mercado cuya principal preocupación es mantener en marcha el negocio, usando la tecnología pero no desarrollándola, como las empresas básicas de Guayana; o empresas que se dedican a prestar servicios, como las telefónicas, bancos o seguros.

A mi parecer y entendimiento, la respuesta se basa en la combinación del factor humano y en la organización de los proyectos. Un proyecto organizado, con actividades bien definidas y atomizadas al máximo permite a desarrolladores foráneos intervenir puntualmente en el proyecto, generando así una dinámica que ayuda a mantener fresco el proyecto y sus participantes. Esto representa para la empresa una gran ventaja, con esta filosofía queda atrás la época de proyectos interminables que comenzaron siendo divertidos y terminaron por ser un total dolor de cabeza. Además de brindarle a los desarrolladores la oportunidad de refrescarse, les permite involucrarse en muchos más proyectos dentro de la compañía, algo nada malo para la gerencias que se tambalean cuando sus empleados estrellas deciden irse en búsqueda de nuevos retos.

Sin duda alguna son las empresas de servicios las más vulnerables a los cambios y avances tecnológicos, para estas empresas es una obligación estar al día con la tecnología, de otro modo no podrían mantenerse de pie en el mercado sin ser atropelladas por la competencia. Estas empresas, que se dieron cuenta que era necesario contar con un departamento de sistemas que hiciera algo más que reparar las computadoras de los gerentes y mantener a tono los servidores de base de datos, son las candidatas perfectas para aplicar esta filosofía, porque a pesar de no ser desarrolladoras de tecnología, necesitan incorporarla a sus procesos de negocios para no quedarse atrás en la carrera, al tiempo que necesitan innovar y evolucionar para resaltar en el mercado.

Aprendamos de los grandes.