Programação Orientada a Objetos no WordPress: Entendendo as Expectativas do Cliente
À medida que continuamos avançando na discussão sobre programação orientada a objetos no WordPress, é importante ter certeza de que não estamos nos antecipando quando se trata de construir um produto para outra pessoa.
Muitas vezes, é fácil:
- ouvir o que um cliente diz,
- construir algo com base no que ouvimos,
- entregá-lo ao referido cliente.
Mas há muito mais do que isso. Eu dancei um pouco em torno disso em posts anteriores desta série; no entanto, quero começar a detalhar o que significa ouvir:
- O que um cliente diz,
- Desenvolver um conjunto de requisitos,
- E, em seguida, crie ciclos de feedback em torno disso.
Em última análise, queremos ter certeza de que as pessoas para quem estamos trabalhando e as soluções que estamos construindo são realmente soluções e não obstáculos ou obstáculos sobre os quais eles precisam pular.
Além disso, não acho suficiente que um cliente simplesmente aproveite a experiência de seu produto final, mas também trabalhar com ele (ou aqueles) construindo a solução.
Com isso dito, vamos dar uma olhada no que significa ouvir o que eles dizem e partir daí.
Entendendo as expectativas do cliente
Sempre que você lê livros ou outro material sobre esse tipo de coisa, muitas vezes faz de uma das duas partes o “cara mau". Nem sempre, mas às vezes faz:
- o cliente parece ignorante sobre o que está falando,
- ou faz o desenvolvedor parecer um idiota por agir como alguém que sabe mais sobre o assunto em questão.
Que tal uma terceira opção onde o cliente tem uma ideia clara do que quer, o(s) desenvolvedor(es) estão dispostos a ouvir e trabalhar em conjunto com o cliente para construir algo?
Claro, haverá esclarecimentos ao longo do caminho, e haverá termos que precisam ser definidos, e alguma “recalibração” do calendário de desenvolvimento pode até fazer parte disso.
Mas a conclusão é esta: nenhuma das partes deve trabalhar contra a outra. Em vez disso, trata-se de trabalhar em conjunto para a solução. Claro, requer comunicação (na qual os desenvolvedores nem sempre são bons, na minha experiência, mas não há razão para que não possa ser melhor).
O que um cliente está dizendo? (O que o desenvolvedor está dizendo?)
Sempre que vocês dois se encontram, você provavelmente está pensando a mesma coisa porque cada um fala uma língua diferente e cada um de vocês pensa que o que o outro está dizendo é jargão.
E isso não está errado.
Os clientes têm um jeito de falar sobre o que querem, e os desenvolvedores têm um jeito de falar sobre como vão entregar.
Os termos que usamos
Mas pode haver um objetivo comum.
Procure uma descrição do problema que está tentando ser resolvido. Tente fazê-lo em termos leigos para que o design esteja alinhado com o objetivo e a funcionalidade da solução.
Eu não acho que isso funcionará para todos, mas esta é a primeira coisa que eu recomendo fazer sempre que você estiver sentado com seu cliente.
Como você verá mais adiante nestes posts, é útil desenvolver algumas frases que você pode usar no início de sua declaração de trabalho, às quais você pode consultar sempre que tiver uma decisão a tomar.
Em outras palavras, você (e eles) podem perguntar:
O que estou trabalhando está contribuindo para o objetivo comum?
E é aqui que você pode determinar o conjunto principal de requisitos.
“É preciso…”
Quando se trata de comprar algo, construir algo, solicitar algo, querer algo, ou qualquer outra coisa, é muito fácil começar a frase dizendo “eu quero que…”
Mas há uma grande diferença entre “eu quero fazer [algo]” e “eu preciso [fazer algo]”, e quando você está trabalhando em software, geralmente é seguro dizer que as coisas que são necessárias são essenciais. ao aplicativo. E as coisas que são desejadas são o que vem depois que a base do aplicativo foi construída.
Ou seja, é uma conversa sobre “obrigatório” e “quero ter”. E é importante ter conversas para que você possa chegar a essa declaração final do objetivo comum do aplicativo.
Uma vez que isso esteja no lugar, você pode começar a planejar seu software em torno do problema do cliente. E é aí que a coleta de requisitos entra em ação.
Desenvolvimento de Requisitos
O que você e o cliente têm uma sólida compreensão do que precisa ser construído, então é hora de juntar os requisitos.
Esta parte pode ser mais divertida do que parece. Eu sei, eu sei: parece dever de casa ou alguma tarefa, certo? Mas isso não. Em vez disso, é pegar o que eles querem, o que você entendeu, traduzindo para uma linguagem comum e então redigindo um documento que explica o que o software fará.
Dependendo da sua experiência, porém, isso pode ser chato. E por chato, quero dizer uma das piores partes do seu trabalho. Além disso, os requisitos sempre mudam, certo?
Nem sempre.
Se você dedicar algum tempo para entender o que eles querem desde o início, os requisitos não precisam ser um documento de 50 páginas descrevendo como cada módulo deve funcionar.
Muitos livros documentam isso dizendo que é assim que tem que ser. Mas em quase uma década fazendo isso, nunca tive algo tão longo e os clientes geralmente ficaram incrivelmente agradecidos por ver uma pequena lista que pode ser alterada por e-mail ou Google Docs, assinada e então referida como o projeto se move frente.
Falarei mais sobre isso no futuro, mas qualquer que seja a experiência ruim que você tenha, o medo ou a apreensão que você tenha, não precisa ficar parado. E vamos continuar a falar sobre isso através desta série.