La historia de Jibble
Crear un software que destaque, sea sólido y tenga impacto es difícil. Muchos equipos pueden hacer una cosa, unos pocos pueden hacer dos, pero rara vez vemos un equipo capaz de conseguir las las tres cosas.
Eso es lo que he visto en Jibble.
Una rápida búsqueda en Google corroborará mi afirmación: el software de la empresa tiene una impresionante puntuación de 4,8 en GetApp y Capterra y de 4,7 en la App Store de Apple.
Estoy seguro de que hay muchas cosas que la empresa puede mejorar, pero el equipo está haciendo algo bien si estas son nuestras calificaciones.
Quería entender qué estaban haciendo exactamente, así que decidí que debía intentar comprender cómo y por qué la empresa estaba consiguiendo estos impresionantes resultados.
Me doy cuenta de que el software de control horario y el de seguimiento del tiempo no son realmente tan atractivos; definitivamente no es lo mismo que trabajar para una empresa de juegos como Activision, que está desarrollando el nuevo juego de Spiderman.
Sin embargo, Jibble se jacta de ser «El nuevo estándar en el control del tiempo», una afirmación audaz, pero que me pareció estar basada en hechos reales. Es el resultado de un esfuerzo agotador por hacer interesante algo cotidiano, pero significativo.
A primera vista, Jibble puede parecer un concepto común y corriente del tipo «Vale, has encontrado un problema, vamos a engranar algo de código, crear una interfaz de usuario, añadir una pasarela de pago y lanzarlo al mundo».
Eso, al menos, era lo que yo entendía al principio, antes de unirme al equipo, pero como aprendí rápidamente, las empresas SaaS que desarrollan productos complejos, como el software de control horario, funcionan de forma diferente.
Hay que seguir MUCHOS procesos y, aunque Jibble no es Google, cuenta con un equipo impresionante de personas que dirigen el desarrollo. Estos héroes a menudo pasan desapercibidos.
Es posible que hayas oído que los ingenieros de software no son grandes comunicadores: suelen ser introvertidos, dueños de sus propios dominios, y rara vez quieren ser molestados por la interacción humana. Este estereotipo es cierto hasta cierto punto.
La mayoría de los ingenieros, para ser buenos en su oficio, tienen que pasar incontables horas acurrucados sobre sus pantallas poco iluminadas afilando constantemente sus teclados, y nuestro equipo no es diferente.
Habiendo estado en ambos lados del funcionamiento de la empresa, me encuentro en una posición única para poder comentar por qué las cosas aquí simplemente… funcionan y por qué merece la pena que le eches un ojo a esta startup.
Nuestro proceso de desarrollo
Nuestro equipo dedica incontables horas a perfeccionar cada centímetro de su proceso de desarrollo, que es el siguiente:
1. Creación de la idea: Encontrar un punto débil
Nuestro equipo dedica una cantidad de tiempo insoportable antes de escribir la primera línea de código, para asegurarse de que no gastamos el doble una vez que hemos empezado a construir. Como dijo Abraham Lincoln:
«Dame seis horas para talar un árbol y me pasaré las cuatro primeras afilando el hacha».
2. Investigación externa
Una vez identificado un punto crítico en el ámbito de nuestro software de seguimiento del tiempo, el equipo se apresura a comparar los comentarios de los clientes, las tendencias actuales y previstas del mercado y las tecnologías pertinentes para encontrar puntos en común que ayuden a preparar los datos necesarios para tomar una decisión informada.
3. Investigación interna: Debates con el equipo
Una vez recopilados los datos, se involucra a los accionistas pertinentes, incluidos los Product Owners, Product Managers, CTOs, Lead Designers y Team Leads de todas las secciones.
Cuando el equipo ha mantenido un debate interno sobre los pros y los contras, los recursos frente al tiempo y el ROI previsto de la decisión que estamos a punto de tomar, se pide a todo el mundo que se tome su tiempo para expresar sus preocupaciones y expresar qué dirección creen que deberíamos tomar y por qué sí o por qué no.
4. Toma de decisiones: Hacerlo ahora o hacerlo más tarde: ¿Cómo afectará a la empresa?
Una vez que se ha llegado a una conclusión, el equipo elige la decisión que se ajusta a la visión de la empresa y a sus objetivos inmediatos o previstos. Si la decisión no cumple esos criterios, no pasa el corte.
Las decisiones suelen estar relacionadas (aunque no siempre) con la mejora de funciones existentes o el desarrollo de otras nuevas. Una vez que se ha dado luz verde a cualquiera de ellas, hay que decidir dónde situarla en la hoja de ruta: ¿lo hacemos ahora, el mes que viene, el trimestre que viene, o lo dejamos para más adelante?
En este punto analizamos qué impacto tendrá nuestra decisión en los clientes actuales, las perspectivas de futuro y la capacidad actual, y luego tomamos una decisión.
5. Análisis del diseño
Una vez decidida la línea de tiempo de la funcionalidad a desarrollar, tenemos que pensar en cómo será. Esto es algo en lo que muchos nuevos empresarios y propietarios de productos de software se equivocan.
Se centran demasiado en cómo debería funcionar cuando también deberían asegurarse de que todas las características encajan en su esquema visual.
6. La documentación, el pliego de condiciones
El siguiente paso es la perdición de los desarrolladores de software: la documentación. El pliego de condiciones es donde escribimos el alcance del proyecto que estamos desarrollando. Es donde se escribe la idea y se desarrolla en un documento que será la fuente de la verdad para el desarrollo, las pruebas y la comprobación de errores.
Establece una descripción detallada de la funcionalidad completa, explica cómo se verá y describe el objetivo final (por el momento, no nos fijamos mucho en las métricas). También se incluye una documentación técnica redactada por nuestros desarrolladores. Así es como redactamos actualmente las especificaciones:
- Borrador inicial del PM
- Los jefes de equipo revisan las especificaciones iniciales y dejan comentarios sobre la viabilidad técnica o sugerencias alternativas.
- Modificaciones del PM
- Otro debate (los pasos 2-3 pueden repetirse varias veces en función de la complejidad del proyecto)
El equipo se asegura de que todos los casos extremos también se tengan en cuenta durante este tiempo, pero si el diseño se ha finalizado, ponemos fin a las discusiones sobre especificaciones. Hasta entonces, cualquier tipo de iteración es posible.
7. Diseño del producto
Nuestros brillantes diseñadores crean diversos mockups con una variedad de opciones de visualización, que respetan la estética de la marca, como la paleta de colores de Jibble. En esta etapa se tiene en cuenta cada versión de visualización —móvil, web, tableta—y una amplia gama de tamaños de pantalla.
8. Implementación del back-end y pruebas unitarias
La mayoría de las funcionalidades comienzan en el back-end. Nuestro back-end necesita dar soporte a la funcionalidad antes de que agreguemos la interfaz de usuario y la lógica en el lado del usuario y la incorporemos a nuestra API.
Por ello, se realizan sesiones de grooming con el equipo de BE para perfeccionar los tickets y las tareas basadas en las especificaciones, y luego se asignan los tickets durante la planificación del sprint del back-end.
El equipo de BE también es responsable de desarrollar pruebas unitarias para el código que escriben, asegurándose de que toda la funcionalidad funcione como se espera. En este punto, se crea la arquitectura de la funcionalidad. Un buen modelo de funcionalidad facilitará el proceso de desarrollo para los clientes.
9. Implementación y tests o pruebas unitarias
Una vez implementado nuestro back-end, los equipos de desarrollo móvil y web comenzarán sus respectivas implementaciones de la funcionalidad. El proceso es similar al del back-end; sin embargo, el refinamiento de tickets se realiza principalmente fuera de las llamadas de planificación.
Los equipos de desarrollo se basan principalmente en las especificaciones, diseños y la estructura del modelo BE de la funcionalidad para implementar su código. En móvil, contamos con dos equipos diferentes para la interfaz de usuario que siguen un mismo conjunto lógico compartido; esto optimiza la entrega y reduce la redundancia. Las pruebas iniciales son realizadas por el equipo de desarrollo y luego se pasan al equipo de QA para verificaciones manuales.
10. Tests o pruebas de aceptación de QA
A medida que se desarrollan las funcionalidades, se despliegan en nuestros entornos de prueba, donde el equipo de QA realiza rigurosas pruebas de aceptación. Es una forma elegante de decir que probamos las características desarrolladas del software de seguimiento de tiempo para asegurarnos de que funcionen según lo esperado. Si se encuentran problemas, volvemos al taller para realizar ajustes y mejoras.
11. Pruebas de regresión de QA.
Si todas las funcionalidades funcionan como se espera, se envían a producción, donde se vuelven a probar, esta vez para asegurarse de que las correcciones recientes no rompan lo que ya estaba funcionando.
Las pruebas de regresión se definen como un tipo de prueba de software que confirma que un cambio reciente en el programa o código no ha afectado negativamente a las funcionalidades existentes. Aquí, en Jibble, realizamos dos tipos de pruebas de regresión: una es una prueba de regresión informal o menor, que se lleva a cabo dentro del alcance de los tickets de pruebas de aceptación que presentan problemas y necesitan ser corregidos de nuevo. La otra es una prueba de regresión de ciclo completo, que se realiza hacia el final del sprint, conocida como el ciclo con mayor cobertura, enfocándose en el camino crítico de las funcionalidades seleccionadas.
En este momento, las estamos ejecutando manualmente hasta que los scripts de automatización estén completamente listos.
12. Pruebas exploratorias
Como el equipo trabaja de manera ágil en el desarrollo de su software de hojas de tiempo, todo lo anterior se realiza en ciclos de dos semanas. Fuera de esos ciclos, o durante períodos en los que la carga de trabajo es relativamente baja, el equipo realiza pruebas exploratorias, lo que significa estar atento a todo y señalar cualquier mejora que necesite una corrección rápida.
También llevamos a cabo pruebas exploratorias mientras probamos los tickets de pruebas de aceptación, que abarcan el alcance ampliado del ticket en sí.
13. Alivio y liberación
Finalmente, después de todo ese esfuerzo dedicado, nuestra creación se lanza al mundo. ¿No esperabas que llevara tanto tiempo desarrollar software de hojas de horas, ¿verdad?
La conclusión
Para crear un producto excepcional, necesitas tener una visión excepcional y no desviarte de ella cuando aparecen dificultades. El equipo de seguimiento de tiempo de Jibble tiene esa sabiduría de no ceder demasiado rápido a las tendencias; son decididos pero están en constante iteración para mejorar.
Al mismo tiempo, ejecutan estrategias con el fin de mantenerse fieles a su visión de lo que debería ser «el nuevo estándar en control horario». Esto, creo, juega un papel importante en su reciente éxito.
La conclusión final para los equipos que buscan replicar el éxito de Jibble en la construcción de software de seguimiento de tiempo confiable es esta: crea rápido, construye fuerte, forma equipos ágiles que dediquen tiempo a hacer investigaciones basadas en datos antes de tomar decisiones, y emplea ingenieros brillantes que utilicen las mejores prácticas y la colaboración global para construir, probar, mejorar y lanzar características como un temporizador. Luego, siéntate y observa cómo ocurre la magia.
