domingo, 27 de maio de 2012

Outsourcing Possível


Participando de um GT de outsourcing, um colega de batalha de alguns anos me pergunta qual minha opinião sobre uma forma efetiva de uma empresa pública terceirizar desenvolvimento de software. Pra mim não há muitas alternativas, até porque já se tentou de quase tudo, sem sucesso.

Primeiramente, descartamos o bodyshop. Para os incautos, trata-se da contratação de serviços em que a remuneração se dá por hora-homem, ou seja, ela é completamente desatrelada de qualquer entrega, razão pela qual é ilegal (TCU), imoral e engorda (no caso, o caixa da terceirizada).

Portanto, o modelo a ser adotado é o de Fábrica, com a métrica adequada àquilo que se quer contratar (ex: APF), com fatores de ajustes para atender às especificidades da organização. E o ideal é a contratação de pacotes significativamente grandes, de forma a diluir os custos de controle. 

Bom, até aqui nenhuma novidade. Mas o ponto central começa com algo que postei em outro texto, que é a redução contínua do delay entre o surgimento da necessidade do negócio e sua implantação. E mais. Digamos que esse delay seja de trinta dias. Hipoteticamente, somente após uns vinte dias é que as regras efetivamente se materializam (se é que se materializam), de forma que não há como se explicitar formal e tempestivamente isso numa encomenda terceirizada.

Assim é que, na prática, um modelo possível seria uma especificação superficial por parte da contratante de forma a permitir, num primeiro momento: uma medição indicativa; uma previsão orçamentária; e uma estimativa de esforço/prazo.

A partir daí, um funcionário da contratante compõe uma célula de desenvolvimento com a equipe disponibilizada pela contratada, ao tempo em que se busca uma maior consolidação da demanda, de forma que, ao final do serviço, seja possível medir e remunerar a empresa pelo produto entregue, de acordo com as condições pactuadas.

Eu sei, não é lá um modelo muito redondo, e há alguns aspectos questionáveis, mas não há muito como fugir disso.

Infelizmente.    

terça-feira, 22 de maio de 2012

Em Busca do Equilíbrio­




Na TI de hoje, especialmente para uma empresa com as características de um grande banco, o negócio não pode esperar. Portanto, é natural que o  desenvolvimento de software trabalhe quase sempre com prazos exíguos.

Nesse contexto, qualquer processo declarado, por mais enxuto que seja, é visto como um transtorno. Num cenário de restrição extrema, o único artefato indispensável tende a ser o código em si, o sistema.

A área de TI deve perseguir obstinadamente o objetivo de entregar tempestivamente, mas com qualidade, a solução que permita à empresa realizar negócios.

Para tanto, é imperioso racionalizar os processos. A base acadêmica é importantíssima, mas ela deve ser adaptada às especificidades de cada organização.

Outro aspecto relevante é a retroalimentação dos processos, por parte de quem os executa. Por mais competente que seja a área normatizadora, nem sempre aquilo que ela declara se mostra efetivo ao ser aplicado à realidade, e é aí que o feedback se faz necessário. 

O mais importante é nunca perdermos de vista que processos, padrões e artefatos não são um fim em si mesmo, mas devem sempre estar a serviço de um objetivo maior. Mas precisamos pensar a TI além do cenário de curto prazo.

Para perpetuarmos nossa área, faz-se necessário reter conhecimento e construir sistemas robustos, estáveis, com documentação necessária e suficiente. Nem mais nem menos.

A documentação de um sistema é útil se ela espelha fielmente sua arquitetura e funcionalidades, além de poder ser efetivamente reusada em intervenções futuras.   

Um ambiente produtivo estável libera mão-de-obra de manutenção para o atendimento de novas demandas, aumentando a agilidade e a própria imagem da TI junto à organização. Precisamos encontrar o ponto de equilíbrio entre entrega e controle. Esse é o nosso desafio.

Parece óbvio, e é. Mas não é fácil.