00:00:04 Introducción a la Frankensteinización de software.
00:00:35 Impacto de la Frankensteinización de software en el software B2B.
00:01:31 Cómo las demandas de los clientes influyen en la Frankensteinización de software.
00:02:32 ‘Cicatrices’ en el software y sus implicaciones.
00:05:33 Costos de mantenimiento de la Frankensteinización de software.
00:08:00 Desafíos y costos de nuevas características de software.
00:08:57 Características sin complejidad: perspectivas B2C.
00:10:36 Problemas con el enfoque B2B en soluciones de software.
00:13:18 La experiencia de Lokad: lo correcto vs lo rápido y la deuda tecnológica.
00:15:14 Envision: la solución de Lokad a la complejidad.
00:16:30 Programación específica de dominio: evitando limitaciones y conflictos.
00:17:43 Abordando el bloatware de software en supply chain.
00:18:01 Estrategias para simplificar el software complejo.
00:20:54 Gestionar la ‘masa tecnológica’ en sistemas de software.
00:22:00 Sinergia entre TI, supply chain y marketing en los cambios del sistema.
00:22:43 Problemas con una personalización excesiva del software.
00:23:48 Comprobando la integridad del proveedor de software a través de la personalización.
00:24:00 Ganar influencia sobre la estrategia de desarrollo del producto.
00:26:08 Elegir un software ágil y enfocado para evitar la personalización.
Resumen
En Lokad TV, Joannes Vermorel introduce el concepto de Frankensteinización de software, refiriéndose a la manera en que el software B2B evoluciona mediante modificaciones al azar que no se alinean con su diseño original. Se presentan los ERPs como ejemplo, enfatizando el dilema entre mantener la arquitectura del software y satisfacer nuevas demandas. Vermorel advierte contra decisiones apresuradas, que según él suelen resultar en cicatrices en el software y un incremento de los costos de mantenimiento. A pesar de reconocer la complejidad inevitable en la gestión del software, Vermorel subraya la importancia de aprender de los modelos B2C para controlar las interacciones entre características. La respuesta de Lokad a este problema es “Envision”, un lenguaje de programación específico de dominio que separa los problemas de infraestructura y los problemas específicos de dominio.
Resumen Ampliado
En el último episodio de Lokad TV, la conversación gira en torno al concepto de Frankensteinización de software, un término introducido por Joannes Vermorel, el fundador de Lokad. Utiliza este término para describir la transformación del software B2B a lo largo del tiempo, particularmente el software de supply chain de larga vida, a medida que evoluciona mediante negociaciones continuas y grandes acuerdos entre los proveedores de software y sus clientes.
Vermorel explica que la Frankensteinización de software ocurre cuando se realizan ajustes en el software en respuesta a las demandas de los clientes. Estos cambios a menudo son inconsistentes con la arquitectura, filosofía y diseño original del software. Como resultado, el software acumula estas alteraciones, o “cicatrices”, con el tiempo, convirtiéndolo en lo que Vermorel describe como un “monstruo Frankenstein”: un sistema de software compuesto y extrañamente evolucionado.
Además, señala que esta situación es especialmente pronunciada en el software de supply chain, pero también es común en muchos tipos de software B2B. Sin embargo, aclara que el término “cicatriz” no debe interpretarse como algo inherentemente negativo. Estas modificaciones pueden mejorar el software al añadir nuevas características, mejorando así su funcionalidad.
Vermorel ofrece un ejemplo del software de Planificación de Recursos Empresariales (ERP), que asume que la estacionalidad puede capturarse utilizando perfiles fijos de 52 semanas. Este diseño funciona bien hasta que surge una demanda que no se ajusta a este marco, como modelar el Año Nuevo Chino, el Ramadán o la Pascua, que siguen calendarios diferentes y cambian de fecha anualmente.
En tales casos, el proveedor de software se enfrenta a un trade-off. Pueden atender la nueva demanda integrando una solución “hackish”, que no encaja de manera perfecta en la arquitectura del software pero proporciona la característica requerida. Sin embargo, este enfoque a menudo conduce a más “cicatrices”, contribuyendo a la Frankensteinización del software.
Enfatizando el ritmo acelerado de las negociaciones con los clientes clave en el negocio del software, Vermorel advierte que la urgencia puede conducir inadvertidamente a “cicatrices de software”. Define esto como un proceso en el que las características implementadas apresuradamente aumentan la complejidad y el costo de mantenimiento del software con el tiempo.
Explicando las complejidades de la arquitectura de software, Vermorel señala que cada línea de código o característica requiere mantenimiento. A medida que se añaden más características, las interconexiones se vuelven más complejas, llevando a un “problema de complejidad cuadrática”. Esencialmente, las interacciones potenciales aumentan exponencialmente a medida que crece el número de partes, causando una variedad de problemas potenciales como bugs, caídas y amenazas de seguridad.
Vermorel enfatiza la importancia de una arquitectura de software meticulosa para controlar el número de interacciones entre las características. Señala que el objetivo debe ser solo duplicar la cantidad de mantenimiento requerido si se duplican las características, en lugar de cuadruplicar o más, que es lo que a menudo sucede cuando el desarrollo es apresurado.
Cuando se le pregunta cómo las empresas de software pueden introducir nuevas características sin añadir una complejidad excesiva, Vermorel sugiere aprender de compañías de software B2C como Google y Netflix. Se toman el tiempo para entender los problemas específicos que intentan resolver y diseñan soluciones que abordan una amplia categoría de problemas similares. Contrasta este enfoque con el mundo B2B, donde los clientes a menudo vienen no solo con problemas, sino también con sus propias soluciones propuestas.
Respecto a cómo Lokad maneja estos problemas, Vermorel revela su lucha inicial por equilibrar hacer las cosas correctamente y acomodar rápidamente las solicitudes de los clientes. Notaron un aumento de la deuda tecnológica en los primeros años, lo cual Vermorel reconoce como perjudicial. Se dieron cuenta de que, aunque añadir características para complacer a clientes individuales podría parecer beneficioso a corto plazo, conduce a un producto complejo, inconsistente y difícil de gestionar a largo plazo.
En reacción a esta realización, Lokad ideó una solución única: un lenguaje de programación específico de dominio llamado “Envision”. El objetivo de Envision es separar los problemas de infraestructura de los problemas específicos de dominio, permitiendo a Lokad gestionar la adición y el mantenimiento de nuevas características de manera más efectiva sin añadir complejidad excesiva.
Vermorel continúa elaborando sobre cómo los productos de software, especialmente en la industria de supply chain, frecuentemente enfrentan un problema de hinchamiento debido a una personalización extensa para cada cliente. Si bien la personalización tiene como objetivo ofrecer soluciones hechas a la medida, a menudo resulta en un sistema complejo y difícil de manejar que requiere un esfuerzo significativo para mantener y actualizar. Para evitar esto, Vermorel comparte cómo Lokad utiliza un script específico de dominio, Envision, para crear soluciones altamente personalizadas, pero manejables, para sus clientes.
Abordando el tema de la complejidad del software, Chandler pregunta qué pueden hacer las empresas de software para prevenir el bloatware. Vermorel responde que el escenario depende de si una empresa tiene acceso a su software. Si no, la empresa necesita lidiar con la complejidad del software adquirido. Sin embargo, si el acceso está disponible, el software puede simplificarse identificando y eliminando elementos no utilizados, reduciendo en gran medida la complejidad.
Cambiando el enfoque hacia las responsabilidades del personal de TI y los supply chain executives, Vermorel observa que, aunque el personal de TI suele tener el conocimiento técnico, a menudo carecen de comprensión del valor comercial de ciertas características. Esto conduce a una desconexión entre las características necesarias e innecesarias. Por lo tanto, los responsables de la toma de decisiones empresariales deben colaborar estrechamente con TI para impulsar la priorización y la simplificación del sistema.
Vermorel ofrece consejos para los ejecutivos de supply chain que buscan invertir en nuevo software. Advierte contra exigir una personalización excesiva, ya que puede acarrear más problemas. En su lugar, los ejecutivos deben mantener un contacto regular con los gerentes de producto o CTOs del proveedor para comunicar sus necesidades directamente. En lugar de forzar características específicas en un contrato, el objetivo debe ser presentar los problemas a quienes son capaces de diseñar soluciones.
Finalmente, Vermorel aconseja a las empresas elegir un software que se destaque en una sola cosa, en lugar de optar por soluciones integrales. Este enfoque enfocado facilita las mejoras y reduce la complejidad causada por una multitud de características interconectadas. Al mantenerse cerca de quienes controlan la hoja de ruta y elegir un software con un enfoque muy preciso, las empresas pueden gestionar mejor la complejidad y aumentar la productividad.
Transcripción completa
Kieran Chandler: Hoy vamos a abordar el tema de la Frankensteinización de software. Entonces, Joannes, este es un tema bastante difícil de pronunciar, así que probablemente te dejaré este a ti. Supongo que no estamos hablando de un gran monstruo verde hoy. ¿De qué estamos hablando exactamente?
Joannes Vermorel: Estamos hablando de un proceso que impulsa la evolución del software, específicamente el software B2B, y aún más específicamente, el software de supply chain. Se aplica principalmente al software B2B de larga vida. Este proceso, al que me refiero como “Frankensteinization”, evoluciona el software a lo largo de los años con una corriente continua de grandes acuerdos negociados entre los proveedores de software y sus clientes. Lo interesante, y de donde proviene la parte de “Frankensteinization”, es que cada gran acuerdo negociado entre el proveedor y uno de sus grandes clientes probablemente deje una cicatriz en el software.
Es un proceso gradual en el que un proveedor negocia con una gran empresa. La gran empresa tiene demandas, y para satisfacer esas demandas se realizan ajustes en el software que no encajan con la arquitectura, la filosofía o el diseño original en su conjunto. Se añade la característica, pero de una manera algo hackish. Esa es una cicatriz. El problema es que, si repites este proceso una y otra vez durante años, lo que obtienes en términos de software es, de alguna manera, un monstruo Frankenstein. Es una bestia hecha de muchas cicatrices que se ven algo horribles y súper compuestas. Evoluciona de formas extrañas, y así es como se terminan obteniendo estos monstruos de software Frankenstein. Esto es algo que ocurre en la mayoría de las bases de datos, pero en el software de supply chain, es como si estuviera en esteroides.
Kieran Chandler: Hablemos de estas cicatrices, como las mencionas. ¿Cómo se ven? Quiero decir, están mejorando el software, ¿verdad? Están añadiendo características adicionales. ¿Es eso algo tan malo?
Joannes Vermorel: Sí, obviamente ese es el compromiso. Quieres mejorar tu software, pero un pieza de software es un objeto muy complicado. No es como un edificio donde puedes simplemente añadir un piso o expandirte de manera ordenada. El software viene con muchas suposiciones de diseño inviolables hechas desde muy temprano que le otorgan cierta integridad—integridad arquitectónica.
Tomemos muchos ERPs como ejemplo, que fueron construidos en torno a la idea de capturar la estacionalidad con perfiles de exactamente 52 semanas, representando un año dado. Así, literalmente tienes una tabla con 52 columnas, una columna por semana, y tienes todos estos perfiles de estacionalidad que puedes aplicar a cualquier artículo que estés produciendo o vendiendo. Pero, ¿qué pasa si deseas modelar algo como el Año Nuevo Chino? No encaja en esta cuadrícula de 52 semanas porque se trasladará de un año a otro según el calendario tradicional chino, no el calendario gregoriano. Te enfrentarás a problemas similares con el Ramadán o incluso con la Pascua.
Tienes esta suposición muy acertada que puede desmoronarse cuando te enfrentas a una demanda que no encaja en tu marco. Y eso puede tomar muchas formas. El problema es que, como proveedor de software, realmente no tienes el tiempo para reescribir toda tu pila de software para que estas nuevas características se integren en tu arquitectura de manera completamente nativa. Al final, es algo hackish.
Kieran Chandler: Estás negociando con un cliente importante, así que no tienes años para cerrar el acuerdo. Y luego, tampoco tienes años para entregar el futuro. Por lo tanto, las cosas deben hacerse en una emergencia relativa cada vez, simplemente por el hecho de que, en realidad, es una negociación más grande de lo habitual para cerrar una venta. Las cosas se hacen con prisa casi por diseño. Pero, ¿cuándo algo se convierte en una cicatriz y cuándo en una buena característica? Porque todo este software tiene que evolucionar, tiene que cambiar, tiene que funcionar para sus clientes. ¿Qué diferencia a uno de otro? ¿Cómo sabes que algo que estás desarrollando no se convertirá en una cicatriz?
Joannes Vermorel: La cuestión es, ¿cuánto costará en términos de mantenimiento? Cada línea de código que existe en tu gran software empresarial es algo que tendrás que mantener. Algo que la gente no siempre se da cuenta, incluso los profesionales del software, es que el software es como una maquinaria intrincada en la que cada parte debe interactuar de alguna manera con todas las demás partes. Tienes un problema de complejidad cuadrática.
¿Qué significa eso? Significa que si tengo diez partes, básicamente tengo alrededor de 100 interacciones potenciales, ya sabes, 10 x 10. Si tengo mil partes y todas están interactuando, entonces tengo 1,000 por 1,000 interacciones. Cada interacción potencial es una receta para todo tipo de problemas: problemas de seguridad, bugs, caídas, resultados incorrectos o simplemente una desaceleración masiva en el software.
Cuando añades más partes, aumentas el número de interacciones potenciales entre las partes en tu software, y aumenta mucho más rápidamente que el número de partes. Y cuando digo partes, puedes pensar en características, funcionalidades, pantallas, opciones de datos o entradas.
Si eres muy cuidadoso con la arquitectura de tu software, puedes preservar el número de interacciones entre tus funcionalidades para mantenerlo bajo control. Si duplicas el número de funcionalidades en tu software, no quieres multiplicar el número de interacciones por 4, porque eso significa que al duplicar el número de funcionalidades, en realidad multiplicas por cuatro la cantidad de mantenimiento que necesitas hacer.
Pero es muy difícil. Cuando tienes prisa, al duplicar el número de funcionalidades, en realidad multiplicas por 4 o incluso más la cantidad de esfuerzo que tienes que invertir en el mantenimiento. Con el tiempo, el costo de mantenimiento se dispara, y tu capacidad para implementar cosas nuevas disminuye cada vez más. Cada vez que introduces una nueva funcionalidad, desencadena una ola completa de incompatibilidades e interacciones no previstas y extrañas entre las diferentes partes, porque no ha sido completamente pensada. El dolor aumenta con el tiempo.
Kieran Chandler: Bien, entonces pensemos las cosas desde la perspectiva de esa empresa de software. ¿Cómo pueden introducir estas nuevas funcionalidades? ¿Cómo pueden implementar estas funcionalidades para mantener felices a sus clientes, sin introducir esta capa extra de complejidad? ¿Qué pueden hacer?
Joannes Vermorel: Creo que la lección viene del mundo del software B2C. Google no implementa nuevas funcionalidades para Google Search, ni Netflix introduce nuevas funcionalidades para Netflix solo porque están ganando un nuevo cliente. No captan nuevos clientes y comienzan a discutir con ellos diciendo, “Oh, si no tenemos esas funcionalidades, entonces no te inscribirás con nosotros, así que necesitamos hacerlo ahora.”
No funcionan de esa manera. Piensan en cuál es el dominio, cuál es el problema específico que están tratando de resolver. Intentan tener una perspectiva muy amplia sobre este problema y luego pensar.
Kieran Chandler: Estás hablando de un enfoque que busca generar soluciones para toda una categoría de problemas, en lugar de un único micro problema. Esto requiere re-arquitectar el software para abordar un amplio espectro de problemas similares. Y esto sucede todo el tiempo. Al interactuar con los clientes, escuchas sus problemas, no sus soluciones propuestas. En comparación, en el mundo B2B, los clientes tienden a presentar no solo su problema, sino también una solución. Esta solución puede o no encajar en tu pila de software existente o en la evolución de este problema. Entonces, ¿se trata de no escuchar realmente?
Joannes Vermorel: Precisamente, se trata más de comprender realmente el problema central en lugar de fijarse en una solución particular. Grandes empresas como Google y Netflix son excelentes ejemplos de esto.
Kieran Chandler: Entonces, ¿estás diciendo que las empresas no están escuchando realmente? Pero ¿qué pasa con esos molestos pop-ups que piden feedback? ¿Alguien les presta atención realmente?
Joannes Vermorel: Los pop-ups a los que te refieres son típicamente funcionalidades no deseadas. Pero hay que reconocer a empresas como Google. Estos pop-ups, en los que tienes que aceptar los términos, no fueron una elección de ellos. Se vieron obligados a implementarlos por restricciones regulatorias. Así que, aunque pueda parecer una funcionalidad extraña, no fue cosa de ellos. Además, si miras quién ganó la web, no fueron las empresas con anuncios súper molestos. Fueron aquellas como Google que tenían anuncios limpios y discretos. Ellos pensaban en sus clientes en lugar de devaluar su producto con algo tan molesto. Se toman el tiempo de pensar bien en sus funcionalidades.
Kieran Chandler: En las empresas de software B2B, particularmente en supply chain, hay una gran diversidad. Puede haber cientos de escenarios, y a menudo, en el último minuto, las personas negocian muchas funcionalidades que casi siempre resultan ser malas ideas seis meses después. Entonces, ¿estarías de acuerdo en que la “Frankensteinización” del software es algo malo? Y en ese caso, ¿qué han hecho de diferente en Lokad para evitar este problema?
Joannes Vermorel: Absolutamente, la Frankensteinización del software es un problema. Durante los primeros años en Lokad, nos enfrentamos a este mismo tema. Fue un compromiso difícil. Si quieres hacerlo bien, puede llevar uno o dos años, lo cual es demasiado lento. Si no lo haces bien, puedes terminar en unas pocas semanas o meses, pero entonces te quedas con una gran cicatriz, un hack feo. Terminas acumulando deuda técnica. Así que, durante los primeros años en Lokad, no teníamos una solución, pero éramos cada vez más conscientes del problema. Incluso como startup, la deuda tecnológica se acumulaba, lo cual era una situación preocupante. Fue en ese momento cuando me di cuenta de que la tendencia era desfavorable. Mirando unas cuantas décadas en el futuro, podía ver cómo los competidores, con su software inflado para la optimización de supply chain, simplemente estaban añadiendo cada vez más funcionalidades sin ninguna coherencia.
Kieran Chandler: Parece que las empresas de software siempre están añadiendo nuevas funcionalidades, y el resultado final puede ser un producto confuso e inflado. ¿Puedes hablar sobre tu enfoque para este problema en Lokad?
Joannes Vermorel: Absolutamente. La forma en que el software tiende a inflarse es añadiendo una mala funcionalidad a la vez. Si continúas por este camino durante 20 años, terminas con un producto monstruoso. No es que los desarrolladores sean incompetentes o tontos, simplemente están haciendo un trabajo decente de forma incremental, tratando de ganar un cliente a la vez. Sin embargo, este enfoque recorre el software un cliente a la vez, y el resultado final suele ser muy, muy malo.
Así que, decidimos tomar un ángulo completamente diferente en Lokad, y eso llevó al nacimiento de Envision, nuestro lenguaje de programación de dominio específico. Con Envision, dividimos efectivamente todos los problemas. Separamos la infraestructura, la infraestructura de datos y la infraestructura de machine learning. Estos son productos de larga duración que queremos mantener y actualizar, y es un esfuerzo de varios años cada vez que decidimos cambiarlos y actualizarlos.
Luego, por separado, para cada cliente, creamos una implementación completamente hecha a la medida escrita en scripts en Envision. Dado que Envision está diseñado específicamente para la optimización de supply chain, podíamos escribir algo completamente hecho a la medida para cada cliente, con alta productividad.
Así que, empezamos con una hoja en blanco, la personalizamos completamente, y luego no tenemos que enfrentarnos a una situación en la que el cliente nos pida algo que no soportamos. Debido a las capacidades programáticas de Envision, si tenemos que hacer algo especial para un cliente, el peor escenario es que el script que escribamos no será tan compacto como de costumbre. Sin embargo, aún podemos beneficiarnos de una infraestructura diseñada para facilitar la solución de ciertos tipos de problemas.
Si introduces capacidades avanzadas de dominio específico programáticas en tu plataforma, entonces de repente no tienes que apresurar una negociación que dejará cicatrices en tu producto. Puedes hacer la personalización en tu entorno programático, el cual es hecho a la medida para cada cliente, y luego seguir implementando actualizaciones para tu plataforma en tu propio calendario, que probablemente no coincidirá con el de tus clientes.
Kieran Chandler: Identificaste este problema bastante temprano. ¿Qué consejo le darías a otras empresas de software que están experimentando este tipo de bloatware? ¿Pueden hacer algo al respecto? ¿Deberían empezar a eliminar algunas de estas funcionalidades para simplificar las cosas?
Joannes Vermorel: La situación depende de varios factores. Si eres una gran empresa que posee el software, como un WMS, ERP, MRP, etc., es posible que ni siquiera tengas acceso al software en sí, podría ser simplemente un producto de un proveedor. Si no tienes acceso al producto, entonces estás atrapado con la complejidad del software que has adquirido.
Si tienes acceso al software y quieres simplificarlo, entonces sí, deberías empezar por revisar todas las cosas que no estás usando y descartarlas agresivamente. A muchas personas les preocupa eliminar partes de un software existente porque temen perder ciertas funcionalidades. Es cierto que si eliminas funcionalidades, las pierdes. Sin embargo, si eliminas algo que casi nunca se usa, también puedes eliminar toda una serie de problemas que eran causados por la mera presencia de esa pequeña funcionalidad.
A menudo vemos implementaciones de ERP en Lokad con literalmente miles de tablas. Puedes tener un ERP con, digamos, cinco mil tablas. Cada tabla puede tener entre 10 y 200 campos, lo que resulta en una complejidad masiva. Incluso respaldar el ERP puede ser increíblemente complicado.
Kieran Chandler: Porque tienes tantas tablas, necesitas una tabla para almacenar la lista de las tablas y demás. Esa es el tipo de situación en la que, si puedes identificar toneladas de tablas que ya no se usan, o pantallas que ya no se utilizan, simplemente eliminándolas, todo se simplifica.
Joannes Vermorel: Exactamente, por ejemplo, si tienes que actualizar de una versión de tu base de datos a otra, uno de los problemas que puedes encontrar es que necesitas actualizar partes de la lógica que ya no usa nadie. Cada línea de código que existe, sea en Java, C Sharp, SQL o lo que sea, es algo que necesitas mantener mientras esa línea de código exista. Si eliminas eso, significa que durante tu próxima integración o migración, la gente no tendrá que hacerse la pregunta de cómo migramos esto a la siguiente versión del sistema o al siguiente sistema en su totalidad.
Y esto es algo en lo que los ejecutivos de supply chain deben pensar. Al comprar software, realmente deberían adherirse al principio de parsimonia: si no lo necesitas realmente, es mejor no tener esa parte del sistema. Solo será una carga. Es vital prestar atención constantemente a la masa tecnológica de la solución que estás adquiriendo y operando.
Esta masa tecnológica no es gratuita. Si tienes más pantallas, necesitas a más personas para capacitarlas. Si puedes eliminar un par de pantallas, eso significaría menos capacitación, menos reportes de bugs, menos peleas con TI y así sucesivamente. Se trata de gestionar la complejidad de TI, pero lo complicado es que, típicamente, TI no tiene idea de ello porque no tiene acceso al valor de negocio. No pueden diferenciar entre funcionalidades que son realmente necesarias y aquellas que no lo son absolutamente. No pueden traducir tablas, campos, pantallas o capacidades a euros o dólares. Eso es algo que solo las personas de supply chain o de marketing, si estás mirando otro sistema, pueden hacer. Por eso TI necesita el respaldo de esas personas, los decisores de la compañía, para impulsar la priorización y el cambio en la simplificación del sistema.
Kieran Chandler: Y así, para concluir, mencionaste que si soy un ejecutivo de supply chain que quiere invertir en un nuevo software para mi empresa, parece que no debería estar pidiendo tanta personalización, ya que eso introduce problemas. Entonces, ¿qué debería buscar?
Joannes Vermorel: Sí, pedir personalización o funcionalidades especiales es como una receta para generar problemas. Si tu proveedor de software no tenía suficientes problemas propios, simplemente estás creando nuevos que empeorarán las cosas. Así que, en realidad, no deberías hacerlo. Si puedes pedir personalización, solo como prueba, porque si el proveedor se involucra voluntariamente en la discusión contigo sobre la personalización, eso significa que el proveedor no tiene integridad. Eso significa que el proveedor hace eso con cada uno de sus demás clientes, lo que implica que, incluso si el producto es bueno hoy, dentro de cinco años será una pesadilla.
En primer lugar, si pides personalización, es bueno solicitarla y realmente deberías esperar que esta petición sea denegada. Si no, entonces es un problema.
Kieran Chandler: ¿Una de las cosas que la gente debería pedir son funcionalidades especiales, correcto? Quiero decir, si hay algo que se deba pedir, podría ser acceso al CTO o al gerente de producto del lado del proveedor. ¿Incluirlo como parte del contrato, tal vez? Como querer tener una reunión con esa persona durante dos horas una vez al mes. ¿Por qué?
Joannes Vermorel: Si negocias tener acceso directo a las personas que están diseñando la hoja de ruta del proveedor, simplemente puedes presentar tus cambios. No necesitas imponerles tu solución; solo presenta tu problema. Porque, como ingenieros, ¿qué hacen cuando se les presenta un problema? Empezan a trabajar en una solución. Si tienes una reunión de rutina en la que presentas tus problemas, no necesitas negociar ninguna funcionalidad específica en el contrato. En un par de años, comenzarán a aparecer en el producto funcionalidades que parecen encajar con el mismo problema que expusiste.
Kieran Chandler: ¿Puedes explicar un poco más sobre eso?
Joannes Vermorel: Si haces las cuentas, considera al CTO de una empresa de software. ¿Cuántas reuniones puede tener esta persona con clientes en un mes determinado? Digamos que tiene un máximo de 20. Si tienes una reunión al mes, esencialmente estás obteniendo alrededor del cinco por ciento de la capacidad mental del CTO, quien está impulsando el desarrollo tecnológico del proveedor con el que trabajas. Esto significa que tus problemas están recibiendo una cantidad significativa de atención.
Kieran Chandler: Entonces, ¿cuál es tu sugerencia?
Joannes Vermorel: Mi sugerencia, si quieres hacerlo de manera inteligente, es acercarte a las personas que tienen el control sobre la hoja de ruta. Es más inteligente que negociar apresuradamente por funcionalidades rotas que probablemente descartarás en seis meses porque tu solución no fue buena o tu problema ha cambiado. Además, otro tipo de consejo sería evitar el software que hace demasiado. Quieres pensar en una pieza de software que haga una cosa y la haga bien, en lugar de un software con amplias capacidades que termina haciendo todo mal.
Kieran Chandler: ¿Puedes elaborar un poco más sobre ese punto?
Joannes Vermorel: Es más fácil mejorar una pieza de software fuertemente enfocada que mejorar un marco gigantesco que lo hace todo. Siempre que vayas a ajustar algo, piensa en ello como el número cuadrático de interacciones. Si tienes mil funcionalidades y añades una, necesitas considerar todas las interacciones con las 1,000 funcionalidades preexistentes. Entonces, si introduces una funcionalidad, revisas todas las 1,000 interacciones. Sin embargo, si tienes solo diez funcionalidades y añades una undécima, solo son diez interacciones que revisar. Así que, de nuevo, concéntrate en algo que sea ágil y esté enfocado claramente en el problema específico que estás tratando de resolver.
Kieran Chandler: ¡Genial! Me temo que tendremos que dejarlo aquí por hoy, pero supongo que hay algunos CEOs por ahí que quizás no te lo agradezcan demasiado por ello, probablemente recibiendo unas cuantas llamadas más ahora. Bueno, eso es todo por esta semana. Volveremos nuevamente la próxima semana con otro episodio. Hasta entonces, cuídate.
Joannes Vermorel: Gracias.
