Archive for the 'innovation management' Category

the buck stops here!

Thursday, August 10th, 2006

pense que você está numa empresa de software. processos ágeis de desenvolvimento [ao contrário dos métodos “antigos” e “pesados” que você conhecia -e era obrigado a usar] estão sendo instalados no lugar. e, alguma hora, é hora das “lideranças executivas” assumirem o papel de liderar o processo de introdução e institucionalização de alguma coisa que, por definição, precisa de muito menos “liderança” do que o passado [passou mesmo?…] do seu negócio costumava precisar… e aí? [processos ágeis de desenvolvimento de software são, claro, um mero exemplo; poderia ser uma nova forma de administrar o tempo, uma outra organização societária, uma nova estratégia de vendas… o que fosse].

brian marick esteve na agile 2006 e tá meio [muito] descontente com as tendências que, segundo ele, estão aparecendo na conferência [e no movimento “ágil”] de trazer as tais “lideranças executivas” pra “liderar” o processo… marick acha que trazer os “grandes homens” [teoria apoiada por alguns, segundo a qual as grandes mudanças sociais, econômicas, empresarias… são efetuadas por “grandes” homens… o que implica na necessidade de “heróis” como vetores essencias da mudança] é… “part of the domestication of Agile: the fitting of something potentially disruptive into the comfortable patterns of life“… parte do processo de “domesticação” dos processos ágeis, uma inovação potencialmente de ruptura, de forma a fazê-los caber na organização e estrutura corporativas. ainda segundo marick [no caso de software, pelo menos]… “We know how to do software better. It’s the executive’s job to support us in doing that-to clear obstacles out of the way of our practice-and not to lead us. We already know where to go. We know how to do our job. We need to be assisted, not led.”… nós sabemos como melhor fazer nosso trabalho. o trabalho [por outro lado dos executivos] é nos apoiar, criar as condições para que melhor façamos nosso trabalho… e não nos liderar. nós sabemos onde queremos ir. nós precisamos de apoio, e não de liderança.

as forças armadas americanas estão seriamente considerando um conjunto de mudanças destinadas a transferir o poder para as bordas, para as pontas. a idéia básica é a mesma de marick: ao invés de líderes, de heróis para nos dizer para onde estamos [ou deveríamos estar] indo, precisamos de pontos de apoio para suportar a carga, conosco e para nós, do que nós sabemos que tem que ser feito. ora pois, agile & mission oriented management no exército?… que coisa, hem?

a pergunta da hora é: sabemos mesmo o que tem que ser feito? quantos de nós, em uma instituição de 1.000 pessoas, sabem e estão em condições de exercer seus saberes, direitos e deveres, correndo os riscos que podem [veja bem, podem] nos levar aos resultados que, por um tempo, serão nosso nirvana [empresarial e, quiçá, pessoal]? é muito fácil, sob várias óticas, reclamar que não há espaço na instituição, que os gerentes tolhem nosso desenvolvimento profissional [e pessoal], que vendas não vende o que deveria estar vendendo, que a gestão não sabe pra onde o negócio está indo. é muito mais complexo, no entanto, participar integralmente do ciclo de vida da instituição, se capacitando continuamente para os processos inevitáveis de evolução insttiucional [uma boa parte dos quais é forçado pelo mercado!] e assumindo seus pontos de vista e suas diferenças de ponto de vista em relação ao que o resto da instituição pensa. a ponto, claro, de mudar o que ela pensa… e faz.

durante algum tempo, num passado distante, fui assessor da secretaria de política de informático do ministério de ciência e tecnologia. o secretário era ivan moura campos. na época, tanto quanto hoje, altos executivos do governo federal tinham por mania de falar do governo na terceira pessoa… frases típicas: “nós, aqui, defendemos x, y, z… o governo tem outras prioridades”… ditas por indivíduos que eram institucionalmente responsáveis por x, y, z e mais algumas variáveis. ivan tinha uma política [e aprendi com ele] resumida por the buck stops here. harry truman, presidente dos eua, tinha a inscrição sobre sua mesa na casa branca e o significado era [e é] inequívoco: truman não transferia para ninguém as responsabilidades sobre forma, métodos e processos com os quais os eua eram administrados durante sua gestão. nem ivan. nem eu, daí por diante. nem você, de hoje em diante. seja lá o que estiver rolando na sua periferia, se você está sendo verdadeiro no que faz, tudo é problema seu. não há nenhuma possibilidade de alguém -seja lá quem for, ou em que nível estiver-, em alguma empresa, falar sobre seu local de trabalho, sua empresa, na terceira pessoa [”isso não é comigo”…] sem estar fugindo dos problemas reais do seu negócio, seja por que for.

eu concordo com marick: transferir as responsabilidades de mudança para os “líderes” é deixar prá lá. é fugir do compromisso com as mudaças. é entregar o futuro aos heróis. e a história não é feita por eles: pode até ser escrita em função deles, face à complexidade de descrever processos de mudança, sempre muito complexos, em função de todo o fluxo de transações, no tempo, e às vezes por muito tempo, que as mudanças de verdade envolvem. mas não é só: se as bases precisam se ver como essenciais aos processos institucionais [e, conseqüentemente, no topo de tudo]… ao mesmo tempo, os líderes precisam se ver como servidores: eles são a base sobre a qual se sustentam os processos institucionais, principalmente os de mudança, de inovação, aqueles que representam maior risco, maior possibilidade de fracasso. ninguém precisa de líderes para tempos de bonança; precisamos de bases, de referência, de suporte para tempos de crise. aliás, hoje, em empresas de tecnologias de informação e comunicação, todos os tempos são de crise, dada a velocidade das mudanças, sobre seu negócio, forçadas pelo mercado… normalmente [graças!] fora de seu controle…

resumo da ópera: sua instituição está [sempre] mudando. você faz parte disso. a menos que não queira. se não quiser, prepare-se pra mudar mesmo assim: breve, o lugar em que você trabalhava terá mudado tanto que não mais espelhará o que você faz, ou iria querer fazer. logo… melhor fazer parte da mudança mesmo: desde o comecinho!


Technorati : ,
Del.icio.us :
43 Things :

inovação colaborativa, engenharia e brasil

Wednesday, July 19th, 2006

uns meses atrás escrevi, para a cni, um texto de suporte a um trabalho da confederação sobre engenharia no brasil e a necessidade de [nas universidades e centros de pesquisa] tratarmos os problemas de pesquisa, desenvolvimento e inovação dentro de uma agenda e escopos coordenados e de maneira colaborativa [entre nós e com a indústria], como uma das únicas chances de darmos alguns dos saltos de que precisamos para competir internacionalmente com algo mais do que grãos e carne. o texto começa assim…

As mudanças na economia mundial, com aberturas em vários níveis criando novas oportunidades de redesenho das cadeias de valor das indústrias e dos serviços, vem exercendo uma pressão cada vez mais intensa nos sistemas nacionais [e locais] de inovação, de mais de uma forma instados a exercer um papel mais próximo do mercado e em tempos cada vez mais estritos. Ao mesmo tempo, quando o papel das organizações de negócio passa a ser o de “resolver” o problema de seus clientes e usuários, e não o de oferecer uma “solução” específica para alguma parte de suas preocupações, cresce a importância das combinações multi-disciplinares e paradigmáticas para servir como base para o processo de inovação. É neste contexto que se situa, hoje, a relação entre a pesquisa colaborativa [nas instituições de ensino e pesquisa] e o mundo real dos negócios [e sua permanente demanda por inovação].

a íntegra da [minha] contribuição pode ser lida aqui… e o documento integral da cni está aqui. boa leitura…

cooperativas e f/l/oss-d

Tuesday, July 18th, 2006

um grupo de pessoas que desenvolve software aberto [f/l/oss = free/libre/open source software] é, quase que por definição, um grupo [!] e não uma empresa. há empresas que desenvolvem software livre [mas, às vezes, de forma pouco aberta] e há umas poucas que participam, de forma muito aberta, de processos de desenvolvimento de f/l/oss.

agora imagine que uma empresa ou um pedaço do governo vai fazer uma licitação para desenvolver software. e que um dos grupos capacitados para desenvolver a solução que o cliente quer [e pela qual quer pagar] é um grupo de pessoas ligadas a um projeto f/l/oss. um grupo, apenas. grupos normalmente não têm vendedores, marcas… mas têm qualificação e reputação. não têm estruturas corporativas e hierarquias, mas têm processos e métodos. não têm um CGC para entrar na licitação, mas podem ter muito mais competência do que boa parte dos cgcs que já ganharam um contrato parecido.

mas a empresa que está comprando o serviço não vai dar um contrato para desenvolver o software a um grupo de pessoas, pura e simplesmente, pois o estabelecimento de tal relação comercial é muito difícil. é quase impossível se o contratante for o .gov.br. quem seria processado se der tudo errado? uma pessoa física que mora fora do brasil, no nosso caso?…

o último resilience report da booz-allen-hamilton é sobre corporações auto-governadas, ou corporativas, e o exemplo primeiro é sobre um banco, o rabobank holandes, um gigante de mais de 100 anos que administra mais de 500 bilhões de dólares e vai muito bem obrigado. um banco onde os clientes das agências [bancos locais] se reunem pra discutir pra onde o banco, como um todo, vai. talvez a gente devesse tentar fazer algo parecido para software, no brasil, em escala. seria uma forma de criar um ente corporativo capaz de competir por contratos no mercado [e com as devidas responsabilidades legais] ao mesmo tempo em que poderia ser uma forma eficaz de organização empresarial [uma coop é uma empresa] e uma maneira legítima de passar ao largo do medievalismo [e dos custos] do sistema trabalhista brasileiro.

o resilience report sobre cooperativas pode servir de partida pra um estudo aprofundado sobre o assunto. e há exemplos locais a estudar e imitar, como a solis [veja entrevista de cesar brod sobre o tema], que tem 3 anos de vida e parece estar indo muito bem. associativismo e software aberto têm muito a ver; cooperativismo, equipes distribuídas [com processos e métodos de qualidade] pelo mundo podem ter muito a ver e a fazer, também. e podem ser itens essenciais de uma competitividade internacional que não estamos conseguindo desenvolver, por enquanto, por aqui.

ozzie who?…

Saturday, June 17th, 2006

olhando pra nota anterior, talvez você não saiba quem é o cara [ray ozzie] que vai assumir o espaço de bill gates como chief architect da microsoft. pois tá’qui uma excelente análise dele, e da situação da msft, feita por smartmoney… que acha que ele tem uma boa chance de fazer com que uma microsoft 2.0 tenha o mesmo brilho que a companhia teve nos seus dias de glória…

kill bill?

Thursday, June 15th, 2006

bill gates anuncia que começa a deixar a microsoft; o plano de transição de dois anos entra no ar já; ray ozzie assume imediatamente como chief software architect e craig mundie é o novo chief of research & strategy. e não é primeiro de abril… deve ser por isso [e outras] que ozzie não tem tempo pra atualizar seu blog desde o… primeiro de abril. steve ballmer continua como ceo. o anúncio causou uma leve subida nas ações da microsoft [0.9%], que estão levando pancada em wall street desde o fim de abril, quando a companhia anunciou que iria usar vários bilhões de dólares[a mais] do lucro para radicalizar o combate a google, yahoo, amazon e e-bay. problemas de incumbente: o quase monopólio da microsoft tem um preço, pago em lealdade a seus antigos [às vezes muito antigos] clientes. a companhia não pode simplesmente mandar todo mundo trocar windows xp por um “beta qualquer”. não dá. simplesmente não dá. o que significa custos de arrasto muito grandes… uma espécie de custo de “ser” uma microsoft.

gates sempre teve competência [e sorte] em fazer algo que poucos dirigentes conseguem: elicitar [dos ditos e não ditos do mercado] uma estratégia emergente para a microsoft, permitindo que a empresa, gastando alguns poucos bilhões de seu caixa, sempre chegasse à frente dos adversários, mesmo saindo muito depois. no caso de vários deles, causando inclusive a destruição do oponente e seu dna, para sempre. desta vez [sempre há um desta vez…] a maioria dos analistas concorda que a microsoft tem problemas demais e que o número de frentes de competição é tão grande que o controle [maior ou menor, mais maior do que menor] de centro [e de gates?] sobre o resto da companhia tem afetado seriamente sua capacidade de, senão antecipar tendências, pelo menos segui-las tão rapidamente como no passado. ballmer, ao timão, avisa que “só precisa de 5 anos” e alguns bilhões [a mais] por ano para chegar nos lugares e nas marcens de lucro onde hoje está a concorrência. os acionistas aguardam, algo impacientes. o caixa está lá, os técnicos estão lá, o ânimo parece estar lá… só falta o mercado esperar…

se eu estivesse na foto [na foto acima, de hoje, em redmond: gates, mundie, ozzie, ballmer]: transformaria a microsoft numa holding, separaria o que hoje são meras divisões [e, em casos, produtos] em várias companhias [completamente] diferentes [e com dinâmicas idem] e partiria pra adquirir propriedade intelectual e, principalmente, gente, que estivesse construindo a web 2.0 -a informaticidade- de daqui a 5 anos. ballmer & co. não parecem acreditar que innovation happens elsewhere. mas numa companhia do tamanho da microsoft, é a pura verdade. aliás, é verdade numa companhia do tamanho de google, também. basta ver quanta coisa [ruim, boa e mais ou menos] eles compraram recentemente. mas eu não estou na foto; nem scoble, by the way, está mais. quanto mais eu, que nunca estive…


acabou a lua de mel. e agora?

Sunday, May 28th, 2006

guy kawasaki, um dos caras mais espertos do mercado de negócios digitais, acaba de escrever um texto imperdível para quem está começando um negócio. o título do original em inglês [after the honeymoon] já diz tudo. você se juntou com gente muito massa, têm todos “grande” capacidade de trabalho e de trabalhar juntos, um conjunto de idéias de fazer einstein corar, arranjaram gente pra botar dinheiro no negócio e tudo ia muito bem… até vocês terem que mostrar serviço. kawasaki elenca nove formas de dar errado logo na partida [já passei por todas em mais de um start-up] e, sinteticamente, dá uma idéia de como a situação chegou onde está e o que fazer dado que o ventilador não está muito limpo…


cada um dos itens escolhidos por kawasaki já deve ter acontecido, pelo menos uma vez, em quase todos os start-ups do mundo, especialmente nos de tecnologia. vale a pena ler o texto inteiro e pensar muito no que, dele, se aplica ao seu negócio, mesmo que você não seja exatamente um startup no sentido temporal do termo. no brasil, aliás, a maioria das empresas de tecnologia fica durante anos num estágio pré-startup de suas vidas, sem meios, coragem, ou os dois ao mesmo tempo, de sair da casca do ovo e enfrentar as duras realidades de mercado, que envolve responder perguntas [que estão lá, no texto] como… por que meu sócio não faz sua parte [e o que devo fazer com ele]?… por que não estamos conseguindo vender [e porque a “culpa” não é do mercado… “que não está preparado pra nós”]?… por que meu investidor não ajuda mais [e/ou se mete tanto no “meu negócio”]?…

faça a si próprio, ou a seu negócio [às pessoas que estão nele] as perguntas de kawasaki… veja o que se aplica e o que tem conserto, se tiver. se muita coisa não tiver jeito [e/ou você achar que não tem], das duas uma: combine com todos os seus sócios uma providencial falência e, se houver astral, um começar de novo. ou então, se nem pra isso houver clima, bata em retirada, pra não perder os amigos. talvez, num outro negócio [ou, dependendo das razões do desastre atual, numa outra vida] vocês estejam juntos novamente.

e depois não digam que eu não avisei…

o fim do mundo [como ele é]

Sunday, April 2nd, 2006

a ibm andou ouvindo 765 altos executivos de grandes empresas pelo mundo inteiro e 65% deles está planejando mudanças radicais nos seus negócios, para fazer face a pressões da competição e demandas do mercado. o rolo é que mais de 80% destes mesmos senhores acha que suas organizações não fizeram bonito, no passado, quando o assunto era mudança, seu planejamento e implementação.

mudança na escala prevista é inovação em grande escala; o mercado inteiro corre o risco de mudar… perguntados sobre como melhor inovar, a resposta de 76% aponta colaboração e parceria como a melhor forma, mas apenas 52% dos CEOs acredita que suas empresas estão colaborando acima de um nível classificado como “moderado”. ou seja, o risco de muita coisa dar errado é muito grande e muitos de nós, que estamos na periferia desta confusão que começa a se aprontar no horizonte, vamos ser atingidos. melhor botar as barbas [e em muitos casos, o emprego] de molho…

resumo da ópera: mudança não é exceção, é regra. acabou-se o tempo em que podíamos viver acomodados, esperando a aposentadoria. melhor nos prepararmos, lendo este texto sobre “business tsunamis”, este outro sobre o equilíbrio entre risco e recompensa, este aqui sobre como escrever a história de futuros corporativos e|ou [como introdução ou aviso, se não houver muito tempo] um curto, simples, de tony hodgson, sobre strategic thinking with scenarios. ah, sim: continuando a conversa do post anterior, sua empresa está se preparando pra um tsunami destes?…

aversão a risco = morte certa

Thursday, March 30th, 2006

todo mundo que pretende ter, ou tem, usuários deveria passar vez por outra em creating passionate users, onde se escreve sobre… como criar usuários que amam seu produto e|ou serviço. um dos textos mais interessantes dos últimos tempos, lá, é sobre o assunto do título, ou como idéias absolutamente geniais, que poderiam transformar vidas de usuários e até criar novas categorias [como skype, por exemplo] acabam se encontrando, ainda jovens, com uma intensa aversão a risco, quase sempre por parte dos níveis gerenciais do lugar onde a idéia ocorre, e se transformam em [bleargh!] uma gosma disforme que, para quer quer que olhe, nem fede, nem cheira.

o blog cita exemplos e pergunta… “…can anything be done about all the spirit-squashing risk-aversion?” a resposta vem, imediata, e eu concordo com ela desde sempre: “Recognition is the first step. Unfortunately, those who recognize it tend to be the leaf nodes–the ones with the power to create and implement the ideas, but very little power to authorize them. Those with the most potential to create change are the branches. The Managers With a Clue.”  um negócio, certamente um negócio de tecnologia de informação, que não tenha e|ou não consiga ser guiado pelos seus gerentes-com-alguma-coisa-na-cabeça está fadado a um triste fim.

e o principal papel destes troncos da árvore empresarial, associados às folhas, onde vive [a engenharia e] normalmente a genialidade e capacidade de implementação, é evitar o pantanoso terreno do mais ou menos. uma companhia que se preza faz dois tipos de produtos: um que os usuários amam e outro que eles odeiam. profundamente.  pra fazer os que ficam no tanto-faz-tanto-fez é melhor desistir e abrir uma pousada. a figura abaixo é a perfeita tradução do conceito de tudo-ou-nada, quando se fala em inovação…

o texto é longo, mas vale a pena ler; passando de raspão por princípios budistas, acaba em um pequeno manual que há de servir pelo menos para você confrontar seu gerente [pergunte se ele leu!…], para decidir entrar numa campanha para mudar sua empresa [se você achar que é possível] ou então [no pior, ou no melhor caso]… procurar outro lugar pra trabalhar.

The Development of Science-Based Products: Managing by Design Spaces

Thursday, March 2nd, 2006

o título é de um paper de Armand Hatchuel, Pascal Le Masson, Benoit Weil, publicado na Creativity and Innovation Management, uma revista arretada, em dezembro de 2005. os autores usam -muito bem- o conceito de design spaces para mostrar como as diferentes componentes do processo de desenvolvimento de produtos baseado em resultados científicos [exploração de um espaço funcional, produção dos resultados científicos relacionados, e administração do projeto] podem ser conciliadas, ao contrário do que normalmente se pensa. interessante… e pode ser muito relevante se os casos mostrados forem mesmo exemplares… link para o paper [gratis]: