Aplique métricas significativas para renovar su código de producto | Desarrolladores


Por Jack M. Germain

29 de junio de 2021 4:00 a. M. (Hora del Pacífico)

La industria del desarrollo de software se está preparando para la actividad posterior a la pandemia. Pero los desarrolladores sin duda encontrarán que la carrera por el lanzamiento probablemente fracasará si no consideran métricas significativas en su implementación.

La consideración más importante para implementaciones y lanzamientos exitosos es usar métricas inteligentes, precisas y efectivas, dice Aurimas Adomavicius, cofundador y presidente de Devbridge, una consultoría global de productos digitales.

El software sostenible está impulsado por métricas de productos, pero debe adoptarse en toda la empresa. Las métricas efectivas brindan un punto de comparación para el negocio y cambian el comportamiento en la forma en que se toman las decisiones, explicó. La adopción organizativa de métricas proporciona una medida común entre equipos e iniciativas para impulsar decisiones de cartera más amplias.

Adomavicius tiene experiencia en el desarrollo de productos de software eficaces para varias empresas de Fortune 500. Su mantra es lograr que los desarrolladores de software comprendan la importancia de utilizar métricas correctas y precisas al desarrollar productos sostenibles.

Fundó Devbridge, una consultora de tecnología con sede en Chicago, a los 27 años y ha hecho crecer la empresa a quinientos empleados en cinco oficinas globales.

Aurimas ganó el premio “Emprendedor del año” de Ernst & Young en 2018 y ha aparecido en Entrepreneur, Raconteur, Forbes y otras publicaciones. Es el autor de “La fuente secreta: la cultura, las habilidades y el proceso para fabricar excelentes productos digitales”.

TechNewsWorld habló con Adomavicius para seguir el concepto de cómo los desarrolladores de software pueden poner en práctica métricas significativas.

TechNewsWorld: ¿Cómo ha cambiado la pandemia la percepción o el uso de las métricas de productos?

Aurimas Adomavicius: La pregunta puede ser más sobre el crecimiento o las métricas como indicador. No sé si algo realmente ha cambiado drásticamente, con la excepción de que durante la pandemia muchas organizaciones se dieron cuenta muy rápidamente de las brechas en su implementación. La mayoría de esas brechas realmente se relacionan con el autoservicio para los clientes y la habilitación de la experiencia del cliente.

Entonces, ¿la pandemia no tuvo influencia en el desarrollo de software?

Adomavicius: Para los trabajadores internos, hubo una gran brecha porque en el momento en que las personas fueron enviadas a trabajar desde casa, muchas empresas se dieron cuenta de que gran parte de la tecnología de apoyo que tienen para el software de productos, en muchos sentidos, se queda corta para permitir una fuerza de trabajo distribuida. Ahora que la mayoría de la gente regresa. Supongo que las condiciones están volviendo a la normalidad.

¿Cómo afectó este cambio a la industria del software?

Adomavicius: La mayoría de los servicios se llevan a cabo en línea, a diferencia de las personas que utilizan ubicaciones físicas. Las empresas necesitaban acelerar la forma en que construyen las tecnologías y el software.

Hemos visto un crecimiento comercial de más del 30 por ciento durante 2020. En ese mismo vector en 2021, crecerá a un ritmo bastante rápido. Creo que va a seguir subiendo. La pandemia ha acelerado la forma en que las empresas están creando las herramientas necesarias, sus empleados, así como el software y las experiencias.

Entonces, desde el punto de vista de un desarrollador de software, los desarrolladores deben estar atentos cuando hablamos de métricas. Realmente tenemos que pensar en eso.

¿Cómo influyen exactamente las métricas en la implementación del software?

Adomavicius: Primero, necesitamos establecer qué es una buena métrica. Por lo general, los cuantificamos en el contexto de que sean específicos, medibles y alcanzables. Por lo tanto, esas tres condiciones deben estar presentes para cualquier conjunto de métricas.

Con métricas y métricas de productos, realmente no queremos incluir solo a los desarrolladores. El desarrollo de productos es una combinación de roles. Tienes el desarrollo de software en sí. Con los desarrolladores de software, también tiene diseñadores de productos y gerentes de productos. Por lo general, los tres tipos diferentes forman equipos de productos multifuncionales. Realmente necesita cubrir un amplio espectro de cosas que importan en un producto, por lo que los tres conjuntos son las tres grandes categorías.

¿Cómo se interrelacionan esos conjuntos de métricas?

Adomavicius: Hay métricas de gastos de productos y métricas de entrega. La idea es que las métricas de calidad miren la calidad de la sostenibilidad del producto. Las métricas de producto analizan los objetivos y resultados comerciales que se supone que debe impulsar el producto. Por ejemplo, si tiene una pieza de software que se utiliza para la programación y el envío, su empresa en torno a ese producto de software debería poder programar en un día determinado, con tendencias a lo largo del tiempo, etc.

Aurimas Adomavicius, cofundador y presidente de Devbridge

Aurimas Adomavicius

Las métricas de calidad pueden ser cualquier cosa, desde monitorear defectos en busca de defectos aceptables hasta defectos severos. La calidad es más que simplemente rascar la superficie. Con las métricas de entrega, observa el éxito de utilizar una metodología de entrega ágil.

Las métricas pueden considerar factores como la velocidad y el consumo, o el estado de la acumulación, y muchos otros. Cuando miramos el desarrollo de software en general, debemos establecer un conjunto de métricas para cualquier producto o equipo de producto dado.

Examinamos esas tres categorías y luego monitoreamos las que son más importantes para un producto en particular.

¿Alguna de las categorías es más importante para la adopción exitosa del proyecto de software?

Adomavicius: Las métricas de productos son probablemente la opción más cercana o buena. Una de las métricas de su producto podría ser algo así como usuarios simultáneos en el sistema que utilizan activamente un producto a lo largo del tiempo. Las tasas de adopción podrían ser una de las métricas de su producto. Pero debemos mirarlos de manera integral. Siempre nos gusta verlo como un marco de métricas.

Tener el conjunto de métricas adecuado para el equipo de producto es muy importante. La adopción debe formar parte del sistema métrico. Eso permitirá al equipo realizar y observar esas métricas mientras diseñan el producto y piensan en las características que son más beneficiosas.

A menudo se habla del papel de los prejuicios personales que pueden afectar lo que sucede con el desarrollo de software. Explique esa noción.

Adomavicius: Con el sesgo en general, cada persona está sesgada. Cuando pensamos en productos, es muy probable que tengamos múltiples audiencias para decir cuál será el producto. Por ejemplo, las empresas de desarrollo de software tratan con personas mayores, partes interesadas y ejecutivos. Se mezclan en las sesiones de planificación aportando sus perspectivas sobre lo que debe ser el producto.

Parte de esta perspectiva se basa en comentarios anecdóticos que se recopilan en la primera línea del negocio. Parte de ella se basa en la conciencia histórica de la industria. Pero el desafío es que cuando los ejecutivos o las partes interesadas vienen a ayudar, muestran sesgos que se basan en la perspectiva que tienen en los negocios.

Un buen ejemplo sería cuando una parte interesada senior está realmente entusiasmada con una noción de producto que refleja una perspectiva sesgada que pide una característica particularmente crítica. Tener analíticas de productos integradas en el software a medida que sale al mercado puede evaluar muy rápidamente qué tan importante es esa característica en particular para los clientes.

En respuesta, puede proporcionar una vista previa de una función, sin desarrollar necesariamente esa función, y luego evaluar el interés del cliente en utilizar esa función antes de que se comprometa la inversión.

Son posibles muchos tipos de pruebas para probar la participación de sesgos. O los desarrolladores pueden estructurar los análisis de productos que se implementan para guiar e informar al equipo sobre los elementos que deben perfeccionarse.

Usamos análisis de refinamiento continuo. Este proceso debería ocurrir de forma perpetua.

¿Esta consultoría de software que está proporcionando es parte de una nueva tendencia?

Adomavicius: Creo que históricamente el software fue creado por ingenieros. Es un campo técnico. Fue creado por ingenieros. A menudo, cuando se lanza el software, queda expuesto a puntos de fricción en los que el software está diseñado desde la perspectiva de un ingeniero, pero no desde la perspectiva de un usuario.

Esta industria ha comenzado a alejarse de la puramente impulsada por la ingeniería. El desarrollo de software en un producto puede haber estado ocurriendo durante los últimos siete u ocho años.

Lo que está sucediendo con la forma en que se construye una pieza de software implica el uso de esta metodología de métricas donde el producto está en el centro y los comentarios de los usuarios son el núcleo del equipo. A este enfoque lo llamamos bucle de construcción, medición y aprendizaje.

A medida que el enfoque de métricas significativas comenzó a ganar impulso, la metodología está obteniendo más reconocimiento en la industria. Algunas de las empresas más grandes del mundo como Netflix y muchas otras están utilizando este tipo de metodología centrada en el producto. La necesidad de estos servicios ha crecido de forma espectacular. Así que realmente está acercando mucho más la tecnología al redil.

Dejando a un lado la pandemia, ¿qué factores están afectando el desarrollo de software hoy en día que no existían hasta la transformación digital?

Adomavicius: Cosas como el análisis predictivo y la inteligencia artificial, los macrodatos y las capacidades de aprendizaje automático permitieron el reconocimiento de la necesidad de un cambio en el desarrollo de software.

Los productos que se utilizan para ejecutar corporaciones son piezas de software heredadas increíblemente obsoletas. El software obsoleto está escrito en lenguajes que ya no admiten vulnerabilidades. El resultado es un aumento de los ataques de piratería y las violaciones de seguridad.

Este tipo de desarrollo centrado en el producto se puede aplicar para resolver mucho de eso en estas organizaciones. Con suerte, eso permitirá que estas empresas se vuelvan más ágiles y hagan más trabajo. Los equipos pueden ser mucho más eficaces gracias a la tecnología mejorada. O los equipos pueden tomar decisiones más rápido con menos errores e incluso hacer que su trabajo sea más agradable.

¿Este concepto de métricas significativas funciona igualmente bien con los desarrolladores de productos patentados y de código abierto?

Adomavicius: Realmente no importa porque el código abierto versus el propietario sigue siendo tecnología de software. Quizás los desarrolladores usen diferentes lenguajes o marcos. Esas cosas realmente no cambian por qué esto debe suceder o cómo nos aventuramos y administramos esos negocios.

Realmente no importa si la propiedad intelectual está incorporada en el producto o si los marcos o lenguajes de codificación subyacentes son de código abierto o no. Si observa la industria, verá Java o .Net. La mayoría de esos marcos han sido de código abierto. Realmente se trata de los resultados que se pueden generar para las empresas.



Jack M. Germain ha sido reportero de ECT News Network desde 2003. Sus principales áreas de enfoque son TI empresarial, Linux y tecnologías de código abierto. Es un crítico estimado de distribuciones de Linux y otro software de código abierto. Además, Jack cubre ampliamente la tecnología empresarial y los problemas de privacidad, así como los desarrollos en el comercio electrónico y la electrónica de consumo. Envíe un correo electrónico a Jack.

.



Source link