Segundo Nassin Taleb, um Cisne Negro é um evento raro, exerce um impacto extremo e só conseguimos desenvolver explicações após sua ocorrência, tornando-o explicável e previsível.
São alguns exemplos de Cisne Negro: o ataque de 11 de setembro às torres gêmeas em Nova York, o estouro da bolha do subprime nos Estado Unidos em 2008 e a recente queda do preço dos comodities, como por exemplo, a queda do preço do barril do petróleo, um dos fatores de que exerceu um grande impacto em nossa economia. Sim, estamos diante da imprevisibilidade.

Como os Cisnes Negros afetam os projetos da TI? Estamos blindados em relação a tais eventos ou qual a nossa resiliência quando ocorrem?
Proponho a análise de alguns eventos comuns e previsíveis, mas que são ignorados na análise de riscos do projeto, apresentando um turbilhão de justificativas após a sua ocorrência.
Quantos projetos foram entregues dentro do prazo, sem ultrapassar o orçamento, atendendo as necessidades dos clientes? Qual a nossa assertividade na sagrada relação Prazo x Custo x Escopo?
Qual a distorção em outra relação, Planejado x Realizado?

Tais indicadores assombram gestores de projeto, o time de desenvolvimento, os solicitantes e os patrocinadores. Mas, é mesmo possível planejar com exatidão os projetos de TI que durarão acima um ano?
Apoiamos o exercício de nossas previsões na analogia com projetos da construção civil. Justificamos a utilização dos mesmos paradigmas, mas até que ponto consideramos a natureza distinta entre eles? Na construção civil, estamos prevendo e planejando resultados de um produto tangível e mesmo assim, tais projetos não estão imunes aos Cisnes Negros.
Durante o planejamento de um projeto de TI, a fim de entregarmos um “cronograma” que deixará nosso indicador verde no escritório de projetos, chutamos prazos, adicionamos alguma gordura ou adotamos um percentual de gordura institucionalizada, como se pudéssemos minimizar incertezas. Entretanto, concluído o cronograma, observamos sua transformação em clausula pétrea ou dogma. É inadmissível e imperdoável alterá-lo. Admitir atrasos, mais custos ou corte do escopo? Não!!!! Muitas metas serão comprometidas ao ousarmos tanto. Como o pecado original, esta é a gênesis das frustrações, noites em claro e cancelamentos dos projetos de TI.
Quantos sistemas são construídos, raramente utilizados ou até esquecidos, ocupando espaço nos servidores? Quantos outros, obsoletos na entrega, perderam o time to market das organizações? Considere também a adoção de critérios dúbios, para corte de escopo, quando o projeto se arrasta em atrasos.
Assim como no mercado financeiro, nós simplesmente não podemos prever.
“Acho escandaloso que, apesar do histórico empírico, continuemos a projetar o futuro como se fôssemos bons nisso, usando ferramentas e métodos que excluem eventos raros. Previsões são firmemente institucionalizadas em nosso mundo.
Temos uma queda por aqueles que nos ajudam a navegar pela incerteza, sejam eles adivinhos, acadêmicos (chatos) “bem-publicados” ou servidores civis utilizando matemática fajuta.” [Taleb]

O coaching e os treinamentos da Massimus são dedicados a boas prática do SCRUM.

O SCRUM nos permite planejar de forma iterativa, quebrando o paradigma do modelo cascata para o desenvolvimento de software; mantém o foco do time e dos stakeholders no produto a ser construído – pensamos o produto muito cedo.
Um dos fatores de sucesso em projetos que adotam o SCRUM é importante que o PO – Product Owner esteja comprometido com o projeto e com produto. Não basta criar uma lista de users stories – muitos Backlogs me surpreenderam com a ousadia de chamar aquilo de user story – sortear a ordem de priorização e estabelecer números aleatórios para o tamanho das mesmas. Esta é a fórmula certa para sermos atingidos por qualquer imprevisto e totalmente abatidos por Cisnes Negros.
Um Backlog estruturado e bem administrado é fundamental. As principais características que o qualificam como bem estruturado são: user estories que entregam valor aos stakehoders; priorização e tamanho das users stories realistas.
Durante as cerimônias de planejamento, atribuímos prioridade alta para as users stories com valor para o cliente, mas não podemos colocar no início do Backlog users stories carregadas de incertezas técnicas e/ou de negócio, já vi isto também.
Backlog estruturado e bem administrado nos permite encontrar o MPV – Minimum Viable Product, em português, o Produto Mínimo Viável.

Não podemos prever, mas o SCRUM possui ferramentas para mitigarmos incertezas e a Massimus pode e vai ajudá-lo nessa empreitada.

Sara Alves é Agile Coach da Massimus.

Taleb, Nassin Nicholas, 2007, A Lógica do Cisne Negro o impacto do altamente improvável, BestSeller, Rio de Janeiro.
Picheler, Roman, 2010, Agile Product Management with SCRUM, Addison-Wesley, Canada