No mundo das modernas tecnologias de TI, quando vários aplicativos do Google Play e Appstore informam diariamente sobre atualizações, é muito comum ouvir a equipe do projeto para a implementação do sistema ERP “o projeto levará de 9 (otimista) a 12 meses (realista)”. Além disso, existem projetos mais complexos. Em uma das empresas em que meu amigo trabalhava, apenas o estágio de criação e assinatura do design dos processos durou 6 meses. O volume do documento de design mostrou-se bastante impressionante e, na forma impressa, poderia muito bem ter salvado a vida de um guerreiro da China antiga (eles dizem que usavam papel como material para a armadura). Os dias da China antiga passaram, mas hoje essa pilha de papel continua a salvar, se não vidas, pelo menos os sistemas nervosos dos consultores na fase de colocação do sistema em operação. Mas o que um documento de design não salva é uma mudança no tempo do lançamento do projeto e problemas com a qualidade do sistema no momento da operação comercial. Vamos tentar descobrir por que isso está acontecendo e se é possível de alguma maneira diferente.
Imagine que você está solicitando a reparação do seu novo apartamento. Antes de começar o trabalho, a equipe do contratante solicita que você assine um documento de texto, geralmente sem ilustrações, sobre como o seu apartamento cuidará do reparo, incluindo todos os detalhes: soquetes, interruptores, móveis etc. O líder da equipe avisa que as mudanças durante a fase de aceitação são mais prováveis total levará a custos adicionais. Por esse motivo, você aborda com responsabilidade a tarefa, gasta muito tempo e, no final, assina o documento. Bem, suponha que você saia por seis meses do país. E confie completamente na equipe de implementação para fazer o reparo sozinho, sem nenhum controle e monitoramento de sua parte. Após seis meses, volte, entre no apartamento e verifique se o apartamento pronto não atende totalmente às suas expectativas. Em seguida, peça à equipe do projeto que refaça alguns detalhes, por exemplo, mova os soquetes para mais perto da geladeira. A equipe do projeto diz que será muito caro transferir as tomadas e levar muito tempo, porque você tem que cavar a parede e azulejos etc. Você entra no quarto, liga o ar condicionado já instalado e entende que ele irá explodir à noite quando você . Peça à equipe para movê-lo, mas você obtém a mesma resposta que com os soquetes. No entanto, isso é uma questão de princípio para você e você diz que não começará a morar no apartamento até que o ar-condicionado esteja onde você precisar, porque no seu apartamento atual é exatamente onde você precisa, e você não vê sentido em se mudar. piorará o conforto da sua vida diária. Como resultado, você liga para um apartamento três meses depois do plano original, com um excesso de orçamento de 20%.
O principal problema, na minha opinião, é que estamos tentando prever e corrigir todos os detalhes no estágio de design antes de começar o trabalho. A fase de projeto está atrasada, porque os usuários de negócios raramente podem se dedicar completamente ao projeto; eles precisam lidar com seus processos de negócios diários. No momento em que o design é assinado, eles acumularam uma lista pendente bastante extensa de tarefas pendentes e não estão mais prontos para se envolver no projeto até a fase de teste. Eles já gastaram muito tempo planejando todos os detalhes e gostariam de ver um sistema finalizado e ajustado. No entanto, o resultado final não atende às expectativas. Uma razão para isso é ilustrada abaixo:
Em nossa empresa, estamos testando com sucesso uma nova abordagem de projetos para a implementação e replicação de sistemas ERP. Além disso, em projetos de replicação, a abordagem permite concluir o projeto ainda mais rápido que o plano usual, com fases sucessivas de design, desenvolvimento e teste (também conhecido como Waterfall).
Passamos disso:
Para isso:
Chamamos essa abordagem de mista (Waterfall - Agile) porque usamos os elementos Agile (trabalho de sprint) e Waterfall (a operação comercial começa apenas após a conclusão de todo o projeto). A aceleração se deve ao fato de que, em primeiro lugar, trabalhamos com usuários corporativos em paralelo (trabalhamos no design de sprints futuros e customização, desenvolvimento dos atuais) e, em segundo lugar, “transferimos soquetes” para mais perto do futuro refrigerador antes da colocação dos ladrilhos e conjunto de cozinha montado. Quanto maior o volume do projeto, maiores serão os ganhos de tempo e qualidade em comparação com a abordagem clássica da Waterfall.
Exemplo de projeto em Marte usando uma abordagem combinada
As principais características do projeto:
- 5½ períodos (22 semanas) do início ao lançamento
- Equipe completa do projeto - 40 pessoas (usuários de negócios e consultores de TI, desenvolvedores)
- 4 equipes funcionais dentro da equipe do projeto - Finanças, Compras, Logística e Vendas, Departamento de Controle de Qualidade
- 4 ciclos de teste de negócios com 93% de scripts bem-sucedidos na primeira tentativa. 5 oficinas em período integral
No estágio pré-projeto, estimamos que faríamos o projeto em 30 semanas. De fato, usando a abordagem Agile, fizemos tudo em 22 semanas. Por 4 meses de operação após o lançamento, recebemos 1 solicitação de alteração da empresa.
Principais fatores de sucesso
Equipes internas de TI. Assim que possível, organize com as principais equipes de TI que estarão envolvidas na implementação. Recrute suporte de gerenciamento para dialogar com um contratado externo.
Empreiteiro externo. A equipe do projeto do contratado deve incluir profissionais que estejam bem cientes do próprio sistema e dos princípios de implementação Agile. Iniciantes não devem ser. Realize entrevistas seletivas com a equipe antes de assinar o contrato.
A equipe de negócios deve ter a oportunidade e o desejo de participar regularmente do projeto durante todas as fases do desenvolvimento. Isso não significa que a empresa terá que trabalhar mais. Redistribuímos o tempo da fase usual de design e teste em cada segmento do desenvolvimento.
Algumas perguntas frequentes
Pergunta 1: O departamento comercial pede para assinar um contrato com um empreiteiro de valor fixo antes de iniciar o desenvolvimento. Mas como avaliar o custo se não houver um projeto concluído e assinado?
Resposta 1: Assinamos um contrato de equipe fixa com um contratado - fixamos a equipe e o tempo de implementação do projeto, por exemplo, 8 meses. Não é o mesmo que Time-Material, pois registramos a duração e a quantidade total de trabalho. Ao mesmo tempo, continuamos flexíveis na alteração / adição de requisitos de negócios, se a duração do projeto e a equipe não aumentarem.
Pergunta 2: E se os usuários corporativos adicionarem constantemente novos requisitos durante a revisão e o planejamento de cada sprint?
Resposta 2: Nesse caso, solicitamos que você priorize os requisitos e remova aqueles que têm a menor prioridade e não se enquadram nos prazos do projeto. I.e. adicione um novo em vez de algo existente. Todas essas mudanças / novos requisitos estarão esperando por nós em qualquer caso, na fase de aceitação, independentemente da abordagem. Porém, no caso de aceitação intermediária no final de cada sprint, temos mais oportunidades de gerenciar esses requisitos, enquanto, ao aceitar imediatamente antes do lançamento, arriscamos o tempo do lançamento e a qualidade do sistema (qualidade por definição é a correspondência do resultado final com as expectativas do usuário, não design de texto).
Se você estiver interessado neste artigo, tiver alguma dúvida ou apenas quiser compartilhar uma opinião sobre o exposto, ficarei grato se você compartilhar comentários na publicação ou em uma mensagem pessoal. Ilustrações e conteúdo ideológico do artigo com a participação de Angelina Abdullaeva
angelina .abdullayeva.