Algunos principios que me importan cuando el software acompaña a personas repartidas entre muchas oficinas, procesos y decisiones del día a día.
Mucho software interno vive en un lugar extraño: es crítico para quienes lo usan, pero rara vez recibe la misma atención externa que los productos orientados a clientes.
Eso vuelve aún más importante la disciplina de producto.
En mi trabajo actual pienso bastante en qué pasa cuando un mismo sistema tiene que acompañar al staff de muchas oficinas con contextos, expectativas y hábitos operativos diferentes.
Cuando el software interno se comparte de forma amplia, trato de enfocarme primero en tres cosas.
Las personas deberían entender dónde vive la información, qué acciones tienen disponibles y en qué estado está el sistema.
Los sistemas internos suelen fallar porque acumulan excepciones y conocimiento implícito. Una buena UI no resuelve todos los problemas de proceso, pero puede reducir muchísimo la confusión.
Cuando muchos equipos usan la misma herramienta, la consistencia se vuelve una forma de confianza.
Los patrones deberían repetirse. Las etiquetas deberían mantenerse estables. Tareas similares deberían comportarse de manera similar. Esa consistencia hace más simple la capacitación y reduce el costo de cambiar entre flujos.
Las herramientas internas no se construyen solo en código. También se construyen a través de revisiones, planificación, estimaciones y comunicación.
Si un equipo no comparte las mismas expectativas sobre calidad, alcance y entrega, el producto eventualmente va a reflejar esa confusión.
Los sistemas internos son prácticos. Muestran si un equipo puede construir software que ayude a personas reales a hacer trabajo real con menos fricción.
Ese es un desafío que me sigue resultando interesante.