Proxy Product Owner
- A função do Gerente de Projetos de
software utilizando métodos ágeis em equipes
geograficamente distribuídas
Carlos E. Flores, Marta R. Bez Centro Universitário Feevale: ICET 93.510-250 – Novo Hamburgo – RS – BrazilResumo. Este artigo descreve o estudo de caso de uma empresa que, ao
contratar um terceiro para implantar e desenvolver melhorias em um sistema, cria um cenário complexo que envolve o uso de um método de desenvolvimento ágil e “outsourcing offshore”. São apresentados no artigo as características do cenário em estudo e uma possível solução, composta pela adição de um papel ao método ágil de desenvolvimento, denominado “proxy product owner” visando a proteção do método e mitigar as dificuldades enfrentadas.
1. Introdução
Este artigo apresenta o estudo de caso de uma empresa que está ingressando na
área do e-commerce. Para isso, contratou um fornecedor de software que possa
suprir suas necessidade e que tenha a capacidade para suportar o rápido
crescimento previsto pelo contratante.
O autor deste artigo foi designado como Gerente de Projetos pela empresa contratada, sendo responsável pela avaliação dos requisitos priorizados pelo cliente e gestão da equipe de desenvolvimento.
Devido às características do negócio e da ferramenta adquirida, é recomendado o uso de um método ágil para desenvolvimento de melhorias que devem adaptar a ferramenta ao negócio do cliente. Porém, o uso de métodos ágeis em um projeto distribuído entre duas empresas e três países faz com que o método precise ser adaptado. Será apresentado na seção 2 a descrição do cenário em estudo, na seção 3 as dificuldades encontradas e, por fim, na seção 4 a solução proposta com o uso do Proxy Product Owner.
2. Descrição do cenário
Para o fornecedor é vital manter a autonomia sobre sua equipe de desenvolvimento, conservando o sentimento de time e vínculo com a empresa. O cliente deseja ter autonomia sobre o escopo do produto. Para isso, deve ser estruturada uma equipe dentro de sua área de TI para gerir a nova demanda gerada pelo e-commerce.
A empresa contratada tem sua sede nos Estados Unidos, com filiais no Brasil e na Índia. Essas características já são suficientes para formar um cenário complexo, que é agravado pela complexidade do produto e os ambiciosos objetivos do cliente.
2.1. O Time Frame das equipes envolvidas
A empresa contratada para o desenvolvimento e suporte possui sua sede nos Estados Unidos, com filiais na Índia e Brasil. O desenvolvimento de novas funcionalidades é feito nos Estados Unidos, pois exige um alto grau de especialização, e é onde estão os desenvolvedores com maior experiência na ferramenta utilizada.
O Gerente de Projetos, responsável pelo time de melhorias, também trabalha alocado na sede do cliente. Isso faz com que tenha uma melhor percepção das reais necessidades do contratante e facilita sua comunicação com a equipe de e-commerce, porém a distância e diferença de fuso horário dificultam a comunicação com seu time de desenvolvimento.
O primeiro nível de suporte acontece no Brasil, onde um funcionário alocado na sede do cliente trabalha para resolver as questões com menor exigência técnica. Os demais níveis de suporte, N2 e N3, são realizados na Índia. Isso traz benefícios como o custo e a possibilidade de resolver problemas antes que o turno de trabalho do cliente inicie, porém, também dificulta sua comunicação e colaboração com seu líder de suporte no Brasil.
A figura abaixo apresenta a alocação dos times por país e seu horário de trabalho.
Imagem 1. Time Frame
2.2. Terceirização (Outsourcing)
A terceirização pode ser total, onde o contratante não possui nenhum envolvimento com o processo produtivo, ou parcial, onde funcionários da empresa contratante tem participação ativa na definição e produção do produto.
No exemplo descrito, a terceirização é parcial. Apesar do contratante não participar do desenvolvimento do software, ele descreve os requisitos para as melhorias e prioriza os itens que devem ser desenvolvidos na sprints. Sendo assim, o contratante acumula as funções de definição do produto e gerência de escopo.
A terceirização do desenvolvimento é vantajosa para o contratante, pois as melhorias necessárias na ferramenta exigem um alto grau de especialização, o que inviabiliza a manutenção de uma equipe própria, que teria uma “curva de aprendizado” muito longa e um custo elevado. (PRADO; TAKAOKA, 2002)
O contratante também tira proveito da experiência adquirida por uma empresa especializada, que possui vários clientes utilizando a mesma plataforma. Isso agiliza o processo evolutivo, pois os problemas enfrentados já foram tratados com outros clientes. A crescente escassez de mão de obra especializada dificultaria a formação de um pequeno time de desenvolvimento. E mesmo que fosse esse o caminho escolhido e contratado um time qualificado, a empresa ainda estaria vulnerável à grande rotatividade e dificuldade para lidar com a variação no volume de demandas.
Contudo, a maior motivação para a terceirização no cenário descrito é a necessidade da empresa contratante de manter o foco no seu negócio, que não é TI, e sim a venda de seus produtos. Para isso, ela se concentra na utilização de informações, deixando a manutenção de sua infraestrutura e evolução de suas ferramentas para empresas especializadas.
2.3. Equipes Distribuídas (Offshore Outsourcing)
O offshoring é um tipo de outsourcing onde tarefas são executadas por equipes em outros países.
O motivo mais frequente para a adoção do offshoring é a redução de custos, mas, em alguns casos, pode ser uma opção estratégica para entrar em um mercado, para recrutar talentos escassos, ou mesmo para superar limitações legais no país de origem.
A Índia é atualmente o país dominante na prática do offshoring, exportando mão de obra de TI para todo o mundo. (SOURCINGMEG, 2013)
O offshoring pode ser usado na forma de terceirização (outsourcing), ou como uma extensão da empresa na forma de uma filial no exterior.
No cenário descrito, a empresa contratada possui sua matriz nos Estados Unidos, onde trabalham os principais desenvolvedores, líderes técnicos e diretoria.
Na filial indiana são desenvolvidas as tarefas de suporte nível 2 e 3, testes, e também algumas tarefas de desenvolvimento para novas funcionalidades.
A empresa contratada também possui um escritório no Brasil, onde trabalham o responsável por suporte nível 1 e o gerente de projetos. O escritório do Brasil foi estruturado para obter uma presença fixa no país, onde a empresa possui alguns dos seus maiores clientes.
2.4. A utilização de um métodos ágil
Métodos de desenvolvimento tradicionais consideram como bem sucedidos os projetos que são entregues no prazo, são desenvolvidos dentro do orçamento, e cumprem as especificações planejadas.
Essa é uma definição incompleta. Muitos projetos entregues com atraso são um grande sucesso, e muitos projetos entregues dentro do prazo e de acordo com as especificações não agregam nenhum valor para a empresa. (SHORE, 2007)
Ao contrário de tentar eliminar completamente as incertezas, ou iniciar o projeto assumindo um alto risco de não atingir o objetivo esperado, os métodos de desenvolvimento ágeis assumem que incertezas existem e que muitas delas não podem ser eliminadas com análise e planejamento.
O Scrum faz correções de rumo durante o processo produtivo. Se um objetivo de negócio não está sendo cumprido, o escopo pode ser alterado para a próxima sprint. Essa ação, em um método de desenvolvimento tradicional, seria considerada um fracasso, já que o planejamento inicial não foi cumprido. (DUNN, 2012)
Áreas com concorrência acirrada e mudanças constantes, como o varejo via internet (e-commerce), não podem aguardar longos ciclos de desenvolvimento para obter resultados ou repriorizar seus objetivos.
3. Obstáculos encontrados
O ideal para o bom funcionamento de um projeto que utiliza um método ágil é manter as pessoas próximas. A forma mais eficiente de trabalho é manter todos os envolvidos trabalhando na mesma sala, se possível na mesma mesa.
Quando o cenário encontrado não é o ideal para o método, problemas de comunicação, colaboração, e produtividade serão enfrentados.
3.1. Dificuldades criadas pela distância
A simples separação dos integrantes do time em diferentes salas do mesmo prédio já é suficiente para diminuir sua produtividade. A dificuldade aumenta exponencialmente quando o time é separado por dezenas de milhares de quilômetros. (ZETLIN, M, 2012)
A forma mais eficiente e efetiva de transmitir informação para dentro de uma equipe de desenvolvimento é uma conversa face a face. (Agile Manifesto, 2001)
Porém, o que mais afasta os integrantes de um time ágil não é a distância, mas sim a diferença de fuso horário. Londres está a cerca de 8.600 quilômetros da Califórnia, enquanto a distância entre Londres e Cape Town é de 9.700 quilômetros. Entretanto, a diferença de fuso horário entre Londres e San Francisco é de oito horas, enquanto Cape Town está à apenas duas horas a frente de Londres. (COHN, 2010)
3.2. Problemas com a comunicação
Uma das causas mais frequentes de problemas na terceirização de desenvolvimento no exterior (offshore outsourcing) são as falhas de comunicação.
O processo de comunicação envolve falar, escutar, observar mensagens não verbais, questionar, analisar e avaliar. O objetivo de compartilhar conhecimento irá falhar, se os cinco componentes do processo não forem bem executados. (GOOLSBY, K, 2009)
Pode haver falhas no início do processo durante a criação ou passagem dos requisitos ao time de desenvolvimento. Como os times de desenvolvimento e negócios
não falam o mesmo idioma, os requisitos precisam ser traduzidos e a passagem dos requisitos não é feita pela mesma pessoa que os reescreveu, sendo necessário o envolvimento de um terceiro que faça traduções e encaminhe as demandas para serem desenvolvidas.
O Product Owner e Scrum Master não estarão presentes durante a análise dos requisitos, com isso a solução proposta pode não trazer os resultados desejados, ou não utilizar os métodos adequados.
Existem ainda as dúvidas, que mesmo com bons documentos de requisitos, sempre irão surgir. Um documento pode estar bem redigido e cobrir todos os pontos necessários, mas ainda depende da interpretação do seu leitor para alcançar o resultado desejado.
3.3. Distribuição do projeto entre várias empresas
Além da distância, a divisão de um projeto entre mais de uma empresa faz com que as pessoas não trabalhem interagindo de forma eficiente. Pessoas têm interesses próprios, mesmo quando trabalham por uma causa comum. Os objetivos costumam divergir a favor do que julgam ter maior importância. Pode ser um aumento de salário, uma promoção, ou o reconhecimento pelo seu esforço.
O mesmo acontece com empresas, mesmo quando trabalham no mesmo projeto, sua motivação e métodos de trabalho são diferentes, normalmente guiados pela cultura da empresa ou pelo plano de negócio definido pela diretoria.
Estas divergências, quando misturadas em um mesmo projeto, têm efeito negativo na colaboração dos envolvidos. Ao invés de procurar atingir os objetivos do negócio, os funcionários vão trabalhar para atingir os objetivos do gerente da conta, que por sua vez, pretende cumprir o contrato da forma mais lucrativa possível.
Os projetos perdem em transparência e agilidade quando as equipes não seguem o mesmo líder, questões simples podem levar muito tempo para serem resolvidas porque dois ou mais níveis de hierarquias precisam ser consultados.
3.4. Evitar o Body Shop
No caso estudado, a gestão está sob o poder da empresa cliente, que deve definir o escopo do projeto e escrever os requisitos. Porém, não é do interesse da empresa cliente gerenciar o desenvolvimento, que fica a cargo da empresa contratada.
Essas características configuram um modelo de terceirização do tipo outsourcing, e não body shop, o que propicia para cliente e contratada os seguintes benefícios:
- O cliente só paga pelo que, de fato, utiliza; - O cliente se dedica mais ao negócio;
- Espera-se que o fornecedor do serviço tenha know-how, melhores práticas e seu próprio gerenciamento de projetos;
- O fornecedor mantém o senso de equipe e cultura da empresa com seus desenvolvedores;
- A empresa cliente elimina o liability que teria por manter funcionários de um terceiro trabalhando tempo integral em sua sede.
- O fornecedor é visto como um parceiro estratégico de negócio, e não apenas um provedor de mão de obra. (BATISTELA, G, 2007)
Funcionários contratados sob a modalidade body shop não costumam ser comprometidos com a empresa em que estão alocados, não dando a devida importância ao projeto desenvolvido. Esse profissional não tem perspectivas de crescimento, pois não é funcionário da empresa onde presta seus serviços.
4. Soluções utilizadas no caso em estudo
Agile e Outsourcing são teoricamente incompatíveis. (ROUSSEV, B, 2009) Porém, algumas adaptações e boas práticas podem possibilitar o uso do Scrum com Outsourcing, e até mesmo com Outsourcing Offshore.
4.1. Como resolver o problema da distância? Algumas características do Scrum são:
- Agregar valor ao negócio com maior velocidade; - Pouca documentação;
- Times pequenos;
- Manter os integrantes do time trabalhando o mais próximos possível, para maximizar a comunicação.
Em teoria, times que trabalham afastados, e com poucas horas de trabalho em comum, precisam de mais documentação e sprints de trabalho mais longas. Todas essas características são prejudicadas pela distância e dificuldade de comunicação geradas pelo offshore outsourcing.
Empresas costumam terceirizar seus serviços de desenvolvimento porque seu contingente de funcionários está aumentando, e estão à procura de recursos de baixo custo e em quantidade.
É necessário adaptar o método para que funcione com times maiores, esse objetivo pode ser atingido com a formação de pequenos times independentes, ou utilizando processos fortes e maximizando a comunicação.
No caso estudado, os funcionários não são alocados pela sua área de atuação. Existem testadores trabalhando na filial indiana e na sede americana, assim como um desenvolvedor de melhorias alocado na filial indiana, enquanto seus colegas trabalham nos Estados Unidos.
As reuniões diárias melhoram muito a comunicação, deve ser escolhido um horário com fuso-horário comum entre as sedes da empresa.
Horários de trabalho podem ser ajustados para diminuir a diferença causada pelo fuso-horário. O ideal é que os funcionários da sede indiana iniciem e terminem mais tarde, e que os americanos iniciem mais cedo. Dessa forma, todos teriam mais tempo de trabalho em comum.
A primeira etapa onde pode haver falhas na comunicação é quando uma tarefa é descrita e designada para um desenvolvedor. Utilizar um conjunto de diretrizes claras para criação dos requisitos (MESSER, H, 2010) pode minimizar os problemas de interpretação do requisito e reduzir a quantidade de funcionalidades não documentadas e que precisam ser descritas durante o processo de desenvolvimento.
Deve ser encontrado um meio rápido para obter feedback, isso é fundamental para manter o alto nível de colaboração. Quanto mais impessoal a forma de comunicação, menos eficiente ela é. Portanto o e-mail não deve ser a única alternativa para resolver dúvidas e conseguir ajuda.
4.2. O papel do Product Owner e do Proxy Product Owner
No caso estudado, e de acordo com a solução proposta, o fornecedor do serviço oferece a solução denominada Proxy Product Owner para facilitar a interação entre o time de desenvolvimento e o cliente, e possibilitar o uso de um método ágil de desenvolvimento. Este proxy deve representar os interesses do cliente para o time de desenvolvimento, sendo um profundo conhecedor dos objetivos de negócio e detalhes dos requisitos priorizados.
O dono do negócio permanece sendo o Product Owner, porém o proxy tem autoridade para responder em nome do cliente, a menos que isto possa alterar decisões estratégicas que devem ser tomadas pelo cliente.
O Proxy deve ter a autoridade de um PO sênior, e ser respeitado pelos stakeholders, caso contrário suas ações não terão a relevância necessária, gerando uma lacuna no processo, sobrecarregando o PO, e prejudicando a agilidade do método. O papel do Product Owner é resumidamente:
- Escrever e manter o Product Backlog, normalmente na forma de User Stories; - Deve estar presente nas reuniões de Sprint Planning e no final da Sprint, na reunião de Sprint Review para verificar se o trabalho executado está de acordo com seus critérios de aceitação;
- Seu objetivo principal é, maximizar o valor e retorno do investimento para o produto. (MAHMOOD, F, 2012)
É comum que o Product Owner acumule outras funções, portanto, ele pode não ter tempo para lidar com todos os detalhes a serem decididos sobre os requisitos, e não tem disponibilidade para responder rapidamente às dúvidas dos desenvolvedores.
O Proxy Product Owner pode ser uma função intermediária que se encarrega das tarefas originalmente atribuídas para o PO, que por acumular outras funções, não dispõe de tempo suficiente para exercer a função de PO plenamente.
Nesse caso, o Proxy Product Owner é quem participa das reuniões de Planning e Review e reporta suas impressões ao PO. (MAHMOOD, F, 2011)
No caso estudado a motivação é outra, o Proxy Product Owner é necessário porque o time de desenvolvimento não tem acesso direto ao PO, os desenvolvedores se reportam a um gerente da empresa contratada, que acumula as funções de Scrum Master e Proxy Product Owner.
Para o time de desenvolvimento o PPO (Proxy Product Owner) será o dono do negócio, pois é dele que receberão os requisitos a serem desenvolvidos e manterão contato parar tirar dúvidas durante o desenvolvimento. No entanto, o PPO não é o dono do negócio, essa é apenas uma adaptação necessária para manter o método ágil funcionando com uma equipe distribuída, como é ilustrado na figura abaixo.
Imagem 2. Proxy Product Owner, Product Owner e equipe distribuída.
Como ilustrado na figura abaixo, o Proxy também pode ter a função de consolidar os interesses de vários stakeholders que fazem o papel de donos do negócio. Este não é o cenário ideal, e dificulta a atuação do Proxy Product Owner, que lidaria com disputas políticas e teria maior dificuldade para comunicar com clareza os interesses do cliente para o time de desenvolvimento.
Imagem 3. Proxy Product Owner e múltiplos Product Owners
O objetivo é criar uma abstração de ambos os lados, fazendo com que o time de desenvolvimento tenha fácil acesso às definições funcionais e que o Product Owner tenha a visibilidade necessária, sem que a empresa contratada perca a gerência sobre seus funcionários.
A desvantagem na utilização de um proxy é a possível queda na qualidade da informação com a distanciação criada entre time e PO, e diminuição na performance do processo ágil. Estes problemas podem ser evitados ou mitigados com boa comunicação entre PO e PPO, e disciplina ao seguir o método escolhido.
5. Conclusão
O Proxy Product Owner é necessário para eliminar ou reduzir barreiras e burocracia, facilitando o acesso do time aos detalhes dos requisitos, e fazendo com que as prioridades definidas pelo PO sejam devidamente comunicadas e executadas. O uso do PPO também se faz necessário quando o time de desenvolvimento não responde diretamente ao Product Owner, e a organização geral da conta é muito complexa para utilizar um método de ágil.
O Proxy Product Owner não será a solução quando a definição de Product Owner não for bem compreendida pela empresa, nesses casos o cargo costuma ser delegado a outra pessoa, e o PO só volta a ter contato com o produto antes de seu lançamento, o que é extremamente prejudicial para o projeto. O objetivo da introdução do PPO ao processo não é substituir ou diminuir as responsabilidades do Product Owner, mas sim auxiliá-lo a executar suas funções com maior eficiência.
Métodos de produção precisam se adaptar ao contexto, em especial, ao regime de contratação. No caso estudado o regime de contratação aumenta a distância entre os membros do time devido a sua composição distribuída, esta proposta visa eliminar ou diminuir essa distância, tornando o processo tão eficiente quanto seria em sua formatação ideal.
O uso do Proxy Product Owner permite a utilização de um método teoricamente incompatível com o contexto. No caso estudado, apesar de não ter eliminado todas as barreiras, facilitou a integração entre as diversas partes do time e possibilitou a utilização do método ágil, que se mostrou eficiente, pois várias releases foram implantadas com sucesso.
Referências
BATISTELA, G. Do body shop para o outsourcing de desenvolvimento. 2007. Disponível em: http://www.baguete.com.br/artigos/208/gilmar-batistela/26/04/2007/do-body-shop-para-o-outsourcing-de-desenvolvimento. Acesso em outubro/2013
COHN, M. Succeeding With Agile. Addison-Wesley; 2010.
DUNN, R. Permanecendo Agile em uma economia incerta. IBM Developer Works.
2012. Disponível em:
http://www.ibm.com/developerworks/br/rational/library/edge/08/may08/dunn/. Acesso em setembro/2013.
GOOLSBY, K. Four Communication Best Practices Often Overlooked in Outsourcing Relationships. 2009. Disponível em: http://www.egmanagedservices.com/wp-content/upload/2011/10/Four_Communication_Best_Practices_Often_Overlooked_in _Outsourcing_Relationships.pdf. Acesso em outubro/2013
MAHMOOD, F. What is a Proxy Product Owner? 2012. Disponível em: http://www.accelright.com/agile-scrum/what-is-a-proxy-product-owner/. Acesso em outubro/2013
MAHMOOD, F. Proxy Product Owner Role. 2011. Disponível em: http://www.accelright.com/detail-Proxy-Product-Owner-Role_46.html. Acesso em outubro/2013
MESSER, H. How do we solve communication problems in (offshore) outsourcing? Disponível em: http://bridge-outsourcing.com/outsourcing/solve-communication-problems-offshore-outsourcing Acesso em outubro/2013
PRADO, E. P. V.; TAKAOKA, H. Os fatores que motivam a adoção da terceirização da Tecnologia de Informação: uma análise do setor industrial de São Paulo. Revista de Administração Contemporânea. v. 6 n.3. Curitiba. Sept./Dec. 2002. Disponível em: http://www.scielo.br/scielo.php?pid=S1415-65552002000300008&script=sci_arttext. Acesso em: setembro/2013.
ROUSSEV, B. Agile IT Outsourcing 2009. Disponível em: http://www.irma-international.org/viewtitle/30891/. Acesso em outubro/2013
SHORE, J. The Art of Agile. O'Reilly Media; 1 ed. 2007. Disponível em: http://www.jamesshore.com/Agile-Book/. Acesso em setembro/2013.
SOURCINGMEG. Offshore Outsourcing to India. CTQ Media. Disponível em: http://www.sourcingmag.com/content/offshore_outsourcing_india.asp. Acesso em setembro/2013.
ZETLIN, M. Is your outsourcer agile enough? Março, 2012. Disponível em: http://www.computerworld.com/s/article/9225013/Is_Your_Outsourcer_Agile_Enou gh_. Acesso em agosto/2013.
