Qué es y cómo pagar la deuda técnica de una empresa

Deuda técnica mala = deuda que hacia futuro pueden aniquilar el negocio.

Preguntar al equipo de ingeniería: "Esto que quieren cambiar ¿Afecta a los usuarios? - Si o No?
Si no afecta los usuarios o si no hay cambio positivo, muy probablemente los ingenieros están pagando deuda técnica.
Los equipos de ingeniería aman optimizar y en ocasiones lo hacen probando cosas nuevas. Esto significa, que muchas veces van a tratar de venderte una mejor que realmente no afecta a los usuarios para nada; pero utilizan adjetivos que no significan nada: robusto, veloz, ágil.

Hacer las preguntas clave:
Si nosotros no arreglamos esto, ¿en cuánto se va a volver un problema?
Es importante mantener tracking de la deuda técnica, mantener un registro de dónde ocurre?.

• La rápida iteración es mejor que tener un producto perfecto (mejora continua = constante iteración).

• Es mejor que los usuarios me den feedback rápidamente, incluso cuando algo está roto, es mejor a tener el **producto ideal **que nadie ve nunca y que la luz nunca está ahí.

• El código se hace para mover el negocio.

El mejor ejemplo de deuda técnica está en los vehículos… jejeje…

• Hay que cambiar esta pieza- dice el mecanico.
• ¿Qué pasaría si no lo hago?- pregunta el cliente.
• En 2 semanas puede trancarse el rodamiento y tendrías que para el carro por un mes para reparar los daños.
• Ah oks, nos vemos el viernes de la semana que viene entonces y te lo dejo el fin de semana.

Deuda tecnica de Platzi:

El uso real es mejor que ser perfeccionista, pero no significa olvidar tu deuda técnica, ya qué eventualmente puede convertirse en un stopper total.

La deuda técnica es inevitable y siempre estará ahí, la diferencia está en como la afrontas.

Hoy mi CIO sacó el concepto de que no estamos midiendo la deuda técnica y me lucí porque había llevado el curso 😄

Para complementar el tema de la deuda técnica y cuándo hay que resolverla dejo una lectura sobre Cost of Delay que ayuda a tomar decisiones.

Platzi es el ejemplo más claro de que hacer una aplicación es difícil. Aun así cuando ellos mismos enseñan a hacerla.

La deuda técnica en pocas palabras es causada por la postergación de deberes , se debe de mitigar mediante la rápida iteración

Ejemplo del perfil vendedor y/o arrogante: se vuelven peligrosos cuando les apasiona más la tecnología como tal que la solución (quieren volver a hacer todo desde cero, quieren probar las últimas tecnologías aunque no sean las correctas. Sin un análisis profundo.

✨Mantener tracking o seguimiento de la deuda técnica nos permite evitar errores de la aplicación, esto permite minimizar los riesgos.

Hoy me eh dado cuenta que tengo una deuda técnica y que estamos aprovechando la pandemia para realizar los cambios necesarios

Hice una reflexión y resumen de este concepto en un post de LinkedIn, bienvenidos a conectar:

https://www.linkedin.com/posts/ivanesro_deudataezcnica-startup-startupscol-activity-6754051583014776832-Bn8q

Wooou, interesante lo de la deuda técnica, en el sitio donde trabajaba programé muchas macros en Excel, a medida que se requerian nuevas cosas luchaba para cumplir con los nuevos requerimientos y ajustarlas a lo que ya había creado, me acuerdo que una actualización quedó pendiente. El código de la macro requeriría una actualización después de 9999 registros, cuando ocurra eso no lo sé con exactitud, ahí está la deuda técnica.

Antes de esta clase organice mis cables, me sentí como cuando google te lanza publicidad de un producto después de hablar del mismo unos minutos antes.

Muchas empresas, tristemente están pagando en este momento la deuda técnica de haber desarrollado sobre flash, por no haberse anticipado al cambio tecnológico. 🤦🏻‍♀️

Deuda Técnica: Cuando tratamos de avanzar muy rápido sin tener en mente los sistemas, estructuras y lógica del negocio. Que nos permite adelantarnos a los problemas que vienen a futuro, para poder construir algo mucho más escalable …

La deuda tecnica es inevitable, lo importante es hacersen las preguntas claves:
Si nosotros no arreglamos esto, ¿en cuánto se va a volver un problema?
tambien, es importante mantener tracking de la deuda técnica, mantener un registro de dónde ocurre.

me pasa ese problema con la aplicación de platzi el detalle es que a mi me aparece en portugués y los cursos en portugués

Si tienes un aplicativo que estar por lanzarlo pero ves que hay ciertas cosas que no te cuadrar o no te terminan de convencer, mil veces es mejor lanzarlo de una vez que esperar a resolver esas pequeñas cositas.

El feedback que tus usuarios te pueden dar en este tiempo puede ser valioso y permitirte ahorrar un montón de tiempo en el futuro.

Es como Facebook, que siempre va lanzando pequeños parches sin hacer grandes cambios para ver como la gente interactúa con esos cambios.

“Uso real > Perfección” esto también lo asimilo con el tema del inglés, muchos estudiantes esperan ese momento en el que “tengan en su mente toda la teoría y gramática” para poder comenzar a hablar el idioma, pero desde determinado tiempo es fudamental comenzar a usarlo si quieres avanzar.

El nudo del nudo, un desastre he visto en varias organizaciones en relación al cableado.

Jajaja, esto es hilarante y triste a la vez, en especial lo de “Cámbieme el botoncito ahí”.

Notas

• No toda deuda técnica es mala
• Debemos mantener tracking de la deuda técnica. ¿Si nosotros no arreglamos esto, en cuánto se va a volver un problema?
• Rápida iteración > Producto perfecto, pero hay que manejar un balance y entender las implicaciones de lanzar el producto como está en ese momento.
• El uso real es más importante que tener un producto/servicio perfecto.

La deuda técnica es causada por la postergación de deberes, si se llega a postergar mucho llega a ser como una bola de nieve que con el tiempo va creciendo cada vez más y puede causar un problema, es cuando queremos avanzar muy rápido y cuando hay un problema no le damos su tiempo para solucionarlo y en cambio seguimos avanzando en vez de reparar el error.
La deuda técnica es inevitable, en algún momento llegara a pasar pero no necesariamente tiene que ser algo malo, normalmente es la razón por que un proyecto se puede atrasar, la deuda técnica que llega a ser mala es aquella que en un futuro puede aniquilar el negocio. En el caso de software es importante tener una buena comunicación con el equipo de ingeniería, por ejemplo, preguntarles “si nosotros no arreglamos esto, ¿en cuánto se va a volver un problema?”. Es importante mantener tracking de la deuda técnica, mantener un registro de dónde ocurre, debes tener en mente que hay un deadline para la deuda técnica.

No conocía este concepto de deuda técnica. Reconozco que cuando veo un data center lleno de cables, provoca tumbarlo todo y empezar de cero. Si es rescatable y existe documentación puede que no haya que hacer muchos cambios y tratar de organizarlo mejor.
.
Pero en definitiva si hay que tumbarlo hay que hacerlo. Me ha pasado con pequeños racks y gabinetes donde la gente nunca se dió una vuelta para hacerle un cariño, más bien todo lo contrario, montarle más y más cables.

Qué es y cómo pagar la deuda técnica de una empresa

.
Es un término que se utiliza en desarrollo de software para describir el costo adicional que se incurre cuando se elige la solución más rápida en lugar de la más efectiva. Se refiere a las consecuencias por negligencias, errores o deficiencias deliberadas o involuntarias en relación con el código. Las correcciones y medidas de mantenimiento posteriores frenan la productividad y generan costos elevados adicionales.
.
La deuda técnica es la razón número uno por la cual algo se atrasa. Es como si no siguieran las reglas de típicas de ingeniería, lo que causa que nos demoremos más de lo debido en hacer algo muy sencillo.
.
No toda la deuda técnica es mala. Las deudas técnicas malas son las que, hacia el futuro, pueden afectar mucho a tu negocio, de lo contrario, lo que se está haciendo es pagar deuda técnica. Por eso debes tener una buena comunicación con el equipo técnico para evitar que esa deuda técnica siga creciendo hasta el punto de detener tu negocio.
.
El uso real de tu aplicación es más importante que tener una aplicación perfecta.

Lo importante es mantener tracking o seguimiento de la deuda técnica para evitar que llegue de sorpresa.

Esto es muy importante:
“Las empresas no hacen código, las empresas están ahí para mover un modelo de negocio”

“El software es un jardin, no un edificio”
Voy a enmarcar esa frase.

CyberPunk 2077 un claro ejemplo. Freddy siempre viendo el futuro.

Rápida iteración > Producto Perfecto

El software es un jardín no un edificio. La deuda técnica es avanzar tan rápido y no tener una base bien construida, que no esta dispuesta a cambios, y cada cambio es complicado por la cantidad de deuda técnica acumulada.

Eso del archivo de Strings me hizo acordar de una actualización que hizo una droguera (farmacia) de cadena en Colombia con la app de E-commerce. La versión anterior era aun mejor que la actual. y sucedía que muchos de los campos estaban en portugués y el resto en español.

Por lo general siempre se tiene deuda tècnica, pero lo que se debe hacer cuando se identifica es saber cuanto tiepo se volverà un problema y que tan grande es el problem

justo antes de ver este video estaba viendo como solucionar el tema de tantos cables. Tengo pensado comprarme un cargador con dos salidas usb a / usb c y un cable usb thunderbolt. Chau cables

Esas interfaces de pantalla Negra y texto verde, también estaban o estan desarrolladas con un lenguaje llamado AS400.

TECHNICAL DEBT is what it sounds like: a debt that businesses eventually have to pay with time, money, and resources, typically for choosing speed over quality.

La rápida iteración es mejor que tener un producto perfecto (mejora continua = constante iteración).

Esto de el producto ideal si que costó muchisimo, la luz nunca se ha podido ver. Ha sido toda una cruz. Por fin siento que Freddy me da la razón para poder hablar con el equipo con fundamento y claridad.

Me encantó el concepto de deuda ténica, es nuevo para mí. Entiendo que hay que aceptarla y tratar de mantenerla controlada.

freddy muy bien explicado, sabia que existía la deuda técnica, pero no la entendía, me quedo muy claro. el ejemplo de deuda técnica que hace el compañero haciendo referencia a los vehículos es muy explicita, muy bien!!!

esa deuda tecnica aplica a la administración de empresas grandes tambien, me ha pasado que hay mejoras que se puden hacer en ciertos procesos adminsitrativos pero se posponen porque el mood de los directivos en esa epoca esta enfocado o a recortes, o a venta o a financiamiento y aunque se tenga la mejora a la mano, se conozca el deficit o mejora simplemente no es el momento y se pospone…

aquellas cosas de ir al cine en la vida pasada, por eso es que amo a Platzi

Este tema se entiende perfecto con los parches de los videojuegos.

la frase que pronuncio “El codigo esta para mover un modelo de negocio” resume mucho de lo que mueve las decisiones de una compañía.

y la otra parte acerca de los videojuegos donde se ven bugs en los lanzamientos, contrasta con otros que se toman casi una eternidad en salir al publico, ya que en muchos casos la obsesión por la perfección del desarrollador que se enamora de su producto trae consecuencias negativas.

He visto varias deudas técnicas en la aplicación de Platzi , una de ellas es que la ventana donde están algunos un comentarios escritos, aparece recortado y no se puede continuar leyendo.

Sin duda debemos profundizar más en el tema ya que a veces es algo que no entiende el usuario final.
Siendo diferentes diariamente nos volveremos indispensables

Siempre es importante evaluar qué partes del producto son indispensables para los usuarios, así se puede tener un buen parámetro para evaluar cómo se distribuye el tiempo entre desarrollo y deuda técnica.

El reto más fuerte que veo es tener buen criterio para priorizar esto, actualmente hay marcos de trabajo y metodologías para hacer esto con mayor eficacia. Un ejemplo es el RICE Scoring Model, que viene de las palabras; Reach, Impact, Confidence & Effort.

Les dejo este enlace por si quieren saber más al respecto..

No termino de agradecer la cantidad de informacion actualizada que suministran en cada curso, me extraña si y es la primera vez que lo comento gracias a lo exposicion en esta leccion es el ultimo enlace pautado para preentar el examen final, pueden pasar 3 cosas:

• Se queda en un ciclo infinito mostrando la ultima clase.
• Enlace presentando al astronauta de Platzi.
• La presentacion del examen.
  Curiosidad aparte tiene meses este bug, ultimamente ya no sale el astronauta pero se queda en el ciclo infinito mostrando la ultima clase y una que otra vez aparece la pantalla para entrar ha presentar.
  Espero con fe puedan solucionar esto equipo.

Según la respuesta de un nuevo programador ante la deuda técnica podemos descubrir si es arrogante, vendedor, creador o mago…

La deuda técnica es inevitable y siempre la tendrás en el desarrollo de software.

La deuda técnica es la razón #1 por la que algo se atrasa.

No toda deuda técnica es mala.

Ni me había dado cuenta, la mayoría de los usuarios no se percatarían de esto

No toda deuda técnica es mala.

Deuda técnica mala = Afecta usuario.
Rápida iteración > producto perfecto

Es interesante esto de la deuda tecnica. Si que tiene sus riesgos en querer cambiar las partes de la funcionalidad del programa. Aunque eso ocurre diariamente en una empresa. Asi que eso seria lo normal. Espero que esto sea una buena solucion para nuestro programa. Como dicen, es mejor cumplir las deudas o vamos a tener problemas al momento de ejecutarlas. Si es que hay alguna pandemia como el coronavirus.

Pagar la deuda técnica es actualizar los sistemas de acuerdo a los cambios en el tiempo, la deuda técnica consiste en el costo de actualización que se desarrollaría en el tiempo de acuerdo a las acciones de actualización. De no actualizar se atrasan los sistemas.

free fire

Qué es y cómo pagar la deuda técnica de una empresa

La deuda técnica mala es la deuda que hacia el futuro pueden llegar a aniquilar el negocio

_Si afecta a los usuarios/lógica del negocio (las decisiones de cambio de ingeniería) o no hay cambios positivos entonces pagas deuda técnica _

A los equipos de ingeniería le gustan optimizar y a veces es un poco de “humo”; esto no significa que esté mal pero hay que entender los plazos para iterar esa optimización si es que no ayuda al usuario a corto plazo

La razón #1 por la que algo se atrasa: no entender la lógica del negocio y no tenerla bien definida.

En pocas palabras, la deuda técnica es el costo del trabajo adicional causado por la elección de la solución más rápida en lugar de la más efectiva. Si bien, en ocasiones, la deuda técnica vale la pena, es importante que tu equipo comprenda las ventajas y las desventajas de las decisiones apresuradas y cómo gestionar el retrabajo de una manera eficiente.

Muy interesante tema! Sin duda la deuda técnica se correlaciona directamente con el crear código y el desarrollo la tecnología. Es mejor la rápida interación y el uso real que da el usuario, en lugar de buscar la perfección para nuestros proyectos y aplicaciones sin el feedback de nuestro cliente/usuario.

The Amazing Grace o Grace Hopper fue la creadora de COBOL en los 60’s el primer lenguaje de programación universal que pudiera ser usado en cualquier computador. Un gran merito para esta gran mujer!

Buenos días, hace 1 año asumí el liderazgo de un equipo de TI en Perú, una empresa que tiene 70 años en el mercado y que tiene toda su Core de negocio en una plataforma de escritorio (Visual Basic 6.0 con SQL 2000), esto sería una deuda técnica ya que por muchos años no han tenido la iniciativa de cambiar la arquitectura de Software, esto se da porque en la actualidad estos sistemas aún siguen soportante las operaciones del negocio, y con ello están contentos.
En mi caso, si el cambio debería ser el 100% de la tecnología y cambiarlo por algo mas actualizado y que soporte a los nuevos procesos que se desean cambiar.

¿Qué opinión podrían brindarme?

Una manera de gestionar la deuda técnica es usar scrum, en conjunto con metodologías de desing thiking y canvas, iterar rápido bajo parámetros de control,

En realidad pensé que se refería a un termino financiero jajaja

La rápida iteración es la clave

Si tu deuda técnica te impide desarrollar tu producto o servicio es hora de parar y pagarla, en ocasiones pagarla puede significar reescribir por completo o desde cero tu aplicación o proyecto.

Me llevo esto tu jardín necesita constante iteración.

Muchas veces los que el equipo técnico considera perfección, puede ser distinto para el usuario final en el uso real. Por eso es mejor tener la exposición a los usuarios que son los que sabrán donde necesitan perfección con el uso de la app.

Muy buena clase !

Interesante planteamiento, no lo tenía en cuenta.
Gracias por brindarme esta nueva perspectiva

El uso real de tu producto o servicio digital lleva a la perfeccion

Gracias

Strings: Cadenas de texto, son útiles para almacenar datos que se pueden representar en forma de texto.

Es cuando hay que resolver el problema y no solo seguir escondiendo el mugre debajo del tapete

El concepto de jardin , me cambio por completo mi concepcion de ese campo. Brutal¡¡¡

El uso real de tu aplicación es mucho más importante que tener una aplicación perfecta.

Esto es muy real.
incluso cuando haces hojas en excel.
Incluso cuando colocas informacion en columnas.

No sabia que habia nombre para esto.

considero que siempre que halla un análisis profundo la deuda técnica se podrá mitigar muchísimo.

PMV, incluso sin ser startup.
PMV es la verdadera velocidad

Es importante recordar que la rápida iteración es mejor que tener un producto perfecto.

El uso real de tu aplicación es mucho mas importante que tener una aplicación perfecta.

La deuda técnica es inevitable cuando estas creando software.

Deuda técnica en una imagén.

Rápida iteración es mejor que un producto "perfecto".

Ahora imagínense las deudas técnicas de los gobiernos latinoamericanos.

el balance de lo bueno y malo lo debes tomar tu!

Muy buena clase!! a evaluar la deuda técnica

Gran enseñanza. Muchas gracias. Me invita a ser más tolerante por supuesto.
“La gente buena primero lee y hace un diagnóstico antes de quemar lo que ya hay”

El COBOL es un sistema antiguo

tremendos todos estos conceptos!

Interesante el concepto de deuda técnica.