Deixem-me fazer-vos uma pergunta: Como gestor de produto ou scrum master, sente que há um ponto de viragem em que a consistência se transforma em tirania?

P>Ponho esta questão a alguns pobres e insuspeitos peeps em algum produto recente e Agile Meetups aqui na área de Raleigh. A minha recompensa foram numerosas afirmações de que tais tolos hobgoblins existem.

Mais recentemente, depois de ter colocado a minha pergunta numa variedade de canais de comunicação social, estou convencido de que nós, no negócio da entrega de software, por vezes escravizamo-nos de facto em nome da consistência.

Por isso, vamos desempacotar isto um pouco e ver se não conseguimos chegar a acordo sobre o que é que um tal ponto de viragem pode parecer …., examinando primeiro o que não é.

Consistência Sábia

Um exemplo de consistência benéfica para os gestores de produtos está na forma como elaboramos as nossas histórias de utilizadores. Por exemplo, gosto de seguir o princípio INVEST – NÃO como uma receita de placa de caldeira – mas sim como guia para garantir que não estou a pedir às minhas equipas que comam o elefante inteiro numa única história de utilizador.

Outro exemplo de boa consistência vem do mundo de UX, especificamente o 6º capítulo do seminal de Don Norman “O Desenho das Coisas do Cotidiano”. Aí, Norman afirma que aqueles de nós com experiência de condução podem gerir uma marca e modelo que nunca operámos antes, devido à colocação consistente de características como o pedal do acelerador e os espelhos de visão lateral.

Steve Krug corre com este exemplo no capítulo ‘Billboards Design 101′ do seu encantador livro “Don’t Make Me Think”. Krug faz argumentos eficazes em nome do reconhecimento da recordação, especialmente quando se trata de tratamentos de hierarquias visuais, hiperligações, e disposição do conteúdo.

No entanto, Krug argumenta também que o que queremos em última análise é a clareza, com o uso sábio da consistência como meio eficaz para lá chegar. Ele também oferece este aviso no mesmo capítulo:

E, finalmente, uma palavra sobre consistência.

Ouvimos frequentemente a consistência citada como um bem absoluto. As pessoas ganham muitos argumentos de design só por dizerem “Não podemos fazer isso. Não seria consistente”.

Consistência é sempre uma coisa boa a procurar dentro do seu site ou aplicação. Se a sua navegação estiver sempre no mesmo sítio, por exemplo, não tenho de pensar nisso ou perder tempo a procurá-lo. Mas haverá casos em que as coisas ficarão mais claras se as tornar ligeiramente inconsistentes.

Consistência Tirânica

p>A minha citação de abertura veio da “Auto-Confiança,” um ensaio que faz um argumento convincente para que as pessoas pensem por si próprias, em vez de aceitarem um destino frequentemente associado a falésias e lemingues.

Como mencionei anteriormente, fiz a minha pergunta inicial numa variedade de canais sociais e Meetups. Abaixo estão exemplos que colhi que acredito demonstrar uma consistência tola, se não tirânica:

• Um scrum master pitching a fit se um programador não criar uma história JIRA para corrigir uma gralha num artefacto README.md.
• Um editor de uma organização de notícias que insiste que a aplicação móvel nativa suporte exactamente as mesmas 150 secções que a sua solução baseada no browser de desktop para não confundir os utilizadores.
• Um gestor de projecto que mantém esse planeamento de capacidade como a única e verdadeira forma de assegurar que um cliente está a receber aquilo pelo qual pagou porque as abordagens mais modernas à entrega de software têm demasiada incerteza envolvida.
• Uma pessoa do campo pergunta “Não há uma forma de conseguirmos que todas as equipas de desenvolvimento se alinhem na forma como dimensionam as histórias?”
• Um arquitecto que argumenta a favor de Big Design Up-Front de tudo para cada cenário porque insiste que é a única forma de saber o que construir para suportar um conjunto de funcionalidades.
• Um cliente que exige que os resultados fornecidos por uma nova infra-estrutura de pesquisa de texto completo baseada em Lucena sejam 100% idênticos aos retornados da implementação da base de dados NoSQL de saída.
• Um gestor de produto que se recusa a aceitar histórias de utilizadores de outros a menos que sejam formatadas sem falhas e exaustivamente completadas utilizando uma placa de caldeira TPS e a respectiva folha de rosto.

O resultado de tais cenários é uma frustração de moagem que as nossas equipas de desenvolvimento suportam como uma devoção servil à consistência … uma priorização bem intencionada mas mal orientada que impede grandemente a sua capacidade de descobrir e entregar rápida e continuamente as características certas de valor.

Sabedoria Adicional

Outros mais inteligentes do que eu também alertaram para uma subserviência tola à consistência; abaixo estão alguns URLs úteis que visitei na preparação deste post.