Nos projetos de desenvolvimento de software, temos a figura do analista, que é o profissional que fica em contato contínuo com o cliente levantando e mapeando o conhecimento do negócio e os requisitos necessários para a construção do software a ser desenvolvido. Junto com ele se destaca também o desenvolvedor, que possui o papel de fazer o software acontecer com base nos requisitos já mapeados, sejam eles representados em forma de casos de uso, estória ou qualquer que sejam os artefatos para representação do conhecimento de negócio utilizado no projeto.

Com base nesse cenário muito comum, pergunto a vocês: O papel de análise deve ser somente do analista? O desenvolvedor deve somente entrar “no jogo” durante a programação? É importante que o desenvolvedor conheça bem o negócio, visto que o analista já tem esse papel?

É exatamente com base nesses questionamentos que os convido para um breve bate-papo. Prometo 🙂 .

Sei que as respostas para as questões acima vão depender muito do contexto ou cenário em que o software está sendo desenvolvido. E imaginando que muitos poderiam responder isso, devo esclarecer que corroboro com essa opinião. Acreditem, eu mesmo não visualizo soluções definitivas e nem respostas exatas para tais questionamentos. O que quero enfatizar é que existem pontos importantes que podem ser levantados com base nas perguntas citadas.

Durante um projeto de desenvolvimento de software, a comunicação torna-se objeto imprescindível. E, tendo isso em mente, sempre que possível, o conhecimento do negócio deve se expandir de forma mais ampla para toda equipe, para que não fique em sua maior parte apenas nas cabeças dos analistas ou nos artefatos gerados.

A presença de desenvolvedores em reuniões com clientes ou usuários pode facilitar muito o entendimento dos conceitos e objetos que fazem parte do negócio.

O fato é que tudo tende a ficar muito “pobre” quando o desenvolvedor apenas conhece certa classe do modelo e suas associações, sem saber exatamente o que isso significa ou pode impactar no ambiente para o qual o software está sendo concebido.

Quando o desenvolvedor conhece realmente o negócio, há a possibilidade de eliminar o tão perigoso “achismo”, criando assim uma visão crítica que pode enriquecer muito o desenvolvimento do software.

Envolver de alguma forma o desenvolvedor durante as fases de análise pode diminuir o ruído da comunicação, pois isso reduz os efeitos colaterais de uma análise mal elaborada, sem deixar de mencionar o ganho com a facilidade na disseminação do conhecimento.

Existem muitos pontos que ainda poderiam ser destacados, entretanto, a proposta era apenas um breve bate-papo, conforme prometido anteriormente.

Espero que pensem um pouco mais nos pontos apresentados. Afinal, a ideia é que o texto funcione como um chamado para a reflexão, até mesmo porque não temos muito para onde fugir, e na maioria dos casos vamos ter que cair no tão famoso: “Depende”.