Aconteceu que ultimamente tenho trabalhado muito com os requisitos de produto do “cliente interno”, incluindo colegas de vários departamentos e equipes técnicas (dentro da empresa). E as pessoas vêm constantemente a mim para que nossa equipe implemente certos recursos, refaça algo, adicione, remova.
Neste artigo, quero dizer como você pode trabalhar com todo esse caos recebido.
O artigo foi escrito com base na prática do trabalho e não pretende abranger todo o tópico de gerenciamento de projetos, requisitos, equipes, qualidade da implementação subsequente dos requisitos pelos desenvolvedores, o tópico da análise dos resultados da implementação, etc.
Mas abrange apenas uma pequena parte estreita entre "Lista de desejos" e "implementação", que é precisamente sobre os requisitos em si: Lista de desejos / requisitos / desejos / problemas arbitrários, etc. voam até nós, trabalhamos com eles e, no final, obtemos o que adequado para o desenvolvimento.Descobrindo o verdadeiro problema
Quando alguém apresenta um problema, uma demanda, uma ideia para um novo recurso etc. nem sempre nos traz este pronto, adequado para implementação. Como regra geral, esse ou algum tipo de "cosmos" é algo muito grande, nocauteador, irreal, exigindo refazer tudo completamente para resolver um pequeno problema, cuja relevância é desconhecida. Ou apenas um requisito "bruto", incompreensível e inespecífico.
Por exemplo, uma pessoa sugere adicionar um novo recurso. E faça dessa maneira, oferecendo algum tipo de implementação técnica. Nesse caso, sem saber o que está organizado e como isso pode ser implementado. Obviamente, não se pode apenas pegar esses requisitos e implementá-los. Se o tivessem feito, o mundo mergulharia no caos e na escuridão do submundo há muito tempo.
Para empurrar um pouco o caos e a escuridão do submundo, precisamos entender o que está por trás dessas idéias e propostas. Que problema a pessoa que veio até você realmente deseja resolver, que problema deve ser resolvido?
Isso está longe de ser sempre claro e óbvio imediatamente. Muitas vezes você precisa passar, fazendo as mesmas perguntas várias vezes. Ou perguntas diferentes. Até que finalmente se torne claro o que há de errado em essência, na essência da questão e como, no entendimento de uma pessoa, deve haver "assim". E esse entendimento, em regra, é muito diferente da declaração original da tarefa / problema. Mas sem recebê-lo, é impossível prosseguir com as próximas etapas e satisfazer a necessidade.
Entender o que uma pessoa
realmente precisa é de uma arte inteira, à qual parábolas inteiras são dedicadas (por exemplo, "Vladimir Tarasov - Aproxime-se de um cervo"), livros (por exemplo, "Rob Fitzpatrick - Pergunte a sua mãe") e intensidades práticas (por exemplo, no desenvolvimento personalizado).
Bicicleta velha sobre o comprador da broca
Um homem chega à loja e compra uma broca lá. Mas, na verdade, ele não precisa de uma furadeira, ele precisa de um buraco na parede que ele deseja perfurar. Portanto, ele compra uma broca.
Mas isso não é tudo. Um buraco não é necessário por si só. Ela é necessária para pendurar uma imagem bonita e grande em uma moldura pesada. E esse herói quer pendurar uma foto para agradar sua sogra, que há muito lhe pedia para pendurar uma foto, mas ele ainda não fez isso.
Parece-nos que já encontramos um problema fundamental. Mas não.
De fato, em um dia haverá uma partida de futebol, que nosso herói realmente quer ver. E, para que a sogra não tivesse motivos para incomodá-lo, ele conseguiu o direito de assistir futebol - ele fez o que lhe pediram há muito tempo - ele exibiu uma foto.
Ou seja, comprando uma broca, ele realmente queria assistir calmamente ao futebol.
Aqui deve-se notar que a situação em que alguém aparece com estranhos, incompreensíveis, tortuosamente formulados ou, do seu ponto de vista, requisitos incorretos, é
normal . Para as pessoas em geral, é natural que elas desejem algo, mas nem sempre conseguem articular exatamente e corretamente o que desejam. As pessoas, em regra, são assim - isso é natural. Ou seja, a questão não é que alguém esteja errado, mas como você sabe como lidar com essa situação.
Nesse momento específico, trabalhar com um cliente interno não é muito diferente de trabalhar com um cliente externo.
Requisitos para recursos que já existem
A bicicleta do espião.
De alguma forma, eles enviaram um espião para uma cidade para descobrir onde a fábrica de cartuchos está localizada. Eles deram informações para ajudar a haver uma igreja na cidade e, se você andar em linha reta e sair pela rua, então em algum lugar nessa direção haverá uma fábrica.
Aí vem um espião na cidade. Ele conhece a avó e pergunta:
- Diga-me, como chegar à igreja?
- Mas você vê a fábrica de cartuchos? Dele, siga em frente e depois para a direita. Haverá uma igreja.
O caso mais simples, quando acontece que o que uma pessoa quer, já temos. Talvez não exatamente da forma que uma pessoa esperava, supunha, imaginava. É que a pessoa não sabe o que é, ou não sabe como usá-lo, ou tem informações incorretas sobre como funciona. Ou você só precisa configurar / ativar algo para obter o que precisa.
Quando tudo é tão simples, tudo o que resta é dar à pessoa instruções sobre como obter o resultado necessário, aproveitando as oportunidades existentes.
Feito.
Requisitos duplicados
Muitas vezes acontece que os requisitos são semelhantes, diferem apenas nas nuances da configuração (potencial) ou sobre a mesma coisa, mas em palavras ligeiramente diferentes. Tais requisitos podem ser combinados para entender quanto e em que locais a flexibilidade é necessária (ou será necessária no futuro) e onde não é necessária. Quais são os principais recursos? Criar um sistema ou peça de funcionalidade uma vez que satisfaça todas essas necessidades de uma só vez. Talvez com configurações ou variações diferentes, mas não será necessário que cada necessidade faça o mesmo separadamente várias vezes.
Um exemplo:
Representantes de vários departamentos diferentes procuram você (geralmente independentemente um do outro e em momentos diferentes) e dizem que um precisa enviar relatórios para e-mails para clientes da lista, o outro - notificações para um certo círculo de endereços de que alguns sistemas técnicos não são trabalho O terceiro vem e deseja, de acordo com os resultados de tal e tal processamento dos dados do cliente, uma carta com os resultados do processamento é enviada ao cliente.
É óbvio aqui que, em todos os casos, é necessário um sistema para o envio de cartas e as tarefas para o envio são de diferentes lugares, em diferentes circunstâncias.
Consequentemente, um certo sistema unificado de envio de cartas está emergindo. Em que tarefas podem vir de diferentes sistemas. E se todos os eventos acima (com os quais aqueles que desejam enviar cartas para nós) ocorrerem dentro do mesmo sistema, melhor ainda: significa que o sistema pode ser feito ainda mais uniforme e mais simples.
Se não trabalhamos com os requisitos recebidos dessa maneira e eles desenvolvem-se imediatamente na forma bruta, depois de algum tempo, encontraremos nosso sistema com vários remetentes de cartas diferentes, cada um dos quais funciona de acordo com sua própria lógica, tem sua própria implementação especial, configurações, funções. E, para alterar uma pequena parte da lógica nas três, ou adicionar uma função de outra a um desses remetentes, é necessário copiar e colar o código ou reescrever uma parte bastante grande e refatorar após a implementação e operação. Embora, em princípio, alguém possa entender antecipadamente que tudo será assim.
Requisitos conflitantes
Acontece que quaisquer dois ou mais requisitos específicos se contradizem. Às vezes "completamente", que não podem ser combinados de forma alguma. Às vezes, no entanto, “modos diferentes” podem ser previstos, em cada um dos quais um requisito é satisfeito, enquanto o outro não está disponível. Ou resolva um dos problemas de outra maneira - a contradição desaparecerá.
Para avançar em direção a uma solução, você precisa começar a desenrolar a cadeia de "por que / por que". Para cada um dos requisitos (conforme descrito na primeira parte do artigo). Ou seja, precisamos entender o mais profundamente possível a partir de quais exatamente esses requisitos surgiram e que as pessoas que vieram com esses requisitos querem "realmente".
Então temos a oportunidade de encontrar outras soluções para esses "problemas reais" ou entender como esses requisitos conflitantes podem ser combinados.
Por exemplo, se um requisito é de fato necessário apenas em algumas condições estreitas específicas e outro em outras condições estreitas específicas. Acontece que eles não se cruzam. Ou a tarefa para a qual esse requisito foi inventado pode ser resolvida de uma maneira completamente diferente, talvez até mais simples e eficaz. E então um dos requisitos desaparece (ou se transforma em um completamente diferente - que não tem nada a ver com o segundo), e o segundo permanece. E não há contradição.
Ou entenda: esses requisitos não podem ser combinados de forma alguma e você precisa escolher um. Mas, felizmente, isso ainda é bastante raro.
Tudo isso é possível porque quase todas as tarefas podem ser resolvidas de várias maneiras. E se nos elevarmos cada vez mais a partir de uma formulação inicial específica, bruta, talvez semi-técnica, no entendimento de qual é a tarefa, em princípio, haverá mais e mais opções de solução. Incluindo soluções não técnicas (nível de configurações, processo, organizacional, etc.). E quanto maior a escolha de opções, mais fácil é escolher duas opções para resolver dois problemas que não interferem entre si e, talvez, ajudar, se possível.
Requisitos da caldeira
A idéia é que, inicialmente, todos os requisitos diferentes de todas as fontes sejam mesclados em um único heap, em uma única caldeira. Em seguida, você pode desmontá-las, analisá-las para as opções acima - “repetidas” ou “contraditórias”, para fornecer os requisitos já preparados: não repetitivos e consistentes que você pode “pegar e fazer” na ordem correta.
Ou seja, a idéia é olhar para o quadro todo. Por tudo o que é agora e que eles querem adicionar, mude. E com base em todo esse quadro, já está decidido: o que, como e quando fazê-lo.
Nesse contexto, todos os requisitos recebidos são matérias-primas para se preparar para as tarefas de desenvolvimento na saída. Além disso, as tarefas na saída nem sempre coincidem individualmente com algumas necessidades recebidas. Uma tarefa pode satisfazer várias necessidades ao mesmo tempo ou fechar uma classe inteira de requisitos. Ou apenas faça parte de uma grande história.
Sumário
É assim que o caos se transforma em um conjunto bonito, útil e compreensível para desenvolvedores de tarefas e funções do seu sistema que agrada a seus colegas.