<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Productividad on CTOMultiplier</title><link>https://ctomultiplier.com/es/tags/productividad/</link><description>Recent content in Productividad on CTOMultiplier</description><generator>Hugo</generator><language>es</language><lastBuildDate>Mon, 23 Mar 2026 17:59:59 +0100</lastBuildDate><atom:link href="https://ctomultiplier.com/es/tags/productividad/feed.xml" rel="self" type="application/rss+xml"/><item><title>IA en desarrollo de software: ¿Hype o Game Changer?</title><link>https://ctomultiplier.com/es/ia-en-desarrollo-de-software-hype-o-game-changer/</link><pubDate>Thu, 13 Mar 2025 10:59:03 +0000</pubDate><guid>https://ctomultiplier.com/es/ia-en-desarrollo-de-software-hype-o-game-changer/</guid><description>&lt;p&gt;Estamos en 2028, han pasado 6 años desde el boom de la IA generativa con la aparición de ChatGPT y de lo que fue una ola de adopción de IA generativa para desarrollar software. Sin embargo después del &lt;em&gt;hype&lt;/em&gt; que se produjo en los años 2023 y 2024, paulatinamente se fue reduciendo el uso de los copilots y asistentes de código basados en IA. Se observó que en el fondo no ofrecían mucho valor, ya que la mayoría del código que producían era incorrecto y de calidad mediocre, y que los desarrolladores pasaban más tiempo corrigiendo los errores introducidos por la IA, que el que se ahorraban. Esto provocó que las iniciativas de adopción fueran perdiendo fuerza hasta desaparecer del debate tecnológico, recordando el efímero destino del metaverso.&lt;/p&gt;</description></item><item><title>Systems Thinking: Pensando en sistemas</title><link>https://ctomultiplier.com/es/systems-thinking-pensando-en-sistemas/</link><pubDate>Mon, 13 Nov 2023 18:11:56 +0000</pubDate><guid>https://ctomultiplier.com/es/systems-thinking-pensando-en-sistemas/</guid><description>&lt;p&gt;En ocasiones trabajo con clientes que tienen un problema importante para entregar en los plazos y calidad acordadas. Cuando empiezo a investigar las causas me encuentro que cuando hablo con el equipo de producto dicen que el problema es que ingeniería no es suficientemente rápido y/o producen demasiados defectos, y cuando hablo con ingeniería me dicen que les llegan especificaciones incompletas desde producto, lo cual hace que tengan que emplear más tiempo en desarrollar, y que a veces tengan que deshacer cambios porque no eran lo que el cliente quería. Es común que estás organizaciones se vean como un conjunto de silos, y crean que la solución pasa por “arreglar” uno de esos silos (p.ej: ingeniería). Pero esta es una visión reduccionista del problema, y que pocas veces ayuda a solucionarlo. Para tratar el problema de raíz se necesita re-pensar como entendemos la organización, y es aquí donde el Systems thinking nos puede ayudar. Como decía Einstein: “No podemos resolver problemas pensand o de la misma manera que cuando los creamos”.&lt;/p&gt;</description></item><item><title>El impacto de la cultura en el rendimiento</title><link>https://ctomultiplier.com/es/el-impacto-de-la-cultura-en-el-rendimiento/</link><pubDate>Mon, 13 Nov 2023 17:44:00 +0000</pubDate><guid>https://ctomultiplier.com/es/el-impacto-de-la-cultura-en-el-rendimiento/</guid><description>&lt;p&gt;Esta semana quiero hablar de un podcast de techlead journal (enlace al final), en el que entrevistan al autor del libro Wrong fit, right fit. En el podcast, el autor (André Martin) habla de la cultura de las empresas como factor determinante para el desempeño y la felicidad de un empleado. Cita &lt;strong&gt;un reporte de Gallup que dice que se pierden 8.8 billones de dólares (trillones americanos) debido a la falta de engagement (o compromiso) de los empleados con sus empresas&lt;/strong&gt;. André equipará trabajar en una empresa con la que no tienes un encaje cultural (o cultural fit), a escribir con tu mano izquierda (o derecha si eres zurdo). Lo puedes hacer, y vas a producir..pero la calidad va a ser mucho peor y además te sentirás poco realizado.&lt;/p&gt;</description></item><item><title>Cómo llevar a cabo reuniones efectivas</title><link>https://ctomultiplier.com/es/como-llevar-a-cabo-reuniones-efectivas/</link><pubDate>Thu, 26 Oct 2023 10:53:18 +0000</pubDate><guid>https://ctomultiplier.com/es/como-llevar-a-cabo-reuniones-efectivas/</guid><description>&lt;p&gt;Muchas veces se habla de si los meetings o reuniones tienen valor, y si no habría que suprimirlas completamente porque son una pérdida de tiempo. Personalmente me parece que esta visión es algo extrema, pero entiendo que responde a que en multitud de ocasiones la forma en que hacemos las reuniones es efectivamente una pérdida de tiempo y dinero, y una fuente de frustración y desmotivación. A lo largo de mi carrera he trabajado con unas cuantas empresas, y en todas he participado en meetings improductivos, y esto parece ser una constante hables con quien hables. Es difícil encontrar a alguien que cuando le preguntes acerca de cómo hacen los meetings en su empresa, no se queje.&lt;/p&gt;</description></item><item><title>¿Sabes lo que es DPE?</title><link>https://ctomultiplier.com/es/sabes-lo-que-es-dpe/</link><pubDate>Wed, 27 Sep 2023 07:23:39 +0000</pubDate><guid>https://ctomultiplier.com/es/sabes-lo-que-es-dpe/</guid><description>&lt;p&gt;DPE se refiere a Developer Productivity Engineering y es el nombre de una nueva disciplina que nace con el objetivo en mejorar la productividad de los desarrolladores a través de automatización, observabilidad y mejora de las herramientas.&lt;/p&gt;
&lt;p&gt;El trabajo de un desarrollador cuando está programando tiene tres fases: code -&amp;gt; build -&amp;gt; test, el desarrollador repite esta secuencia decenas o incluso centenas de veces al día. Y en muchos casos las fases de build y test pueden llevar del orden de minutos. Por ejemplo: si el build de una aplicación tarda 5 minutos y el desarrollador hace 10 builds al día, eso son 50 minutos que el desarrollador tiene que estar esperando por día. Y del mismo modo, la fase de testing puede aumentar ese tiempo de espera del desarrollador. Si esto lo multiplicamos por el número de desarrolladores en una compañía, el coste es significativo.&lt;/p&gt;</description></item><item><title>Guía para hacer Code Reviews en tu equipo</title><link>https://ctomultiplier.com/es/guia-para-hacer-code-reviews-en-tu-equipo/</link><pubDate>Tue, 25 Jul 2023 15:42:32 +0000</pubDate><guid>https://ctomultiplier.com/es/guia-para-hacer-code-reviews-en-tu-equipo/</guid><description>&lt;p&gt;Las revisiones de código son una práctica que se ha extendido mucho en los últimos años, que consiste en que uno o varios desarrolladores revisen el nuevo código implementado por otro compañero, con el objetivo de detectar problemas de calidad del código, bugs, vulnerabilidades, malas prácticas, etc.. . Esto permite acortar los feedback loops, lo cual como sabemos es muy beneficioso ya que cuanto más tarde se detecte un problema, mayor será el coste de repararlo y el posible impacto en negocio.&lt;/p&gt;</description></item><item><title>¿la productividad de tu Scrum es baja? Tu problema puede ser el WIP</title><link>https://ctomultiplier.com/es/productividad-del-scrum-baja-tu-problema-puede-ser-el-wip/</link><pubDate>Thu, 20 Jul 2023 09:18:13 +0000</pubDate><guid>https://ctomultiplier.com/es/productividad-del-scrum-baja-tu-problema-puede-ser-el-wip/</guid><description>&lt;p&gt;Está probado que cuanto más trabajo en progreso tenga una persona o un equipo, mayor es el tiempo que se emplea en cerrar las tareas. Por un lado, si estamos haciendo varias tareas a la vez y las entregamos a la vez, el tiempo de entrega será la suma del tiempo de hacer las dos tareas. Sin embargo, si trabajamos en las tareas en orden secuencial, la primera tarea será entregada antes, y el tiempo medio de entrega también será más bajo.&lt;/p&gt;</description></item></channel></rss>