Existem diversos fatores que julgo influenciarem esse tipo de perfil: escassez de pessoas qualificadas, ofertas de trabalho em abundância, prostituição do mercado de trabalho, políticas falidas de recursos humanos, entre outros. Dependendo da nossa posição, poucos desses fatores são de nosso controle.

No entanto, nos últimos dias passei por uma experiência interessante e percebi que existe um ponto em especial que podemos controlar plenamente ou contribuir para evitar esse tipo de comportamento desinteressado: boas práticas de engenharia de software.

É impressionante como encorajar a aplicação de boas práticas de desenvolvimento de software pode transformar pessoas antes desinteressadas novamente em profissionais ativos e entusiasmados. Não é necessário ter as melhores ferramentas, utilizar a última tecnologia da moda ou o melhor processo de desenvolvimento. Na maioria das vezes basta que o líder incentive e apoie esse tipo de comportamento para obter bons resultados.

Mesmo que você não seja líder de equipe e que algumas pessoas o desencoragem com aquele papo de “não adianta tentar fazer X oy Y porque aqui isso não vai funcionar”, não entre nessa onda. Procure incentivar as pessoas que estão ao seu redor a buscar a melhoria contínua e mesmo que todos não te ouçam não desista. Existem muitas empresas que valorizam profissionais com perfil arrojado e pró ativo.

Valorize-se!

Se você não é uma dessas pessoas que apenas empurra seu trabalho com a barriga, existem algumas coisas que você pode fazer para ter mais chances de ser bem sucedido durante sua carreira profissional.

Não são raras as vezes em que trabalhamos em uma empresa grande e não passamos de um número. Essa é uma situação relativamente ruim e pessoas ambiciosas (no bom sentido da palavra se é que tem um ruim) não se sentem confortáveis nessa posição. No entanto, ganhar visibilidade no meio de tanta gente não é uma coisa muito fácil e pode demorar muito tempo. E não é só questão de visibilidade, mas também de procurar um sentido para aquilo que você se dedica diariamente. Dependendo do tamanho da empresa e da posição as vezes não temos condições nem de dizer o que realmente a empresa faz.

Uma das formas de ganhar visibilidade e reconhecimento dentro da empresa é fazer alguma coisa que impacte positivamente no resultado da empresa dela. Seja esse resultado financeiro, operacional ou de qualquer outro tipo.

O problema é que é muito complicado, como um mero desenvolvedor em uma grande organização, fazer alguma coisa sozinho que faça esse tipo de diferença.

“Como vou fazer isso?”

Geralmente toda equipe de desenvolvimento tem um gerente (independentemente de ser um gerente tradicional ou não) ou algum tipo de chefe. Esse gerente tem problemas ou objetivos a cumprir e se utiliza de sua equipe (se não utiliza, deveria) para resolve-los. Em uma empresa organizada, esse problema que ele tem que resolver deve estar alinhado com os objetivos da empresa. Sendo assim, como membro do time de desenvolvimento, você deve descobrir qual o problema que seu time deve resolver e trabalhar o máximo que puder para resolve-lo ou pelo menos ajudar seu time a faze-lo. Dessa maneira você estará ajudando seu time e de brinde seu gerente, pois o problema que ele tinha já não exisitirá mais.

Nesse momento, somente pelo fato de trabalhar pela equipe e cumprir um objetivo que não é pessoal, você já deve se sentir bem.

Se seu gerente também estiver alinhado com esse pensamento e estiver tentando resolver o problema do chefe dele, com essa sucessão de acontecimentos você vai acabar resolvendo ou contribuindo para a solução do problema do chefe do seu chefe. E assim a coisa vai até o topo da empresa…

“Mas ai meu gerente vai pegar todo meu crédito? Nem a pau!”

É, podemos dizer que ele irá, mas esse é o trabalho dele. Como gerente, ele deve utilizar-se das pessoas corretas (uma dessas pessoas é você) nos lugares corretos para atingir um objetivo. Quando você menos esperar, você estará contribuindo para um movimento que provavelmente fará a diferença no resultado da empresa. Dessa forma, seu chefe será reconhecido e conforme as coisas forem avançando isso irá refletir em você também.

Não podemos esquecer, que acima de tudo, estamos trabalhando para uma empresa. Essa empresa tem objetivos a serem cumpridos. É muito fácil falar que devemos estar alinhados com esses objetivos. Difícil é realmente estar alinhado, mas faz parte do nosso trabalho tentar.

Se a organização conseguir passar esses objetivos para seus funcionarios e estes se comprometerem realmente para com a equipe inevitavelmente todos irão ganhar. Espirito de equipe é fundamental!

O engraçado foi que, na metade da prova, eu tinha certeza que já tinha reprovado. A prova tem duração de 3 horas e 40 questões. Em menos de 30 minutos estava prontinha!

O fato de achar que tinha reprovado não foi porque não estudei (eu não estudei mesmo), mas sim pelo fato da prova não cobrar nada que seja realmente útil ou do dia-a-dia. Fiquei decepcionado com o conteúdo da prova. Foram muitas questões a respeito de COM+ que na minha opinião já não tem mais nada a ver com a atualidade da plataforma e várias questões também sobre aspectos de segurança que eu particularmente nunca usei e acredito que nunca vou usar.

Eu nunca valorizei muito certificações, principalmente Microsoft que até pouco tempo atrás era bem mais fraca, e por isso demorei tanto tempo pra tirar a primeira. Hoje, no nível atual das certificações que já incluem WCF, WWF e WPF acho que começa a ser interessante e valer a pena, pelo menos pela realização pessoal.

Mesmo assim, certificação na minha opinião serve mais como um mecanismo pessoal que diz que o sujeito se interessou e deu-se o trabalho de estudar e fazer as provas do que como um mecanismo de avaliação técnica.

Quem quiser fazer sua prova, pode aproveitar o second shot que ainda está valendo.

Brincadeira! Mas de fato, em uma conversa ontem com a patroa descobri que as mulheres (pelo menos ela) tem mais facilidade pra entender alguns principios da agilidade do que muitos homens.

Estavamos conversando sobre nossos trabalhos (ela trabalha com logística/compras) e caimos no papo de projetos em geral e no porque especifíco da maioria dos projetos de software falharem. Expliquei pra ela que um dos motivos é a utilização de modelos em cascata onde em um projeto de 12 meses o fornecedor fica 4 meses junto com o cliente no início do projeto e só da as caras novamente 8 meses depois com um software (ou parte dele apenas) fresquinho funcionando.

Foi incrível que no momento que terminei de explicar o processo em cascata e ia começar a falar a respeito de agilidade ela me interrompeu (ela não sabe nada de software) e traçou um paralelo MUITO legítimo que serve como um ótimo exemplo da aplicabilidade de métodos agéis. Explico:

No tempo livre ela pratica dança do ventre e, esse ano junto com seu grupo de dança, ela participou de duas apresentações abertas ao público. Para isso, o grupo teve que encomendar roupas sob medida e combinando até certo ponto entre si. Foi ai que os problemas começaram. Apesar de seguirem um modelo básico -como quando construimos softwares diferentes para o mesmo seguimento de empresas- cada roupa tinha suas peculiaridades -assim como as regras de negócio especifícas de cada empresa-. Ela passou as necessidades de sua roupa pra professora do grupo -podemos chamá-la de analista de negócios- e essa por sua vez especificou para as costureiras da empresa fornecedora -os programadores!- como o cliente queria a roupa. Conversaram uma ou duas vezes na primeira semana e depois de aproximadamente 3 meses a roupa estava pronta e perfeita!

Será que estava mesmo?

É claro que NÃOOOOOOOOOOOOOOOOOOOOOOOOO!

(Até então eu imaginava que processos em cascata falhassem só em projetos de software, mas pelo jeito parece que não)

Já com a roupa nas mãos e p*** da vida por ter gasto uma grana preta com a roupa (acreditem, custa caro) que apesar de seguir um esqueleto básico e padronizado não estava nem perto de estar pronta (tamanho, cores e acessórios errados) ela entrou em contato com o fornecedor. Apesar dos problemas ela imaginou que seria possível consertar a roupa a tempo da apresentação que iria acontecer em 1 mês. No entanto, ao final desse mês e no dia da apresentação a roupa tinha sido consertada, mas ainda estava cheia de problemas -assim como as milhares de não conformidades de software feitos por esse processo-. O jeito foi se apresentar do jeito que estava (meia boca) -ida a produção!- e ainda hoje (6 meses depois) ela ainda esta brigando com as costureiras pra ter a roupa 100%.

O mais interessante é que depois de me contar essa história, ela mesmo conseguiu chegar a solução mais óbvia (que ainda não entra na cabeça da maioria das pessoas no nosso mercado de software) que havia pra evitar ou diminuir os problemas com a roupa: provar semanalmente a roupa junto com as costureiras ao invés de ver apenas o resultado final depois de um tempão. Ou seja, abstraindo um pouco mais temos: ITERATIVIDADE, PARTICIPAÇÂO DO CLIENTE, ACOMPANHAMENTO FREQUENTE e muitos outros príncipios da agilidade.

A idéia dessa analogia que nem saiu da minha cabeça não é mostrar que é possível fazer roupas com metodologias agéis, mas sim o quão prejudicial é desenvolver software sob medida de forma cascateira. Ser ágil, ou ao menos iterativo é muito fácil e os benefícios são claros.

Ultimamente tenho conversado bastante com pessoal da área comercial e todos confirmam o que nós consultores já sabemos: os clientes estão cansados de perder dinheiro com projeto de software! Acredito que agilidade ainda não é uma coisa mais bem aceita e padronizada no Brasil porque a maioria dos clientes compradores de software ainda não sabem que uma alternativa a processos cascata e escopo fechado existe.

Sendo assim, por meio desta analogia das roupas ou por esta outra do Alexandre Magno ou ainda com esta do Vinicius da Improve IT nosso papel é evangelizar os clientes e promover métodos agéis, pois somente desta forma essa bagunça que é nosso mercado hoje vai mudar!

Na realidade, eu não gosto muito do título, pois por toda minha vida profissional (que não é tããããão longa assim) eu acreditei que esse cara era o guru da sapiência e que ele nunca ficaria sem respostas a qualquer pergunta que fosse feita. Então, soa como uma responsabilidade muitooooo grande (e é mesmo) pra um desenvolvedor de apenas 21 anos como eu. De fato, deveria ser assim, mas é humanamente impossível ser ao mesmo tempo generalista e especialista em todas as áreas. Isso me frustrou um pouco, mas ao mesmo tempo, por outro lado abriu minha cabeça e me fez reconhecer que existem diversos tipos de arquitetos, cada um na sua. E que existem pessoas, mesmo sem carregar o título, que também fazem arquitetura em um momento ou outro de um projeto. É baseado em conhecimento próprio e utilizando o conhecimento dos membros da equipe que o arquiteto deve trabalhar.

Inicialmente, dentro da área de software (imaginando que infra-estrutura não exista) eu identifico dois principais arquitetos: Arquiteto de Soluções ou Corporativo e Arquiteto de Sistemas. O primeiro deles define quais tecnologias, metodologias e ambientes serão utilizados para os sistemas da empresa e procura manter todos os sistemas seguindo essas linhas agindo de forma incisiva nas fronteiras entre implementação e processos de negócio sem dar muita atenção nos detalhes técnicos de cada sistema.

Já o segundo, que é onde eu me encaixo por trabalhar em consultoria atendendo a diversos clientes, é o cara que dado um projeto deve atuar em todas as etapas da construção do sistema. Desde levantamentos inicias, passando por implementação e até roll-out em produção. Além das habilidades técnicas que são imprescendiveis nesse papel e isso ninguém pode negar, o arquiteto deve ser um cara balanceado pra atuar como um mediador entre todos os stakeholders do projeto. Em um projeto com papéis bem definidos, a tendência é que cada um cuide das apenas das suas responsabilidades. Isso é bom, pois cada especialista atua onde mais conhece, mas se não houver cuidado, pode fazer com que os principios inicialmente definidos não sejam seguidos. É ai onde o arquiteto deve entrar pra fazer com que todas as diretivas sejam seguidas. Isso exige liderança, habilidades em negociação e muitas vezes pulso forte pra suportar caras feias que aparecem quando uma decisão não agrada a todos.

No âmbito técnico, além de definir um modelo a ser seguido para implementação, ele deve atuar junto a equipe de análise nas etapas de modelagem a fim de entender do negócio para que seja possível escolher as tecnologias que melhor se encaixam no domínio de negócio. Uma vez modelado o domínio de negócio e tendo as tecnologias definidas, ele deve atuar junto a equipe de desenvolvimento guiando a implementação e removendo possíveis roadblocks. Sempre que houver um conflito técnico, ele deve atuar em prol do projeto para decidir a questão independente de chateação ou não por parte dos membros da equipe.

E pra finalizar, deve conhecer metodologia e processos de desenvolvimento a fim de tornar o planejamento e execução dos projetos mais baratos e acertivos.

Dava pra ficar enumerando a respeito das skills e habilidades que um arquiteto deve ter, mas em resumo acho que isso é o principal. O importante é ter em mente que não importa o quanto estudemos nunca vamos chegar no que eu imaginava que existia: arquitetos-sabe-tudo.

Ao longo dos dias vou procurar postar entries nessa categoria pra ir complementando os pensamentos e ai, quem sabe um dia, eu formato tudo num grande apinhado de informações! ehehehe…

Soçarba