Expectativas do CFO e Desenvolvimento do Scrum

5

Quando se trata de assuntos financeiros, eu não sou bem versado. Estou tentando liderar minha organização em nosso esforço de desenvolvimento de software usando um ciclo de vida de desenvolvimento baseado em Scrum. Frequentemente sou desencorajado ao tentar treinar a liderança executiva por acreditar que o Scrum e o Agile não funcionam bem com seus objetivos financeiros. No outro dia, fui desafiado a mostrar como meus desenvolvedores de software poderiam tirar 60% de suas horas de trabalho.

Encontrei alguns artigos na web ( link ), mas não apresentou grandes argumentos.

Estou procurando conselhos ou exemplos de organizações que capitalizam os custos de software com eficiência em um ambiente de desenvolvimento ágil.

Este artigo resume a questão muito bem, mas não oferece conselhos link

    
por garrmark 24.01.2012 / 02:06
fonte

4 respostas

0

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.

    
por 31.01.2012 / 02:01
fonte
5

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 é?

    
por 24.01.2012 / 12:08
fonte
1

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).

O ponto é, nenhum CFO está realmente preocupado com o dinheiro que está sendo gasto (se houver uma justificativa devida), tanto quanto ele está preocupado que o dinheiro é desperdiçado porque no final do projeto falhar. (O artigo que você postou simplesmente ignora algumas situações simples da vida real); Se você realmente quer promover o Agile, nunca promova que vai reduzir os custos. O ponto é principalmente que

  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.

    
por 24.01.2012 / 12:44
fonte
1

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.

Além disso, se você ler as diretrizes contábeis, elas não estão definindo a viabilidade do mercado, mas a crença de que o esforço é viável depois que uma iteração completa do trabalho é feita. Bem, uma iteração pode ser facilmente considerada como uma sprint , que inclui "Para os fins desta Declaração, a viabilidade tecnológica de um produto de software é estabelecida quando a empresa concluiu todo o planejamento, projeto, codificação, e testar as atividades necessárias para estabelecer que o produto possa ser produzido para atender às suas especificações de projeto, incluindo funções, recursos e requisitos de desempenho técnico. " Depois disso tudo pode ser capitalizado, a menos que você acredite que alguma parte do projeto 'não pode ser produzida'.

(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.)

    
por 31.01.2012 / 03:49
fonte

Tags