Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.
O gerenciamento de requisitos é uma disciplina extremamente necessária no processo de desenvolvimento de software porque ela desempenha um papel de interface entre a equipe de desenvolvimento, usuários e patrocinador do projeto. A correta identificação e descrição dos requisitos de software é um fator crítico para o sucesso do produto final de software.
Uma aplicação de software em uma empresa é idealizada para atender às necessidades do negócio. Não basta que ela possua belas interfaces gráficas atendendo a todos os requisitos de usabilidade. Se não atender às reais necessidades dos usuários, sempre haverá alguém para dizer “o sistema é muito bonito, mas....”. O problema está neste “mas...”. Com isso, o usuário está querendo dizer que a aplicação desenvolvida não resolve o problema dele. Isso não quer dizer que aplicações que atendem às necessidades dos usuários precisam ter interfaces ruins. O ideal é que o software tenha essas duas características, ou seja, tenha uma boa interface e atenda às reais necessidades do negócio.
Um problema comumente encontrado nas equipes de projeto de software é a utilização de arquitetos, projetistas e programadores para fazer a elicitação de requisitos do sistema. Este problema se reflete na baixa qualidade das descrições que frequentemente são imprecisas, inconsistentes, sem clareza, recheadas de soluções físicas e muito frequentemente ambíguas, gerando falhas na comunicação com a equipe de desenvolvimento, levando à produção de um sistema que não atende às reais necessidades dos usuários. O ideal seria a utilização de profissionais com o perfil adequado para a correta identificação, descrição e gerenciamento de todo o ciclo de vida dos requisitos.
Outro aspecto da gestão de requisitos frequentemente esquecido, é a visão corporativa que promove o alinhamento dos sistemas com a arquitetura de negócio da empresa, a qual reflete os conceitos, processos de negócio e estratégias, descritas do ponto de vista da alta administração. Infelizmente a grande maioria das empresas ainda não possui uma arquitetura de negócio bem definida e gerenciada com mecanismos que garantam que as aplicações de software implementem seus processos, estruturas e conceitos.
A disciplina de gestão de requisitos é riquíssima, mas ainda precariamente exercida nas empresas. O foco ainda está voltado somente para a descrição de casos de uso e assim mesmo não está boa, porque é feita por pessoas sem um adequado perfil. Ainda faltam muitas coisas para serem feitas, tais como obtenção da precisão na descrição dos requisitos, analise dos problemas e suas causas-raíz, definição das necessidades dos stakeholders a partir dos problemas identificados, alinhamento dos requisitos à Arquitetura de Negócio da empresa, gerenciamento da rastreabilidade e das mudanças desses requisitos ao longo do processo e, finalmente, o gerenciamento de todo o ciclo de vida de cada requisito através das disciplinas e atividades das iterações de cada fase dos ciclos de desenvolvimento e de evolução de um sistema.
Percebo claramente, nos projetos que gerencio ou que participo como mentor/coach, uma grande dificuldade dos nossos analistas em descrever conceitos e procedimentos. Estou me referindo à produção de um pequeno texto em português. É lamentável, pois percebo uma grande displicência ao escrever. Os textos não possuem precisão, clareza, objetividade e consistência. Numa rápida leitura dos requisitos de um sistema, freqüentemente encontramos inúmeras redundâncias e ambigüidades na descrição desses requisitos.
Isso tem trazido inúmeros problemas no relacionamento com fábricas de software usadas para projetar e implementar sistemas, pois criam a necessidade de reuniões complementares para clarificar, corrigir, completar, refazer e até criar novos requisitos. Isso traz problemas de prazos e conseqüentemente de custos.
Ainda temos muito que melhorar, tanto do ponto de vista técnico como do ponto de vista de redação. Lembro-me da minha professora de português no meu tempo de colégio, afirmando que para aprender a escrever, é necessária muita leitura e treino em redação. Hoje eu testifico que isso é verdade. Não estou afirmando que uma descrição de requisitos deve se comparar a uma obra literária, perfeita no conteúdo e na forma. Mas pelo menos um pouco de cuidado para não trazer problemas de entendimento.
Tomo a liberdade de aconselhar, que devemos desenvolver constantemente o bom hábito de escrever bem. Podemos fazer isso nos nossos e-mails que redigimos diariamente evitando excessos de informalidades tão populares nas trocas de mensagens em sites de relacionamento online.
Concluindo, minha sugestão é que os tomadores de decisões em um ambiente corporativo de desenvolvimento de sistemas, devem escolher analistas de negócio/requisitos que possuem perfil adequado para se especializarem no gerenciamento de requisitos nos âmbitos de projeto e corporativo. Esses analistas formarão uma equipe altamente especializada, com uma visão corporativa dos requisitos, buscando reutilização de requisitos já implementados e testados, tranzendo eficácia e eficiência aos projetos. Com esta visão corporativa, essa equipe buscará o alinhamento das Aplicações de Software com a Arquitetura de Negócio da empresa, alinhando os projetos de software ao Plano Estratégico.
Este grupo pode ser formado de diversas maneiras, variando desde uma simples célula informal, até uma unidade organizacional formalmente inserida no organograma da empresa. O que quero salientar, é que a gestão de requisitos é uma disciplina de importância estratégica, que deve receber uma especial atenção pelos tomadores de decisão em governança de TI.
São Paulo, 22 de fevereiro de 2008.
O gerenciamento de requisitos é uma disciplina extremamente necessária no processo de desenvolvimento de software porque ela desempenha um papel de interface entre a equipe de desenvolvimento, usuários e patrocinador do projeto. A correta identificação e descrição dos requisitos de software é um fator crítico para o sucesso do produto final de software.
Uma aplicação de software em uma empresa é idealizada para atender às necessidades do negócio. Não basta que ela possua belas interfaces gráficas atendendo a todos os requisitos de usabilidade. Se não atender às reais necessidades dos usuários, sempre haverá alguém para dizer “o sistema é muito bonito, mas....”. O problema está neste “mas...”. Com isso, o usuário está querendo dizer que a aplicação desenvolvida não resolve o problema dele. Isso não quer dizer que aplicações que atendem às necessidades dos usuários precisam ter interfaces ruins. O ideal é que o software tenha essas duas características, ou seja, tenha uma boa interface e atenda às reais necessidades do negócio.
Um problema comumente encontrado nas equipes de projeto de software é a utilização de arquitetos, projetistas e programadores para fazer a elicitação de requisitos do sistema. Este problema se reflete na baixa qualidade das descrições que frequentemente são imprecisas, inconsistentes, sem clareza, recheadas de soluções físicas e muito frequentemente ambíguas, gerando falhas na comunicação com a equipe de desenvolvimento, levando à produção de um sistema que não atende às reais necessidades dos usuários. O ideal seria a utilização de profissionais com o perfil adequado para a correta identificação, descrição e gerenciamento de todo o ciclo de vida dos requisitos.
Outro aspecto da gestão de requisitos frequentemente esquecido, é a visão corporativa que promove o alinhamento dos sistemas com a arquitetura de negócio da empresa, a qual reflete os conceitos, processos de negócio e estratégias, descritas do ponto de vista da alta administração. Infelizmente a grande maioria das empresas ainda não possui uma arquitetura de negócio bem definida e gerenciada com mecanismos que garantam que as aplicações de software implementem seus processos, estruturas e conceitos.
A disciplina de gestão de requisitos é riquíssima, mas ainda precariamente exercida nas empresas. O foco ainda está voltado somente para a descrição de casos de uso e assim mesmo não está boa, porque é feita por pessoas sem um adequado perfil. Ainda faltam muitas coisas para serem feitas, tais como obtenção da precisão na descrição dos requisitos, analise dos problemas e suas causas-raíz, definição das necessidades dos stakeholders a partir dos problemas identificados, alinhamento dos requisitos à Arquitetura de Negócio da empresa, gerenciamento da rastreabilidade e das mudanças desses requisitos ao longo do processo e, finalmente, o gerenciamento de todo o ciclo de vida de cada requisito através das disciplinas e atividades das iterações de cada fase dos ciclos de desenvolvimento e de evolução de um sistema.
Percebo claramente, nos projetos que gerencio ou que participo como mentor/coach, uma grande dificuldade dos nossos analistas em descrever conceitos e procedimentos. Estou me referindo à produção de um pequeno texto em português. É lamentável, pois percebo uma grande displicência ao escrever. Os textos não possuem precisão, clareza, objetividade e consistência. Numa rápida leitura dos requisitos de um sistema, freqüentemente encontramos inúmeras redundâncias e ambigüidades na descrição desses requisitos.
Isso tem trazido inúmeros problemas no relacionamento com fábricas de software usadas para projetar e implementar sistemas, pois criam a necessidade de reuniões complementares para clarificar, corrigir, completar, refazer e até criar novos requisitos. Isso traz problemas de prazos e conseqüentemente de custos.
Ainda temos muito que melhorar, tanto do ponto de vista técnico como do ponto de vista de redação. Lembro-me da minha professora de português no meu tempo de colégio, afirmando que para aprender a escrever, é necessária muita leitura e treino em redação. Hoje eu testifico que isso é verdade. Não estou afirmando que uma descrição de requisitos deve se comparar a uma obra literária, perfeita no conteúdo e na forma. Mas pelo menos um pouco de cuidado para não trazer problemas de entendimento.
Tomo a liberdade de aconselhar, que devemos desenvolver constantemente o bom hábito de escrever bem. Podemos fazer isso nos nossos e-mails que redigimos diariamente evitando excessos de informalidades tão populares nas trocas de mensagens em sites de relacionamento online.
Concluindo, minha sugestão é que os tomadores de decisões em um ambiente corporativo de desenvolvimento de sistemas, devem escolher analistas de negócio/requisitos que possuem perfil adequado para se especializarem no gerenciamento de requisitos nos âmbitos de projeto e corporativo. Esses analistas formarão uma equipe altamente especializada, com uma visão corporativa dos requisitos, buscando reutilização de requisitos já implementados e testados, tranzendo eficácia e eficiência aos projetos. Com esta visão corporativa, essa equipe buscará o alinhamento das Aplicações de Software com a Arquitetura de Negócio da empresa, alinhando os projetos de software ao Plano Estratégico.
Este grupo pode ser formado de diversas maneiras, variando desde uma simples célula informal, até uma unidade organizacional formalmente inserida no organograma da empresa. O que quero salientar, é que a gestão de requisitos é uma disciplina de importância estratégica, que deve receber uma especial atenção pelos tomadores de decisão em governança de TI.
São Paulo, 22 de fevereiro de 2008.
3 comentários:
Postar um comentário