24 de agosto de 2009

O que todo coordenador ou gerente de TI deve saber

Esse post é o outro lado da moeda do post O que todo desenvolvedor deve saber, motivado pelos comentários dos leitores Alexandre Santos, Rafael e Anônimo (do dia 21/08/09 às 17:35).

Minha intenção naquele post era a de mostrar aos desenvolvedores que não conseguimos viver apenas de idealismo em nossa profissão. Temos que tentar ficar antenados com o ambiente que nos cerca, normalmente capitalista e afoito por bons resultados tangíveis.

Neste aqui, pretendo dizer aos coordenadores e gerentes de TI que somos idealistas e que temos vontade própria, como bem ressaltou o Rafael em seu comentário de 21/08/09 às 17:22.

Bem, vamos ao post.


Em todos esses anos de desenvolvedor, já passei pelas mãos de muitos coordenadores e gerentes, e também já coordenei muita gente.

Já trabalhei numa "euquipe" (eu sozinho), já tive coordenador muito bom, já vi gerente de relatórios, já coordenei nó-cego e cara bom de serviço. Já vi gente dizer que para gerenciar técnico, tem que ser técnico. Já vi muita gente dizer que nem sempre isso é necessário. Já vi bons técnicos tornarem-se péssimos gerentes.

Mas nunca vi um bom gerente tornar-se um bom técnico. Será que existe algum motivo para isso?

Por que, geralmente, as pessoas que ocupam posição de liderança esquecem-se de como é ser um técnico? Por que é que quando elas sobem um degrau, começam a comportar-se exatamente da mesma forma que o gerente de quem elas tanto reprovavam as atitudes?

Se você é um coordenador ou gerente de uma equipe de TI, seria bom lembrar de alguns detalhes que para nós desenvolvedores não são meros detalhes.


1. Não somos robôs.

É, não somos seres autômatos que fazem sempre as mesmas coisas, apesar de às vezes isso parecer ser verdade.

Não somos uma peça que pode ser trocada e a outra assume imediatamente nosso papel e função. Se você, coordenador de TI, já ouviu falar da era da informação, sociedade da informação, sociedade conectada e termos assim, já deve ter lido o livro A Empresa na Velocidade do Pensamento do Bill Gates.

Ah, você não leu esse livro? Desculpe, mas acho que você ainda precisa entender como as coisas poderiam funcionar em sua empresa. Depois de entender isso, você vai cair na real e sacar que as pessoas têm um papel fundamental no cumprimento de alguns quesitos importantes em sua equipe.

Se você acha que os desenvolvedores, sendo o "chão de fábrica", são dispensáveis, me explique o por quê de os softwares geradores de código tão promissores nas décadas de 80 e 90 não decolaram. Se você ainda não estava na informática nesse tempo, me diga o motivo de os webdesigners profissionais (aqueles bons e que realmente sabem o que estão fazendo) valorizarem tanto códigos HTML e CSS e dispensarem tanto os códigos gerados pelo Dreamweaver (e, antigamente, pelo Frontpage).

Subindo um pouco o nível, tente dispensar alguém de sua equipe na semana de implantação do sistema em produção!

Pois é, não somos robôs. O conhecimento que está dentro de nossa cabeça não passa por osmose, nem quando programamos em par. Sim, programação em par existe! E é realidade. Não é coisa de futuro, não. Sobre isso, "o Google é seu amigo". Ah, e também não trata-se de meiose. :-P


2. Somos telhado de vidro.

Se você tivesse um telhado de vidro, jogaria pedra nele? Eu não! De jeito nenhum! Pois é por ali que a primeira chuva vai entrar: por onde a pedra caiu.

Muitas vezes nós, os desenvolvedores, somos usados para levar a culpa de inconsistências e de mal-entendidos. Ora, não somos perfeitos e temos a chance de entender errado, certas coisas. Já vi muitos desenvolvedores omissos, que não mereciam ser estagiários, mas eram considerados seniores. Esses, na minha empresa nem chegariam à metade do estágio.

Em contrapartida, pela dinâmica das nossas atividades, não podemos pedir que os usuários assinem tudo. Como queremos entregar nosso trabalho com agilidade, usamos muito de telefone e contato pessoal para tirar dúvidas. Nem tudo fica escrito ou documentado. Quando entendemos o que foi solicitado e mostramos o resultado para o chefe de quem nos deu a informação que faltava, frequentemente ouvimos um claro e alto "não é assim que precisamos!" ou um "não foi isso que eu pedi!".

Nessas horas, o que mais queremos é um aliado, que confie no que dizemos, que acredite que realmente recebemos a informação para fazer assim. Se é para fazer diferente, que seja, mas precisamos de um escudo, não de outra pedra!


3. O que é certo? E o que é errado?

Você já pensou que fazemos muita coisa certa, mas que parece errada? E algumas coisas erradas que parecem certas?

Pense numa totalização de nota fiscal onde o valor desta precisa bater com o total dos valores dos itens, multiplicados por suas respectivas quantidades. Ser rígido assim é correto? Sim, mas nem sempre.

Não vou entrar aqui em detalhes, mas trabalhei por vários anos em empresas de Telecom, onde os itens são trabalhados com 5 casas decimais, mas o valor a pagar pelo consumidor tem apenas 2 casas. Se você já teve problema com arredondamento de valores, vai entender do que estou falando.

Agora me responda: o que é certo e o que é errado nesse caso?

É bom termos as regras de negócio bem claras e usuários que realmente conheçam o negócio. Refiro-me à matemática, não à informática!

Ruim é fazer o certo e alguém dizer que está errado. Isso pode ser trágico, às vezes.


4. Trabalhamos para viver; não vivemos para trabalhar.

Não vou nem escrever sobre isso. Indico a leitura do famoso texto O Cara da Informática.


5. Seria bom você ser um técnico.

Como eu disse, já ouvi opiniões contra e a favor dessa afirmação.

Como técnico, eu gostaria muito que meu coordenador ou gerente fosse "um dos nossos". Seria bom que ele soubesse das dificuldades que enfrento. Seria bom que as pressões e decisões fossem embasadas apenas em critérios técnicos.

Como eu já fui coordenador, sei que não vivemos no mundo perfeito e que esse cenário nem sempre é possível de encontrar. As pressões nem sempre têm coerência técnica, mas as decisões podem ter.

Como coordenador ou gerente, identifique seus técnicos confiáveis e confie neles. Seja o cabeça, mas utilize-os como seus braços. Aliás, sugiro que você os use como seus cérebros sempre que puder. Filtre as coisas, claro, mas use-as!

Seja lá como for, procure entender um pouco do nosso mundo. Converse conosco. Também temos ideias. Aliás, é por isso que ganhamos mais do que muitas profissões mais antigas. Por nossas ideias e soluções. Lembra da sociedade da informação?


6. Pra quê serve o maestro da orquestra?

Seja sincero, você faria uma estimativa com o único objetivo de furar o prazo? Nós também não.

Os desenvolvedores acham que podem fazer mais do que realmente fazem. Frequentemente me pego agindo assim. Somos autoconfiantes e otimistas, mas não chutamos fora por querer.

Às vezes chutamos na trave, às vezes fazemos gol, às vezes a bola vai lá na arquibancada. Os jogadores de fubetol também fazem assim, não vencem todas as partidas, mas ninguém quer mandá-los embora só por causa disso, certo?

Antes de jogar, o time treina. Antes de fazer a apresentação, a orquestra ensaia. E por que, antes de desenvolver, os desenvolvedores não treinam nem ensaiam? Já pensou nisso?

Até hoje, de todas as empresas que eu trabalhei, só uma empresa (uma única! umazinha só!) se preocupava com os ensaios da equipe técnica. Não era obrigado, mas livre para quem quisesse participar. Essa vale a pena citar: é a SEA Tecnologia, que fica em Brasília. Lá tem uns caras feras (mesmo!), e que treinam o tempo todo. O Coding Dojo pode ser uma boa ideia, viu?

Você, como coordenador, se preocupa com o ensaio da sua equipe? Não estou pedindo curso, não. Lembre-se: o técnico treina o time. O maestro ensaia a orquestra. E o coordenador de TI, faz o que?

Pense nisso!


7. Somos pagos para compartilhar conhecimento.

Sim, todos nós! Eu disse todos?!

Ei coordenador, e aquele cara que só esconde o jogo? É o mesmo que não passa a bola. É o cara que só quer ser o solista, o primeiro violino! O cara que só toca o que quer, quando quer.

Será que ele teria espaço no time ou na orquestra?


8. Somos pagos para aprender, certo?

Isso me faz lembrar do item anterior: compartilhar conhecimento.

Se alguém da mesma empresa já sabe o que preciso fazer, que tal você, coordenador, promover um encontro técnico?

Afinal, para a gerência, quanto antes as coisas ficarem prontas, melhor para todos, certo? ;-)

Eu trabalhei recentemente em um lugar onde a internet era bloqueada durante o expediente. Será que existe maior incoerência do que essa? Privar os profissionais de tecnologia de terem acesso a informação?

Como aprender num ambiente assim?

Sem comentários, né?


9. A mesma regulagem para todos.

Se você mede 1,80m e sua esposa 1,50m e vocês compartilham o mesmo carro, o banco do motorista precisa ser ajustado, bem como os retrovisores, certo?

O mesmo acontece com as chuteiras dos jogadores, com os graus dos óculos de quem tem déficit de visão. Cada um tem uma necessidade e preferência próprias.

Se isso é tão claro nesses exemplos, por que nós, desenvolvedores, somos forçados a usarmos as mesmas ferramentas o tempo todo?

Se eu sou produtivo com Eclipse e meu colega com Vim, você pode me explicar por que temos todos que usar Netbeans?

Há em muitos lugares uma situação vista no início do século XX, quando Henry Ford disse certa vez que "você pode ter um carro de qualquer cor, desde que ele seja preto". Uau! :-#


É isso, coordenadores e gerentes de TI. Vamos ficar ligados. Sem paternalismo, mas com discernimento.

Tem muito mais coisa pra falar, mas acho que os comentários vão ajudar a expandir o assunto, certo?

11 de agosto de 2009

Scrum fora da TI – Reconhecendo o ambiente

Hoje (10/ago/2009) eu comecei a aplicar um pouco de Scrum em um ambiente que não é o de desenvolvimento de sistemas.

Meu desafio será aplicar Scrum em uma fábrica de roupas na região de Vitória (ES). Em outras palavras, vamos praticar alguma coisa de metodologia ágil em um ambiente altamente tendencioso ao modelo taylorista, focado em procedimentos.

Ter o manifesto ágil em mente é importante para não se deixar levar pelos impulsos naturais, pois a situação da fábrica é muito delicada;

A gerente geral dessa fábrica assumiu há cerca de um mês e encontrou um ambiente completamente desordenado onde as informações vitais simplesmente não existiam. Ninguém sabia o quê estava sendo produzido exatamente. As demandas de produção não eram conhecidas. Também não havia nenhuma noção de agendamento, capacidade de produção, o que deveria ser pago nem quando, nem tampouco o que havia para receber na praça. Resumindo bastante: caos total e muita dívida. Repetindo: muita dívida!

Eu não me lembro de ter trabalhado em um projeto com tanto risco, tanta incerteza e tantas restrições juntos ao mesmo tempo. Talvez o maior risco para mim seja meu próprio salário, mas sou movido a desafios. rsrs

A partir de agora eu pertenço à equipe que tem como objetivo fazer as informações circularem de forma orgânica nessa fábrica. Novamente falando no bom e claro português: estamos apagando o incêndio. Meu foco será a área financeira. Eu não atuarei como desenvolvedor de aplicativos. Não serei o “cara da informática”. Serei o gerente financeiro por algum tempo.

Num caso como esse podem surgir algumas perguntas naturais, que também me vieram à mente, e que tentarei responder abaixo.


1) Ágil fora do desenvolvimento de sistemas?!

Sim, e por mais absurdo que possa parecer para alguns, por que não?

Um dos motivos é porque o manifesto ágil nos recomenda valorizar mais as pessoas do que os processos. Não importa o tipo de atividade que façamos. Se essas atividades são executadas por pessoas, estas (as pessoas) devem ser valorizadas.

Além disso, Scrum é um framework de gerenciamento que não me deixa engessado e eu posso adequá-lo às minhas necessidades.

2) Usar método ágil num contexto de linha de produção não é incoerente ou incompatível?

A fábrica não são só as máquinas funcionando. Existem as áreas administrativa, de RH, financeira, comercial, compras, logística, etc.

Todas essas áreas da empresa têm atividades que precisam ser realizadas em determinada ordem de prioridade. Temos vários projetos sendo executados ao mesmo tempo: entrega de bermudas para o cliente "a"; arremate de peças para o cliente "b"; "namoro" com vários representantes e potenciais clientes e fornecedores ao mesmo tempo; patrocínio de atletas; participação em eventos... e por aí vai.

Engana-se quem pensa que as prioridades nesse ambiente são sempre as mesmas e que não há variação de atividade. O que não existe aqui é uma coisa chamada monotonia, meu amigo!

Cada coisa a ser feita é uma história diferente e cada uma delas vai impactar no resultado da empresa de maneira positiva ou negativa, dependendo de nossa decisão. Sim, o termo "história" não foi usado aqui por acaso e tem muito a ver com os cartõezinhos do kanban. ;-)

Toda empresa é um organismo vivo que precisa responder rapidamente às mudanças de mercado, de legislação e estar à frente da concorrência. Ou seja, precisamos ser ágeis.

3) Por que não apagar primeiro o incêndio para depois pensar num modelo ágil?

Porque o manifesto ágil nos diz que podemos ter retorno rápido e palpável do investimento.

Se eu tenho um cenário de falta total de informação, mas a empresa continua funcionando, tendo que produzir, pagar funcionários, fornecedores e credores, nada mais natural do que utilizar um meio de focar no que é prioritário para ter um grande ROI, o mais rápido possível.

Além disso, para cada tipo de peça fabricada, ou de tecido utilizado, eu preciso saber a capacidade de produção (velocidade) de minha equipe. Note que aqui temos níveis de complexidade diferentes para atividades diferentes.

Estamos aprendendo o tempo todo, pois lidamos com tipos de tecido diferentes, arremates mais simples e outros mais complexos, que influenciam diretamente na minha velocidade de produção. Agora você já consegue enxergar alguma semelhança com produção de software?

Alguns podem pensar que são coisas completamente distintas. Realmente são.

Outros podem dizer que software não é produzido em linha, como roupas. Novamente, têm razão.

Mas uma coisa é inegável: o manifesto ágil me dá a oportunidade de humanizar mais algumas áreas tidas como "robotizáveis", o que nem sempre é verdade. Me dá também a oportunidade de maximizar o ROI do meu cliente.

O Scrum me dá a visibilidade de completamento de tarefas para que as pessoas tenham mais comprometimento e mais responsabilidade em suas atividades. Me auxilia a analisar o que fizemos, onde erramos e o que vamos fazer para não errarmos igual no futuro.


Minha experiência está apenas no início. Ainda teremos muita história para contar e idéias para trocar.

Até breve.

5 de agosto de 2009

Todo desenvolvedor deve saber

Estou na estrada de desenvolvimento de sistemas há um bom tempo e tenho visto tecnologias surgirem e desaparecerem.

Tenho ouvido um monte de letras ao longo dos anos. Às vezes siglas exatamente iguais significam coisas completamente diferentes!

A cada 2 ou 3 anos surge uma nova linguagem, um novo framework, uma nova metodologia, uma nova ferramenta... e por aí vai.

Por causa dessas mudanças todas, resolvi relacionar algumas coisas que todo desenvolvedor precisa saber.
A tecnologia conta, mas as pessoas é que colocam a tecnologia em ação.


1. Você é pago para dar lucro.

A despeito de suas preferências e independentemente de quão gente boa você é, você é pago para dar resultado palpável.

A empresa não vai ficar com você simplesmente pelo fato de você ser nerd pra caramba e estar por dentro da última release do kernel do linux, que tem uma nova opção de boot que acelera o processo em 0.50ms.
Acorda aí!


2. Você é pago para compartilhar conhecimento.

Pode parecer meio estranho para alguns, mas o conhecimento que você tem na sua cabeça não é só seu. Ou não deveria. É por isso que algumas empresas dizem que seus colaboradores formam seu capital intelectual.

Capital = dinheiro
Intelecto = conhecimento

Isso nos remete ao 1o item: você tem que dar lucro! Com seu conhecimento, viu?

Então, compartilhe.
Eu tenho um amigo que diz que quem esconde o jogo tem prisão de ventre cerebral.

Pior que ele tem razão! rsrs


3. A empresa tem necessidades que nem sempre são as suas.

Já reparou nisso?
  • O dono da empresa quer que você dê ideias de como ganhar mais dinheiro.
    Você diz que seria legal liberar geral o acesso à internet.
  • O dono da empresa diz que um cliente quer um projeto desenvolvido em Fortran.
    Você diz que seria melhor converter o sistema existente lá para Java.
  • O dono da empresa diz que para trabalhar no cliente, você precisa ir de roupa social.
    Você diz que o mundo tá todo errado e que o lance hoje é ir de boné e bermuda.
  • A empresa arranja clientes que querem um projeto mas não têm tanto dinheiro assim, por isso querem um sistema simplesinho.
    Você diz que meia-boca você não faz de jeito nenhum!
E agora? Você, desenvolvedor, tem 2 saídas:
a) aceite as necessidades da sua empresa.
b) encontre alguém que queira aceitar as suas necessidades.


4. Você é pago para aprender.

Esse é o emprego dos sonhos de todo mundo, né?
Nem sempre. Pense bem.

Quando você é pago para aprender sem prazo para terminar, é uma coisa.
Mas quando o projeto tem data marcada, cuidado!

Se você é especialista em PHP, mas tem que fazer alguma coisa em Ruby on Rails em 1 mês, os espinhos do mar de rosas comecam a aparecer e a arranhar, mesmo o mundo todo dizendo que o negócio é facinho pra caramba. Sim, fazer o aplicativo de blog que tem no tutorial é banal. O difícil é fazer o aplicativo que você precisa entregar.

Mas você é pago para aprender. Aprenda ou diga logo que não consegue.
Uma dica: aprenda a aprender!


5. Você é pago para (ou por) saber fazer e conhecer muita coisa.

Você é fera em Python? Bom.
Fera mesmo? Muito bom.
É um dos desenvolvedores da linguagem? Ótimo!
Mas não consegue dar uma palestra sobre isso? Que pena! :-(

A empresa precisa de pessoas multidisciplinares. Ou seja, aquele cara que bate o pênalti e corre p/ defender!

Se você é bom em programação mas nunca pensou em sair de frente do computador para dar uma palestra, reveja seus conceitos.

Se a timidez toma conta do seu ser a ponto de embrulhar seu estômago, suar suas mãos, tremer suas pernas, pense em fazer um curso de teatro. Isso sim é sair da zona de conforto!


6. Sua experiência de vida conta.

Não estou falando apenas sobre quantas linguagem e bancos de dados você conhece.

Estou falado sobre como você se virou pela primeira vez que sua mãe ou seu pai te mandou fazer o 1o pagamento sozinho no banco.
Estou falando sobre a 1a vez que você chamou uma garota p/ namorar e ela aceitou.

É disso que estou falando. Traga suas experiências para a empresa. Conte sua história! Ela vale muito.



Ei, esqueci de falar que um desenvolvedor precisa saber Java, C, Ruby, Python, SQL, HTML, CSS, PHP, Linux, Shell. Precisa saber o que significa ASP (linguagem), ASP (serviço), XML, RPC, DOM, DAO, Controller, MVC, Servlet, SCRUM, XP...
Bem, isso todo mundo já sabe, né? ;-)

Livro: Inovadores em ação

Ontem, passeando pela Livraria Leitura, encontrei uma promoção muito boa. Por R$ 9,90 comprei o livro Inovadores em Ação.

O livro conta histórias reais de 32 empresas que, de uma forma ou de outra, saíram do quadradinho, olharam para fora de suas paredes, desafiaram o mercado e deram novo fôlego à competição.

Ainda estou na metade do livro, mas fiquei encantado com a história Arkadi Kuhlmann, um banqueiro norte-americano que criou o ING Direct USA, um banco que tem como proposta não tirar dinheiro dos clientes. Aliás, esse banco não aceita clientes com muito dinheiro. Paradoxal, né? Pois é. Ele já é o 4o maior banco dos EUA!

A Procter & Gamble também tem um caso interessante. Ela pegou a idéia do desenvolvimento colaborativo de software e aplicou à linha de pesquisa de novos produtos. Totalmente surreal para quem não trabalha com software! Antes, faltavam ideias de projetos; hoje, eles precisam filtrar tudo que chega de ideia nova.

Outra história bem diferente é de uma mineradora de ouro que resolveu publicar os mapas de uma de suas minas auríferas, buscando encontrar projetos que pudessem ajudá-la a melhorar a extração naquele local. A princípio ela estaria literalmente "entregando o ouro pro bandido". Leia e veja o resultado!

Uma das coisas que o livro diz é que talvez seja mais importante ter pessoas trabalhando com você do que para você.

Bem, fica aí a dica. A leitura é realmente muito boa e inspiradora.

Se você é um inovador, por que ainda não leu? ;-)

Eu estou lendo e tendo algumas ideias doidonas! rsrs