Na minha opinião, o artigo
“Chefes de sugadores de sangue no contexto ...” não divulgou o motivo da quebra de equipes autônomas, mas o motivo disso foi a baixa velocidade de distribuição de requisitos para o produto e a falta de entendimento de que o líder sempre faz parte da equipe.
Alterando a abordagem do planejamento do departamento de design durante o desenvolvimento de um novo produto, você pode aumentar a velocidade com a qual as informações são distribuídas, o que é muito mais importante para um projeto do que apenas ter informações.
Design clássico
No esquema clássico, o processo de planejamento do trabalho e o desenvolvimento têm prazos claros. Normalmente, o processo de planejamento ocorre antes do desenvolvimento. No final do planejamento de cada mês, aparece um "cronograma de trabalho em rede", segundo o qual o processo de desenvolvimento de produto pelo departamento de design começa. Não existem muitos tipos de gráficos de rede - estes são principalmente
PERT e
GANTT . Os termos no cronograma da rede geralmente são declarativos e não são copiados por nada, o que cria algum escopo imaginário ao executar o trabalho no processo de desenvolvimento pelo departamento de design e desenvolvimento. De fato, os termos do cronograma da rede são acordados com o cliente e o contratado é forçado a cumpri-los; caso contrário, a falha nos prazos principais de desenvolvimento pode ameaçar o fechamento do projeto como um todo. Ninguém pergunta aos desenvolvedores no esquema clássico, e o gerente de projetos simplesmente reduz os prazos de cada trabalho para os desenvolvedores.
Pelo lado, parece que o gerente de projeto está dando a todos uma espécie de vara de pescar (ferramenta) e diz: “Pegue enquanto a carpa é crua. No final do mês, irei verificar quantas foram capturadas. Precisamos pegar 2 toneladas. ” Durante o mês, o gerente de projeto realiza reuniões nas quais informa quem, quantas toneladas e que tipo de peixe ele pescou. No final do mês, o gerente de projeto lança um novo cronograma de rede "atualizado", segundo o qual o cliente deseja capturar não a carpa crucian, mas, por exemplo, a
abobrinha . O "sábio gerente de projeto" tem a chance de obter um bônus por comprar um novo plasma ou um novo SUV moderno. Se ele tiver sorte e houver pelo menos alguém que pegue o “peixe abobrinha”, ele pagará um bônus a si mesmo e ao pescador sortudo e aplicará uma multa a outros.
Esse modo de operação força o gerente de projeto a assumir algumas das tarefas de desenvolvimento por conta própria, e os desenvolvedores desse projeto estão constantemente atrasados no trabalho e, às vezes, precisam ir aos fins de semana para poder desenvolver novas interfaces de interação do usuário com o produto a tempo. Tudo isso, como mencionei acima, é ainda mais agravado pelo fato de que os requisitos para o produto final podem mudar e, então, o cronograma da rede é ajustado e o ajuste é feito de forma a não afetar as datas principais do projeto.
Nesse esquema, todo trabalho depende do fator humano, que desempenha um papel fundamental. O fator humano pode ser minimizado com a introdução de sistemas automatizados de planejamento e desenvolvimento, o que, em essência, muitas pessoas implementam
CAD ,
CAM ,
CAE ,
PDM ,
ERP ,
CRM ,
PLM etc. em suas empresas.
No entanto, a base na forma de um esquema clássico, quando o planejamento e o desenvolvimento têm limites de tempo claros, permanece inalterada. Como resultado, os desenvolvedores precisam manter várias edições atualizadas do produto e da documentação de software em cada sistema automatizado, além de oferecer suporte constante à integração do sistema, o que é muito problemático nas atuais condições competitivas do mercado de TI. Em última análise, o cliente precisa apenas de uma coisa - é o produto acabado ou a produção simplificada. No esquema clássico, a lista de documentação desenvolvida pelo contratado será sempre redundante, uma vez que nem o cliente nem o contratante têm total confiança de que o objetivo será alcançado, o que significa que é necessário documentar o processo ao máximo para identificar quem é o culpado pelo não cumprimento dos prazos. Mesmo que o objetivo final seja inicialmente formulado como específico (específico), mensurável, atingível, realista e baseado em tempo, como resultado, após o primeiro requisito adicional, o artista pode perder a confiança alcançabilidade do objetivo final e, portanto, haverá um detalhamento dos prazos e o encerramento do projeto.
Como, então, garantir que o cliente não altere os requisitos com muita frequência e que o contratado cumpra todos os requisitos no prazo?
No esquema clássico, o processo de planejamento é realizado por um especialista experiente na área de planejamento de projetos, que, com base em sua experiência, determina a lista de tarefas e seus termos. Acredito que tudo isso não poderia ter sido feito por um especialista experiente, porque a própria equipe pode determinar os prazos para a conclusão das tarefas, bem como a lista de tarefas necessárias para a execução. Para isso, o especialista do cliente precisa descrever o produto o mais detalhadamente possível em sua
CT e o prazo em que o produto é necessário, e é isso! A equipe, sob a orientação do gerente de projeto, pode realizar o planejamento do trabalho, identificar armadilhas, decompor tarefas, enfim, todo o trabalho que um especialista experiente realiza.
O "problema" é que, neste caso, cada membro da equipe conhece o objetivo final, é transparente e, a cada momento, sabe-se a que distância a equipe está dele. O "sábio gerente de projeto" não poderá incluir seu mega-objetivo nesse objetivo: "comprar um SUV moderno". Para que ele atinja 100% de seu objetivo com sucesso, ele precisa separar os processos de planejamento e desenvolvimento e fornecer listas de tarefas em lotes à medida que surgem "problemas". Nesse caso, a tarefa do gerente de projetos é desviar a atenção da equipe para o objetivo final do projeto, tanto quanto possível, e concentrar sua atenção na solução exatamente na hora certa para o trabalho em rede específico. Em outras palavras: “encha a equipe com trabalho de rotina”.
Um esquema de trabalho fundamentalmente diferente é um esquema de trabalho usando metodologias de desenvolvimento flexíveis, onde o princípio principal é:
entregas contínuas freqüentes de um produto de valor para o cliente.Para conseguir isso, em primeiro lugar, a transparência do processo de planejamento permite, quando cada membro da equipe conhece o objetivo final e participa da formação do pool de tarefas pelas próximas 1-4 semanas, após as quais o cliente verá a primeira versão do produto com novas funcionalidades. É de responsabilidade do gerente de projeto obter aprovação do cliente ou simplesmente notificá-lo da versão do produto com novas funcionalidades, que estarão prontas após a conclusão da iteração. Todos os requisitos adicionais provenientes do cliente devem ser levados em consideração ao planejar a equipe do conjunto de tarefas nas iterações a seguir.
Para não se desviar do caminho para alcançar o objetivo final, a equipe se reúne todos os dias para comícios de 15 minutos, nos quais cada membro da equipe responde a três perguntas:
- O que foi feito desde a reunião anterior?
- O que será feito para o próximo rali?
- Quais são os problemas?
No caso em que o planejamento é realizado separadamente do desenvolvimento, a resposta para a segunda pergunta é dada pelo gerente de projeto, no entanto, assim como a resposta para a terceira.
No final de cada iteração (sprint), a equipe demonstra o produto com novas funcionalidades para o cliente. Após cada demonstração, a equipe se reúne separadamente do cliente para realizar uma retrospectiva. Existem muitos métodos para conduzir retrospectivas, quero observar uma retrospectiva no estilo “PLUS / DELTA”, em que cada membro da equipe expressa 10 pontos positivos (PLUS) e dez pontos que fizeram a equipe se desviar (DELTA) de alcançar o objetivo pretendido.
No esquema de trabalho usando técnicas de desenvolvimento flexíveis, os sistemas automatizados desempenham um papel fundamental, permitindo obter um produto com a nova funcionalidade mais avançada no final da iteração. Após cada iteração, o produto pode ser enviado para desenvolvimento tecnológico em sistemas
ERP ou
CRM , a fim de iniciar ainda mais a produção de um protótipo de produto para teste em condições o mais próximo possível dos reais. Assim, após cada iteração, o produto de software é refinado e novos requisitos funcionais são criados. Os próprios clientes que já estão no estágio de desenvolvimento tecnológico ou em um projeto piloto por meio do feedback no sistema
CRM expressarão requisitos nos quais você nem pensaria. O principal é transmitir esses requisitos aos desenvolvedores a tempo, e não escondê-los em seus corredores da razão, como às vezes os "Gerentes de Projeto Sábios" fazem.
Tirar conclusões
As tentativas de construir o processo de desenvolvimento de acordo com o esquema clássico, usando metodologias flexíveis, geralmente falham, e ver muitos gerentes de projeto em prol de seus "megacels" ou simplesmente seguir automaticamente o princípio fundamental de "dividir e conquistar" se recusar a aplicar na prática o conhecimento moderno de gerenciamento de projetos.