BT

Início Artigos Comparações entre táticas militares de guerra e desenvolvimento de software terceirizado

Comparações entre táticas militares de guerra e desenvolvimento de software terceirizado

Favoritos

Pontos Principais

  • Há paralelos entre a terceirização do desenvolvimento de software e as atividades militares que podem lançar luz sobre algumas táticas que podem ajudar a fornecer produtos de software.
  • Envolver as equipes de vendas e pré-vendas em uma missão de reconhecimento e garantir que transmitam seu conhecimento do ambiente do cliente para o time de desenvolvimento posteriormente pode atenuar problemas no projeto.
  • Iniciar o projeto com uma explicação clara dos benefícios para o cliente e do que será entregue ajuda as pessoas que não estão no dia a dia do cliente a alinhar-se com as metas do projeto e criar motivação.
  • Encantar o cliente entregando algo ótimo muito rapidamente irá direcionar todo o projeto ao sucesso.
  • O tempo entre o engajamento com o cliente e a primeira entrega precisa ser o mais curto possível, e a longo prazo, provavelmente os projetos preditivos e sequenciais serão um desafio para todos.

Introdução

Amparados por uma grande quantidade de mudanças e incertezas, os projetos de desenvolvimento de software representam, sem dúvida, uma das disciplinas mais arriscadas no gerenciamento de projetos, algo evidenciado pelo fato de nossas taxas médias de sucesso serem mais baixas do que em outras áreas de negócios mais "determinísticas". Cito aqui o relatório anual CHAOS, um estudo bem reputado no campo desde meados dos anos noventa com um banco de dados de milhares de projetos de todos os tipos e tamanhos reunidos ao longo de mais de duas décadas. Apesar de alguns debates sobre sua metodologia, este relatório mostra de maneira consistente entregas fracas ou ruins para o sucesso de um projeto de software.

Grandes esforços de grandes pensadores da indústria têm sido exercidos para aprimorar nossas ferramentas, técnicas, processos e metodologias para enfrentar esse sintoma industrial, especialmente com os desafios cada vez mais crescentes desde a evolução da era e-anything aos atuais fluxos de inundação da Revolução Digital. Todos nós nos esforçamos para alcançar esses avanços tecnológicos para melhorar nossos resultados. No entanto, no meio de todo esse jazz, ainda existem algumas práticas geralmente negligenciadas enquanto gerimos projetos de software. A razão pela qual são negligenciadas pode ser por se prestarem mais à experiência em campo do que os conhecimentos teóricos em tecnologia ou engenharia de sistemas. No entanto, são práticas e pragmáticas de uma maneira que podem melhorar significativamente nossas taxas de sucesso, ao mesmo tempo em que assumimos nossas tarefas específicas na criação de software.

O que vou tentar fazer neste artigo é lançar luz sobre três dessas práticas para você experimentar enquanto lidera o seu projeto e ver os resultados por si mesmo, caso já não tenha tentado, e em seguida, adicionar essas práticas ao seu conjunto de habilidades para momentos futuros se as considerar tão dignas como as considerei.

Nosso principal público nesta discussão é quem está liderando um projeto de software. A propósito, a discussão é neutra a metodologias na medida em que permanecemos com algum sabor ágil no que fazemos. Assim, o leitor pode seguir independentemente da metodologia particular que adota para o processo de desenvolvimento.

Sobre as origens

Por favor, não dê um passo para trás ao ver o título; não há balas ou granadas voando por aqui!

No entanto, tem evoluído uma boa semelhança entre a entrega de software e a guerra: ambos envolvem algum tipo de "batalha" de algum modo. Na guerra, é contra um inimigo. No software, é contra o "fracasso" - que é, de qualquer forma, um inimigo para qualquer negócio.

Pelo menos duas grandes obras sobre guerra, A Arte da Guerra por Sun Tzu, o antigo líder e estrategista militar chinês, e Da Guerra por Carl von Clausewitz, o general e pensador militar prussiano, inspiraram empresários com uma boa dose de táticas na administração de seus conflitos e relações empresariais.

Agora, à medida que as pessoas de software lutam pelo sucesso da mesma forma que as forças armadas lutam pela vitória, vamos explorar essa semelhança e emprestar três conceitos principais para vencer nossa batalha contra o fracasso.

Vamos seguir os truques.

Inteligência de projeto: Uma missão de reconhecimento

Os clientes não são inimigos e os projetos não nascem realmente como conflitos, mas, para fazer o seu ataque "amigável" ao seu cliente, é preciso saber o suficiente sobre seu território e sua capacidade. Esse conhecimento prévio é o que chamamos de Inteligência de Projeto.

Há uma missão de reconhecimento necessária aqui. Nunca tome isso como uma missão de espionagem, é apenas uma questão de observação ética e profunda das coisas, pois elas são naturalmente expostas a nós pelo cliente. Mas quem são os agentes que farão isso por você? Apenas olhe ao seu redor.

Vendas e pré-vendas são a ponta da lança na conquista da batalha de um novo contrato. Antes que a vitória ocorra, eles passam um bom tempo no território do cliente, estabelecendo conexões, conhecendo as coisas e as pessoas e se esforçando para que isso aconteça: a contratação. Eles, desta forma, podem ser expostos a uma boa quantidade de informações não apenas sobre os motivos puramente comerciais, mas também sobre as políticas comerciais da nova frente, suas fraquezas e pontos fortes.

A grande perda na concessão de contratos, portanto, ocorre quando essa constelação de coletores de inteligência de vendas e pré-vendas se esvai prematuramente do projeto, deixando o campo apenas para o time de implementação, sem aproveitar seu conhecimento maior sobre o "território" do cliente e colaborar no repasse de informação com profundidade suficiente para os times seguintes.

Sempre achei um bom sinal de colaboração e uma ferramenta muito valiosa para a entrada segura do projeto que recebemos uma "transferência" profunda das vendas/pré-vendas para o PM e o BA. Esse subprocesso é, na verdade, uma missão de inteligência no período de pré-contratação que a constelação de vendas precisa explorar para fornecer informações úteis ao gerenciamento e à equipe do projeto, em quatro eixos principais:

  • Os stakeholders
  • O poder de decisão e a dinâmica entre eles
  • Processo de negócios e requisitos; esta é a parte usual da história
  • As fraquezas e pontos fortes do conhecimento do cliente, tanto do ponto de vista de negócio como tecnológico.

Dessa forma, um gerente de projeto pode ter uma visão clara dos riscos e dos impedimentos que a implementação pode encontrar ao longo do caminho, portanto, poderá planejar melhor para atenuá-los. No que diz respeito aos requisitos, e mesmo que a informação ainda seja um pouco grosseira, as informações recolhidas dariam ao analista uma visão mais apurada para planejar melhor suas reuniões e iniciar sua missão a partir de uma posição mais informada, tornando seus esforços mais efetivos, esperançosamente, em períodos mais curtos.

Essa técnica pode parecer mais relevante para o lado "cronograma" do projeto, em vez da "Qualidade e Valor" da sua produção. Na verdade, essa inteligência de projeto atinge os dois lados, qualidade e programação. O trabalho de inteligência adequado evita o "ruído" no projeto que costumamos encontrar falando com as pessoas erradas ou obedecendo a decisões não autorizadas do lado do cliente. O ruído do projeto é uma fonte de ambigüidades e retrabalho ao longo do desenvolvimento, atingindo assim a programação diretamente por um lado. Por outro, toda a situação perplexa afeta a moral da equipe e se concentra nas tarefas, degradando a qualidade e o valor do produto.

Pode-se facilmente dizer que um trabalho adequado de inteligência de projeto certamente reduzirá esse ruído no projeto, dando um impulso à pontualidade, qualidade e valor da entrega.

Envolvimento estratégico da equipe: Mobilização moral

Em ambientes comuns de terceirização, a maioria do time de implementação (além do analista e do PM) não verá o cliente, e seu conhecimento sobre o projeto estará restrito a folhas de especificações, códigos, diagramas UML, cronogramas e material de teste. O que isso afeta no processo de formação de equipes?

Se começar um projeto dessa maneira sombria, bem, talvez o complete, mas às custas do lado motivacional da história. Com o tempo, tenha certeza de que seu time não se sentirá bem com o que faz e, acredite ou não, o tédio gradualmente se infiltrará em suas almas, levando-os a pensar em novos empregos.

Nas minhas palestras sobre liderar times de software, eu costumava mergulhar nas experiências do meu público fazendo uma pergunta: "Qual é a primeira coisa que você faz quando começa um novo projeto?". Quase sem exceção, costumava obter respostas sobre a mobilização de recursos: planejamento de capacidade, orçamento, EAP e atribuições de tarefas - pura coisa de "gerenciamento".

O problema aqui é que não há habilidade de "liderança" nessa resposta, apenas de gestão. E a diferença é grande! A resposta certa, de volta à analogia militar, é motivar a equipe em torno do novo alvo e energizá-lo para que seu trabalho seja feito com prontidão para assumir algum estresse ao longo do caminho. Esta é a moral da sua batalha.

Como fazer isso? A resposta é simples: faça o kickoff interno com o time de implementação como uma cerimônia que alinha todo mundo com o lado comercial do novo empreendimento. Os palestrantes são principalmente o PM, o analista e também pode ser alguém de vendas. O objetivo é orientar o time de implementação para um panorama geral sobre:

  • O lado comercial do aplicativo e a maneira como ele atende o cliente.
  • O valor de mercado do aplicativo para o cliente.
  • O valor estratégico do aplicativo para a empresa.
  • Os desafios previstos no aplicativo, no que diz respeito a negócios e tecnologias usadas.

Permita perguntas, discussões e opiniões. Certifique-se de que todos estejam envolvidos. Um novo projeto é uma nova chance de aprender e prosperar com sua equipe e empresa, então vamos fazer isso direito.

Naturalmente, se entrará em mais detalhes sobre os aspectos do negócio à medida que as tarefas forem atribuídas. Apenas certifique-se de que a perspectiva total de negócios não seja perdida dentro de blocos de código, pilhas de papéis com esboços e tabelas.

Na minha experiência, a abordagem tem um impacto bem observado no comportamento da equipe, portanto, performance:

  • Adiciona uma nova dimensão à perspectiva técnica pura dos desenvolvedores, ajudando a diminuir o estado de aborrecimento que os atinge quando trabalham em algo puramente técnico com suas ferramentas que não mudam com frequência.
  • Deixa-os com um "sentimento de valor e respeito". Envolvê-los em tal camada de informação é um sinal claro de que os trata como "parceiros de sucesso" e não apenas como "executores de tarefas", com todo o impacto positivo em sua moral, portanto, em desempenho e qualidade.
  • Ajuda a equipe a se concentrar em uma missão. Isso significa simplesmente melhor colaboração e produtividade ao longo do caminho.

Com essa tática simples, estará a caminho de fazer uma boa decolagem para o seu destino com sua equipe e seu cliente; o que é puro sucesso.

A magia da primeira entrega: O princípio da surpresa

Com certeza, a guerra não admite nada melhor como isso, a vitória: o princípio da rapidez do ataque, ou tomar de surpresa, sendo todas táticas bem testadas de guerra! Aqui não é uma guerra para destruir, mas uma guerra para entregar.

Vamos admitir, nada define sua imagem aos olhos de um cliente mais do que sua primeira entrega. Tem que ser extremamente útil, impressionante, robusto, estável e pontual. Não precisa ser grande, mas deve atender a esses atributos antes do tamanho da funcionalidade incluída. Na verdade, o espírito da escola ágil está na escolha sábia do valor comercial correto (ROI) para formular a primeira entrega, deixando-nos preocupados com a qualidade e a robustez desse marco tão especial que nunca deve ser comprometido em nenhuma circunstância.

O risco é enorme aqui, se deixar de atender a essa expectativa em sua primeira entrega, seja no prazo ou na qualidade, seu cliente terá uma vantagem sobre você durante todo o período do projeto: uma situação que é difícil de resolver e que implica muitas conseqüências certamente pouco a favor do time de desenvolvimento.

Por outro lado, se conseguir fazer um bom show na primeira entrega ou no sprint, tenha a certeza de ter tomado a posição certa para "liderar" o projeto, incluindo a frente do cliente "tacitamente" até o final do negócio. Apenas continue assim!

Aí vem, a propósito, uma das deficiências do waterfall, ou a escola determinista na entrega. O waterfall geralmente endossa fases mais longas para construir e entregar funcionalidade e voltar com isso para o cliente em fases. A menos que esteja lidando com um alto grau de certeza, como no caso de construir um produto de seu projeto para o mercado aberto e não para atender às necessidades e cronogramas específicos do cliente, esses períodos mais longos de descomprometimento com o cliente representam um chamado para perder energia, entusiasmo e, portanto, começar a sofrer negligência de todos os lados. Além disso, mesmo que forneça algum produto que não seja "software funcional", como um documento de design de acordo com o plano, pergunte a si mesmo quem no lado do cliente lerá, criticará, revisará ou comentará e avaliará o tempo (e responsabilidade) por tudo isso? Todos nós conhecemos as dificuldades aqui, acredito. Ver uma boa parte dos sonhos dos clientes se tornar realidade em breve é, de longe, muito diferente do cliente passar o tempo lendo a mais completa e elegante pilha de papel de qualquer tipo.

Isto é o que deve ser feito, um ataque rápido!

Mas o que acontece se o seu cliente não estiver tão pronto e respondendo tanto quanto é preciso para fazer seu primeiro ataque rápido? Se fez essa pergunta, então o considero um praticante digno vindo com uma situação do campo a ser considerada! Claro, isso é um impedimento que temos que pensar em como superar. Os truques para superá-lo estão prontos, mas diria que vamos levar isso para uma discussão separada em um artigo dedicado, esperançosamente, em breve.

Finalmente: Cuidado com a Zona Perigosa

Não vou deixar essa tática de ataque rápido sem ênfase em um fato conceitual no processo de entrega, a Zona Perigosa, como a vivenciei e batizei. Isto é, na verdade, o período entre o envio de um pagamento inicial por um cliente até a primeira entrega do produto contratado.

E por que é perigoso?

O software é um produto intangível por natureza, não se o obtém diretamente da prateleira. Mesmo se falamos de soluções empacotadas, ainda há algum atraso e esforço humano para implementar e personalizar as necessidades do cliente. Portanto, não é como hardware ou carros, por exemplo, onde se recebe o que se paga imediatamente ou talvez com um prazo de entrega definido, mas ainda com uma funcionalidade tangível que os clientes conhecem desde o início. Isso significa que um cliente pagante não sentirá o valor que pagou, exceto quando for instalado o primeiro grupo de funções, um grupo que atenda (ou exceda) suas expectativas.

Quando esse período de tempo se arrasta, o risco no projeto sobe exponencialmente, e começa-se a encontrar um caso de "hipodinâmica" no lado do cliente, que refletirá sobre a equipe e afetará negativamente o projeto. Uma situação que é muito difícil de recuperar, infelizmente.

Conclusão

Construir software é uma batalha pelo sucesso. A partir do momento em que o contratamos para concluí-lo, ficamos vulneráveis a riscos decorrentes de mudanças, incertezas, comportamento do cliente ou outros fatores internos relacionados à equipe. Tomar algumas táticas da guerra é uma boa ideia para lidar com tudo isso. Certifique-se de que tenha feito o exercício corretamente de "Inteligência de Projeto" para conhecer seu cliente antes de se envolver. Motive seu pessoal e dê a eles uma boa visão do valor do que estão fazendo e o impacto para a empresa, bem como em suas carreiras profissionais. Surpreenda seu cliente com uma primeira entrega poderosa que o deixe sob seu controle tácito pelo resto do projeto. Reduza o tempo para entregar o primeiro fragmento de funcionalidade, ou a Zona de Perigo, ao mínimo possível.

E então, gerencie seu projeto.

Sobre o autor

Medhat Sabry é consultor de desenvolvimento de software, palestrante e escritor, dirigindo-se à comunidade de desenvolvimento sobre sua própria iniciativa web autoconstruída chamada Techstamina, junto com outros canais de redes sociais e profissionais. Permanecendo no coração do processo de entrega de software por quase quatro décadas, Medhat teve uma sólida exposição aos desafios emergentes da indústria de desenvolvimento que formou sua paixão em ajudar desenvolvedores e empresas a desenvolver sua resistência profissional para enfrentar as pressões e desafios cada vez maiores no mercado de software atual.

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.