fev 022018
 

Autor – Ivar Jacobson, tradução Anderson Barcat

            Para diminuir o “gap” entre Negócios e TI nós precisamos fazer com que joguem no mesmo time.  Eu comparo este time com um time de futebol, no qual os participantes não são só especialistas mas também generalistas – todos podem chutar a bola quando convocados.

O “time” Negócios+TI  deveria funcionar de uma forma similar. Apesar de ter funções especializadas, todos devem contribuir para alcançar o objetivo comum, afim de que todos possam ser bem sucedidos.

Mas eles fazem isto? Se eles fossem um time de futebol, provavelmente eles não ganhariam muitos, ou nenhum, jogo.  Estendendo esta analogia com o futebol, a área de negócios muitas vezes age como o proprietário ausente que quer que a equipe vença, mas não quer tomar o seu tempo para estar diretamente envolvido.

Ao invés disto, eles tentam “micro-gerenciar” à distância, exigindo um plano “play-by-play” detalhando quem vai marcar o gol e quando, e repreende a equipe por não aderir ao plano.  Eles dizem que vão providenciar os jogadores (representantes de negócios e “Product Owners), mas estes jogadores estão geralmente ausentes, por estar ocupados fazendo outras coisas. Como o proprietário da equipe, eles também não querem perder muito tempo para contratar os melhores jogadores e técnicos, mas eles ainda sim querem ganhar dos times que estão dispostos a gastar mais.

Mas do lado de TI, muitas vezes isto não é melhor.  Ao invés de fornecer provas convincentes que a equipe está fazendo progresso, se escondem atrás de ‘scouts’ detalhados e jargões técnicos. Eles alegam que não podem ganhar até receber os melhores uniformes, um bom campo de treino, as melhores chuteiras e um novo estádio.  Eles passam muito tempo desenvolvendo novas estratégias e ‘scouts’ e pouco tempo no campo realmente treinando. Eles exigem que o proprietário revise e aprove todas as jogadas, e se uma jogada não funciona, eles culpam o proprietário por não fornecer um bom feedback.  Você está começando a ver as conexões? Talvez o futebol e o software não sejam tão diferentes assim!  Para ser mais direto, isto é o que geralmente acontece:

 

A área de Negócios:

  •  geralmente quer ditar o preço (ou custo) e a agenda mesmo antes de realmente entender o que eles realmente precisam ou qual o problema estão solucionando.
  • é raramente responsável pelos benefícios dos negócios reivindicados  nos planos de negócios. Os planos de negócios são muitas vezes “manipulados” para justificar um projeto que a área “quer fazer” – mas o time de projetos é responsabilizado  pelas estimativas de custo e cronograma com base em uma “lista de desejos” mal concebida de recursos e em um plano de negócio “excessivamente otimista”.
  • frequentemente sente que qualquer coisa menos do que atingir todas as expectativas iniciais, não importa quão mal compreendido, é um fracasso.
  • muitas vezes não é claro sobre suas reais necessidades e tende a demandar várias coisas que não precisa.
  • quando muda de opinião sobre o que realmente eles precisam, raramente ajustam o custo e cronograma original.
  • muitas vezes não está disposta a investir muito tempo em melhor entender suas necessidades porque isto vai “tomar muito tempo”, e ainda sim a falha na entrega será considerada uma falha de TI
  • muitas vezes não está disposta a disponibilizar acesso as pessoas com maior conhecimento porque elas são consideradas muito valiosas para serem tiradas dos seus trabalhos regulares, mesmo que o custo do projeto seja maior e a necessidade de sucesso ainda maior.
  • muitas vezes se refere ao desenvolvimento de software como uma habilidade “commodity” que eles podem terceirizar para o fornecedor com menor custo. Eles não valorizam profissionais de desenvolvimento que realmente entendem os negócios deles e geralmente não estão dispostos a investir no desenvolvimento da TI da organização como um recurso estratégico.  Mas TI não é uma vítima sem culpa neste jogo:

A área de TI:

  • geralmente aceita a situação, sentindo que eles não tem poder para fazer algo a respeito. Mesmo quando eles sabem que não podem fornecer estimativas de custo e cronograma com apenas uma vaga compreensão das necessidades, eles fornecem de qualquer maneira, e essa “vaga estimativa” torna-se a medida contra a qual o projeto é responsabilizado, mesmo quando se trata de uma  suposição “mal informada”.
  • muitas vezes carece de Gerentes de TI  que entendam de fato sobre desenvolvimento de software, e muitos não tendem a ter interesse em ser melhor informados. Como resultado eles acham que as pessoas são “intercambiáveis”, que um bom processo pode compensar a falta de habilidade e experiência, e que o sucesso significa entregar o que negócios pede ao invés do que ele realmente precisa.
  • costuma medir as coisas erradas -como a produção de artefatos – ao invés de medidas como a qualidade, redução de riscos, e o progresso real medido com a execução do software testado.
  • tende a ter uma pequena participação, não estratégica, com foco em “cool technology”, que tem pouca ligação com os benefícios aos negócios. Eles não tem a confiança de negócios  para contribuir como solucionadores de problemas estratégicos, muito em virtude de que eles não demonstram que realmente entendem o negócio e como aplicar a tecnologia para criar valor nos negócios.  Eles esperam que negócios falem o que eles devem fazer ao invés de oferecer soluções.
  • a tecnologia em si é imatura e não é bem compreendida, e as decisões algumas vezes são tomadas por “modismos” e o desejo de usar a mais nova tecnologia.
  • E Finalmente, os membros do time de TI frequentemente não respeitam as contribuições uns dos outros.  Desenvolvedores abaixam o nariz para testadores e analistas de negócios. Analistas de negócios tendem a ser indiferentes sobre se o que especificaram pode mesmo ser desenvolvido (isto é um mero detalhe), e os testadores muitas vezes não tem as habilidades para fazer mais do que testes manuais, uma vez que isto requer habilidades reais de desenvolvimento.

Há realmente uma forma simples de  quebrar estas barreira para efetivamente se trabalhar como um time?  SIM, e não.  Algumas mudanças são simples no conceito mas difíceis na execução. Outras mudanças requerem que a relação entre Negócio e TI seja repensada.  O primeiro passo a dar é parar de pensar sobre Negócios como “o cliente” e TI como “o fornecedor” -  eles precisam jogar no mesmo time, juntos, para poder ganhar.

dez 092013
 

Dada a importância da relação entre o Gerente de Projetos e Analista de Negócios em uma equipe de projeto , como uma organização pode nutrir essa relação fundamental  e , no processo, garantir um melhor desempenho da equipe ?

Aqui estão seis estratégias básicas que você pode empregar :

1 – Treinar os Gerentes e Analistas na metodologia e nos papéis.  Cada um deve compreender mutuamente as responsabilidades e concordar na forma de obter resultados.

2 – formar equipes de duas pessoas, de gerentes e analistas que possam trabalhar juntos mais de uma vez , para que eles possam conhecer os pontos fortes e fracos de cada um.

3 – Recompensar a colaboração dos gerentes e analistas que apresentam as melhores características de seus respectivos papéis.

4 – Escolher os gerentes e analistas que compreendem naturalmente o valor do comprometimento e que trabalham ativamente em conjunto para gerenciar riscos.

5- Desenvolver uma mentalidade onde os profissionais se comuniquem muito para garantir que nada seja perdido.

6- Por fim, prestar muita atenção para as interdependências. Umas das principais áreas estratégicas da sobreposição entre as funções do gerente e analistas, por exemplo, é a área de definição e gestão de escopo.  Esses profissionais devem estar profundamente envolvidos em discussões como esta que podem parecer simples, mas podem fazer estragos em cronogramas e orçamentos.

 

Documento original publicado por   Cathy Cecere – modernanalyst.com  – Tradução Livre – Anderson Barcat