Crónicas Australianas. Día 14

Más lecciones aprendidas aplicables aquí sobre como Atlassian desarrolla software que se vende en todo el mundo.

scroll

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]

  • Buenas David.

    Muy interesante, como casi siempre ;->.

    Todas las técnicas, y muchas más, se pueden aplicar en España, el único problema es la apertura de miras. A mi, personalmente, me resulta muy difícil explicar a la gente que voy a dedicar x recursos en ciertas técnicas, para recuperar esa inversión por 10, pero a “largo plazo”. Y esta es la frase mágica, no existe visión a largo plazo. Lo que no entienden es que no existe el santo grial, ni el dorado ni tantas otras cosas.

    Yo voto para que escribas un tercer artículo.

    Un saludo.

    • En realidad, casi todo lo que cuento es PURO SENTIDO COMÚN. Gente creyendo en su producto y reinvirtiendo beneficios para hacerlo mejor. 

      Llega un momento en que la pura reinversión genera más y más beneficios, compra de otros productos, etc.

      Espero que todos estemos de acuerdo en que, si esto no se hace en España, es por actitud no por aptitud… :/

  • ¿No es un poco descabellado lo de querer más que duplicar un departamento? Pasar de 7 a 17 personas. ¿como lo hacen para que la nueva gente se empape de la cultura?

    Al ver los números que manejan para cualquier cosa, me parece complicado que mantengan la filosofía de intentar hacer todo lo mejor posible. Me explico, si yo solo puedo poner a 2 personas a hacer algo, me tengo que esforzar por encontrar la mejor manera de que esa gente sea todo lo productiva que se pueda, potencias la imaginación. Pero si puedo meter a 30, esa necesidad desaparece, ya no es necesario que sean super productivos.

    El tutorial de Here be Dragons es muy interesante para conocer los productos de Atlassian, pero personalmente me llevé una pequeña decepción al enterarme, una vez terminado, que era necesario ser customer de Atlassian para poder recibir la camiseta. Aún así lo recomiendo a todo el mundo.

    En España un problema que tenemos (en lo que yo conozco) es que la mayoría de las empresas son de servicios, y están a lo que digan los clientes. Si los clientes piden estas técnicas ellos las dan, si los clientes no las piden, pues no. Un poco a lo Groucho Marx, “estos son mis principios. si no le gustan tengo otros”. Y como últimamente lo principal que se tiene en cuenta es el precio ofertado, el resto de cosas no son importantes.

    • Hombre… yo te puedo contestar sobre lo que conozco. Por la parte que me toca, Atlassian quería contratar a 10 embajadores en toda Europa y un año después somos… 3. Básicamente, porque no ha encontrado gente que encaje en el puesto.

      Una cosa es la gente que quieran contratar y otra cuando consigan hacerlo (te recomiendo que leas este artículo sobre el recruitment de Atlassian… desde la perspectiva de una agencia de búsqueda de talentos: http://rossclennett.blogspot.com/2010/11/atlassian-recruitment-november-2010.html)

      Otro punto importante es que sólo se contrata a gente que sea muy independiente y este a gusto con la autogestión.

      Pero si… es evidente que nunca puedes esperar que Panrico produzca pan con tanta calidad como una panadería. Otra cosa es lo que consideremos “calidad”… eso es muy relativo. De momento, Atlassian sigue creciendo y los productos no empeoran.

      Un abrazo,
      David

      • Este artículo va a ser uno que se te olvidó poner en un twit hace unos meses.

        Si no consiguen a gente, es solo que no buscan en el sitio adecuado. ¿cuando van a abrir oficina de desarrollo en España?

  • Juan José del Río Holgado

    Ahora solo hace falta que os acordéis también de los administradores de JIRA y nos hagáis más facilita la administración.

    Cosas como no poder cambiar los nombres de los elementos de las listas, o no poder “deshabilitar” elementos para que no aparezcan son un soberano coñazo en el trabajo día a día. 😉

    • O_o ¿Con que versión trabajas? La Administración, dentro de que es completa, se ha simplificado hasta el infinito y más allá.

      Pero lo que más me llama la atención de lo que me dices es que es FACILÍSIMO ocultar campos en las pantallas o hacerlos no obligatorios… aquí tienes más info:

      https://answers.atlassian.com/questions/11881/can-you-hide-fields-on-certain-screens-issue-types

      • Juan José del Río Holgado

        Creo que nos me he explicado bien:

        Ni en 3.x ni en 4.x se pueden “deshabilitar” elementos en listas.

        Por ejemplo, si tengo un custom field single-select o multi-select  con los valores “a”, “b” y “c”, no puedo:

        – Hacer que “b” no aparezca más en la lista sin tener que editar todos los tickets que usan ese valor y apuntarlos a otro valor de la lista / a none (si el campo es opcional).

        – Renombrar “b” a “x”. La alternativa es añadir “x”, migrar todos los de “b” a “x”, y luego borrar “b”.

        Y bueno, ya no hablo de la API SOAP que no permite ni crear subtasks. 😉

        Eso sí, no lo tomes como una crítica mortal. Seguís siendo de lo mejorcito y no me queda más remedio que usaros a diario. 🙂

        • Respecto a la API SOPA, ya te digo que te actualices a JIRA 5. Con el API REST ahora puedes hacer DE TODO.

          Lo que me cuentas de actualizar un campo personalizado de tipo lista donde eliminas un valor… bueno, es rebuscado, no creo que sea un problema para el 99% de la gente y, además, puedes hacer el “cambio en bloque” que comentas (en 4 clics has modificado todos los valores) pero… ¡No justifico nada! Si crees que es algo a mejorar e importante, crea la incidencia en el JIRA público y haz campaña para que la gente lo vote.

          Te aseguro que Atlassian se toma MUY EN SERIO el número de votos en las incidencias y propuestas de mejoras.

          Un saludo!

          • Juan José del Río Holgado

            Quizás no sea un problema para el 99% de los clientes, pero sí que es un problema para las personas que tenemos instancias gigantes de JIRAs (de esas en los que los tickets se cuentan por cientos de miles), y algunas “listas” en custom fields superan el centenar de elementos. 😉

            Con respecto a las votaciones… hombre, tiene su gracia que el voto de una persona que tiene miles de usuarios a su cargo valga lo mismo que el que compra un JIRA por 10 euros “para probar” 😉

            Además, ya sé que los votos os importan… pero cosas como https://jira.atlassian.com/browse/JRA-9 , que se han tardado 9 años en implementar son un poco… tela marinera. ;-P

            Y finalmente, con respecto a la API REST… chachi. Ahora solo toca migrar un centenar de scripts. 🙂

          • Hombre… entonces, a lo mejor, el primer problema es como proporcionamos la información porque, desde un sencillo “no poder ‘deshabilitar” elementos” hemos acabado con “cientos de miles” de tickets… 😛

            En ese caso, yo te recomiendo que hables directamente con soporte, que para eso están, tanto para ver si te pueden solucionar el problema como para recomendarte la mejor manera de solucionarlo. 

            Y si no te lo solucionan, ponme en copia: dbonilla AT atlassian.com 

            En cualquier caso, seguro que vas a tener mejor feedback que en los comentarios de un post que no tiene nada que ver, en el humilde blog de un sencillo embajador 🙂

            Respecto a lo del cambio de scripts… ya lo siento! Por lo menos, en esta versión han prometido que la API será estable en todas las versiones 5.x

          • Juan José del Río Holgado

            Creo que os habéis vuelto a olvidar de la creación de subtasks… 😉

            http://docs.atlassian.com/jira/REST/latest/

          • Creo que nos hemos olvidado “sólo” en la documentación. Échale un vistazo a esto:
            https://answers.atlassian.com/questions/22046/how-to-create-a-subtask-with-json-rest-api