egomesbrandao, blog

Chego na empresa, ligo minha máquina e,  enquanto isso, pego um café, duplo. A injeção de cafeína vai ajudar a começar o dia. A equipe de interface gráfica no nordeste espera a conclusão do web service para finalizar o trabalho que eles deveriam ter feito no fim de semana. Sim, no fim de semana! O projeto atrasou, a equipe de marketing resolveu adicionar mais uma funcionalidade, além daquela outra adicionada na semana passada, e agora estamos atrasados… Bom, estamos atrasados  já tem… Um mês. Eu fico puto com isso, prefiro ter um filho veado que um filho cliente!
O VS.Net abre, sincronizo o código, trabalhei nele até as 22:00 da sexta-feira passada, mas vai saber se alguém mexeu em alguma coisa. No fim de semana pensando no meu problema, as idéias se encaixaram e guardei a solução. Tarefa simples, porém braçal, tudo o que é preciso para iniciar uma segunda-feira sem pensar muito, só codar. Vou alterar o código é… Meu, quem foi que fez check-out exclusivo nessa classe? Ah! O cara que está  atrasado… Fico puto com isso! Prefiro ter um filho veado que um filho programador que faz isso… Aliás, prefiro ter um filho veado que um filho que configura o TFS com check-out exclusivo.
OK, vamos adiante, preparar os dados que serão enviados para a UI. Não é complicado, dados cadastrais, interface móbile… Caramba, um saco de dados vem desse web service, o que vai deve estar definido na especificação… Que especificação? A única coisa parecida com uma é um e-mail em tom imperativo dizendo: implemente nova função, blá, blá, blá; nada que ajude realmente. Fico puto com isso, será que não é possível descrever direito a necessidade? Prefiro ter um filho veado que um filho gerente de produto.
Já são 10:45 da manhã, em quinze minutos reunião com arquiteto sobre o outro projeto que deveria ter começado, e começou;  é isso que diz o cronograma, mas esta em paralelo por causa desse. Meu, preciso dizer que preferia ter um filho veado que um filho gerente de projetos? Pausa pro café, antes da reunião.
O arquiteto chega, atrasado. Caramba, o que esses caras fazem? Reunião marcada pela exigência do processo, que a arquitetura seja envolvida no início para o levantamento de necessidades dos serviços disponíves. O arquiteto me pede pra levantar os dados, fazer uma planilha, buscar os serviços disponíveis, para que ele possa aprovar! Parece  que eles são aquelas crianças chatas que os amiguinhos não querem brincar junto e daí os pais criam regras para isso. Pô, prefiro ter um filho veado que um filho arquiteto corporativo! Se eu soubesse onde estão os serviços eu não teria marcado a reunião, ao invés do cara colaborar,  o cara quer burocratizar.
Hora do almoço. Aproveito para ler e-mails pessoais, dar uma navegada, já que nos acham incapazes de controlar o tempo de acesso a internet e por isso ela é bloqueada o dia todo, lógico é necessário controlar a produtividade, a atenção… Bom, o UOL e o Terra estão liberados o dia todo! Vai entender… Meu, prefiro ter um filho veado que um filho admin de rede.
Na fila do almoço o de sempre, aquela mulher que fica escolhendo a folha de alface, o pedaço de batata, põe uma, duas, três, quatro colheres muito pequenas de arroz… escolhe o pedaço do frango, lógico que ela  está batendo papo com a amiga na fila da frente, atrasando as duas, criando uma fila enorme. Nem vou falar nada…
Volto pro escritório, pego café, e vou fazer um teste do WS, rodo o código, … erro! O WS chama outro que está  com pau… Ligo pro dev, pergunto pra ele, e a resposta é “testei na minha máquina e mandei pro ambiente de homologação, mas não testei lá”, meu… calma… Verifico o ambiente e vejo que ele esqueceu de subir os arquivos XML de configuração. Abro chamado para o suporte, solicito inclusão dos arquivos… Espero. Recebo e-mail de OK. Novo teste, rodo… Erro! Meu… “Login inválido do banco de dados”… OK… Peço o arquivo Web.config de homologação, não mudaram o endereço do servidor do BD! OK… Mudando… Novo chamado, nova inclusão, mais uma espera… E-mais de OK… Teste… Executo… Erro! ERRO!! Não é possível. Análise do Web.config, o cara de suporte subiu o meu arquivo, com a senha em branco… Cara, prefiro ter um filho veado que um filho analista de suporte!! Alterações feitas, testadas, ambiente OK, e-mail para equipe da UI, … É só esperar confirmação. Enquanto isso,  é ler um pouco.
Recebo e-mail de que o meu WS está  com erro… Não é possível… Nada de errado! Pego o arquivo XML no log, … Pô, dois cabeçalhos “<?xml version=’1.0′ (…)”, como que o cara quer que funcione? Não, nem vou comentar.

Se você está  rindo disso… Ainda vai acontecer com você. Provavelmente amanhã…

Texto inspirado em um quadro do Terça Insana.

Ou o contrário… eu explico.

Anos atrás,  quando comecei a me envolver mais com arquitetura de sistemas, quando procurei por “coisas que me ajudassem a desenvolver melhor o meu trabalho (tudo começou por que eu achava que deveria existir uma maneira melhor de fazer acesso a dados do que com Dataset’s, mas isso é outra história), eu me deparei com Padrões de design, DDD, e por aí vai; Nessa época o Giovanni Bassi também estava procurando pessoas para discutir arquitetura, e assim que me deparei com o .Net Architects. Passei por uma grande empresa de software no Brasil e lá existia cargo de arquiteto, de arquiteto corporativo, este último trabalhando com a diretoria. Mas conhecendo mais sobre arquitetura, com as discussões no #DNA comecei a pensar que, na verdade, o arquiteto era um papel exercido por um desenvolvedor dentro do processo de desenvolvimento de software, e não um cargo ocupado por alguém pensando somente em arquitetura conceitualmente, mas  sim “codando” junto com o time de desenvolvimento, pelo menos em uma parte significativa do tempo e em PoC’s, ou em partes específicas. Afinal, se o arquiteto não vive a codificação, como ele garante que a arquitetura que ele pensou inicialmente está aderente ou ainda,  que está mais ajudando do que atrapalhando? Sim, por que se a arquitetura é a estrutura na qual será construído um software ela tem que ajudar a codificar, se está atrapalhando, é melhor fazer sem. Ou seja, ninguém deveria ser contratado para ser arquiteto e sim, deveria exercer o papel de arquiteto durante um projeto, ou em uma equipe de um produto específico. Da mesma maneira que podemos estar no papel de tester, ou focado em desenvolvimento de interface (papel de dev de UX), etc…

Para que o arquiteto consiga desenvolver uma arquitetura, o que ele precisa? Conhecimento, experiência; ou não, se o cara é inteligente e cresce com PBL, qual o problema? Existem os skills que não são técnicos, comunicação, habilidade social (afinal ele precisa conviver com o time e não achar que esta acima de tudo isso). E ninguém tem dúvida que ele deve conhecer Design Patterns, frameworks, build, Testes e por aí vai. Mas espera, isso não seria tudo o que um desenvolvedor deveria conhecer? Design Patterns, codificação, framework’s, melhores soluções, tendências, Testes, Build, sem isso um dev não vai desenvolver.

- “Ah! Um dev desenvolve software, ele constrói software, já um arquiteto cria arquitetura, a base, ou um projeto… Não é a mesma coisa.” Será? Um dev realmente constrói software? Vamos fazer um paralelo? Vamos pegar outro segmento de mercado, uma indústria, uma construtora civil… Para se produzir um carro, para se construir uma ponte, é necessário um projeto, existem pessoas com diferentes habilidades lá, nem todas conseguem imaginar um carro ou os detalhes de uma ponte e nem todas conseguem instalar vidros nas portas ou pilares. Então os que não conseguem imaginar os detalhes de construção são dirigidos por um plano, ou um projeto, que é elaborado por pessoas que conseguem visualizar todos esses detalhes. Então arquitetos, engenheiros mecânicos produzem um projeto que serve de guia para operários construirem a ponte ou o carro. Os arquitetos e engenheiros tem uma visão abrangente, mesmo se só desenvolverem um pedaço desse projeto, esse pedaço é abrangente, pois é composto por diversos detalhes. O operário tem uma visão de processo de construção, seguindo o plano. Às vezes dentro desse processo ele consegue sugerir melhorias, novas idéias, mas dentro desse processo.

Voltando ao desenvolvimento de software… O desenvolvedor constrói software? Ele empilha os bits em código de máquina? Ele “builda” o código de máquina? Não! Um desenvolvedor de software constrói um projeto do que ele quer que seja o software, daí ele aperta F5 e envia uma mensagem para o Compilador dizendo “construa um código de máquina baseado nesse projeto aqui, nesse código”. Se o desenvolvedor é quem projeta ele é um arquiteto/engenheiro de software, pois ele exerce as características que definimos como a de um arquiteto. Ele não é simplesmente um operário que segue um projeto, que segue um plano, um processo. Ele pensa, elabora, planeja e PRECISA conhecer tudo aquilo escrito lá em cima: Design Patterns, ORM, Banco de dados, SOA, linguagens de programação, código, frameworks, protocolos, API’s, UX, etc… etc… Um desenvolvedor que apenas sabe usar IF…ELSE, FOR…EACH, SWITCH, simplemente não estudou o suficiente, é iniciante, ou esta enganando alguém. E ainda não leu “Clean Code”.

Se todos os dev’s se comportarem com o que esperamos hoje de um arquiteto eles serão realmente responsáveis pelo código que estão gerando, já que a arquitetura será dele também, já que ele vai ter que estudar, e muito, para aprender tudo isso. Ele também vai aumentar a visão que tem do projeto, poderá ver coisas que não estava entendendo e que contribuíram para um desenvolvimento mais pobre que ele tenha feito. É óbvio que um desenvolvedor que acabou de iniciar na profissão não terá conhecimento e experiência suficiente para codar sozinho definindo frameworks, arquitetura, mas com o auxílio de um outro dev mais experiente ele irá adquirir essa bagagem.

Então desenvolvedor,  pense como um arquiteto, seja um arquiteto! O projeto/código é seu!

Se você é responsável por alguma área de TI, coordenador, gerente, diretor e tem uma pequena verba sobrando,  que tal torrar? Afinal,  se você não gasta toda a sua verba, no ano que vem vão diminuí-la, certo? O problema é que não pode dar na cara, se você simplesmente torrar essa grana em um happy hour com a equipe, comprar cadeiras melhores ou um segundo monitor para cada desenvolvedor, isso pode levantar suspeitas e te acusarem de não saber controlar sua verba. Então seguem abaixo algumas sugestões. Espero que lhe ajude na ascenção de sua carreira! Se você for promovido, deixe seu depoimentos nos comentários. Segue abaixo o manual: Como torrar sua verba de TI de maneira “responsável”:

Atualize os seus softwares

Caro e não palpável:  a compra de software é uma maneira de você gastar e ninguém ver onde. Você pode comprar várias e várias licenças, hoje em dia não vem nem mais a caixinha que ocupava espaço, e gastar muito dinheiro com isso. Para gastar bem gaste com a moda, compre ALM! Várias licenças de Team Foundation vão custar uma bela grana e simplesmente não use-as. Pelo menos não totalmente, para não dar na cara, use somente o controle de versão, todas as outras funcionalidades podem ser esquecidas, não precisa usar o build automático, tracking, etc…
Ganhe um Bônus adquirindo o VS.Net Ultimate e não treine os desenvolvedores para usar as facilidades que ele oferece, aliás… o TFS não vai estar funcionando mesmo.

Contrate um gerente de projetos

Aqui é “double damage”! Além de gastar dinheiro com um profissional para tomar conta de outros, os desenvolvedores, no caso, pois eles não tem a menor idéia do que fazer, precisam de uma babá e às vezes trabalhar na base do chicote; esse integrante do time vai reagir de forma contrária ao time, vai introduzir ruído, marcar extensas reuniões, vai sentar ao lado de um dev para ver o que está acontecendo e ajudar no código; ou seja, vai atrasar seu projeto ou piorar as manutenções de software. Traduzindo:  mais tempo, que é mais dinheiro, mais gastos. Se você além de double quer um bônus com essa aquisição, peça um que seja PMP, certificado claro, pois a hora é mais cara e ele vai trazer um livros de regras junto para aplicar no seu processo.

Processo

Se você não tiver um processo você já tem muito gasto, atrasos, comunicação falha, e por aí vai. Mas, instalando um processo você pode gastar ainda mais!! Vá para o mercado, procure profissionais gabaritados em processos, e peça uma avaliação, afinal você quer ter mais visibilidade do projeto, ter certeza que estão fazendo a coisa certa e quer controlar se a galera esta indo pro banheiro dormir no vaso depois de uma noite de balada na terça-feira, e para isso terá que gastar mais. Planilhas de horas, ou um software, documentação abrangente, validações, reuniões de planejamento, análise do problema; tudo isso deve estar contemplado no processo. Ganhe bônus instalando uma ferramenta de controle do processo.
Já tem um processo na empresa? Então mude! Escolha um da moda e obrigue sua adoção, lembre-se de contratar um consultor para isso! A mudança do projeto deve ocorrer durante o projeto em andamento e não se preocupe, coloque tudo o que puder, as pessoas devem se adaptar,  e não o contrário.

Contrate pessoas

Se você acha que ainda esta gastando pouco,  nada é mais caro do que a contratação de pessoas. Principalmente pessoas que não estão comprometidas com a empresa, portanto abuse dos terceiros, eles podem te dar um bônus em gastos se você contratá-los com “horas abertas”. A contratação de mais pessoas vai prejudicar sua comunicação no projeto e provavelmente vai dobrar seu tempo de desenvolvimento, isso mesmo, vai dobrar! Se isso não é custo suficiente,  peça certificados; os profissionais com certificação vão lhe garantir um gasto extra, já que como pessoas com mais conhecimento vão te cobrar mais.

Se você não tem uma verba sobrando… Mantenha seu ambiente com um clima péssimo, infra-estrutura ruim, máquinas velhas, isso fará com que as pessoas não queiram trabalhar, logo elas vão produzir pouco ou nada e o projeto vai atrasar. Algumas vão se demitir então poderá contratar novos, mais alinhadas com as diretrizes da empresa. Depois poderá pedir mais verba para consertar o andamento do projeto… Volte ao início e aplique as propostas apresentadas.

Se você é desenvolvedor e leu esse texto… bazinga!

Hoje o Manifesto Ágil completa 10 anos. Nesse tempo muita coisa mudou, evoluiu, ou não!

10 anos na indútria da TI é muito tempo. Muita tecnologia nasceu e outras tantas morreram, muitos aplicativos foram desenvolvidos, alguns de sucesso incrível outros nem tanto, e outros que pareciam não deixar de existir,  nunca foram engolidos por inovações. Mas, desenvolver software ainda é uma incógnita para muitos do mercado.
Pode ser muito tempo para a TI, mas, historicamente falando, 10 anos é pouco tempo para analisarmos grandes mudanças.

Fazer software ainda é para muitas empresas sofrível! E é curiosa essa afirmação, pois em um segmento em que mudanças acontecem da noite para o dia, novas tecnologias são desenvolvidas frequentemente, elas não são absorvidas pela própria indústria que as cria. É como se as empresas de telefonia não fizessem uso do telefones para se comunicar.

O manifesto ágil focou em pessoas, interação, mudanças e colaboração. Mas poucas foram as empresas que conseguiram absorver esses conceitos. Por que? Muito antes do manifesto, Ricardo Semler mudou a cultura da sua empresa, a Semco. Quando a TI nem falava de trabalho remoto (famoso Home Office), colaboração entre indivíduos, ambiente de trabalho… A Semco já mudava essas formas antiquadas de pensar. Não foi fácil, mas se operários de fábrica conseguiram ter flexibilidade no horário de trabalho, por que profissionais que não estão presos a uma linha de produção ainda não conseguiram?

Os ambientes colaborativos na internet 2.0 aparecem aos montes, são ferramentas de redes sociais, aplicativos profissionais, até mesmo CRM já tem internamente sua rede social (veja o Salesforce Chatter), mas todas essas facilidades a um click de distância de qualquer indivíduo com acesso a grande rede são barrados por firewalls de empresas preocupadas com produtividade. Essas mesmas empresas são aquelas que minam a produtividade de seus funcionários proporcionando um ambiente tão ruim de trabalho que é desanimador querer resolver algum problema. Veja o vídeo do Jason Fried da 37Signals no TED (Why work doesn’t happen at work).

O ágil esta na moda hoje! É legal a empresa ser ágil, só pela palavra já é legal, ter um framework do tipo Scrum, esse então todo mundo parece usar, mas realmente fazer uso, difícil… O Giovanni Bassi da Lambda3 recentemente escreveu um post com o título Que fique claro: não se “instala” agile, diferentemente do que pensam muitos “gerentes” por aí, que acham que é só chamar um “consultor”, fazer 3 dias de cursinho, e bora usar o Scrum.

Infelizmente a mudança cultural defendida pelo movimento ágil vai demorar a acontecer em muitos lugares, pois a cultura da falta de colaboração entre indivíduos, falta de valoriazação do trabalho, más práticas, é a realidade de muitas empresas, e pior, educaram vários indivíduos assim… Deseducar será um longo processo para elas. Quem hoje consegue se livrar de toda essa carga cultural negativa vai surfar a onda.