Expectativas do CFO e Desenvolvimento do Scrum

Depois de ter uma interessante conversa no Twitter com Berry Hawkins ( link ) eu acho que tenho a minha resposta.

O problema é que eu ainda estava pensando que precisava que meus desenvolvedores levassem em conta o tempo gasto na criação de software como uma despesa.

A solução é verificar se a atividade é antes de depois que o produto ou recurso é considerado viável. Qualquer atividade, independentemente de ser design, desenvolvimento ou teste, pode ser capitalizada desde que seja passada a etapa de pesquisa.

Eu escrevi algumas novas diretrizes e as incluí no meu CFO para revisão (dedos cruzados). O teste real serão os auditores, mas acho que conseguir o CFO a bordo é o primeiro passo. Obrigado por todos os seus comentários.

Este não deve ser seu problema .

A capitalização de custos é o problema de seu CFO e / ou contador. As regras variam em diferentes jurisdições. Os responsáveis pela contabilidade são especialistas e devem capitalizar os custos de acordo com as regras contábeis relevantes.

No máximo, eles podem precisar pedir algumas informações de suporte (por exemplo, das 5.000 horas de desenvolvedor trabalhadas neste trimestre, você pode estimar que% foi em desenvolvimento de novo software ou aprimoramento de ativos de software existentes?). Mas cabe a eles fazer a pergunta certa.

Se você está desenvolvendo principalmente um novo software em um produto que sua empresa vende ou pretende vender (ou seja, o produto conta como um ativo intangível que retorna benefícios econômicos futuros), é perfeitamente possível capitalizar 100% dos custos de desenvolvimento. Além disso, alguns países têm incentivos especiais para investimentos em P & D, o que é possível para o seu trabalho de desenvolvimento de software.

A metodologia de desenvolvimento de software que você usa é irrelevante, a única coisa que provavelmente importará é ter alguma maneira de categorizar quais custos foram gastos em projetos ou ativos capitalizáveis. Mas o mesmo problema se aplica ao desenvolvimento em cascata!

Mas pelo amor de Deus, deixe os contadores resolverem tudo isso. Você não espera que o CFO escreva código, não é?

Eu li o link que você postou. É básico e cheio de suposições! Se você tem que defendê-lo realmente, azar!

No entanto, eu diria, convencer o CFO não deveria ser difícil (uma vez que você sabe o que importa).

1. reduz o risco: garantirá que você não terá que cancelar todo o material! Se você tiver que fazer isso - você garantirá que com o Agile / Scrum você perceberia isso muito antes de outros métodos.

2. reduz o risco de esperar para chegar ao mercado (e começar a receita) muito antes de aguardar a conclusão do registro inteiro.

3. reduz o risco de criar o projeto errado!

Isto é verdade com qualquer método iterativo e não apenas Agile / Scrum. O que você realmente precisa mostrar não é que Agile é melhor feito; mas como as coisas são horríveis quando os projetos falham. (Eu acho que é aí que explicar o CFO é ainda melhor do que o TI porque eles começam a defender as coisas imediatamente!).

Em geral, se a organização (e especialmente os líderes) está sintonizada com tais filosofias (como o waterfall), provavelmente é uma má ideia vender-por-promessa . É melhor demonstrar-fazendo-lo . Comece pequeno onde você tem um controle confortável. E provavelmente a primeira tentativa que eu farei é questionar - por que começar com tantos recursos? Vamos dividi-los em 10 lançamentos! Em seguida, quem impede você de atender os clientes? Passo a passo, comece a aderir algumas partes do Ágil sem fazer rituais explicitamente anunciados. Uma vez que você for bem-sucedido, as pessoas perceberão o que o Agile trará a bordo.

Quando você faz recomendações específicas, (em vez de filosofia) as pessoas tendem a ouvir muito melhor.

Você está deixando de fora muitas informações e, como resultado, acho que você não é uma empresa de consultoria; já que nesse caso, na minha opinião, todas as horas que todos faturáveis podem ser capitalizados.

Ok, honestamente, o que o CFO quer ouvir é um bom argumento para o motivo pelo qual uma enorme porcentagem das horas não são de P & D e D - e, tanto quanto eu sou capaz de dizer ter o número 86 do FASB é a única regra que importa; Embora eu recomendo a leitura do documento real , e documento real , e documento real st / summary / stsum86.shtml "> não o resumo .

De acordo com o meu conhecimento, as únicas horas que sempre seriam categorizadas como P & D no Scrum são durante picos, todas as outras horas 'podem' ser consideradas não R & D horas na minha opinião; ou seja, Scrum é apenas fazer o que é viável.

(Por último, eu não sou um CPA, e provavelmente ninguém mais está aqui também - e mesmo se eles estivessem, seguir o conselho da internet para práticas contábeis é o que é. Se você não está feliz com as respostas, então honestamente, eu sugeriria à empresa contratar uma terceira parte, responsabilizá-la por sua opinião e acabar com isso.)