Opiniones polémicas
Cosas que creemos y que podrían incomodar. No buscamos ser contrarios por deporte — son lecciones ganadas a pulso tras años de ver proyectos triunfar y fracasar.
La mayoría de los proyectos de IA no deberían construirse
Al menos no todavía.
Ganamos dinero construyendo soluciones de IA, pero somos los primeros en decirte que la mayoría de los proyectos de IA son soluciones buscando problemas. Antes de automatizar algo, asegúrate de que realmente valga la pena. (O que sea posible automatizarlo.)
A veces una hoja de cálculo, un checklist o simplemente contratar a otra persona es la respuesta correcta. Preferimos perder un proyecto a construir algo que no entregue valor real.
El resultado es lo único que importa.
TODO lo demás es un detalle.
Los nerds podemos quedarnos atrapados en los detalles de cómo se construyen las cosas. Como catadores de código fino, podemos debatir eternamente la mejor forma de hacer algo. Pero al final del día, un código hermoso no vale nada si apesta usarlo.
El software empresarial suele ser terrible
La complejidad no es una característica.
La mayoría del software empresarial está diseñado para venderse, no para usarse. Viene atiborrado de funciones que nadie necesita, requiere meses de implementación y termina siendo evadido en lugar de usado.
Herramientas simples que hacen una cosa bien le ganan a plataformas complejas que hacen todo mal. Tu equipo realmente las va a usar.
Las juntas son donde el trabajo va a morir
Si pudo ser un correo, debió ser un correo.
La respuesta automática a cualquier problema en el mundo corporativo es agendar una junta. La mayoría existen porque alguien no quiso tomar una decisión o escribir algo.
Nosotros nos inclinamos fuerte hacia la comunicación asíncrona y la documentación escrita. Cuando nos reunimos, es porque realmente necesitamos discutir algo, no porque es martes a las 10am.
Lo perfecto es enemigo de lo bueno
Lánzalo. Aprende. Itera.
Hemos visto demasiados proyectos morir en la búsqueda de la perfección. Seis meses planeando, revisiones interminables de stakeholders y documentación exhaustiva — seguidos de un lanzamiento que fracasa porque nadie usó la cosa hasta que estaba "lista".
Preferimos lanzar algo imperfecto en dos semanas, aprender del uso real e iterar. Terminas con un mejor producto más rápido y desperdicias menos dinero en funciones que nadie quería.
La mayoría de las "mejores prácticas" no lo son
El contexto importa más que la convención.
Las mejores prácticas suelen ser solo "prácticas que funcionaron para alguien más en un contexto diferente". Seguirlas a ciegas sin entender por qué existen lleva a ingeniería de culto cargo.
Nosotros pensamos desde los primeros principios. A veces eso significa seguir convenciones. A veces significa ignorarlas por completo. El objetivo es resolver tu problema, no llenar casillas.