Offshore Outsourcing e Internal Offshoring: Padrões de evolução

Outra comparação entre os dois modelos e as categorias identificadas está relacionada com a evolução da prática de DDS em cada um. Novamente, não se tem conhecimento de que algo similar tenha sido feito anteriormente, o que caracteriza uma contribuição relevante para a literatura da área. Os estudos encontrados na literatura, principalmente durante a execução da revisão sistemática, caracterizam padrões de evolução do ponto de vista de relação entre as empresas – visão organizacional [99, 100, 132], mas não com uma visão mais abrangente, incluindo as visões técnica, não-técnica e organizacional.

Desta forma, os dados coletados permitiram uma análise de alguns aspectos relevantes do ponto de vista de evolução em cada modelo. A Tabela 31 apresenta as cinco principais categorias identificadas. Estas categorias foram identificadas a partir da

análise das respostas de todas as perguntas que faziam algum tipo de menção a padrões de evolução da prática do DDS.

Tabela 31. Padrões de evolução em cada modelo

Offshore Outsourcing # Internal Offshoring

Gerência de pessoas 1 Gerência de projeto

Comunicação 2 Aprendizado

Gestão de conhecimento 3 Gerência de pessoas

Engenharia de requisitos 4 Processo de desenvolvimento de software

Estratégia de DDS 5 Comunicação

Em relação aos padrões de evolução, no modelo de offshore outsourcing evidenciou-se uma maior preocupação com aspectos não-técnicos e organizacionais, enquanto que no modelo de internal offshoring ficou mais evidente uma preocupação com aspectos técnicos e não-técnicos. Estes resultados corroboram com o que foi encontrado na comparação anterior, a respeito dos desafios encontrados em cada modelo. No modelo de internal offshoring exista uma dependência significativa da matriz da empresa em termos de aspectos organizacionais, que acaba trazendo uma experiência considerável para as operações das unidades. Já no modelo de offshore outsourcing acaba se destacando a necessidade de estabelecer padrões de evolução em todos os sentidos, principalmente do ponto de vista organizacional.

Em um segundo momento, analisou-se uma pergunta específica inserida ao final do conjunto de perguntas do instrumento de coleta de dados, que se relacionava com cada construto teórico. Esta pergunta solicitava ao respondente para comentar sobre como as práticas relacionadas com aquele construto havia evoluído ao longo do tempo dentro da organização estudada. Sendo assim, para cada construto teórico, foi possível consolidar as principais diferenças entre os dois modelos do ponto de vista de padrões de evolução (Tabela 32).

A partir desta comparação, foi possível determinar um conjunto de padrões de evolução no contexto de internal offshoring. Para isso, algumas premissas básicas foram seguidas e são apresentadas na próxima seção.

Tabela 32. Padrões de evolução encontrados em cada modelo

Construtos teóricos Offshore Outsourcing Internal Offshoring

Políticas e padrões

As empresas seguem modelos de qualidade de software desde o começo (CMMI)

Algumas empresas não precisam seguir modelos de qualidade, visto que todos os projetos são internos. Existem casos onde a matriz da empresa precisa avaliar a qualidade das unidades através da adoção de modelos de qualidade, tais como CMMI.

Níveis de dispersão

As empresas possuem projetos desenvolvidos com diversas empresas de forma simultânea, o que pode tornar o monitoramento mais complexo

As empresas geralmente iniciam as operações de unidades uma por vez, facilitando o monitoramento das diferentes equipes e a melhoria da estratégia de DDS

Natureza dos projetos

No começo, os projetos são

concentrados em desenvolvimento e codificação. Se a relação com as empresas externas é de longo prazo, outras fases do ciclo de vida podem ser distribuídas, mas isto não é a regra

No começo, os projetos são

concentrados em desenvolvimento e codificação. Como a relação geralmente é de longo prazo e os projetos são desenvolvidos na mesma empresa, é mais fácil reter o

conhecimento do negócio e ter o envolvimento das unidades em outras fases do ciclo de vida de

desenvolvimento

Estrutura organizacional

As empresas possuem projetos desenvolvidos com diversas empresas de forma simultânea, o que pode tornar o monitoramento das equipes mais complexo. Neste caso, pode acabar surgindo sobreposição de responsabilidades

As empresas geralmente iniciam as operações de unidades uma por vez, facilitando o monitoramento das diferentes equipes e a melhoria da estratégia de DDS. É mais fácil definir estrutura e diferentes

responsabilidades

Alocação de projetos

Os projetos são distribuídos e alocados de forma ad-hoc logo no começo – as necessidades de negócio influenciam na decisão

Os projetos são distribuídos e alocados seguindo um modelo de decisão desde o começo – fatores tais como

experiência e conhecimento influenciam na decisão

Diferenças culturais

Diferenças culturais não são reconhecidas como importantes no começo – a postura é reativa

Diferenças culturais são reconhecidas como importantes desde o começo

Aquisição de confiança

O processo de aquisição de confiança varia de projeto para projeto, e não é institucionalizado desde o começo

O processo de aquisição de confiança é incentivado desde o começo através de treinamentos específicos em

habilidades interpessoais e

desenvolvimento global de software

Distância percebida

As pessoas percebem mais distância no começo devido à falta de confiança e diferenças culturais

As pessoas geralmente se sentem mais próximas, por estarem na mesma empresa

Metodologia de desenvolvimento

A padronização de processo é uma das primeiras atividades dentro de um projeto neste modelo

A padronização de processo geralmente é uma das primeiras atividades planejadas, e é facilitada pela relação dentro da mesma empresa

Gestão de projeto

Existe um investimento na gestão de projetos desde o começo, embora o foco não seja na formação de gerentes globais

Os gerentes de projeto são treinados em como se tornar gerentes globais desde o começo

Colaboração

A definição da infra-estrutura para apoiar o desenvolvimento de software é geralmente definida no começo da relação com as empresas externas. Muitas vezes a falta desta definição dificulta a colaboração entre as empresas

Ferramentas de comunicação e colaboração são utilizadas desde o começo. As ferramentas geralmente acabam se tornando padrão para toda a empresa em nível global