Espírito Colaborativo

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.

Related Posts:

Read More

Taquigrafo

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 destas relações da palavra Análise, e buscar constantemente nos aproximar delas.

Profissionais de Análise de Requisitos que vão até o cliente preparados apenas para ouvir e anotar todas as necessidades e especificações que o cliente informar, para depois simplesmente transcrevê-las dentro de modelos de documentos, estão se distanciando do termo “Análise”.

De fato, não é necessário um Analista pra transformar anotações em documentos. Na reunião de levantamento, seria mais produtivo substituí-lo por um taquigráfico; e na geração do modelo de documento um digitador pouparia muitas horas do projeto. Correto?

Não mesmo! Quem garante que as informações transmitidas pelo cliente estão coerentes, do ponto de vista do negócio ou da tecnologia? É profissional deixar o processo de desenvolvimento correr desta forma, transferindo um enorme problema de escopo para a fase de implementação com regras conflitantes, alterações constantes no escopo e estrutura do projeto a cada validação do cliente/usuário? Qualquer economia de tempo que se possa imaginar evitando debates na análise, pode ser perdido corrigindo o software em um momento posterior.

Tudo isso poderia ser evitado (ou mitigado) por um Analista, desde que ele efetivamente pratique esse processo de investigação, descoberta, estudo… lembra da definição de análise? Investigar se está fazendo sentido para o negócio; estudar o negócio, legislações envolvidas; pesquisar outros sistemas ou consultar outros analistas com mais 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 no projeto, e conseguimos gerar benefícios e evitar dores de cabeças nas etapas seguintes até a entrega da solução.

Ou será melhor agilizarmos logo um curso de taquigrafia? 😉

Related Posts:

Read More

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.

Related Posts:

Read More

Levantamento de Requisitos: Entendendo o cliente

Muitas vezes nos vemos de frente de um cliente que não sabe exatamente do que precisa, ou que não consegue transmitir esta informação de maneira clara e objetiva. O resultado é que gastamos horas e horas em reuniões de levantamento de requisitos sem conseguir 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 diversas técnicas mais ou menos adequadas para ultrapassar esta barreira e captar estas informações em diferentes casos. Mesmo com clientes mais “indecisos”, ou em casos onde 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 para não torná-la cansativa, desmotivando o entrevistado ou causando uma queda de produtividade ou organização das ideias. Sempre planeje sua entrevista com antecedência e anote simplesmente tudo.

Brainstorming

Muito útil quando existem diversos interessados no projeto com pontos de vista diferentes. É dividido em duas etapas. Na primeira, anota-se todas as idéias que surgirem, sem que sejam questionadas. Neste momento o mais importante é a participação e a quantidade. Na segunda etapa, debate-se com o grupo para refinamento das idéias apresentadas. Deixe sempre 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. Observe as pessoas, pois este processo te auxilia a identificar as pessoas mais participativas para agendamento de entrevistas.

Role playing

Esta técnica consiste em observar o usuário 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 necessidades, sentindo na pele como é a execução do processo. Muito útil quando o usuário não consegue identificar ou transmitir as informações necessárias para a identificação dos requisitos.

Existem outras técnicas de levantamento para diferentes casos. O importante é conhece-las e saber seus pontos fortes e fracos, pra aplicá-las adequadamente.

Related Posts:

Read More