00:00:04 Introducción a la Frankensteinización del software.
00:00:35 Impacto de la Frankensteinización del software en el software B2B.
00:01:31 Cómo las demandas de los clientes influyen en la Frankensteinización del software.
00:02:32 ‘Cicatrices’ en el software y sus implicaciones.
00:05:33 Costos de mantenimiento de la Frankensteinización del software.
00:08:00 Desafíos y costos de las nuevas características del software.
00:08:57 Características sin complejidad: ideas del B2C.
00:10:36 Problemas con el enfoque B2B en las soluciones de software.
00:13:18 Experiencia de Lokad: correcto vs rápido y deuda técnica.
00:15:14 Envision: la solución de Lokad a la complejidad.
00:16:30 Scripting específico del dominio: evitando limitaciones y conflictos.
00:17:43 Abordar el bloatware del software en las cadenas de suministro.
00:18:01 Estrategias para simplificar el software complejo.
00:20:54 Gestionar la ‘masa tecnológica’ en los sistemas de software.
00:22:00 Sinergia de TI, cadena de suministro y marketing en los cambios del sistema.
00:22:43 Problemas con la personalización excesiva del software.
00:23:48 Probar 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 software ágil y enfocado para evitar la personalización.
Resumen
En Lokad TV, Joannes Vermorel presenta el concepto de Frankensteinización del software, refiriéndose a la forma en que el software B2B evoluciona a través de modificaciones improvisadas que no se alinean con su diseño original. Compara estos cambios con ‘cicatrices’, que contribuyen a la creación de un sistema de software compuesto y evolucionado. Se presenta a los ERPs como ejemplo, enfatizando el dilema entre mantener la arquitectura del software y satisfacer nuevas demandas. Vermorel advierte contra decisiones precipitadas, que a menudo resultan en cicatrices de software y un aumento en los costos de mantenimiento. Si bien reconoce la inevitable complejidad en la gestión del software, Vermorel destaca la importancia de aprender de los modelos B2C para controlar las interacciones de características. La respuesta de Lokad a este problema es “Envision”, un lenguaje de programación específico del dominio que separa los problemas de infraestructura y los específicos del dominio.
Resumen Extendido
En el último episodio de Lokad TV, la conversación gira en torno al concepto de Frankensteinización del software, un término propuesto por Joannes Vermorel, fundador de Lokad. Utiliza este término para describir la transformación del software B2B a lo largo del tiempo, especialmente el software de larga duración y de cadena de suministro, a medida que evolucionan a través de negociaciones continuas y grandes acuerdos entre proveedores de software y sus clientes.
Vermorel explica que la Frankensteinización del software ocurre cuando se realizan ajustes al software en respuesta a las demandas de los clientes. Estos cambios a menudo son inconsistentes con la arquitectura original, la filosofía y el diseño del software. Como resultado, el software acumula estas alteraciones, o “cicatrices”, con el tiempo, convirtiéndolo en lo que Vermorel describe como un “monstruo de Frankenstein” - un sistema de software compuesto y extrañamente evolucionado.
Además, señala que este fenómeno es especialmente pronunciado en el software de cadena de suministro, pero también es común en muchos tipos de software B2B. Sin embargo, aclara que el término “cicatriz” no debe ser malinterpretado como inherentemente negativo. Estas modificaciones pueden mejorar el software al agregar nuevas características, mejorando así su funcionalidad.
Vermorel proporciona un ejemplo de software de Planificación de Recursos Empresariales (ERP), que asume que la estacionalidad se puede capturar 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 dilema. Pueden atender la nueva demanda mediante la integración de una solución “chapucera”, que no se ajusta perfectamente a 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.
Haciendo hincapié en el ritmo acelerado de las negociaciones con los clientes clave en el negocio del software, Vermorel advierte que la urgencia puede llevar inadvertidamente a “cicatrices en el 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 del software, Vermorel señala que cada línea de código o característica necesita mantenimiento. A medida que se agregan más características, las interconexiones se vuelven más complejas, lo que lleva a un “problema de complejidad cuadrática”. Esencialmente, las interacciones potenciales aumentan exponencialmente a medida que aumenta el número de partes, lo que provoca una variedad de problemas potenciales como errores, bloqueos y amenazas de seguridad.
Vermorel destaca la importancia de una arquitectura de software meticulosa para controlar el número de interacciones entre características. Señala que el objetivo debería ser duplicar solo la cantidad de mantenimiento requerido si se duplica el número de características, en lugar de cuadruplicar o más, como suele suceder cuando el desarrollo se apresura.
Cuando se le pregunta cómo las empresas de software pueden introducir nuevas características sin agregar una complejidad excesiva, Vermorel sugiere aprender de las empresas de software B2C como Google y Netflix. Se toman el tiempo para comprender los problemas específicos que están tratando de 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.
En cuanto a cómo Lokad maneja estos problemas, Vermorel revela su lucha inicial para equilibrar entre hacer las cosas correctamente y acomodar rápidamente las solicitudes de los clientes. Se dieron cuenta de un aumento de la deuda tecnológica en los primeros años, lo cual Vermorel reconoce como perjudicial. Se dieron cuenta de que si bien agregar características para complacer a clientes individuales puede 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 del dominio llamado “Envision”. El objetivo de Envision es separar los problemas de infraestructura de los problemas específicos del dominio, lo que permite a Lokad gestionar la adición y el mantenimiento de nuevas características de manera más efectiva sin agregar una complejidad excesiva.
Vermorel continúa explicando cómo los productos de software, especialmente en la industria de la gestión de la cadena de suministro, a menudo se enfrentan a un problema de inflado debido a la personalización extensiva para cada cliente. Si bien la personalización tiene como objetivo ofrecer soluciones a 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 del 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 evitar el software inflado. Vermorel responde que el escenario depende de si una empresa tiene acceso a su software. Si no es así, la empresa debe lidiar con la complejidad del software adquirido. Sin embargo, si hay acceso disponible, el software se puede simplificar identificando y eliminando elementos no utilizados, lo que reduce en gran medida la complejidad.
Cambiando el enfoque a las responsabilidades de los profesionales de TI y los científicos de la cadena de suministro, Vermorel observa que si bien el personal de TI suele tener los conocimientos técnicos, a menudo carece de comprensión del valor comercial de ciertas características. Esto lleva a una desconexión entre las características necesarias y las innecesarias. Por lo tanto, los tomadores de decisiones comerciales deben colaborar estrechamente con TI para impulsar la priorización y la simplificación del sistema.
Vermorel brinda consejos para los ejecutivos de la cadena de suministro que buscan invertir en nuevo software. Advierte contra exigir una personalización excesiva, ya que puede generar más problemas. En cambio, los ejecutivos deben mantener contacto regular con los gerentes de productos o los CTO de los proveedores para comunicar directamente sus necesidades. En lugar de imponer características específicas en un contrato, el objetivo debe ser presentar problemas a aquellos capaces de diseñar soluciones.
Por último, Vermorel aconseja a las empresas que elijan software que destaque en una sola cosa, en lugar de optar por soluciones completas. Este enfoque centrado 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 software enfocado, las empresas pueden gestionar mejor la complejidad y mejorar la productividad.
Transcripción completa
Kieran Chandler: Hoy vamos a abordar el tema de la Frankensteinización del software. Entonces, Joannes, este es un tema que es bastante difícil de pronunciar, así que probablemente te lo deje a ti. Supongo que hoy no estamos hablando de un gran monstruo verde. ¿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 la cadena de suministro. Se aplica principalmente al software B2B de larga duración. Este proceso, al que me refiero como “Frankensteinización”, hace evolucionar 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, de donde viene la parte de “Frankensteinización”, es que cada gran acuerdo negociado entre el proveedor y uno de sus grandes clientes probablemente dejará 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 cumplir con esas demandas, se realizan ajustes en el software que no se ajustan a la arquitectura general, la filosofía o el diseño original. Se agrega la función, pero de una manera algo chapucera. Eso 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 de 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 terminas con estos monstruos de software de Frankenstein. Esto es algo que sucede en la mayoría de las bases de datos, pero en el software de la cadena de suministro, es como si estuviera en esteroides.
Kieran Chandler: Hablemos de estas cicatrices, como las llamas. ¿Cómo se ven? Quiero decir, están mejorando el software, ¿verdad? Están agregando características adicionales. ¿Es eso algo malo?
Joannes Vermorel: Sí, obviamente ese es el compromiso. Quieres mejorar tu software, pero un software es un objeto muy complicado. No es como un edificio donde puedes simplemente agregar un piso o expandirlo de manera agradable. El software viene con muchas suposiciones de diseño inviolables hechas muy temprano que le dan al software cierta integridad, integridad arquitectónica.
Tomemos muchos ERPs como ejemplo, que se construyeron en torno a la idea de capturar la estacionalidad con perfiles que son exactamente 52 semanas, que representan un año determinado. Entonces, 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 quieres modelar algo como el Año Nuevo Chino? No encaja en esta cuadrícula de 52 semanas porque se va a mover de un año a otro según el calendario chino tradicional, no el calendario gregoriano. Te enfrentarás a problemas similares con el Ramadán o incluso la Pascua.
Tienes esta suposición muy bonita 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, en realidad no tienes tiempo para reescribir toda tu pila de software para que estas nuevas características se integren en tu arquitectura de una manera completamente nativa. Al final, es un poco chapucero.
Kieran Chandler: Estás negociando con un cliente importante, por lo que no tienes años para cerrar el trato. Y luego, tampoco tienes años para entregar el futuro. Entonces, las cosas tienen que hacerse en una emergencia relativa cada vez, simplemente debido al hecho de que en realidad es una negociación más grande de lo habitual para cerrar una venta. Las cosas se apresuran casi por diseño. Pero, ¿cuándo algo se convierte en una cicatriz y cuándo algo se convierte en una buena característica? Porque todos estos software tienen que evolucionar, tienen que cambiar, tienen que funcionar para sus clientes. Entonces, ¿qué diferencia a los dos? ¿Cómo sabes que algo que estás desarrollando no se convertirá en una cicatriz?
Joannes Vermorel: La pregunta es cuánto costará en términos de mantenimiento. Cada línea de código que existe en tu software empresarial grande es algo que tendrás que mantener. Una cosa que las personas no siempre se dan cuenta, incluso los profesionales del software, es que el software es como una maquinaria intrincada donde cada parte tiene que 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, errores, bloqueos, resultados incorrectos o simplemente ralentizaciones masivas en el software.
Cuando agregas 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, capacidades, 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 características para mantenerlo bajo control. Si duplicas el número de características en tu software, no quieres multiplicar el número de interacciones por 4, porque eso significa que cuando duplicas el número de características, en realidad cuadruplicas la cantidad de mantenimiento que necesitas hacer.
Pero es muy difícil. Cuando tienes prisa, cuando duplicas el número de características, 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, tu capacidad para implementar cosas nuevas disminuye cada vez más. Cada vez que introduces una nueva característica, desencadena una ola completa de incompatibilidades y extrañas interacciones no deseadas entre diferentes partes, porque no se ha pensado completamente. El dolor aumenta con el tiempo.
Kieran Chandler: Bueno, entonces pensemos en las cosas desde la perspectiva de esa empresa de software. ¿Cómo pueden introducir estas nuevas características? ¿Cómo pueden implementar estas características para mantener contentos a sus clientes, sin introducir esta capa adicional de complejidad? ¿Qué pueden hacer?
Joannes Vermorel: Creo que la lección viene del mundo del software B2C. Google no lanza nuevas características para Google Search, o Netflix no lanza nuevas características para Netflix solo porque están contratando a un nuevo cliente. No trabajan así. 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.
No trabajan así. 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 piensan.
Kieran Chandler: Discutes un enfoque que tiene como objetivo generar soluciones para toda una categoría de problemas, en lugar de un solo microproblema. Esto implica reestructurar 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 stack 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 obsesionarse con 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 realmente escuchando. Pero, ¿qué hay de esas molestas ventanas emergentes que piden comentarios? ¿Alguien realmente las está mirando?
Joannes Vermorel: Las ventanas emergentes a las que te refieres son características típicamente indeseables. Pero hay que dar crédito a empresas como Google. Estas ventanas emergentes, donde tienes que aceptar los términos, no fueron su elección. Se vieron obligados a implementarlas debido a restricciones regulatorias. Entonces, aunque pueda parecer una característica extraña, no fue su elección. Además, si miras quién ganó en la web, no fueron las empresas con anuncios súper molestos. Fueron aquellos como Google que tenían anuncios limpios y discretos. Pensaban en sus clientes en lugar de devaluar su producto con algo tan molesto. Se toman el tiempo para pensar en sus características.
Kieran Chandler: En las empresas de software B2B, especialmente en la cadena de suministro, hay mucha diversidad. Puede haber cientos de escenarios y, a menudo en el último minuto, las personas negocian muchas características que casi siempre resultan ser malas ideas seis meses después. Entonces, ¿estás de acuerdo en que la Frankensteinización del software es algo malo? Y si es así, ¿qué has hecho de manera 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 problema. 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 luego te quedas con una gran cicatriz, un hack feo. Terminas acumulando deuda técnica. Entonces, durante los primeros años de Lokad, no teníamos una solución, pero cada vez éramos más conscientes del problema. Incluso como startup, la deuda tecnológica iba en aumento, lo cual era una situación preocupante. Fue en este punto que me di cuenta de que la tendencia no era favorable. Mirando un par de décadas hacia el futuro, podía ver cómo los competidores, con su software inflado para la optimización de la cadena de suministro, simplemente agregaban más y más características sin ninguna consistencia.
Kieran Chandler: Parece que las empresas de software siempre están agregando nuevas características y el resultado final puede ser un producto confuso y abultado. ¿Puedes hablar sobre tu enfoque para este problema en Lokad?
Joannes Vermorel: Absolutamente. La forma en que el software tiende a volverse abultado es agregando una mala característica 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 manera incremental, tratando de ganar un cliente a la vez. Sin embargo, este enfoque desgasta el software cliente por cliente y el resultado final suele ser muy, muy malo.
Entonces, decidimos tomar un enfoque completamente diferente en Lokad, y eso llevó al nacimiento de Envision, nuestro lenguaje de programación específico del dominio. 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 cambiar y actualizarlos.
Luego, por separado, para cada cliente, creamos una implementación completamente personalizada escrita en scripts en Envision. Como Envision está diseñado específicamente para la optimización de la cadena de suministro, podríamos escribir algo completamente personalizado para cada cliente, con alta productividad, al mismo tiempo que lo hacemos completamente a medida.
Entonces, comenzamos con una hoja en blanco, la personalizamos por completo y luego no tenemos que enfrentar una situación en la que el cliente nos pida algo que no admitimos. 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 sea tan compacto como de costumbre. Sin embargo, aún podemos beneficiarnos de una infraestructura diseñada para facilitar la resolución de ciertos tipos de problemas.
Si introduces capacidades programáticas avanzadas específicas del dominio en tu plataforma, 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 que es a medida para cada cliente, y luego seguir implementando actualizaciones para tu plataforma según tu propio cronograma, que probablemente no coincidirá con el cronograma de tus clientes.
Kieran Chandler: Identificaste este problema bastante temprano. ¿Qué consejo le darías a otras empresas de software que experimentan este tipo de software abultado? ¿Pueden hacer algo al respecto? ¿Deberían comenzar a eliminar algunas de estas características para simplificar las cosas?
Joannes Vermorel: La situación depende de varios factores. Si eres una empresa grande que posee el software, como un WMS, ERP, MRP, etc., es posible que ni siquiera tengas acceso al software en sí, podría ser solo 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 comenzar por analizar todas las cosas que no estás utilizando y descartarlas agresivamente. Muchas personas suelen preocuparse por eliminar partes de un software existente porque les preocupa perder ciertas capacidades. Es cierto que si eliminas capacidades, pierdes esas capacidades. Sin embargo, si eliminas algo que casi nunca se usa, también puedes eliminar clases enteras de problemas que fueron causados por la mera presencia de esta pequeña característica.
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 hacer una copia de seguridad del ERP puede ser increíblemente complicado.
Kieran Chandler: Debido a que tienes tantas tablas, necesitas una tabla para almacenar la lista de las tablas y demás. Ese es el tipo de situación en la que, si puedes identificar muchas tablas que ya no se utilizan, o pantallas que ya no se utilizan, simplemente eliminándolas, simplificas todo.
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 piezas de lógica que ya no son utilizadas por nadie. Cada línea de código que existe, ya sea Java, C Sharp, SQL o cualquier otro, es algo que debes mantener mientras exista la línea de código. Si lo eliminas, significa que durante tu próxima integración o migración, las personas no tendrán que preguntarse cómo migrar esta cosa a la próxima versión del sistema o al próximo sistema en general.
Y esto es algo en lo que los ejecutivos de la cadena de suministro deben pensar. Al comprar software, realmente deberían adherirse al principio de parsimonia: si realmente no lo necesitas, es mejor no tener esa parte del sistema. Solo será una carga. Es vital prestar constantemente atención 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 más personas para capacitarlas. Si puedes eliminar un par de pantallas, eso significaría menos capacitación, menos errores reportados, menos peleas con TI, etc. Se trata de gestionar la complejidad de TI, pero la parte complicada es que típicamente, TI no tiene idea de eso porque no tienen acceso al valor comercial. No pueden diferenciar entre características que son realmente necesarias y características que no son absolutamente necesarias. No pueden traducir tablas, campos, pantallas o capacidades a euros o dólares. Eso es algo que solo las personas de la cadena de suministro o de marketing, si estás mirando un sistema diferente, pueden hacer. Por eso TI necesita el respaldo de esas personas, los tomadores de decisiones en la empresa, para impulsar la priorización y el cambio en la simplificación del sistema.
Kieran Chandler: Y para concluir, mencionaste que si soy un ejecutivo de la cadena de suministro que quiere invertir en un nuevo software para mi empresa, parece que no debería estar pidiendo mucha personalización porque eso introduce problemas. Entonces, ¿en qué debería estar buscando?
Joannes Vermorel: Sí, pedir personalización o características 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 solo empeorarán las cosas. Así que realmente no deberías hacer eso. Si realmente puedes pedir personalización, solo como prueba, porque si el proveedor se involucra voluntariamente en la discusión contigo sobre la personalización, significa que el proveedor no tiene integridad. Eso significa que el proveedor hace eso con todos los demás clientes, lo que significa 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 pedirlo y realmente deberías esperar que se te niegue esa solicitud. Si no, entonces eso es un problema.
Kieran Chandler: Una cosa que las personas deberían pedir son características especiales, ¿verdad? Quiero decir, si hay algo que se debe 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 esta persona 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? Comienzan a trabajar en una solución. Si tienes una reunión de rutina donde presentas tus problemas, no necesitas negociar características específicas en el contrato. En un par de años, comenzarán a aparecer características en el producto que parecen adaptarse al problema que has expuesto.
Kieran Chandler: ¿Puedes explicarlo un poco más?
Joannes Vermorel: Si haces los cálculos, 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 del ancho de banda mental del CTO, quien está impulsando el desarrollo tecnológico del proveedor con el que estás trabajando. 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 inteligentemente, es acercarte a las personas que tienen control sobre la hoja de ruta. Es más inteligente que negociar apresuradamente características rotas que probablemente descartarás en seis meses porque tu solución no era buena o tu problema ha cambiado. Además, una clase diferente de consejo sería evitar el software que hace demasiado. Quieres pensar en un software que haga una cosa y la haga bien, en lugar de un software con capacidades extensas que termine haciendo todo mal.
Kieran Chandler: ¿Puedes ampliar más ese punto?
Joannes Vermorel: Es más fácil mejorar un software enfocado que mejorar un marco gigantesco que lo hace todo. Cada vez que vayas a ajustar algo, piensa en ello como el número cuadrático de interacciones. Si tienes mil características y agregas una, debes pensar en todas las interacciones con las 1,000 características preexistentes. Entonces, si introduces una característica, debes analizar todas las 1,000 interacciones. Sin embargo, si solo tienes diez características y agregas una undécima, solo hay diez interacciones que revisar. Así que nuevamente, concéntrate en algo que sea ágil y esté enfocado 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 directores ejecutivos por ahí que no te agradecerán mucho por eso, probablemente recibirán algunas llamadas telefónicas más ahora. Bueno, eso es todo por esta semana. Volveremos la próxima semana con otro episodio. Hasta entonces, cuídense.
Joannes Vermorel: Gracias.
