Estudio de 2 o agencia de 30: de qué depende la calidad de un SaaS

La calidad de un SaaS es la parte de lo que un equipo publica que funciona para los usuarios a la primera, y lo que mejor la predice es cuántas personas tocan cada parte del código y si cada parte tiene un responsable. La plantilla que aparece en la web de un proveedor no predice ninguna de las dos cosas. Un estudio de dos personas y una agencia de treinta pueden entregar un producto que falla cada semana. Y los dos pueden entregar uno que funciona.

Este artículo es para el founder o el CTO que tiene dos presupuestos encima de la mesa, uno de un estudio pequeño y otro de una agencia grande, con una diferencia de precio que pide una explicación. La explicación más habitual es la calidad: un equipo grande suena a experiencia, revisiones y suplentes; uno pequeño suena a riesgo. La investigación sobre defectos de software mide algo más concreto, y puedes comprobarlo en los dos proveedores antes de firmar. Si tu pregunta es qué alcance encaja con qué tamaño, empieza por nuestra comparativa entre estudio pequeño y gran agencia. Aquí hablamos solo de calidad.

¿Qué dicen los datos sobre tamaño de equipo y defectos?

QSM, una empresa de estimación de software que recoge datos de proyectos terminados desde 1978, ha estudiado el tamaño de los equipos varias veces. En 2012 Kate Armel comparó 1.060 proyectos de TI cerrados entre 2005 y 2011, divididos en equipos de hasta 4 personas a tiempo completo (mediana de 2,1) y equipos de 5 o más (mediana de 8,5). En los proyectos pequeños, los equipos grandes costaron 3 veces más y entregaron el doble de defectos. En los proyectos grandes costaron 4 veces más, con el triple de defectos. Las personas de más apenas acortaron el calendario.

El resultado se repite en todas las muestras de QSM. El estudio de Doug Putnam de 1997, sobre 491 proyectos, señalaba como óptimos los equipos de 3 a 7 personas para sistemas de tamaño medio. Una muestra posterior de 390 aplicaciones comparó equipos de menos de 4 personas con equipos de 9 o más: los grandes recortaron el calendario en torno a un 30%, pero el coste subió un 350% y los defectos que hubo que corregir en pruebas, un 500%, según el resumen de QSM de sus cuatro estudios sobre tamaño de equipo.

Hay un matiz que cambia cómo se leen todas estas cifras. QSM midió el equipo del proyecto, no el tamaño de la empresa que lo empleaba. Una agencia de 30 personas puede poner a 4 en tu producto. Un estudio de 2 puede sumar colaboradores externos hasta que 9 personas escriban en tu repositorio. El número que cuenta es el del equipo que toca el código, y casi nunca aparece en la primera página de un presupuesto.

¿Por qué la plantilla es el número equivocado para comparar?

Se lee rápido, pero responde a otra pregunta: cuánto trabajo puede llevar un proveedor a la vez. La calidad depende de cómo se reparte ese trabajo. Melvin Conway describió el mecanismo en 1968, en How Do Committees Invent?: las organizaciones que diseñan sistemas acaban produciendo copias de sus propias estructuras de comunicación.

Un producto hecho por un departamento de diseño, un equipo de frontend y otro de backend suele mostrar las costuras donde esos equipos se encuentran. Un producto hecho por dos personas las muestra donde esas dos personas dejaron de hablarse. El tamaño cambia dónde caen las costuras; todo equipo deja alguna, y los cinco puntos que siguen te dicen dónde quedarán las tuyas.

Cinco cosas de las que depende la calidad de un SaaS

1. Cuántas personas tocan cada parte del código

En 2008, Nachiappan Nagappan, Brendan Murphy y Victor Basili estudiaron 3.404 binarios de Windows Vista, más de 50 millones de líneas de código, para saber qué medidas predecían los binarios que fallarían después del lanzamiento. Ocho medidas organizativas, como cuántos ingenieros habían editado un binario y a qué distancia estaban en la cadena jerárquica, identificaron los binarios con riesgo de fallo con una precisión del 86,2% y una exhaustividad del 84,0%. Los cambios en el código (churn) se quedaron en el 78,6% y el 79,9%. La complejidad del código, en el 79,3% y el 66,0%. La cobertura de pruebas llegó al 83,8% de precisión, pero solo al 54,4% de exhaustividad. Cómo estaban organizadas las personas decía más sobre dónde aparecerían los fallos que cualquier propiedad del propio código.

2. Si cada parte tiene un único responsable

En 2011, Christian Bird y sus colegas de Microsoft Research continuaron con Don't Touch My Code, sobre Windows Vista y Windows 7. Dividieron a quienes contribuían a cada binario en contribuidores principales, con al menos el 5% de los cambios, y contribuidores menores, por debajo de ese umbral. En Vista, el número de contribuidores menores se correlacionaba con los fallos previos al lanzamiento con un coeficiente de 0,86, y con los posteriores con 0,70. La parte de los cambios del responsable principal tenía una correlación negativa, de menos 0,49 en ambos casos. Los componentes que mucha gente tocaba un poco fallaban más. Los que tenían un responsable claro, menos.

En un equipo pequeño la responsabilidad llega casi sola, porque hay pocas personas con quien repartirla. Un equipo grande también puede tenerla si la diseña: un responsable con nombre y apellidos por módulo, y cada cambio que llega de fuera revisado por esa persona.

3. Quién se va antes de terminar

Entre las medidas de Nagappan estaba también el número de ingenieros que habían tocado un binario y después habían dejado la empresa. Quien hereda código que no escribió no sabe por qué se escribió así, y esos huecos acaban en defectos. Este riesgo no favorece a ningún tamaño. En un estudio de dos personas, una salida se lleva la mitad del conocimiento. En una agencia grande, la gente cambia de cliente cuando arrancan proyectos nuevos, y salir de tu cuenta equivale a salir de tu código. Pregunta a los dos proveedores cómo lo gestionan, y que la respuesta quede en el contrato.

4. Cuántos traspasos hay entre el diseño aprobado y la pantalla publicada

Cada traspaso es un punto en el que alguien reformula una decisión que no tomó. El diseñador pasa el archivo a quien hace el frontend, que pasa una petición de API a quien hace el backend, que pasa una build a quien hace QA. Cada paso puede hacerse bien. Cada paso es también una ocasión más para que la pantalla en producción se aleje de la que aprobaste. Cuenta los traspasos del proceso de cada presupuesto y pregunta para qué sirve cada uno.

5. Quién escribe el código y quién lo revisa

Las personas que aparecen en la presentación comercial no siempre son las que escriben el código. Pasa en cualquier proveedor que venda más trabajo del que sus perfiles senior pueden hacer en persona, sea pequeño o grande. La experiencia llega al código a través de la revisión: un revisor senior en cada cambio de pagos, autenticación y acceso a datos detecta los defectos que más cuesta corregir después. Pregunta quién revisa, en qué partes del producto y si un cambio puede entrar sin esa revisión.

¿Hasta dónde llega un equipo de dos personas?

La investigación que favorece a los equipos pequeños también marca sus límites. Dos personas no pueden llevar cuatro líneas de trabajo a la vez: un lanzamiento con web app, dos apps nativas y un pipeline de datos en la misma fecha necesita más manos. Dos personas rara vez cubren a fondo todas las especialidades: una prueba de penetración, una auditoría formal de accesibilidad o una guardia de 24 horas suelen venir de fuera. Y una responsabilidad concentrada en dos personas es también un riesgo concentrado en dos personas. Un estudio pequeño que se toma en serio la calidad te dice qué especialistas suma y qué pasa con tu producto si una de sus personas se para.

¿Cuándo vale la pena un equipo de treinta?

Una agencia grande justifica su plantilla cuando el trabajo se divide en líneas paralelas, cada una llevada por un equipo pequeño con su propio responsable. Treinta personas organizadas en cinco equipos de seis se comportan, según los datos anteriores, como cinco equipos pequeños con un coste de coordinación añadido. Treinta personas en un único grupo, asignadas a lo que urge esta semana, se comportan como los equipos grandes de los datos de QSM. El presupuesto no te dice cuál de las dos estás comprando. Las preguntas de abajo, sí.

¿Cómo comprobar la calidad de un proveedor antes de firmar?

1. Pide los nombres de quienes escribirán en el repositorio. Nombres y roles, y si esos nombres entran en el contrato.
2. Pide el mapa de responsables. ¿Quién lleva pagos, autenticación, modelo de datos y design system? Un nombre para cada uno.
3. Pide la regla de revisión. Qué cambios necesitan un segundo revisor y quién es.
4. Pregunta qué pasa cuando alguien deja el proyecto. Preaviso, periodo de solapamiento, traspaso por escrito. Las cláusulas que conviene buscar están en nuestro artículo sobre las ocho cláusulas a revisar en un contrato.
5. Pregunta qué cifras de entrega siguen. DORA, el programa de investigación sobre entrega de software que lleva años en marcha, mide la inestabilidad con dos ratios: el change fail rate, la parte de los despliegues que necesitan una intervención inmediata, y el deployment rework rate, la parte de los despliegues no planificados que provoca un incidente en producción. Un proveedor que mide alguna de las dos puede enseñarte una tendencia. Uno que no mide ninguna calcula su propia calidad a ojo.
6. Pide ver el historial de un proyecto parecido. Aunque oculte los nombres, un log de commits muestra cuántas personas tocaron cada módulo y con qué frecuencia una publicación vino seguida de correcciones.

Una fase de discovery corta y de pago es la forma más barata de ver estas respuestas en la práctica antes del contrato principal. Las preguntas para la primera llamada están en nuestra guía sobre cómo contratar un estudio de product engineering.

Dónde estamos nosotros

Somos un estudio pequeño, así que lee esta sección teniéndolo en cuenta. Los datos favorecen un equipo sobre tu código que sea pequeño, estable y con responsables claros, lo emplee quien lo emplee, y un estudio pequeño puede fallar en eso igual que una agencia grande. Cuando un proyecto necesita más líneas paralelas de las que puede llevar un equipo pequeño, lo decimos en la primera llamada.