Após a pilotagem "quente" na semana passada, o cérebro aparentemente relaxou e foi pego pela pergunta: "O que deveria ter sido feito para que tudo corra bem e sem todos esses nervos?"
As opções de resposta que ele gerou, tentarei descrever.
Sobre mim
9 anos - consultor de TI SAP ERP. Responsabilidades: projeto, formação de equipe, teste e depuração, treinamento, pilotagem.
Quadro de aplicabilidade
Ele escreveu concentrando-se em projetos de 3 a 4 meses a 1 ano com complexa integração entre sistemas.
Tendo decidido não correr o risco de me afogar na conquista do perfeccionismo, tendo perdido a paixão inicial pela escrita, tive que abandonar as reivindicações para um alto nível de estrutura, consistência e perfeição. Pelas mesmas razões, escrevi o texto apenas "por experiência pessoal", não li textos que estavam em sintonia com o tópico antes da publicação.
Portanto, até certo ponto, conto com os comentaristas para, possivelmente, escrever uma segunda edição, na qual os critérios acima já estavam no nível adequado.
Glossário
BA - analista de negócios
BZ - base de conhecimento do projeto
BT - requisitos de negócios
TI - arquiteto e consultores da equipe do projeto
KP - usuário principal do
MC - consultor júnior, enikeist
PR - solução de design
Prod - produt produtora
Desenvolvedor - desenvolvedor de sistemas
CT - desenvolvedor de CT - cenários de teste
SC - senior consultor, designer
TK - termos de referência
Chaves para o sucesso do projeto de TI
Promessa geral - comunicação estabelecida
É necessário alcançar a sincronicidade entre negócios e TI na percepção dos requisitos de negócios, cenários de teste, solução de design e como será a implementação.
BT detalhada e atenciosa
A BT deve ter um entendimento completo e síncrono entre negócios e TI. Para fazer isso, deve ser BA e CP (idealmente, quando BA é um antigo CP).
Conjunto completo de scripts de teste
O número máximo de cenários maximamente detalhados deve ser conhecido e calculado antes de escrever a solução. Os scripts devem ser escritos em ordem, do mais comum ao mais raro. Este último, no caso de sua automação cara, deve ter um controle manual cuidadoso.
Divisão de trabalho em TI
A equipe do projeto deve ter uma divisão de acordo com a complexidade intelectual do trabalho. É bom que o designer tenha a habilidade de projetar a documentação estilisticamente, sem nenhum custo extra. Caso contrário, é melhor dar a orientação de "beleza" a uma pessoa com uma posição júnior.
O mesmo se aplica ao conteúdo de TK / PR no estado atual:
- O Comitê de Investigação escreve ao desenvolvedor sobre os ajustes e coloca o MK em uma cópia
- O MK coleta e reflete alterações no modo de edição usando controle de versão
- SK aceita edições
- MK atualiza a documentação no BZ
Os testes também devem ser delegados ao MC.
Não sei como está fora da SAP, mas o princípio de um consultor-harvester é muito usado aqui, o que faz tudo (design, teste, documentação de escrita).
Como resultado, qualidade, termos (e "dinheiro") sofrem e os riscos associados ao fato de tudo estar vinculado para 1 pessoa.
Testando scripts antes do lançamento
- O teste deve ser realizado em um ambiente próximo ao ambiente do produto (idealmente em uma cópia do vendedor).
- Participação obrigatória de pessoas que trabalharão diretamente com o funcional (é aconselhável realizar um programa educacional antes da decisão).
Espaço comum para equipes de sistemas integradores
Quando há uma integração complexa no projeto, é extremamente importante criar um campo comum do contexto do projeto e fornecer "próximo ao corpo". Idealmente, toda a equipe do projeto deve estar em uma sala. Caso contrário, você precisará de uma pessoa separada ou de uma ferramenta útil para garantir a sincronização entre as equipes.
Adequação técnica do host
A reconciliação formal por relações públicas é o flagelo do projeto. O anfitrião deve imaginar completa e detalhadamente a decisão. Se o projeto envolver uma profunda modernização da funcionalidade existente, a empresa deve conhecê-lo bem.
Idealmente, se o host for uma pessoa de negócios perfeitamente conhecedora, com lógica consistente e estruturada.
Moderador Piloto
Neutro para TI e pessoa de negócios com os ingredientes de um árbitro. Cria um plano de pilotagem, elabora relatórios de testes, acompanha os comentários e suas correções.
Se houver um impulso, existe uma idéia para descrever os problemas que podem surgir se as recomendações descritas não forem seguidas.