Slide 10 - Sintetize ao invés de otimizar

Esta é a forma pela qual Takeuchi e Nonaka diagramaram isto. Segundo eles, há pessoas que se focam na economia da velocidade e neste cenário dizem: “desconecte tudo, compre alguns alicates, junte isto tudo construindo o mínimo que for possível e isto é realmente rápido”. Isto dá a você velocidade. Mas para realmente ter controle para conseguir uma economia de escala e de escopo você traz tudo debaixo de um guarda-chuva que você pode controlar com cuidado. Isso lhe dá uma velocidade muito menor mas também uma escala muito menor. O que Takeuchi e Nonaka estão dizendo é que você deve abandonar esta forma de pensar. Nós precisamos nos mover abaixo deste caminho fazendo o melhor que podemos até que percebamos que não estamos na direção correta. Então mudamos nossa direção e quando percebemos que estamos um pouco fora mudamos novamente. E nessa navegação, essencialmente através do espaço do projeto de software ou do espaço de projeto do próprio processo nós nos forçamos para a região além da qual poderíamos ter ido, a qual eles dão o nome de fronteira orgânica. E agora, aqui, obtemos mais de tudo. Talvez você não consiga ser tão veloz, talvez não escale tão bem, mas no total agrega mais valor ao cliente. E isso é realmente importante quando você está desenvolvendo um software.

Estive na semana passada na Bell South, uma empresa que tem um estilo de gestão bastante tradicional na área de telecomunicações. O maior problema deles é que leva muitos, muitos meses para ter um produto pronto e, quando eles entregam o produto os clientes dizem: “bem, as coisas mudaram e isto não é realmente o que queríamos”. Assim, eles estão construindo estes grandes contratos de milhões e milhões de dólares, construindo sistemas que têm milhões de linhas de código e quando eles terminam, estão com algo errado nas mãos. Então, eles têm que parar de fazer a coisa errada. É muito difícil acabar com isso. O que eles precisam entender quando estão construindo este contrato é que eles nunca irão executá-lo. A não ser que sejam estúpidos. Porque se eles o executarem, o cliente irá dizer a eles: “Isto não é o que queríamos! Isto aqui é o que queríamos.”

So, this is a way that Takeuchi and Nonaka diagrammed this. They say, you know, there are people who focus on the economy of speed and in their scenario they say “unbundle everything, buy up some pliers, plug it together and you build as little as possible and that is really fast”. That gives you speed. But to really get control, to get in an economy of scale and scope, then you bring everything under one umbrella you can carefully control it and then you get a lot less speed but you got a lot less scale. And what Takeuchi and Nonaka are saying is we need to abandon that way of thinking. We need to move down a path doing the best that we can until we see we are not going in the quite direction. Than we change our directions and then when we see -- “well that's a little off” -- and we change again. And this navigation, essentially through the design space of software or the design space of the process itself will push us out into the region beyond of what we could have gone, what they call the organic frontier. And now, here, you are getting more of everything. You are getting maybe not quite as fast, maybe not quite as scalable, but in total more value to the customer. And this is really important when you are building software.

I was just at Bell South last week, which has a very traditional large company management style in the telecom area. And their biggest problem is it takes them many, many months to get a product out and when they get the product out the customers says “well, things have changed and it is not what we really wanted at all”. So, they are building these big contracts for millions and millions of dollars, building these systems that have to have millions of lines of code and when they get to the end it is the wrong thing. So, they just have to stop doing the wrong thing. And it is very hard to stop. And what they need to understand when their building that contract, they need to understand that they will never build that. Unless they are foolish. Because if they build that, the customer will tell them “That is not that we wanted! This is what we wanted.” Ok?