«¡Solicitud de características!!!»
A menudo es el grito de batalla que usamos los ingenieros de software para minimizar la urgencia del problema de un cliente. Después de todo, no hay tiempo para agregar nuevas características cuando miramos el interminable registro de errores que enfrentamos.
Para los ingenieros de software de EE.UU., la diferencia entre un error y una solicitud de característica es muy clara. Un error es una discrepancia entre cómo funciona realmente el código y cómo se pretendía que funcionara nuestro código. Una solicitud de característica requiere código nuevo para satisfacer un caso que no puede ser manejado por la base de código actual.
Este tipo de proceso de pensamiento siempre nos lleva a la pregunta más general de cómo se debe usar software como DoneDone. ¿Debería su organización usar un tipo de software para registrar errores, otro tipo de software para administrar tareas futuras y otro tipo de software para rastrear solicitudes de funciones?
Gastamos mucha energía mental tratando de examinar los problemas registrados por un cliente o un cliente, tratando de determinar si lanzamos un problema al cubo de «errores» o al cubo de «solicitud de características». Para el trabajo de consultoría, cuando trabajamos con un acuerdo predefinido de cómo debe comportarse el software, esto tiene sentido. Las solicitudes de funciones pueden requerir un cargo adicional.
Pero, cuando se trata solo de la práctica pura de crear un buen software, particularmente si estamos trabajando en nuestros propios productos, ¿cuánto deberíamos preocuparnos por categorizar un problema de esta manera?
Dejamos que los tecnicismos (y la tecnología) se interpongan en el camino de la solución de problemas.
Robert Martin (también conocido como Tío Bob) habla mucho sobre software. Considera que la Web es simplemente un mecanismo de entrega y nada más. No es la experiencia del usuario final, y no es el propósito del software. Es simplemente un pequeño detalle tonto. Sin embargo, cuando los programadores programamos, la arquitectura de nuestras aplicaciones está demasiado influenciada por el hecho de que es una aplicación web.
De la misma manera, ¿y si consideramos que el término que usamos para «una cosa que debe hacerse» es un detalle tonto?
Desde el punto de vista de la persona que registra esa «cosa», ¿realmente le importa que esté solicitando una nueva función en lugar de descubrir un error? Ella solo quiere que su problema sea resuelto por otro ser humano, y preferiblemente, para saber cuándo su problema podría ser resuelto.
Es posible que pueda ver el tecnicismo más obviamente si dejamos el mundo del software. Cuando el fontanero venga a arreglar la ducha con goteras, imagino que no te importan los detalles. Si el cabezal de la ducha estaba instalado incorrectamente (error) o si la junta está rota (error) o si faltaba cinta de teflón en una tubería barata (característica), todo lo que te importa es cuánto tardará en arreglarse y cuánto se te cobrará.
Error o petición? Son las dos cosas. Y, no importa.
La semana pasada lanzamos Kin, una herramienta de software de recursos humanos para pequeñas empresas. Kin le ofrece una forma sencilla de rastrear las solicitudes de tiempo libre de cada empleado. Una cosa que Kin no hace en este momento es distinguir los fines de semana y los días festivos de los días de trabajo. Por lo tanto, si desea tomarse una semana completa durante el Día de Acción de Gracias, debe ingresar manualmente la cantidad de horas que solicita.
El equipo ya ha recibido algunas solicitudes para que los parientes hagan este seguimiento automáticamente. De hecho, está en la cola de lanzamiento. Pero, cuando se registra, en cualquier lugar en el que se registra, ¿debería el equipo de Kin considerarlo un error, una solicitud de característica, una tarea o una tarea pendiente?
Llamando a mi tío Bob interior, mi respuesta es simple: No importa cómo clasifiques la solicitud. Es sólo un detalle tonto.
Eso no quiere decir que no debamos clasificarlo en absoluto. El equipo de Kin podría etiquetar el problema en «solicitud de características» y trabajar primero en solucionar problemas más críticos (como un usuario con un problema de autorización). Eso está muy bien, y es un enfoque válido.
Sin embargo, sería un error asumir automáticamente que todas las solicitudes de características de las cosas que llamamos son menos urgentes que todos los errores de las cosas que llamamos. Eso es hacer que el detalle más bien menor de cómo clasificamos el problema sea la pieza central para cuando lo resolvamos. No debería ser así. Al final del día, todas estas solicitudes son simplemente cosas que necesitan resolución.
Que el tecnicismo sea el detalle tonto
Con ese fin, la etiqueta que damos a todas estas solicitudes no es en gran medida importante. Lo que importa más es que alguien los esté atendiendo y que haya una idea general de cuándo se atenderán estas solicitudes. Lo que importa más es que un 33% más de usuarios se beneficiarán de que se dirija al Elemento A en comparación con el Elemento B. Independientemente del tipo de elemento A o B, el Elemento A es más valioso de abordar. Eso es. Nada más.
Así que, la próxima vez que dediques demasiado tiempo a categorizar tareas, errores, solicitudes de características y tareas pendientes, recuerda olvidar los detalles técnicos. Son sólo detalles tontos.
Regístrese para obtener una cuenta DoneDone en 30 segundos. ¿Quieres leer más de Ka Wai Cheung? El nuevo libro de Ka Wai sobre el programador de hoy en día, El Código del desarrollador, está disponible en libros electrónicos e impresos. Puedes seguirlo en Twitter @developerscode.