Durante mi estancia en las oficinas de Atlassian en Sídney, no sólo he estado recibiendo formación sobre los productos y la compañía, sino que he pasado tanto tiempo o más en reuniones donde se discutía la futura estrategia corporativa.

Y no porque sea un ejecutivo de nivel mundial o porque me consideren una luminaria de los negocios, sino porque poseo algo que se valora a precio de oro dentro de la compañía: información directa sobre lo que quieren partners y clientes.

Product Management: si quieres vender, conoce a tu cliente

En Atlassian hay una verdadera OBSESIÓN con ajustar el roadmap de cada producto a las necesidades reales de los clientes. Después de constatar que la interfaz de JIRA resultaba complicada y confusa para muchos usuarios, por ejemplo, se creó el proyecto Kick-Ass, un desarrollo interno con el objetivo de hacer que la aplicación sea más sencilla y usable, al que han dedicado ni más ni menos que 30 desarrolladores.

Tradicionalmente, los Product Managers -los encargados de confeccionar ese roadmap– provenían del marketing puro y duro pero, desde que Audra Eng se hizo cargo de la gestión de producto, ha estado promoviendo sistemáticamente a técnicos como Product Managers. Según ella, los técnicos tienen una visión del mercado más amplia y más a largo plazo.

El arte de la documentación técnica

En Atlassian hay 7 escritores técnicos contratados a tiempo completo y quieren contratar a 10 más. La responsabilidad de los escritores técnicos no es sólo crear manuales de usuario, sino tutoriales completos sobre como administrar las herramientas y, lo que es más importante, como desarrollar plugins que extiendan los productos.

Evidentemente, toda la documentación se crea en Confluence -una de las herramientas de la casa- pero, Sarah Maddox me estuvo contando algunas peculiaridades de su forma de trabajar que merece la pena destacar:

• Están OBSESIONADOS por conseguir que la documentación no sólo sea exhaustiva y de calidad, sino atractiva. Para conseguirlo, utilizan todos los trucos que pueden. Desde el uso de Zen Foundation -un plugin de Confluence– para darle un diseño propio y distintivo a developer.atlassian.com, hasta el uso de Gamification, como en el increíble tutorial Here be Dragons, que enseña a instalar y configurar todas las herramientas de la compañía mientras juegas.
• La Documentación no está cerrada sino que permiten que la Comunidad colabore. Para empezar ¡Permitiendo comentarios en la propia documentación! Siguiendo con un programa que permite editar directamente el contenido a contribuidores de reconocido prestigio; y llegando hasta incluir enlaces a blogs externos con documentación relevante y de calidad sobre los productos.
• Toda la información se publica automáticamente en formato PDF, HTML y XML, para que no sólo sea fácil de leer, sino también de procesar, si hiciera falta.
• Toda la documentación se publica con licencia Creative Commons -reservando sólo el derecho de atribución- así que, en teoría, se podría coger toda la documentación, empaquetarla, ponerle una portada y venderla como libro en Amazon. Sería ratuno y vergonzante pero, por poder, se podría.

La verdad, esta política de documentación, con [highlight]el objetivo final de conseguir que más gente conozca y use los productos[/highlight], me parece brillante y sorprendente en una empresa de software propietario. Sobre todo, acostumbrado a la estrategia de otras compañías que han convertido la documentación de sus productos en otro negocio en si, aunque eso suponga un freno a sus propios productos.

El Testing, con cabeza

En Atlassian hay muy poca gente en el departamento de Calidad y están buscando continuamente gente nueva. Eso es así porque buscan perfiles muy concretos y poco comunes: desarrolladores que estén verdaderamente interesados y apasionados por la calidad en el software.

[highlight]No hay ni un solo miembro del equipo de QA que no sea técnico[/highlight]. Entre otras cosas, porque entre sus obligaciones está la de mejorar y complementar los test unitarios ya programados por el equipo de desarrollo.

Durante la entrevista con el equipo, hubo un par de cosas que me llamaron mucho la atención:

• El Testing Exploratorio, que en muchos sitios se hace de forma aleatoria, en Atlassian se hace siguiendo también una metodología: se hacen una serie de preguntas, una serie de presunciones de cómo trabajaría un determinado usuario. Se les asigna una cantidad de tiempo y se prueban.
• Además de los tipos de pruebas habituales (functional testing, domain testing, stress testing…), en Atlassian se practica también el claim testing: si la compañía anuncia que la versión X del producto Y es un 20% más rápida, se prueba que efectivamente sea así.

[quote]OBSESIONADOS por conseguir que la documentación no sólo sea exhaustiva y de calidad, sino atractiva[/quote]

Una vez más, me dejo muchas cosas en el tintero a pesar de escribir un artículo mucho más largo que lo habitual. Si queréis conocer de primera mano como se trabaja en Atlassian –o lo que es lo mismo, una compañía de producto con presencia internacional- creo que tendré que escribir una tercera parte de las crónicas australianas.

[highlight]¿De verdad no creéis que muchas de las prácticas que he descrito pueden aplicarse directamente en nuestras empresas en España?[/highlight]