Resumen Conversaciones con CEOs y CIOs

Ya me he leido todos los libros de Roberto Canales Mora
Informática Profesional
Planifica tu éxito, de aprendiz a empresario
Conversaciones con CEOs y CIOs sobre Transformación Digital y Metodologías Ágiles
Los cuales puedes encontrar aquí
Sobre Informática Profesional escribí un post recomendando su lectura y citando algunas de los conceptos que para mi fueron más interesantes y ahora he decido hacer lo mismo con Conversaciones con CEOs y CIOs sobre Transformación Digital y Metodologías Ágiles. Donde a continuación voy a citar algunas opiniones que para mi tienen mucho valor.

Si trabajas en el mundo de las tecnologías de la información ya sea directamente o indirectamente recomiendo la lectura de los libros de Roberto, y si tengo que aportar mi humilde opinión personal, para mi gusto Informática Profesional y Planifica tu éxito están un paso por delante de Conversaciones con CEOs y CIOs aun así y todo recomiendo la lectura de los tres y que cada uno pueda formarse su propia opinión.

Como ya dije en mi anterior entrada, Roberto, muchas gracias por estos regalos al sector.

Buscamos clientes y sus frustraciones, y no nos autoexcluimos de la generación de ideas.

Todo se puede hacer, pero algunas cosas son cariiiiiísimas.

Hay que tener siempre en mente un alcance limitado. Podemos manejar conceptos de moda, como el producto mínimo viable.

Eso es como el leñador que dice que no tiene tiempo para afilar el hacha porque tiene que cortar árboles.

Uno de los mayores problemas que tienen las organizaciones es que intentan abordar progresiones continuistas y no disruptivas. Piensan en lo que les falta y no dónde estará el mercado dentro de tres años. Si empiezas hoy un producto en base a lo que necesitas, cuando lo termines ya será un producto del pasado. Irás siempre a remolque del mercado.

Recuerda que los CIOs no pueden ser miembros de segunda del comité de dirección, lo que puede pasar si sólo nos centramos en la táctica u operación diaria.

A lo mejor descubres que es buena inversión que alguien de tu equipo dedique tiempo a la comunidad de desarrolladores o emprendedores, acercándose y haciéndose un hueco entre ellos, bien con conocimiento, o bien con recursos, como ofrecer tus instalaciones o poner la comida. En cierto modo, tu organización puede subvencionar a un grupo para que innove en los negocios que os interesan y en una constelación cercana.

Falla rápido, falla barato.

Si no lo he construido, no hay que recuperar esa inversión. Si no lo construyo, no me retrasa el lanzamiento, ni me tengo que coordinar con terceras partes.

Por eso tenemos que interiorizar que la optimización de una parte del sistema provoca una suboptimización del todo. Si das mucho poder a Compras para que baje precios, es capaz de comprar incorrectamente por hacer bien su trabajo. Si das un bonus a Negocio por conseguir unos objetivos, machacas a Tecnología y Operaciones. Si Tecnología se vuelve muy burocrática o busca la máxima innovación, parará todas las iniciativas. Está claro que tenemos que trabajar de un modo alineado.

Si el núcleo de tu sistema lo tienes de hace treinta años, y su modificación evolutiva o correctiva la tienes externalizada, yo lo dejaría como está, de momento. Pero si vas a afrontar retos de transformación digital, a mí me gustaría tener el control y el conocimiento en equipos internos o, por lo menos, una parte, o, por lo menos, durante los primeros proyectos. Los mismos conceptos que hablábamos de fallar rápido y barato y las técnicas de design thinking los podemos aplicar aquí a las tecnologías y metodologías de mercado.

La gente de peso elige muy bien adónde asiste y a quién quiere conocer.

¿No te parecería más adecuado revisar la calidad de lo que te construyen al primer mes? De este modo, si no se cumplen las expectativas técnicas desde un principio, poco hay hecho y poco hay que arreglar, ¿no?

A medida que vayan pasando los años, cada día estaréis más lejos del código y con menor capacidad de valorar la calidad. ¡Siempre lo puede hacer un tercero distinto! De todos modos, hay herramientas de medida de calidad que básicamente te dicen de un modo bastante objetivo, en base a reglas estándar, si los desarrollos están bien o mal hechos. Por lo menos parte.

Hay cuatro métricas básicas. Una es la cantidad de código repetido. Si un programador copia y pega bloques de código, cuando tenga que cambiar un módulo tiene que acordarse de dónde estaba repetido y reproducirlo. Imagina que se calcula el precio de un producto en diez sitios.

Cuadro de mando del código fuente que se genera.

Efectivamente, aquí empieza a aparecer un término que se denomina «deuda» técnica. Es decir, que lo que te están construyendo tiene unas deficiencias cuantificables. Las herramientas te dicen hasta los «días» que harían falta para corregirla. En muchos casos son años. Esa deuda ni siquiera conviene abordarla a lo loco.

Esto se llama TDD o Test Driven Development o desarrollo guiado por pruebas. Podríamos decir que es un
modo distinto de diseñar y construir software donde los programadores primero piensan los escenarios de prueba y luego el código real. Realmente el desarrollo guiado por pruebas es un modo mejor de diseñar software.