5 erros de planejamento comuns no desenvolvimento de software

É difícil prever o futuro, mesmo que existam métodos específicos para isso. A realidade é que até o planejamento de um projeto simples no desenvolvimento de software é um desafio. Há muitas coisas que precisam ser consideradas e igualmente muitas coisas que podem dar errado. Está comprovado que frequentemente dá errado quando o software é entregue apenas com base em previsões. Infelizmente, isso ainda é um hábito muito arraigado.

Os erros mais comuns cometidos no desenvolvimento de software:

1. A complexidade do desenvolvimento de software é frequentemente subestimada

O desenvolvimento de software é frequentemente comparado à construção de uma casa. Parece uma boa comparação, já que à primeira vista os desenvolvedores de software "constroem" algo. Infelizmente, o desenvolvimento de software é fundamentalmente diferente da construção tradicional de casas. Quando métodos de planejamento tradicionais são aplicados, podem surgir problemas.

Nassim Nicholas Taleb descreve em seu livro "The Black Swan" dois mundos diferentes: "Mediocristan" e "Extremistan". Ambos os mundos representam dois tipos diferentes de incerteza.

Para demonstrar essa diferença, Taleb propõe o seguinte experimento:
Seleciona-se 1.000 pessoas diferentes da população. Essas pessoas se deitam uma após a outra, cabeça com pé, formando uma longa linha.

Vamos supor que a altura média de uma pessoa seja 1,68 m. A linha teria então aproximadamente 1.680 metros de comprimento. Uma linha duas vezes mais longa (3.360 m) precisaria de cerca de 2.000 pessoas (que também têm altura média de 1,68 m).

O que aconteceria se mais 1.000 pessoas se juntassem à linha existente? Desta vez, porém, incluiríamos o homem mais alto do mundo (Sultan Kösen, 2,51 m). Nesse caso, precisaríamos de apenas 1.999 pessoas. Mesmo depois de incluir um cenário de pior caso no planejamento, não há grande diferença em relação ao nosso cálculo inicial.

Agora vamos tentar o mesmo experimento novamente – mas com um cálculo diferente:

Desta vez, 1.000 pessoas diferentes são selecionadas da população e o patrimônio das respectivas famílias é registrado. O patrimônio médio de uma família nos EUA é, por exemplo, 110.000 dólares. Para este grupo, isso seria uma soma total de 110.000.000 de dólares. Em seguida, estima-se o tamanho necessário de um cofre para guardar o patrimônio total de 2.000 pessoas. Você pode calcular o tamanho de forma relativamente simples, descobrindo o tamanho necessário para o patrimônio de 1.000 pessoas e depois dobrando.

Agora pegamos novamente 1.000 pessoas, mas incluímos Bill Gates. O que poderia acontecer? A estimativa original era para um cofre que poderia guardar 220.000.000 de dólares. Agora, no entanto, precisamos de um para 77.500.000.000,00 de dólares. Qual diferença faz aqui um cenário de pior caso?

O que esses experimentos têm a ver com desenvolvimento de software?
Se você já tem experiência com desenvolvimento de software, certamente já se deparou com um problema ou outro que não conseguiu resolver. Talvez seja um bug muito difícil de corrigir. Ou é um problema técnico que você não consegue resolver com as ferramentas disponíveis. A estimativa original não estava apenas um pouco imprecisa, mas apresenta um desvio de 10%, 20% ou 500%. Esse é o mundo do desenvolvimento de software. Isso é "Extremistan" (segundo experimento), onde um incidente ou elemento pode ter um grande impacto no resultado.

A maioria dos projetos de construção são do mundo de "Mediocristan" (o primeiro experimento), onde os desvios se equilibram no todo. Vamos repetir o experimento com arranha-céus selecionados aleatoriamente e colocar esses edifícios lado a lado como dominós. Agora entra em cena o edifício mais alto do mundo, o Burj Khalifa. O resultado final é o mesmo do exemplo com a altura das pessoas ou do exemplo com o patrimônio?

Como podemos evitar confundir "Extremistan" com "Mediocristan"? É importante entender a natureza da tarefa que você está planejando em cada detalhe. Se o esforço de trabalho de um único item pode potencialmente desviar significativamente de outros itens, é aconselhável usar métodos de planejamento adequados. Por isso, os métodos de planejamento empíricos utilizados no Scrum são mais adequados para projetos de "Extremistan".

2. Não planejamos o imprevisível

Tarefas complexas requerem um tipo diferente de gestão de riscos. No planejamento de projetos tradicional, são utilizados buffers para incidentes imprevisíveis. Muitas vezes existe a crença de que o imprevisível se equilibra, recuperando o tempo perdido com o tempo ganho. Infelizmente, isso não funciona no caso de trabalho complexo.

Neste projeto, estamos confiantes de que podemos entregar na data planejada. Mas vamos supor que os fatos de fundo fossem os seguintes:

• Você é um peru
• O progresso que está sendo acompanhado é o seu peso
• Ninguém te contou sobre o Dia de Ação de Graças. O que acontece com perus no Dia de Ação de Graças?
  Como você se sente agora?

Nassim Nicholas Taleb usa essa metáfora em seu livro "The Black Swan" para ilustrar o impacto de incidentes imprevisíveis. O peru nunca ouviu falar do Dia de Ação de Graças e também não há buffer calculado. Incidentes imprevisíveis não estão previstos no planejamento convencional. Mas no desenvolvimento de software, eles ocorrem frequentemente.

Como evitar esse erro? O framework do Scrum prevê que partes individuais do software sejam entregues em intervalos regulares. O risco é reduzido entregando cedo e frequentemente – e não através de buffers planejados. Quando ocorrem incidentes imprevisíveis, existe a possibilidade de recorrer ao que foi construído até então.

3. Frequentemente fazemos promessas aos stakeholders que não podemos cumprir

Se sabemos que o desenvolvimento de software é complexo e arriscado, por que não podemos simplesmente comunicar isso aos stakeholders? Por que fazemos promessas que não podemos cumprir? A resposta é que os líderes precisam de certeza. Eles definem o orçamento, precisam ter certeza de que todas as atividades estão planejadas, querem um prazo e, claro, querem todas as funcionalidades desejadas.

Mas são necessários compromissos gravados em pedra?
A maioria dos profissionais da indústria entende o risco. Eles também entendem que frequentemente precisam assumir riscos para obter retornos e lucros. Muitas vezes, o nível de risco está diretamente relacionado ao retorno potencial. A maioria das empresas preferiria um retorno garantido. Mas sabem que o lucro de tais investimentos é tão baixo que frequentemente não vale a pena investir. Se todo mundo sabe disso, por que nem todos fazem isso?

Se os stakeholders entendem a relação entre risco e recompensa (lucro), por que não seguir o mesmo princípio no desenvolvimento de software? Em cada novo release, há um elemento de recompensa. Em todo bom projeto, há um cálculo de rentabilidade (Return on Investment (ROI)). Se uma rentabilidade significativa é esperada em um projeto, então os stakeholders devem esperar um certo risco. Portanto, converse com seus stakeholders sobre isso. Alerte-os de que talvez não recebam tudo o que foi esperado no momento do planejamento. Esse é o risco no desenvolvimento de software. Isso não significa que o risco não possa ser limitado. Mas uma discussão honesta deve definitivamente ser realizada.

Se os stakeholders querem compromissos vinculantes de você, então faça apenas aqueles que você pode realmente cumprir. Comprometa-se com a colaboração. Comprometa-se a seguir o processo acordado. Comprometa-se a trabalhar com foco em qualidade. Comprometa-se com revisão e adaptação contínuas. Comprometa-se a garantir transparência.

Converse com os stakeholders sobre risco e recompensa e explique a eles que construir um novo software segue o mesmo princípio. Discuta quais medidas de mitigação de riscos podem ser aplicadas. E comprometa-se apenas com o que você realmente pode entregar.

4. Frequentemente damos aos stakeholders a impressão de que alguns trabalhos são gratuitos

Quando prometemos aos nossos stakeholders certas funcionalidades em um determinado momento e por um determinado orçamento, eles pensam que compraram e pagaram por essas funcionalidades. Como desenvolvedor, você se comprometeu a entregar as funcionalidades. O risco agora é que os stakeholders pensem que não terão custos adicionais. Afinal, já pagaram e acreditam que todas as funcionalidades adicionais estão incluídas no preço. A única coisa com que se preocupam são os custos de eventuais alterações. Em seu livro "Predictably Irrational", Dan Ariely descreve a mudança no comportamento humano quando algo é gratuito:

"Em todos os lugares existem vantagens e desvantagens, mas quando algo é gratuito, esquecemos das desvantagens."
Se seus stakeholders entenderem que nenhuma funcionalidade é garantida até estar concluída, eles participarão mais frequentemente, tomarão decisões e farão compromissos. Insistirão que as funcionalidades importantes sejam concluídas primeiro e depois as menos importantes. Estarão menos dispostos a investir muito esforço em funcionalidades que não são tão importantes.

Portanto, você deve lembrar regularmente seus stakeholders de que não há garantia de que uma funcionalidade será entregue conforme planejado antes de ser realmente entregue.

Para fins de priorização, deve-se trabalhar permanentemente com os stakeholders durante o projeto. As Sprint Reviews do Scrum dão aos stakeholders a oportunidade regular de verificar o progresso do processo, discutir o trabalho pendente e definir prioridades.

5. Não agimos profissionalmente

Imagine que você fosse fazer uma cirurgia nos olhos. O oftalmologista sabe que nesta operação existe um risco de 10% de complicações e que, em vez de uma melhora, a cegueira poderia ser a consequência. O médico decide então não compartilhar essa informação com você. Ele acredita que poderia perder seu contrato de outra forma. Agora imagine que você faz a cirurgia e perde a visão. Então descobre que o oftalmologista conhecia esse risco, mas não o informou. Ele teria que enfrentar sérias consequências. Certamente não é o procedimento que se esperaria de um profissional.

Seria melhor se o oftalmologista alertasse sobre o risco, mas depois dissesse: "Não se preocupe, sou um ótimo oftalmologista e garanto que nada vai acontecer." Isso seria mais profissional?

Esse cenário se repete constantemente em projetos de desenvolvimento de software. Mentimos para nossos stakeholders. A razão pela qual mentimos pode ser ruim (fazer os stakeholders assinarem o contrato) ou boa (tirar o medo dos stakeholders) ou simplesmente estamos mentindo para nós mesmos. O resultado permanece o mesmo: é extremamente não profissional!

Para evitar esse erro, você precisa ser honesto, mesmo quando for difícil. Isso dá aos stakeholders a oportunidade de reconhecer os riscos e planejar de acordo. Um profissional usa e promove os fundamentos empíricos do Scrum e assim ajuda os stakeholders a lidar melhor com os riscos.

Resumo: Erros de planejamento no desenvolvimento de software

É difícil prever o futuro. Quando planejamos desenvolvimento de software complexo, cometemos muitos erros que frequentemente levam a uma baixa taxa de sucesso. Através do uso do Scrum, tais erros são evitados.

Este texto vem do blog de Steve Porter e foi traduzido por nós para o alemão.

O que faz um Product Owner?

=> Aprenda mais sobre as tarefas e responsabilidades dos Product Owners.

A Reunião de Sprint Planning

=> Processo e dicas importantes para Product Owners sobre o Sprint Planning