Cómo comenzamos a lanzar funciones el doble de rápido (estudio de caso)

Cuando las empresas confían en su aplicación para su trabajo diario, debe ser lo suficientemente ágil para abordar rápidamente sus necesidades. Si no lo haces, otros definitivamente lo harán. En el implacable mundo de SaaS, retrasar una característica crítica (o apresurar una pieza de código llena de errores) significará perder clientes. Un flujo de trabajo ágil y sólido puede marcar la diferencia.

Somos el equipo detrás de Active Collab , una aplicación de administración de proyectos con un conjunto de funciones en constante crecimiento y una base de usuarios considerable. Esto significa que incluso el cambio más pequeño en la funcionalidad afectará a un gran número de personas.

Lectura adicional en SmashingMag:

• Cómo implementar nuevas funciones sin perjudicar a los usuarios leales
• La lista de verificación de lanzamiento del sitio web: 15 verificaciones esenciales antes de lanzarlo
• Un enfoque centrado en el usuario para el diseño web para dispositivos móviles
• Cómo lanzar cualquier cosa
  

Por lo tanto, el proceso de desarrollo debe funcionar sin problemas y con un estándar, con retrasos reducidos al mínimo. Antes de que cualquier cambio llegue al usuario final, pasa por cinco fases cruciales: retroalimentación, diseño, desarrollo, control de calidad e implementación . En este artículo, compartiré lo que hemos aprendido (de la manera difícil) sobre cada una de las etapas durante más de ocho años en el negocio.

Una llamada de atención

Antes de entrar en detalles, veamos cómo sucedió todo esto. Después de años de agregar funciones sin un escrutinio suficiente, nuestra aplicación sufría de un exceso de funciones. Hemos agregado tanta funcionalidad a lo largo de los años que los nuevos usuarios se sintieron intimidados por la gran complejidad de la interfaz de usuario (para no volver nunca más). Sabíamos que teníamos que reconstruir desde cero, incluso si eso significaba reescribir cada función desde cero.

Luego vinieron los retrasos. Las características de las nuevas versiones se retrasaban constantemente. Por ejemplo, se suponía que un desarrollador junior debía desarrollar una integración con QuickBooks. No predijimos con precisión la complejidad, las habilidades o los conocimientos necesarios. Además, él era el único asignado a esa tarea, y nadie podía intervenir rápidamente para ayudarlo. Como resultado, lo que se suponía que era un trabajo de dos semanas terminó siendo de cinco. Esas fueron algunas banderas rojas.

Era claramente el momento de cambiar a un enfoque más ágil. Tomamos lo que nos gustaba de varios métodos ágiles (y no tan ágiles), lo combinamos con la experiencia y creamos nuestra propia versión, que ha estado brindando excelentes resultados desde entonces.

Echemos un vistazo más de cerca al camino que debe recorrer una función antes de ofrecerla al usuario final.

De la sugerencia a la característica

En nuestro flujo de trabajo, una nueva función comienza a tomar forma mucho antes de que llegue al equipo de desarrollo y, por lo general, surge de los comentarios de los usuarios. Esto no es una coincidencia: solíamos lanzar funciones que nadie necesitaba, generalmente solo porque un usuario era particularmente ruidoso o simplemente pensamos que sería genial tener algo. En lugar de imaginar qué funciones podrían necesitar nuestros usuarios, ahora tomamos decisiones basadas en la demanda real.

Si le gusta la manufactura esbelta, diría que nuestros clientes “obtienen” ciertas funciones solicitándolas con más frecuencia que otras. Nuestros equipos de soporte y ventas son una gran parte del proceso porque están constantemente en contacto con los usuarios que comparten sus necesidades e ideas.

Según los comentarios, nuestros equipos actualizan un formulario que se ve así:

Cuando no tengamos toda la información que necesitamos, nos pondremos en contacto con los clientes directamente. Esto generalmente se hace con encuestas dirigidas a una muestra cuidadosamente seleccionada. El punto es que escuchamos. No se pierde ningún comentario sobre nosotros. Siempre es reconocido y documentado.

El siguiente paso es el análisis. Contamos los puntajes cada mes para ver qué función obtuvo la mayor cantidad de votos. Además, con la categorización adecuada, obtenemos una perspectiva más amplia sobre qué partes de nuestro software necesitan trabajar. Por ejemplo, si el calendario recibe muchas quejas, consideraremos renovar toda la sección, en lugar de introducir la función que obtuvo la mayor cantidad de votos (como la exportación del calendario).

Sin embargo, incluso cuando se conocen los resultados, la decisión de introducir una función no es definitiva. Antes de que llegue a nuestra lista de tareas pendientes, siempre hacemos una verificación exhaustiva de la cordura:

• ¿Qué beneficios traerá esta característica a los usuarios?
• ¿Se ajusta a nuestra filosofía de producto?
• ¿Agregará complejidad innecesaria?
• ¿Combina bien con la interfaz y la funcionalidad existentes?
• ¿Tenemos los recursos para entregarlo en un plazo razonable?

Cuando una característica pasa la lista de verificación y los propietarios del producto la aprueban, es hora de pasar a la mesa de diseño.

Diseñando para el usuario

La experiencia nos ha enseñado que agregar una nueva función no significa simplemente pegarla en la parte superior de la interfaz de usuario, sino que debe combinarla con el diseño existente, pensando en el usuario. Si no hace esto, pronto terminará con una aplicación tan compleja que solo unos pocos valientes sobrevivirán los primeros cinco minutos de la prueba (sí, hemos estado allí). La estética también es importante para una buena primera impresión, pero nuestra principal preocupación es la facilidad de uso . Se debe agregar una característica de una manera que se sienta natural para el usuario.

Mantenemos las cosas en perspectiva preguntando: ¿Dónde esperaría el usuario que esté esta opción?

Para los usuarios existentes, es importante que el nuevo diseño siga los patrones con los que están familiarizados y no interrumpa su flujo de trabajo. Además, existen estándares y convenciones de la industria a los que todos (inconscientemente) estamos acostumbrados. Nunca esperes que tus usuarios cambien sus hábitos por completo. Es más probable que busquen en otra parte si la interfaz no es intuitiva.

Toma atajos de teclado. Puede crear su propio conjunto de accesos directos y esperar que los usuarios los aprendan (probablemente no lo harán). O podría agregar los que la gente ya usa. Muchos de nuestros usuarios ya usan Slack, por ejemplo, así que agregamos un atajo con el que ya están familiarizados ( Command + K para saltos rápidos también funciona en Active Collab ).

Cuando los flujos de usuario están en su lugar, nuestro diseñador de UX maqueta el diseño en Sketch. Rara vez usamos HTML en las primeras etapas. Las visualizaciones de Sketch bien pensadas nos brindan suficiente flexibilidad para que no tengamos que retroceder cuando comenzamos a codificar. El diseño inicial generalmente termina igualando alrededor del 80% del producto final. El resto se agrega y ajusta a lo largo del camino.

Otro paso importante del proceso de diseño es la copia. Nuestros redactores dedican mucha atención a cada palabra. Incluso tenemos nuestra propia guía de estilo, para sonar lo más accesible y fácil de entender posible. Por ejemplo, decir "certificado de seguridad" en lugar de "certificado SSL" transmite en términos sencillos algo con lo que un usuario promedio podría no estar familiarizado.

Cuando todo esto está hecho, la función se asigna a un equipo de desarrollo. El equipo está compuesto por un gerente de proyecto, un desarrollador principal y varios desarrolladores de back-end y front-end, según la carga de trabajo. El gerente del proyecto se asegura de que todo funcione sin problemas y según lo programado, mientras que el desarrollador principal se ocupa del aspecto técnico de las cosas. También coordinan y asesoran a los desarrolladores junior.

Hora de poner las cosas en marcha

Nuestras reuniones iniciales no son reuniones motivacionales aburridas. Son oportunidades para que un equipo de desarrollo (formado por desarrolladores junior y senior) se reúna con el gerente del proyecto y el propietario del producto.

En lugar de permitir monólogos vacíos, nos enfocamos en poner las palabras de todos en tareas procesables. A lo largo del día tienen lugar tres encuentros importantes :

• El propietario del producto presenta la característica dada al equipo, las ideas detrás de ella, los diseños iniciales y los resultados esperados.
• Luego, el equipo tiene su propia reunión en la que discute el plan de acción, los problemas potenciales y el cronograma de pruebas.
• A la reunión final asisten todos los involucrados y el plan toma su forma final. Al final de esta reunión, el equipo brinda estimaciones para las demostraciones y una fecha de vencimiento final.

Tres reuniones pueden parecer mucho para un día, pero así es como nos aseguramos de que los problemas se resuelvan desde el principio. Completar los espacios en blanco en esta etapa les ahorra a nuestros desarrolladores mucho tiempo, comienzos en falso y retrocesos. Las reuniones también fomentan el trabajo en equipo y hacen que todos sientan que sus contribuciones son bienvenidas.

Después de las reuniones, el equipo tendrá toda la información necesaria:

1. ¿Qué? Este es el alcance de la función e incluye todo lo que hay que hacer, así como posibles bloqueadores y cuellos de botella. Tratamos de anticipar tantos escenarios y casos extremos como sea posible. Predecirlos todos no es fácil; a menudo surgen a medida que avanzamos.
2. ¿Por qué? El propietario del producto estima el valor comercial de una característica y explica por qué vale la pena el esfuerzo. De esta forma, el equipo obtiene una imagen clara de los beneficios para los clientes y el producto. El principal motivador aquí es que todos deben entender por qué su trabajo es importante y cómo contribuye a la empresa en su conjunto.
3. ¿Cómo? Al describir los pasos necesarios para completar una característica , nos aseguramos de que nuestros desarrolladores nunca pierdan la brújula. También establecemos expectativas realistas agregando una etiqueta de complejidad. Elegimos tallas de camiseta: la S se puede resolver en unas pocas horas, mientras que la XXL tarda semanas o más en completarse.
4. ¿Quién? El líder del equipo es responsable de terminar una función o tarea a tiempo y de actualizar al propietario del producto sobre el progreso. A otros miembros del equipo se les asigna su propio conjunto de subtareas, de modo que queda perfectamente claro quién es responsable de qué. Mantener esto lo más transparente posible nos ayuda a ver si alguien está teniendo problemas o causando retrasos.
5. ¿Cuándo? Teniendo todo en cuenta, se estima una fecha de vencimiento . Si una tarea se retrasa, analizamos las razones y usamos esa experiencia la próxima vez. De esa manera, una fecha límite incumplida se convierte en una oportunidad de aprendizaje y no en una fuente de estrés.

El día de inicio puede ser agitado, pero también es muy fructífero. Todos colaboran con ideas y comentarios. Una tarea se transforma de una pizarra vacía a un centro de comentarios, ediciones y actualizaciones. Al final del día, el equipo de desarrollo tiene una imagen clara del trabajo por delante y una base sólida sobre la que construir.

Revisamos esta lista de verificación antes de comenzar a trabajar:

• función explicada,
• pasos para completar descritos,
• valor comercial asignado por el propietario del producto,
• complejidad asignada por equipo,
• dependencias de características y errores identificadas,
• criterios de desempeño identificados (si es necesario),
• demostraciones programadas,
• fechas de inicio y finalización establecidas por el líder del equipo.

Este es el momento en que una tarea se mueve a la columna "En progreso".

¡Es hora de codificar!

Trabajo en equipo en exhibición

Nuestros desarrolladores nunca trabajan solos: siempre es un esfuerzo de equipo y es, con mucho, la forma más eficiente de lanzar nuevas funciones. Antes de que se introdujeran los equipos, un desarrollador (junior) se quedaba atascado con un problema y podría haber dado vueltas en círculos durante días (sin que nadie se diera cuenta). O, si no fueran del tipo de llanero solitario, estarían constantemente distrayendo a colegas y gerentes.

Por otro lado, con los equipos, mezclamos personas con diferentes conjuntos de habilidades y niveles de experiencia. Esto significa que a todos se les asigna un conjunto de tareas adecuadas a su nivel. Además, los senior obtienen el beneficio de aprender a administrar y entrenar a sus compañeros de equipo junior, y los junior pueden pedir ayuda. Debido a que es un esfuerzo de equipo y todos trabajan hacia el mismo objetivo, las preguntas no se consideran distracciones y el equipo puede abordar cualquier problema de manera mucho más eficiente. El equipo se convierte en una entidad autoorganizada, dividiendo el trabajo en fases (o sprints) y presentando su trabajo durante demostraciones.

Mostrar y contar

De acuerdo con el cronograma, el equipo realizará una demostración para el propietario del producto. El propósito de las demostraciones es mostrar qué tan bien se está desempeñando una función en su estado actual y dónde necesita más pulido. Es un control de la realidad que no permite excusas como, "Solo necesita algunos toques finales" (toques que tomarían otro mes). Además, si las cosas comienzan a torcerse, los propietarios de productos pueden reaccionar rápidamente.

Reuniones Semanales

Comenzamos con breves reuniones diarias regulares a las que asistían todos los desarrolladores. Cada desarrollador describiría brevemente en qué estaba trabajando, sus problemas, sus bloqueadores y si necesitaba ayuda. Pronto se hizo evidente que estas reuniones debían estar más enfocadas y proporcionar resultados tangibles. Entonces, cambiamos a tener reuniones con equipos individuales una vez a la semana. Así es como los propietarios del producto y el director del proyecto se mantienen informados y todos los problemas potenciales se tratan en el acto.

Poniéndolo a prueba

El código está escrito, las demostraciones han tenido éxito, todo parece estar funcionando bien... hasta que liberas la función y ves que la aplicación falla. Es por eso que cada característica que hacemos pasa por el control de calidad (Q/A). Siempre. Nuestro evaluador analiza meticulosamente todos los escenarios posibles, verifica todas las opciones y ejecuta pruebas en diferentes entornos. Una característica rara vez pasa Q/A en el primer intento.

Para aumentar la productividad, solíamos dejar que los desarrolladores comenzaran con nuevas funciones durante esta fase, pero eso solo resultó en muchas funciones retrasadas y a medio terminar. Entonces, ahora el equipo de desarrollo se mantiene ocupado trabajando en pequeñas tareas de mantenimiento mientras se revisa su característica. Si Q/A encuentra un problema, los desarrolladores lo solucionan inmediatamente y lo vuelven a enviar. El proceso se repite hasta que la función pasa las preguntas y respuestas y pasa a la revisión del código.

Aquí es cuando un desarrollador senior se asegura de que el código esté escrito de acuerdo con nuestros estándares. Un paso final antes del lanzamiento es escribir la documentación: no desea verse abrumado por los correos electrónicos de soporte después del lanzamiento de una función que nadie sabe cómo usar. Nuestros redactores también actualizan las notas de la versión y escriben materiales de marketing, como anuncios por correo electrónico y publicaciones de blog.

Aquí está nuestra definición de "hecho":

• pruebas automáticas escritas,
• Q/A hecho y todas las tareas resultantes completadas,
• revisión de código realizada y código fusionado para dominar,
• notas de la versión actualizadas,
• dependencias de funciones y errores identificadas.

La tarea ha llegado a la etapa final, llamada "Release Q".

Día de lanzamiento

A la hora de elegir un día para los nuevos lanzamientos, inmediatamente nos decidimos por el viernes y el lunes. El viernes no es bueno porque cualquier problema potencial no se resolvería hasta el lunes; además, el equipo de soporte ya estaba bastante ocupado en ese momento. El lunes no es el mejor momento porque cualquier actualización importante requiere preparación, que tendría que hacerse el fin de semana. Siempre es bueno dejar un día para retoques finales. Esto reduce las opciones a tres días, y elegimos el martes. Este es el por qué:

• Tenemos el lunes para revisar el lanzamiento y agregar los toques finales antes de implementarlo.
• Si hay frases sin traducir (nuestra aplicación web está disponible en siete idiomas), tenemos tiempo suficiente para terminar la traducción.
• El equipo de marketing tiene mucho tiempo para enviar boletines y anuncios a través de las redes sociales.
• Estamos disponibles para brindar soporte de actualización de manera rápida y eficiente durante el resto de la semana.
• Si una fecha límite ha pasado por cualquier razón, todavía tenemos el miércoles o el jueves para completar el trabajo.

Día de actividad libre

El día después de un lanzamiento importante es un día libre para el equipo. Aquí es cuando aprenden nuevas habilidades o hacen cualquier cosa relacionada con el trabajo que les parezca interesante. Aunque todos están ansiosos por saber qué función lanzaremos al día siguiente, el equipo aún no habla de eso. En cambio, se relajarán y tal vez vean una presentación sobre la historia de Erlang, o terminen de leer ese artículo sobre por qué PSR-7 y el middleware son importantes para el desarrollo de PHP moderno, o tengan su propia discusión retrospectiva. Es un día bien merecido para recargar pilas y celebrar el trabajo bien hecho.

Día de caza de insectos

Además de desarrollar nuevas características importantes, siempre hay trabajo por hacer en las existentes. Ya sea una corrección de errores, una actualización de diseño o un pequeño cambio en la funcionalidad, el equipo debe encargarse de ello en un tiempo razonable.

Es por eso que tenemos días de búsqueda de errores al menos una vez al mes. Es cuando todos los desarrolladores dejan de trabajar en sus proyectos principales y centran su atención en el mantenimiento. Este esfuerzo concentrado ha demostrado ser un gran éxito. Cuando todos trabajan únicamente en errores el mismo día y están disponibles para ayudarse mutuamente, el equipo resuelve una gran cantidad de problemas.

¿Cual es el resultado?

Lanzar una función importante ahora lleva unas tres semanas en promedio, desde el inicio hasta el desarrollo, las pruebas, la revisión del código, la documentación y el lanzamiento final. Una función de complejidad equivalente solía llevarnos 45 días. Desde nuestra perspectiva, eso es un aumento del 100% en la productividad . Lo logramos con los mismos recursos y personas, la única diferencia es un flujo de trabajo mejorado.

Entonces, si tenemos algo para usted, es esto: fomentar una cultura empresarial que elimine el miedo al cambio hará que su equipo sea mejor en lo que hace. Ya sea que lo llame Scrum, Kanban o Lean, no importa, siempre y cuando ayude a su empresa a crecer. La experimentación y la innovación se encuentran en el corazón de cualquier enfoque ágil. No tenga miedo de probar diferentes soluciones, medir los resultados y, en función de los resultados, modificar las prácticas existentes. Seguirán buenos resultados.