Outsourcing em projetos de tecnologia

29/11/2018 14:00:00

70% das organiza��es dos EUA fracassam em projetos de TI

Outsourcing em projetos de tecnologia

Para quem não trabalha com tecnologia, gerenciar um projeto neste campo é um desafio tremendo.

Os processos são delicados e complexos, e são vários os riscos que fazem com que o planejamento vá por água abaixo, tanto em termos de recursos, quanto de tempo.

Não por acaso, uma pesquisa realizada recentemente pela Harvard Business Review traz dados eloquentes: 70% das organizações dos EUA fracassam em projetos de TI, e um em cada seis desses projetos extrapolam o prazo determinado.

O outsourcing, ou externalização, é um caminho para atenuar esses riscos. Muitas empresas têm contratado parceiros especializados em tecnologia para tocar projetos internos, parte delas com grande sucesso, outra parte, nem tanto.

Mas por que o outsourcing ajuda tanto? O que faz com que um projeto de tecnologia com outsourcing seja bem-sucedido? Quais são as boas práticas para quem quer dividir a gestão de um projeto de tecnologia com um parceiro?

 

NOVIDADE TODO MÊS

Para Elcio Ferreira, cofundador da Visie, empresa de desenvolvimento de softwares e sites, o outsourcing é a resposta porque retira das costas de empresas cujo core não é tecnologia, uma responsabilidade tremenda: a atualização:

“Na nossa área de web, tem novidade todo mês. É impossível que alguém cujo core business não seja tecnologia se mantenha atualizado; mas essa é a nossa responsabilidade”.

Mas o que é determinante para o sucesso dos projetos: a gestão ágil, com certeza:

“Desde que adotamos a metodologia, revolucionamos a empresa e os projetos que tocamos com os clientes”.

Elcio entende a gestão ágil como uma forma de “assumir os riscos abertamente”, o que faz toda a diferença no andamento de um projeto de tecnologia. Nos modelos tradicionais, baseados no gráfico de Gantt, cada entrega é muito formalizada, o que gera variável de risco muito grande.

 

TUDO COMPARTILHADO

Os modelos ágeis permitem que a Visie compartilhe os riscos com seus clientes, apresentando um cenário realista para eles e combinando, juntos, soluções para eventuais contratempos. Com isso, a eficiência tende a aumentar, e os custos diminuem.

“No dia zero de um projeto é impossível estabelecer, com certeza, os detalhes de seis meses adiante. Você trabalha na sua melhor estimativa com uma transparência muito grande.”

Nós fazemos estimativas de projeto na presença dos clientes. Eles veem tudo, participam. Temos interações diárias e a cada 15 dias fechamos os sprints. Como não consigo ter um mapa detalhado ou ter certeza, lidamos com atualizações mais frequentes. E tudo é decidido em conjunto. Decidimos juntos meta de prazo, orçamento, escopo. E vamos negociando nos sprints.

 

 

A IMPORTÂNCIA DO PRODUCT OWNER

Mas como o cliente participa desse projeto? “Por meio do PO, ou Product Owner. Eles é o responsável pelo produto,” responde Elcio Ferreira.

E o PO precisa ter autonomia para decidir, para imprimir agilidade ao projeto, mesmo que seja necessário consultar um comitê para avalizar compras:

“Se uma empresa não tem esse profissional, ela não consegue ser ágil. O projeto vai emperrar". 

Elcio lembra que todo o planejamento dos sprints deve ser realizado com base no histórico dos usuários, que o PO deve conhecer bem:

“Esse profissional traz as histórias de usuário para o projeto, e é com base nelas que vamos seguir adiante. O Product Owner precisa saber escolher as histórias que vai trazer, e isso não tem a ver com tecnologia. Até pode ter, mas no final se trata do valor entregue para o usuário”.

 

TRAUMA

Como exemplo de o que não fazer em um projeto de tecnologia, Elcio lembra do caso que o levou a criar a Visie.

Ele trabalhava numa empresa de desenvolvimento, onde o RH utilizava um software.

A organização cresceu e precisou fazer um outsourcing para essa área.

“O fornecedor contratado tinha a visão de que produzir software é caro, e é preciso desenhar tudo antes de começar o desenvolvimento. Antes de sequer começar a escrever a primeira linha de código, tudo já teria que estar estabelecido”, lembra ele. A empresa parceira passou sete meses lá, desenhando, criando diagramas e aprovando-os com as áreas de negócio. “Cansei de contar reuniões em que vi o stakeholder assinar documentos enquanto eu tinha certeza de que ele não havia entendido nada”, conta o empreendedor da Visie. “Se eu mesmo, que sou técnico, tinha dificuldade de entender, imagine quem não é”, destaca.

O problema é que o documento assinado indicava o que devia ser feito. E quando o stakeholder via o resultado final, percebia que não era nada do que ele queria. “Aí teria que voltar atrás, pagar tudo de novo.

Quando Elcio saiu de lá, resolveu abrir seu próprio negócio propondo o oposto desse modelo.

Nos modelos ágeis, o principal foco é a entrega rápida de valor. E isso faz toda a diferença, porque o desenvolvimento de um software ou de um site é intangível:

“Você só começa a ter certeza do que está entregando quando começa a ter a coisa real,” afirma Elcio.

Os modelos ágeis focam em desenvolvimento baseado na história do usuário. O foco é: o que conseguimos nesses quinze dias em termos de entrega de valor?

Esse processo orienta a empresa especialista em tecnologia a planejar o necessário somente para um ciclo, e não além dele.

Com isso, todos saem ganhando: quem é contratado, porque consegue planejar e focar melhor os esforços. E quem contrata, porque o projeto tende a tornar-se mais eficiente e menos dispendioso.