En celebración de nuestro 6º aniversario y como complemento a mi artículo 15 lecciones de 15,000 horas de emprendimiento FinTech, Quiero publicar algunos de mis mayores errores para que otros emprendedores puedan evitarlos. 

Nota del editor: 3 * 2 = 6 y 3 ** 2 = 9, por lo que el título todavía está relacionado con nuestro sexto cumpleaños. ¡Por eso es importante aprender a codificar!

 

En primer lugar, antes de la lista, si quieres ser un emprendedor tecnológico, debes aprender a codificar. Quizás eso sea obvio, quizás no lo sea.  Aprender a codificar me permitió para construir la primera versión y, a diario, me permite entender por qué los desarrolladores hacen lo que hacen. Durante un período de tiempo, realmente disfruté codificando y ensuciarme las manos con las API, etc. Un curso de aprendizaje automático me ha permitido interactuar con más confianza no solo con nuestros científicos de datos sino también con los CTO de clientes y socios.

Cometí errores y personas con más experiencia me enseñaron por qué eran errores. Muchos fundadores pueden desarrollar complejos de superioridad, pero conocer tus propios errores te permite identificarte con tus empleados y tener la mente clara.

Ahora vayamos a la lista.

 

1. MVP es una perra

Necesita dinero para construir el negocio, pero todos los inversores quieren ver un Producto Mínimo Viable (MVP). Sin uno, el suyo es solo una idea, o un sueño, desde el punto de vista del inversor. Los sueños son geniales, dirán, pero no son dignos de inversión. 

Intenta construir un MVP lo más rápido posible. Después de todo, es mínimo.

Juntas las cosas; estás aprendiendo sobre la marcha y cada día parece que has logrado mucho. Entonces te das cuenta de que escribiste una línea de código y creaste dos errores nuevos. Toma atajos y, dado que solo necesita que funcione para unos pocos usuarios en la etapa MVP, omite la escalabilidad. Son computadoras, pueden hacer las cosas rápido. ¿Qué tan malo puede llegar a ser pasar de 50 a 5.000 usuarios?

Para mí, no conocía todas las mejores prácticas, como probar, documentar y prepararme para la escalabilidad. El objetivo era tener un producto básico para recaudar fondos, no construir la edición empresarial. Escribí el backend usando el marco de Ruby on Rails pero el frontend en JavaScript y jQuery. Eso parece razonable al principio, y en ese momento, los marcos frontend no eran tan populares. Pero no usar un marco en la interfaz probablemente nos costó un año de refactorización y replanteamiento, porque la escalabilidad y la flexibilidad eran inexistentes y eso se traducía en una experiencia de usuario de largos tiempos de carga. La ineficiencia también significó altos costos de procesamiento y alojamiento en la nube. Por no hablar de explicar (y redescubrir) mi propio código a los desarrolladores, porque mi documentación era mínima y los conceptos de fintech pueden ser bastante complejos para los programadores que no son expertos en finanzas.

Probablemente necesite de 3 a 6 meses para llegar al MVP desde cero y varios meses más para ganar tracción. Al mismo tiempo, necesita recaudar fondos, pero los inversores solo quieren ver tracción e ingresos. Para generar ingresos y tracción todopoderosos, muchos nuevos fundadores intentarán pasar de un MVP directamente a la calidad empresarial. Pero luego los argumentos de venta se desvanecerán porque no será de calidad empresarial, sino que será mínimamente viable. 

Cuando construya su MVP, al menos planifique la escalabilidad y la eficiencia. Nadie puede hacer una prueba de futuro desde el principio, porque ni siquiera sabe si funcionará. Pero siempre tenga en cuenta los desafíos tecnológicos futuros y mitígalos lo mejor que pueda desde el principio.  

Después de recaudar fondos y contratar desarrolladores, es posible que desee refactorizar el código y reevaluar la arquitectura antes de centrarse en más funciones, usuarios e ingresos. Esta inversión inicial de tiempo podría evitar varios problemas importantes en el futuro. Construiste un mínimamente producto viable, después de todo, no un producto óptimo final.

Una forma de evitar la etapa de MVP y la construcción de productos requerida desde el principio es recaudar millones por completo para una idea, una práctica muy común en Silicon Valley. Por supuesto, es un privilegio solo para unos pocos: emprendedores en serie con un historial sólido, amigos de un VC o un inversor ángel importante, o un profesional senior de la industria con muchos contactos. Para el resto de nosotros algunos Será necesario un tipo de MVP antes de ver los dólares o intereses de los inversores.

 

2. Iniciar sesión con todos los Tom, Dick y Harry: me refiero a Facebook, Twitter, Linkedin, Google y ahora Apple

Puede que tenga un espíritu inclusivo. Quizás un usuario le envió un correo electrónico preguntándole cuándo puede iniciar sesión a través de Facebook. Así que miras los documentos y, increíble, son solo unas pocas líneas de código. Pero has abierto la caja de Pandora. Una vez que las “pocas líneas de código” se expanden a muchas y finalmente logra que el proceso de autenticación funcione con sus sistemas, debe integrarlo en todos sus canales de entrega. Si tiene una sola aplicación en iOS, tal vez no sea tan mala. Pero cuando tiene un sitio web, aplicaciones de Android e iOS y sistemas de voz como Alexa y Google Home, debe agregar la funcionalidad de inicio de sesión para todos ellos.

Luego, puede verse obligado a agregar otros, como el inicio de sesión de Apple para usuarios de iPhone (consulte Cláusula 4.8 de sus TyC) si desea seguir prestando sus servicios a través de su plataforma. 

Ahora que tiene 6 piezas de código diferentes, una para cada canal de entrega, ya está todo listo. Hasta que cambie una de las API y necesite corregir su código en todos los canales. A Google y Apple no les preocupa que sus cambios rompan tu pequeña aplicación, pero estarás en problemas si lo hace.

A veces, incluso los usuarios se confunden sobre cómo se registraron: ¿fue a través de Facebook o Twitter? Si es confuso para el usuario, imagínese lo que es crear todos esos métodos de inicio de sesión y luego administrarlos todos, y la confusión del cliente cuando su cuenta no refleja el último cambio que hizo porque había iniciado sesión con un método diferente. 

Las integraciones de inicio de sesión siempre invitan a más integraciones de inicio de sesión

A menos que necesite datos más allá de la autenticación (como imágenes de Facebook o información de usuario de Google), sea exclusivo: use solo un nombre de usuario o correo electrónico y excluya los otros métodos de inicio de sesión. Cuando tiene un flujo de caja positivo y puede permitirse un desarrollador únicamente para la autenticación, puede pensar en agregar varios métodos de autenticación. 

 

3. La tentación de recodificar funciones innecesariamente 

Así como varios métodos de autenticación son “solo unas pocas líneas de código”, escuchará a los desarrolladores decir “el código es demasiado complejo. Déjame reconstruirlo y será mucho más eficiente ”. ¡Presiona el botón de pánico!

Los desarrolladores tienen el impulso para hacer que su código sea eficiente y limpio, y a medida que se agregan más funciones, el código se vuelve complejo. Pero la codificación es solo una parte, y en sistemas complejos, como el cuerpo humano y el clima, pequeños cambios en un lugar del código pueden tener efectos drásticos en cadena más tarde o en otro lugar.

Además, la gestión adecuada de productos no es solo codificación. Una vez que el código está listo, el equipo de Garantía de calidad (QA) debe probarlo. Este proceso invariablemente da como resultado una ida y vuelta que consume mucho tiempo (véase el Sin 6 a continuación). Entonces debe estabilizarse. Si hay algún cambio importante, es posible que sea necesario modificar la mensajería y el diseño. Aparecen efectos imprevistos y, de repente, llegan las quejas de los clientes. 

No repare algo que no esté roto. Hemos hecho esto y pagamos un alto precio a tiempo para el lanzamiento, la estabilidad y la calidad. 

 

4. No entender cómo administrar y motivar a los desarrolladores

En tecnología, los desarrolladores literalmente crean (y destruyen) su producto. Los tipos de personas que se sienten atraídas por el desarrollo de software son de una raza especial y debe comprender cómo funcionan. Puede tener 20 años en la industria y haber dirigido a cientos de personas no relacionadas con la tecnología, pero es posible que todo ese conocimiento y experiencia no ayude a trabajar con los desarrolladores. 

No entender sus motivaciones y cómo operan es un gran error. Conduce a malentendidos, retrasos y dolores de cabeza. En el proceso de contratación, conocerá a muchos desarrolladores que desean un salario alto, una gran autonomía y un horario flexible. La mayoría no querrá revisiones diarias, fechas límite estrictas y horas extras. Toma estas consideraciones en serio.

Más ahora que nunca, el trabajo remoto es una posibilidad real para los desarrolladores, y todo el mundo está contratando. Lo mejor funcionará donde mejor se les trate. Y no desea un producto de mala calidad producido por empleados descontentos, especialmente cuando necesita una solución de último momento antes de presentarlo a los inversores. Los desarrolladores felices harán una excepción con el tiempo extra por usted; los infelices podrían simplemente desaparecer. 

Puedes leer mi artículo completo sobre cómo trabajar con desarrolladores.

 

5. No automatizar las pruebas desde el principio

Al igual que la seguridad, las pruebas de código a menudo se consideran opcionales y una pérdida de tiempo. Pero a medida que el equipo y el producto crecen, la complejidad obligará a realizar pruebas. No puede integrar un componente en un sistema complejo sin ninguna prueba, no sea que esté listo para enfrentar las consecuencias del cliente cuando la producción se paraliza y comienza a escupir códigos de error a los usuarios.

Siempre hemos realizado pruebas unitarias, es decir, probando cada componente individual en sí mismo, antes de conectarlo al sistema completo. Sin embargo, solo comenzamos las pruebas de integración automatizadas holísticas a partir de 2019. Una de las principales razones fue la falta de recursos para volver a probar todo el sistema para cada actualización. Mientras la parte actualizada funcionara, asumimos que todo el sistema funcionaría. 

La automatización de sus pruebas, especialmente para la integración, hace que sea mucho más fácil probar y volver a probar cada parte del sitio para cada integración. Dado que generalmente se desconoce qué cambiará en todo el sistema debido al nuevo módulo, las pruebas de integración deben cubrir todo el sitio. No automatizado, esto es muy tedioso y los QA dedican mucho tiempo a tareas mundanas. Pero una vez automatizados, se liberan.

Esto conduce a una integración continua, en la que se agrega código nuevo constantemente, en lugar de grandes actualizaciones. Si sus pruebas no están automatizadas, espere hasta que estén listos muchos cambios pequeños y luego libérelos todos juntos, de modo que pruebe todo el sistema una vez. Pero una vez que se automatizan las pruebas mundanas en todo el producto, se puede adoptar la integración continua sin desperdiciar recursos de control de calidad en pruebas repetitivas.

 

6. Subestimar el tiempo de lanzamiento: codificación (1x), control de calidad (2-3x), estabilización (2-3x)

Cuando se trata de tecnología, especialmente si viene de fuera del mundo tecnológico, la codificación parece estar al frente y al centro. Quieres crear un producto tecnológico, lo codificas y listo, ¿verdad? Claro, si no lo necesita para funcionar.

Pasará 1 semana en tiempo de desarrollo. Luego, los controles de calidad prueban todo (que no se puede automatizar), se escriben los tickets y el código regresa a los desarrolladores para corregir errores. Luego, los QA obtienen el código modificado y el proceso comienza de nuevo, generalmente tomando 2-3 veces el tiempo de desarrollo original. Una vez que esté listo para impulsar el nuevo código a producción, en caso de big data y características complejas, debe dedicar de 2 a 3 veces el tiempo de desarrollo original para garantizar la estabilidad y el rendimiento de calidad. 

Sumado, pasó de un tiempo de lanzamiento de 1 semana (estimación original para nuevos emprendedores tecnológicos) a 5-7 semanas. No estar preparado para este tipo de aumento de los plazos hará que prometa demasiado con los clientes y presione demasiado a su equipo cuando no se cumpla el plazo. 

Esto es asumiendo que tenía la documentación adecuada para el código en primer lugar y que los desarrolladores ya comprenden lo que necesitan UX, UI y gestión de productos.

La construcción de un producto tecnológico de calidad requiere más tiempo del que la mayoría de la gente imagina.

 

7. Pasar por alto la diferencia de productividad entre codificadores buenos y malos

Hay mucha presión en las primeras etapas para sangrar la menor cantidad de efectivo posible. Esto lleva a contratar desarrolladores junior para proyectos que no deben confiarse a desarrolladores junior. Es genial contratar desarrolladores junior más adelante para que lo ayuden con tareas más pequeñas, pero el núcleo de su negocio es su tecnología: se necesita un desarrollador bueno y experimentado. De lo contrario, dedicará mucho tiempo a reelaborar el código antiguo para mejorar la escalabilidad, la estabilidad y la eficiencia. En el futuro, valdrá la pena pagar más por un buen desarrollador con suficiente experiencia.

Esto requiere ambas cualidades: experiencia y capacidad. Algunos desarrolladores junior son programadores increíbles, simplemente pasan por alto problemas futuros que los programadores experimentados no ignoran. Por el contrario, 10 años de experiencia no se traducen necesariamente en una buena capacidad de codificación. Deberá asegurarse de que ambas cualidades estén presentes. Habiendo aprendido de esto, ahora dedicamos mucho más tiempo durante el proceso de contratación para asegurarnos de que incorporamos al candidato adecuado. Luego, durante el período de prueba, evaluamos su trabajo a fondo y las señales de alerta se tratan de inmediato.

Con la cantidad de trabajo adicional requerido en depuración, recodificación, control de calidad y rediseño debido a un código incorrecto, la diferencia de productividad entre un desarrollador bueno y uno malo o inexperto podría ser 1000x.

 

8. La tentación de construir todas las 'experiencias' internamente

Toda empresa quiere ofrecer una experiencia de calidad a sus usuarios. Cuando se embarca en el viaje para construir esa experiencia, es posible que ya tenga el backend construido. Quizás incluso tenga un par de clientes que usen su API. Debería ser muy fácil entregar esos datos a la interfaz de un consumidor, ¿verdad?

Servir los datos, claro, es fácil. ¿Construyendo realmente la interfaz? Esa es una historia diferente. La interfaz es engorrosa. Primero están los gráficos: necesitará un diseñador para hacer esos gráficos. Las API son solo puntos finales, todo texto y código. Ah, y los gráficos deberán escalar para mostrarse correctamente en diferentes resoluciones de pantalla y navegadores. ¿Y quién no quiere una aplicación móvil? Eso viene con su propia serie de problemas, como tipos de inicio de sesión forzado (ver 2 arriba), múltiples sistemas operativos y hardware variable.

Mi recomendación: tendrá que construir gran parte de la interfaz, pero si puede comprar componentes prefabricados de terceros que le permitan cubrir la mayoría de los escenarios (sistema operativo, hardware, tamaño de pantalla, etc.), compre los componentes prefabricados. Su producto se diferencia por el código de backend y el diseño de frontend, no por el código fundamental de frontend. Si puede comprarlo, evite los dolores de cabeza de control de calidad probando 15 navegadores, tabletas y teléfonos diferentes. No tiene que construirlo todo internamente; puede haber una solución para la compra a un precio razonable. O incluso de código abierto, si tienes suerte. Pero no se deje atrapar por la creencia de que el código abierto siempre vale la pena el ahorro, porque a veces la versión premium resolverá su necesidad exactamente sin ningún tiempo de desarrollo adicional. 

 

9. No comprender las diferencias de roles en un contexto tecnológico

Otro concepto erróneo de quienes no tienen experiencia en tecnología es que todos los roles tecnológicos son más o menos iguales. Claro, los desarrolladores son backend / frontend, la interfaz de usuario es diferente a la infraestructura. Al principio, esto puede incluso ser cierto. Cuando eres solo tú (y tal vez un par más), todos los roles se mezclan. Pero a medida que la empresa crece, la diferenciación y la especialización son necesarias y confundirlas puede ser un costoso error en tiempo y calidad. 

El primer caso en cuestión: el diseño. Hay diseñadores para la interfaz de usuario (UI) y hay diseñadores para la experiencia del usuario (UX). La interfaz de usuario tiene mucha creatividad, lo que hace que todo sea elegante y agradable de ver. UX tiene más que ver con la estructura: ¿cómo fluyen los usuarios a través del sistema? ¿Qué sucede si ocurre un error aquí, el usuario llega a la Pantalla A o a la Pantalla B? ¿Tiene sentido este diseño en el contexto de la procedencia del usuario o simplemente crea confusión?

No conocer la diferencia entre UX y UI puede generar productos visualmente atractivos que frustran y confunden a los usuarios. No solo vendes el look, vendes la experiencia. Asegúrese de que valga la pena el dinero para los clientes, o se irán a otra parte.

También confundí a los desarrolladores de software con el personal de DevOps, lo que generó más presión de trabajo para nuestros desarrolladores. Los sistemas tecnológicos, especialmente aquellos tan complejos como el nuestro, no son únicamente código (como se menciona en Sin 6). Big Data también empuja el límite de lo que pueden hacer los sistemas, por lo que la estabilidad y la accesibilidad se convierten en la máxima prioridad. Por supuesto, en el mundo actual, el tiempo de actividad de 100% se da por sentado, y no cumplir con esto se nota de inmediato. Ya tenemos 1.5 DevOps y es posible que necesitemos contratar uno más para poder agregar más servicios de IA.

Sus desarrolladores, tanto backend como frontend, se centran en el código y el algoritmo. Necesita DevOps para garantizar que la potencia informática esté disponible para ejecutar ese código, y debe ser lo suficientemente estable para mantener contentos a los clientes. No mezcle DevOps y desarrollo de software.

 

9a. Pecados de otro

Recibimos algunas advertencias interesantes de Jelle van Mourik, una lectora de Facebook. Los presentaremos aquí en este encabezado (lo hemos parafraseado un poco y, por supuesto, agregamos nuestro propio sabor):

  • No obligue a los programadores a codificar lo que no codifican. En otras palabras, no intente hacer que un programador de backend trabaje en el código de la interfaz de usuario de frontend y viceversa. Dado que el USD y el RMB son monedas que no se utilizan indistintamente, pueden ser líneas de código, pero los enfoques, las estructuras y la experiencia difieren entre varios aspectos. Errores considerables, retrasos y dolores de cabeza esperan a cualquiera que intente que un codificador codifique lo que no codifica.
  • Diseñe antes de codificar: no hay nada como hacer que todo el código base funcione y darse cuenta de que el nuevo diseño es incompatible o requiere una revisión significativa del código.
  • Vaya a las pruebas de usuario lo antes posible, porque los usuarios son los que no puede controlar y romperán las cosas o las rechazarán, y eso es malo para el negocio.
  • Aborde los comentarios negativos en la aplicación para que los usuarios descontentos le expresen ese descontento a usted, no al público en general en las tiendas de aplicaciones de iOS y Android.
  • Mantenga una sola rama estable para la implementación, no varias ramas "liberables" que divergirán, luego confundirán a todos y les faltarán piezas críticas que le llevarán una semana integrar a tu rama liberada
  • Mantenga una lista explícita de tareas técnicas por hacer y planifique sprints usándola. Estas cosas tienden a pasar desapercibidas. De hecho, si puede pagarlo, es posible que desee contratar a una persona para que se encargue de esta

 

Y esos son los 9 pecados (más los pecados de los lectores). ¿Tiene alguna experiencia similar que le gustaría compartir con nosotros? ¿Alguna otra trampa sobre la que le gustaría advertir a sus compañeros emprendedores? Por favor comente a continuación.