Esta é a segunda de 3 partes do "Café com Agile", para quem não viu a primeira parte, link para a parte 1. Se você ficou com alguma dúvida, ou quiser dar alguma sugestão é só deixar um comentário ou entrar em contato comigo ou com o Sandro. Agora sem mais delongas, a segunda parte do Café com Agile.
Milton: Mudando um pouco o rumo da nossa última conversa, vamos falar um pouquinho de projetos agora. Acho que é melhor você falar um pouco sobre como você aprendeu que os projetos devem ser gerenciados
Sandro: O PMI entende que certas áreas de conhecimento são vitais para que um projeto termine com “sucesso” (a entrega do produto do projeto), no tempo programado, no escopo acordado, no custo estimado, e atingindo as expectativas do cliente (QUALIDADE)
Sandro: São 9 as áreas de conhecimento: escopo / tempo / custo / qualidade / aquisição / comunicação / RH / riscos / integração
Milton: No fim das contas temos a trinca: Custo, Prazo e Qualidade. A idéia é ter um equilíbrio para maximizar estes 3 pontos, certo?
Sandro: Sim, imagine um triangulo: de cada lado dele uma dessas áreas
Sandro: Se você aumentar o prazo, aumentará o custo ou o escopo, é bem interessante essa visão
Milton: E ainda tem o escopo, que influencia estas 3 variáveis, certo?
Sandro: Certo
Milton: Bom, aqui já posso observar uma figura muito forte, que é o Gerente de Projetos
Milton: Ele é o cara que pode, e que deve fazer, decidir, definir, mandar e desmandar tudo relacionado ao gerenciamento do projeto
Sandro: Sim, planejamento, planejamento, planejamento
Sandro: E cada área de conhecimento possui um Plano de Ação
Milton: É o Gerente de Projetos que define o escopo com o cliente, ele vende, ele negocia, ele define cronograma, ele define as tarefas, ele faz as estimativas
Milton: Pelo menos sempre tive essa é a impressão
Milton: E ele faz isso em cada uma das 9 áreas de conhecimento
Sandro: Sim, por isso ele não pode (não deve pelo menos) botar a mão na massa, pois tudo isso gasta MUITO, mas MUITO, tempo.
Sandro: Ele tem, durante o seu dia a dia, de passar por todas essas áreas e ver o que cada uma está dizendo para ele fazer naquele dia/momento.
Sandro: Além disso, cuidar da expectativa, problemas, atrasos, etc.
Sandro: E é claro que, o bom-senso tem que prevalecer. Se tenho um projetinho, vou precisar agir no plano de aquisição / comunicação da mesma forma que um projeto normal? Ele tem que analisar isso e deixar de fora o que não será necessário.
Milton: Entendi. Eu acho que vamos voltar nessa questão do bom-senso depois, por enquanto, eu acho legal a gente voltar a questão do escopo
Milton: Até onde sei, quando se fala em PMI, normalmente é definido todo o escopo do projeto logo na fase inicial, e tudo é desenvolvido com base neste escopo
Milton: Ai, qualquer coisa fora desse escopo irá impactar diretamente no custo e prazo do projeto
Sandro: Sim, mas quando o cliente solicita uma alteração nele, essa solicitação irá para uma Comissão, onde será analisado o impacto sobre o projeto. A partir dela é que definirá se será feito sem cobrar, ou então cobrando e alterando o cronograma, etc. Negociando com o cliente em seguida.
Sandro: E fica tudo registrado, para fins de documentação, nada é boca a boca, mesmo porque é esse registro que circulará dentro da equipe do projeto
Milton: É, acho que agora é hora de começar a comparar as coisas com scrum um pouco
Milton: Talvez a maior diferença entre um projeto "tradicional" e outro que siga a filosofia agile, é a questão do escopo
Milton: Em agile não existe um escopo fortemente detalhado no início do projeto, o escopo é associado a um objetivo do negócio do cliente
Milton: Digamos que o seu cliente é uma panificadora. O escopo desse projeto pode ser definido como "Quero aumentar a minha capacidade de atendimento dos meus clientes, controlando melhor os pedidos e a produção da minha panificadora"
Milton: O escopo morre ai, você não precisa saber detalhadamente que campos existirão no cadastro de clientes, como vai ser o controle de estoque, se precisa implementar TEF nas vendas logo no início do projeto
Milton: Você não precisa disso, porque o software será desenvolvido aos poucos, em ciclos ou iterações, e os requisitos serão levantados conforme forem sendo desenvolvidos
Sandro: Mas e o prazo e custo disso?
Milton: A cada iteração ou ciclo, você desenvolve pequenos incrementos do produto, cada um destes incrementos tem prazo de entrega e custos fixos
Sandro: Definidos no inicio do projeto?
Milton: Sim
Sandro: Não visualizei ainda. Se você acorda com o cliente: serão 300 incrementos. Cada incremento custa $ XX e leva YY dias.
Sandro: Levará então XXXX dias e custara YYY. Entrego em 31/12/2008. Mais ou menos isso?
Milton: Não. Em scrum, assumimos que não há como saber "quantos incrementos" serão necessários, temos apenas uma estimativa inicial que será ajustada continuamente durante o projeto.
Milton: No scrum, essa lista é chamada de Product Backlog. Ela é mantida e priorizada pelo Product Owner(um dos papéis do scrum), que é responsável pelo retorno financeiro do projeto
Sandro: Mas então o cliente não sabe quanto lhe custará e o tempo que levara o projeto, certo? Somente valores estimados, certo?
Milton: Para estimar quantos incrementos serão necessários, você precisa ter uma lista do que tanto o produto final deve ter. Com essa lista em mãos, é possível fazer uma estimativa inicial (junto com a equipe de desenvolvimento) de quantos incrementos serão desenvolvidos até o final do projeto. Normalmente há uma limitação de custo, nesse caso a quantidade de incrementos que serão entregues será limitada e o custo e prazo de entrega do projeto podem aumentar ou diminuir.
Milton: Agora, em valores exatos, não há como saber o custo e prazo do projeto. E se parar pra pensar, mesmo no esquema que você me disse também não há como saber. Você acaba estimando e assumindo um contrato de risco
Milton: Ai, se você terminar antes, você ganha ou o cliente te paga menos, se terminar depois alguém vai ter que assumir o prejuízo
Milton: Como você nunca via querer terminar muito antes do prazo, normalmente o cliente paga o pato, concorda?
Sandro: Claro, sem dúvida, se você estiver terminando o projeto muito antes do prazo e houver outras prioridades, o projeto do cliente será deixado um pouco de lado para maximizar os lucros Sandro: Entendi, o negocio é a negociação, estando tudo transparente no início (e no contrato também) vale o bom-senso e a aceitação da forma como será projetado o produto final
Milton: Exato, a coisa começa ai, toda a forma de se negociar comercialmente já muda
Aguardem, em breve teremos a parte 3.
Milton: Mudando um pouco o rumo da nossa última conversa, vamos falar um pouquinho de projetos agora. Acho que é melhor você falar um pouco sobre como você aprendeu que os projetos devem ser gerenciados
Sandro: O PMI entende que certas áreas de conhecimento são vitais para que um projeto termine com “sucesso” (a entrega do produto do projeto), no tempo programado, no escopo acordado, no custo estimado, e atingindo as expectativas do cliente (QUALIDADE)
Sandro: São 9 as áreas de conhecimento: escopo / tempo / custo / qualidade / aquisição / comunicação / RH / riscos / integração
Milton: No fim das contas temos a trinca: Custo, Prazo e Qualidade. A idéia é ter um equilíbrio para maximizar estes 3 pontos, certo?
Sandro: Sim, imagine um triangulo: de cada lado dele uma dessas áreas
Sandro: Se você aumentar o prazo, aumentará o custo ou o escopo, é bem interessante essa visão
Milton: E ainda tem o escopo, que influencia estas 3 variáveis, certo?
Sandro: Certo
Milton: Bom, aqui já posso observar uma figura muito forte, que é o Gerente de Projetos
Milton: Ele é o cara que pode, e que deve fazer, decidir, definir, mandar e desmandar tudo relacionado ao gerenciamento do projeto
Sandro: Sim, planejamento, planejamento, planejamento
Sandro: E cada área de conhecimento possui um Plano de Ação
Milton: É o Gerente de Projetos que define o escopo com o cliente, ele vende, ele negocia, ele define cronograma, ele define as tarefas, ele faz as estimativas
Milton: Pelo menos sempre tive essa é a impressão
Milton: E ele faz isso em cada uma das 9 áreas de conhecimento
Sandro: Sim, por isso ele não pode (não deve pelo menos) botar a mão na massa, pois tudo isso gasta MUITO, mas MUITO, tempo.
Sandro: Ele tem, durante o seu dia a dia, de passar por todas essas áreas e ver o que cada uma está dizendo para ele fazer naquele dia/momento.
Sandro: Além disso, cuidar da expectativa, problemas, atrasos, etc.
Sandro: E é claro que, o bom-senso tem que prevalecer. Se tenho um projetinho, vou precisar agir no plano de aquisição / comunicação da mesma forma que um projeto normal? Ele tem que analisar isso e deixar de fora o que não será necessário.
Milton: Entendi. Eu acho que vamos voltar nessa questão do bom-senso depois, por enquanto, eu acho legal a gente voltar a questão do escopo
Milton: Até onde sei, quando se fala em PMI, normalmente é definido todo o escopo do projeto logo na fase inicial, e tudo é desenvolvido com base neste escopo
Milton: Ai, qualquer coisa fora desse escopo irá impactar diretamente no custo e prazo do projeto
Sandro: Sim, mas quando o cliente solicita uma alteração nele, essa solicitação irá para uma Comissão, onde será analisado o impacto sobre o projeto. A partir dela é que definirá se será feito sem cobrar, ou então cobrando e alterando o cronograma, etc. Negociando com o cliente em seguida.
Sandro: E fica tudo registrado, para fins de documentação, nada é boca a boca, mesmo porque é esse registro que circulará dentro da equipe do projeto
Milton: É, acho que agora é hora de começar a comparar as coisas com scrum um pouco
Milton: Talvez a maior diferença entre um projeto "tradicional" e outro que siga a filosofia agile, é a questão do escopo
Milton: Em agile não existe um escopo fortemente detalhado no início do projeto, o escopo é associado a um objetivo do negócio do cliente
Milton: Digamos que o seu cliente é uma panificadora. O escopo desse projeto pode ser definido como "Quero aumentar a minha capacidade de atendimento dos meus clientes, controlando melhor os pedidos e a produção da minha panificadora"
Milton: O escopo morre ai, você não precisa saber detalhadamente que campos existirão no cadastro de clientes, como vai ser o controle de estoque, se precisa implementar TEF nas vendas logo no início do projeto
Milton: Você não precisa disso, porque o software será desenvolvido aos poucos, em ciclos ou iterações, e os requisitos serão levantados conforme forem sendo desenvolvidos
Sandro: Mas e o prazo e custo disso?
Milton: A cada iteração ou ciclo, você desenvolve pequenos incrementos do produto, cada um destes incrementos tem prazo de entrega e custos fixos
Sandro: Definidos no inicio do projeto?
Milton: Sim
Sandro: Não visualizei ainda. Se você acorda com o cliente: serão 300 incrementos. Cada incremento custa $ XX e leva YY dias.
Sandro: Levará então XXXX dias e custara YYY. Entrego em 31/12/2008. Mais ou menos isso?
Milton: Não. Em scrum, assumimos que não há como saber "quantos incrementos" serão necessários, temos apenas uma estimativa inicial que será ajustada continuamente durante o projeto.
Milton: No scrum, essa lista é chamada de Product Backlog. Ela é mantida e priorizada pelo Product Owner(um dos papéis do scrum), que é responsável pelo retorno financeiro do projeto
Sandro: Mas então o cliente não sabe quanto lhe custará e o tempo que levara o projeto, certo? Somente valores estimados, certo?
Milton: Para estimar quantos incrementos serão necessários, você precisa ter uma lista do que tanto o produto final deve ter. Com essa lista em mãos, é possível fazer uma estimativa inicial (junto com a equipe de desenvolvimento) de quantos incrementos serão desenvolvidos até o final do projeto. Normalmente há uma limitação de custo, nesse caso a quantidade de incrementos que serão entregues será limitada e o custo e prazo de entrega do projeto podem aumentar ou diminuir.
Milton: Agora, em valores exatos, não há como saber o custo e prazo do projeto. E se parar pra pensar, mesmo no esquema que você me disse também não há como saber. Você acaba estimando e assumindo um contrato de risco
Milton: Ai, se você terminar antes, você ganha ou o cliente te paga menos, se terminar depois alguém vai ter que assumir o prejuízo
Milton: Como você nunca via querer terminar muito antes do prazo, normalmente o cliente paga o pato, concorda?
Sandro: Claro, sem dúvida, se você estiver terminando o projeto muito antes do prazo e houver outras prioridades, o projeto do cliente será deixado um pouco de lado para maximizar os lucros Sandro: Entendi, o negocio é a negociação, estando tudo transparente no início (e no contrato também) vale o bom-senso e a aceitação da forma como será projetado o produto final
Milton: Exato, a coisa começa ai, toda a forma de se negociar comercialmente já muda
Aguardem, em breve teremos a parte 3.
Link para a Parte 1
Link para a Parte 3
Nenhum comentário:
Postar um comentário