{"id":26393,"date":"2020-06-19T12:46:27","date_gmt":"2020-06-19T12:46:27","guid":{"rendered":"https:\/\/cityfalcon.com\/blog\/?p=26393"},"modified":"2020-06-25T07:10:56","modified_gmt":"2020-06-25T07:10:56","slug":"9-product-and-technology-sins-of-a-founder-who-learnt-to-code","status":"publish","type":"post","link":"https:\/\/www.cityfalcon.ai\/blog\/es\/the-startup-journey\/9-product-and-technology-sins-of-a-founder-who-learnt-to-code\/","title":{"rendered":"9 pecados de producto y tecnolog\u00eda de un fundador que aprendi\u00f3 a codificar"},"content":{"rendered":"

En celebraci\u00f3n de nuestro 6\u00ba aniversario y como complemento a mi art\u00edculo <\/span>15 lecciones de 15,000 horas de emprendimiento FinTech<\/span><\/a>, Quiero publicar algunos de mis mayores errores para que otros emprendedores puedan evitarlos.\u00a0<\/span><\/p>\n

Nota del editor: 3 * 2 = 6 y 3 ** 2 = 9, por lo que el t\u00edtulo todav\u00eda est\u00e1 relacionado con nuestro sexto cumplea\u00f1os. \u00a1Por eso es importante aprender a codificar!<\/em><\/p>\n

 <\/p>\n

En primer lugar, antes de la lista, si quieres ser un emprendedor tecnol\u00f3gico, debes aprender a codificar. Quiz\u00e1s eso sea obvio, quiz\u00e1s no lo sea.<\/span> \u00a0Aprender a codificar me permiti\u00f3<\/span> para construir la primera versi\u00f3n y, a diario, me permite entender por qu\u00e9 los desarrolladores hacen lo que hacen. Durante un per\u00edodo de tiempo, realmente disfrut\u00e9 codificando y ensuciarme las manos con las API, etc. Un curso de aprendizaje autom\u00e1tico me ha permitido interactuar con m\u00e1s confianza no solo con nuestros cient\u00edficos de datos sino tambi\u00e9n con los CTO de clientes y socios.<\/span><\/p>\n

Comet\u00ed errores y personas con m\u00e1s experiencia me ense\u00f1aron por qu\u00e9 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.<\/span><\/p>\n

Ahora vayamos a la lista.<\/span><\/p>\n

 <\/p>\n

1. MVP es una perra<\/b><\/h2>\n

Necesita dinero para construir el negocio, pero todos los inversores quieren ver un Producto M\u00ednimo Viable (MVP). Sin uno, el suyo es solo una idea, o un sue\u00f1o, desde el punto de vista del inversor. Los sue\u00f1os son geniales, dir\u00e1n, pero no son dignos de inversi\u00f3n.\u00a0<\/span><\/p>\n

Intenta construir un MVP lo m\u00e1s r\u00e1pido posible. Despu\u00e9s de todo, es m\u00ednimo.<\/span><\/p>\n

Juntas las cosas; est\u00e1s aprendiendo sobre la marcha y cada d\u00eda parece que has logrado mucho. Entonces te das cuenta de que escribiste una l\u00ednea de c\u00f3digo 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\u00e1pido. \u00bfQu\u00e9 tan malo puede llegar a ser pasar de 50 a 5.000 usuarios?<\/span><\/p>\n

Para m\u00ed, no conoc\u00eda todas las mejores pr\u00e1cticas, como probar, documentar y prepararme para la escalabilidad. El objetivo era tener un producto b\u00e1sico para recaudar fondos, no construir la edici\u00f3n empresarial. Escrib\u00ed 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\u00f3 un a\u00f1o de refactorizaci\u00f3n y replanteamiento, porque la escalabilidad y la flexibilidad eran inexistentes y eso se traduc\u00eda en una experiencia de usuario de largos tiempos de carga. La ineficiencia tambi\u00e9n signific\u00f3 altos costos de procesamiento y alojamiento en la nube. Por no hablar de explicar (y redescubrir) mi propio c\u00f3digo a los desarrolladores, porque mi documentaci\u00f3n era m\u00ednima y los conceptos de fintech pueden ser bastante complejos para los programadores que no son expertos en finanzas.<\/span><\/p>\n

Probablemente necesite de 3 a 6 meses para llegar al MVP desde cero y varios meses m\u00e1s para ganar tracci\u00f3n. Al mismo tiempo, necesita recaudar fondos, pero los inversores solo quieren ver tracci\u00f3n e ingresos. Para generar ingresos y tracci\u00f3n todopoderosos, muchos nuevos fundadores intentar\u00e1n pasar de un MVP directamente a la calidad empresarial. Pero luego los argumentos de venta se desvanecer\u00e1n porque no ser\u00e1 de calidad empresarial, sino que ser\u00e1 m\u00ednimamente viable.\u00a0<\/span><\/p>\n

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\u00e1. Pero siempre tenga en cuenta los desaf\u00edos tecnol\u00f3gicos futuros y mit\u00edgalos lo mejor que pueda desde el principio.\u00a0\u00a0<\/span><\/p>\n

Despu\u00e9s de recaudar fondos y contratar desarrolladores, es posible que desee refactorizar el c\u00f3digo y reevaluar la arquitectura antes de centrarse en m\u00e1s funciones, usuarios e ingresos. Esta inversi\u00f3n inicial de tiempo podr\u00eda evitar varios problemas importantes en el futuro. Construiste un <\/span>m\u00ednimamente <\/span><\/i>producto viable, despu\u00e9s de todo, no un producto \u00f3ptimo final.<\/span><\/p>\n

Una forma de evitar la etapa de MVP y la construcci\u00f3n de productos requerida desde el principio es recaudar millones por completo para una idea, una pr\u00e1ctica muy com\u00fan en Silicon Valley. Por supuesto, es un privilegio solo para unos pocos: emprendedores en serie con un historial s\u00f3lido, amigos de un VC o un inversor \u00e1ngel importante, o un profesional senior de la industria con muchos contactos. Para el resto de nosotros <\/span>algunos <\/span><\/i>Ser\u00e1 necesario un tipo de MVP antes de ver los d\u00f3lares o intereses de los inversores.<\/span><\/p>\n

 <\/p>\n

2. Iniciar sesi\u00f3n con todos los Tom, Dick y Harry: me refiero a Facebook, Twitter, Linkedin, Google y ahora Apple<\/b><\/h2>\n

Puede que tenga un esp\u00edritu inclusivo. Quiz\u00e1s un usuario le envi\u00f3 un correo electr\u00f3nico pregunt\u00e1ndole cu\u00e1ndo puede iniciar sesi\u00f3n a trav\u00e9s de Facebook. As\u00ed que miras los documentos y, incre\u00edble, son solo unas pocas l\u00edneas de c\u00f3digo. Pero has abierto la caja de Pandora. Una vez que las \u201cpocas l\u00edneas de c\u00f3digo\u201d se expanden a muchas y finalmente logra que el proceso de autenticaci\u00f3n funcione con sus sistemas, debe integrarlo en todos sus canales de entrega. Si tiene una sola aplicaci\u00f3n 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\u00f3n para todos ellos.<\/span><\/p>\n

Luego, puede verse obligado a agregar otros, como el inicio de sesi\u00f3n de Apple para usuarios de iPhone (consulte <\/span>Cl\u00e1usula 4.8 de sus TyC<\/span><\/a>) si desea seguir prestando sus servicios a trav\u00e9s de su plataforma.\u00a0<\/span><\/p>\n

Ahora que tiene 6 piezas de c\u00f3digo diferentes, una para cada canal de entrega, ya est\u00e1 todo listo. Hasta que cambie una de las API y necesite corregir su c\u00f3digo en todos los canales. A Google y Apple no les preocupa que sus cambios rompan tu peque\u00f1a aplicaci\u00f3n, pero estar\u00e1s en problemas si lo hace.<\/span><\/p>\n

A veces, incluso los usuarios se confunden sobre c\u00f3mo se registraron: \u00bffue a trav\u00e9s de Facebook o Twitter? Si es confuso para el usuario, imag\u00ednese lo que es crear todos esos m\u00e9todos de inicio de sesi\u00f3n y luego administrarlos todos, y la confusi\u00f3n del cliente cuando su cuenta no refleja el \u00faltimo cambio que hizo porque hab\u00eda iniciado sesi\u00f3n con un m\u00e9todo diferente.\u00a0<\/span><\/p>\n

\"\"<\/a>

Las integraciones de inicio de sesi\u00f3n siempre invitan a m\u00e1s integraciones de inicio de sesi\u00f3n<\/p><\/div>\n

A menos que necesite datos m\u00e1s all\u00e1 de la autenticaci\u00f3n (como im\u00e1genes de Facebook o informaci\u00f3n de usuario de Google), sea exclusivo: use solo un nombre de usuario o correo electr\u00f3nico y excluya los otros m\u00e9todos de inicio de sesi\u00f3n. Cuando tiene un flujo de caja positivo y puede permitirse un desarrollador \u00fanicamente para la autenticaci\u00f3n, puede pensar en agregar varios m\u00e9todos de autenticaci\u00f3n.\u00a0<\/span><\/p>\n

 <\/p>\n

3. La tentaci\u00f3n de recodificar funciones innecesariamente\u00a0<\/b><\/h2>\n

As\u00ed como varios m\u00e9todos de autenticaci\u00f3n son \u201csolo unas pocas l\u00edneas de c\u00f3digo\u201d, escuchar\u00e1 a los desarrolladores decir \u201cel c\u00f3digo es demasiado complejo. D\u00e9jame reconstruirlo y ser\u00e1 mucho m\u00e1s eficiente \u201d. \u00a1Presiona el bot\u00f3n de p\u00e1nico!<\/span><\/p>\n

Los desarrolladores tienen el impulso para hacer que su c\u00f3digo sea eficiente y limpio, y a medida que se agregan m\u00e1s funciones, el c\u00f3digo se vuelve complejo. Pero la codificaci\u00f3n es solo una parte, y en sistemas complejos, como el cuerpo humano y el clima, peque\u00f1os cambios en un lugar del c\u00f3digo pueden tener efectos dr\u00e1sticos en cadena m\u00e1s tarde o en otro lugar.<\/span><\/p>\n

Adem\u00e1s, la gesti\u00f3n adecuada de productos no es solo codificaci\u00f3n. Una vez que el c\u00f3digo est\u00e1 listo, el equipo de Garant\u00eda de calidad (QA) debe probarlo. Este proceso invariablemente da como resultado una ida y vuelta que consume mucho tiempo (v\u00e9ase el Sin 6 a continuaci\u00f3n). Entonces debe estabilizarse. Si hay alg\u00fan cambio importante, es posible que sea necesario modificar la mensajer\u00eda y el dise\u00f1o. Aparecen efectos imprevistos y, de repente, llegan las quejas de los clientes.\u00a0<\/span><\/p>\n

No repare algo que no est\u00e9 roto. Hemos hecho esto y pagamos un alto precio a tiempo para el lanzamiento, la estabilidad y la calidad.\u00a0<\/span><\/p>\n

 <\/p>\n

4. No entender c\u00f3mo administrar y motivar a los desarrolladores<\/b><\/h2>\n

En tecnolog\u00eda, los desarrolladores literalmente crean (y destruyen) su producto. Los tipos de personas que se sienten atra\u00eddas por el desarrollo de software son de una raza especial y debe comprender c\u00f3mo funcionan. Puede tener 20 a\u00f1os en la industria y haber dirigido a cientos de personas no relacionadas con la tecnolog\u00eda, pero es posible que todo ese conocimiento y experiencia no ayude a trabajar con los desarrolladores.\u00a0<\/span><\/p>\n

No entender sus motivaciones y c\u00f3mo operan es un gran error. Conduce a malentendidos, retrasos y dolores de cabeza. En el proceso de contrataci\u00f3n, conocer\u00e1 a muchos desarrolladores que desean un salario alto, una gran autonom\u00eda y un horario flexible. La mayor\u00eda no querr\u00e1 revisiones diarias, fechas l\u00edmite estrictas y horas extras. Toma estas consideraciones en serio.<\/span><\/p>\n

M\u00e1s ahora que nunca, el trabajo remoto es una posibilidad real para los desarrolladores, y todo el mundo est\u00e1 contratando. Lo mejor funcionar\u00e1 donde mejor se les trate. Y no desea un producto de mala calidad producido por empleados descontentos, especialmente cuando necesita una soluci\u00f3n de \u00faltimo momento antes de presentarlo a los inversores. Los desarrolladores felices har\u00e1n una excepci\u00f3n con el tiempo extra por usted; los infelices podr\u00edan simplemente desaparecer.\u00a0<\/span><\/p>\n

Puedes leer <\/span>mi art\u00edculo completo sobre c\u00f3mo trabajar con desarrolladores<\/span><\/a>.<\/span><\/p>\n

 <\/p>\n

5. No automatizar las pruebas desde el principio<\/b><\/h2>\n

Al igual que la seguridad, las pruebas de c\u00f3digo a menudo se consideran opcionales y una p\u00e9rdida de tiempo. Pero a medida que el equipo y el producto crecen, la complejidad obligar\u00e1 a realizar pruebas. No puede integrar un componente en un sistema complejo sin ninguna prueba, no sea que est\u00e9 listo para enfrentar las consecuencias del cliente cuando la producci\u00f3n se paraliza y comienza a escupir c\u00f3digos de error a los usuarios.<\/span><\/p>\n

Siempre hemos realizado pruebas unitarias, es decir, probando cada componente individual en s\u00ed mismo, antes de conectarlo al sistema completo. Sin embargo, solo comenzamos las pruebas de integraci\u00f3n automatizadas hol\u00edsticas a partir de 2019. Una de las principales razones fue la falta de recursos para volver a probar todo el sistema para cada actualizaci\u00f3n. Mientras la parte actualizada funcionara, asumimos que todo el sistema funcionar\u00eda.\u00a0<\/span><\/p>\n

La automatizaci\u00f3n de sus pruebas, especialmente para la integraci\u00f3n, hace que sea mucho m\u00e1s f\u00e1cil probar y volver a probar cada parte del sitio para cada integraci\u00f3n. Dado que generalmente se desconoce qu\u00e9 cambiar\u00e1 en todo el sistema debido al nuevo m\u00f3dulo, las pruebas de integraci\u00f3n 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.<\/span><\/p>\n

Esto conduce a una integraci\u00f3n continua, en la que se agrega c\u00f3digo nuevo constantemente, en lugar de grandes actualizaciones. Si sus pruebas no est\u00e1n automatizadas, espere hasta que est\u00e9n listos muchos cambios peque\u00f1os y luego lib\u00e9relos 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\u00f3n continua sin desperdiciar recursos de control de calidad en pruebas repetitivas.<\/span><\/p>\n

 <\/p>\n

6. Subestimar el tiempo de lanzamiento: codificaci\u00f3n (1x), control de calidad (2-3x), estabilizaci\u00f3n (2-3x)<\/b><\/h2>\n

Cuando se trata de tecnolog\u00eda, especialmente si viene de fuera del mundo tecnol\u00f3gico, la codificaci\u00f3n parece estar al frente y al centro. Quieres crear un producto tecnol\u00f3gico, lo codificas y listo, \u00bfverdad? Claro, si no lo necesita para funcionar.<\/span><\/p>\n

Pasar\u00e1 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\u00f3digo regresa a los desarrolladores para corregir errores. Luego, los QA obtienen el c\u00f3digo modificado y el proceso comienza de nuevo, generalmente tomando 2-3 veces el tiempo de desarrollo original. Una vez que est\u00e9 listo para impulsar el nuevo c\u00f3digo a producci\u00f3n, en caso de big data y caracter\u00edsticas complejas, debe dedicar de 2 a 3 veces el tiempo de desarrollo original para garantizar la estabilidad y el rendimiento de calidad.\u00a0<\/span><\/p>\n

Sumado, pas\u00f3 de un tiempo de lanzamiento de 1 semana (estimaci\u00f3n original para nuevos emprendedores tecnol\u00f3gicos) a 5-7 semanas. No estar preparado para este tipo de aumento de los plazos har\u00e1 que prometa demasiado con los clientes y presione demasiado a su equipo cuando no se cumpla el plazo.\u00a0<\/span><\/p>\n

Esto es asumiendo que ten\u00eda la documentaci\u00f3n adecuada para el c\u00f3digo en primer lugar y que los desarrolladores ya comprenden lo que necesitan UX, UI y gesti\u00f3n de productos.<\/span><\/p>\n

La construcci\u00f3n de un producto tecnol\u00f3gico de calidad requiere m\u00e1s tiempo del que la mayor\u00eda de la gente imagina.<\/span><\/p>\n

 <\/p>\n

7. Pasar por alto la diferencia de productividad entre codificadores buenos y malos<\/b><\/h2>\n

Hay mucha presi\u00f3n 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\u00e1s adelante para que lo ayuden con tareas m\u00e1s peque\u00f1as, pero el n\u00facleo de su negocio es su tecnolog\u00eda: se necesita un desarrollador bueno y experimentado. De lo contrario, dedicar\u00e1 mucho tiempo a reelaborar el c\u00f3digo antiguo para mejorar la escalabilidad, la estabilidad y la eficiencia. En el futuro, valdr\u00e1 la pena pagar m\u00e1s por un buen desarrollador con suficiente experiencia.<\/span><\/p>\n

Esto requiere ambas cualidades: experiencia <\/span>y <\/span><\/i>capacidad. Algunos desarrolladores junior son programadores incre\u00edbles, simplemente pasan por alto problemas futuros que los programadores experimentados no ignoran. Por el contrario, 10 a\u00f1os de experiencia no se traducen necesariamente en una buena capacidad de codificaci\u00f3n. Deber\u00e1 asegurarse de que ambas cualidades est\u00e9n presentes. Habiendo aprendido de esto, ahora dedicamos mucho m\u00e1s tiempo durante el proceso de contrataci\u00f3n para asegurarnos de que incorporamos al candidato adecuado. Luego, durante el per\u00edodo de prueba, evaluamos su trabajo a fondo y las se\u00f1ales de alerta se tratan de inmediato.<\/span><\/p>\n

Con la cantidad de trabajo adicional requerido en depuraci\u00f3n, recodificaci\u00f3n, control de calidad y redise\u00f1o debido a un c\u00f3digo incorrecto, la diferencia de productividad entre un desarrollador bueno y uno malo o inexperto podr\u00eda ser 1000x.<\/span><\/p>\n

 <\/p>\n

8. La tentaci\u00f3n de construir todas las 'experiencias' internamente<\/b><\/h2>\n

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\u00e1s incluso tenga un par de clientes que usen su API. Deber\u00eda ser muy f\u00e1cil entregar esos datos a la interfaz de un consumidor, \u00bfverdad?<\/span><\/p>\n

Servir los datos, claro, es f\u00e1cil. \u00bfConstruyendo realmente la interfaz? Esa es una historia diferente. La interfaz es engorrosa. Primero est\u00e1n los gr\u00e1ficos: necesitar\u00e1 un dise\u00f1ador para hacer esos gr\u00e1ficos. Las API son solo puntos finales, todo texto y c\u00f3digo. Ah, y los gr\u00e1ficos deber\u00e1n escalar para mostrarse correctamente en diferentes resoluciones de pantalla y navegadores. \u00bfY qui\u00e9n no quiere una aplicaci\u00f3n m\u00f3vil? Eso viene con su propia serie de problemas, como tipos de inicio de sesi\u00f3n forzado (ver 2 arriba), m\u00faltiples sistemas operativos y hardware variable.<\/span><\/p>\n

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

 <\/p>\n

9. No comprender las diferencias de roles en un contexto tecnol\u00f3gico<\/b><\/h2>\n

Otro concepto err\u00f3neo de quienes no tienen experiencia en tecnolog\u00eda es que todos los roles tecnol\u00f3gicos son m\u00e1s 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\u00fa (y tal vez un par m\u00e1s), todos los roles se mezclan. Pero a medida que la empresa crece, la diferenciaci\u00f3n y la especializaci\u00f3n son necesarias y confundirlas puede ser un costoso error en tiempo y calidad.\u00a0<\/span><\/p>\n

El primer caso en cuesti\u00f3n: el dise\u00f1o. Hay dise\u00f1adores para la interfaz de usuario (UI) y hay dise\u00f1adores 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\u00e1s que ver con la estructura: \u00bfc\u00f3mo fluyen los usuarios a trav\u00e9s del sistema? \u00bfQu\u00e9 sucede si ocurre un error aqu\u00ed, el usuario llega a la Pantalla A o a la Pantalla B? \u00bfTiene sentido este dise\u00f1o en el contexto de la procedencia del usuario o simplemente crea confusi\u00f3n?<\/span><\/p>\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\u00farese de que valga la pena el dinero para los clientes, o se ir\u00e1n a otra parte.<\/span><\/p>\n

Tambi\u00e9n confund\u00ed a los desarrolladores de software con el personal de DevOps, lo que gener\u00f3 m\u00e1s presi\u00f3n de trabajo para nuestros desarrolladores. Los sistemas tecnol\u00f3gicos, especialmente aquellos tan complejos como el nuestro, no son \u00fanicamente c\u00f3digo (como se menciona en Sin 6). Big Data tambi\u00e9n empuja el l\u00edmite de lo que pueden hacer los sistemas, por lo que la estabilidad y la accesibilidad se convierten en la m\u00e1xima 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\u00e1s para poder agregar m\u00e1s servicios de IA.<\/span><\/p>\n

Sus desarrolladores, tanto backend como frontend, se centran en el c\u00f3digo y el algoritmo. Necesita DevOps para garantizar que la potencia inform\u00e1tica est\u00e9 disponible para ejecutar ese c\u00f3digo, y debe ser lo suficientemente estable para mantener contentos a los clientes. No mezcle DevOps y desarrollo de software.<\/span><\/p>\n

 <\/p>\n

9a. Pecados de otro<\/strong><\/h2>\n

Recibimos algunas advertencias interesantes de Jelle van Mourik, una lectora de Facebook. Los presentaremos aqu\u00ed en este encabezado (lo hemos parafraseado un poco y, por supuesto, agregamos nuestro propio sabor):<\/span><\/p>\n