BT

Início Artigos Silos, politicagem, e a entrega de produtos de software

Silos, politicagem, e a entrega de produtos de software

Favoritos

Pontos Principais

  • Silos e política surgem quando o caminho da ação não é claro.

  • A falta de clareza leva as facções lutando pela direção.

  • Projetos de software são complexos e difíceis de estruturar.

  • Frameworks por si só não conseguem resolver a política, pois a estratégia e a estrutura ideais são específicas do problema.

  • As equipes podem lidar com a política identificando impedimentos e rotas a serem escaladas mais cedo, criando relacionamentos com antecedência, e trabalhando dentro de limitações.

As equipes técnicas tendem a não estar preparadas para a política. Isso leva a que os problemas políticos sejam aceitos como tragicamente inevitáveis ou eliminados devido à incompetência de outros. Mas a política não é inevitável e não é causada pela incompetência.

A política nos negócios surge quando a direção não é definida com clareza suficiente. Isso pode ser melhor entendido através do trabalho de Patrick Lencioni, que será explorado na próxima seção. Quando armados com esse entendimento, passaremos para a política no mundo do desenvolvimento de software. Criar software é uma tarefa complexa que apresenta desafios especiais. No entanto, o princípio básico de definir a direção com clareza é aplicável. Uma melhor compreensão das causas da política ajudará a entender a melhor forma de resolver ou pelo menos lidar com ela em projetos de software.

Política no mundo dos negócios

Algumas empresas têm um foco claro, objetivos bem definidos, e uma estratégia para alcançá-los. Outras passaram a ser o que são através de aquisições e crescimento históricos, resultando em uma estrutura confusa e em uma direção pouco clara. Empresas focadas experimentam muito menos divisão interna e política do que empresas amplas e confusas.

Empresas focadas são menos políticas porque estão focadas. Se o curso da ação for definido claramente e a liderança deixar claro que eles estão por trás disso, os departamentos trabalharão para isso. A política acontece quando há ambiguidade sobre direção. Isso deixa espaço para as facções promoverem sua própria interpretação ou lutarem por seu território específico.

Algumas empresas, especialmente as grandes, têm estruturas organizacionais que geram políticas. Isso pode até acontecer como efeito colateral do sucesso. Uma empresa começa como um pequeno desafiante, com uma estratégia específica para obter participação de mercado do grande operador histórico. Mas, à medida que obtém mais sucesso, cresce e expande seu modelo de negócios para vender mais produtos e serviços relacionados. Talvez também adquira outras empresas, algumas das quais podem se encaixar apenas parcialmente no modelo de negócios original. Eventualmente, o foco da empresa fica obscurecido e os departamentos se encontram lutando por status e orçamento, cada um defendendo que o que eles fazem é essencial para os negócios.

Lencioni sugere reduzir a política estabelecendo uma meta temática para a organização e sub-metas abaixo dela. Uma abordagem semelhante é adotada pelo framework Objetivos e Principais Resultados (Objectives and Key Results, OKRs), onde as metas de nível superior estão vinculadas aos objetivos de nível inferior em toda a organização. Lencioni alerta que a simples produção de metas e objetivos não resolverá a política, a menos que a direção estabelecida seja muito específica e acionável e tenha uma lógica unificadora por trás dela. As equipes precisam entender a direção que está sendo definida por sua liderança e qual o papel que podem desempenhar melhor dentro dela. Caso contrário, haverá desalinhamentos que se transformarão em conflitos.

Política no mundo do software

Desalinhamentos podem surgir com facilidade em projetos de software. O software é complexo e o processo de construção é complexo. Um projeto pode ter um objetivo nítido de orientação em alto nível, mas ainda pode se tornar político, pois as sub-equipes individuais podem ter interesses ou interpretações desalinhados sobre sua parte para alcançar os objetivos.

Desalinhamentos entre equipes podem se concentrar em prioridades, escopo, ou direção. Imagine que uma equipe se vê bloqueada, pois não consegue concluir um trabalho até que o trabalho seja concluído por outra equipe. A outra equipe pode não considerar esse item de alta prioridade para eles; nesse caso, há um desalinhamento de prioridades. Ou a outra equipe pode considerar o trabalho fora do seu escopo; nesse caso, precisa ser resolvido quem deve entregar o trabalho. Ou, mais seriamente, pode haver um desacordo sobre a direção - a outra equipe pode entender a solicitação, mas considera uma solicitação ruim que eles não desejam que seja atendida (por exemplo, a alteração proposta prejudicaria o design).

A complexidade e a especialização necessárias para lidar com grandes projetos podem dar origem a vários tipos de silos. Pode-se encontrar interesses desalinhados entre:

  • Equipes Scrum dentro de um grande projeto Scrum.
  • Funções específicas, como DevOps, Garantia de Qualidade ou Produto.
  • Diferentes stakeholder ou grupos de usuários dentro da empresa.
  • Arranjos hierárquicos, como diferentes níveis de gerenciamento.

Em última análise, as divergências devem ser resolvidas para que o projeto seja entregue. Um dos principais desafios para os líderes de projetos é descobrir qual a melhor forma de organizar projetos para minimizar o esforço perdido em batalhas políticas.

Organização para combater a política

Projetos maiores podem se beneficiar da criação de uma estrutura para que as práticas de trabalho possam ser compartilhadas em todo o projeto. Para projetos que envolvem várias equipes de desenvolvimento, os frameworks populares são LeSS (Large Scale Scrum) e SAFe (Scaled Agile Framework), além do DAD (Disciplined Agile Delivery). Existe uma tentação em toda a indústria de software de procurar respostas generalizadas para problemas específicos. É mais recomendável usar soluções que outros já descobriram pois muitas vezes economiza esforço de programação. Mas o diabo está nos detalhes. Quando se trata de chegar a uma maneira ideal de organização de um projeto, é preciso haver sensibilidade com as especificidades do projeto.

Uma prática comum é dedicar equipes a recursos específicos com uma clara intenção. Cada equipe tem membros com diferentes especializações e pretende criar uma 'fatia vertical' de funcionalidade que pode ser entregue aos usuários. Por exemplo, a equipe não conteria apenas desenvolvedores de front-end, para que não precisassem aguardar desenvolvedores de back-end de outra equipe para progredir. As equipes que fornecem resultados para outras equipes de software em vez de para os usuários são chamadas de equipes de componentes em vez de equipes de recursos.

Frameworks podem ajudar, fornecendo orientação sobre a estruturação de equipes. O LeSS recomenda a preferência de equipes de recursos, para reduzir a dependência entre equipes mas, como você detalha quais recursos são gerenciados por quais equipes depende de você. Também é muito provável que você tenha dependências entre equipes, não importa como se organize, pois sistemas complexos têm recursos entrelaçados. Além disso, haverá preocupações transversais, como princípios de design, que precisarão ser alinhados entre as equipes.

Em projetos maiores, nem todos podem realisticamente fazer parte do cenário central da visão de alto nível. Em vez disso, essa visão precisa ser comunicada de maneira eficaz. As visões evoluem ao longo do tempo e os projetos precisam definir regularmente metas específicas para fases específicas. Manter as equipes alinhadas tende a exigir tempo dos membros da equipe. O tempo gasto com isso pode ser reduzido usando representantes, mas o uso de intermediários pode levar a mal-entendidos.

O fato de existirem frameworks concorrentes é mais uma indicação de que não existe uma resposta certa para a organização ou práticas do projeto. Por mais que os OKRs por si só não produzam alinhamento da empresa, os frameworks de projetos por si só não produzirão alinhamento em projetos de software. Na melhor das hipóteses, eles fornecem ferramentas para o alinhamento. Cabe aos projetos aplicar essas ferramentas de uma maneira que faça sentido para elas. Mensagens regulares sobre prioridades e direção podem ser essenciais para o alinhamento. Quanto mais específicas e focadas, melhor.

Lidando com a política como uma equipe

E se alguém se encontrar em uma equipe de entrega dentro de um programa maior e politizado? Lidar com a política entre equipes pode ser um desafio fundamental para uma equipe de software. Mesmo para equipes que não fazem parte de programas maiores, ainda pode haver grandes desafios ao lidar com equipes externas (por exemplo, equipes de infraestrutura) ou partes interessadas.

A política pode ser mais fácil de lidar quando se pode antecipá-la. As equipes podem estar melhor preparadas para desafios políticos se anteciparem possíveis problemas no início do projeto. Uma técnica útil é mapear o que poderia ser um problema, qual seria o impacto, e quem seria capaz de ajudá-los. Isso é chamado de diagrama de impacto de impedimento.

Origem da imagem: Impediment Busting: Designing an Impediment Removal Process for Your Organization

Esses diagramas e mais são discutidos no artigo de Ken Power, Quebrando o impedimento (Impediment Busting). Se usado no início, como uma espécie de pré-mortem, pode ser usado para cultivar relacionamentos com os principais stakeholders. Pode ser especialmente útil estabelecer com stakeholders que eles atuarão como uma rota de escalada. Dessa forma, se a ajuda deles for necessária, não será uma surpresa para eles. Também pode ser possível chamar essas figuras seniores para dar as mensagens importantes para ajudar a alinhar as equipes e evitar conflitos antes que aconteçam.

Stakeholders e outras equipes naturalmente têm suas próprias prioridades e precisam ser abordados com sensibilidade. A apreciação das prioridades dos outros ajuda a formular suas abordagens de uma maneira que seja mais agradável para eles. Também pode criar possibilidades mais aparentes de negociação. Por exemplo, talvez você precise de outra equipe para disponibilizar um serviço para o seu projeto, mas atualmente eles estão sobrecarregados com outros trabalhos. Se você conseguir negociar uma data para a entrega, isso pode mostrar compreensão e ajudar a criar empatia.

Às vezes, a negociação falha ou não é possível sem uma representação mais sênior. Em alguns ambientes, atrair mais gerentes seniores pode ser uma forma mais tranquila para alinhar prioridades. Em ambientes adversos, qualquer escalação pode ser um assunto delicado. O escalonamento pode ser visto como um destaque para o fato de que as expectativas não estão sendo atendidas e pode envolver apontar o curso de ação de uma certa equipe como um obstáculo para outra equipe. Naturalmente, isso torna as coisas delicadas, pois as pessoas tendem a ser sensíveis sobre como seus gerentes as vêem e os gerentes podem ficar na defensiva quando as ações de sua equipe são desafiadas. É preciso ser cuidadoso sobre como a escalação do problema provavelmente se desenrolará se e se será escalado ainda mais na cadeia. Pode ser valioso, em qualquer ponto da escalação, enfatizar o quadro geral da organização e encontrar pontos em comum ou indicadores de resolução. Isso pode ajudar a direcionar o foco para caminhos de ação e para os impactos comerciais mais amplos.

Resolver diferenças leva tempo e energia e nem todas as batalhas são vencíveis. A construção de relacionamentos pode aumentar bastante a influência, mas apenas dentro de limitações, e pode ser especialmente desafiadora em um ambiente já politizado. Às vezes, compromissos e soluções alternativas são as melhores opções realistas. É importante não superestimar a gama de influência. Em ambientes politizados, a chave do sucesso pode ser escolher cuidadosamente as batalhas.

Sobre os autores

Ryan Dawson é um desenvolvedor apaixonado, interessado em culturas de software e open source. Atualmente, ele trabalha na Seldon, fornecendo ferramentas para implantações de aprendizado de máquina no Kubernetes. Ryan trabalha no cenário de desenvolvimento em Londres em vários setores desde 2007.

Laura Edwards é gerente sênior de produtos da hotels.com e trabalha com comércio eletrônico e finanças desde 2009. Laura combina estratégia, detalhes e empatia para criar produtos e recursos centrados no cliente.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.