Estratexia

Mesmo ao tomar e medir datos, as persoas seguen sendo un compoñente chave da estratexia de aplicación das métricas e no impulso de cambio baseado neses datos. As métricas que levan a unha mellora do proceso ou a un cambio motivacional son necesarias para ser entendidas e aprobadas por aqueles dos que se vai facer un seguimento. E non hai que medilo todo, senón centrarse en áreas específicas do traballo dos/as desenvolvedores/as que axuden a entender se está a funcionar.

Ademais disto, a estratexia de métricas está directamente ligada ao propósito xeral da actualización do proceso. De cando en vez, as organizacións actualizan os seus obxectivos e eses obxectivos obrigan a facer un cambio nas métricas empregadas para analizar canto lle falta á organización para acadalos.

Así, hai dous compoñentes principais neste proceso: obxectivos e persoas. E os/as desenvolvedores/as deben estar aliñados/as cos obxectivos da organización para transitar o mesmo camiño cara ao éxito.

Desenvolvedores/as e mandos intermedios deben formar parte do proceso para comprender cales son as métricas útiles, axudar a rexeitar as fútiles e mellorar o ciclo de métricas. Isto tamén permitirá introducir un ciclo de desenvolvemento baseado en datos e permitirá que os/as desenvolvedores/as se sintan cómodos/as cando o usen.

Para o uso de métricas en InnerSource, xa definiramos os seguintes propósitos:

• Concienciación: Ser coñecedores/as do traballo en curso.

• Mellora do proceso: Detectar problemas e comprender as súas causas raíz (buscar os puntos de conxestión do proceso actual).

• Motivación: Deixar que o equipo de desenvolvemento participe do seguimento (por exemplo, fomentando novas contribucións a un novo proxecto).

Unha forma habitual de aplicar unha nova metodoloxía consiste en seguir o PDCA (polas súas siglas en inglés, Planificar-Facer-Comprobar-Actuar) para unha mellora continua. Os pasos «Planificar» e «Comprobar» serán os máis relevantes para este capítulo de métricas, mentres que os outros dous estarán presentes na aplicación de melloras no proceso («Facer») e na toma de decisións («Actuar»).

As accións de planificación consisten en comprender a situación actual do proceso dentro da organización. Para iso, e desde o punto de vista das métricas, é necesario recadar información cualitativa e cuantitativa. Cuantitativa, no sentido de medir o que está a suceder no equipo de desenvolvemento actual e comprender como desenvolvedores/as e mandos intermedios usan a infraestrutura e interactúan entre si. Así poderá botarse unha primeira ollada á situación do proxecto nun momento determinado.

En canto aos datos cualitativos, tamén será necesaria a retroalimentación do equipo de desenvolvemento e dos/as cargos superiores, xa que comprenden como funciona realmente o proceso actual. Cabe esperar que isto solucione as cuestións que non acada o enfoque cuantitativo e permita comprender se, desde o punto de vista da dirección, as métricas son útiles para o seu traballo ou non o son en absoluto.

Por último, é preciso definir os obxectivos, preguntas e métricas que axudarán a entender a contía da mellora á hora de aplicar novas políticas no proceso de desenvolvemento de software e noutras áreas. Esas métricas tamén se poden vincular a algunhas accións, como alertas cando o proceso do software non evoluciona como se esperaba. E esas alertas deberían rematar en accións ou decisións no paso de «Actuar».

En resumo; a retroalimentación cualitativa e cuantitativa, a definición de obxectivos e preguntas para medir o seu éxito que se comprobarán con posterioridade e, no momento de iniciar este proceso, facer un seguimento da situación do proxecto.

Unha vez que se definen as métricas e os KPI, o paso «Facer» levará algunhas semanas ou meses de traballo nos que os/as desenvolvedores/as traballarán nunha determinada situación con algunhas condicións específicas. O paso de «Comprobar» permitirá determinar se este proceso tivo o éxito suficiente, en función dos obxectivos orixinais definidos no paso «Planificar». Poderiamos ter mellorado o rendemento do modelo de desenvolvemento, pero se o obxectivo deste ciclo fose atraer máis desenvolvedores/as, fallariamos.

Ademais, a aplicación de diferentes políticas ou accións pode levarse a cabo de forma paralela e con diferentes proxectos. Poñamos o exemplo da selección dun novo modelo de gobernación para tres proxectos InnerSource diferentes: ditador/a benévolo/a, meritocracia pura na que os/as desenvolvedores/as poden traballar por si mesmos/as e un modelo mixto de meritocracia no que se guía aos/ás desenvolvedores/as no tipo de tarefas nas que poden traballar.

Isto pode axudar a seguir un proceso de proba do modelo de goberno a pequena escala, de xeito que aquel con máis éxito poida exportarse posteriormente a outros. Esta proba A/B permite determinar o mellor modelo de goberno en determinadas circunstancias. E contar coa retroalimentación cualitativa e cuantitativa das persoas implicadas no proceso, e das fontes de datos que empregaron, proporciona unha valiosa perspectiva sobre o rendemento dos varios modelos.