BT

Maximização de resultados com a Descoberta Intencional

por Fernando Ultremare em 29 Jun 2011 |

Deliberate Discovery (descoberta intencional) é o nome dado por Dan North ao seu modelo pragmático para maximização dos resultados em projetos de software. Segundo este modelo, devem ser concentrados os esforços para remover ou reduzir as restrições que limitam a produtividade, ou seja, deve-se focar nos pontos que realmente precisam de atenção.

Em seu primeiro post de introdução ao modelo, North explica que "a capacidade de aprender é a verdadeira restrição" e que "o desconhecimento sobre aspectos relevantes do problema é o único grande impedimento à produtividade." Um experimento sugerido por North, proposto inicialmente por Ashley Johnson, ilustra bem a ideia geral:

Imagine um projeto recente ou um conjunto completo de tarefas da sua equipe que seja representativo (e de preferência que tenha durado alguns meses). Quanto tempo esse trabalho demorou para ser concluído de ponta a ponta, da concepção até a entrega? Agora imagine fazer o mesmo projeto novamente, com a mesma equipe e as mesmas condições iniciais, com a diferença que sua equipe já sabe tudo o que aprendeu durante o projeto. Quanto tempo levaria para concluir o projeto nessa segunda vez?

Isso nos remete ao ponto principal do modelo de Dan North: como obter ganhos reais de produtividade, atuando intencionalmente na aceleração do processo de descoberta daquilo que “não sabemos que deveríamos saber”, que pode ser entendido como um "desconhecimento de segunda ordem". 

Em oposição a esse modelo, está o que ele chama de “descobertas acidentais”, que ocorrem por acaso, muitas vezes depois de já terem causado grande impacto negativo sobre projeto.

Segundo North, “o desconhecimento atua em diferentes eixos”: podemos desconhecer aspectos fundamentais em diversas áreas que possuem influência direta no resultado do projeto.

Pode-se desconhecer aspectos relevantes das tecnologias sendo utilizadas, a amplitude de opções tecnológicas disponíveis, desconhecer uma abordagem diferente para a solução do problema ou uma melhor forma de articulá-lo – que poderia tornar sua solução mais simples e óbvia. Pode-se não conhecer sobre as pessoas em sua equipe, suas aspirações, medos, motivações, seus relacionamentos uns com os outros dentro e fora da organização. Pode-se desconhecer sobre as restrições organizacionais de seu cliente, sobre eventuais integrações com terceiros, sobre as pessoas com as quais se deveria estar trabalhando para melhorar o relacionamento...

Mas como então atacar um problema de que nem ao menos de sua existência somos conscientes? North destaca que temos que superar uma tendência natural das pessoas de desviar sua atenção de problemas como esse, negando instintivamente a condição de “desconhecimento do desconhecimento”. (Este processo é explicado em mais detalhes no livro "A Mind of Its Own" da psicóloga australiana Cordelia Fine). 

North ilustra a tendência de desviar-se do desconhecido citando a popular história do bêbado que perde suas chaves em um local escuro e passa a procurá-las apenas sob a luz de um poste, por ser este o único lugar em que poderia enxergar as chaves.

Nessa linha, North faz uma forte crítica à nossa atual obsessão pelas técnicas de planejamento ágil, como histórias de usuário e estimativas por pontos ou dias ideais. Estas técnicas, quando utilizadas de maneira equivocada, produzem uma falsa sensação de conhecimento sobre as dimensões do problema sendo resolvido. Criam uma luz artificial que nos impede de buscar o entendimento sobre as verdadeiras restrições que estão limitando a produtividade. 

Na sua apresentação realizada na QCon São Francisco deste ano, Dan North resumiu a prática da descoberta intencional da seguinte maneira:

  • Presuma que você está sempre trabalhando dentro do desconhecimento
  • Presuma que um eixo específico do seu desconhecimento é a sua restrição atual
  • Melhore a produtividade atacando ativamente o desconhecimento

E prosseguiu através da exposição de uma série de técnicas que tem aplicado em seus próprios projetos e que trazem na essência a criação de um ambiente em que o aprendizado é otimizado. Dessa maneira, “as entregas (ou a produtividade) acontecerão sozinhas”. A lista completa das técnicas sugeridas pode ser encontrada nos slides da apresentação; aqui mostramos uma seleção dessas técnicas:

  • Contanto que o desconhecimento esteja sendo reduzido, não tema a "parálise na análise" (analysis paralysis).
  • Siga princípios de etnografia: investigue as reais preocupações dos usuários e clientes, e também identifique com o que deveriam se preocupar.
  • Faça o design de forma a permitir descobertas e aprendizado: identifique o que deu errado e o que está acontecendo de errado agora.
  • Coloque uma versão do sistema em produção o quanto antes: coloque qualquer coisa em produção.

Seja através dessas ou de outras técnicas, North apresenta acima de tudo um caminho de muitas possibilidades e antecipa que “às vezes não será possível conhecer o desconhecido”, mas conclui que “para todos os outros casos, existe a descoberta intencional”.

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.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Testes Automatizados by Eder Ignatowicz

Fernando,

Eu entendi que a Descoberta Intencional lida com todos os aspectos do desenvolvimento de software, mas você acredita que testes automatizados podem criar uma luz artificial ?

Testes exploratórios ajudariam a levar luz as regiões escuras do software ?

Muito Bom by Paulo Murer

Imaginei a cena que voce descreveu. Me lembrou de quando temos que escrever a redação de vestibular. Quanto tempo se gasta fazendo o rascunho e quanto tempo se gasta passando a limpo? E rola entregar sem passar a limpo? Eu voce ja inicia a prova planejando um tempo para passar a limpo sua redação.

Re: Testes Automatizados by Fernando Ultremare

Eder,

Acredito que pode criar sim essa luz artificial.

Os testes exploratórios ajudam muito, nossa equipe tem sentido isso na pele. Quanto mais complexo o sistema, mais casos extremos que são difíceis de serem cobertos pelos testes automatizados.

Dan North sugere também a utilização de testes randômicos.

Software em produção também ajuda nessa questão. O problema aqui são os erros e seus impactos, que as vezes podem causar danos irrecuperáveis, como perda de informações.

Nessa caso, uma abordagem, que também utilizamos com sucesso, é possuir mecanismos de auditoria em informações críticas do sistema, que permitem monitorar e reprocessar os dados sempre que necessário.

Um abraço

O que há de ruim no empirismo? by Daniel Moreira Yokoyama

Eu não sei se entendi direito o que isso tudo quer dizer.
Afirmações como "dar tiros no escuro enquanto somos ignorantes do que estamos fazendo" e a analogia com o bêbado, faz entender que não estamos falando de uma maneira comum de se fazer software.
Se o método é empírico, não estamos falando de algo que não conhecemos, mas algo do qual conhecemos aos poucos à medida em que o todo se revela.
É como fazer um mapa de uma região: você é incapaz de fazê-lo antes de percorrê-la. Mas também não vai querer ir direto ao ponto mais distante antes de começar a desenhar o mapa. Pode simplesmente desenhá-lo à medida que anda pelo terreno.
A ignorância não pode ser o fator que mais te restringe, mas é justamente enquanto você deixa de ser ignorante que você já cria algo de valor para ser entregue. E isto se provou ser bem mais vantajoso do que tentar encarar toda a ignorancia de uma vez só como se fosse possível ter o conhecimento do todo antes de começar qualquer coisa.
Ou talvez eu não tenha entendido direito o que o texto quer dizer.

Re: O que há de ruim no empirismo? by Fernando Ultremare

Oi Daniel, muito obrigado por suas observações!

Então, veja o que você disse:

"é justamente enquanto você deixa de ser ignorante que você já cria algo de valor para ser entregue"

É exatamente essa a idéia da coisa. Pois quando deixamos de ser ignorantes, geramos mais valor, mais rápido. Concordo que pode haver alguma confusão com as palavras ignorância/aprendizado e onde está a restrição em si. Mas é essa a idéia mesmo.

A sua analogia do mapa também é muito boa. Existem diferentes maneiras de se descobrir um mapa (quem joga Warcraft sabe bem disso), por exemplo:

Você pode enviar um batedor (scout) para percorrer pela maior parte do mapa o mais rápido possível. Nessa missão, o batedor não para para olhar com detalhes o território, mas já percebe as principais características do terreno e até mesmo da estratégia do adversário. Aquilo que o batedor encontrar no meio do caminho, vai fazer toda a diferença em qual será sua estratégia dali para frente.

Realmente, não estamos falando de uma maneira comum de se fazer software e nenhuma metodologia específica.

Como você mencionou, em um modelo empírico, também iremos deixar de ser ignorantes sobre aspectos importantes do problema, a diferença está no fato dessa descoberta ser acidental ou intencional. Em quais caso vale mais a pena ser acidental ou intencional, também é uma boa pergunta.

Quanto do investimento em atividades de descoberta intencional será pago pelo ganho que as descobertas nos trarão, contando que sejam antecipadas em vista de uma descoberta/aprendizado acidental?

Um abraço!

Re: O que há de ruim no empirismo? by Daniel Moreira Yokoyama

Até entendo... mas não sei exatamente se isto é bom ou não. Teria que entender melhor a aplicação disto pra tentar ver de fato se é uma vantagem ou não.
Vou ler mais a respeito.
Mas acho aqui que essa classificação de descobertas "intencional" e "acidental" um pouco imprecisa.
Quando desenvolvemos usando o empirismo da agilidade, a descoberta não é nem intencional nem acidental. Eu tenho alguma idéia do todo (por mais que um scout, possa me dar as principais características, ele não vai me dar detalhes... e num projeto de software, você sempre tem o que eles chamam de "Big Picture", mas sem os detalhes) e vou descobrindo os detalhes a medida que avanço.
Não sei classificar esse tipo de "descoberta" nem como intencional e nem como acidental. Na verdade eu acho que a melhor palavra é "empírica", por que a palavra define tudo: à medida que avanço, descubro.
É claro que todos nós gostaríamos de descobrir tudo o quanto antes, mas foi aí que descobrimos nossa falha: não somos capazes de fazer isto. As mudanças dos detalhes específicos, a falta de capacidade do usuário de saber o que realmente quer e até mesmo os problemas inerentes da interpretação da análise e o BDUF, tudo isso causou na convergência que estamos fazendo hoje.
De qualquer forma, como já disse, vou ler melhor a respeito. Depois volto aqui pra comentar.

Re: O que há de ruim no empirismo? by Fernando Ultremare

Ok Daniel, realmente é um assunto que da para explorar bastante... Será muito bom se você agregar mais com sua visão!

Apenas para complementar, pelo que entendi, talvez você está fazendo um paralelo do modelo big design upfront (RUPiano) ao modelo ágil de desenvolvimento, que é mais orgânico. Mas não é por esse caminho que acho mais correto olhar a prática. Também não se trata de uma técnica para desenho da arquitetura do sistema ou levantamento de requisitos, etc.

Segundo a teoria das restrições, todo sistema possui um único ponto de gargalo. Não importa quão eficiente as outras partes do sistema sejam, a capacidade geral desse sistema estará limitada por seu gargalo. Quando esse gargalo é eliminado, outro ponto do sistema será o seu novo gargalo, e assim por diante.

No desenv. de sw, os gargalos podem ser inúmeros em diferentes aspectos: técnicos e humanos.

O modelo então está relacionado à descobrir ativamente esses gargalos que, no fim das contas, são os maiores vilões da produtividade do projeto. O problema é que eles atuam ou podem estar dormentes, sem nosso conhecimento, por um bom tempo. Quando então são descobertos acidentalmente (ou empiricamente), já fizeram um bom estrago.

Por exemplo, note que nem todas as situações poderão ser descobertas: a saída de uma pessoa chave da equipe por razão inesperada, uma nova lei que muda as regras do jogo, a mudança de um stakeholder importante, a descontinuidade de um fornecedor de uma tecnologia utilizada no projeto... e por ai vai.

Um abraço!

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

7 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT