1up4Developers

Para começar o post, segue esta história sobre gerenciamento que vi no blog do Gustavo Ribeiro:

Todos os dias, uma formiga chegava cedinho ao escritório e pegava duro no trabalho. A formiga era produtiva e feliz. O gerente marimbondo estranhou a formiga trabalhar sem supervisão. Se ela era produtiva sem supervisão, seria ainda mais se fosse supervisionada.

E colocou uma barata, que preparava belíssimos relatórios e tinha muita experiência, como supervisora. A primeira preocupação da barata foi a de padronizar o horário de entrada e saída da formiga.

Logo, a barata precisou de uma secretária para ajudar a preparar os relatórios e contratou também uma aranha para organizar os arquivos e controlar as ligações telefônicas.

O marimbondo ficou encantado com os relatórios da barata e pediu também gráficos com indicadores e análise das tendências que eram mostradas em reuniões.

A barata, então, contratou uma mosca, e comprou um computador com impressora colorida. Logo, a formiga produtiva e feliz, começou a se lamentar de toda aquela movimentação de papéis e reuniões!
O marimbondo concluiu que era o momento de criar a função de gestor para a área onde a formiga produtiva e feliz, trabalhava. O cargo foi dado a uma cigarra, que mandou colocar carpete no seu escritório e comprar uma cadeira especial.

A nova gestora cigarra logo precisou de um computador e de uma assistente (sua assistente na empresa anterior) para ajudá-la a preparar um plano estratégico de melhorias e um controle do orçamento para a área onde trabalhava a formiga, que já não cantarolava mais e cada dia se tornava mais chateada.

A cigarra, então, convenceu o gerente marimbondo, que era preciso fazer um estudo de clima. Mas, o marimbondo, ao rever as cifras, se deu conta de que a unidade na qual a formiga trabalhava já não rendia como antes e contratou a coruja, uma prestigiada consultora, muito famosa, para que fizesse um diagnóstico da situação. A coruja permaneceu três meses nos escritórios e emitiu um volumoso relatório, com vários volumes que concluía: “Há muita gente nesta empresa!”

Então o marimbondo mandou demitir a formiga porque ela andava muito desmotivada e aborrecida.

Então lembrei de uma imagem que ilustra perfeitamente esta fábula e retrata fielmente a “organização” de alguma empresas:

Dividir para conquistar: você está fazendo isso errado!

Quando uma startup passa a vender mais e ter uma procura maior por seus produtos/serviços (o que é bom), uma reação comum da “cúpula” é aumentar o quadro de funcionários visando atender a demanda. Logo surgem os problemas com a organização do pessoal e/ou fluxo de trabalho. A solução mais simplista (e óbvia) é a especialização: fulano faz isso, ciclano faz aquilo, e beltrano gerencia. Logo controles são criados, fluxos validados, centros de custo, documentos, reuniões, atas, comitês, gestão de pessoas e relacionamento, terceirização, cargos, departamentos… e nasce o monstro da burocracia, aka “enterprise”.

Com essa especialização, cada “módulo” (também conhecido como departamento) começa a perder o foco no GRANDE objetivo da empresa e passa a defender apenas seus interesses – a famosa MISSÃO da empresa passa a ser coadjuvante. O resultado? A empresa dobra ou triplica seu quadro de funcionários e na maioria dos casos, seu lucro bruto. Porém agora tem mais despesas com pessoal e gastos extras para manter esse novo modelo “enterprise”. Trocando em miúdos, continua na mesma!

Onde está o erro? Mais uma vez o FOCO está na solução ao invés de PROBLEMA. Se você ler meus posts anteriores vai ver que este é um tema recorrente. Então por que as empresas continuam fazendo as coisas erradas e cometendo os mesmos erros?

Idéias criativas surgem das pessoas diretamente relacionadas com os problemas e não de diretores, contadores, gestores, etc. Esse modelo “enterprise” é um overhead organizacional que só gera ruído e desperdício!

A solução é adotar agile!

SOLUÇÃO!? Mas qual era o PROBLEMA mesmo!? Sim, mais uma vez o foco é a solução ao invés do problema.

Como eu disse nos posts anteriores, acreditar que uma mudança drástica do processo pode mudar a cultura da empresa e pincipalmente as pessoas é o maior erro na adoção de metodologias ágeis. Mudam o processo mas não mudam as pessoas.

De uma forma simples e direta, agile resume-se a quatro valores:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Ou seja, pessoas, software, colaboração e feedback. Simples assim!

O manifesto ágil não cita nada sobre “enterprise”, sobre a implementação. Este é o grande desafio em sua adoção. Como seguir estes valores sem burocratizar e engessar o processo? Como criar uma relação de colaboração com os clientes? Como responder rapidamente a mudanças? Como eliminar o esforço que não agrega valor ao produto e/ou empresa? Como evitar politicagem?

Mantenha-se pequeno!

Otimize! Busque soluções para os problemas que impedem de produzir mais e com mais qualidade. Faça MAIS com MENOS. Foque no O QUE ao invés do COMO. Escale as pessoas verticalmente!

Inove! Não espere conseguir resultados diferentes fazendo sempre a mesma coisa. Busque novidades, opniões, experiências. Ouça seus funcionários, seus clientes. Estude, pesquise, arrisque, erre, acerte… continuamente.

Mantenha o foco! Tenha um GRANDE e único objetivo e certifique-se que todos acreditem nesta filosofia. É importante que todos comprem a idéia e o modus operandis.

Finalizando, este é apenas meu ponto de vista, baseado na minha experiência em diversas empresas grandes e pequenas, vivenciando problemas, errando muito e principalmente aprendendo com os erros dos outros. Agilidade pode funcionar bem em grandes corporações, desde que haja foco e que todos comprem a idéia. Você pode concordar ou não.

Nos últimos anos o mercado de TI cresceu exponencialmente. Surgiram desde pequenas empresas especializadas em construir websites até monstruosas fábricas de software com seus contratos milionários. Algumas com orçamento limitado outras com dinheiro jorrando pelos canos. Umas com problemas por falta de organização outras com problemas burocráticos. Bons profissionais vs. equipes de sobrinhos, habilidade técnica contra enxurradas de documentos… muito fracasso, pouco sucesso.

A meta é coletar as moedas até conseguirmos uma estrela

Surgiram muitas empresas especializadas em desenvolver software ou que têm um software como produto principal. Normalmente, essas empresas se preocupam apenas em satisfazer os investidores e se esquecem dos clientes. Focam em vender e deixam a qualidade de lado. Prezam pela imagem e ignoram os problemas.

É uma triste realidade que essas empresas tenham mais executivos do que programadores. Como diz o Luli Radfahrer, executivos são aqueles seres que se vestem com um pensamento fracassado, usam uma linguagem própria sendo uma mistura de termos que só eles entendem e 20% de palavras em inglês… não vivem os problemas reais da empresa. É como se estivessem em outro mundo: Mario World!

O mundo dos executivos: nuvens sorrindo

A maioria das empresas que têm problemas com desenvolvimento de software ainda estão vivendo na década de 90. Internet ainda é uma palavra assustadora. Programador é apenas um funcionário que sabe o que significam siglas de informática e sabem mexer no computador. Mudança ainda é encarada como algo arriscado, que deve ser planejado, estudado e aprovado pelo presidente, diretoria e gestores. A palavra da vez é processo e seu fiel companheiro é prazo. A burocracia é uma amiga que garante que as coisas não fujam de controle. Nesse cenário não há como fugir do waterfall.

O maior problema do waterfall são os papéis: cada um com sua “especialidade”. Alguém determina que um infeliz funcionário vai ser responsável por “levantar requisitos”. Faz um cursinho de UML e começa a escrever uma quantidade sem fim de Casos de Uso sem ter noção alguma do que seu trabalho afeta no processo. Então a “equipe” começa a ter muito “retrabalho”, uma vez que os clientes não estão satisfeitos com o que está sendo entregue. Logo percebem que devem fazer o “levantamento” mais detalhado e passam a engessar ainda mais o processo com reuniões, assinaturas, etc. Conclusão: tempo e dinheiro desperdiçados e nenhum resultado satisfatório.

Meu trabalho é digitar 4 8 15 16 23 42 a cada 108 segundos

Falta de foco? Profissionais não qualificados? Processo falho? Não apenas isso: não há comunicação, não há troca de experiências. O waterfall favorece o aparecimento da síndrome do funcionário público: “eu sou gerente: eu córdeno, não preciso saber programar”. As decisões geralmente são tomadas por uma única pessoa. Os projetos seguem o modelo de construção civil. Os profissionais se acomodam pois não veem perspectiva, não conhecem o processo completo, não são ouvidos e por isso não são valorizados.

O foco destas empresas está longe de ser tecnologia. Se concentram em suas buzzwords, processos e reuniões e se esquecem do produto, ou seja, o software. Focam mais na solução do que no problema. Fazendo uma analogia, essas empresas são como um barco furado, onde está entrando água mas há pessoas com baldes para retirá-la e mantê-lo flutuando. Se a agua subir muito, contratam mais pessoas para operar os baldes. Enquanto isso, os executivos ficam acenando como se nada tivesse acontecendo. Quando perguntam se há algum problema, nenhum fdp infeliz tem coragem para falar que o problema é o furo no barco!

As empresas que focam em tecnologia e nos profissionais, tipo o Google ou a 37signals, estão se dando bem e mostrando que agilidade não é apenas mais um processo… é algo real e que funciona!

Agilidade é sair fazendo as coisas de qualquer jeito

Diante do cenário caótico das empresas, um grupo de profissionais organizou um movimento a fim de unificar as práticas bem sucedidas e tornar o processo de desenvolvimento mais produtivo e pragmático: o manifesto ágil. Quem freqüenta esse blog sabe que nós somos fãs e seguidores das práticas ágeis, não porque somos fanáticos e acreditamos somente em uma verdade absoluta, mas por que já sofremos muito com projetos e empresas fracassadas, vivenciamos os problemas que compartilhamos neste blog, passamos noites em claro corrigindo código escrito por maus profissionais, acumulamos horas em reuniões suficiente para tirarmos brevê, tivemos que negociar com cliente, com o chefe, fazer entrevista, contratar, gerenciar, analisar, programar, testar… nós sofremos os problemas do waterfall na pele!

O termo agilidade é bem popular atualmente: “precisamos agilizar nosso processo de desenvolvimento”. Como divulgação do manifesto ágil é algo muito positivo, pois mais pessoas podem conhecer e utilizar as práticas ágeis. Mas, como toda fama tem seu lado negativo, não seria diferente neste caso. Muitos profissionais “gafanhoto” estão utilizando esse termo como alavancagem profissional. Já tem gerente falando que RUP é ágil, arquiteto defensor de modelagem UML ágil, diagrama ER ágil, modelo de dados ágil, caso de uso ágil, cronograma ágil, etc. Ou seja, estão distorcendo totalmente o propósito e a filosofia da agilidade.

Como disse o Chapiewski, os programadores estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Agile é muito mais do que desenvolver iterativamente, fazer stand-up meetings e planejamentos ágeis. Não dá para ignorar todas as práticas de engenharia de software que realmente fazem com que a produção e mudanças em softwares sejam ágeis, sem contar todos os princípios e práticas que fazem uma diferença enorme.

O mercado que não é bobo já percebeu esse movimento migratório e lançou seus cursos de “Gerenciamento de projetos ágeis com MSProject”, “Desenvolvendo aplicações web com agilidade”, “Aprenda a programar com JUnit e TDD”. Não demorou muito para que uma massa de desenvolvedores colocasse o termo ágil em seus currículos. Pretensiosos demais em achar que um cursinho qualquer pode ensinar todo conceito e técnicas ágeis catalogadas por profissionais com décadas de experiência em desenvolvimento de software.

“Estou aprendendo Ruby on Rails por que o mercado está pagando bem“. do dia para a noite surgiram milhares de especialistas ágeis. O cara que programava em .NET ou Java no modelo tradicional (digitador de código), faz um cursinho rápido e de repente começa a desenvolver aplicações numa tecnologia que exige uma enorme bagagem conceitual. Faz tudo errado, pois não sabe realmente o que está fazendo, o projeto fracassa e ainda deixa a tecnologia com má fama. Isso aconteceu com PHP, ASP e está acontecendo com Rails.

Programar é difícil, não é um trabalho para qualquer aventureiro. É preciso estudar muito, se dedicar e principalmente, gostar! Não basta apenas estudar para conseguir uma certificação pois não garante nada. Deve-se viver a programação, participar de fóruns, contribuir com projetos open-source, discutir idéias, ser auto-crítico, ler muito, praticar, apreciar as boas práticas e abolir o que não presta…

Agilidade é propor soluções simples para os problemas

Agilidade não é anarquia, não significa “sair fazendo as coisas de qualquer jeito”, dizer “não” para documentação, etc. É uma mudança de atitude, uma nova maneira de enfrentar os problemas e propor soluções simples e práticas, é ter foco, é saber fazer mais com menos, é automatizar tarefas, é estar comprometido… agilidade é atitude.

Contratamos uma consultoria para implantar Scrum

Scrum é a metodologia da moda. Assim que começou a se popularizar entre a comunidade de desenvolvedores, não demorou muito para o que vários sites e blogs se dedicassem exclusivamente na sua divulgação, apresentando benefícios, artigos, guias, exemplos, certificados para imprimir e pendurar em uma moldura na parede, etc. Logo surgiram as consultorias especializadas em adestramento treinamento e implantação de Scrum nas empresas. Um pouco de política aqui e influência ali até que a INFO Magazine publicasse uma matéria dizendo sua empresa deveria usar Scrum como solução para todos os problemas.

Mais uma vez, a falta de foco e maturidade das empresas distorcem tudo. Muitas empresas “compraram” o Scrum como a solução pronta. Bastar treinar os funcionários, comprar blocos de post-it e tudo passa a funcionar bem e gerar lucro. Pagam um curso de “gerenciamento de projetos com Scrum” para os gerentes. Depois apostam todos as fichas em um projeto “piloto”. Fazem tudo que manda o manual: reuniões diárias, planing-pocker, quadro com post-its, etc. E o projeto… fracassa!

Queimando dinheiro

Então quer dizer que Scrum não funciona? Foi dinheiro desperdiçado? Tanto esforço para nada? Neste caso, devo dizer que sim! Se esqueceram do processo anterior falho, funcionários pouco qualificados e dos líderes sem foco. Escolheram aqueles funcionários mais “experientes” para serem o Scrum Master. Sim, aqueles mesmos que só sabiam escrever casos de uso e diagramas UML. Se esqueceram dos valores, dos princípios, da atitude, do relacionamento com o cliente. O pensamento não mudou, o foco ainda era no processo. Depois de tanto esforço, só deram outro nome o waterfall. Não demorou muito e surgiram os papéis, artefatos, documentos… ou seja, a empresa continua cometendo os mesmos erros!

Não importa a tecnologia ou processo se não souber usá-lo corretamente! E definitivamente Scrum não pode ser encarado como mais um processo bonitinho, com seus papéis, artefatos, bla bla bla. Um processo de software que funciona é aquele onde a equipe está realmente comprometida e tem experiência acumulada para enfrentar e resolver problemas ao longo do desenvolvimento da aplicação. O processo, ou metodologia, será meramente um nome para as práticas que a equipe conhece e utiliza naturalmente.

Resumo

Não há ferramenta, metodologia ou processo que substitua a atitude e experiência de um verdadeiro desenvolvedor ágil. Estude, pratique, esteja comprometido, estude denovo, questione-se, estude novamente. Revise seu código, estude mais um pouco, e principalmente, tenha atitude! Agilidade não é metodologia, é atitude!

Na semana passada uma desconfortável discussão me pôs a pensar sobre os obstáculos culturais na aceitação de princípios ágeis no desenvolvimento de sistemas. A discussão ocorreu quando um amigo meu comentou comigo a respeito de uma metodologia que ele pretende aplicar em um projeto no qual está envolvido. Fiz questão que ouvi-lo com atenção, pois ele, além de ser uma pessoa da minha consideração, possui um background de sistemas muito diferente do meu. O que permite tentar entender outros lados de problemas em comum.

Logo nos primeiros instantes da conversa, percebi que a metodologia que ele estava a me explicar era nada menos que algo derivado de waterfall, onde, basicamente, um “sistema” é definido, por sábios analistas, em um conjunto de diagramas diversos, para depois passar por “estágios” de aprovações e assinaturas mil, e então finalmente cair nas mãos sujas de pizza dos programadores. Documentos. Documentos e mais documentos. Tudo para garantir que não houvesse mal-entendidos, nenhum “re-trabalho”, nenhuma oportunidade de “o cliente” pedir mais do que podia ou mudar de idéia depois de todos os acordos — simplesmente, a metodologia era sinônimo de controle total e absoluto sobre todas as “fases” de um projeto.

Eu não podia ouvir tudo aquilo e ficar calado. A primeira pergunta que eu fiz foi: quais problemas essa idéia vai combater? Ou, pra ser mais sincero com o eventual leitor, perguntei que problemas, observados na prática, seriam resolvidos com a metodologia. Sim, na prática, pois durante a conversa ele havia dado exemplos bastante hipotéticos e superficiais de problemas. Recebi como resposta um olhar de espanto, como se eu tivesse perguntado se a Lua era feita de queijo Minas. Deveria ser óbvio para mim quais eram os problemas! Na raiz de todos os males está a informalidade total no andamento dos projetos! Cliente conversando direto com programador! Sistema que foge às especificações! Cronogramas que não são cumpridos! Programador dando uma de arquiteto! E outras na mesma linha.

Diante de tantas certezas, vi que a conversa já não ia dar em nada, mas continuei o debate. Respondi que, no projeto em que eu estou trabalhando, uma situação de caos total foi revertida sem que a equipe tivesse que conversar em UML, sem que colocássemos travas no diálogo com o cliente… mas com muito, muito “re-trabalho”. Disse ainda que, do meu ponto de vista, os problemas eram de fundo humano: equipe mal qualificada e expectativas amadoras dos assim chamados responsáveis. E ainda afirmei que não acreditava em especificação perfeita, primeiro porque especificações e diagramas são feitos por seres humanos (ainda que na qualidade de iluminados analistas), e segundo porque software se trata de algo mutável pela própria natureza. (Ou então seria chamado “hardware”.) Não falei em termos tão professorais assim, ou ao menos, procurei ser humilde nas colocações.

Continuei dizendo que, por causa desse fundamento humano, a solução dos problemas, se é que existe, passaria por: apoiar o talento das pessoas, não ser reativo nas negociações, recrutar direito, apostar em um gerenciamento mais adaptativo (em nenhum momento usei a palavra “ágil”) de projetos. Certamente, soluções bem menos simples do que dar ordens de se produzir e seguir diagramas ao pé da letra. (Como se houvesse leitura “ao pé da letra”…)

Pensei que possuía alguma credibilidade, mas acho que a essa altura da conversa o meu amigo já não me via como desenvolvedor experiente, e sim como um encarregado que tinha ido trocar a água do bebedouro perto do qual estávamos e resolveu dar palpite sobre esse troço de sistemas. Tive que ouvir que eu estava “totalmente errado”, que esse papo de dar valor às pessoas era “a causa de nada funcionar”, que as empresas precisavam reter conhecimento através de documentação (no que ele está certo), e que “muitas empresas grandes” estavam trabalhando com essa metodologia. (Não citou as empresas e eu não questionei pra não ficar chato.)

O papo acabou logo depois, mas se alguém ainda está lendo e achou que brigamos, não foi o que aconteceu. Continuamos amigos igual antes. Mas dificilmente volto a ter uma conversa com ele sobre esses assuntos. Existe uma diferença cultural muito grande entre nós dois no que diz respeito a software, e é esse o assunto do post!

Em toda a minha carreira eu apostei na minha capacidade de resolver coisas, no meu domínio sobre as questões relevantes aos trampos com os quais me envolvi, na confiança que eu podia estabelecer com as pessoas em volta e, reciprocamente, na confiança que essas pessoas podiam ter em mim. Eu não sei trabalhar de outro jeito e nem quero mudar, pois várias vezes tive o prazer de ver as coisas funcionando/mudando justamente pelas minhas atitudes. Uma metodologia na base do diagrama, na base do analista/deus e programador/vassalo não é só inútil pra mim como simplesmente não me oferece condições de trabalho.

Por outro lado, não me lembro de ter visto esse meu amigo falar com orgulho a respeito de algum projeto do qual tenha participado. Percebo que sua carreira foi marcada por muito trabalho, muito esforço com equipes ruins, muita pedrada de cliente folgado. Chefes ignorantes. Tarefas monótonas. Isso tudo, sem a contrapartida de gostar do que faz, nem de conseguir se motivar observando os próprios sucessos, pode facilmente, na minha opinião, produzir um semeador de waterfall, como meu amigo parece ter se tornado. Para um perpetuador de waterfall, um sistema é uma coisa plana, composta de tarefas registradas em alguma linguagem esquemática pobre, que será transcrita para o computador por pessoas-robôs cujo maior erro é, eventualmente, pensar.

Uma coisa plana sem espaço para a confiança, nem para a imaginação — origens de todos os males, pelo bate-papo ao pé do bebedouro.

(Parte da motivação para este post veio de “What are the right conditions for agile adoption?“, de David Anderson.)

Prosseguindo com a série de perguntas que não querem calar, desta vez com um enfoque em RH & correlatos. Já com sugestões do respeitável público! Continuem comentando. A intenção é catalogar tosquices de comportamento encravadas no nosso cotidiano.

1. Por que “anos de experiência” são tão importantes nos classificados de emprego?
   As profissões de informática já existem há décadas, e existe um grande histórico de coisas que deram certo e outras que nem tanto. Entre essas últimas, persiste uma forma garantida de contratar gente inepta, ao mesmo tempo em que aliena bons profissionais: a temível “experiência comprovada” em alguma coisa! Não importa se o candidato trabalhou uma vez por mês ou 16h por dia com a tal tecnologia durante todo o tempo requerido, ou se ele trabalhou com algo similar e não terá dificuldade, ou se consegue tranqüilamente ficar craque no tal requisito em duas semanas. Competência e experiência se confundem de forma surreal. É tão difícil assim avaliar aptidões?
2. Se certificações são tão inúteis, por que fazem tanto sucesso entre candidatos e recrutadores?
   Existe um debate acalorado sobre a utilidade/qualidade das certificações como forma de filtro de candidatos a emprego. As empresas não abrem mão de exigir algum diploma, pois a oferta está grande. Os candidatos, por sua vez, fazem sacrifícios para colocar uma estrelinha a mais no CV, pois a concorrência está grande. E na prática, quando pintar um problema, tanto o profissional ultra-graduado quanto o humildezinho vão recorrer a dois recursos: (1) capacidade de raciocínio e (2) Google. Quem tira proveito disso tudo além das empresas de treinamento?
3. Por que contratadores dificultam o acesso à internet por parte dos contratados? by peczenyj
   Será que quem contrata acha que o cara vai ser mais produtivo se ficar longe do GMail, MSN, Terra Esportes, 1Up4Dev? Sei lá. Eu achava que as empresas contratavam pessoas para que elas atingissem determinados objetivos, e não para que produzissem código ininterruptamente, sem “distrações”. Mas pode ser que, para elas, a produtividade seja um número, não um valor.
4. Qual é o sentido de se impor políticas de segurança inócuas? by miguel
   Há quem se sinta seguro contratanto dummies quaisquer para implementar filtros de firewall e fazer papel de polícia, bloqueando pen drives e colocando a impressora pra funcionar só das 8 às 18h. Missão: racionalizar o uso dos recursos de trabalho! Aumentar a segurança! Impedir vazamento dos fontes! Ao mesmo tempo, relaxam no recrutamento e logo a empresa vai estar infestada de pessoas que pareciam super-bem-intencionadas, mas vão passar o dia vendendo muamba no Mercado Livre através de um proxy russo. Ou emporcalhando os preciosos fontes, o que é bem pior que roubá-los.
5. Por que contratados e contratadores gostam de se tratar como empregados e patrões, mesmo em condições “PJ”?
   É fato inegável que a carga escorchante de tributos incidentes sobre a folha de pagamento leva as empresas a procurarem alternativas. Invariavelmente elas sub-contratam outras empresas para que, estas sim, se virem com o problema da mão-de-obra. Mas alguém já viu isso acontecer pra valer? O que existe é um local de atividade, um horário de trabalho, um salário, e cara feia se você quiser atender outro “cliente”. Os contratados não agem como empresários, embora paguem caro para o serem. E parece que ninguém se incomoda com o teatrinho patrão-empregado.
6. Qual a lógica em se cobrar por hora e não ganhar por hora?
   Os iniciantes começam com 10 ou 12 reais. Os júniores podem sonhar com o dobro disso. Os plenos estão na faixa dos 30 ou 35. E para os sêniores, o céu é o limite! Mas, curiosamente, quase todos trabalham 160 horas por mês. Quero dizer, são pagos por 160 horas trabalhadas no mês, recorrendo talvez a um banco de horas (muitas vezes fictício) quando a conta estoura. Ainda assim, freqüentemente gostamos de calcular nossos rendimentos pelo valor-hora, sonhando que estaríamos quase ricos se as contas batessem. 160 horas, my ass.
7. Como se enquadram projetos temporários nas variantes do Agile? Ou: posso ser free-lancer e agile ao mesmo tempo?
   Esta pergunta não é irônica (é, as outras pretendiam ser). É uma dúvida que eu tenho de verdade. Não sou expert em Agile/Scrum/XP/etc, e lendo a respeito dessas formas de trabalho, às vezes acho difícil compatibilizar a idéia de contrato temporário com desenvolvimento incremental sem tempo para terminar. Agile, por natureza, contra-indica prazos precisos. O contrato temporário, por natureza, baseia-se no inverso. Gostaria de entender melhor como essa situação já se resolveu na vida real.

Um post no estilo “remoendo coisas que passam pela minha cabeça”. À medida em que continuarem passando, aumento a FAQ.

1. Por que se fala mais de processos e ferramentas do que de indivíduos e interações?
   O item 1 do manifesto agile não me parece tão professado quando se observa a quantidade de informação dedicada a sistematizar — isto é, pôr em um processo — as alternativas agile. É da natureza do engenheiro colocar tudo em um diagrama?
2. Por que tanta gente (incluindo eu) prefere reclamar do emprego ao invés de arrumar coisa melhor para fazer?
   Parece haver uma terra prometida onde os projetos não atrasam, os clientes estão sorrindo, os chefes têm bom senso e os salários são muito bons. Lá você vai trabalhar quatro dias por semana e tem um andar com mesas de sinuca. Você acha que merece trabalhar lá, mas se conforma com “a situação”, que “é assim mesmo”, e ainda cobra pouco por isso.
3. Como metodologisificar* os projetos concebidos em erro?
   Imagine o seguinte: o cliente precisa cumprir uma meta, não vai conseguir e convenceu você a levar a culpa tocar o projeto. Não foi difícil te convencer, pois você precisa da fatura. Qual metodologia vai te salvar? Em casos assim, é sempre erro de negociação ou o projeto pode ser metodologizado* direito?

   *Dá pra sentir o quanto eu gosto da palavra metodologia

4. Por que é tão difícil segurar gente boa na equipe?
   Provavelmente o seu talentoso colega vai trabalhar num lugar que oferece praticamente as mesmas CNTP para a proliferação de programadores medíocres: projetos mal geridos, chefes acomodados, clientes insanos e café ruim. Tudo por 1 ou 2 reais a mais à hora. Por que tantas empresas insistem em tratar programador como commodity? (Os signatários do blog já viram pessoas sendo pagas para dizer isso.)
5. Por que é tão difícil mandar os incompetentes embora?
   Qualquer pessoa que faça a mesma coisa do mesmo jeito há mais de um ano está acomodada. Uma empresa que aceita um recurso desses, também. Desconfio que quando ela hesita em mandar incompetentes embora alegando “perda de conhecimentos esclerosados acumulados”, ela quer dizer “somos incapazes de fazer avaliação profissional objetiva”. Engraçado: cadê o programador-commodity nessas horas?
6. Existe uma palavra melhor para iteração?
   Essa palavra é muito pedante. Só os iniciados sabem do que se trata, e os demais ficam pensando em “interação”. Que, na boa, pode muito bem se referir à mesma coisa. Não estou falando de “iteração de loop/enumeração/lista”, onde a tal palavra é indispensável. Agora, falando de projetos, com gente normal (não-programadora), que se fale então em ciclo, passo, ação, ou interação mesmo — preciosismo pra quê, meu deus.
7. Por que as empresas acreditam em antivírus?
   Vou ter que interromper a escrita das FAQs pois o antivírus começou a executar sua rotina diária. Ele não vai encontrar nenhum vírus mas a empresa vai dormir tranqüila. Enquanto isso, estou numa máquina Windows com direitos de admin local e o único browser que posso usar é o Internet Explorer 7. Paciência.

Ultimamente eu tenho me sentido um pouco Josef K, daquela história. Acordo sem peso na consciência, mas basta abrir a porta (ou o Google Reader) e parece que o mundo decidiu que eu preciso tomar parte de um processo, o qual quanto mais eu tento compreender, mais enrolado, culpado e incompetente eu tenho que me sentir.

“O processo” aqui é todo o conjunto de metodologias, patterns, mindsets e filosofias que, se eu não absorver e professar, não sou digno nem de abrir o Visual Basic 4. Claro que ficar expert no processo não é coisa simples assim como ler um blog ou ler um livro. Além de estudar, você tem pôr em prática, compartilhar o conhecimento e encantar as pessoas ao redor, ao mesmo tempo. Você tem que se tornar um especialista em tudo e ter uma wikipédia implantada na cabeça, pra não se esquecer de nada.

De todas as suas especialidades, você deve conhecer os patterns, os anti-patterns, como aplicá-los, como não aplicá-los, os casos de sucesso e os fracassos. E não basta todo o conhecimento puro e simples. Isso é fácil de ter! O passo 1 na sua hierarquia de necessidades é adquirir uma técnica apurada, ficando fera do assembly ao Haskell, do file system à enésima forma normal, do calloc() ao GC, sem tropeços.

Depois você precisa expandir um pouco os seus horizontes com o estudo das metodologias que fazem um software nascer, crescer e vencer. É preciso saber como um projeto é gerido, como os programadores funcionam, o que o cliente realmente quer… enfim, satisfazer todos os stakeholders, como você vai se acostumar a dizer. Tudo isso dentro do orçamento que você vai obviamente saber controlar para depois calcular o ROI — coisa simples, admita.

E já que está manjando de finanças, o degrau a seguir é acompanhar o mercado de IT corporativo e open-source, para conhecer os produtos, estratégias, mergers, winners e losers. E, conhecendo, escolher o que é melhor. Não vai querer ficar pra trás, né? Não vai ser difícil para alguém tão inteligente quanto você.

Ficará evidente que você não passa deste ponto do processo se não souber aplicar toda a sua expertise na forma de arquiteturas ágeis, interfaces ágeis, teamwork ágil e comunicação ágil. Claro, a esta altura absolutamente tudo o que você faz é ágil de alguma maneira. (Sua namorada pode reclamar, porém.) Este momento é crítico na sua carreira, pois você não pode errar só porque seu desempenho tem que estar num ponto ótimo dentro de 10 ou 12 dimensões. Por sorte, você conhecerá todas as métricas e seus benchmarks, para poder guiar a si próprio e sua equipe.

Então, passando esses níveis de subsolo você está pronto pra atingir o térreo do desenvolvimento bacana de software. Você já tem experiência e conhecimento suficientes para exercer sua profissão em alguma empresa 2.0 (quiçá 3.0!) por aí. Já poderá participar de discussões de arquitetura, engenharia e filosofia de software nos blogs. Você venceu o processo.

Quanto aos Josef K da vida… bom, você sabe o que acontece no final.

Diferente do meu blog, onde o foco é apresentar as idéias “mastigadas”, aqui eu pretendo gerar discussões para que possamos entrar num consenso.

Primeiro, deem uma olhada neste artigo que apresenta bancos de dados como commodities, ou seja, qualquer um serve. Depois tem mais esses posts sobre ORM e Frameworks que também acho interessante.

Agora gostaria de saber a opinião de vocês: dado um sistema não crítico de mercado (tipo um CRM, e-commerce, portal, etc), onde mais de 50% das funcionalidades são CRUD, 30% relatórios e os 20% restantes alguma lógica e processamento, a escolha do banco de dados e a forma com que os dados serão manipulados são os principais fatores determinantes do sucesso de um projeto?

1… 2… 3… Valendooo!

– Inaugurando a minha participação no blog –

Sabe aqueles quadros que costumam vender na rua? Esses de feirinha, que são verdadeiros clássicos: casas toscas num gramado, cenários praianos, coisas deste naipe. São parte do que é chamado de arte naïf: obras não necessariamente intelectuais ou acadêmicas. Que podem até ser tecnicamente bem-feitas, mas dificilmente vão transformar seus autores em Van Goghs, mesmo que eles arranquem as próprias orelhas com os dentes.

Lembrei dessas coisas no mês passado, quando eu estava a ponto de precisar desenvolver um parser para uma certa linguagem de programação antiga. O parser seria um pedaço de uma ferramenta que extrai informações sintáticas e estruturais de um programa a partir do seu fonte — coisa que qualquer IDE atual disponibiliza quando se faz refactoring ou checagem de referências e dependências. Mas, como a tal linguagem não tem exatamente um IDE, a ferramenta (e o parser) tem que ser desenvolvidos “do zero”. E lá estava eu estudando as necessidades do meu trabalho.

Em pouco tempo concluí (instintivamente, não objetivamente) que o ideal era construir um mecanismo de parsing genérico, que servisse para qualquer linguagem. Entendi que esse mecanismo era possível de existir, desde que o léxico (sintaxe para definir sintaxes) fosse potente. Foi divertido então definir um léxico que permitisse uma estruturação a la BNF. E de forma bastante ingênua parti para montar um protótipo de parser. Um protótipo que entendesse uma linguagem simples. Um parser de XPath, por exemplo, só pra começar…

Foi aí que eu vi que ainda preciso comer muito arroz e feijão! O fato é que eu nunca precisei fazer um compilador na faculdade (ha!), e portanto não sabia que o buraco é muito mais embaixo. Existe um monte de formas de se construir um parser, uma porção de ferramentas, documentos, exemplos… e eu lá, escavando a pedra pra fazer a roda.

Pra mim foi interessante entender como esses mecanismos funcionam, e também foi bacana ter imaginado alguns algoritmos que, depois vi, são usados no ramo há muito tempo. Mas o ruim da história é ter entrado num caminho arriscado ao criar uma solução duvidosa, por pura ignorância. Nesse episódio eu fui um engenheiro naïf!

A minha “obra” até poderia ser passável tecnicamente, mas sem dúvida eu deixaria uma série de defeitos para trás, que qualquer um mais capacitado iria bater o olho e pensar: mas quem fez esta merda? Que é mais ou menos o que eu penso quando vejo uma ou outra pog alheia…

Seu código se sentiria à vontade na feirinha hippie?