Os 3 Poderes da Indústria
09 Nov
Posted by: Carlos Santos in: Engenharia, Engenharia de Produção, Indústria, Projetos
Para quem trabalha em indústria o é muito interessante a analogia que será feita a seguir.
Os Três Poderes da Indústria
Primeiro vamos começar com uma indústria que possui seus departamentos “chaves” comparados aos três poderes do Estado. Tal qual no Brasil temos o Executivo, Legislativo e Judiciário podemos atribuir as mesmas responsabilidades desses poderes a áreas de uma indústria.
Legislativo - esse poder na indústria é representado pela Engenharia. A Engenharia, seja de desenvolvimento, de produtos, de processo, de fábrica ou industrial (quaisquer desses tipos) é responsável por definir padrões, especificações o que podemos comparar à criação das “leis”. Baseado nessas “leis” que a fábrica segue as regras para poder produzir seus produtos. Ela elabora os pedrões e especificações.
Executivo - esse poder na indústria é representado pela Produção. A Produção executa a fabricação dos produtos de acordo com as regras definidas pela Engenharia. Quando algo não está bem especificado pela Engenharia, então começam acontecer os problemas, defeitos, rejeitos, que irão influenciar no resultado da qualidade do produto. Essas “leis” da Engenharia que são executadas pela Produção podem estar relacionadas tanto ao produto quanto ao processo.
Judiciário - esse poder na indústria é representado pela Qualidade. A área de Qualidade julga o bom processo, bom produto e sua permanência de qualidade no mercado, ou seja, confiabilidade. Essa área deve ser independente hierarquicamente da Produção ou da Engenharia para ter autonomia em bloquear saída de produtos para o mercado que não estejam de acordo com as “leis” (normas) do processo ou “leis” (especificações) técnicas elaboradas pela Engenharia.
Existem outras áreas importantes na indústria, porém esses três poderes mencionados anteriormente, se forem bem “empoderados” pelos donos das indústrias e bem representados por profissionais que “briguem” por essas responsabilidades de forma independente, farão toda a diferença no sucesso de uma empresa.
Você concorda com a analogia aos três poderes? Por isso que existe tanta “briga” saudável numa fábrica…
Nos últimos anos observei a transição de entendimento sobre o Scrum Master (SM) e ao mesmo tempo preconceito com esse papel.
No início todos queriam ser SM porque era novidade, o nome é bonito e talvez fosse alguma coisa melhor que Gerente de Projetos (GP), depois banalizou o SM e achavam que era um papel burocrático ou fazedor de documento e convocador de reuniões. Todos então queriam ser um Product Owner (PO)!
As pessoas da área de projetos, por ignorância ou por vaidade, se preocupam muito com títulos, mesmo que seja em papéis ou certificados e esquecem de fazer o básico: bom trabalho para ter reconhecimento e sucesso.
Mas o que se espera de um Scrum Master?
Para mim, que já atuei como GP, SM e PO está bem claro o papel de cada um. No Scrum não existe GP ou Líder de Projetos (LP)! Só existem SM, PO e Scrum Team (ST).
O Scrum veio pra dividir o papel do GP em duas partes: gerente de pessoas e gerente de produto.
Pela minha experiência, mesmo que tivesse um projeto com uma equipe de 5 pessoas, 1 Scrum Master e 1 Product Owner bem definido, mesmo que esses 2 líderes custassem caro valeria a pena. O Gerente de Projetos tem que ser um iluminado que advinha tudo, define o escopo, requisitos, documentação, cuida das pessoas, orçamento, treinamento, impedimentos, simplesmente tudo! Ele não consegue na maioria das vezes fazer tudo isso e ainda mais se sobrecarregando com projetos que rodam em tempos fixos com entregas marcadas pra determinadas datas. Mas o objetivo desse artigo não é falar sobre o GP. Queria falar especificamente sobre o que espero do Scrum Master.
Hoje sai procurando uma pessoa pelos corredores que tivesse o seguinte perfil: maturidade, experiência, respeito, comprometimento, atitude, liderança e contei nos dedos de uma mão algumas pessoas que poderiam me ajudar na equipe que temos. Essa pessoa teria que conquistar o respeito e confiança da equipe, resolver os problemas levantados diariamente, se preocupar com questões como: viagens de trabalho, aquisições de material de consumo, controle de banco de horas ou hora-extra, verificação de necessidade de aquisição de livros ou assinaturas, disparo de compra de equipamentos ou programas de computador (quando necessário), disparo de solicitações de treinamentos (identificados para o projeto), conduzir reuniões, ajudar os colegas, interagir com o Product Owner, defender o time e também dar uma dura quando for preciso.Quem é esse cara? Muitos responderiam: “é o gerente de projetos” ou outros “é o gerente de linha”. Errado! Esse cara é o Scrum Master!
Os preconceituosos acham que o Scrum Master só resolve impedimento em post-it, marca reunião e chama pro Daily meeting quando a turma esquece do horário, mas não é apenas isso! Aliás não é exatamente isso!
O Scrum Master é um líder de pessoas que mantém o processo funcionando perfeitamente de acordo com as regras do framework. Para um programa ele atua com esse lado do gerente de projetos e/ou do gerente de linha.
O outro lado técnico, de negociação e outros atributos que um gerente de projetos possui, é assumido pelo Product Owner, que também é um líder, com iniciativa, articulado, boa comunicação escrita e verbal, jogo de cintura, honesto, justo, focado no negócio e produto.
Não é difícil ter todos esses atributos em uma pessoa só e ainda ter que entregar produto no tempo certo com bom, custo, qualidade e satisfação do cliente?
Então por que as pessoas querem ser apenas gerente de projetos, rodar um Scrumbutt e ainda achar que Scrum Master é um babysitter do time? Será que tem algo errado? Será que tem Scrum Master? Será que tem Mindset?
Podemos encontrar vários livros de educação financeira e todos eles são unânimes que precisamos multiplicar nossos ganhos através de bons investimentos e prazos.
Quando a gente começa a trabalhar jovem e alguém fala:
- “você já pensou em fazer um plano de providência?” ou
- “você já pensou alguma vez como será sua vida financeira ao se aposentar?” ou
- “você guarda algum dinheiro para o futuro?”.
Respostas imediatas:
- “não está na época de me preocupar com isso, ainda sou muito novo” ou
- “esse negócio de aposentadoria é pra velho!” ou
- “tenho é que curtir a vida e depois a vida me leva…”
Mas se formos um pouco mais críticos com relação à essas perguntas podemos buscar a mensagem transmitida como: curtir a vida, porém se preparando pra curtir ela melhor quando ficarmos mais maduros.
Dos 20 aos 30 a vida é muita balada, muita resistência pra beber, dançar, noitadas, etc.
Dos 30 aos 40 a gente começa a diminuir a velocidade e procurar alguma coisa. E também começa a ganhar um pouco mais de dinheiro.
Dos 40 aos 50 a gente pensa: “puxa, por que eu não tinha essa cabeça naquela época dos 30 anos?!”
Nossa vida útil começa lá pelos 20 a 25 anos. Aproveitamos bastante e quando chegamos na meia-idade ainda podemos perceber que nos falta mais uns 20 anos de vida útil caso nos cuidemos bem! Já vi muita gente que chega inteiro (lúcido, boa saúde) aos 60 anos e diz e agora? Vou depender dos meus filhos? Da aposentadoria?
No Brasil quando a gente se aposenta próximo dos 65 anos consegue no máximo R$3.000 por mês! Alguns poucos anos antes disso e cai pela metade esse salário de aposentadoria..
Levantei uma tabela de quanto uma pessoa precisa poupar mensalmente a uma determinada taxa de juros mensais durante um tempo para poder chegar no seu 1 milhão de dinheiro.
Para que serve chegar nesse 1 milhão?
- Para ter uma renda passiva ente R$5.000 a R$10.000 por mês ou
- para multiplicar mais ainda esse valor e investir em negócios, ou
- para aproveitar o resto de vida útil que lhe resta..
- Existem várias respostas de acordo com a necessidade de cada um.
- Só não é interessante pedir dinheiro dos filhos ou netos para comprar um remédio ou tomar um café!
| Juros (am) | 10 anos | 15 anos | 20 anos | 25 anos | 30 anos | 35 anos | 40 anos |
| 0.30% | 6,914.76 | 4,185.48 | 2,842.59 | 2,053.87 | 1,541.83 | 1,187.49 | 931.32 |
| 0.35% | 6,696.40 | 3,983.56 | 2,656.41 | 1,882.83 | 1,385.32 | 1,044.85 | 801.82 |
| 0.40% | 6,483.13 | 3,788.99 | 2,479.66 | 1,723.08 | 1,241.69 | 916.38 | 687.51 |
| 0.45% | 6,274.91 | 3,601.66 | 2,312.11 | 1,574.22 | 1,110.31 | 801.21 | 587.19 |
| 0.50% | 6,071.69 | 3,421.46 | 2,153.54 | 1,435.83 | 990.55 | 698.41 | 499.64 |
| 0.55% | 5,873.44 | 3,248.28 | 2,003.70 | 1,307.50 | 881.74 | 607.04 | 423.62 |
| 0.60% | 5,680.11 | 3,081.98 | 1,862.32 | 1,188.75 | 783.18 | 526.16 | 357.96 |
| 0.65% | 5,491.64 | 2,922.42 | 1,729.12 | 1,079.13 | 694.19 | 454.85 | 301.51 |
| 0.70% | 5,307.99 | 2,769.48 | 1,603.82 | 978.15 | 614.08 | 392.22 | 253.20 |
| 0.75% | 5,129.11 | 2,622.99 | 1,486.11 | 885.32 | 542.16 | 337.40 | 212.02 |
| 0.80% | 4,954.93 | 2,482.81 | 1,375.70 | 800.18 | 477.78 | 289.58 | 177.08 |
| 0.85% | 4,785.40 | 2,348.77 | 1,272.28 | 722.23 | 420.29 | 248.00 | 147.52 |
| 0.90% | 4,620.45 | 2,220.71 | 1,175.54 | 651.02 | 369.10 | 211.96 | 122.61 |
| 0.95% | 4,460.02 | 2,098.47 | 1,085.17 | 586.08 | 323.61 | 180.81 | 101.68 |
| 1.00% | 4,304.05 | 1,981.86 | 1,000.85 | 526.97 | 283.29 | 153.96 | 84.16 |
| 1.05% | 4,152.47 | 1,870.73 | 922.29 | 473.26 | 247.63 | 130.87 | 69.52 |
| 1.10% | 4,005.21 | 1,764.89 | 849.18 | 424.54 | 216.16 | 111.06 | 57.33 |
| 1.15% | 3,862.20 | 1,664.18 | 781.23 | 380.42 | 188.43 | 94.11 | 47.20 |
Vamos analisar juntos:
- Quem aplica na poupança (0.5% ao mês) precisa juntar durante 30 anos todo mês a quantia de R$990,55 para conseguir chegar a 1 milhão!
- Se o cára abre os olhos com 40 anos de idade, precisará juntar R$2.153,54 por mês pra completar 1 milhão. Porém observe que a caderneta de poupança te dá somente isso!
Essa mesma pessoa que consegue boas taxas (exemplo 0.90% ao mês)
- Ao invés de aplicar R$990,55 durante 30 anos, precisaria juntar mensalmente R$369,10!
- Ao invés de aplicar R$2.153,54 durante 20 anos, precisaria juntar mensalmente R$1.175,54!
- Uma pessoa pra juntar dinheiro durante 30 anos teria que começar a investir no mais tardar aos 30 anos de idade.
- Uma pessoa pra juntar dinheiro durante 20 anos teria que começar a investir no mais tardar aos 40 anos de idade.
Ou seja, nunca é tarde, porém o tempo é cruel!
Uma pessoa de 50 anos terá que se sacrificar muito mais! E ainda tem um agravante: a curva de salários ao longo de nossa vida. No Brasil, começa pequena entre os 20 e 30 anos, aumenta entre os 30 a 50 anos e depois tende a diminuir quando chega próximo dos 60 anos. É a senóide salarial…
Tá na hora de correr!!! Procurar economizar, juntar dinheiro, conseguir boas taxas e depois desfrutar… Você já pensou nisso?
Ou seja apesar do investimento previsto na lei ser mais abrangente o que sobra para investir, na prática, é o Nordeste.
A divisão das obrigações de investimentos é assim (usando como exemplo o monitor em São Paulo):
- Total 4% (percentual específico para monitor LCD para SP)
- Interno: 2,16%
- Externo: 1,84%
E o investimento externo se quebra no seguinte:
- Em qualquer lugar: 0,8%
- No Nordeste: 0,64% (0,19% em Instituições oficiais // 0,45 % em instituições não oficiais)
- FNDCT (“fundão”): 0,4%
- TOTAL : 1,84%
Prazo para gastar a verba:
Pela lei tem que gastar dentro do ano.
Existe uma tolerância que o gasto do ano pode ser feito até março do ano seguinte.
Por exemplo, o que foi gasto até março de 2009 pode ser considerado (se quiser) como gasto de 2008.
Mas existe jurisprudência de negociar verbas anteriores acumuladas, porém isso tem que ser negociado com a Suframa, ou seja, cada caso é específico para ser tratado de acordo com a lei interpretada pela representação do MCT e através da Suframa.
Se a empresa resolver montar um Instituto de Pesquisa & Desenvolvimento, ela pode de imediato dispensar alguma verba ( já de P&D) para Consultoria, abertura de instituto, aluguel de uma planta em Manaus, instalações prediais, compra de móveis e equipamentos, etc ? (antes de legalmente estar funcionando?)
É bom lembrar que a prestação de contas para a Suframa é feita através do relatório anual de P&D, e sempre a posteriori.
Ou seja, vamos dizer que a empresa fez todo esse investimento em 2009. Essa “prestação de contas” só vai ser feita no ano seguinte, normalmente até abril de 2010. No relatório anual, que é sempre relatado em termos de “projetos de P&D” isso pode ser lançado como projeto “Implantação do Instituto de Pesquisas”.
Em outras palavras: ninguém precisa pedir autorização prévia da Suframa para fazer o investimento, em compensação só depois da Suframa analisar o relatório é que ela vai dizer se glosa ou aceita o investimento.
A premissa básica para fazer qualquer investimento em P&D em Manaus, utilizando verbas de P&D de bens de informática geradas localmente, é estar aprovado no CAPDA, e esse processo leva alguns meses.
O Instituto de Pesquisa é uma outra empresa com CNPJ diferente e “sem fins lucrativos” (não é LTDA).
Essas perguntas e respostas que resolvi postar é para ajudar a quem tem dúvidas na hora de implantar ou de saber como manter regulamentado um Instituto legalmente perante o governo. Não é para banalizar e qualquer um sair montando um centro de P&D, pois requer alto investimento, é uma decisão muito séria e comprometimento com a sociedade e com o governo.
Encontrei no blog do Jeff Sutherland e resolvi traduzir pra contribuir com as pessoas que queiram saber mais acerca desse importante checklist.
Em 2005, Bas Vodde (CST) estava fazendo coaching em equipes na Nokia Networks na Finlândia e então desenvolveu o primeiro Teste Nokia focado nas práticas Ágeis. Ele tinha centenas de times e queria uma forma simples de determinar se cada time estava fazendo o básico.
O teste Nokia é parecido com uma verificação rotineira de manutenção do seu carro. Como verificar se seu pneu possui ar, seu tanque tem gasolina, válvulas estão boas, etc. Deve executar antes de “rodar” Scrum com seu time.
Não é o segredo da alta performance, porém é a primeira linha da receita para a alta performance.
Em 2007, Jeff Sutherland otimizou o Teste Nokia para Certificação Scrum e em 2008 desenvolveu um sistema de pontuação para o Teste Nokia. Em 2009 um quesito foi adicionado ao teste Nokia.
Cada pessoa do time pega uma folha de papel e pontua cada questão com nota de 1 a 10.
TESTE NOKIA:
1. Iterações
a) Não há iterações
b) Iterações maiores que 6 semanas
c) Iterações com durações variáveis e menor que 6 semanas
d) Iterações fixas com duração de 6 semanas
e) Iterações fixas com duração de 5 semanas
f) Iterações fixas com duração de 4 semanas ou menos
2. Testando dentro do Sprint
a) Nenhum membro de QA (Garantia da Qualidade) dedicado
b) Unit Tests
c) Features testados
d) Features testados assim que finalizados
e) Software passa sob testes de aceitação
f) Software é entregue
3. Especificação Ágil
a) Não há requisitos
b) Grandes documentos de requisitos
c) User Stories pobres
d) Bons requisitos
e) Boas User Stories
f) Somente o suficiente, especificações na hora necessária
g) Boas user stories amarradas com as especificações à medida que for preciso
4. Product Owner
a) Não tem Product Owner (PO)
b) PO que não entende Scrum
c) PO que atrapalha ou interrompe o time
d) PO não envolvido com o time
e) PO com Product Backlog claro estimado pelo time antes da reunião de Sprint Planning (PRONTO)
f) PO com roadmap de lançamento com datas baseado na velocidade do time
g) PO que motiva o time
5. Product Backlog
a) Não há Product Backlog (PB)
b) Múltiplos Product Backlogs
c) Product Backlog único
d) PB claramente especificado e priorizado por ROI antes do Sprint Planning (PRONTO)
e) Product Owner possui um release burndown com data(s) de lançamento(s) baseada(s) na velocidade
f) Product Owner consegue medir o ROI com base no faturamento real, custo por pontos por estórias ou outras métricas.
6. Estimativas
a) Product Backlog não está estimado
b) Estimativa não foi feita pelo time
c) Estimativa não foi feita com Planning Poker
d) Estimativa feita com Planning Poker pelo time
e) Erro de estimativa menor que 10%
7. Gráfico do Sprint Burndown
a) Não há burndown chart
b) Burndown chart não é atualizado pelo time
c) Burndown chart em horas/dias não considerando trabalho em progresso (burndown de tarefas parciais)
d) Burndown chart somente desce quando a tarefa é concluída (padrão TrackDone)
e) Burndown chart somente desce quando a estória é concluída
f) O time sabe sua velocidade
g) O release plan do Product Owner for baseado em velocidade conhecida.
8. Interrompimento (atrapalhamento, distúrbio) do Time
a) Gerente ou Líder de Projetos interrompe o trabalho do time
b) Product Owner interrompe o trabalho do time
c) Gerentes, Líderes de Projetos ou Líderes Técnicos dizem ao time o que fazer
d) Existe um Líder de Projetos e papéis do Scrum
e) Ninguém interrompe ou atrapalha o time e só existem papéis do Scrum
9. Time
a) Tarefas atribuídas para cada membro durante o Sprint Planning
b) Membros do time não possuem nenhum overlap em suas áreas de especialidade
c) Não há liderança emergente - um ou mias membros da equipe designados como com autorizade direcionada
d) O time não possui a competência necessária
e) O time se compromete coletivamente com o objetivo do sprint e backlog
f) Os membros do time lutam coletivamente contra os impedimentos durante o sprint
g) O time está num estado de hiperprodutividade
Resultado da pontuação:
- Questão 1: a=0, b=1, c=2, d=3, e=4, f=10
- Questão 2: a=0, b=1, c=5, d=7, e=8, f=10
- Questão 3: a=0, b=1, c=4, d=5, e=7, f=8, g=10
- Questão 4: a=0, b=1, c=2, d=2, e=5, f=8, g=10
- Questão 5: a=0, b=1, c=3, d=5, e=7, f=10
- Questão 6: a=0, b=1, c=5, d=8, e=10
- Questão 7: a=0, b=1, c=2, d=4, e=5, f=3, g=2
- Questão 8: a=0, b=1, c=3, d=5, e=10
- Questão 9: a=0, b=0, c=1, d=2, e=7, f=9, g=10
- Ao iniciar o treinamento CSM (Certified Scrum Master) a pontuação gira em torno de 4.0.
- No final das aulas de CSM, as pessoas acreditam que podem aumentar a nota para nota 6.0 ao final de um mês.
Se puder, deixe um feedback de como foi o seu resultado e bom trabalho!
Esse grupo é oficialmente reconhecido pela Scrum Alliance e parabenizo, pois começou muito bem!
O primeiro grupo de Scrum do Brasil, de São Paulo não teve tanta gente no primeiro encontro. Existem oficialmente grupos em São Paulo, Recife e Manaus.
Na abertura o Heitor Roriz informou que 48 pessoas já se inscreveram no grupo.
Para participar do grupo, basta enviar um email para o Grupo Scrum Amazonia (scrum-amazonia@yahoogroups.com).
Houve sorteio de Planning Pokers do INdT, Planning Pokers da FPF e de livros de Scrum.
A próxima edição do encontro Scrum Amazonia acontecerá em Lima no Peru, afinal a Amazônia é maior em área do que a Europa e não podemos esquecer que existe a parte internacional da mesma!
O Marco Mafra do INdT, fez a primeira palestra que mostrava o histórico do Scrum no Instituto, desde o primeiro insight até o nível de maturidade atingido atualmente. Comentou sobre a fase de investigação, treinamento de pessoas, definição de processo de desenvolvimento de projetos utilizando o framework, certificação ISO9001 e mostrou números estatísticos de utilização do Scrum no Instituto. Mais de 50% já aderiu ao framework!
A segunda palestra foi a minha contribuição. Nessa palestra foi mostrado na prática como está funcionando o processo de programa e projeto baseado em Scrum. Também foi explicado resumidamente a relação entre as camadas: de projeto, do framework e registros para certificação ISO9001. Foram mostradas cada uma das cerimônias como ocorrem e enfatizado que o TrueScrum são: pessoas, post-its e cerimônias.
Na terceira palestra o Paolo Ramos da Divus fez uma ótima apresentação mostrando como o Scrum está chegando em empresas do governo. Explicou sobre a necessidade dos gerentes, desenvolvedores trabalharem de forma mais efetiva, planejar melhor e fazer um acompanhamento do backlog para que realmente entregue os projetos em tempo. Foi relatado rapidamente um estudo de caso da AFEAM, porém o importante foi deixar a mensagem do interesse dos órgãos públicos adotarem o Scrum, tais como TRT, Prodam, etc.
Na quarta palestra o Alexandre Cruz da Fundação Paulo Feitoza (FPF) relatou um histórico de como o Scrum começou a ser praticado na Fundação, dificuldades, mudança de mindset até confirmar que eles estão empenhados em obter o sucesso de seus projetos utilizando o referido framework. Estão fazendo um grande projeto de sistema para hospitais do governo municipal e estadual utilizando o Scrum!
Fiquei surpreso positivamente em saber como o Scrum está bem evoluido na FPF, visto que começaram conosco no INdT há aproximadamente um ano atrás.. Sucesso!
Para mais detalhes das palestras visite o site do Scrum Amazônia ou entre no Grupo!
O contrato de sprint é algo novo que estou trabalhando e implementando no momento.
Fiz algumas pesquisas de como implementar um contrato de sprint que na realidade é um contrato com escopo variável.
Conversei com alguns especialistas em contratos como Artem Marchenko e Peter Stevens e redigi melhor essa proposta Ágil é claro. Tudo depende do “mindset” da empresa parceira. Tem que estar apta a rodar o projeto em Scrum… A seguir vou relatar um pouco da experiência com esse tipo de contrato.
Competição de Estimativas:
Em primeiro lugar o Product Owner precisa criar o Product Backlog para a primeira estimativa. Chamamos o candidato o prestador de serviços com seus desenvolvedores e fazemos uma Reunião de Estimativa do backlog. Essa reunião é uma excelente oportunidade para sentir segurança no domínio do assunto por parte dos desenvolvedores. Eles estimarão as user stories de acordo com a visão de complexidade que eles têm sobre o assunto. Você, como contratante, observa as discussões, questionamentos, etc. Depois que terminar essa reunião o PO tem um backlog estimado por uma equipe de desenvolvedores que sabem o que queremos deles e eles sabem o que terão pela frente. Podemos chamar outra empresa e fazer a mesma dinâmica. Teremos o segundo, terceiro, backlog estimados.
Velocidade do Sprint:
Ah, um pequeno detalhe: após a estimativa do backlog, perguntamos ao time quanto eles puxariam para o primeiro sprint (sem ver a pontuação)? Essa resposta será a referência inicial para calcular a velocidade deles.
Depois temos uma estimativa de número de sprints a ser executado. Pontos totais dividido pelo número de pontos puxados para o primeiro sprint.
Exemplo: total estimado do backlog 500 pontos. Estimado para puxar pro primeiro sprint 50 pontos, teremos numa primeira estimativa o trabalho medido para 10 sprints. Vamos supor que desde o início nós calculamos sprints de 10 dias úteis, então esse trabalho será realizado em 100 dias úteis, ou seja, 5 meses (sem muitos cálculos, considerando 1 mês =20 dias úteis).
Custo do Sprint:
Pergunto depois ao responsável da empresa pra me informar quanto custa um Sprint de N dias para um trabalho estimado a ser concluído em 10 sprints?
Ele vai fazer todos os cálculos de overhead, lucro, uso, etc. e vai dizer. Pode até fazer o cálculo da forma tradicional, mas chegará a um número. Exemplo: Sprint custa R$30.000. Faço a seguinte conta: R$30.000 x 10 sprints = R$300.000 será o custo estimado do projeto.
Make or Buy?
Faço os cálculos internamente para decidir se vale a pena fazer o trabalho externamente. Isso depende de uma série de fatores como recursos disponíveis, competências, tempo, carga de trabalho, etc.
Como eu comparo os preços? Tenho um indicador interno de histórico de projetos executados chamado de Man Month Rate (MMR) ou Custo Homem Mês que nada mais é todos os custos exceto investimentos e subcontratados dividido pelo número de efetivos e dividido pelo número de meses.
Exemplo: meu último projeto teve um custo operacional de R$1.000.000 realizado por 10 pessoas em 10 meses. Cálculo: R$1.000.000 / 10 pessoas / 10 meses = R$10.000 é o valor do meu MMR.
Agora, com posse desse dado, sabendo que minha equipe tem condições técnicas de realizar o projeto faço o seguinte cálculo: lembra dos 5 meses calculados anteriormente? Então agora internamente calculo R$10.000 * 10 pessoas * 5meses = R$500.000 o valor estimado pra fazer internamente. Quanto o fornecedor me cobrou? R$300.000. Esse valor está bom, é mais barato fazer fora (Buy).
Estabilização da Execução:
Agora após decidir quem executará o projeto, vamos pra a execução do contrato.
Será estimado inicialmente para finalizar daqui a 5 meses (com base em 10 sprints), pode acabar antes do tempo ou esticar um pouco mais, porém isso é o que tenho no momento.
Sprint1 e Sprint2 serão pagos ao fornecedor sem aplicar penalidades ou bônus. Valores fixos. Para fins de entrosamento, medir velocidade, resolver questões de infra, etc.
Penalidade Insucesso:
A partir do terceiro sprint, começo a aplicar as regras de bônus ou penalidade. No Sprint Planning o PO determina o objetivo esperado do sprint. No Sprint Review, ele confirma de esse objetivo (meta) foi atingido. Caso não tenha sido atingido, o pagamento desse sprint será debitado de um percentual penalidade, pagando apenas os custos do mesmo. Exemplo: penalidade de 20%, custo do sprint R$30.000, pagarei R$24.000 (R$30.000 – R$6.000)
Penalidade/Bônus Progresso:
Caso o objetivo do sprint tenha sido atingido, ainda falta mais uma coisa antes de definir o pagamento do sprint. Qual o percentual de entrega em pontos?
Estabeleci algumas métricas internas para pontuação (delivery). Por exemplo, abaixo de 80% de entregas aplica-se uma penalidade de 10%. Acima de 100% de entrega, aplica-se uma bonificação de 10%. Entre 80% e 100% dos pontos, paga-se o valor cobrado pelo sprint.
Em números: vamos supor que no sprint planning o time puxou 100 pontos e entregou 79 pontos (com objetivo atingido). Nesse caso receberão R$30.000 – R$3.000 = R$27.000.
Caso eles tenham feito entre 80 e 100 pontos, receberão os R$30.000 que cobraram.
Caso tenham feito 101 pontos ou 200 ou mais pontos, receberão R$30.000 + R$3.000 = R$33.000.
Cancelamento Fracasso:
Quando rodamos a partir de terceiro sprint, podemos avaliar o atingimento das metas. Caso sucessivos sprints não atinjam as metas, tem algo errado que deve ser revisto. Ou performance da equipe, gerenciamento do backlog, impedimentos, etc. Pode-se decidir então cancelar o projeto antes que o prejuízo aumente por fracasso.
Cancelamento Sucesso:
O projeto também pode ser cancelado por motivo de sucesso.
Caso no meio do projeto, lá pelo sprint 5, o ROI tenha sido atingido, ou seja, o cliente já está satisfeito com o que tem no momento, pode-se negociar com o fornecedor-parceiro o término adiantado com sucesso mediante uma bonificação sobre os sprints faltantes. Exemplo: faltam 5 sprints de R$30.000 cada, paga-se 20% sobre os 5 sprints que equivale a R$6.000 x 5 = R$30.000 de bônus por cancelamento com sucesso.
Pode ocorrer do fornecedor-parceiro não querer finalizar e receber tal bônus por não ter como alocar as pessoas em outro projeto, nesse caso podemos continuar executando o projeto, que tem escopo dinâmico (product backlog), na base do money for nothing and change for free. Sendo que a partir desse ponto de execução as funcionalidades não agregam mais tanto valor ao produto.
Os percentuais e valores colocados aqui são meramente para exemplificar a dinâmica desse modelo de contrato. Cada empresa pode adotar os percentuais adequados à sua operação, algumas mais conservadoras e outras mais arrojadas.
Espero ter contribuído com essa modalidade de contrato que estou confiante que trará bons resultados pra ambos. É verdadeiramente uma relação ganha-ganha.
O MS Project é uma ferramenta comercial como muitas outras existentes, considerado importante para ter a visão e controle de atividades, custo, prazo, estrutura do projeto, etc.
As pessoas que utilizam tais ferramentas têm o costume, pelo fato de trabalhar com a abordagem tradicional ou cascata, de escrever em níveis de detalhes as atividades, durações e recursos envolvidos.
Afinal, na abordagem tradicional, o WBS significa Estrutura Detalhada de Trabalho. Nesse modelo, o Gerente de Projetos precisa advinhar tudo para que o projeto ocorra no tempo planejado.
Quando trabalhamos com Scrum, normalmente após a definição e estimativa do primeiro backlog (na semana 0), podemos ter uma estimativa de tempo restante supondo que a velocidade puxada para o primeiro sprint seja constante. Mas nada impede que coloquemos isso em um cronograma.Por que não?
Alguns projetos são programados para seis meses ou um ano.
Em nenhuma das abordagens (tradicional ou ágil) sabemos exatamente o que acontecerá no final.
Usando o Scrum, o Product Owner pode saber periodicamente como está o índice de acertos X erros, visto que não esperamos até o final do período pra entregar tudo e sim vamos entregando parcialmente.
Para um projeto de seis meses fixos (orçamento alocado), dependendo das durações dos sprints podemos saber o máximo número de sprints para o período. Pode acontecer de o projeto acabar antes desse número máximo de Sprints ou algumas funcionalidades do backlog serem replanejadas ou até eliminadas. Mas é importante ter uma visão cronológica em casos de várias equipes independentes trabalhando no mesmo projeto ou em projetos de um programa.
Observe que na figura acima, ao usar o cronograma, temos na fase de planejamento o Sprint0 e na fase de implementação o Sprint1..SprintN. Não controlamos tarefa, pois o WBS no scrum é o Sprint Backlog. Controlamos apenas os timeboxes e releases. Portanto uma ferramenta como o MS Project é útil sim na abordagem Scrum e não tem nada a ver com mistura de tradicional com ágil.
Você controla de que forma os períodos e releases de seu projeto baseado em Scrum?
Na empresa em que trabalho tivemos uma linha de tempo desde a investigação sobre o framework Scrum, treinamentos até a adoção do mesmo como framework oficial de desenvolvimento.
Quando falamos de organização, não bastar rodar o Scrum e ter o Scrumboard com seus post-its, precisamos formalizar alguns registros para que possamos evidenciar o Planejamento, Execução, Controle e Ação (PDCA).
Decidimos que esses registros seriam gerados pelo Scrum Master e deixar a equipe multifuncional se preocupar apenas com o trabalho de fazer produtos.
Muita gente confunde “framework” com metodologia ou processo. É bom esclarecer que o Scrum é um framework, ou seja, estrutura/forma de trabalhar. Porém o Scrum foi o framework que trabalhei em todos os meus anos de experiência com projetos, que realmente consegue resultado em pouco tempo.
Sobre esse framework identificamos uma camada acima: Desenvolvimento de Projetos. Poderia considerar 3 camadas: Desenvolvimento de Produtos, Desenvolvimento de Projetos e Gerenciamento de Projetos antes de chegar na camada ISO que é uma abrangência maior da organização.
Na camada Desenvolvimento de Produtos nos preocupamos com o framework em si. Pode ser Scrum, Cascata ou qualquer um que se queira usar.
Na camada Desenvolvimento de Projetos nos preocupamos com os entregáveis das fases Conceito, Planejamento, Implementação e Transferência.
Na camada Gerenciamento de Projetos nos preocupamos com as evidências das tomadas de decisões, reuniões de aprovação de “milestones” (marcos) e decisões de “go-no-go“.
Na figura abaixo a representação hierárquica sobre a ISO, projetos e Framework.
Podemos observar que a ISO está num nível abrangente na organização, pois é necessário que se descreva os Processos Administrativos, de Tecnologia da Informação e de Projetos ou outros mais. Esses processos são descritos através de Procedimentos.
Quando chegamos na área de projetos nos deparamos com situações onde os gerentes aplicam os frameworks específicos de acordo com os tipos de projetos ou departamentos. Não é recomendado criar um Procedimento único que abranja tudo, pois será muito difícil conciliar os registros de processo do modelo cascata com o modelo ágil ou outro modelo. Nessa etapa a sugestão é que o Procedimento de Projetos referencie a Instruções de Trabalho (IT) para a abordagem do framework utilizado. Exemplo: IT Scrum, IT Cascata, IT outro.
Na IT de Scrum podemos gerar como registros de processo alguns artefatos: Product Backlog, Sprint Planning1, Sprint Planning2, Sprint Review, Sprint Retrospective. Nessa camada os principais atores são o Scrum Master e Product Owner.
Na camada de projetos, os registros de projetos independem de scrum ou cascata. São eles: Charter do Projeto, Plano de Projeto, Relatório de Conclusão da Execução, Relatório de Transferência ou outros relatórios existentes. Nessa camada o principal ator é o Gerente de Projetos ou o Project Owner (uma espécie de Scrum Master dos Scrum Masters)
Na camada de decisões, os registros são reuniões de aprovações de milestones, documentos de aprovações em sistemas internos, emails, etc. Nessa camada gerentes de diretores são os principais atores.
Assim fica prático e totalmente exequível a implantação desse modelo normatizado: ISO9001 Ágil.
Caso você ache que vale a pena implementar dessa forma, ao finalizar a implantação deixe seu depoimento para que outros possam compartilhar de tal caso de sucesso, ok?
Search
Archives
Recent Comments
Categories
Syndication
Recent Posts
Carlos
Para não esquecer/perder meu acervo de assuntos, tenho o costume de publicar para compartilhar e exercitar minha mente.
Carlos' micro Blog
-
- http://twitpic.com/qat7j - Ele disse que eh mais facil voar um aviao de controle remoto da Toys R Us :-) agora foi o morcegao das praias do
- http://twitpic.com/qargx - Ah se Manaus tivesse a brisa de Recife...
- @vivoemrede nao funciona linha corporativa do INdT desde ontem a noite! Estou usando um TIM prepago que pro ironia do destino ta melhor. #fb
- Soltando pipa do RJ no CSU com filho :-) #fb
- RT @Samsungtweets: AT&T and Samsung Unveil Go Netbook: http://tinyurl.com/yhrmjh5 #fb
Powered by Blog.com
