Como você mede o valor do seu software?

Um dos princípios do ágil é que você deve medir o software em funcionamento:

O software de trabalho é a principal medida de progresso - 12 princípios do Agile

O problema é que, embora eu possa medir meu software em termos de histórias concluídas, bugs compactados ou o volume de relatórios de defeitos diminuindo, estou preocupado em saber como medir o valor do meu software.

Se eu usar Mike Cohn como exemplo e ele ajudar a SalesForce.com a fornecer 500% mais valor a seus clientes em comparação com o ano anterior * - como faço para medir esse aumento? Como faço para medir onde estou agora?

Outras métricas que ele usa são o número de recursos e o número de recursos por desenvolvedor. Isso é algo que eu poderia resolver se meu backlog estivesse em boas condições e as histórias fossem cortadas por 'recurso', mas estamos apenas começando com o Agile, por isso preciso de alguma maneira de descobrir qual é o valor que entregamos agora , use uma métrica semelhante em, digamos, seis meses, para ver se aumentamos nossa produção.

Ouvi falar em medir o valor de software por um aumento na receita ou um aumento na satisfação do cliente (como você avalia isso?), Mas esses aumentos podem ser atribuídos a qualquer coisa na empresa (vendas, contabilidade, suporte) e não diretamente para o trabalho que meu departamento está fazendo.

Então, como vocês medem o valor do seu software e como começaram?

* Sucesso com Agile - Mike Cohn

Aqui está como eu defino valor em geral (mesmo fora do desenvolvimento de software)

Você define o que é valor .

Se o valor for o valor ganho / economizado graças ao software, o valor será:

Receita - Custo de desenvolvimento = Valor

ou

Custos operacionais economizados - Custo de desenvolvimento = Valor

Pode ser virado. Você sabe quanto custou o volume de negócios na sua empresa? Se você puder mensurá-lo, a redução de 50% do seu faturamento graças ao ágil permitirá calcular o valor fornecido:

50% de redução na rotatividade = (custo da rotatividade / 2) = valor

Valor pode qualquer coisa que seja importante para você , o cara que define qual é o valor.

É por isso que o valor é avaliado em pontos no ágil. Os pontos são comparados aos da história para ajudar você a priorizar o valor. Porque você deve comparar o valor (comercial) (arbitrário) com o valor (custo) dos pontos da história.

Em muitos casos, o valor do software é medido calculando "ganhos adicionais" ou "economia de custos alcançada".

Em outros casos, onde o software é parte integrante de um sistema maior (isto é, o software que controla um carro), é mais difícil. Você mede os gastos para fazê-lo (valor = custo) ou calcula o valor de todo o sistema (ganhos adicionais / economia de custos arquivados) e aloca uma parte do if para o software (por exemplo, proporcional aos custos do software vs . custos totais)

Simplificando, você precisa descobrir qual é a diferença financeira entre tê-lo e não tê-lo.

Se um pouco de software automatiza um processo que significa que duas pessoas que trabalham em período integral não precisam mais realizar essa tarefa, isso economiza seus salários anuais (mais os custos relacionados) para a empresa. Se, em média, os vendedores venderem 10% a mais do que aqueles que não usam o novo sistema, o benefício será 10% do total de vendas para todos os vendedores que possam usar o software.

Os números podem estar imprecisos e prontos, mas a maioria das coisas pode ser quantificada o suficiente para lhe dar uma impressão útil do que esperar.

Esta é uma pergunta complicada. Não sei se gosto da métrica "recursos / desenvolvedor", porque nem todos os recursos são criados iguais. Alguns recursos são obrigatórios e roubam os clientes do seu concorrente. Alguns recursos são obscuros e podem ser usados ​​por 0,1% dos seus clientes, e eles também podem funcionar bem sem ele.

Os aumentos na receita são bons se você puder correlacioná-la facilmente a um influxo repentino de vendas / renovações do software com o momento de um novo lançamento. Além disso, se você conseguisse rastrear a conversão de usuários de produtos concorrentes para uma nova versão. A satisfação do cliente pode ser medida em termos de número de chamadas felizes (ou falta de chamadas irritadas) normalizadas para o número de clientes ou vendas. Para relacioná-las diretamente ao seu departamento, o principal pode ser o momento dessas mudanças e o tempo do software que você está lançando.

Software de trabalho é a medida. Ouça abertamente seus usuários e envolva-os no processo de desenvolvimento. Entregue regularmente as funcionalidades que eles dizem que são necessárias quando precisam. Entregue em pequenos pedaços para que os usuários sintam progresso.

Se você está apenas começando o desenvolvimento ágil ou mesmo um novo projeto ... as partes interessadas precisam ter um pouco de fé. Isso requer que o proprietário do produto articule por que o ágil é melhor do que outros processos (presumo que você pense que esteja em sua situação específica).

Se o proprietário do produto não tiver certeza de quais recursos (histórias) oferecem o valor mais relativo, será necessário sentar-se com as partes interessadas e descobrir isso. Planejar o poker é uma boa ferramenta para isso. Atribuir valor comercial relativo a cada história também ajuda na priorização, mas tenha cuidado para não falar com os contadores de bean sobre "Valor comercial ágil", não é o mesmo que ROI!

Muitas vezes, há um resultado final 'rígido' que pode ser medido facilmente para manter os contadores de feijão felizes: "O recurso X aumentou nossa receita em 150%". Mas, na maioria das vezes, é uma combinação de valores 'rígidos' e 'flexíveis' "Nossa receita aumentou 160% e achamos que podemos atribuir isso à mudança de software, já que os clientes, em média, nos deram classificações 11% mais altas com o novo recurso de interface do usuário "

É realmente difícil medir essas coisas com precisão - tente olhar o mais holisticamente possível.