Lições do projeto do BALCÃO DO CONSUMIDOR

De DTI Wiki

  1. Treinamento deficiente: treinamento ministrado pela equipe de suporte não é satisfatório pois até então não há o envolvimento necessário para compreensão de todo o projeto. No mesmo sentido, suporte não dispõe de tempo para testes nos novos sistemas. Resolvemos assumir o primeiro treinamento, sendo que a participação do suporte neste é obrigatória.

  2. Organização do treinamento dos usuários: abrir a sessão de treinamento informando que não poderão haver interrupções para discutir requisitos ou features. O instrutor deve explicar todo o projeto para somente ao final abrir espaço para dúvidas e questionamentos, voltando aos pontos a serem discutidos se for necessário. Desta forma a dinâmica planejada para o treinamento não é 'quebrada'.

  3. Sincronização/seguir sequência do processo de desenvolvimento: exemplos: a) não realizar a reunião das lições aprendidas antes do término de todas as etapas do processo de desenvolvimento; b) não treinar os usuários enquanto há fase de testes pendente, a menos que haja modularização; c) usuários não podem testar o sistema em ambiente de produção; d) testador não pode receber atribuições de testes sendo que não foram compilados todos os objetos necessários na TEST.

  4. Levantamento de requisitos: melhorar/aprimorar as técnicas de levantamento de requisitos para buscar informações mais completas dos usuários, pois houve a descoberta de novos requisitos na fase de validação do sistema. Obs.: é fato que os requisitos mudam no decorrer do projeto, e isto não tem como mudar. O que devemos fazer é minimizar a ocorrências das mudanças e gerenciá-las, de forma que não impactem no cronograma (uma forma seria adicionar uma iteração ao projeto). Acreditamos que ao melhorarmos a comunicação com o usuário a incidência de requisitos tardios diminuirá.

  5. Padronização: falta de padronização em telas/relatórios da intranet dificultaram o desenvolvimento. O grupo de padrões será reativado e fará as adequações necessárias aos padrões.

  6. Testes pelos desenvolvedores/analista: melhorar as validações básicas dos sistemas (anteriores à fase de testes). Nos apontamentos do testador não deveriam estar contido erros básicos do Oracle, tais como inconsistências de campos 'not null', tamanho máximo de caracteres, etc... São itens simples que devem ser testados e já resolvidos antes de ser enviado ao analista de testes.

  7. Atenção às características já existentes: exemplo: revisar a auditoria dos sistemas sempre que houver alteração em tabelas da base de dados.

  8. Comunicação entre os envolvidos (analistas/DBA/testador): exemplo: antes do analista de sistemas criar a base de dados deverá dar conversar com o DBA para validar o que está sendo criado, pois podem surgir sugestões de aproveitamento de tabelas já existentes, etc.