sábado, 9 de junho de 2012

Você faz a diferença positiva?

Fazer a diferença positiva é ser o elemento que somado ao estado atual das coisas resulta em um estado diferente e melhor. Já se perguntou se você é este elemento que agrega valor e gera vantagem competitiva em sua organização?

Talvez o primeiro passo para isso seja realmente acreditar nesta possibilidade. Infelizmente alguns profissionais caem na armadilha do conformismo, e começam a pensar que não há mais espaço para inovação em suas organizações. 

Uma vez o comissário do Departamento de Patentes dos Estados Unidos disse que “tudo o que poderia ser inventado já havia sido inventado”. Segundo Gordon Dryden e Jeannete Vos, este comissário, Charles H. Duell, teria dito isso em 1899. Tem ideia da enormidade de coisas que foram inventadas depois disso?

Outra armadilha é ficar preso ao próprio mundo, e não conseguir perceber o que se passa em sua volta. É provável que você seja um profissional de TI, mas o que o impede de conhecer outros mundos, outras áreas, de se apropriar de outros conhecimentos?

É bom lembrar que o inventor do filme Kodachrome era um músico (Leopold Godowsky), o inventor da lâmina de barbear descartável era um vendedor de tampas de garrafa (King Camp Gillette), e o inventor do pneu era um cirurgião veterinário (John Boyd Dunlop). Combinar conhecimentos de TI com os das demais áreas da organização contribuirá para a construção de algo novo, que represente diferença positiva.

Não é necessário descobrir uma coisa totalmente nova, uma tecnologia inexistente, ou um processo absolutamente inovador, para fazer a diferença. Vale lembrar que com mais ou menos 20 notas musicas é possível criar milhões de músicas, e que quase tudo o que há escrito no planeta foi criado com apenas 26 letras. Gordon Dryden disse também que uma ideia nova é na verdade uma combinação diferente de elementos antigos.

Que tal olhar a sua volta e identificar problemas que precisam de solução? Mas cuidado, porque as vezes os problemas estão lá por tanto tempo que já nos acostumamos com eles. Eles nem parecem mais problemas. Quebre padrões e paradigmas e descubra a raiz, a causa dos sintomas. Este será o verdadeiro problema a resolver.

Estabeleça hipóteses e possíveis soluções.  Que mudanças poderiam resolver o problema? É preciso aplicar tecnologia? Nem sempre é preciso. Lembre, a tecnologia é um poderoso remédio, mas não tente usá-la para curar todos os males. Pense diferente, abra a mente. Os problemas são cada vez mais complexos, e as soluções tendem a combinar diversos remédios diferentes que atuam de maneira sinérgica.

Comece pensando, idealizando, sonhando. ‘Se você pode sonhar com algo, então pode fazê-lo’ (Walt Disney). Para se chegar a um estado diferente é preciso desafiar o estado atual. Para que uma ideia nova se estabeleça, é preciso desafiar as ideias já estabelecidas. Talvez imaginemos que não podemos mudar o estado das coisas na empresa porque ela é resistente a mudanças. Mas é possível que não consigamos isso porque nós somos resistentes a mudanças, e a mudança deve começar dentro de nós mesmos, para depois contagiar o outro.

Qualquer um pode fazer a diferença positiva em uma organização. Que tal se essa pessoa for você? Então, just do it.

terça-feira, 22 de maio de 2012

Software - Engenharia, Moda ou Arte?


Se você constrói software, então é engenheiro. Mas o engenheiro de software é um sujeito paradoxal, uma espécie de peixe voador, ou pássaro mergulhão. Nada contra estas espécies, mas o nome deles já é um contrassenso. Me lembra um pouco o engenheiro de software. A palavra "engenharia" nos remete a prédios, máquinas, aviões, navios e coisas assim, diria, um tanto 'hard'. Mas o nosso engenheiro constrói 'soft'.

É claro que, como engenheiro de software que sou, aprecio os benefícios possíveis a partir do exemplo das outras engenharias, como a medição de prazos e resultados, a capacidade de simulação e previsão, a gestão dos recursos, entre outros. Essas similaridades são interessantes e podem nos ajudar a avançar. Me preocupam mais, no entanto, as diferenças. Que diferenças? Ah, já vou dizendo.

Uma importante diferença tem a ver com as ferramentas que utilizamos. Neste aspecto a engenharia de software está mais para a Moda do que para a Engenharia. Engenheiros tendem a exigir elevadíssimo nível de confiabilidade de suas ferramentas e materiais, especialmente quando se trata de construções críticas. Já pensou como seria a construção de uma usina nuclear com uma ferramenta que o primo do engenheiro descobriu em uma viagem que fez à Tailândia, e que ele achou super legal? Ou a construção de um foguete com uma chapa metálica recém inventada, que é o maior sucesso na indústria de carros? Pode parecer absurda a ideia, mas muitas vezes é exatamente o que faz o engenheiro de software.

Ao passo que as outras engenharias utilizam ferramentas e materiais amplamente testados e aprovados em rigorosos e demorados testes, que as vezes duram anos, o engenheiro de software usa o Python porque é bom a beça. O Java porque todo mundo tá usando. O Asp.Net porque é sofisticado e dá status. O PHP porque é facilzinho. Ou seja, como eu disse, está mais para a Moda do que para a Engenharia. Não digo que estas tecnologias são ruins ou boas, digo que a decisão por uma delas é geralmente feita da maneira mais ametódica possível. Há ainda aqueles que tratam a tecnologia como religião (nasci nela e vou morrer nela) e outros como time de futebol (tô torcendo pra minha ser campeã).  E aí, pra esse último, vale tudo: camiseta, boné, xícara, tudo com o nome da tecnologia pela qual ele torce. Eu ficaria muito preocupado de contratar um engenheiro com esse comportamento, pois como saber se ele está escolhendo a tecnologia mais adequada ao meu projeto, ou se está escolhendo a sua "tecnologia do coração"?

Outra importante diferença está relacionada ao produto que o engenheiro de software entrega. Colocar um avião em produção ou uma ponte pra operar, sem os devidos testes, pode levar o engenheiro para a cadeia. Entre os testes estão as mais diversas técnicas, inclusive simulações, que não se deixam abalar pela sempre presente pressa do cliente. Já na área de software, é muito comum ver em produção um sistema que sequer passou por uma equipe de testes; foi testado pelo desenvolvedor mesmo (se é que foi). Alguns usuários já até se acostumam com os erros e inventam maneiras de conviver com eles. E o desenvolvedor geralmente fica irritando quando alguém reclama. As duas respostas mais comuns são: 1) Estranho... e 2) Na minha máquina tá funcionando.

O caro colega engenheiro de software, a esta altura, deve estar irritado. Calma, também sou engenheiro de software, e sei que não gostamos de ouvir críticas. Quando alguém fala mal de nossos métodos e sistemas chegamos perto de perder o controle. Nossos sistemas são como filhos para nós, e não queremos ouvir ninguém falando mal deles. Neste caso estamos mais para o mundo das Artes do que da Engenharia. Somos artistas genais, os outros é que não conseguem entender nossa obra.

Que tal nos aproximarmos das engenharias tradicionais, mais velhas e mais sábias? A academia tem grandes estudos, muito experimentos, que podem ser uma pista do caminho a tomar. Há métodos de testagem disponíveis, que devem melhorar significativamente a qualidade do produto que entregamos. E por fim, vamos ouvir mais e falar menos. Afinal, temos dois ouvidos, apenas uma boca, e o cliente sempre tem razão.