bemvindo@startify.com.br (27) 3019-7996
O problema com times orientados para atividades
04/07/2016
0

* Este post é uma tradução feita em 1 de julho de 2016 do post de 1 junho de 2016, escrito por Sriram Narayan. Esta é uma tradução livre, feita com autorização do autor. O post original, em inglês, você lê aqui.

Orientado a atividadesQualquer esforço significativo de desenvolvimento de software exige a execução de diversas atividades diferentes: análise, desenho da experiência do usuário, desenvolvimento, teste, etc. Times orientados para atividades organizam-se ao redor dessas atividades, sendo então dedicados para o desenho da experiência do usuário, desenvolvimento, testes, etc. Orientação para atividades promete muitos benefícios, mas o desenvolvimento de softwares é, normalmente, feito melhor com times orientados para resultados.

 

Tradicionalmente, grandes empresas com grandes departamentos de TI tendem a executar o desenvolvimento de projetos de TI com muitos times orientados para atividades, apontados de uma organização em matriz da área (organização funcional). Os braços marcados com as linhas sólidas na imagem (normalmente liderados por um vice-presidente de desenvolvimento, testes e assim por diante) são geralmente limitados pelas atividades que emprestam “recursos” para projetos ou programas da organização, marcados pelas linhas tracejadas na imagem. As justificativas comuns para isso incluem:

  • Ajuda a padronização de convenções e técnicas de desenvolvimento quando todos os desenvolvedores reportam a uma mesma organização (o braço da matriz). O mesmo se aplica a testes e etc;
  • Facilita a mentoria, treinamento e estímulo da competência em geral se todos os desenvolvedores tem gerentes experientes na mesma área que eles. O mesmo se aplica a área de testes e outras;
  • Ajuda a maximizar a utilização do talento (e portanto ganhar eficiência em custos) por alocação pessoas de um repositório rotativo de desenvolvedores, testadores, etc.

No entanto, times orientados para atividade são propensos a otimizar sua própria atividade e não com a visão do todo, pensando na entrega de softwares úteis. Esta é a consequência daquilo pelo que são responsáveis e como sua performance é medida. É comum para um time feito apenas de desenvolvedores ser medido pela sua velocidade. Se eles são incumbidos apenas de entregar o escopo, eles não pensarão se o programa construído a partir desse escopo será capaz de resolver os problemas que originaram a demanda. E mesmo que o façam, eles serão desencorajados pelo time de gestão do produto – outro time focado em atividades que é responsável apenas pela determinação das especificações.

Organizar por atividades obstrui a redução do tamanho dos lotes de trabalho que são distribuídos entre os times. Uma equipe separada de testadores não vai aceitar que os desenvolvedores enviem um teste de cada vez. Eles preferem testar o que seria suficiente para lançar o produto, ou pelo menos o que seria uma funcionalidade completa do produto. Isso alonga o tempo de feedback sobre essas novidades, aumenta o tempo entre as especificações e a entrega do produto final e afeta diretamente a capacidade da empresa (ou departamento) em responder às demandas dos clientes.

TI de alta velocidade exige times motivados. Autonomia é um motivador chave nas equipes. No entanto, uma organização orientada para atividades só pode oferecer uma quantidade limitada de autonomia, pois ela tende a usá-la para otimizar apenas a sua esfera de atividade.

Uma variação da organização orientada para atividade são times super especializados que podem ter os seguintes resultados:

  • Times centrados em habilidades ou ferramentas. Ex: time dedicado a WebSphere Portal Server (se você também não sabe o que é isso, a Wikipedia explica) ou que trabalham apenas com BizTalk (outro serviço que não sabia que existia).
  • Times organizados em camadas arquitetônicas. Ex: um time para a camada de apresentação, outro para a camada intermediária, outro para a camada de dados.

Eles são problemáticos porque tem um foco bastante limitado e tendem a otimizar para a performance do time, em vez de se dedicarem ao todo. É certo que, algumas ferramentas podem exigir especialistas, mas isso não é razão para isola-los em outro time. Especialização não é o problema; organizar seguindo as linhas de especialização sim.

O que funciona melhor

Desenvolvimento de software é um processo de desenho iterativo. E para alcançar a verdadeira iteração e capturar o valor de feedbacks frequentes, as atividades precisam ser realizadas por um só time (tendo uma linha de reporte comum), o tanto quanto possível. Muitos negócios baseados em internet e vendedores independentes de software já operam desta forma.

Livro Sriram
O livro de Sriram detalha mais sobre como construir uma organização de TI eficaz usando abordagens ágeis.

Organizações orientadas a atividades podem ser atrativas da perspectiva de maximização do uso dos recursos, mas ela atrapalha a maximização de valor adicionado e a flexibilidade para atender às demandas do cliente. No mundo dos negócios atual, responsividade ao mercado (eficiência de tempo) é mais importante que a eficiência de custo, especialmente quando se trata de itens de dispêndio de capital, como o desenvolvimento de software. Além disso, o reporte direto na organização deveria ser alinhado aos objetivos mais importantes, que são resonsividade e adição de valor.

Na ausência de uma estrutura de reporte direto, é possível estimular competências através de comunidades de prática lideradas por especialistas com capacidade de mentorar, e com um orçamento para eventos da comunidade, comprar livros e providenciar treinamento. Essas comunidades também ajudam a padronizar convenções e técnicas sem ultrapassar limites. E sobre ter um gestor estável a quem se reportar, isso só é um problema na TI centrada em projetos. Uma configuração centrada na capacidade do negócio permite esse tipo de estabilidade.

Agradecimentos (artigo original)

Agradeço a Bill Codding, David Wang (Wang Wei), James Lewis, Kief Morris, Patrick Kua, Patrick Sarnacke, Steven Lowe e Venkatesh Ponniah por seus comentários. Agradecimento especial a Martin Fowler pela sua orientação quanto ao conteúdo, ajuda na publicação e pelas boas ilustrações.

Comentários