cómo escalar tu producto con un equipo pequeño de desarrolladores

Artemio: Hola ¿Qué tal? Bienvenidos a todos a una edición más de Cuando el Río Suena, un podcast que está hecho para todas las personas que están allá afuera construyendo algo donde antes no había nada, también para todos aquellos líderes y operadores de startups tecnológicas en Latinoamérica y el mundo.

El día de hoy me acompaña mi socio Rodrigo Salmerón, como ya es costumbre ¿Cómo estás, Ro?

Rodrigo: ¿Qué tal Arte? Muy bien.

Artemio: ¡Qué gusto tenerte acá ya casi en el capítulo número 100 de este espacio!

El día de hoy nos acompaña Jorge Rangel, de Apphive ¿Cómo estás, Jorge?

Jorge: ¿Qué tal? Estoy muy bien, gracias por invitarme.

Cuéntanos el pitch de elevador de Apphive

Artemio: ¡Es un gusto tenerte por acá! Lo que te trae a esta mesa de conversación es tu puesto como CTO en Apphive. Para poner a todos en la misma página respecto a qué es lo que hacen y qué visión están persiguiendo ¿Podrías contarnos cuál es su pitch elevador?

Jorge: ¡Claro! Desarrollar apps móviles no es sencillo y no solo se trata de los requerimientos técnicos de las personas, muchas veces la parte más complicada es tener el setup y las herramientas correctas para crear la aplicación, Apphive pone tus manos las herramientas ya configuradas para que no te preocupes de qué plataformas vas a utilizar o qué dependencias tienes sino que solamente te preocupes en desarrollar la solución de tu cliente. Nosotros ponemos a disposición de las personas, a un click de distancia, cosas como compilaciones para Android, IOS, web, configuración de servidores y todo lo demás; de tal forma que, si necesitas desarrolladores, sin embargo no necesitas tantos expertos como los necesitarías y empezaras desde cero.

¿Cómo es tu posición como CTO en Apphive?, ¿cómo luce el día a día en tu vida?

Artemio: Fantástico, me encanta esta visión de democratizar un poco el acceso a todo tipo de herramientas. Algo que yo he dicho ya en repetidas ocasiones en este podcast es que, realmente el empoderamiento que da el darle a una persona con software, ya sea para uso personal o para uso profesional, para que una compañía sea mucho más eficiente o brinde una mejor experiencia de cliente, en este momento la barrera para desarrollar este tipo de soluciones es muy alta, de entrada por el precio, después por el tipo de perfiles que necesitas, por consiguiente todos los requerimientos técnicos y el cruzadero de cables que es armar precisamente una solución digital. Por ello, este tipo de soluciones, a mí me encantan porque si yo tiro la visión a largo plazo de cómo debe ser el futuro, debe ser así, más un drag & drop, más de un prompt, diríamos en estos días que está tan habituada esa palabra y menos tener que desarrollar líneas, y líneas, y líneas de código, particularmente cuando no eres tú quien no tiene ese conocimiento técnico pero aun así tiene muchas ganas de hacerlo.

Rodrigo: Jorge, también queríamos preguntarte ¿Cómo es tu posición como CTO en Apphive?, ¿Cómo luce tu día a día? Y ¿Cómo ha evolucionado este rol a lo largo del tiempo?, ¿Cómo es ahora?

Jorge: ¡Claro! De hecho para que tengan un poco de contexto, Apphive no tiene mucho que empezó, hace más o menos cinco años y yo estuve casi desde el principio, prácticamente un año después de que empezó la empresa. Yo no entré como el CTO, sino que entré como desarrollador de Apphive. Somos una empresa muy pequeña en cuanto a personal, sobre todo del área de desarrollo, nunca hemos sido más de 10 para que se hagan una idea del lado de desarrollo. Básicamente desde el principio me tuve que enfrentar a tomar decisiones en cuanto a qué vamos a utilizar para meterle al web, qué vamos a hacer para hacer las aplicaciones de los clientes, cómo vamos a automatizar esto. De hecho de curiosamente, no lo había pensado, pero mis días a días se parecen mucho en el sentido de que siempre están ese tipo de preguntas, siempre está el “Ahora necesitamos sacar esto, qué vamos a ocupar, cómo vamos a presentar las soluciones” Lo describiría muy retador del lado técnico, siempre es muy retador en cuanto a las acciones de hay que sacar esto y hay que buscar la forma.

Empezamos como empresa muy pequeña, ahorita afortunadamente ya tenemos nuestra base de clientes, al principio no nos podíamos dar el lujo de gastar en personas con la experiencia necesaria para que nos orientaran, que nos orientaran en cómo hacer una cosa, cómo hacer lo siguiente; no la tuvimos que fletar nosotros leyendo documentaciones, investigando haciendo experimentos con diferentes cosas. Nos hemos equivocado mucho en algunas cosas pero otras las hemos hecho bien y aquí seguimos. Básicamente así describiría yo mi día a día.

Artemio: Es un constante resolver problemas, pensar en los retos que está enfrentando la compañía ¿Verdad?

Jorge: Es correcto, así es. Sí, siempre y todo el tiempo.

¿Cuál es el reto más grande de construir y mantener un app builder?, ¿Qué tipos de problemas surgen?

Artemio: Cuéntanos, ¿Cuáles son los retos más grandes de construir y mantener un app builder?, porque me puedo imaginar un poco el tipo de box que les reportan sus usuarios o las cosas que ustedes cachan pero ¿Cuáles son los patrones de una plataforma como esta?

Jorge: De hecho, hay dos cosas. La primera, que curiosamente no es tan técnica, es el hecho de que normalmente cuando tú estás en una empresa o en una startup de tecnología siempre, y es verdad, te dan el consejo de que tienes que estar sacando siempre feedback de tus usuarios para tú poder mejorar tu producto, eso sí es válido y también de nuestro lado es válido, pero ¿Creerías que curiosamente hay una parte donde los clientes tienen una idea de lo que necesitan en lo que quieren de una plataforma? Pero como lo dijiste al principio, nuestros clientes no siempre son gente técnica, es decir, suelen ser gente que tienen un negocio y quieren hacer la parte técnica más fácil. La forma en la que te dan el requerimiento no siempre es la ideal y un reto que nosotros hemos tenido muy grande es poder traducir ese requerimiento que ellos tienen realmente en algo que le beneficia a todos. Un ejemplo muy claro está en que luego nuestros clientes, en el principio cuando empezábamos, nos decían: “¿Por qué no puedo arrastrar yo una pantallita que tenga todo mi login ya configurado?, ¿Por qué no puedo agarrar y decir que este es mi login y ponerlo ahí?” Nosotros le decíamos “Sí, mira, la cosa con eso es ¿Qué vas a hacer cuando lo quieras modificar?, Y si ¿Llega otro cliente y quiere algo diferente, cómo le va a hacer para que eso se adapte a lo suyo?”. Yo siento que un gran reto es ese balance entre, qué tan fácil tenemos que hacerlo contra, qué tan flexible tiene que ser para abarcar más clientes. Ese es uno de los grandes retos que tenemos.

Lo otro es que no hay tutoriales de esto, no hay un lugar en el que puedas decirme ¿Cómo hago una plataforma para que los demás pueda hacer aplicaciones?, ese tema sí ya técnico. Por ese lado, muchas veces nos equivocamos por dentro en la estructura de las aplicaciones de los clientes será así. Luego nos encontramos en el camino de que no, porque esto hace que sean muy pesadas, que sean muy lentas cosas así, y tenemos que estar constantemente cambiando eso. Muchas veces los clientes afortunadamente no ven ese paso, no ven la pelea de la migración que tenemos que hacer nosotros por dentro y por fortuna al final ellos ya nada más dicen “Oye, está un poquito más rápida la app, ¿no?” Para mí esa es la parte de la satisfacción de ese lado.

Yo creo que esas son las dos cosas del lado de la producción de la aplicación más difíciles. Hay otra, que es la parte de la motivación de las personas que trabajan en esto. ¿Por qué? Porque normalmente, cuando buscas developers, de ese tipo de personas hay varios, he encontrado gente muy talentosa, pero luego en las empresas los acostumbran a tener soluciones ya hechas para muchas cosas, es decir, les dices “Queremos hacer esta solución, te la dejo en tus manos” Y aunque tengan mucha experiencia, es difícil encontrarse con developers que tengan las habilidades comunicacionales para empezar, que te sepan decir cómo está el problema, que te sepan preguntar, porque muchas veces ni preguntan, es como “Tenemos esta problemática. Ellos responden: Ah sí, déjame ver. No te dice nada y a la hora de la revisión se hacen ajustes” Creo que la razón es el mito de que nosotros los developers tenemos que ser personas que no sabemos hablar con los demás, que somos muy cerrados.

Artemio: Que son puros niños rata.

Jorge: Niños rata es correcto, pero con la experiencia que he visto, creo que me sirven más mis habilidades comunicacionales que la parte técnica, porque entiendes mejor a tus usuarios, sabes decirles mejor las cosas. La parte técnica se resuelve con la documentación y entonces ese es el otro gran reto, encontrar el talento necesario. Ese es un reto que yo he visto que en todas las empresas está. Encontrar el talento que se necesita para sacar las cosas adelante es bien complicado.

Artemio: Está cañón porque, después te encuentras a un rockstar, tal vez lo agarras junior, tu lo formas, va de lujo la situación pero de repente llega alguien que le ofrece el doble del salario, y ya con eso tienes que volver a empezar.

Jorge: ¿Cómo le dices que no? Al final esa persona escoge.

Artemio: 100%, se siente un poco como una graduación agridulce porque es al final de un día, gracias a lo que aprenden en tu compañía lo que les permite aspirar a un salario así, incluso a que un recruiter los escoja y los perfile, que ahí les ande ofreciendo el doble del salario de lo que ganan.

Tirando la visión a largo plazo a 10 año, ¿Cuál es el futuro del trabajo de los developers?, ¿Adquirirá más valor el trabajo de un desarrollador o se disminuirá?

Rodrigo: Oye Jorge, justo tocando este tema, el del salario de los desarrolladores, de que ahora tenemos una explosión pero hay pocos. Tenemos un shortage de desarrolladores en la región. Muchas startups están intentando llenar este gap para que haya recursos para todas las empresas que se quieren hacer, todo porque actualmente el talento está muy competido y las grandes empresas están viendo a quién se roban de la otra empresa. Están en esta competencia que, sin duda sube los salarios de los desarrolladores. Ahora, tirando una visión a largo plazo, digamos a 10 años ¿Cómo ves tú el futuro del trabajo en los devs? Porque, sin duda nos estamos moviendo en una dirección de eficientar este trabajo. Por ejemplo, en Apphive tienen esta visión de requerir menos gente técnica para poder lanzar una solución igual de compleja. Se están construyendo herramientas eficientes para coders pero también para no coders, vamos avanzando poco a poco en esa dirección. La pregunta final es ¿Tú crees que en el futuro, a largo plazo, como te decía a 10 años, va a adquirir más valor el trabajo de los developers?.

Jorge: En mi opinión, bajar no lo creo, estabilizarse sí, la veo más probable a bajar. ¿Por qué? Porque lo que pasa con estas herramientas con la que trabajo yo, que es Apphive o incluso por ejemplo, yo hago mucho coding, así escrito, pero para ello utilizo Copilot y desde que empecé a utilizar esta herramienta y al momento de quitarla, me da flojera y la razón es porque me va autocompletando.

Yo he notado es que la habilidad de un developer, realmente valiosa, es la transformación de los requerimientos del cliente a la lista del checklist técnico, de qué es lo que se tiene que hacer, esa transformación es realmente lo valioso porque ya teniendo el checklist técnico es más fácil poner a una persona con menos experiencia programando a hacerte la solución si está bien claro el requerimiento, por lo que realmente no veo que vayamos a desaparecer los developers, a riesgo de sonar como la persona que tiene una profesión que se está muriendo y que quiere decir que no.

Lo que sí va a cambiar es ¿qué tanto trabajo de nosotros se dedicará a hacer realmente el código o realmente a hacer la configuración los módulos? Todo eso ya va a ser menos carga de trabajo y se va a ir más a ajustar los requerimientos de los clientes. Esa habilidad, que es la más valiosa de un developer, sigue estando ahí y sigue siendo. A pesar de ser lo más impresionante puede utulizar Copilot o esto de Chat GPT, esa parte no te resuelve ese aspecto, es decir, si tú le preguntas varias situaciones no sabe responderlo como un experto. Ejemplo, y no tardo mucho ahí, solamente es para ejemplificar, he dado workshops sobre las plataformas de Apphive y me quedó mucho con la situación de uno de nuestros clientes que me dijo: “Yo estoy haciendo una app de restaurantes y dice mi cliente que quiere que la lista, cada vez que la refresques, la lista salga aleatoria ¿Cómo hago eso?” En ese momento le digo que sí se puede pero yo le preguntaría ¿Por qué quiere que salga aleatoria?. Ya con eso el cliente me da más contexto, mencionaba que quiere no siempre salgan el mismo hasta arriba porque siempre le dan click a ese y por ello ese vende más ese que los demás”. Es ahí donde le digo que más bien lo que tu cliente quiere es distribuirlos por cuánto venden, que vayan saliendo los que menos venden hasta arriba para que les den click. ¿Por qué me quedo con ese ejemplo? Porque ilustra muy bien y de forma muy concreta a lo que me refiero con los requerimientos del cliente; el cliente al no ser técnico tiene una idea de lo que necesita pero rara vez te lo explica de forma que los developers necesitan para implementarla. Por developers solamente no me refiero a las personas sino también a estos sistemas automatizados. En este mundo debe de haber alguien que traduzca lo que te dice el cliente, la persona final a lo que realmente necesitan estas personas que lo ejecutan para que salga bien.

El valor de los desarrolladores que hacen esto va a subir. La única diferencia es que vas a necesitar menos y tal vez eso sea el componente que haga que se estabilice el precio de este servicio. No tanto realmente que sea menos valioso.

Rodrigo: Ahora que mencionas esto, no puedo evitar pensar en las computadoras, no los aparatos, sino las personas que se dedicaron a computar antes de tener los aparatos, eran cuartos y cuartos de gente haciendo cálculos y anotando el resultado, volviéndolos a sacar, ahora los coders podrían pasar un poco a esos cuartos como de manufactura, la talacha o el ensamblaje, sea el trabajo que sea para quedarse nada más con la parte de la ideación y conectar los cables.

Jorge: Exactamente, sí. Por ejemplo, ven que cuando lanzaron el Apolo, las computadoras que realmente programaban las bobinas de esos mecanismos eran mujeres que se dedicaban a tejer, ellas realmente nunca entendían por qué lo tenían que conectar así, nada más lo conectaban. Nuestro trabajo también es bien importante, sin embargo el trabajo que realmente cobra mucho valor ahí es el de la persona que diseñó esas conexiones, sigue siendo exactamente lo mismo, nada más para un nivel más.

Artemio: Ya llevamos unos 10 capítulos donde por más que lo intentamos se cola la palabra Chat GPT, inteligencia artificial, Copilot, Ghost Rider, es imposible no estar hablando en este paradigma porque realmente es el último paradigma en el tech y es una de las fronteras existen, que están empujando.

Para quienes quieran echarse un clavado en todo lo que están haciendo en el Open AI, toda la visión que tiene esa inteligencia artificial o esa empresa, vayan a ver un podcast del Lex Friedman, un profesor del MIT, es una conversación como de 2:30 horas y media con el CEO de Open AI que se llama Sam Altman. Él justo menciona algo que se me hace bien interesante y que a mí me pone mucho a pensar, él dice que: “En medida que estos modelos del lenguaje y esta inteligencia artificial que están construyendo ellos, que además es muy abierta y es bastante fácil de implementar, es una API bien sencilla de integrar a tu negocio si realmente ahí está la necesidad de integrarlo” Lo que menciona con todo este paradigma, es que el costo de la inteligencia artificial va a decrecer muchísimo, no el valor, pero el costo de tener acceso a esta información, y ya no solo en materia de Google sino que incluso esté digerida y que sea conversacional, también que incluso tú puedas proponer planes de acción sobre eso y además, para los que están ahí en la frontera, seguro han estado viendo cómo surgen estos auto agentes donde hay un promt inicial y según el resultado, la misma el AI lo revisa, lo refina y pone un nuevo promt que refina el trabajo que está haciendo el AI, así hasta llegar a un resultado y ya ni siquiera necesitas estarle dando órdenes.

Aunque todos estos mecanismos se ven un poco complejos, porque yo creo que cualquier persona que esté usando Chat PT y es experta en materia de consultoría en cualquier tema, te das cuenta que se queda corto el robot, y te dices a tus adentros: Yo aquí sigo siendo el mero mero. Pero ¿Qué pasa con la siguiente iteración y la que sigue?

Yo creo una AI puede hacer o va a poder hacer el 90% en la chamba que no sea física de cualquier tipo de posición y por ello creo que lo único que va a salvar el que alguien opte no hacerlo con un AI y hacerlo tal vez con tu empresa o con tu persona es generalmente la marca, la persona o el look & feel que tú le puedas dar, único de tu persona y de tu ente en esta Tierra en comparación de un AI, en comparación es el toque personal lo único que pienso yo que nos puede salvar, porque al final ves y siento que si tiramos la visión a 10 años va a poder hacer todo lo que nosotros mejor y más rápido.

Yo estoy ahí viendo como un AI eventualmente va a ser que quiebre nuestra empresa pero nosotros la vamos a usar primero hasta que eso suceda.

Jorge: Con lo que me acabas de decir, hace poco estaba viendo un video de un tipo que está allá en Suiza que se dedica a hacer muebles y hablaba de: ¿Qué prefieres comprar la mesita de café de Ikea o mandarme a hacer una? Esa persona dice que la que mandas hacer con él te va a costar 10 veces más que la de Ikea y además la recibes luego, luego, en cambio, la mía te vas a tener que esperar dos meses. Él estaba ilustrando los puntos fuertes de cada una y con lo que acabas de decir, eso del toque personal, me vino a la mente algo importante, el hecho es que, no es tanto de que vaya a llegar a ser superior o no a la equivalente a persona que haga ese trabajo en el chat, sino que uno como empresa no siempre escoge lo mejor de lo mejor, sino lo que mejor se adapte a lo que necesitas para distribuir tu producto. Por ejemplo, si tú te vas a dedicar a vender mesas, no te vas a poner con esta persona que yo vi en un video en YouTube a pedirle tus mesas para que la saque una tras otra conforme las vas vendiendo, sino porque te figuras en cierta forma de hacerlas en serie. Vas a sacrificar calidad y ese toque personal, nunca va a llegar a ser así como la mesa que construye él en meses, porque le mete mucho trabajo: le mete otros materiales, el material es más caro, y también la personalizada. Si en tu casa no cabe una como la de Ikea, él le puede bajar centímetros, le puede tallar tu nombre a un lado, el de tu novia o lo que tú quieras. A lo que voy es que, yo siento que algo muy similar está pasando con estos nuevos sistemas, no va a sustituir a ninguno de los trabajos intelectuales, sino más bien que les va a dar a las empresas la opción de tener un producto diferente, que cumpla las necesidades que tiene en ese momento.

Incluso en developers, ejemplo de lo anterior es que si quieres un script nada más para usarlo una vez que te haga algo en tu base de datos, eso lo haces con el chat, no vas a decirle un desarrollador para que se lleve tres horas haciéndolo cuando el chat le dices, te lo hace y muy probablemente ni bugs va a tener. Sin embargo, igual se va a escuchar que lo digo para salvarme yo, pero en las plataformas de desarrollo tienes que tomar muchas decisiones que no son técnicas, aquellas que van más del lado de las personas; yo no dudo que si le das el suficiente contexto a un interpretador de lenguaje como Chat GPT, este pueda darte una respuesta aceptable, pero el problema es darle todo ese contexto, el problema es meterle todo eso ahí para que lo vea. Yo voy más por ese lado, y si tienden a ser más potentes, pero como no soy experto yo en esa área, no sé exactamente hasta donde esté el límite de realmente qué sea lo que puedan hacer, no me siento tan confiado en especularlo porque de hecho yo también he escuchado a varias personas que son expertas en eso y ese es su respuesta. Artemio: Claro y sería preocupante que la gente experta en AI creyera que la AI les va a quitar la chamba, hablaría de que ya estamos llegando a eso, a mí me gusta pensar que todavía no estamos ni cerca.

¿En qué equipo tiene más desarrolladores dentro Apphive?

Artemio: Pero bueno, ya, cerramos la sección de Chat GPT, obligada de un capítulo más.

Rodrigo: Oye Jorge, para avanzar un poco, queríamos preguntarte ¿En qué equipo tiene más desarrolladores dentro Apphive? Digamos ¿El builder o los propios módulos, el de tecnología? Ya nos contaste que nunca han sido más de 10, cuéntanos a grandes rasgos, ¿Dónde están acomodados los 10?

Jorge: De hecho, lo que hacemos nosotros es que tenemos un solo departamento de desarrollo, no tenemos una división por plataforma, somos un equipo de desarrollo y debido que te digo que somos pocos, no nos hace sentido ahorita dividirnos así en dos ramas. Siempre nos hemos estado peleando con eso porque la velocidad a la que sacamos los features es aceptable, pero yo creo que sí podría ser mucho más grande si tuviéramos más gente.

Una de las cosas que yo siento que es más ventaja de nuestro lado, que de hecho creo que es la única ventaja que tenemos las startups sobre las empresas grandes, es a la velocidad a la que podemos cambiar de dirección. Nosotros, como no somos muchos y que por cierto todos estamos remotos (antes teníamos ubicación física, pero después de la pandemia no hemos vuelto a tener la necesidad) la ventaja que yo veo es que me puedo sentar con todos, hablar con todos, tener todos el mismo panorama y repartirnos las tareas y si en algún momento la gente de negocio determina que es más importante hacer otra cosa, podemos virar inmediatamente sin tener que hacer un gran escándalo al respecto. Yo siento que es la única ventaja que tiene el hecho de que seamos pocos, nosotros no distribuimos más de ningún lado. Lo que sí te puedo decir al respecto es que solemos enfocarnos más en el lado de la estabilidad del producto, todo porque ya nos ha pasado anteriormente es que nos hemos peleado mucho con muchas dependencias que tenemos, ejemplo de ello es que, no es muy fácil que a cada rato Android o IOS actualizan cosas. Ellos se mueven increíblemente rápido y luego las personas que tienen esas plataformas, igual que nosotros, suelen no pensar tanto del lado de su usuario que usa esas plataformas, dicen “Yo lo voy a actualizar porque tengo que actualizarlo y ahora ni modo, tu entiendes de dos sopas: O te quedas donde estás o te actualizas”.

Esa constante batalla que nosotros tenemos con actualizarnos, creo que eso es a lo que le hemos dedicado un poco menos de tiempo últimamente. Obviamente siempre estamos intentando sacar cosas nuevas, y como dicen, si haces bien tu trabajo no lo va a ver el cliente, el cliente nunca va a decir “Ah, esta gente tiene up to date mi SDK de Android” No eso no, al cliente final lo que le interesa es que su aplicación siga funcionando y le siga generando business.

De ese lado es donde ahorita estamos más, respondiendo a tu pregunta, sí estamos proyectando seguir creciendo.

Otra cosa que siento que nosotros hemos hecho bien, es no agarrar y decir “Vamos a contratar 20 devs de trancazo” No porque también le he puesto bastante énfasis al lado humano de esto, de desarrollar aplicaciones y si nos llevamos más tiempo en capacitar a cada uno, en que se sienta cómodo con las herramientas y en que le vaya dando; por ello, como no somos muchos, tampoco puedo dejar a tres o cuatro coacheando juniors para dejar de hacer cosas nuevas que tenemos que hacer. Es un tema medio delicado de nuestro lado, pero sí, si queremos crecer, pero ahorita no tenemos una distribución.

Artemio: Es un estira y afloja interesante.

Algo que nos gusta mucho a mí y a Rodrigo recordarle a nuestro equipo es que todo el valor que perciben nuestros clientes, nosotros, como una agencia que desarrolla software personalizado para empresas, todo el valor realmente se percibe en cuanto la máquina funciona. Precisamente por cada bug que se encuentra el cliente decrece ese valor percibido que estamos aportando a la empresa que nos contrata. Es cuando se encuentra ese bug, cuando se encuentra esa falla, cuando no funciona su software, es ahí cuando se cae toda la planeación que hicimos, todas las entrevistas de usuario, es todo un tema de *software management (*y este es uno que no es nada sencillo), es altamente técnico, todas las horas que pasamos diseñando y desarrollando que pasándote a Figma, haciendo la documentación, que además nada de eso es percibido por el cliente más que el robot funcionando, de ahí viene el énfasis en tener una buena arquitectura, en hacer QA, en todo lo que haces para asegurarte de que tu software funciona.

Mencionas algo que me lleva a otro capítulo, no recuerdo con quién fue, más bien han sido un par de capítulos, pero algo que nos dijo Paul, que es una excelente inversionista de startups aquí en Latinoamérica es que “Siempre tienes que resistir el urge to hire”, particularmente cuando bajas una nueva ronda de inversión, crees que la solución esté en contratar gente y siempre tienes que preguntarte dos veces si realmente eso es la solución al problema que estás enfrentando, porque también el meter más gente a tu equipo, involucra más problemas, más gente, más capacitación y no necesariamente siempre es la mejor solución al problema que estás enfrentando.

Intermedio

Artemio: Estamos llegando al intermedio de este programa. Le recuerdo a toda la gente que nos está escuchando que en cuandoelriosuena.com ustedes se pueden suscribir a la newsletter de este programa y recibir una notificación cada que saquemos un capítulo nuevo, lo hacemos todos los lunes de manera religiosa y también queremos pedirles con el corazón en mano Rodrigo y yo, que si pueden compartir este espacio, esta comunidad, este recurso con alguien que esté operando o liderando cualquier área en una startup de tecnología o cualquier emprendedor que está allá afuera, que por favor lo haga. Este espacio es ellos, se va a mantener gratuito y realmente la bola de nieve que se está armando aquí entre recursos, conexiones, conocimiento, cómo hacerle en cosas que tú también vas a vas a enfrentar en tu camino, es algo muy emocionante, así que formen parte de esto, todo empieza suscribiéndose a esa newsletter. Regresamos.

¿Cómo eligen qué funcionalidades deben ser personalizables y cuáles no dentro de Apphive?

Rodrigo: Bienvenidos de vuelta a este episodio de Cuando el Río Suena, en esta ocasión con Jorge Rangel, CTO de Apphive.

Retomando algo que en realidad ya habíamos mencionado antes pero que no nos detuvimos a profundizar, ¿Cómo eligen qué funcionalidades deben ser personalizables y cuáles no dentro de Apphive?

Nos comentabas que sus usuarios les pedían personalización en lugares donde tenían que decirles no. ¿Cómo toman ese tipo de decisiones? Me puedo imaginar que mucho tienen que ver con la data y con lo que está pidiendo al usuario, entonces ahí como que se puede promediar, pero me imagino que hay algo más que hay cierto factor ahí de creatividad de su lado. Cuéntanos ¿Cómo es este proceso?

Jorge: Para que quede bien claro cómo llegamos a lo que estamos ahora, en un principio, eso que me acabas de decir era un desastre pero bien bonito; era más especulativo el asunto, era más por el lado de que teníamos un feature, nos sentábamos las tres personas que en ese momento que éramos los responsables de esa parte y entre nosotros discutíamos por qué debería o por qué no debería de ser más o menos personalizable. A veces funcionaban y otras resulta que no era así el caso.

Actualmente tenemos varias formas de determinarlo. Una es que, por ejemplo, nosotros hacemos workshops con nuestros clientes en los cuales hacemos funcionalidades en la plataforma y en la cuáles ellos nos discuten su punto de vista de por qué debería de estar algo de cierta manera; es muy diferente a que simplemente les preguntes, cuando tú le preguntas a un usuario, el usuario normalmente te escribe algo muy general, pero ya viéndolo en un ejemplo claro es más fácil. Y como en los workshops hay más personas, el feedback no suele ser nada más puntual a un requerimiento de un cliente, sino que es más para todos. Tiene sus fallos porque muchas veces pasa como a todos nos pasa, que cuando una persona dice algo y te suena bien todos se van para allá, ese es uno de los canales, sin embargo eso no es todo el panorama. Después de eso nos sentamos nosotros del lado de desarrollo y las personas de negocio e igual discutimos al respecto, ya teniendo la la propuesta de los usuarios cuál es la idea que se tiene.

Un tema que muchas veces ha salido del lado de los developers es que decimos “Eso suena mucho a algo que ya hace otra plataforma para desarrolladores”. Por ejemplo, eso que quieren hacer con las librerías de audio para reproducir canciones. Suena mucho a una librería de NPM que alguno de nosotros ya utilizó. Lo que hacemos es, vemos varias librerías desde el lado de desarrollo, vemos cómo está la forma en la que ellos pretenden que tú la uses, vemos cuáles son las más populares, las más fáciles de usar y las utilizamos como una base para contrastar lo que los usuarios nos dijeron, hasta ese punto llegamos a un acuerdo, no será tan fácil al principio, pero lo hacen así porque es más flexible para estos casos, es preguntarnos que no queremos que sea tan difícil por alguna otra razón. Por último final lo que hacemos es un experimento. Deberías de ver cuánto trabajo nos costó dar con un proceso real de hacer experimentos, porque hacer experimentos en el lado empresarial es muy complicado. La mayoría de las personas no tienen una idea clara de qué es un experimento o cómo se ejecuta uno, gracias a que la mayoría piensan que la idea del experimento es probar que lo que estás diciendo es verdad, cuando realmente, casi siempre, lo que buscamos es probar que es mentira, eso funciona mucho mejor, dices “Mi postulado es que si le pones esta variable a esta función va a ser más fácil de usar” ¿Cómo me pruebas que no es verdad eso que te estoy diciendo? Y entonces al final, ya con toda esa información metemos dos o tres variantes, hacemos experimentos con algunos usuarios y ya nos convence una, y esa es la que metemos. Esto no siempre es así, muchas veces el tiempo nos come y al final agarramos en alguna parte del proceso, la cortamos y lo metemos así y ya después pagamos el precio. Si los clientes después nos dicen “Así, no funcionaba”, lo tenemos que cambiar, pero ese proceso que les describí es el que intentamos seguir, pero como les digo, muchas veces el negocio no se espera a que nosotros este tomamos la decisión y nos dice “Ya tenemos que sacarla porque ya la teníamos en el roadmap para los clientes y ya están diciendo que a qué hora queda” Entonces es una constante pelea de esos dos lados, esa es la estructura que intentamos llevar a la hora de decidirlo.

Rodrigo: Qué interesante este enfoque científico para probar estos features.

Por otro lado, suena al siguiente paso lógico, en lugar de hacer la prueba de fuego directamente con los usuarios y sentir ahí la frustración o el resultado de la decisión, para ello intentas hacerlo en un laboratorio antes para ver cómo funciona dicha integración antes de llevarlo al público. Eso de que se les acabe el tiempo es la virtud de la startup, que les permite ir a la velocidad a la que a la más rápida que puedan y corregir sobre la marcha, que tampoco se pierde tanto ahí.

¿Cómo deciden que tan complejas o que tan accesibles hacer sus funcionalidades?

Artemio: Construir una app tiene muchos componentes complejos, hemos hablado de varios, de entrada el técnico, pero al mismo tiempo hay una lógica de negocios pero algo que yo he identificado que en lo que personalmente soy bueno es ser bueno dándole referencias a mi equipo de cosas que están muy bien hechas en el campo digital. Sin embargo, aunque yo no tengo el conocimiento técnico de lo que involucra, se desarrolla cierto gusto que tiene que ver más con una especie de lógica de negocios, de cómo funcionan las cosas en el ambiente digital. Así podemos simplificar 1,000 cosas que se derivan de una aplicación. ¿Cómo deciden que tan complejas o que tan accesibles hacer sus funcionalidades?

Ahorita hablábamos, particularmente de que cuando hacen personalizable la funcionalidad pero tal vez, incluso como llevándolo a una capa más de abstracción ¿Cómo es que toman estas decisiones en función de sus usuarios porque, yo me imagino que sus usuarios son los menos técnicos de los menos técnicos y pero no sé ahí, tú ya me corregirás.

Jorge: Sí, con eso hay una frase en inglés que es “Tú solo te disparas en el pie”, no sé si la han escuchado. Es que cuando estás desarrollando algo hay herramientas que están diseñadas para que te dispares tú solo en el pie, a lo que me refiero es que dependiendo de qué tanto nivel técnico tengas, si te hacen una herramienta muy libre, puedes casi hacer malware con la funcionalidad que te dan o puedes pegarte a tu negocio, porque de hecho, eso que dices tu es bien importante.

Nuestros clientes, la gran mayoría, de hecho, empiezan sin un background técnico, esa también ha sido una de las cosas que hemos visto nosotros, al principio la mayoría de nuestros clientes son emprendedores que no tenían los recursos para contratar a la parte técnica y querían ahorrársela con una plataforma, eso es más común. Es menos común la persona que ya tiene el desarrollo y la formación técnica y que quiere utilizar la plataforma, con respecto a eso de cómo decidimos las cosas también tenemos que cuidar mucho esa parte.

Nos pasó hace poco con algo de geolocalización, especificando, con la geolocalización de los clientes, teníamos una función en la que te va reportando cada vez que se mueve el carro, muchos usuarios querían una opción para que te lo reportaran más veces. ¿Qué es lo que pasa? Si no sabes bien lo que estás haciendo, lo que hacían era que cada vez que reportaba, mandaban a llamar a un server y ese server hacía un montón de cosas, se quemaban todos sus recursos en eso con dos o tres usuarios que tenía en ese momento activos.

También ha sido primordial de nuestro lado es ponernos en la cabeza de alguien que no sabe de lado técnico, que tú le dices “Quiero hacer a esto” y a él se le hace la cosa más natural del mundo estar mandando a llamar al servidor, porque para él un servidor es un servicio en la nube que es como mágico. No consume tanto recurso como una compu, cómo te cobra la base de datos, cómo te cobra todo ese tipo de cosas. Es bien difícil, por la ceguera de taller que tenemos nosotros, luego dar con esas cosas, los usuarios nos sorprenden mucho con ese tipo de cosas y no es malo, es lo que les digo a ellos, no te estoy diciendo que te falla porque no eres técnico, tú mismo lo dijiste, es porque yo sé que tú estás viendo lo del lado del business. Cuando necesitas una herramienta que de verdad tienes que tener todo el poder de decidir esas dos, también es nuestra responsabilidad dejarle claro al usuario que si le mueve ahí tiene el riesgo de hacer cosas que él no pensaba hacer. Por ejemplo, en esta que les digo de estar reportando, si lo dejamos bajarse a intervalos que el quiera, pero si se baja intervalos le decimos “Oye, este intervalo que estás poniendo aquí puede llevarte a gastos innecesarios en tu servidor, puede llevarte a que tu teléfono bloqueen las llamadas al server porque también eso lo hace el teléfono para no gastar pila y entonces puedes usarla, pero por favor, testéala antes bajo tu riesgo”

Ese decirles no es muy común, porque si tú lo ves del lado del ámbito de un desarrollador normal, a lo mejor le advierten el desarrollador, pero el cliente final nunca se da cuenta de eso, no lo ve. Siempre ha sido ahí, más o menos una cuestión medio difícil, no siempre tenemos nosotros la visión para adelantarnos a lo que nuestros clientes pueden hacer, las personas que no tienen la formación técnica suelen ser muy creativas en cómo romperte tus tus sistemas, casi nunca te vas a dar cuenta. A mí me ha pasado infinidad de veces y me va a seguir pasando, que entregó un producto y el cliente le pica, hace algo que yo ni me imaginaba que le iba a hacer, es decir que ni por la cabeza me había metido. Ese suele ser un reto muy grande, intentamos hacerlo, pero honestamente no hemos dado con una forma de predecirlo, a menos que se hagan experimentos; haciendo experimentos, sí, porque ellos mismos son los que lo hacen, pero ahí en fuera no hay otra forma.

Rodrigo: Claro, esto que dices de que los clientes siempre van a encontrar cómo romper tu aplicación, es algo que nos hemos encontrado muchísimas veces y nos divierte mucho siempre que lo mencionan porque nos podemos imaginar en qué escenarios acabaron para que esta sea selección. La importancia de testear y de buscar, ya sea de testear de forma automatizada y de estar con usuarios reales para que puedan buscar los caminos y ver dónde es más probable que truene la aplicación por un uso que alguien más en dónde se le va haciendo más natural del mundo de cargar y recargar el sitio o hacer una búsqueda después, hay 1,000 maneras de romper algo cuando no se pensó para usarse en esa dirección.

¿Cuál es el perfil más especializado/retador a nivel técnico que emplean en Apphive?, ¿por qué es tan importante para ustedes?

Rodrigo: Jorge, de los 10 desarrolladores que son en el equipo, ¿Cuál es el perfil más especializado/retador a nivel técnico que emplean ahí en Apphive? ¿Y por qué es tan importante para ustedes?

Luego tenemos a personas de ciencia de datos, a gente que le mueve a la inteligencia artificial, que son perfiles más difíciles de conseguir que por ejemplo con react, que puede ser ahora el estándar.

Jorge: En este momento es Dev Box, este siempre ha sido la parte más complicada para nosotros en desarrollo, de hecho, actualmente ya lo tenemos figurado, porque la gran mayoría normalmente lo haces una vez, lo de buggeas, funciona y ya se queda, sin embargo este ha sido la parte más challenging, ya les había platicado hace un momento de cómo tenemos que estar pesando, teníamos antes que estar pesando mucho quién contratábamos, por qué razón y todo. No teníamos tiempo, no teníamos la opción de tener que esperarnos a que alguien llegara para configurarlo, tuvimos que intentarlo, nosotros no. Esa parte que suele no ser el énfasis de la mayoría de los programadores o de los desarrolladores; los desarrolladores cuando llegan al puesto, lo primero que te dicen es “Yo sé react, si estás contratando un runner, si estás contratando un backend use en off, yo manejar ese QL ¿Sabes levantar la parte técnica de la app? Pero ahora la que les dices “OK, ¿Qué instancia, en qué configuración y en qué sistema operativo voy a ocupar para mi servidor? ¿Cómo voy a configurar los de plugados a la PlayStore, a la App Store?” Esa parte fue la más complicada del lado técnico y la que ahorita es la más valiosa porque a pesar de que ya la tenemos hecha, constantemente se tiene que estar actualizando, como les mencioné hace rato, por los cambios, en todas las plataformas hay cambios, por ello todo eso se tiene que hacer.

Eso ha sido una de las cosas más challenging, nunca hemos contratado una persona que digas es la persona de ciencia de datos o la persona especializada en AI que hace esto, a la fecha no lo hemos hecho. De hecho, la filosofía que tenemos ahorita, es primero intentamos hacerlo de este lado, primero intentamos figurarlo, si de plano vemos que no está dentro de nuestra capacidad o de nuestro tiempo, ahora si buscamos a alguien, pero afortunadamente no ha sido el caso, afortunadamente las personas que están en el equipo han sido increíblemente valiosas y todos tienen la cultura de ser autodidactas y si les dejas algo te dicen “No lo sé hacer, pero lo vamos a figurar ahorita”. Estoy de acuerdo que, de haber tenido un experto desde un principio, nos hubiéramos ahorrado muchos dolores de cabeza, pero como te digo, no teníamos esa opción, así básicamente está en el asunto, eso es más o menos lo más valioso que tenemos ahorita.

¿Cuál es el consejo más importante que te llevas con el tiempo de trabajar con plataformas de las grandes ligas?

Rodrigo: Ahorita que mencionas esto, teníamos por ahí otra pregunta, que al final sacamos de la lista que te queríamos hacer porque nos encontramos unos tutoriales dentro del website de Apphive sobre el proceso que tenía que seguir alguien para publicar su aplicación en las Apps stores. Pensamos que era algo un poco externo que cada usuario un poco tenía que gestionar por su lado, pero claro, ustedes tienen que hacer el diploide de todos los bills, ver que cuadre, ver que avance, que no haya ningún problema, que el código no se tronó… aún con todas las configuraciones que le haya metido cada uno de los usuarios, que como dijimos en la pregunta anterior, están dedicados a ver cómo rompen tu producto, entonces sí me gustaría recuperarla, porque creo que valen la pena ¿Cuál es el mejor consejo que nos darías?, ¿Cuál es el consejo más importante que te llevas con el tiempo de trabajar con plataformas de las grandes ligas?

Jorge: Hay uno que es muy específico en la App Store de Apple. y tienes que conocer más o menos qué es lo que espera la App store de tu App, tú tienes que tener como en tu cabeza los lineamientos básicos de lo que siguen, por ejemplo, cómo se hacen los loggins, qué cosas puedes meter, qué cosas no puedes meter, para la hora de decidir qué meter a tu aplicación, meterlas. Eso va más allá de la parte de tu configuración técnica, eso lo tienes que tomar en cuenta para poder subirlos, porque bajo nuestra experiencia del lado de Google son muchísimo más libres a la hora de de revisar las aplicaciones. Dudo mucho que realmente la revisen todas así bien, nada más la revisan su parte automática y ya si ven que tienes muchos clientes, ya ponen a alguien a revisarte, es lo que yo he visto por experiencia. Al contrario, en App Store es más random a veces no te la revisan, pero es más común que te las vayan a revisar. El primer consejo es que tengas presente en los lineamientos de ambas tiendas, pero sobre todo de de App Store, de qué es lo que debe de llevar de tu app, independientemente de en qué rubro estás.

La otra que también quiero enfatizar mucho, y que normalmente los clientes luego no toman en cuenta, es que la aplicación no es tu negocio, es lo que luego la mayoría de las personas no te dicen ¿A qué me refiero? A que muchas personas llegan con esta idea de, por ejemplo, si yo te dijera que soy un mago y tú me dices que quieres tu aplicación de Uber y yo hago un truco, ya está tu aplicación de Uber en tiendas, además ya la tienes y funciona al 100%. Yo lo que quiero que esté bien presente es que eso no es garantía de que vas a tener un business, esa es ninguna garantía de que vas a tener un business de hecho; normalmente es primero el business y luego la solución técnica, no al revés. Mi segundo consejo es primero autoevaluarse de si realmente estás en la posición de hacer una aplicación, porque para nosotros es mucho mejor, de verdad deseamos mucho más este que nuestro cliente tenga el éxito económico a que tenga el producto hecho, porque el producto hecho no es más que una herramienta para el éxito económico de su empresa, debe de tener en cuenta si la aplicación es realmente lo que necesita en ese momento. Normalmente es primero el negocio y luego la aplicación.

La que les recomiendo y es que también no olviden que a pesar de que automatizamos un montón de partes, de todos modos va a requerir un algún conocimiento técnico durante el camino. Tú dijiste, viste un tutorial ahí y hemos tenido muchos clientes que se confunden, incluso tengas tres, cuatro pasos al deploggear una aplicación va a haber personas que van a tener problemas en cumplirlo y eso es completamente normal. A lo que voy es que cuando entren a este espacio, mi consejo sería es que tomen en cuenta que se van a frustrar en algún momento con algo que no entienda y dependerá de cada uno determinar si vale la pena o no zambullirse en entenderlo para hacerlo bien. Nosotros hacemos todo lo posible para que sea lo más fácil para el cliente, pero muchas veces hay cosas que realmente no se pueden omitir porque son del lado de ellos, no queremos tener el control sobre algunas cosas de su lado de ellos y ellos tienen que tener esa decisión, muchas veces nuestros clientes no están preparados para esa decisión en ese momento.

Nos pasa mucho que hay gente que llega, hace su aplicación, la compila y después quiere cambiar toda su configuración porque no eran la que ellos querían y eso es muy normal porque al principio no la tenía en presente.

Es importante que se detengan un poquito a entender bien qué es lo que viene ahí. Actualmente estoy trabajando yo mucho con el lado de negocio porque ese otro gran reto que ya no es de mi lado, pero yo les puedo ayudar también ahí a mis compañeros de negocio y es la comunicación de ese challenging técnico a nuestros usuarios: cómo se los dices, cómo les haces saber qué es lo que a lo que se van a enfrentar. Ninguna plataforma de estas no code elimina el challenging técnico sino que lo hace más suavecito, lo hace más accesible, pero sigue ahí.

Mi bottom line sería: Prepárate porque vas a tener un challenging técnico, a fuerza.

Ante los retos que se enfrenta Apphive y tú como su CTO en los próximos años, ¿qué te quita el sueño?

Rodrigo: Jorge, ya la última pregunta, nos estamos acercando al final del capítulo y hemos disfrutado mucho la conversación. Esta última pregunta se la hacemos a todos los invitados desde que empezamos a hacer el podcast, esta es: Ante los retos que enfrenta Apphive y tu como su CTO, en los próximos años ¿Qué te quita el sueño?

Jorge: Que perdamos la visión de que la parte humana por el lado de desarrollo, al final, es la más importante para el desarrollo.

Voy a hacer un poquito más específico, conforme va creciendo la empresa, que yo tengo la seguridad de que va a seguir creciendo, lo único que me preocuparía es que fuéramos descuidando más y más el recurso humano del desarrollo y lo veamos más como una caja negra que simplemente tú le das requerimientos y te sacas software, porque la gran mayoría de las cosas que han sido increíblemente valiosas para nosotros han salido o son producto de la pasión de nuestros programadores, han sido resultado de que ellos van más allá de lo que les pedimos y de que innovan a la hora de que nosotros les pedimos algo, eso no lo hace una persona que no se siente apasionada por lo que está haciendo, no lo hace una persona que no tiene interés por lo que está haciendo.

Tengo muchos colegas que trabajan en empresas grandes donde un programador es un engrane súper pequeñito en una súper maquinota; ellos sienten que realmente no hacen la diferencia y tristemente es que no la hacen. Si se van, hay como 20 más que pueden sustituirlos en esa máquina, la forma en la que en la que se maneja el recurso de desarrollo, actualmente es mucho más de pues dame la mano de obra ahorita y cuando terminemos esto, venga lo que sigue, pero realmente es lo que nos ha dado a nosotros más valor es conservar a nuestra gente, cuidarla, educarla y que ellos nos eduquen a nosotros, que se sientan parte del equipo, eso sería lo que me preocuparía conforme vamos creciendo, que realmente sí cosas técnicas que nos fueran a preocupar de ese lado, no tanto por experiencia, siempre las hemos resuelto sin embargo la parte más difícil siempre ha sido el lado humano de esto.

Artemio: Perfecto, ahí lo tienen, Jorge Rangel de Apphive. Muchas gracias Jorge por venir acá a compartir un poco de tu experiencia y de todos los insights que has ido recabando en tu camino en esa compañía.

De igual forma, muchas gracias Ro por un capítulo más y gracias a todo el equipo de producción que hace esto posible.

Quiero recordarle a todos ustedes que en cuandoelriosuena.com, ustedes se pueden suscribir a la newsletter de este programa y recibir una notificación cada que saquemos un capítulo nuevo. De igual forma vale la pena que vayan a suscribirse a esta newsletter porque se acerca nuestra conferencia anual, Latam Startup, la verdad es que los temas de este año a mí me emocionan muchísimo, sabemos que quieren construir empresas que son remotas pero que sean productivas, sabemos que hay muchos solo entrepenurs ahí afuera, por supuesto que vamos a hablar de AI y de toda esta nueva ola tecnológica que existe. Sabemos que están lidiando con el burn out. Sabemos que quieren implementar semanas de trabajo de 4 días y conocemos un montón de cosas que están enfrentando todos los emprendedores allá afuera y esta conferencia lo que pretende es reunir a las mejores mentes en un espacio para que puedan contarnos cómo es que están solucionando estos problemas que todos estamos enfrentando. Va a ser gratis, así que vayan a suscribirse a la newsletter, todo empieza ahí.

Nos vemos a la próxima, muchas gracias.