Colaboração entre Cliente e TI ajuda no Desenvolvimento de Software
Houve o tempo em que os desenvolvedores de Software recebiam suas demandas diretamente dos clientes/usuários, e compilavam as regras do negócio para dentro de suas aplicações, sem documentação ou muita possibilidade de transferência de conhecimento.
Anos mais tarde, a falta de documentação destes softwares tornaram as empresas dependentes de seus desenvolvedores, que, caso saíssem, deixariam provavelmente um estado de caos. Assim nasceram as metodologias de software com bases na Engenharia, onde documentações, processos e muito planejamento tomou conta da "indústria", e passamos à denominação de "Fábrica de Software", em uma clara alusão ao processo produtivo de uma indústria comum (linhas de produção de software, no caso).
Isso resolveu alguns problemas, mas trouxe muitos outros, dentre eles: o fato do desenvolvimento ser uma atividade intelectual, e não pode ser medida dentro de um conceito de "Fábrica", de montagem de um veículo, por exemplo; O excesso de planejamento e burocracia, tornou o processo de desenvolvimento muito mais lento, e com o aumento da competitividade o tempo passou a ser fator crítico de sucesso para os projetos, inclusive de Software.
Foi aí que um grupo de grandes profissionais do desenvolvimento de software, como Martin Fowler (pra citar só o mais conhecido), elaborou um Manifesto para o desenvolvimento ágil de Software, em busca do equilíbrio entre estes dois mundos vividos anteriormente.
O que é bastante curioso, a primeira vista, é que o manifesto não trata apenas do desenvolvimento de software da área de TI pra dentro, mas sim de uma mudança cultural que deve atingir todos os envolvidos nestes projetos, valorizando:
Indivíduos e interação entre eles mais que processos e ferramentas;
Colaboração com o cliente mais que negociação de contratos;
Interação entre indivíduos, significa a proximidade (encontros "cara-a-cara" sempre que possíveis), disponibilidade e clareza nas informações. No desenvolvimento do Software, a área Cliente sabe quais são as suas dificuldades e necessidades, e a área de TI sabe como melhor consolidar estas necessidades e transformá-las em Software. A efetiva comunicação entre as duas áreas aumentará a qualidade do produto final.
A colaboração com o cliente é a transparência e confiança na comunicação entre ele e a área de TI, em uma via de duas mãos, comunicando sempre o progresso, informando aquilo que ainda não está claro, trocando experiências e trilhando sempre o caminho da qualidade.
Do manifesto, surgiram também alguns princípios, que também indicam como o comportamento colaborativo favorece o bom trabalho dos projetos:
- Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
- Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
- O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
- Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
Com tudo isso, podemos concluir que de fato um Time de Desenvolvimento de Software, não é composto somente por Gerentes de Projetos, Analistas de Sistemas e Desenvolvedores. É feito também pelos Clientes, Patrocinadores e Usuários. Cada um contribuindo com as informações que possuem para o objetivo final e bem comum: Software de qualidade e Ambiente sustentável.
PS.: Não deixe de ver o Manifesto completo, e todos os 12 princípios do software ágil.
Artigos Relacionados:
O papel da Análise de Requisitos e a Taquigrafia/Digitação
O termo Análise, está associado à investigação, descoberta, estudo. Em se tratando de Análise de Sistemas ou Negócio/Requisitos para a construção de sistemas, temos de nos lembrar muito bem destes significados da palavra Análise, e nos aproximar profundamente deles.
Profissionais de Análise de Requisitos, por exemplo, que vão até o cliente prontos apenas para ouvir e anotar todas as necessidades e especificações do cliente, e depois simplesmente transcrevê-las dentro de modelos de documentos, estão se distanciando do termo "Análise".
Não precisamos de Analistas pra transformar anotações em documentos. Podemos substituir o analista na fase de anotação por taquigraficos, e na fase de transcrição para os modelos, um veloz digitador vai me poupar outro caminhão de tempo.
Mas peraí! Quem garante que o cliente está no caminho certo? Vamos deixar o processo correr desta forma, pra sofrer no tempo de implementação com regras conflitantes, com alterações constantes no escopo e estrutura do projeto a cada validação do cliente/usuário?
Isso é papel do Analista. Mas ele precisa efetivamente fazer isso, é um processo de investigação, descoberta, estudo, lembra? Investigar se aquilo está fazendo sentido para o negócio; estudar as legislações envolvidas; pesquisar outros sistemas ou consultar outros analistas com experiência na área de conhecimento; questionar e validar o negócio com o cliente.
Agindo assim, realmente podemos dizer que temos (somos) um Analista, e conseguimos evitar dores de cabeças nas etapas seguintes até a entrega da solução. Ou você prefere agilizar logo um curso de taquigrafia? #troll
Artigos Relacionados:
Metodologia Tradicional ou Scrum: Foco na Qualidade
Muitas empresas e profissionais defendem e comprovam sucesso através da utilização das metodologias hoje ditas "tradicionais", enquanto que, nos últimos anos, vemos uma forte expansão do interesse e uso das metodologias ditas "ágeis", igualmente defendidas através de casos de sucesso. O que nos faz pensar: Afinal, o que fez esses casos darem certo?
Nos últimos meses estive envolvido em um trabalho de atualização e implantação de uma metodologia de desenvolvimento de software no departamento de informática de um órgão público. A metodologia utilizada, apesar de ter suas origens no RUP, conta com influências da cultura ágil, contemplando um número reduzido de artefatos de projeto.
Por se tratar de uma instituição pública, onde naturalmente é mais difícil de se implantar uma nova cultura, e contar com um grande número de equipes e profissionais envolvidos, temos hoje diferentes níveis de maturidade e de aplicação da metodologia internamente. Há casos em que os processos são seguidos rigorosamente, porém os projetos não obtém sucesso, há casos de "caos" finalizados com sucesso e vice-versa.
O problema é que independente da metodologia, é preciso trabalhar a mentalidade dos profissionais, implantar uma cultura de qualidade, para que, independente de seguir a linha de processos tradicional ou ágil, as pessoas estejam focadas no seu trabalho, afetando diretamente a qualidade dos produtos e satisfação dos clientes.
Metodologias X, Y ou Z poderão ser implantadas de acordo com a realidade de cada caso. Implantar SCRUM sem uma participação ativa do cliente como Product Owner possívelmente levará o projeto ao fracasso. Implantar uma metodologia baseada em casos de uso com Analistas de Requisitos que não se façam entender pelo cliente e/ou pela área técnica, possívelmente levará o projeto ao fracasso.
Não se deixe enganar pela venda de Metodologias de Desenvolvimento: não existe Qualidade sem as pessoas. Antes de implantar uma metodologia, trabalhe com todos os envolvidos esta questão. Afinal, este será um fator de sucesso muito mais importante do que a metodologia implantada.
Artigos Relacionados:
Levantamento de Requisitos: Entendendo o cliente
Muitas vezes nos vemos de frente com um cliente que não sabe exatamente do que precisa, ou que não consegue transmitir esta informação de maneira clara. Resultado: Você gasta horas e horas em uma reunião de levantamento de requisitos (ou briefing para os publicitários) e não consegue extrair informações relevantes para o desenvolvimento do projeto.
É comum, principalmente na área de TI, colocarmos a culpa sempre nos clientes (ou usuários), mas, na verdade, existem técnicas mais ou menos adequadas para ultrapassar esta barreira e captar estas informações, mesmo em clientes mais "problemáticos", ou em casos que muitas pessoas sejam influenciadoras ou influenciadas pelo projeto. Conheça um pouco sobre estas técnicas:
Entrevista
A entrevista deve ser feita, preferencialmente, com usuários mais comunicativos e com bom conhecimento do processo. Evite entrevistas com longas horas de duração, o entrevistado pode se desmotivar, causando queda de produtivadade do levantamento de requisito. Sempre planeje sua entrevista e anote tudo.
Brainstorming
Muito útil quando existem diversos interessados no projeto. É dividido em duas etapas. Na primeira, anota-se todas as idéias que surgirem, sem que sejam questionadas. Neste momento o que importa mais é a quantidade, não deixe de anotar nada. Na segunda etapa, debate-se com o grupo para ir refinando as idéias apresentadas anteriormente. Deixe as regras bem claras, e defina uma pessoa (facilitador) para "comandar" a reunião, para garantir que as regras sejam respeitadas.
No Brainstorming, você não precisa de usuários comunicativos, utilizando anotações anônimas para a divulgação das idéias, você atrai até os mais tímidos para a participação da tarefa. Aqui você pode, também, identificar as pessoas mais participativas e agendar entrevistas.
Role playing
Esta técnica consiste em observar o usuario executando determinada tarefa, no dia-a-dia do seu trabalho, ou, até mesmo, você fazendo o trabalho deste usuário, para identificar suas dificuldades e necessitades, sentindo na pele como é realizar a tarefa. Muito útil quando o usuário não consegue identificar ou transmitir as informações necessárias para a identificação dos requisitos.
Artigos Relacionados:
Siga-me
Tags
Posts Recentes
- TEDx Asa Sul – Evento e Talks
- 3 razões pra organizar projetos usando um Quadro (kanban)
- Colaboração entre Cliente e TI ajuda no Desenvolvimento de Software
- O papel da Análise de Requisitos e a Taquigrafia/Digitação
- Pelo fim da Corrupção