Menu
Esqueceu a senha? Fazer cadastro

A Importância das novas métricas “Drag” e o “Custo Drag” na Análise do Caminho Crítico


Nesta postagem, convido ao leitor a conhecer um pouco do trabalho de Stephen Devaux, criador do cálculo do Drag (Arrasto) no Caminho Crítico de um Projeto.
Embora o método tenha algumas décadas e com aplicações importantes em diversos projetos e trabalhos, ele não é ainda muito conhecido e há uma oportunidade de melhorias significativas em resultados de projeto que podem ser obtidos com o seu entendimento.
Ao ler este conteúdo pela primeira vez, achei que se tratava de um cálculo complexo e não pude compreender todos os seus benefícios, mas depois tive a oportunidade de verificar que:
A) Não é tão complexo de ser calculado quando entendemos o princípio de sua aplicação.
B) Uma vez que compreendemos sua aplicação, entendemos que vale o esforço de cálculo;
C) Hoje alguns softwares já realizam este cálculo de forma automática, bastando portanto que entendamos sua aplicação.
Em listas de discussão, as sugestões para o termo “Drag” foram de “Retardo” ou “Arrasto”, ficando a segunda palavra como a definição interpretada como mais adequada para o termo, até mesmo pois outras formas de aplicarmos a palavra “Drag”, como “Drag Equation” já vêm sendo traduzidas como “Arrasto” em outros contextos (Equação de Arrasto, Coeficiente de Arrasto, entre outros).
O texto a seguir está em sua tradução livre em Preto e o original – encaminhado pelo próprio sr. Devaux para sua divulgação – está em Vermelho.

The Importance of the New Metrics Drag and Drag Cost in Critical Path Analysis

by

Stephen A. Devaux, MSPM, PMP

(Tradução livre, por Peter Mello, PMP, PMI-SP, SpS)

Qual é a diferença entre a aplicação do Método do Caminho Crítico e Análise pelo Caminho Crítico (CPM)?

What is the difference between critical path method (CPM) scheduling and critical path analysis?

A aplicação do Método do Caminho Crítico é o processo de se desenvolver um cronograma com as atividades para o trabalho de um projeto tendo como base a sequência lógica entre estas atividades e suas durações. A sequência mais longa entre tais atividades e restrições irá determinar o caminho mais longo do projeto e este é então chamado de caminho crítico.

CPM scheduling is the process of developing a schedule of the activities of the project’s work on the basis of the logical sequence of those activities and their durations. The longest sequence of such activities and constraints determines the length of the project and is called the critical path.

Frequentemente, o cronograma desenvolvido com o método se torna a base para se determinar quando os recursos necessários a cada atividade deverão estar disponíveis de forma a cumprir com a duração agendada. No evento em que um dado recurso não está disponível (ou não está disponível no volume necessário) para atender aos requerimentos do cronograma, em termos tanto de duração como de momento, a atividade talvez tenha que ser postergada. Este processo de postergação de atividades até que todos os recursos necessários estejam disponíveis é chamado de nivelamento de recursos e é normalmente realizado por um processo automatizado e baseado em algoritmos que uma grande maioria de pacotes de software de gestão oferecem. Alguns destes algoritmos são mais robustos que outros, e os softwares competem no mercado tendo como base a sua habilidade de gerar cronogramas nivelados por recursos de maior ou menor duração. Por fim, um cronograma que é bem desenvolvido quase sempre exige que se considere a disponibilidade (ou indisponibilidade) de recursos e o atraso das datas necessárias. Se estes atrasos ocorrem no caminho mais longo, ou se são tão longos que fazem com que um caminho alternativo passe a ser o mais longo (ex. mais longo do que a folga do caminho atual), então a duração total de um projeto será alterada.

Frequently, the CPM schedule then becomes the basis for determining when the resources needed by each activity must be available in order to meet its CPM schedule duration. In the event that a needed resource is unavailable (or unavailable in the needed volume) to meet the schedule requirements of an activity in terms of both duration and timing, that activity may have to be delayed. This process of delaying activities until their needed resources become available is called resource leveling and is often an automated process based on algorithms that most project management software packages offer. Some of these algorithms are more robust than others, and software packages often compete in the marketplace on the basis of the ability to generate a longer or shorter resource-leveled schedule. Ultimately, a schedule that is well designed almost always requires taking into account the availability (and unavailability!) of resources and delaying activity dates accordingly. If such delays are on the longest path, or if they are so long as to cause a path that was not the longest to become the longest (i.e., longer than the path’s float), then the project’s duration will be increased.

O que descrevemos até o momento é o trabalho cuidadoso e adequado que deve ser executado no desenvolvimento de um cronograma de qualquer projeto com uma complexidade significativa, importância ou risco. No entanto, por ignorância ou mesmo inocência, muito projeto não tem seus cronogramas desenvolvidos com a atenção necessária. Em muitas situações um Diagrama de Gantt simples é desenhado (“Nós iremos fazer isso aqui, e então isso ali e então mais alguma coisa aqui e, talvez alguma coisa mais ali…); em algumas vezes o agendamento de um cronograma de trás para frente é utilizado (“Nós temos que terminar isso nesta data, então precisamos disso pronto aqui, e isso significa que isso tem que ser concluído aqui,..”); e algumas vezes apenas se decide dar uma corrida rápida da forma mais forte possível por um mês, de forma a se descobrir o que pode ser feito e então se pensar no que fazer como próximo passo.

What we have described so far is the due diligence that should be performed in scheduling any project of significant complexity, importance or risk. However, due to ignorance or simple unwillingness, many projects are not scheduled in the manner described above. Sometimes a simple Gantt chart is drawn (“We’ll do this here, and then we’ll do this, and then this, and perhaps this stuff here,..”); sometimes backward scheduling is used (“We’ve got to finish by this date, so we need to get this done by here, and that means this has to be done by here,..”); and sometimes it’s just decided to “sprint” as hard as possible for a month, see what gets done, and then then think about what we can do next.

No entanto, a chave é descobrir que nenhum destes métodos remove o caminho crítico ou faz com que sua análise seja menos valiosa!

However, the key is to recognize that none of these methods either removes the critical path or makes critical path analysis less valuable!

O primeiro princípio importante é que praticamente qualquer projeto tem uma vantagem/lucro se completado antes. Em noventa e nove por cento das vezes, o mais cedo que um projeto é concluído, é o mais cedo que o seu produto pode ser entregue e comece a gerar o valor intencionado. Em muitos casos como no desenvolvimento de novos produtos, o valor da aceleração de um cronograma pode ser enorme. Adicionalmente, projetos mais curtos normalmente exigem menos esforço críticos e custos de suporte. E finalmente, quando um projeto é concluído mais cedo, ele remove praticamente todo o risco relacionado ao término tardio! Estes fatores, muitas vezes são deixados sem uma quantificação do seu valor durante o planejamento de um projeto, normalmente representam uma parcela significativa do benefício em se obter um cronograma mais curto, muitas vezes sendo isso suficiente para justificar recursos adicionais necessários ao processo de se realizar a compressão deste cronograma.

The first important principle is that almost every project can profit by being completed sooner. Ninety-nine percent of the time, the sooner a project is finished, the sooner its product can be deployed to start generating its intended value. In many cases such as new product development or enabler projects upon whose deployment other value generators are relying, the value of schedule acceleration can be huge. Additionally, shorter projects often require less overhead and support costs. And finally, when a project finishes earlier, it retires almost all the risk of finishing later! These factors, often left unquantified in project planning, usually represent a very significant benefit to achieving a shorter schedule, often sufficient to more than justify additional resources needed to bring about such schedule compression.

Se um projeto mais curto poderia aumentar o valor do projeto, como é que podemos analisar a melhor forma de realizar esta compressão? A resposta é a Análise do Caminho Crítico, que pode ser executada em qualquer projeto, não importa de qual forma ele foi desenvolvido.

If a shorter schedule would increase a project’s value, how can we analyze how we might best bring about such schedule compression? The answer is critical path analysis, which can be performed on any project no matter how it has been scheduled.

Todo projeto é exatamente tão longo quanto o seu caminho mais longo, muitas vezes chamado de “as built critical path” (ABCP) na indústria da construção. Este caminho é constituído de todas as atividades, esforços, atrasos, retrabalhos, restrições (lógicas, de recurso ou calendário) que são combinadas para criar o caminho mais longo que determina a duração atual do projeto. A Análise do Caminho Crítico é o processo, realizado no início ou em qualquer momento durante a execução, de se determinar quais são os fatores que geram postergações e o que pode ser feito em relação a eles para serem eliminados caso a equipe do projeto ou pessoas chave no projeto assim o decidam.

Every project is exactly as long as its actual longest path, often called the as built critical path (ABCP) in the construction industry. This path will consist of all the activities, sprints, stumbles, delays, rework and constraints (logical, resource, and calendar) that combine to create the longest path which determines the project’s actual duration. Critical path analysis is the process, performed up front or at any point during execution, of determining the delaying factors and what might be done about them if the project team and key stakeholders so decide.

A Análise do Caminho Crítico está disponível há décadas. No entanto, nos últimos quinze anos, uma nova e importante ferramenta foi adicionada para a caixa de ferramentas desta análise. Esta nova ferramenta é chamada de “Critical Path Drag” (Arrasto do Caminho Crítico). Enquanto a análise tradicional mede as atividades que não estão no caminho mais crítico, determinando o quanto elas podem desviar sem se tornarem críticas (por exemplo, através de suas folgas), o “drag” mede os dados no caminho mais longo, de forma a verificar quanto tempo cada um está adicionando a duração do projeto (Arrasto). E o seu corolário é o “drag cost”: qual é o valor daquele tempo adicionado que está reduzindo o valor do investimento no projeto (Custo de Arrasto).

Critical path analysis has been around for many decades. But within the past fifteen years, an important new tool has been added to the toolbox of the analysis. This new tool is called critical path drag. Whereas traditional analysis measured activities that were not on the longest path, determining the amount they could slip before becoming critical (i.e., their float or slack), drag actually measures the things on the longest path, to see how much time each is adding to the project duration. And its corollary is drag cost: how much is that added time reducing the value of the project investment.

Em outras palavras, o “Drag” é crítico, a folga não é.

In other words, drag is critical, float is not.

Alguns pacotes comercialmente disponíveis como o Spider Projeto já começam a oferecer o cálculo do “drag”. Mas esta informação também é crucial para aquelas pessoas em projetos que não tem acesso a tais pacotes.

Commercially-available software packages such as Spider Project that perform drag computation have begun to appear. But the information is also crucial for project personnel who don’t have such packages.

Em redes em cronogramas compostas exclusivamente de atividades com relação Término-Início (TI), o cálculo do “drag” é relativamente simples e, se necessário, pode ser calculado manualmente.

On network schedules with exclusively finish-to-start (FS) relationships, computing drag is fairly straightforward and, if necessary ought to be computed manually:

1. Para uma atividade no caminho crítico que não tem nada em paralelo, o seu arraso é a própria duração.

  1. For a critical path activity that has nothing else in parallel, its drag is its duration.

2. Para uma atividade no caminho crítico que tem outras atividades em paralelo, o seu arrasto é o que for menor: sua duração ou a folga da atividade que tem a menor folga.

  1. For a critical path activity that has other activities else in parallel, its drag is whichever is less: its duration OR the float of the parallel activity that has the least total float.


Figure 1. Computing Drag in a Network with All Finish-to-start (FS) Relationships Figura 1. Calculando o Arrasto emu ma Rede com todas as relações do tipo Término-Início

Na Figura 1: 1. As Atividades do Caminho Crítico A & I não tem nada em paralelo, então o seu arraso é igual as suas durações (A=10 e I = 5)

In Figure 1:

  • Critical path Activities A and I have nothing else in parallel, so their drags are equal to their durations, 10 and 5 respectively.

2. A duração da Atividade B é 20, mas o seu Arrasto é limitado pela folga de 10 das atividades paralelas C & F.

  • Activity B’s duration is 20, but its drag is constrained by the float of 10 of parallel Activities C and F.

3. A Atividade E teria um Arrasto de 9, restrito pela folga da Atividade D. Mas a Duração de E é somente 8, por isso este é o tempo que está adicionando ao Caminho Crítico e assim este é o seu Arrasto.

  • Activity E would have drag of 9, constrained by the float of Activity D. But Activity E’s duration is only 8, so that is all the time it is adding and that is its drag.

4. A Atividade H é paralela com as Atividades D, com folga de 9 e com a Atividade T, com folga 6. O menor valor, 6, é portanto o Arrasto de D.

  • Activity H is parallel with Activities D with float of 9 and Activity G with float of 6. The lower number, 6, is therefore D’s drag.

As relações de Término-Início normalmente são responsáveis por 70% ou mais das relações lógicas de uma rede. A maioria das outras serão o Início-Início, com ou sem “lag” (retardo). O Arrasto de uma Atividade do Caminho Crítico que tem uma ou mais sucessoras início-início também é relativamente fácil de ser calculada, da seguinte forma:

Finish-to-start relationships often account for 70% or more of the logic relationships in a network. The vast majority of others are start-to-start (SS) relationships, with or without lag. The drag of a critical path activity which has one or more start-to-start successors is also relatively easy to compute in the following manner:

5. Se não há outra atividade em paralelo, o arraso será aquele que for menor: sua duração ou a folga total e o “lag”(retardo) para cada uma das atividades sucessoras Início-Início.

  • If it has no other activities in parallel, its drag will be whichever is less: its duration OR the lowest total of float PLUS lag for each of the SS-successor activities.

6. Se tem outras atividades e caminhos completamente em paralelo, o seu Arrasto será o menor deles: o produto do cálculo no item 3 acima ou a folga da atividade paralela completa que tem a menor folga.

  • If it has other activities and paths completely in parallel, its drag will be whichever is less: the product of the calculation in 3 above OR the float of the completely parallel activity that has the least total float.


Figure 2. Computing Drag in a Network with Start-to-start (SS) Relationships Figura 2. Calculando o Arrasto em uma rede com Relações Início-Início

Na Figura 2 (Calculando o Drag em uma rede com relacionamentos Início-Início), sem a Atividade X na figura, o drag da Atividade B seria a menor soma da folga total e o retardo das três relações Início-Início+Retardo da Atividade B.

In Figure 2, without Activity X in the picture, the drag of Activity B would be the lowest sum of lag and total float of Activity B’s three SS + lag successors:

7. C com retardo de 7 e folga total de 5 = 12;

  • C with lag of 7 and total float of 5 = 12;

8. D com retardo de 5 e folga total de 3 = 8; e

  • D with lag of 5 and total float of 3 = 8; and

9. E com retardo de 3 e folga total de 7 = 10.

  • E with lag of 3 and total float of 7 = 10.

Com a duração de 20, o arrasto da Atividade B é a menor de todos estes: 8.

With a duration of 20, the drag of Activity B is the least of these: 8.

Se a Atividade X é parte da rede, então totalmente paralelo com a Atividade B e o arrasto de B seria limitado a 5 pela folga de X.

If Activity X is part of the network, then it is entirely parallel with Activity B and the drag of B would be limited to 5 by the float of X.

Como mencionado, os tipos de cálculo simplificados para o arrasto serão suficientes para calcular o arrasto em 90% a 100% das atividades do caminho crítico na maioria das redes. No entanto, mesmo que o software de alguém não calcule o arrasto do caminho crítico, o arrasto pode ser calculado para todas as relações de dependência, mesmo no caso dos raros casos de relações Término-Término (TT) e Início-Término (IT), com ou sem retardos, simplesmente pelo rearranjo destas relações no caminho crítico para uma situação de Término-Início como vistos na Figura 3.

As mentioned, these relatively simple type of computations will typically be sufficient to compute the drag of 90% – 100% of the critical path activities in most network schedules. However, even if one’s software does not compute critical path drag, drag can be computed for all dependency relationships, even the relatively rare finish-to-finish (FF) and start-to-finish (SF) relationships, with or without lags, simply by re-modeling such relationships on the critical path to all-FS relationships in the manner shown in Figure 3.

Com atividades do Caminho Crítico que tem tais sucessoras, a atividade predecessora precisa ser decomposta com a quantidade da folga de seu sucessor. Se a folga é zero, então um marco (duração zero) deveria ser criado para representar o início daquela predecessora. E se o fim de seu sucesso é restrito pelos predecessores, como em relacionamentos Término-Término (TT) ou Início-Término (IT), então um marco representando o fim do seu sucessor deve ser criado.

With critical path activities that have such successors, the predecessor activity should be decomposed at the amount of the lag to the successor. If the lag is zero, then a milestone (duration zero) should be created to represent the start of the predecessor. And if the finish of the successor is constrained by the predecessor, as in a finish-to-finish (FF) or start-to-finish (SF) relationship, then a milestone representing the finish of the successor should be created.


Figure 3. Decomposing Complex Dependencies with and without Lags to all-FS Relationships Figura 4. Decompondo Dependências Complexas com e sem Retardos para Término-Início

O arrasto do caminho crítico é o tempo pelo qual o item do caminho crítico está atrasando o término de um projeto. Este tempo é dinheiro, reduzindo o valor do investimento do projeto e também do produto, bem como ocasionando um aumento nos custos excedentes do projeto e os custos de oportunidade. O valor deste tempo deve ser estimado e combinado com a funcionalidade ampliada do arrasto na análise do caminho crítico, para justificar mudanças no cronograma que possam ampliar o valor final do projeto. Se uma atividade tem três semanas de arrasto e a redução do tempo total de um projeto aumentaria o seu valor em $60M, $40M e $ 20M respectivamente para cada semana anterior, então aquela atividade tem um custo de arrasto de $120M. Se ampliarmos os recursos de uma atividade em $30M poderia eliminar três semanas de arraso, então o resultado para o projeto seria de $90M mais em lucratividade quando comparado com o cronograma original. Esta técnica pode ser utilizada tanto para justificar o custo adicional de recursos como também para auxiliar o aumento da lucratividade de um projeto.

Critical path drag is the time by which a critical path item is delaying project completion. That time is money, reducing the value of the project investment by reducing the value of the final product as well as by causing an increase in the project’s overhead costs and opportunity costs. The value of that time must be estimated and combined with the drag-enhanced functionality of critical path analysis to permit justification of schedule changes that enhance the final value-above-cost of the project. If an activity has three weeks of drag, and reducing the project duration would increase its value by $60,000, $40,000 and $20,000 respectively for each week earlier, then that activity has drag cost of $120,000. If increasing the activity’s total resource costs by $30,000 would eliminate its three weeks of drag, the result would be a project that is $90,000 more profitable than with the original schedule. This is the technique that can be used both to justify the cost of additional resources and to make projects more profitable.

Esta análise é desenvolvida para calcular o arrasto das atividades em um projeto através do CPM (Método do Caminho Crítico). Mas também irá funcionar de forma equivalente para todos os itens — atividades, “sprints”, atrasos, retrabalhos, restrições (lógicas, de recurso e de calendário) que combinadas irão criar o caminho mais longo de um projeto. E isso é a razão pela qual a análise do caminho crítico, incluindo o cálculo do arrasto e do custo do arrasto, deveria ser utilizada em todos os projetos.

This analysis is designed to compute the drag of work activities in a project scheduled through CPM. But it will work equally well for all items — activities, sprints, stumbles, delays, rework and constraints (logical, resource, and calendar) that combine to create the longest path of any project, however scheduled. And that is why critical path analysis, including drag and drag cost computation, should be used on every project.


Encaminhe sua sugestão de melhorias para esta tradução
(ou dúvidas e sugestões a respeito do próprio conteúdo!)

blogmundopm@peter.smello.email


 

 

HOLOGRAMAS – O futuro da Gestão de Projetos de Inovação

 

Fonte: http://www.microsoft.com/microsoft-hololens/en-us

Fonte: http://www.microsoft.com/microsoft-hololens/en-us

Parece trailer de um filme de ficção científica mas não é, é realidade. Na verdade, não é realidade, é uma holografia inserida na realidade, no mundo real! O avanço tecnológico está muito rápido e nós como profissionais e consumidores, e também as organizações, não estamos conseguindo acompanhar tal velocidade da forma como gostaríamos.

Estamos mergulhados em dispositivos com telas multi-touch. É a TV, o celular, o notebook, a geladeira, tudo tem uma telinha multi-touch, está na moda, se não for multi-touch está ultrapassado, obsoleto. E agora? Agora vem esta tal de holografia. O que fazer com ela? Ainda não sabemos exatamente, mas como cientista em gestão eu fico me perguntando quais são as implicações. Acredito que a inovação em gestão depende de uma combinação de práticas e modelos, ferramentas computacionais (tecnologia) e competências das pessoas. Portanto, o que irá mudar? O que podemos melhorar a partir desta tecnologia? Em quanto tempo? Qual custo? Será uma tecnologia para todos? As empresas devem se preocupar agora?

E mais, qual a relação com a gestão de projetos e inovação? Bem, se você trabalha com projetos, desenvolvimento de produtos ou serviços na sua empresa, acho que vou lhe convencer de ao menos acompanhar como será o desenrolar desta tecnologia nos anos seguintes, ou até mesmo começar já uma investigação de como tirar proveito disso antes de seus concorrentes.

Desde a semana passada diversos canais de notícia e jornais aqui nos Estados Unidos e em algumas outras partes do mundo estão noticiando este assunto e questionando quais as implicações para as organizações e potenciais consumidores. A plataforma chamada “HoloLens” foi apresentada pela Microsoft em um evento de demonstração reservado para convidados. Trata-se de um conjunto de hardware e software que combina holografia com o mundo físico. Assista o depoimento de uma participante das demonstrações (vídeo do canal IGN[1]).

A plataforma é realmente interessante e com certeza vai ter um grande impacto em diversas áreas. Ah! Um fato importante: Quem está por traz do projeto é um Brasileiro, o Chief Inventor, Alex Kipman, responsável também pelo Kinect.

De acordo com matéria publicada no site da Forbes[2], o HoloLens não pode ser comparado com o Google Glass e também não é um equipamento de realidade virtual, como já existe no mercado. O HoloLens combina hologramas em um ambiente físico, real, e permite que o usuário manipule e interaja com os objetos e imagens geradas pelo dispositivo. Você coloca uma espécie de óculos (ou capacete com visores e câmeras) e este aparelho engana sua visão e cérebro por meio de múltiplas câmeras, sensores e luzes projetadas em um visor e assim você enxerga imagens holográficas em 3D em um ambiente físico real[3]. Veja a demonstração em vídeo.

Bem, de qualquer forma, ainda é difícil estimar o potencial de aplicação desta tecnologia em diferentes setores da indústria, projetos e desenvolvimento de produtos. Contudo, uma área em potencial já está de olho nisso, é a área de jogos ou entretenimento. E mais, como esta tecnologia irá evoluir a partir desta demonstração, como será o desenvolvimento de aplicativos pela comunidade e aceitação do mercado, são perguntas sem resposta. Com certeza é um tema empolgante para gastar algumas horas fazendo um brainstorming com profissionais de diferentes industrias para identificar as oportunidades que podem surgir.

Minha organização deve se preocupar com esta tecnologia?

A resposta é depende. Este é o tipo de tecnologia que se evoluir da forma como se espera irá impactar direta ou indiretamente diferentes setores. Agora, se você é o CEO de uma empresa de jogos, sem dúvida nenhuma, comece se preocupar já! Se você é o CEO de qualquer que seja a empresa que desenvolve produtos e serviços cujo grau de interface com o usuário ou clientes é médio ou elevado, não custa fazer algumas perguntas como: de que forma esta tecnologia pode ser incorporada no meu produto ou serviço? Como posso utilizá-la para melhorar o desenvolvimento do meu produto? Como ela irá impactar o mercado que atuo? Como os hologramas podem melhorar a experiência dos usuários do meu produto e meus clientes? Como acelerar o processo de inovação dos meus produtos e serviços a partir do uso desta tecnologia? Como gerar novos negócios com base nesta tecnologia? Existe um artigo recentemente publicado na Harvard Business Review (HBR) falando deste tópico[4].

Quer um exemplo simples? Este exemplo foi citado no artigo da HBR4 e concordo que seja bem factível. Eu comprei um novo apartamento e estou em busca de nova mobília e itens para decoração. Eu acesso um site de um fabricante e venda de móveis e que também vende eletrodomésticos. A empresa possui um aplicativo que eu posso fazer o download e carregar no meu HoloLens. Com ele terei acesso ao catálogo completo de produtos. Daí por diante é pura diversão. Vou mobiliar meu apartamento com hologramas, visualizar com dimensões bem reais e em cores como será a sala, o quarto, a cozinha… A empresa também permite realizar pequenas customizações e ajustes nos móveis, claro, isso é sempre necessário para otimizar espaços em um apartamento. Obviamente, isso terá um custo maior e terei que esperar um pouco mais para receber os móveis. “Navego” virtualmente pelo meu apartamento e sua mobília e com itens de decoração que posso ir adicionando, “experimentando”. Faço um ajuste aqui, outro ali, troco o fogão por um modelo mais compacto, e pronto, ficou ótimo! Gostei! Vou comprar já mesmo. Compro os eletrodomésticos e encomendo os móveis da cozinha, sala e quartos, ali mesmo, naquele ambiente.

Veja como uma tecnologia como essa pode mudar por completo a experiência de compra em determinados setores. E isso é só o começo…

O potencial para projetos de inovação e desenvolvimento de produtos

A seguir coloco algumas poucas ideias de como esta tecnologia poderia impactar o gerenciamento de projetos de inovação e o desenvolvimento de novos produtos e serviços. Vejo que um importante uso para esta tecnologia é aproximar o usuário e cliente do desenvolvimento de um novo produto ou serviço. A seguir descrevo alguns poucos insights e convido todos a fazerem comentários e colocar vossas ideias. Será um exercício bem interessante.

Entendo que são três áreas que podem se beneficiar desta tecnologia em um futuro breve.

Interação com o cliente e potenciais usuários

Talvez você não tenha uma impressora 3D na sua casa, mas seu filho fez você comprar um HoloLens pra ele. Você então descobre que é possível transformar desenhos técnicos em hologramas e carregá-los na plataforma do HoloLens. Você então leva o HoloLens do seu filho (sem que ele saiba) para uma reunião com o cliente, na qual você irá mostrar uma maquete holográfica do produto com os primeiros requisitos que o cliente lhe apresentou no inicio do projeto. Veja, você está ainda no início do projeto, muitos requisitos ainda são desconhecidos, bem como muitos desafios técnicos e problemas que precisam ser solucionados para desenvolver o produto. A sua ideia é apresentar algo que enriqueça a experiência do cliente, inspire a colaboração e que contribua para fomentar uma discussão mais rica sobre o que será o produto e ainda, identificar melhorias ou mudanças necessárias no projeto enquanto o custo da mudança ainda é baixo.

Organizações que desenvolvem produtos que tenham elevada interação com usuários, bens de consumo e bens duráveis por exemplo, poderiam tirar proveito desta tecnologia para aproximar mais os usuários e potenciais clientes já nas fases iniciais do desenvolvimento e geração de conceitos antes mesmo de desenvolver um protótipo físico. Isso poderia ser feito por meio de experimentos usando hologramas. Uma vez que o produto já existe e está no mercado as empresas podem criar aplicativos e serviços que permitam um “test-drive” com o produto ao invés de simplesmente observar fotos ou vídeos sobre o produto, e dessa forma incentivar e motivar a compra do produto.

Comunicação e colaboração entre membros do time de projeto

Pic_motorcycle_MicrosoftHololens

Fonte: http://www.microsoft.com/microsoft-hololens/en-us

Pensando na gestão de um projeto de inovação e desenvolvimento de produto, estou visualizando algumas aplicações e utilidade para os membros do time de projeto, gestores e stakeholders. Vamos utilizar o exemplo apresentado pela própria Microsoft (Figura da Moto ao lado). Você é gestor do projeto de um novo produto, o desenvolvimento de uma nova motocicleta, e está em uma reunião com o time de desenvolvimento. Usando o HoloLens todos participam. Hologramas das partes e peças do produto podem ser exploradas, “testadas” em combinação com um protótipo físico ou produto similar com o objetivo de testar conceitos, ideias e hipóteses sobre o design, funcionalidades, forma, cores, etc.

Detalhe, esta reunião pode ser virtual, com membros do time de diferentes localidades. Isso já não seria mais um desafio já que todos poderiam “brincar” com os hologramas em suas salas ou respectivos escritórios. Seria sem dúvida um bom avanço em ferramentas para desenvolvimento de produtos e projetos de inovação em nível global com equipes virtuais.

Potencial para inovações nas ferramentas de gerenciamento de projetos

Há uma crescente busca por inovações nas ferramentas computacionais de gestão de projetos. Na verdade, muito pouco se avançou no uso de novas tecnologias para gerenciar projetos, principalmente quando se trata de interação com o ser humano e diferentes formas de interface com o usuário dessas ferramentas. Pra se ter uma ideia, ainda há pouca adoção de dispositivos multi-touch com maior apelo visual para se gerenciar projetos de inovação.

fee6354a-37a7-4f7e-a29d-1a8a3e42b8e0

Fonte: http://www.microsoft.com/microsoft-hololens/en-us

A tecnologia do HoloLens poderia ter contribuições relevantes para aprimorar os dispositivos de gestão de projetos. Quer um exemplo simples? O uso de quadros visuais de gestão poderia ser composto também por hologramas ou até ser totalmente substituídos por eles. Se o time tiver um quadro eletrônico que mostre os “cartões” de entrega, cronogramas, listas de entregas, etc., por exemplo, por meio do HoloLens talvez seria possível reproduzir este quadro em outra localidade e permitir que o usuário manipule o quadro como se ele estive presente, sem possuir um quadro físico.

Acho que este exemplo que acabei de dar é muito simplista. Como dizia Albert Einstein, “Se uma ideia inicialmente não pareça insana ou impossível, não há esperança para ela”. Então, vamos pensar de forma mais ambiciosa. Imagine que você é o gestor de um projeto de um empreendimento imobiliário. Vamos adotar a premissa de que haveria uma integração completa entre cronograma financeiro e físico entre os diferentes softwares que sua organização utiliza, incluindo por exemplo, um ERP. Imagine também que a integração de softwares de design e arquitetura também é simples de se obter. Pronto, você tem o ambiente perfeito para o que vou idealizar.

Você, gestor do projeto, vai até o canteiro de obras para acompanhar o progresso do empreendimento e o que foi entregue nas últimas semanas. Você coloca o seu HoloLens e sincroniza os desenhos do empreendimento com os dados de planejamento e cronograma e logo visualiza em cores o real avanço da obra. Em uma combinação de realidade e hologramas você visualiza destacado com uma sombra na cor verde o progresso, a construção realizada e que estava programada para estar pronta, comparado com a última vistoria. Em vermelho está o que deveria ter sido entregue, mas não foi. O que você enxerga é apenas um holograma da parte que deveria estar construída. Neste mesmo ambiente você já recebe dados da análise de valor agregado do projeto, eventuais desvios e dados que lhe ajudará prever se será possível finalizar o que foi prometido até o final do mês. Em seguida você solicita dados de uma simulação, com horas extras, por exemplo, pra ver o quanto seria possível avançar na construção… Tudo isso poderia ser visualizado na obra, na forma de um holograma, o quanto da obra seria entregue com algumas ações e comparar se isso seria suficiente para apresentar para os stakeholders.

Bem, daí por diante é pura imaginação, ou ainda, um possível trailer de um filme de ficção científica mas que poderá ser realidade muito em breve.

 

Grande Abraço,

Até o próximo Innovation Insights!

 

[1] Vídeo Canal IGN https://www.youtube.com/watch?v=lttveKXDaXg

[2] http://www.forbes.com/sites/patrickmoorhead/2015/01/28/microsoft-hololens-gets-faces-wearables-right/

[3] http://www.theverge.com/2015/1/21/7868251/microsoft-hololens-hologram-hands-on-experience

[4] Artigo HBR sobre o HoloLens: https://hbr.org/2015/01/what-hololens-has-that-google-glass-didnt