Voc\u00ea j\u00e1 teve seu projeto cancelado por uma mudan\u00e7a repentina no mercado? J\u00e1 foi demitido apesar de n\u00e3o ter nenhum ind\u00edcio de que isso pudesse acontecer? J\u00e1 ganhou na loteria? Voc\u00ea nasceu? \ud83d\ude00 Se alguma destas coisas j\u00e1 te aconteceu, voc\u00ea vivenciou um Cisne Negro: um evento totalmente imprevis\u00edvel para voc\u00ea, que traz um grande impacto negativo ou positivo.<\/p>\n
No livro The Black Swan<\/em> (A L\u00f3gica do Cisne Negro, em portugu\u00eas), Nassim Taleb apresenta um\u00a0fato, cada vez mais comum, segundo ele, de que as pessoas se apoiam demais naquilo que sabem, desconsiderando os poss\u00edveis impactos daquilo que n\u00e3o sabem. O autor vai dizer que dever\u00edamos estar mais preocupados com o que <\/span>n\u00e3o sabemos<\/span>, pois aquilo que j\u00e1 \u00e9 de nosso conhecimento acaba nos cegando ou nos dando falsas sensa\u00e7\u00f5es de seguran\u00e7a, tornando-nos fr\u00e1geis. Dif\u00edcil de entender? \ud83d\ude42<\/span><\/p>\n Mas pera\u00ed!! Voc\u00ea n\u00e3o ia falar do peru? O que esse cisne a\u00ed tem haver? \ud83d\ude00<\/p><\/blockquote>\n Para falar sobre esse assunto e tentar esclarecer algumas das minhas d\u00favidas tamb\u00e9m, entrevistei\u00a0<\/span>Celso Martins<\/b><\/a>, Agile Coach e desenvolvedor, atualmente atuando na Taller – Ateli\u00ea de Desenvolvimento de Software <\/em>e na<\/span> Crafters Innovation Studio<\/span><\/em>, e que em breve lan\u00e7ar\u00e1 um livro tratando dos “cisnes negros”, complexidade e sistemas, aplicados ao desenvolvimento de software. Agrade\u00e7o enormemente o Celso por separar um tempo e trazer mais luz aos nossos estudos. <\/span><\/p>\n Para melhor aproveitar esta entrevista, caso n\u00e3o tenha lido os livros <\/span>The Black Swan<\/span><\/i> ou <\/span>Antifragile<\/span><\/i>, veja\u00a0<\/span>este v\u00eddeo<\/b><\/a> (13 min) que traz coment\u00e1rios sobre o livro e que pode lhe dar uma base para assimilar melhor as respostas do Celso.<\/span><\/p>\n Esta entrevista ter\u00e1 90% das perguntas sobre o assunto e 10% n\u00e3o, a fim de corrermos o risco positivo de se beneficiar de um conte\u00fado inesperado \ud83d\ude09 <\/span><\/i><\/p><\/blockquote>\n Vamos l\u00e1:<\/span><\/p>\n 1) Numa entrevista que fiz com Alisson Vale publicada neste site, uma das perguntas foi o “<\/b>quanto experimentar<\/b><\/a>“. A pergunta teve como base o poss\u00edvel desperd\u00edcio que haveria ao se tratar tudo como uma necessidade de descoberta e especulei se n\u00e3o haveria momentos em que convergir mais r\u00e1pido para a solu\u00e7\u00e3o seria melhor. No seu livro voc\u00ea tamb\u00e9m ir\u00e1 ressaltar que em desenvolvimento de software estamos sempre navegando entre os dom\u00ednios <\/b>Complicado<\/i><\/b> e <\/b>Complexo<\/i><\/b>, que requerem abordagens diferentes. Voc\u00ea poderia nos dar exemplos nos dois dom\u00ednios e como saber quando estamos em um ou em outro? <\/b><\/p>\n R: Ol\u00e1 Buzon. Primeiramente ressalto que \u00e9 um enorme prazer estar aqui e poder participar desta conversa que faremos sobre um assunto que venho estudando e que tem me agradado bastante, a aleatoriedade. Na verdade, a flutua\u00e7\u00e3o entre os dom\u00ednios do Cynefin <\/a>\u00e9 bem maior. Podemos ir e voltar do caos, do \u00f3bvio, do complicado, do complexo e da desordem. Na desordem, estamos em todos os quatro dom\u00ednios anteriores ao mesmo tempo. Ent\u00e3o al\u00e9m da flutua\u00e7\u00e3o entre os dom\u00ednios, podemos tamb\u00e9m estar em todos. Tamb\u00e9m podemos ter um sistema que est\u00e1 em dois dom\u00ednios ao mesmo tempo, no complicado e no complexo sem que para isso estejamos na desordem.<\/span><\/p>\n Exemplo: Imagine que o Projeto A vai gerenciar uma loja de venda de ra\u00e7\u00f5es para c\u00e3es e o sistema de estoque j\u00e1 foi desenvolvido. Agora o comercial vendeu o Projeto B que vai gerenciar uma loja de aqu\u00e1rios e tamb\u00e9m precisar\u00e1 de um sistema de estoques. Para o sistema de estoques do Projeto B, com o mesmo time ou time similar, voc\u00ea estar\u00e1 no complicado ou at\u00e9 mesmo no \u00f3bvio. Para o sistema A, voc\u00ea estar\u00e1 no complexo. Obviamente estou simplificando para facilitar o entendimento, pois com o conhecimento geral que existe atualmente, n\u00e3o seria nenhum absurdo considerar o Projeto A j\u00e1 de cara no complicado, mas provavelmente, neste caso, nunca estar\u00e1 no \u00f3bvio. Agora imagine que entrou um Projeto C que usar\u00e1 c\u00e1lculos estat\u00edsticos para sugest\u00e3o de restaurantes baseado no seu gosto e na cidade que voc\u00ea est\u00e1, no celular. O time nunca mexeu com mobile. Neste caso estaremos no complexo e um alto n\u00edvel de experimentos ser\u00e1 exigido.<\/span><\/p>\n \u00c9 imposs\u00edvel uma receita de bolo ou checklist que te posicione em um dos dom\u00ednios. Isso acontece sempre de acordo com a an\u00e1lise da situa\u00e7\u00e3o atual, que pode mudar em quest\u00e3o de minutos ou dias, ou semanas, ou de um projeto para outro. Ou voc\u00ea pode estar com uma demanda no complexo e v\u00e1rias outras no complicado. Ou com um objetivo de neg\u00f3cio no complexo e outro no complicado. Sim, a an\u00e1lise \u00e9 complexa e como tal n\u00e3o cabe ferramentas do complicado\/\u00f3bvio, como checklists.<\/span><\/p>\n 2) As Retrospectivas cl\u00e1ssicas do Scrum endere\u00e7am quest\u00f5es do dom\u00ednio complexo? Como deveriam ser as retr\u00f4s para se extrair o melhor do que elas podem oferecer?<\/b><\/p>\n R: No complexo voc\u00ea n\u00e3o pode projetar o futuro a partir de an\u00e1lises do passado. Ponto. Conhecer o que aconteceu no passado s\u00f3 poder\u00e1 te ajudar a deixar o seu processo ou o seu sistema mais robusto a impactos de variabilidades. Se uma variabilidade se repete, voc\u00ea ter\u00e1 o seu contexto, ou parte dele, no complicado. Perceber a migra\u00e7\u00e3o entre os dom\u00ednios do Cynefin \u00e9 essencial para qualquer gestor que quer praticar a gest\u00e3o moderna baseada na teoria dos sistemas. Ent\u00e3o a retrospectiva da forma como conhecemos, mirando nos stressors (Ex: Web service n\u00e3o funcionou) e tentando mitig\u00e1-los \u00e9 inerte. Os impactos continuar\u00e3o acontecendo e deixar o sistema no m\u00ednimo mais robusto quanto a eles \u00e9 uma decis\u00e3o que dificilmente sai de uma retrospectiva tradicional. Hoje em dia vejo a retrospectiva tradicional mais como uma terapia de casais\/grupo. Se o grupo tem roupa suja e ainda n\u00e3o passou do storming, \u00e9 interessante ter. Se passou do storming \u00e9 chata e desnecess\u00e1ria.<\/span><\/p>\n No complexo, experimentar \u00e9 importante. Errar \u00e9 importante. Com a teoria do Taleb aprendemos que \u00e9 imposs\u00edvel validar se algo est\u00e1 correto, entretanto \u00e9 relativamente f\u00e1cil validar se est\u00e1 incorreto. Para validar a corre\u00e7\u00e3o, voc\u00ea precisa que todos os resultados testem positivo. O que n\u00e3o conhecemos? N\u00e3o podemos afirmar que existem apenas cisnes brancos, porque n\u00e3o conhecemos todas as amostras de cisnes existentes. Devemos focar nas consequ\u00eancias e n\u00e3o em adivinha\u00e7\u00e3o: <\/span><\/p>\n Robusto<\/b>: <\/span><\/p>\n Como podemos adaptar nosso sistema (processo, projeto, processo + projeto, departamento, fam\u00edlia, etc) para n\u00e3o sofrermos com impactos desta natureza?<\/span><\/p>\n Antifr\u00e1gil<\/b>: <\/span><\/p>\n Como podemos adaptar nosso sistema (processo, projeto, processo + projeto, departamento, fam\u00edlia, etc) para que ele fique melhor com impactos desta natureza?<\/span><\/p>\n Taleb nos mostra algumas ferramentas, como a opcionalidade.<\/span><\/p>\n 3) Antes de chegar ao fim do livro <\/b>Black Swan <\/i><\/b>confesso que fiquei angustiado, pois a todo instante parece que o autor est\u00e1 dizendo que n\u00e3o sabemos de nada ou que n\u00e3o valeria a pena planejar ou projetar… at\u00e9 que “caem algumas fichas”: o problema n\u00e3o s\u00e3o as estimativas e planos em si, mas a rela\u00e7\u00e3o que temos com eles. Como se d\u00e1 isso no desenvolvimento de software? <\/b><\/p>\n R: A resposta anterior foi uma introdu\u00e7\u00e3o a esta.<\/span><\/p>\n Ao reconhecer que podem existir coisas que estejam nos escapando \u00e0 percep\u00e7\u00e3o damos o primeiro passo em dire\u00e7\u00e3o \u00e0 robustez ou quem sabe \u00e0 antifragilidade. Deixamos de ser <\/span>fragilistas<\/span><\/i>, que nada mais \u00e9 que a pessoa que transfere fragilidade. Isso pode acontecer consciente ou inconscientemente. Uma das caracter\u00edsticas do fragilista \u00e9 a capacidade de manipular em seu favor a narrativa da an\u00e1lise dos fatos <\/span>post-morten<\/span><\/i>, que s\u00f3 \u00e9 poss\u00edvel devido a dist\u00e2ncia e turbidez entre causa e efeito. <\/span><\/p>\n No software encontramos isso expresso pela gest\u00e3o comum nas formas que j\u00e1 conhecemos bem: <\/span>Este projeto est\u00e1 atrasado, porque<\/span><\/i>… ” falhamos no planejamento, ent\u00e3o temos que ter mais dois meses de planejamento no pr\u00f3ximo” ou “falhamos na completude do documento XPTO, ent\u00e3o precisamos do documento X e do documento Y para voltarmos ao controle…”<\/span><\/p>\n O fragilista recebe os <\/span>payoffs<\/span><\/i> positivos de um desastre econ\u00f4mico, enquanto quem acreditou nele recebe os negativos. Os profetas econ\u00f4micos, os jornalistas, os consultores irrespons\u00e1veis ficam com os <\/span>upsides<\/span><\/i> e os empres\u00e1rios, a sociedade, com os <\/span>downsides<\/span><\/i>. Neste caso a antifragilidade foi transferida de quem tem <\/span>skin in the game<\/span><\/i> para quem n\u00e3o tem <\/span>skin in the game<\/span><\/i>, e consequentemente n\u00e3o est\u00e1 exposto aos impactos “previstos” ou n\u00e3o previstos, depende da narrativa que o fragilista vai querer contar p\u00f3s-fato.<\/span><\/p>\n 4) Um sistema de controle de enchentes deixa uma cidade confort\u00e1vel a ponto de permitir que se construam resid\u00eancias e pr\u00e9dios pr\u00f3ximos \u00e0s zonas de alagamento, pois h\u00e1 confian\u00e7a nos procedimentos, alertas e controles definidos. Entretanto, um tsunami que extrapole toda a toler\u00e2ncia do sistema, ocasionar\u00e1 um impacto gigantesco, matando mais pessoas, provavelmente, do que se n\u00e3o houvesse um sistema no qual confiassem. Ou seja, as a\u00e7\u00f5es do plano de risco t\u00eam os seus pr\u00f3prios riscos. \u00c9 poss\u00edvel estar imune a estes eventos? Qual seria a postura que dever\u00edamos ter para minimizar esses impactos? Ou, para quem leu o livro: Como n\u00e3o ser o <\/b>peru de a\u00e7\u00e3o de gra\u00e7as<\/i><\/b>?<\/b><\/p>\n R: Querer ser poss\u00edvel “estar imune” pressup\u00f5e que essa an\u00e1lise esteja correta. No Black Swan existe um defeito cognitivo atribu\u00eddo a isso: Epistemic Opacity<\/em>. E se as medidas de seguran\u00e7a n\u00e3o fossem tomadas e este grupo de pessoas tivesse ido morar nas bocas de um vulc\u00e3o que explodiu e matou todo mundo? Eu entendi o seu ponto, mas s\u00f3 estou tentando mostrar que algumas coisas \u00f3bvias n\u00e3o estariam t\u00e3o \u00f3bvias assim quando o assunto \u00e9 <\/span>n\u00e3o fazer determinada coisa para minimizar riscos<\/b>.<\/span><\/p>\n Neste caso, como voc\u00ea bem exp\u00f4s, seria imposs\u00edvel obter 100% de prote\u00e7\u00e3o ao risco, pois voc\u00ea est\u00e1 tomando uma medida que tenta evitar o Black Swan negativo, e isso na maioria dos casos \u00e9 imposs\u00edvel. No seu exemplo, as pessoas est\u00e3o confiando nas estat\u00edsticas – um tsunami a cada 100 anos – e n\u00e3o nas medidas de seguran\u00e7a que, possuindo ganhos limitados, s\u00f3 conseguiria avisar que voc\u00ea vai morrer em alguns minutos.<\/span><\/p>\n Se voc\u00ea quer um sistema convexo neste caso, \u00e9 preciso contar que o tsunami vai ocorrer na pr\u00f3xima ter\u00e7a e de alguma forma adaptar o seu sistema para que ele ou n\u00e3o sofra ou fique ainda melhor.<\/span><\/p>\n Concorda que, com a primeira, o tsunami n\u00e3o faz diferen\u00e7a e com a segunda e terceira podemos at\u00e9 ter casos em que torceremos para que um tsunami aconte\u00e7a? A primeira \u00e9 robustez, a segunda e terceira s\u00e3o antifr\u00e1geis.<\/span><\/p>\n 5) Muita gente <\/b>avaliou mal<\/b><\/a> o livro do Tabeb, reduzindo seu conte\u00fado a: “<\/b>Shit happens”<\/i><\/b> (merdas acontecem). O que o livro agrega para al\u00e9m do \u00f3bvio na sua vis\u00e3o?<\/b><\/p>\n R: Taleb usa uma linguagem dif\u00edcil, na minha vis\u00e3o, que \u00e0s vezes passa da linguagem dos guetos para uma linguagem mais erudita, com um ingl\u00eas dif\u00edcil no mesmo par\u00e1grafo. Ele tamb\u00e9m n\u00e3o liga para m\u00e9tricas e planejamento de cap\u00edtulos e m\u00f3dulos e muito menos para o que o leitor dele ou o editor v\u00e3o achar. Isso \u00e9 o que ele diz, n\u00e3o lembro se no Black Swan ou Antifragile.<\/span><\/p>\n Quem avalia o livro desta forma negligenciou todos os desvios cognitivos e o mergulho no mundo da matem\u00e1tica fractal no Black Swan, assim como todos os exemplos e at\u00e9 as explica\u00e7\u00f5es matem\u00e1ticas do livro 5 no Antifragile. \u00c9 prov\u00e1vel que estas pessoas pularam o livro 5. Na verdade \u00e9 prov\u00e1vel que tenham pulado os dois livros.<\/span><\/p>\n Na contram\u00e3o do shit happens<\/em>, Taleb nos ensina uma forma de pensar e agir para quando o problema acontecer e nos avisa: ele vai acontecer, pare de contar com a sorte.<\/span><\/p>\n 6) Hoje ainda vemos discuss\u00f5es sobre se usamos Scrum ou Kanban ou varia\u00e7\u00f5es predefinidas destes. Olhando, entretanto, para esta transitoriedade do desenvolvimento de software entre o <\/b>Complexo<\/i><\/b> e o <\/b>Complicado<\/i><\/b>, voc\u00ea imagina que uma equipe deva ter a sensibilidade de escolher os <\/b>approaches<\/i><\/b> mais adequados de acordo com o per\u00edodo em que est\u00e1 vivendo, podendo mudar v\u00e1rias vezes dentro de um determinado per\u00edodo? Ou isso independeria do <\/b>framework<\/i><\/b> em uso?<\/b><\/p>\n R: Esta sua pergunta tem um pouco de gest\u00e3o de mudan\u00e7as. Um sistema precisa de algum tempo para absorver mudan\u00e7as relevantes. Este \u00e9 um ponto. Se voc\u00ea inserir muitas mudan\u00e7as ao mesmo tempo vai provavelmente jogar o sistema no caos.<\/span><\/p>\n Outro ponto \u00e9: quase todos os m\u00e9todos\/frameworks\/whatever quebram no complexo. Apenas um sobrevive – e aqui posso estar sofrendo de <\/span>epistemic arrogance<\/span><\/i> ou <\/span>epistemic opacity<\/span><\/i> – o m\u00e9todo cient\u00edfico. Levantamento e invalida\u00e7\u00e3o (via negativa) de hip\u00f3teses de forma c\u00edclica.<\/span><\/p>\n N\u00e3o \u00e9 glamouroso estar em qualquer um dos dom\u00ednios do Cynefin. Inclusive o mais natural \u00e9 tentarmos trazer do complexo para o complicado para que o que desejamos fazer seja gerenci\u00e1vel, caiba em algum m\u00e9todo ou framework. <\/span>Confie em princ\u00edpios mais que pr\u00e1ticas<\/span><\/a> e mantenha sua cabe\u00e7a aberta ao comportamento e forma\u00e7\u00e3o do sistema. Essa \u00e9 a lei.<\/span><\/p>\n Esta briga Scrum x Kanban \u00e9 profundamente comercial, porque os dois atuam no complicado e n\u00e3o \u00e9 nem um pouco relevante para os meus objetos de estudo atual e n\u00e3o possuo interesse comercial em nenhum m\u00e9todo, portanto \u00e9 irrelevante para mim. \u00c9 bom para dar umas boas risadas.<\/span><\/p>\n 7) Pra quem n\u00e3o conhece o <\/b>fluxo unificado<\/b><\/a> voc\u00ea poderia explicar rapidamente a ideia e mostrar como essa abordagem contribui com a antifragilidade do sistema?<\/b><\/p>\n Rapidamente ser\u00e1 dif\u00edcil. =)<\/span><\/p>\n O Fluxo Unificado \u00e9 fortemente baseado em princ\u00edpios bem solidificados, principalmente a teoria das filas e nos aspectos econ\u00f4micos das filas. Vem para reduzir o custo de coordena\u00e7\u00e3o na opera\u00e7\u00e3o e o custo de execu\u00e7\u00e3o para o cliente – seja ele cliente interno ou externo.<\/span><\/p>\n Como o Fluxo Unificado d\u00e1 o contexto dos projetos unificados a todos os envolvidos, n\u00f3s reduzimos drasticamente o impacto da Lei de Brooks<\/a>, habilitando a opcionalidade no processo de desenvolvimento de software. Segundo Taleb \u00e9 praticamente imposs\u00edvel antifragilidade sem opcionalidade. A opcionalidade \u00e9 a raiz da antifragilidade.<\/span><\/p>\n Cen\u00e1rio tradicional:<\/b><\/p>\n Imagine que o Projeto A encontre um problema para a defini\u00e7\u00e3o de uma integra\u00e7\u00e3o e isso bloqueie uma demanda. Se o seu sistema n\u00e3o trabalha com limite de WiP, provavelmente a solu\u00e7\u00e3o ser\u00e1 puxar outra.. e outra.. e outra at\u00e9 o seu estoque de trabalho-n\u00e3o-feito ficar ingerenci\u00e1vel. Em algum momento o time do projeto A vai parar e o que as empresas modernas fazem \u00e9 tentar gerar conhecimento com esse tempo ocioso for\u00e7ado. As empresas mais tradicionais tentam for\u00e7ar atividades dentro do projeto, as vezes at\u00e9 puxando mais demandas.<\/span><\/p>\n Cen\u00e1rio Fluxo Unificado:<\/b><\/p>\n Agora imagine que no mesmo fluxo esteja fluindo os Projetos A e B. No momento do bloqueio do Projeto A, o time pode fluir, ou dar um g\u00e1s no Projeto B, reduzindo a press\u00e3o do fluxo para quando o Projeto A desbloquear, esse g\u00e1s no Projeto A seja poss\u00edvel. Voc\u00ea est\u00e1, no presente, liberando capacidade para o Projeto A no futuro. O cliente <\/span>n\u00e3o continua pagando<\/b> uma equipe inteira para encher lingui\u00e7a enquanto o projeto est\u00e1 bloqueado. O fato de continuar pagando vai aumentar a ansiedade do cliente, aumentar a press\u00e3o e pode fazer o sistema desandar. Esse “encher lingui\u00e7a” pode at\u00e9 gerar problemas de iatrogenia<\/strong><\/a>, que o Taleb tamb\u00e9m coloca muito bem e aqui nos alongar\u00edamos muito.<\/span><\/p>\n Outsourcing:<\/b> pode ser interno ou externo.<\/span><\/p>\n O cen\u00e1rio tradicional \u00e9 fr\u00e1gil<\/b>: tem medo de variabilidade, ele quer aus\u00eancia de impactos, at\u00e9 porque o planejamento inicial pede isso.<\/span><\/p>\n O cen\u00e1rio de fluxo unificado \u00e9 robusto<\/b>: ele n\u00e3o se importa com impactos, com varia\u00e7\u00e3o, porque \u00e9 muito barato remanejar o fluxo, mexendo na fila de entrada do sistema. Podemos mal associar essa flexibilidade dos times \u00e0 flexibilidade das m\u00e1quinas obtidas no TPS.<\/span><\/p>\n Mas perceba uma peculiaridade: se o Projeto B for um produto, o sistema estar\u00e1 antifr\u00e1gil: uma varia\u00e7\u00e3o de um stressor<\/em> no sistema deixa o sistema “empresa” mais forte, pois estar\u00edamos alocando capacidade ociosa para o produto, caminhando mais rapidamente para validar ou invalidar nossa hip\u00f3tese – produto ou partes do produto – <\/span>antifr\u00e1gil<\/b>.<\/span><\/p>\n Perceba tamb\u00e9m que se voc\u00ea j\u00e1 tem dois produtos no seu portf\u00f3lio, voc\u00ea provavelmente tem alguma vaz\u00e3o planejada para estes projetos, mesmo com times diferentes. Se o projeto B \u00e9 um produto, e estamos com times diferentes, o time do produto normalmente \u00e9 desfeito para inc\u00eandios ou aumento da vaz\u00e3o para os projetos que significam ganho financeiro no curto prazo – sobreviv\u00eancia.<\/span><\/p>\n Como o time est\u00e1 acostumado \u00e0 vaz\u00e3o dos projetos A e B, mesmo que tenha come\u00e7ado com uma propor\u00e7\u00e3o de 90% para o projeto A e 10% para o B, o custo de coordena\u00e7\u00e3o e transa\u00e7\u00e3o para aumentar a vaz\u00e3o do projeto B \u00e9 estupidamente baixo.<\/span><\/p>\n Imagine agora que, mesmo sendo uma empresa 100% de produto e que haja mais de um produto no portf\u00f3lio. Imagine que seja uma empresa de um produto, mas essa divis\u00e3o de projetos passe a ser divis\u00e3o de m\u00f3dulos. \u00c9 comum em empresas que s\u00e3o 100% um produto tenha uma divis\u00e3o de times por m\u00f3dulos ou por frentes.<\/span><\/p>\n \u00c9 claro que existem os downsides<\/em> e para isso indico a <\/span>s\u00e9rie de artigos<\/a><\/strong> que fizemos na <\/span>Crafters<\/a><\/strong> e o <\/span>ebook<\/a><\/strong> que fizemos na <\/span>Taller<\/a><\/strong>.<\/span><\/p>\n O Value Crafting Cycle<\/em>, criado por mim, Felipe Rodrigues e Rafael C\u00e1ceres cai como uma luva para a defini\u00e7\u00e3o inteligente desta propor\u00e7\u00e3o de vaz\u00e3o.<\/span><\/p>\n Teoria das filas + aspectos econ\u00f4micos das filas. Simples assim. =)<\/span><\/p>\n 8) Algumas empresas buscam uma vis\u00e3o de entrega de releases de 3 ou 6 meses. Algumas at\u00e9 mais. H\u00e1 problemas neste exerc\u00edcio sobre o futuro ou ele pode ajudar em algum sentido?<\/b><\/p>\n R: Se n\u00e3o for um contrato assinado \u00e0 sangue e se n\u00e3o remeterem as causas de um projeto que falhou a este planejamento, n\u00e3o vejo muitos problemas. Neste caso, minha opini\u00e3o \u00e9 que os planejamentos para per\u00edodos de tempo maiores \u00e9 no m\u00e1ximo in\u00f3cuo. Este tipo de atitude nos coloca mentalmente contra as varia\u00e7\u00f5es e se houver a disciplina de que as varia\u00e7\u00f5es podem ser boas e de que o plano pode ser ajustado de acordo com elas, n\u00e3o vejo problema. S\u00f3 me parece in\u00fatil e o tempo desperdi\u00e7ado nessa inutilidade seria um downside<\/em>.<\/span><\/p>\n\n