BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Negócios e engenharia de software: contabilidade de produção e a teoria das restrições

por Michael Stal , traduzido por Vitor Puente em 16 Out 2012 |

No post "Teoria das Restrições e Engenharia de Software", Steve Tendon explica porque se deve preferir a contabilidade de produção (throughput) no lugar da contabilidade de custos, nas organizações de desenvolvimento de software. Também disponibiliza um modelo simples para contabilidade de produção que pode ser aplicado à engenharia de software.

Dentre as diversas responsabilidades de um arquiteto de software, tais como elaborar a arquitetura de um software, deve-se adicionar a responsabilidade de manter o foco no negócio. Os arquitetos devem considerar os aspectos estratégicos do negócio dos clientes em suas decisões arquiteturais; do contrário, pode-se acabar criando um sistema desalinhado com os objetivos do negócio. O post de Tendon, consultor especializado no gerenciamento em engenharia de software, fornece uma proposta para avaliar o valor do negócio baseado na contabilidade de produção em vez da contabilidade de custos.

Como modelo para sua proposta, o autor utiliza como exemplo a Teoria das Restrições (do inglês "Theory of Constraints" ou ToC) com sua perspectiva de que "uma corrente não é mais forte do que seu elo mais fraco".

A Teoria das Restrições considera qualquer negócio como um sistema que transforma entradas em saídas. As saídas são produtos ou serviços com um determinado valor pago pelos clientes.

O princípio chave da Teoria das Restrições é que sempre há um passo em um processo de produção que limita todo o fluxo de trabalho. Essa entidade é chamada de CCR, do inglês Capacity Constrained Resource (recurso restringido pela capacidade).

De acordo com Tendon, o CCR é geralmente indicado em cadeias de tarefas em processos e estoques. Na engenharia de software, uma unidade de estoque pode ser um caso de uso no RUP (Rational Unified Process), uma história no XP, ou um item do backlog no Scrum. Para otimizar o CCR, a ToC propõe um modelo, chamado de "os cinco passos para o foco", o qual, de acordo com a Wikipedia, inclui:

  1. Identificar as restrições de um sistema, ou seja, o que impede a empresa de produzir mais numa determinada unidade de tempo;
  1. Decidir como explorar as restrições do sistema - como reduzir ao máximo a restrição;
  2. Alinhar tudo com base na decisão acima - alinhar todo o sistema ou a empresa para dar suporte às decisões realizadas nos passos anteriores;
  3. Realizar um levantamento das restrições do sistema - aplicar mudanças maiores necessárias para eliminar as restrições;
  4. Cuidado! Se durante este processo uma restrição for quebrada, volte para o passo 1 - mas não se deve permitir que a inércia cause uma nova restrição no sistema.

Depois de apresentar o modelo ToC, Tendon explica o conceito de contabilidade de produção (do inglês Throughput Accounting, TA) o qual é definido por três fórmulas:

Produção:

  • P = Receitas - Gastos Variáveis Totais

Lucro Líquido:

  • LL = Produção - Gastos Operacionais

Retorno sobre Investimento:

  • ROI = Lucro Líquido / Investimento

Adaptando-se para engenharia de software:

  • Produção (P): é o caixa gerado através da entrega de código em produção, calculada como Preço de Venda subtraído do Custos Diretos - como empacotamento, entrega, instalação, treinamento, suporte e rede.
  • Investimento (I): é todo o dinheiro investido na produção de sistemas, somado ao dinheiro gasto na obtenção de ideias para funcionalidadas que têm valor para o cliente. Isso inclui ferramentas de desenvolvimento de software e o levantamento de requisitos.
  • Custos Operacionais (OE): são todo o dinheiro gasto em produzir código a partir de ideias. Está ligado diretamente ao trabalho dos engenheiros de software, porém também inclui custos com vendas, custos gerais e custos administrativos.

Esse modelo simples torna a Contabilidade de Produção (Throughput Accounting) acessível até mesmo para profissionais fora da área de contabilidade, como arquitetos de software. Enquanto muitas empresas enfatizam que é necessário reduzir custos para melhorar os negócios, a Contabilidade de Produção traz algumas considerações diferentes, como explica Tendon:

A redução de custos é limitada; já o aumento de produção é potencialmente ilimitado. O foco excessivo na redução de custos pode prejudicar a capacidade de entrega da empresa, levando assim a uma diminuição da produção, o que pode levar a consequências devastadoras.

Em seu post, Tendon demonstra três exemplos de como utilizar o método da contabilidade de produção.

  • Uma maneira de reduzir os custos operacionais na contabilidade de ganhos seria discartar os requisitos antes da implementação. Cada requisito eliminado reduz o custo operacional e aumenta o lucro líquido;
  • A adoção de softwares open source contribui para a redução dos custos com investimento, porém eleva o custo operacional. No entanto, o aumento do custo operacional será menor se comparado com a construção do mesmo sistema;
  • Quando for escolhido um nicho do mercado, uma empresa de software deve aumentar o preço unitário, ofertando funcionalidades únicas para tal mercado.

Tendon explica que a contabilidade de produção não é somente mais um modelo de contabilidade para engenheiros de software, mas sim uma alternativa para a contabilidade baseada em custos, cujo foco é a redução dos custos operacionais. No final do seu post, o autor explica que a contabilidade de produção afeta outros processos, tais como o rotatividade de funcionários e a contratação, assim como restrições de cronograma, orçamento, recursos e escopo. Ele conclui:

A contabilidade de produção pode ser utilizada para auxiliar na tomada de decisões em qualquer processo de negócio, incluindo contratação, terceirização, escolha de metodologia, dentre outros. Basta criar um relação entre cada decisão e os fatores de Produção, Custo Operacional e Investimento, para que seja possível tomar um decisão mais segura.

Alguns leitores comentaram sobre o post no blog. Dave Nicolette, embora elogie o artigo, não concorda com o tratamento dos pontos de histórias de usuários (story points):

Tenho que discordar da prática de associar story points com o valor de renda estimado. IME story points são baseados no nível de esforço, já o valor estimado é ortogonal ao nível de esforço. Prefiro utilizar Valor de Negócio Ganho (veja aqui e aqui) para rastrear a entrega do que é de valor para o cliente. É aplicável tanto para ambientes tradicionais de desenvolvimento quanto para ambientes adaptáveis. Quando vejo as pessoas rastreando tanto o escopo quanto o valor utilizando a mesma medida, é problemático. Mas sua experiência pode dizer o contrário.

Tendon respondeu a este ponto:

Associar story points com o valor da receita realmente não é a melhor abordagem; de fato, medidas relacionadas ao valor ganho [earned value] são mais apropriadas. Entretanto, no casos em que trabalhei, minha abordagem serviu para levantar dados que indicam uma ligação entre story points e números que embasam decisões gerenciais. São uma abordagem prática que oferece uma boa solução. No geral, um story point pode ser associado a um valor médio de receita.

Christian Beck indica que restriçoes nem sempre são ruins:

Em um CDS, restrições são muito utilizadas para determinar não só o volume da saída (que é difícil de definir e medir em um software), como também outros atributos importantes, como qualidade e nível de inovação. Restrições são, deliberadamente, uma parte integral do projeto de um sistema (por exemplo limites WIP, time boxes). Restrições de mudanças são uma ferramenta importante para influenciar (e não controlar) a saída.

O autor responde:

Restrições devem sim, sempre estar relacionadas com o seu objetivo. Algumas irão guiá-lo na direção certa (as boas restrições); outras serão obstáculos (as restrições ruins). É importante saber como distinguir entre as duas; também é benéfico tratar adequadamente as restrições artificiais e as deliberadas (como o limite WIP no Kanban).

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT