FATTO Consultoria e Sistema

www.fattocs.com.br

OUTSOURCING NO DESENVOLVIMENTO E MANUTENO DE

SOFTWARE
Como gerir sem supervisionar?

OUTSOURCING NO
DESENVOLVIMENTO E
MANUTENO DE SOFTWARE

Outsourcing no desenvolvimento e manuteno de software:

Como gerir sem supervisionar?
Introduo
Recentemente, tive contato com uma solicitao de proposta para servios de
desenvolvimento e manuteno de sistemas em regime de fbrica de software para o governo
federal. Ela estabelece como critrio para penalizao da contratada: Quando for identificada
ausncia de profissional da contratada que venha a comprometer a qualidade do servio, o
fato ser devidamente comunicado contratada. Se ocorrer essa comunicao, ser
considerada uma avaliao insatisfatria para cada ocorrncia..
Neste ponto entra em cena a importncia da definio do que seja interno ou externo gesto
da contratada. Isso porque um processo maduro de gesto de contratos prev que no haja
exigncias que constituam interveno indevida do cliente na gesto interna da contratada.
Alguns pontos podem ser destacados como referncias no estabelecimento dessa fronteira,
entre eles: a) o estabelecimento de vnculo de subordinao com os funcionrios dos
fornecedores; b) o estabelecimento da remunerao dos funcionrios dos fornecedores; e c) a
indicao de pessoas para compor o quadro funcional do fornecedor.
Observe que em todos os itens a mobilizao de profissionais responsveis pela conduo dos
servios contratados uma gesto exclusiva da contratada e no exemplo que citamos a
organizao cliente invade esse espao. Por que isso prejudicial gesto do contrato?
Porque mascara por meio de mecanismos de superviso a falta de definio de critrios
monitoramento do que interessa: Os reais objetivos de medio e anlise. O nome que se d a
esses mecanismos Acordo de Nvel de Servio ou Service Level Agreement (SLA). Eles
permitem a gesto do contrato pela avaliao dos aspectos externos aos processos de
desenvolvimento e manuteno de sistemas e que agregam valor ao negcio.

Qual o problema e onde est a sua raiz?

As primeiras iniciativas com o modelo de fbrica de software, pela prpria imaturidade da

comunidade usuria de servios de software, sofreram com uma baixssima qualidade nesses
produtos entregues e os Acordos de Nvel de Servio se apresentam como instrumentos
www.fattocs.com.br

Pgina

O modelo de fbrica de software e a definio de uma unidade de produto (eminentemente o

ponto de funo ou alguma unidade de medio de software derivada dele) comeam a mudar
esse paradigma, mas como pode ser visto na introduo deste artigo, ainda hoje h resistncia
na assimilao do modelo em que no se compra a disponibilidade, mas um produto entregue.

Principalmente entre o final da dcada de 1980 e meados do incio do Sculo XXI, se tornou
muito comum o estabelecimento de relaes de superviso nos contratos de desenvolvimento
e manuteno de sistemas. Isso implica em no haver um produto em especial sendo gerado
pelo contrato, mas sim a contratao de Mo de Obra Contratada (MOC) onde o que se
adquire a disponibilidade do profissional. Expediente bastante similar aquele que se pratica
ao contratar um empregado, contudo, sem muitas das responsabilidades advindas disso e no
nossa inteno discorrer sobre as diversas repercusses administrativas, previdencirias e
jurdicas desse expediente no mdio ou longo prazo.

fundamentais nesse novo modelo de gesto. Coloco novo entre aspas pelo novo ser no
mbito dos servios de software, sendo ele resultado da diviso do trabalho que norteia
praticamente toda a produo em nossa civilizao contempornea com uma orientao para
a diviso do trabalho.
So trs as principais dimenses que devem ser cobertas pelos SLA:
a)

Prazo;

b)

Capacidade; e

c)

Qualidade.

Onde est o Esforo e a Produtividade nessa lista?

Quando se trabalha com um modelo de superviso, uma das mais importantes dimenses da
produo o esforo e a sua adequada aplicao visando aumentar a produtividade. No
modelo de contratao em que h uma unidade de medio de produto (como o ponto de
funo) a produtividade est capturada no preo cobrado pelo ponto de funo. No cabe ao
contratante supervisionar como os homens-hora sero utilizados. Ele no ser cobrado em
funo do esforo, mas sim da produo. interesse natural de o contratado usar a menor
quantidade de recursos na produo e atendimento das demandas do cliente.
Recomendo que um princpio seja observado: Que haja uma relao entre a unidade de
medio usada e o esforo despendido no servio. Por exemplo, usar o ponto de funo como
definido pelo Grupo Internacional de Usurios de Pontos de Funo (IFPUG) quando o contrato
envolve desenvolvimento e manuteno de sistemas implica que os lucros auferidos em
demandas de manuteno paguem o prejuzo verificado em demandas de desenvolvimento.
Isso assumindo que haja um equilbrio nas finanas do contrato. Para evitar esse fenmeno,
usar os pontos de funo de melhoria como definidos pela Associao de Medio e Anlise de
Software da Holanda (NESMA) ou uma simplificao do mesmo uma boa alternativa. Em
nosso mercado, esse expediente normalmente chamado de deflator que aplicado aos
pontos de funo apurados em funes excludas ou alteradas em uma manuteno. Por
exemplo, uma determinada tela ao ser alterada pontua 31 PF, com o uso de um fator de 50%
como deflator em funes alteradas, so considerados apenas 15,5 PF equivalentes.

Qual o foco habitual do primeiro objetivo de medio: Prazo

Hoje existem as seguintes correntes para planejar e monitorar o prazo:

www.fattocs.com.br

Pgina

O prazo um aspecto externo ao processo de desenvolvimento e manuteno de software e o

estabelecimento de metas de prazo pr-estabelecidas em funo (no necessariamente uma
simples proporcionalidade) do tamanho da demanda um dos instrumentos que visam
substituir a funo de superviso de pessoas na gesto das demandas de desenvolvimento e
manuteno de software.

Software hoje est relacionado no mais apenas ao suporte do negcio, crescente o papel
em que o software desempenha sendo a essncia do prprio negcio. Um dos fatores crticos
de sucesso em qualquer negcio a tempestividade no lanamento de seus produtos. O valor
percebido pelo mercado est diretamente ligado inovao em relao concorrncia e o
prazo de entrega de produtos um dos requisitos para isso.

a) Tabelas relacionando faixas de tamanho como ndices do prazo de concluso do

atendimento da demanda, prazos conforme fases de acompanhamento gerencial
intermediria e prazo para mobilizao e incio do atendimento;
b) Relaes matemticas (normalmente um exerccio de regresso exponencial matemtica)
com base em dados de tamanho e prazo de projetos passados;
c) Modelos econmicos como o Constructive Cost Model (COCOMOII) ou o Software Lifecycle
Management (SLIM).
Especificamente no caso de um contrato envolver o mesmo tipo de demanda em termos de
faixa de tamanho, passa a ser coerente a utilizao de um modelo proporcional onde se
estabelece uma taxa de entrega em termos de pontos de funo por homens-dia e a partir da
aplicao dessa taxa de entrega medio ou estimativa de tamanho de uma demanda
estabelecer o seu SLA de prazo.
No existe almoo grtis, como diminuir o preo do ponto de funo? Prevendo a Capacidade
a ser demandada
Cada SLA estabelecido envolve um custo associado, afinal o fornecedor para poder atender s
metas definidas no SLA deve mobilizar uma equipe e uma infra-estrutura. Imagine se no
houver uma expectativa de utilizao mdia dessa capacidade ou um prazo para o fornecedor
poder se mobilizar para o atendimento de um pico que, por exemplo, dobre essa demanda em
determinado perodo. Surgem dois cenrios: a) o fornecedor trabalha no risco de cumprir o
SLA de prazo na eventualidade de momentos de pico; b) o fornecedor trabalha com recursos
em reserva visando prontido quando e se houver demanda para tal. Mesmo considerando
que se trata de uma fbrica de software e que h a possibilidade de movimentao de
recursos entre as diferentes unidades de negcio, ainda assim tanto o item (a) quanto (b)
esto presentes e representam custo que ser transmitido ao preo.

De nada adianta amarrar esforo, prazo e capacidade conforme o escopo se no houver

mecanismos que motivem a qualidade interna e externa nos produtos entregues. Portanto,
fundamental o estabelecimento de SLA de qualidade. A definio de um ponto de falha que
pondere de maneira unificada os erros (problemas internos ao artefato) e defeitos (percepo
externa de que o artefato no se comportou como o esperado). No se trata de uma
contradio ao abrir este artigo, cito o princpio de observar aspectos externos na gesto de
www.fattocs.com.br

Pgina

Sem qualidade no h produtividade!

Visando permitir uma melhor gesto do contrato, recomendado o estabelecimento de um

SLA de capacidade estabelecendo qual a capacidade nominal exigida e um prazo de
antecedncia concedido ao fornecedor no caso de perodos em que a administrao antev
picos acima dessa capacidade nominal. Mesmo esses picos convm serem limitados a uma
capacidade mxima. Podem haver perodos em que isso ocorra, mas quando houver, que o
fornecedor no seja penalizado pelos SLA de Prazo. O motivo para isso no onerar os 80% ou
mais das demandas que no se encontram nessa situao. Se esse no for o caso e as
demandas que estejam acima da capacidade contratada representem esses 80% de demanda,
o que verificamos ou um problema interno ao cliente de gesto de demandas, ou um
problema no planejamento do contrato onde no se estimou adequadamente a utilizao dos
servios contratados.

contratos e agora recomendo a criao de uma unidade que pondere os erros no

estabelecimento de um SLA. Observe que no h uma superviso de pessoas, mas uma
verificao e validao nos produtos entregues. Produtos esses que atravessa a fronteira da
gesto da contratada em direo gesto do cliente. Isso importante por dois motivos: a) os
testes (que identificam os defeitos) tm eficcia restrita; e b) a qualidade interna est
relacionada qualidade externa. Por isso recomendado que os produtos entregues, nesse
particular, sejam verificados quanto conformidade ao processo definido e o produto quanto
aderncia aos padres de qualidade.
A idia do ponto de falha ponderar os efeitos negativos de problemas identificados na
avaliao acima de maneira possvel de ser repetida e estabelecer um SLA que relacione a
quantidade de pontos de falha apurados com os pontos de funo entregues.

Concluso

Pgina

Quando se trabalha em regime de fbrica de software, importante no simplesmente adotar

o ponto de funo como uma unidade de medida da produo, mas tambm estabelecer
critrios que faam com que os fornecedores compartilhem com os clientes os mesmos
interesses de produtividade e qualidade. A superviso no faz com que os interesses sejam
compartilhados, faz com que o fornecedor se comporte bem... Enquanto algum est olhando.

www.fattocs.com.br