Quando que vai ficar pronto?

Vários dados coloridos, mostrando diferentes valores. Por exemplo: 6, 3, 4, 5

Vamos ser sinceros… ̶q̶u̶a̶s̶e̶ ninguém gosta de responder essa pergunta. Ainda mais em pleno 2020 no mundo de incertezas do knowledge work, ou seja, no mundo do trabalho invisível de quem senta atrás de um computador.

Embora essa pergunta seja um pouco chata, convenhamos que ela é inevitável!

Resolví escrever esse artigo pois já tive que responder essa pergunta centenas de vezes e, obviamente, errei centenas de vezes. Pior que isso: entre 2009–2012 eu e os times que trabalhei passávamos uma quantidade absurda de horas ̶c̶h̶u̶t̶a̶n̶d̶o̶ criando estimativas, o que do ponto de vista Lean é um baita desperdício.

Nós erramos porque, quando passamos uma estimativa, na verdade estamos fazendo forecast mental, o que é humanamente impossível.

Vejam a definição de forecast:

Uma tentativa de utilizar um modelo de predição que determina a manifestação de eventos futuros

O exemplo mais conhecido sobre esse tema é previsão do tempo! Se alguém te perguntasse qual a previsão do tempo para os próximos 15 dias, o que você responderia?

Apresentadora Maju Coutinho falando sobre a previsão do tempo no Jornal Nacional da Rede Globo

Não dá para responder sem consultar a previsão em algum lugar, correto? No nosso trabalho deveria ser a mesma coisa, mas infelizmente muitas pessoas ainda tem que tirar esses números da caixola e pior: eles ficam escritos na pedra, o que pode gerar uma enorme quantidade de disfunções (que não são o foco deste artigo). Leiam abaixo o que o Troy Magennis, um dos maiores especialistas em forecast da atualidade, disse sobre o assunto (tradução livre):

“Um pequeno aumento na temperatura do oceano muda a probabilidade de chuva numa certa área. É um sistema complexo! Nós nunca esperamos perfeição sobre previsão do tempo mas, por alguma razão, esperamos uma previsibilidade absoluta para projetos de tecnologia, cuja complexidade é parecida”
— Troy Magennis

Trazendo para o nosso mundo, é difícil mapear todos os fatores de variabilidade num projeto. Assim como um aumento de temperatura do oceano altera a probabilidade de chuva, um workflow incompleto, uma dependência ou demanda urgente não mapeada, pessoas doentes ou de férias, etc; também irão alterar a data originalmente estimada para a finalização de um projeto.

Então concordamos que é difícil. Mas se o pessoal que trabalha com previsão do tempo consegue, nós temos o dever de conseguir também! O objetivo deste artigo é te ajudar a responder a pergunta ‘quando que vai ficar pronto?’ de forma pragmática e objetiva, com base em dados e não na intuição.

Para tentar explicar forecast, vou usar laranjas — para homenagear a querida cidade de Limeira, que no passado acordava seus moradores com aquele característico cheirinho cítrico todas as manhãs — .

Imagine que eu seja o dono de uma fábrica de suco de laranjas — A Xico Sucos — e recebí uma oferta para comprar 1000 sacos (cada saco contém 22 laranjas) por R$1000,00. Se você estivesse no meu lugar, o que faria?

Primeiramente, é necessário definir quais perguntas gostaria de responder. Para fins didáticos, vamos considerar apenas 2 perguntas e as seguintes premissas:

Perguntas: 1)Essa oferta vale a pena? 2)Quantas garrafas preciso comprar? Premissas: 1)Tenho lucro de R$1,00/litro que vender 2)Utilizo somente garrafas de 1 litro 3)Consigo vender tudo que produzir 4) 1 grama de suco = 1 ml de suco

Então vamos lá..

1) Essa oferta vale a pena?

O primeiro passo é definir o modelo. Nesse caso é:

litros = (o * j)/1000

No qual o = quantidade de laranjas e j = quantidade de suco em ml/laranja

Após a definição do modelo, precisamos analisar os dados. Aleatoriamente, vou escolher 19 laranjas das 22000 disponíveis e espremer. Segue o resultado #tudopelaciência

As amostras sempre devem ser escolhidas aleatoriamente. E nunca pela intuição ou conveniência.

19 imagens de copos com suco de laranja em uma balança. Cada balança mostra a quantidade de suco extraído para cada respectiva laranja.

Para ficar mais legível, segue a tabela:

Na esquerda há os valores: 1-66 ml, 2–85 ml, 3–76 ml, 4–72 ml, 5–109 ml, 6–63 ml, 7–77 ml, 8–79 ml, 9–84 ml, 10–91 ml, 11–102 ml, 12–90 ml, 13–121 ml, 14–84 ml, 15- 70 ml, 16–91 ml, 17–50 ml, 18–103 ml, 19–88 ml. Na direita há 2 laranjas inteiras e 1 cortada na metade.

Você deve estar pensando: por quê 19 laranjas? Para responder essa pergunta precisamos entender um pouco sobre inferência estatística, mais especificamente sobre intervalos de confiança.

Se eu tivesse escolhido apenas 2 laranjas, ocorreria esse cenário:

Seta azul com 2 laranjas. À esquerda da primeira laranja, entre as duas laranjas e à direita da segunda laranja aparece o mesmo valor: 33%

Ou seja, a probabilidade de que a quantidade de suco extraído pela próxima laranja (escolhida aleatoriamente) esteja entre as duas já selecionadas é de aproximadamente 33%. Quando escolhemos 19, temos esse cenário:

Seta azul com 19 laranjas. À esquerda da primeira laranja, entre todas laranjas e à direita da última laranja aparece o mesmo valor: 5%

Ou seja, a probabilidade de que a quantidade de suco extraído pela próxima laranja (escolhida aleatoriamente) esteja entre as 19 já selecionadas é de 90%, o que é uma bela de uma confiança para se trabalhar! Matematicamente, isso pode ser representado pela seguinte fórmula:

p = 1-(2/n+1)

Cuja representação num gráfico fica assim:

Gráfico com fundo branco e uma seta azul, cujos valores são preenchidos conforme fórmula acima. O eixo x representa a quantidade de amostras, enquanto o eixo y representa a probabilidade.

Com isso, ao contrário do que muitas pessoas acreditam, podemos concluir que não é necessário um grande número de amostras para gerar um forecast confiável. O grande desafio é decidir quais dados devemos usar e quais devemos ignorar. Normalmente métricas como, por exemplo, throughput, lead time e cycle time, estão sempre variando no contexto do knowledge work e às vezes um histórico muito grande pode atrapalhar o seu forecast. A recomendação atual do mestre Troy Magennis é a seguinte:

* não vou traduzir para não ocorrer nenhum risco de eu passar a informação de forma diferente :)

< 3 samples: GUESS the range, go wide. Not enough data to do anything;

< 7 samples: narrow your GUESSED range using data. Make the lower and higher bounds of your guessed range wider if necessary;

>= 7: use these samples and take the lower and higher bounds or resample like I do when forecasting;

> 15 samples, delete the oldest and use the newest.

Mas em resumo é:

• < 3 amostras: CHUTE!
• < 7 amostras: refine o seu CHUTE!
• >= 7 amostras: utilize os dados;
• > 15: Jogue o resto fora.

Voltando à pergunta… Essa oferta vale a pena?

Para respondê-la, precisamos olhar para a tabela de resultados e fechar os valores mínimo e máximo prováveis no intervalo de confiança, ou seja, identificar qual laranja produziu menos e qual produziu mais suco:

Na esquerda há os valores: 1–66 ml, 2–85 ml, 3–76 ml, 4–72 ml, 5–109 ml, 6–63 ml, 7–77 ml, 8–79 ml, 9–84 ml, 10–91 ml, 11–102 ml, 12–90 ml, 13–121 ml, 14–84 ml, 15- 70 ml, 16–91 ml, 17–50 ml, 18–103 ml, 19–88 ml. Na direita há 2 laranjas inteiras e 1 cortada na metade. A laranja 13 está destacada em amarelo com uma carinha feliz, enquanto a laranja 17 está destacada em vermelho com uma carinha triste

A laranja 13 produziu a incrível quantidade de 121ml de suco enquanto a laranja 17 produziu míseros 50 ml. Considerando o modelo litros = (o * j)/1000, teremos no pior e melhor cenário respectivamente:

mínimo = (22000 x 50 /1000) = 1100 litros

máximo = (22000 x 121 /1000) = 2662 litros

Portanto, considerando as premissas, a resposta para a primeira pergunta é SIM, vou aceitar a oferta! Pois no pior caso teria um lucro de R$100,00.

Então vamos para a segunda pergunta…

2) Quantas garrafas preciso comprar?

Se eu comprar mais que o necessário, vou gastar em garrafas que não irei utilizar -> perco dinheiro!

Se eu comprar menos que o necessário, não terei onde armazenar o suco excedente -> perco dinheiro!

Até agora descobrí somente os resultados mais improváveis: mínimo e máximo. Imagine que você está num cassino e apareceu a chance de ganhar R$10.000,00 num jogo de dados, no qual o dealer irá jogar 2 dados na mesa e você tem que acertar a soma. Qual resultado você apostaria?

Nesse caso, como temos apenas 2 dados e cada dado possui 6 faces, o número de possibilidades é 6*6 = 36 :

Todas as 36 jogadas possíveis com 2 dados, com suas respectivas probabilidades. Cada resultado com sua probabilidade: 2 (1/36), 3 (2/36), 4 (3/36), 5 (4/36), 6 (5/36), 7 (6/36), 8 (5/36), 9 (4/36), 10 (3/36), 11 (2/36) e 12(1/36)

Olhando para a distribuição acima, dificilmente você apostaria no valor mínimo (2) ou no máximo (12), certo? Pois esses são os resultados mais improváveis (2,7%).

Se eu tivesse que apostar, certamente apostaria no valor 7, que é o mais provável (16,6%). Portanto, para decidir qual número apostar no jogo de dado ou para responder a pergunta “quantas garrafas preciso comprar?” é necessário descobrir quais os resultados mais prováveis dentro do intervalo de confiança estabelecido.

No nosso exemplo, como temos 22000 laranjas e 19 amostras, seria o equivalente a ter 22000 dados de 19 faces. Complicou, né?

Nem tanto! Obviamente não dá para fazer esse cálculo manualmente, mas existe uma técnica fantástica para resolver esse tipo de problema: o Método Monte Carlo, cujo conceito principal é utilizar a aleatoriedade para resolver problemas que parecem não ter solução.

Esse método foi inventado na década de 1940 por um cientista polonês chamado Stanislaw Ulam e é utilizado desde então em diversas áreas como, por exemplo, mercado financeiro, biologia, física nuclear, entre muitas outras. Por algum motivo, essa técnica demorou para ganhar tração nas empresas de tecnologia, porém seu uso na última década só cresceu e acredito que chegou para ficar. Vejam esse trecho do excelente livro Actionable Agile Metrics for Predictability, escrito por Dan Vacanti, uma das principais referências em métricas do mundo:

“Eu acredito fortemente que o método Monte Carlo é o futuro do forecasting no knowledge work. Times e empresas que entenderem essa idéia irão sobreviver. Os demais não.”

— Dan Vacanti

Se o Dan Vacanti falou, devemos no mínimo respeitar!

Então vamos utilizar Monte Carlo para responder a pergunta “quantas garrafas preciso comprar?”. Para isso vamos considerar os 19 resultados coletados, rodar milhares de simulações para garantir uma boa distribuição dos valores e criar um tabelão, no qual:

• Cada linha é uma laranja;
• Cada valor é um número aleatório baseado nos 19 resultados já coletados; e
• Somamos todos os resultados de cada coluna para identificar o total em litros que seriam produzidos em cada simulação;

No topo da imagem: os 19 resultados coletados em ml. No corpo há uma tabela com 3 colunas, as quais representam 3 das 10 mil simulações com alguns exemplos aleatórios e cada linha representa uma laranja. Por exemplo: Linha 1: 72 ml, 91 ml, 76 ml. A última linha representa a soma de cada coluna em litros. Por exemplo: 1847 litros, 1851 litros e 1850 litros

Particularmente, a linguagem que eu mais gosto de utilizar para fazer esse tipo de cálculo é a linguagem R. Para montar esse tabelão, precisamos de poucas linhas de código:

https://github.com/felipebassan/monte-carlo/blob/master/oranje_juice_bottles.r

Obs: para completar 10 mil simulações, esse programa leva aproximadamente 1 hora num computador pessoal. Segue o resultado:

Histograma da soma total em litros. O histograma é na forma de sino. Valores em litros que aparecem no eixo x: 1845, 1850, 1855, 1860. Frequências que aparecem no eixo y: 0, 500, 1000, 1500

Olhando mais detalhadamente o resultado, podemos observar:

• mínimo = 1844 litros;
• média e mediana = 1854 litros; e
• máximo: 1863 litros;

Com esses dados podemos concluir que, com 90% de confiança, não vou necessitar mais que 1863 garrafas. Portanto, para garantir, irei fazer uma compra de 1870 garrafas. Done!

Para quem tiver curiosidade e quiser saber mais sobre o método Monte Carlo, só clicar aqui.

Obs: Por coincidência, esse valor ficou próximo da média entre o mínimo e máximo. Mas foi apenas isso: coincidência. Na maioria dos casos a média é uma métrica totalmente distorcida que não gera nenhum aprendizado. Se quiser saber mais sobre o assunto, há um livro completo sobre o tema: The Flaw of Averages.

Agora imagine que surgiu uma terceira pergunta…

3) Quantas laranjas preciso espremer para produzir 13 litros?

Sendo que, neste caso, não é possível espremer todas as 19 laranjas de antemão. Alguma idéia de como responder?

Assim como a pergunta 2, essa também é complexa. Portanto iremos utilizar o Método Monte Carlo novamente, porém com um algoritmo diferente.

Para simplificar, vou recorrer aos dados mais uma vez para a explicação. Uma pergunta similar seria: “Quantas vezes preciso jogar um dado para que a soma das jogadas seja maior que 10?”.

Com 4 simulações, poderíamos ter, por exemplo, esse cenário:

tabela com 4 linhas e cada colunas. Cada linha é uma simulação e cada coluna é uma rolagem de dados. Por exemplo, resultados da primeira linha: 4,5,3,2

A mudança no algoritmo consiste no fato de que agora preciso ir somando os resultados acumulativamente e calcular quais somas trouxeram um resultado maior igual ao esperado. Ou seja:

Mesma tabela, porém cada coluna agora é a soma das colunas anteriores. Coluna 1 = Rolagem 1, Coluna 2 = Rolagem 1 + 2 e assim por diante. As somas maiores igual a 10 estão destacadas com um círculo amarelo. Na última linha aparece a porcentagem das somas que são maiores igual a 10. Coluna 1: 0%, Coluna 2: 1/4, Coluna 3: 2/4, Coluna 4: 3/4

Com base nesse resultado, poderíamos dar a seguinte resposta:

• Com confiança de 75%, preciso jogar o dado 4 vezes para que a soma das jogadas seja maior ou igual a 10.

Obs: obviamente esse resultado não é real pois fizemos apenas 4 simulações em vez de milhares. Essa explicação foi apenas para fins didáticos.

Voltando para as laranjas, imagine que eu pudesse espremer apenas as primeiras 5 laranjas escolhidas aleatoriamente, das quais foram extraídas as respectivas quantidades de suco: 66 ml, 85 ml, 76 ml, 72 ml e 109 ml.

Para responder a pergunta “Quantas laranjas preciso espremer para produzir 13 litros?” podemos utilizar o algoritmo:

• Criar n simulações aleatórias com os resultados já coletados;
• Somar a simulação atual com a soma das simulações anteriores;
• Verificar se a soma atual é maior ou igual a 13 litros; e
• Verificar qual a porcentagem dos valores foi maior ou igual a 13 litros de acordo com o tamanho da amostragem.

Ou seja, um tabelão mais ou menos assim:

Tabela com colunas que representam N simulações. Na última linha a porcentagem cujo resultado foi maior ou igual a 13 litros. Na imagem todas as colunas aparecem como 0%

Mais uma vez irei utilizar a linguagem R para criar o tabelão. Porém, dessa vez com 100 mil simulações:

https://github.com/felipebassan/monte-carlo/blob/master/orange_juice_squeezes.r

O que nos dá o resultado:

Porcentagem do resultado ser maior que 13 litros representada no eixo y e a quantidade de laranjas representada no eixo x. O gráfico é uma linha reta em 0% até passar das 150 laranjas. Após esse ponto ocorre uma subida aguda.

Para melhor visualização, segue o resultado numa tabela:

Tabela com 2 linhas. Primeira linha: quantidade de laranjas. Segunda linha: porcentagem. Resultado: 155 (3%), 156 (7%), 157 (16%), 158 (28%), 159 (44%), 160 (61%), 161 (76%), 162(87%)

Portanto, com esse dados, poderíamos responder:

• Para produzir 13 litros, com confiança de 87%, preciso espremer 162 laranjas

Esse ainda é um forecast relativamente básico pois só temos 5 amostras. Cada nova laranja espremida aumenta a qualidade do forecast. Se pudermos contar com as 19 amostras, teríamos um forecast bem mais confiável. Ficaria assim:

Tabela com 2 linhas. Primeira linha: quantidade de laranjas. Segunda linha: porcentagem. Resultado: 150 (4%), 151 (9%), 152 (17%), 153 (30%), 154 (45%), 155 (61%), 156 (76%), 157(87%)

Ou seja, poderíamos responder:

• Para produzir 13 litros, com confiança de 87%, preciso espremer 157 laranjas

Done!

Se você chegou aqui deve estar pensando… ok, legal! Mas e no meu trabalho?

Tente trocar a pergunta “Quantas laranjas preciso espremer para produzir 13 litros?” por, por exemplo,“Quantas semanas faltam para terminar essas 13 histórias?”.

Imagine o seguinte cenário: O(a) CEO da empresa que você trabalha fez uma apresentação para todos os empregados, na qual foram passados os objetivos macros do ano. Para tentar garantir a entrega do projeto principal, a diretoria resolveu montar um Squad com mais de 20 pessoas e decidiram deixar você como gerente do projeto.

Para dar o pontapé inicial, você chamou uma reunião de 4 horas, no qual foi feito o fatiamento. Resultado:

• 1 Épico com 173 Histórias.

Após uma semana de trabalho, esses dados foram coletados:

Tabela com 5 colunas (cada dia da semana é uma coluna) e com 2 linhas. Na primeira linha aparece a quantidade itens em backlog ou iniciados e na segunda linha aparece a quantidade de itens finalizados

Ou seja:

• Dia 1: nenhuma história foi entregue;
• Dia 2: nenhuma história foi entregue;
• Dia 3: o Squad entregou 2 histórias;
• Dia 4: o Squad entregou 1 história; e
• Dia 5: nenhuma história foi entregue e 5 novas histórias entraram no backlog;

Eis então que a diretoria te chamou numa sala (aquela que você nem sabia que existia, que fica na cobertura do edifício) e o CEO te perguntou “Quando que esse projeto fica pronto?”.

Uma resposta sincera seria:

“No momento é impossível te passar uma data confiável, mas me comprometo que iremos medir a performance do Squad e te passo a primeira previsão em 4 semanas”

No desespero, você pode chutar um número. Entretanto, como é um time novo, não é possível confiar nos dados históricos e, obviamente, não compensa perder tempo tentando fazer um forecast. Portanto, é melhor esperar um pouco.

Entretanto, mesmo que ainda não seja possível realizar um forecast, já podemos tomar uma decisão importante: decidir qual medida de tempo utilizar para o throughput (vazão do sistema).

Throughput = quantas unidades de trabalho são entregues num período específico de tempo.

Como na maior parte dos dias não houve entregas, a métrica histórias/dia não é a mais indicada. Portanto, iremos utilizar histórias/semana.

Agora imagine que se passaram 5 semanas de projetos (enfim chegou a reunião com o CEO) e temos o seguinte cenário, no qual, Graças a Deus, o backlog não aumentou após a primeira semana:

Tabela com 5 colunas (cada semana é uma coluna) e com 2 linhas. Na primeira linha aparece a quantidade itens em backlog ou iniciados e na segunda linha aparece a quantidade de itens finalizados por semana. Na linha 1 aparece a mesma informação em todas as colunas: 178. Na linha 2 aparece respectivamente: 3,2,7,4,1

Uma forma mais legal de ver esses dados é num gráfico cumulativo burn-up:

Eixo y representa a quantidade de histórias. Eixo x representa as semanas do projeto. Numa seta verde cumulativa estão as informações de throughput da segunda linha: 3,2,7,4,1. O total de histórias (178) está representado numa linha preta. À partir da semana 5, são projetadas 3 setas tracejadas nas cores: vermelhoo, amarelo e verde

Se você pensou que essas linhas tracejadas representam o nosso forecast, pensou certo!

Para responder “Quando que esse projeto fica pronto?”, vamos rodar exatamento o mesmo algoritmo das laranjas (pergunta 3), porém substituindo as variáveis pela quantidade total de histórias e throughput.

Ou seja, vamos rodar 100 mil simulações e observar quanto tempo leva para que a soma das entregas seja maior que a quantidade total de histórias do projeto:

https://github.com/felipebassan/monte-carlo/blob/master/project_epic_stories.r

Segue o resultado:

Tabela com 2 linhas. Na linha 1 aparece a quantidade de semanas e na linha 2 a probabilidade. Resultado em vermelho: 52 (45%), 53 (54%). Resultado em amarelo: 54 (62%), 55 (71%), 56 (78%), 57 (84%). Resultado em verde: 58 (88%), 59 (92%), 60 (95%)

Portanto, um exemplo de resposta para o CEO seria:

“No cenário atual, se dermos muita sorte, o tempo total de duração desse projeto será de 52 semanas. Talvez leve 55 semanas, mas provavelmente levará 59.”

Para justificar a resposta, você mostra o seguinte gráfico:

Gráfico que mostra as probabilidades. 52 semanas - 45% (vermelho), 55 semanas — 71% (amarelo) e 59 semanas — 92% (verde)

Para o CEO, 59 semanas é um tempo inaceitável! Ele pede um gás total nesse projeto e uma nova previsão daqui 3 semanas.

O tempo passa e você coleta os seguintes dados:

• Semana 6 = 5 histórias entregues;
• Semana 7= 4 histórias entregues; e
• Semana 8= 7 histórias entregues;

É hora de rodar uma simulação Monte Carlo novamente! Resultado:

Tabela com 2 linhas. Na linha 1 aparece a quantidade de semanas e na linha 2 a probabilidade. Resultado em vermelho: 42 (34%), 43 (46%). Resultado em amarelo: 44 (58%), 45 (70%), 46 (79%). Resultado em verde: 47 (86%), 48 (92%)

Isso mostra claramente que o time melhorou a performance pois o tempo estimado com confiança de 92% caiu de 59 para 48 semanas. Portanto, você pode mostrar um novo gráfico:

Gráfico que mostra as probabilidades. 43 semanas — 46% (vermelho), 45 semanas — 70% (amarelo) e 48 semanas — 92% (verde)

Uma nova resposta seria:

“Boas nóticias! O backlog não cresceu e a performance do Squad melhorou. Muito provavelmente esse projeto será entregue na primeira semana de agosto e não mais na terceira semana de outubro, conforme previsão inicial.*

*Assumindo que a primeira semana de agosto corresponde à semana 48 do seu forecast.

Para finalizar…

Um bom forecast é um processo contínuo e nunca uma data escrita na pedra! Ele serve como um guia para a melhoria contínua, pois te avisa se as decisões tomadas estão surtindo o efeito esperado.

Para projetos com menor complexidade e com equipes já têm uma análise da demanda consolidada, normalmente não é necessário rodar o método Monte Carlo. Provavelmente você terá resultados satisfatórios de previsibilidade apenas ao analisar as distribuições de lead time dos itens de trabalho.

Lead Time = quanto tempo um item leva desde sua priorização até ser entregue.

Como última dica, não se preocupe com tamanho das atividades (por exemplo: P, M, G) pois as filas (tempo que uma atividade fica parada) normalmente são a grande causa de atrasos e de erros de previsibilidade nas entregas.

Foque em categorizar os itens de trabalho (por exemplo: Story, Task, Service Request, Incident, etc), analise as distribuições de lead time e agrupe por similaridade das curvas de probabilidade. Se for muito diferente, considere fazer uma recategorização ou crie filtros.

O lead time também é uma ótima métrica nos ajudar a decidir quando devemos começar a trabalhar em uma demanda. Isso é imprescindível para o sucesso do produto/projeto!

Mas esses assuntos ficam para um próximo artigo. Por enquanto, recomendo esse, que é excelente.

Espero que esse artigo tenha sido útil para você e até a próxima!

Fontes

Esse artigo foi inspirado pelo livro Practical Kanban, de Klaus Leopold;

Outras fontes:

• Material do Troy Magennis;
• Actionable Agile Metrics for Predictability: An Introduction, Dan Vacanti.