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.

abr 242017
 

A OAT Solutions participou do Agile Trends Brasil, que aconteceu nos dias 12 e 13 de Abril, em São Paulo.
Com o destaque de integrar uma rede internacional de empresas que são ‘Atlassian Solution Partner’, e por oferecer soluções em consultoria, treinamentos e ferramentas que cobrem completamente o ciclo de vida relativo a iniciativas de transformação ágil, o estande da OAT Solutions teve intensa movimentação durante os dois dias do evento.
Segundo Álvaro D’Alessandro, diretor da OAT Solutions, “foi uma honra patrocinar um dos maiores eventos da comunidade ágil e foi muito produtivo para trocar experiências, encontrar clientes, amigos, fazer novas conexões e compartilhar algumas de nossas contribuições tendo ao nosso lado a Atlassian”.

Veja a seguir fotos da presença da OAT Solutions no Agile Trends Brasil 2017:

Continue reading »

abr 062017
 

Há poucos dias, enquanto esperava pelo início de uma reunião em um cliente, tive a oportunidade de presenciar algo curioso; imagine a cena: 11 pessoas, de uma equipe que começou a utilizar Scrum há poucos meses, reúnem-se em pé em uma “área de convívio” ao lado das salas de reunião e começam a conversar sobre as atividades do projeto.

Tudo levava a crer que a equipe estava realizando sua Reunião Diária, exceto pelo que pude acompanhar…

Continue reading »

fev 102017
 
Muitas vezes ao falar sobre o cotidiano de atividades em projetos que usam Scrum, algumas pessoas erroneamente usam o termo ‘cerimônia’ para se referir à execução de um conjunto muito comum, com o qual os profissionais tornam-se familiarizados: a Reunião de Planejamento da Sprint, a Reunião Diária, a Revisão da Sprint, a Retrospectiva da Sprint e  o  contêiner das anteriores: a Sprint propriamente dita.
out 172016
 
A OAT Solutions esteve presente no Atlassian Summit 2016, realizado entre os dias 10 e 13 de Outubro de 2016, na cidade de San Jose, Califorinia
Como único Atlassian Expert Brasileiro presente como patrocinador, a OAT teve acesso privilegiado a dezenas de parceiros de todas as partes do globo, que fornecem AddOns que agregam muito valor aos produtos Atlassian, como JIRA, Confluence, JIRA Service Desk e Bamboo entre outros.
Foi também uma oportunidade de ouro para trocar experiências com profissionais de algumas das maiores organizações internacionais que usam os produtos Atlassian, como Google, NASA, Comcast, Electronic Arts, Marinha dos Estados Unidos (US Navy) e Samsung, além de compartilhar em primeira mão da visão inovadora que a Atlassian tem para o desenvolvimento de software, gestão de serviços (ITSM) e tendências como Agile em larga escala, DevOps e MicroServices.
ago 272016
 

Visão geral

Quando as empresas avaliam ferramentas de automação de teste para testes web, frequentemente surge a pergunta: Qual é a vantagem de usar o Rapise ao invés de Selenium?

Ou ainda de modo mais amplo: Por que pagar por uma ferramenta comercial ao invés de usar uma gratuita?

À primeira vista, ambas as ferramentas parecem endereçar os mesmos desafios ao automatizar testes na web, mas é muito importante compreender outros aspectos ao comparar as duas ferramentas.

 

Continue reading »