Smarana

Discussões sobre Memória Organizacional em ambientes de desenvolvimento de Software

O que há de errado na visão ágil sobre requisitos?

Requisitos extensos são sinal de fraco entendimento.

Para quem me conhece, não é novidade que estudo sobre as áreas de engenharia de requisitos e gerenciamento de projetos. Também não ficaram surpresos ao saber que estou escrevendo um livro sobre o primeiro tema. Durante esses estudos, cheguei a algumas conclusões sobre a razão para uma visão no mínimo esquisita estar tão difundida e fazer tanto sucesso sob a aparência de ágil.

Ao meu ver, as pessoas não entendem requisitos. E, por não entender, geram produtos extremamente mal-elaborados. Quando entendem, não conseguem executar ideias melhores por pressão cultural. Eu mesmo já sofri com esse esmagamento da capacidade criativa e, por isso, produzi muitos requisitos cuja qualidade é alvo de minha própria crítica – e essa foi uma motivação para estudar e escrever sobre o tema. Vou tentar elaborar alguns alertas, que discuto mais aprofundadamente no livro.

1 – Requisitos para Gerenciamento de Projetos não são Requisitos para a Engenharia de Requisitos! No primeiro, o objetivo é definir o escopo, enquanto no segundo é definir a forma do produto. Dessa confusão estabelecida derivam o senso de rigidez e a dificuldade de se negociar mudanças de escopo. Em primeiro lugar, se o escopo não está definido, você não tem um projeto, por definição. Aí é justamente onde reside a percepção clara de mudança de escopo (do gerenciamento de projetos) e consequente renegociação de prazos – o que não significa dizer que mudanças na definição de requisitos (engenharia) impliquem em alteração de vetores do projeto.

A compreensão acompanha a escrita e deixa um legado de conhecimento.

2 – Documentação de Requisitos não vem depois do entendimento!  Ela é condutora da compreensão e surge como memória auxiliar e como meio mais estável para a comunicação. Nós não somos uma ilha… equipes mudam e o produto pode passar por diversas pessoas, tanto do lado do desenvolvimento quanto do lado do cliente. Reaprender a cada mudança causa um “overhead” enorme em ambientes de grande “turnover”. A compreensão de aprendizado organizacional, diferenciando-o do pessoal, é fundamental para entender isso. É como na academia… a tese não serve para provar algo e ganhar um título, como atualmente se faz crer, mas para representar o andamento do processo de aprendizado/pesquisa e comunicar aos pares, de forma que não precisem repetir a experiência para aprender o mesmo – se o fazem, é para desvendar outros mistérios.

3 – Documentação de Requisitos não é contrato! Nela não está estabelecido multas, regras bilaterais de conduta ou sanções. Se você considera contrato (a maioria dos analistas o faz), é nesse conceito que está sendo embutida a rigidez combatida pelo pessoal do ágil.

4 – Não se deveria documentar para o cliente. A utilidade da documentação para o cliente é absurdamente inferior à necessidade de uma comunicação eficaz, coesa e estável dentro da equipe de desenvolvimento. Isso exige uma linguagem mais prática e acessível para desenvolvedores, o que é prejudicado pela contaminação de uma linguagem estrangeira. Em uma brincadeira com números que fiz, usando um cenário pessimista, cheguei à conclusão que o esforço efetivo de consulta a documentação (considerando a concepção de engenharia de requisitos que defendo, com elaboração eficiente e eficaz e uso por toda equipe de desenvolvimento) por desenvolvedores é pelo menos 10x maior do que por clientes – isso sem considerar o correto princípio ágil de que o cliente não quer documentação, mas software funcionando.

Ao meu ver, a falta de conhecimento e habilidade para elicitar requisitos – até porque não se forma para a execução de tal atividade – gerou um legado de problemas, falhas, ambiguidades e ineficiência. A maneira aparentemente mais simples de resolver é remover da jogada o foco desses problemas – a análise de requisitos (até porque é muito mais fácil culpar atividades e processos do que as pessoas, nossos colegas e amigos). Sem a atividade, o andamento do projeto seria mais rápido e, portanto, melhor. Rápido, sim. Melhor? Depende do ponto de vista. Ao meu ver, a oneração é falaciosa, pois pequenos projetos demandam menor esforço de requisitos… é uma questão de proporcionalidade. Além disso, como já exposto, tenho uma visão mais aguçada sobre aspectos como conhecimento organizacional e a disseminação da informação no ambiente de trabalho.

Em outro post, falei sobre uma forma de se produzir documentação mais rapidamente, favorecendo o reuso e comunicando apenas as informações relevantes para a construção do software. Tanto lá quanto no livro tento deixar clara essa minha visão de que devemos aliar aos princípios ágeis a uma construção de uma memória organizacional, e não apenas uma solução que funcione hoje, mas que, por divergências de visões e entendimentos incorretos, acabem se modificndo erraticamente, se deteriorando e não gerando o valor desejado.

Libertação de visão estreita pode promover aliança entre ágil e construção de legado de conhecimento.

Enquanto trabalhava, entre outras coisas, apoiando equipes sobre conformidade de requisitos, sempre disse aos gerentes de projeto que eles deveriam fazer uso de sua prerrogativa de gerente (afinal, ganham para isso) e peitar uma flexibilização de projetos, com ou sem minha aprovação. Sempre defendi que requisitos bem feitos (e feitos no momento certo… não só por conformidade) não oneram o projeto, mas promovem outro grau de qualidade ao projeto – o fornecimento de uma comunicação mais eficiente e uma compreensão coletiva, atual e futura, sobre os sistemas. Então, aprimorar a gestão de pessoas poderia ser o caminho para agilidade sem perder de vista a formação de memória organizacional, pela libertação das amarras de uma visão estreita e equivocada de requisitos para uma mais libertadora e crítica, seguindo os princípios ágeis sem abandonar a construção de um legado de conhecimento.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado em terça-feira, junho 21, 2011 por em Gestão do Conhecimento, Processos e Metodologias, Requisitos.

O Autor

Twitter

Goodreads

Oath of non-allegiance

Oath of non-allegiance

Oath of non-allegiance

%d blogueiros gostam disto: