Estou publicando aqui um tópico especial que consiste em relatos do dia-a-dia ocorridos com equipes de desenvolvimento de software, independente de empresa e com quem ocorreu. Poderei relatar algo do meu dia-a-dia, bem como relatos de amigos, colegas ou participantes do blog. Este tipo de tópico será freqüente e o intuíto é trocarmos experiências.
Fiquei sabendo de uma situação que ocorre seguidamente em nossos ambientes de desenvolvimento de software e achei interessante compartilhar. Trata-se de um ocorrido que gostaria de descrever a vocês.
Durante um mês inteiro, foi realizado um trabalho em conjunto com um cliente que consistia em realizar ajustes em dois softwares para contemplar um processo de integração entre de diferentes fornecedores. Em outras palavras, o cliente pedia, os analistas dos dois aplicativos entendiam, os desenvolvedores faziam. No final de cada dia, era enviado um release ao cliente com as devidas correções.
Contudo, o teste funcional ficou a encargo do cliente. Resultado? No outro dia pela manhã o cliente relata uma série de incorformidades que não atendiam o que ele havia solicitado. Tão logo os desenvolvedores sabiam do ocorrido, corriam para corrigir e liberar mais um release ainda pela manhã. Ou seja, o velho "release do release".
Além do problema de passar uma resposabilidade que um cliente não tem a mínima capacidade de assumir e até mesmo de assimilar, proceder destas forma deu margem para o cliente pedir o que ele achava que tinha que mudar em ambas as aplicações para atender todo o processo de integração, até mesmo meros relatórios que buscam informações. O cliente alegava que tais informações deveriam constar nos relatórios porque a integração as trafegava.
Ainda por cima, ocorreu muito do cliente solicitar uma integração, ela ser realizada da maneira que ele solicitou e quando o release chegou lá a segunda coisa que ele informa é que não está como ele havia explicado que queria. A primeira coisa era "bom dia". E ainda ocorria de o cliente assumir que pediu desta forma mesmo, mas que havia se enganado e agora as empresas, como meras fornecedoras, tinham de retomar os trabalhos e ajustar o software. senão o cliente nem as pegava. Isto vai de encontro a um post que fiz anteriormente e que trata do Gerenciamento de Requisitos de Software.
Em razão disso, fica envidente que houve uma grande furada aqui ao envolver um cliente para resolver problemas de dois produtos distintos. Ocasionou problemas de produto, desgaste das equipes de desenvolvimento, desgaste do cliente, mudanças de escopo constantes, má definição do que realmente precisaria ser feito, dentre outros fatores.
Um cliente só deve participar de um processo de desenvolvimento em dois momentos: para dar o aceite no que será feito e para avaliar os resultados após os testes de software.
Abraço,
Marcelo Schumacher
Fiquei sabendo de uma situação que ocorre seguidamente em nossos ambientes de desenvolvimento de software e achei interessante compartilhar. Trata-se de um ocorrido que gostaria de descrever a vocês.
Durante um mês inteiro, foi realizado um trabalho em conjunto com um cliente que consistia em realizar ajustes em dois softwares para contemplar um processo de integração entre de diferentes fornecedores. Em outras palavras, o cliente pedia, os analistas dos dois aplicativos entendiam, os desenvolvedores faziam. No final de cada dia, era enviado um release ao cliente com as devidas correções.
Contudo, o teste funcional ficou a encargo do cliente. Resultado? No outro dia pela manhã o cliente relata uma série de incorformidades que não atendiam o que ele havia solicitado. Tão logo os desenvolvedores sabiam do ocorrido, corriam para corrigir e liberar mais um release ainda pela manhã. Ou seja, o velho "release do release".
Além do problema de passar uma resposabilidade que um cliente não tem a mínima capacidade de assumir e até mesmo de assimilar, proceder destas forma deu margem para o cliente pedir o que ele achava que tinha que mudar em ambas as aplicações para atender todo o processo de integração, até mesmo meros relatórios que buscam informações. O cliente alegava que tais informações deveriam constar nos relatórios porque a integração as trafegava.
Ainda por cima, ocorreu muito do cliente solicitar uma integração, ela ser realizada da maneira que ele solicitou e quando o release chegou lá a segunda coisa que ele informa é que não está como ele havia explicado que queria. A primeira coisa era "bom dia". E ainda ocorria de o cliente assumir que pediu desta forma mesmo, mas que havia se enganado e agora as empresas, como meras fornecedoras, tinham de retomar os trabalhos e ajustar o software. senão o cliente nem as pegava. Isto vai de encontro a um post que fiz anteriormente e que trata do Gerenciamento de Requisitos de Software.
Em razão disso, fica envidente que houve uma grande furada aqui ao envolver um cliente para resolver problemas de dois produtos distintos. Ocasionou problemas de produto, desgaste das equipes de desenvolvimento, desgaste do cliente, mudanças de escopo constantes, má definição do que realmente precisaria ser feito, dentre outros fatores.
Um cliente só deve participar de um processo de desenvolvimento em dois momentos: para dar o aceite no que será feito e para avaliar os resultados após os testes de software.
Abraço,
Marcelo Schumacher
Nenhum comentário:
Postar um comentário