Gestão 2.0 / Sem categoria

Centros de Custo

por Fabio Akita

Comente!

Toda empresa que lida com software tem sempre graves problemas de comunicação. Um deles tem a ver com a Lei de Conway. Não é exatamente uma “Lei” mas uma observação sobre design de software em organizações. Eu li sobre isso pela primeira vez anos atrás no famoso livro The Mythical Man Month, de Fred Brooks.

Conway afirma que “organizações que fazem design de software … estão restritas a produzir designs que refletem as estruturas de comunicação da empresa.”

Pior ainda, um corolário dessa lei é que “quando as estruturas sociais da organização são rígidas, elas podem ser refletidas no design do sofware, resultando em qualidade sempre ruim.” Significa que inclusive as relações interpessoais vão se manifestar no software.

De forma simplificada, se tivermos 3 departamentos responsáveis por desenvolver um mesmo software, provavelmente o resultado serão 3 sub-módulos que se integrarão no mesmo software. Se forem 5 departamentos, o software terá 5 sub-módulos.

Mesmo em uma única equipe tradicional, se tiver 4 programadores, possivelmente teremos 4 sub-sistemas ou um design em 4 partes onde cada um fez uma parte.

Isso é ainda pior porque a maioria das corporações que consomem TI não tem software como negócio principal. Por exemplo, manufaturas, lojas, fábricas, todas apenas consomem software para reduzir custos, otimizar processos, automatizar procedimentos. As grandes até tem departamentos internos de desenvolvimento de software, mas elas são vistas não como real investimento e sim como custo. E como todo custo, a meta é sempre diminuí-los.

Centros de Custo

Falei um pouco sobre isso no meu artigo anterior Fábrica de Software é uma Besteira justamente porque um dos motivadores para fábricas de software é apenas diminuir custos, sem entender que não existe almoço grátis: pense apenas em diminuir custos via mão de obra barata e necessariamente a qualidade vai diminuir exponencialmente.

A questão principal nessas organizações é que todo departamento é tratado principalmente como Centro de Custo. Esse tipo de mecanismo existe para saber onde os custos da empresa estão indo. O mecanismo em si não é o problema, mas sim seu uso. Quando você tem um centro de custo de marketing e outro de RH, não é difícil ratear os custos porque os recursos de um não são reaproveitados trivialmente pelo outro.

Porém, se você tem múltiplos departamentos de software e cada um tem seu centro de custo separado, prepare-se para grandes dores de cabeça e enormes desperdícios. Departamentos que tem recursos compartilhados tem sérios problemas se uma das diretrizes principais é a gestão dos custos. Software é volátil, abstrato, não é um material estocável. Se um departamento precisa do conhecimento do funcionário que está em outro departamento, não é fácil remanejá-los, porque ele faz parte de uma hierarquia, é representado como um recurso e o custo do seu salário está no centro de um departamento. Emprestá-lo é como emprestar dinheiro sem ter retorno direto, porque o salário continua saindo de um centro e não do outro a menos que ele mude de gerência e passe para a hierarquia do outro departamento. Mas se você só precisa dele temporariamente, como algumas semanas, esse tipo de burocracia garante que o conhecimento de um departamento não será reutilizado em outro.

Mais ainda: muitos softwares usam partes que são naturalmente reusáveis. Se um departamento faz essa parte, os outros poderiam se aproveitar dela. Mas o custo saiu de um departamento e não é trivialmente rateável entre os outros. Cria-se mais um problema burocrático: de quem deve ser o investimento pelo reuso? Para isso, criam-se mais gambiarras para essa gambiarra pré-existente: cria-se um Departamento separado de Reuso, um absurdo! Reuso não é sempre planejável, e os melhores componentes na realidade emergem de um sistema onde eles não eram previstos. Crie um departamento para cada coisa reusável da empresa e rapidamente você terá software com qualidade decrescente.

E isso se a empresa tem algum tipo de preocupação mínima em tirar o máximo de seu investimento inicial. Outra coisa que representa enorme desperdício é quando o software feito por um departamento é deliberadamente duplicado por outro. Esse tipo de organização hierárquica baseada em departamentos e centros garante que cada um quer ter controle total sobre seus recursos. Cansei de ver, em inúmeras empresas, um departamento preferir reescrever ou comprar um software que já existia na empresa porque caso contrário ela não teria o controle desejado. Você é dono de uma empresa onde se desenvolve software internamente? Comece a procurar, você vai facilmente encontrar diversos sub-sistemas duplicados que fazem a mesma coisa mas que seu gerente preferiu reescrever, aumentando seus custos totais e desperdiçando investimento que já foi feito.

Olá, mundo!

por gestao20

2 Comentários

Olá pessoal!

Como é meu primeiro post, acho que vale a pena me apresentar. Meu nome é Fabio Akita, sou gerente de projetos e desenvolvedor. Estou atualmente envolvido com as comunidades de Ruby on Rails (tecnologia de desenvolvimento de aplicações Web) e Agile (filosofia de gerenciamento de projetos de software).

Sou conhecido pelo meu blog pessoal www.akitaonrails.com, que convido a todos visitarem e verem meus posts mais antigos.