Ignacio Arriaga · 10/03/2023
Índice
La tecnología es una parte vital en cualquier producto software, pero en ocasiones se comenten errores infantiles al gestionarla. Aquí algunas cosas que hemos aprendido nosotros con el paso de los años.
Las modas duran un tiempo y tú esperas que tu producto dure más que las modas. Elegir un stack tecnológico porque es trendy suele ser una mala idea. En el 99% de los casos elegiría algo open source para realizar mi software. Es muy improbable que la ventaja del código cerrado compense el riesgo de utilizar algo propietario.
Mi opinión es que es mejor buscar frameworks y librerías que lleven unos años desarrollándose y tengan comunidad importante detrás. Los forks y los años de desarrollo suelen ser mejor indicativo que las estrellitas de github. La grandísima mayoría de los SaaS suelen ser un CRUD al uso. Olvídate de escalabilidad en la primera fase, porque ni siquiera sabes lo que tienes que escalar. Lo más simple y, sobre todo, con lo que mejor te manejes, suele ser la elección correcta.
El stack es más importante a la hora de adquirir talento que diferencial a la hora de realizar el producto. Pero en ocasiones pensamos que por tener el stack más moderno vamos a acceder a un pool mayor de talento y yo tengo dudas sobre esto. Creo que hay un montón de desarrolladores acostumbrados a programar en tecnologías más antiguas que los que están formados en las nuevas.
El no-code está muy bien para hacer prototipos, pero si vendes software seguramente te va a tocar programarlo. De otra forma la diferenciación con tus competidores será mínima y destacar en el mercado será muy complicado. Creo que una de las cosas que peor llevan los builders de apps no-code es la experiencia de usuario. Al final es muy difícil dar una buena experiencia en un producto si quieres poder construir todos los productos con una herramienta. Es cierto que hay productos muy exitosos que tienen una UX que dan ganas de arrancarse los ojos, pero porque suelen estar impulsados por mucha pasta y equipos de ventas muy tochos. Y por lo general no tenemos acceso a esos recursos.
El extremo opuesto es incluso menos saludable. No construyas nada que no sea lo que vas a vender. Si necesitas cualquier servicio que no sea tu core, paga por él. Los desarrolladores muchas veces caemos en la falacia de pensar que ahorraremos desarrollando algo y solemos olvidarnos de lo que cuesta mantenerlo. Todos hemos pensado que era buena idea desarrollar un sistema de tickets propio. No construyas nada que no sea tu core. Si algo desarrollas que sea para ganar dinero, no para ahorrarlo.
El concepto de programador que vale por diez no existe. Si alguien se cree tan tan bueno que se considera un 10x programmer, mi apuesta es que va a ser un cretino de tomo y lomo. Es mejor un buen programador con el que se puede trabajar que un genio que es un cretino.
No necesitas al mejor programador que curre en el último sitio fancy, hay muchísimo talento penando en cárnicas. Si el tipo no tuitea, te costará 10k menos al año. Estoy bromeando, en parte, pero las personas que no comparten su trabajo son muchas más que las que sí lo hacen. El trabajo es trabajo, compartirlo es un hobby.
En lo del GitHub con o sin actividad no pensaba ni entrar, pero parece que todavía hay que decirlo en 2022. La gente que programa para otros no suele tener contribuciones en GitHub. Y no pasa nada, hay muchas otras formas de analizar si alguien tiene talento o no.
El secreto para tener un buen equipo es, en este orden: pagarles bien, tratarles bien y dejarlos que hagan su trabajo tranquilos. El mejor canal de adquisición de talento es tu propio equipo. Si la gente está contenta cuando busques gente te traerán oportunidades. Si no es así, preocúpate porque se van a ir.
La motivación es una de las claves de la felicidad de cualquier persona. Saber para qué sirve tu trabajo y cómo impacta al negocio es crucial para sentirte importante. No alejes a los desarrolladores de la parte de negocio.
Hay muchas formas de explicar al equipo técnico en las decisiones de negocio. Para mí, la más útil, es la transparencia. Si una persona no sabe cuánto se factura, qué impacto tienen las funcionalidades en la facturación o cómo se rentabiliza lo que hace, entonces hay un problema de comunicación. Explícales estas y cosas y trata de explicar por qué van a construir lo que les estás pidiendo.
Si crees que los diseñadores se dedican a pintar, mal vamos. En un producto software es tan importante –o más– el que "pinta" que el que programa.
Es complicado que la tecnología sea diferencial, es muy fácil que la UX lo sea. Invierte en gente que entienda qué hay que mostrar al usuario y cómo mostrarlo de la mejor manera.
Invierte en gente que sepa lo que es el CSS, porque si no el paso del producto a la implementación va a ser motivo de tensión.
En una empresa pequeña hay que tener cuidado eligiendo entre la rigidez de una metodología y la flexibilidad (y el caos) de que no haya ninguna. Aplicar scrum o similar puede tener sentido a partir de un determinado tamaño, pero hay que tener mucho cuidado de dejar suficiente espacio para las cosas que vayan surgiendo.
Cuanto menos maduro es un producto, más cosas inesperadas van a surgir y más flexibilidad vas a necesitar. Lógicamente una mínima organización es necesaria pero hay que estar psicológicamente preparado para saber que va a haber muchos cambios de foco. Es difícil hacer una planificación a un mes vista, imagínate a tres meses o a un año.
A no ser que vendas velocidad, no optimices. En versiones iniciales es una pérdida de tiempo y de foco. Que algo no se rompa nunca, probablemente signifique que lo has desplegado demasiado tarde.
Es muy difícil saber qué hay que optimizar antes de ponerlo en producción. En tu cabeza vas a tener miles de usuarios en una semana. Lo más probable es que, si tienes suerte, tardes años en tenerlos. Vas a perder tu tiempo y tu foco en optimizar cosas que, probablemente, jamás van a necesitar esa capacidad que crees.
* Si no lo sabes pero te interesa el mundo del software: debes suscribirte y lo descubrirás inmediatamente.