Os desenvolvedores de software fazem adoram codificar. Mas, pela minha experiência, pouquíssimos deles conseguem explicar o porquê eles estão codificando. Experimente este exercício com um de seus colegas de equipe se não acreditar em mim. Pergunte a eles o que estão fazendo. Em seguida, pergunte por que estão fazendo isso e mantenha perguntando até chegar a um motivo que seus clientes entenderiam.
Em que o senhor está trabalhando?
Estou corrigindo a ordem de classificação nesse datagrid.
Por que o senhor está trabalhando nisso?
Porque está na lista de bugs.
Por que está na lista de bugs?
Porque um dos testadores relatou isso como um bug.
Por que foi relatado como um bug?
O testador acha que esse campo deve ser classificado em ordem numérica em vez de alfanumérica.
Por que o testador acha isso?
Evidentemente, os usuários estão tendo problemas para encontrar coisas quando o item 2 é classificado no item 19.
Se essa conversa lhe parecer estranha, provavelmente o senhor não trabalhou com muitos desenvolvedores de software. Como o número de lambidas necessárias para chegar ao centro de uma bala de chocolatetalvez se surpreenda com o número de vezes que o senhor precisa perguntar “por que” até chegar a alguma coisa. qualquer coisa – com o qual seus clientes realmente se importariam.
É uma grande desconexão.
Os desenvolvedores de software acham que seu trabalho é escrever código. Mas não é.* Seu trabalho é resolver o problema do cliente. Claro, nosso meio preferido para resolver problemas é o software, e isso envolve escrever código. Mas vamos manter isso dentro do contexto: escrever código é algo que o senhor tem para oferecer uma solução. Não se trata de um fim em si mesmo.
Como desenvolvedores de software, passamos tanto tempo atolados em níveis infinitos e fractais de detalhes que é muito fácil cairmos na armadilha de codificar só por codificar. Sem um foco claro e algo em torno do qual nos unirmos, perdemos o contexto do nosso código. É por isso que o é tão importante ter uma declaração clara da visão do projeto que todos possam usar como ponto de referência no projeto. Se o senhor tiver a declaração de visão definida, cada pessoa da sua equipe deverá ser capaz de passar no “teste do elevador” com um estranho – explicar claramente no que está trabalhando e por que alguém se importaria com isso, em 60 segundos.
Se sua equipe não consegue explicar seu trabalho para um leigo de forma significativa, o senhor está com problemas, quer perceba ou não. Mas o senhor está em boa companhia. Jim Highsmith está aqui para ajudar. Ele explica uma fórmula rápida para criar um modelo de visão de projeto:
Um modelo de visão de produto ajuda os membros da equipe a passar o teste do elevador – a capacidade de explicar o projeto a alguém em dois minutos. Ele vem do livro de Geoffrey Moore Crossing the Chasm (Cruzando o abismo). Ele segue o seguinte formato:
- para (cliente-alvo)
- que (declaração de necessidade ou oportunidade)
- o (nome do produto) é um (categoria de produto)
- que (benefício-chave, razão convincente para comprar)
- diferente de (alternativa competitiva primária)
- nosso produto (declaração de diferenciação primária)
A criação de uma declaração de visão do produto ajuda as equipes a manter o foco nos aspectos essenciais do produto, mesmo quando os detalhes estão mudando rapidamente. É muito fácil se concentrar nas questões de curto prazo associadas a uma iteração de desenvolvimento de 2 a 4 semanas e perder o controle da visão geral do produto.
Não sou um grande fã de fórmulas, porque elas são muito, bem.., formulaicas. Mas é um ponto de partida razoável. Jogar Mad Libs e veja o que o senhor consegue fazer. É muito melhor do que não ter uma declaração de visão, ou do que uma bagunça pouco inspiradora, divagante e ad-hoc disfarçada de declaração de visão. Entretanto, acho que a segunda sugestão de Jim para desenvolver uma declaração de visão é muito mais promissora.
Mesmo em uma organização de TI, acho que todo projeto deve ser considerado como um “produto”. Independentemente de os resultados do projeto envolverem melhorias em um sistema de contabilidade interno ou um novo site de comércio eletrônico, o pensamento orientado para o produto traz benefícios.
Uma prática que considero eficaz para fazer com que as equipes pensem em uma visão de produto é o exercício Design-the-Box. Esse exercício é ótimo para abrir uma sessão para iniciar um projeto. A equipe parte do pressuposto de que o produto será vendido em uma caixa encolhida, e sua tarefa é projetar a frente e o verso da caixa do produto. Isso envolve a criação de um nome de produto, um gráfico, três ou quatro pontos-chave na frente para “vender” o produto, uma descrição detalhada do recurso no verso e requisitos operacionais.
Encontrar 15 ou 20 recursos para o produto é fácil. Difícil é descobrir quais são as três ou quatro que levariam alguém a comprar o produto. Uma coisa que geralmente acontece é uma discussão intensa sobre quem realmente são os clientes.
O Design-the-Box é uma maneira fantástica de formular uma declaração de visão. Ela se baseia em um conceito concreto do mundo real que pode ser facilmente compreendido pela maioria das pessoas. Esqueça aquelas buscas de visões que não passam de um sonho: como seria a caixa do nosso produto (hipotético)?
Todos nós somos consumidores; os objetivos de design de uma caixa de produto são óbvios e universais. O que é uma caixa de produto se não o melhor argumento de venda? Ela deve…
- Explicar o que é nosso produto da maneira mais simples possível.
- Deixe bem claro por que um cliente em potencial gostaria de comprar esse produto.
- Seja identificável de forma exclusiva entre todas as outras caixas na prateleira.
Considere a caixa para o malfadada Microsoft Bob como exemplo. Como o senhor explica por que os clientes deveriam querer o Microsoft Bob? Como o senhor explicaria o que é o Microsoft Bob? é?
É instrutivo observar as caixas de produtos existentes que o senhor considera eficazes e aquelas que considera ineficazes. Nós definitivamente sabemos o que nossa caixa de produto não deveria parecer com.
Tenha um uma declaração de visão sólida para seu projeto desde o primeiro dia. Se não tiver, use uma das excelentes sugestões de Jim para criar uma imediatamente. Sem uma declaração de visão coerente, é impressionante o número de equipes que não conseguem passar no teste do elevador – elas não conseguem explicar no que estão trabalhando ou por que isso é importante. Não cometa esse mesmo erro. Obtenha uma declaração de visão incrível com a qual seus colegas de equipe possam relacionar seu trabalho. Certifique-se de que sua equipe pode passar no teste do elevador.
* Totalmente roubado do grande livro de Billy Hollis Palestra de 15 minutos sobre viciados em software.