Feliz 2013 e isso tudo, foi bom e sobrevivemos, facto não somenos importante. Mas adiante, que a Terra girou, o tempo passou e a altura para novos voos chegou. É, estou no mercado, levantando a calçinha para quem der mais e melhor, porque é assim a ordem natural das coisas. Porquê, perguntam-se? Acho que foi um conjunto de razões pessoais e profissionais, algumas das profissionais sentidas muito pessoalmente. Primeiro, sou pago abaixo do meu nível. Sou estrangeiro em terra estrangeira, facto muitas vezes aproveitado pelos empregadores de países relativamente desafogados, que vêem uma oportunidade para prestar serviço social ao meu país enquanto baixam os custos operacionais. Infelizmente não consegui fazer valer os meus trunfos da melhor forma quando aceitei este emprego, algo que tenho tentado corrigir desde então. Segundo, não me sinto valorizado profissionalmente. Como assim? Passado mais de um ano e continuam a atribuir o mesmo tipo de tarefas chatas que te entregavam no início. Por agora devem estar a pensar: "porra, se te dão as mesmas tarefas chatas é porque tu provavelmente não mostraste competência para mais, né? Bruxo.". Penso que não foi isso. Tem mais a ver com a situação em que me encontro.
Introdução
Faço parte de uma equipa de desenvolvimento formada por 3 pessoas, ate há 1 mês por 4. Um de nós é o encarregado pelas operações IT (CTO a partir daqui). Faz basicamente administração do sistema e servidores, trata da distribuição das iterações, para além de (pouco) desenvolvimento. É, um pouco por causa da posição que detém, considerado o "líder" do grupo. O outro é o auto-proclamado "Chefe dos Designers". Quando entrei na empresa, perdia cerca de 40% do tempo no tratamento da apresentação das aplicações web, e no resto do tempo programava. Hoje praticamente só programa, apesar de manter o mesmo título. ("ex-designer" a partir daqui). É responsável directamente por grande parte do código e indirectamente pela maior parte dos problemas de que sofremos de momento (já voltarei ao tema). O membro que falta (recém-saído da empresa) era desenvolvedor a tempo inteiro, saído 9 meses antes da sua entrada na empresa da universidade (estava há 3 meses na empresa quando entrei) e com pouca experiência no desenvolvimento web, embora com vontade para aprender ("outro" a partir daqui). Quando entrei na empresa, caí num projecto já estabelecido, com uma base de código gigantesca e não documentada, e 4 meses depois iniciámos o desenvolvimento de raíz de um segundo projecto que veio a substituír o primeiro como prioridade de topo da empresa.
Avaliação da equipa de IT
Depois de longa análise, entendi que me encontrava numa equipa em estado avançado do princípio de Peter. Para o compreender é preciso ter em conta a história da empresa anterior à minha entrada.
O projecto foi iniciado 3 anos antes da minha entrada. Na altura, faziam parte da equipa 3 desenvolvedores, e durante esses 3 anos o número de membros oscilou sempre entre 3 e 5. O CTO anterior era respeitado pela comunidade ruby do país e desenvolveu alguns projectos interessantes. Devido ao turnover relativamente moderado e número baixo de elementos-núcleo, nunca chegaram a implementar medidas de colaboração na equipa. Implementavam extreme programming ao máximo. A dívida técnica foi-se acumulando. Entretanto chegou à empresa um estagiário, desistente de uma escola de cinema, para completar tarefas de design. Foi desempenhando a sua função de modo satisfatório, razão pela qual eu penso que o convidaram para se juntar a tempo inteiro à equipa, com enfoque especial na colaboração directa com a equipa de IT e no design da plataforma. Travou amizade com um dos membros da equipa de IT e começou a desenvolver interesse pelo lado da programação, tanto que começou a fazer uma perninha em algumas tarefas nesse âmbito.
Cerca de 6/7 meses antes da minha entrada, o CTO original decide doutorar-se e procurar outras pastagens, decisão que possivelmente terá causado algum pânico, pois numa empresa com tão poucos empregados, o conhecimento é geralmente muito centralizado. Um dos outros membros da equipa inicial também decide sair, sobrando o terceiro membro para carregar a bandeira. Imagino que tivesse pouca experiência com a administração dos servidores e tenha sido instruído da melhor e mais rápida maneira possível. O que é irrelevante para a discussão. Não só isso, como um segundo membro importante da equipa saía, tinham que suprir da melhor forma a falta desse outro recurso. O resultado? O estagiário-agora-membro designer passou a fazer mais que uma perninha, passou a enfiar as duas mais um braço. Chegados ao momento da contratação do meu colega "outro" recém-saído, faziam então parte da equipa um dos desenvolvedores iniciais, com 0 experiência de liderança e a dar os primeiros passos na administração do sistema, e um sujeito que passou de designer estagiário a membro em regime de tempo parcial da equipa de desenvolvimento em menos de 2 anos. Ambos (o primeiro principalmente) eram então os responsáveis por uma base de código e conteúdos gigantesca (para cima de 30 tabelas na base de dados) e não documentada.
Pausa para reflectir: Ficaram vagas por preencher que exigiam alguma responsabilidade e experiência. Duas possibilidades: procurar pessoas com o mesmo grau de competência para preencher as posições em falta (a opção inteligente) ou promover elementos da equipa (a opção mais barata). Alarme Princípio de Peter. Primeiro sintoma? Ao receberem o novo elemento na equipa, não o integraram na base de código existente de maneira a facilitar a sua adaptação, mas responsabilizaram-no pela integração dos serviços da plataforma numa plataforma embebível no facebook. Um outsourcing quase interno. Esta era a ocupação do novo elemento quando eu entrei na empresa.
Qual era o meu perfil à altura da entrada? Eu era alguém já experienciado no desenvolvimento web e Rails, relativamente independente. Não era nenhum ás, mas já tinha bastante confiança tanto com a framework como com a linguagem de programação. Esperava-se de mim, pelo que entendi, preencher a vaga do segundo membro original de imediato e com o passar do tempo responsabilizar-me por tarefas de manutenção dos servidores que eram do encargo do CTO. Para além disso iria iniciar-se o desenvolvimento do tal segundo projecto mencionado acima, que foi pensado na altura como um spin-off da plataforma principal, e eu estaria na linha da frente no desenvolvimento desta. Apesar de não conhecer o passado da empresa, compreendi o que esperavam de mim, e fiz por isso. Completava as minhas tarefas e sugeria até algumas melhorias à plataforma existente. Exemplo? Cada utilizador da plataforma tinha um mural como o do facebook, onde se formava uma corrente de posts vindos da própria plataforma e das redes sociais associadas à conta. No meio do conteúdo vinham links, que eram apresentados como links textuais. Eu desenvolvi um widget para embeber esses links nos posts, por iniciativa própria. Não o escrevo para me gabar. Quero somente esclarecer que, enquanto aqui estive motivado, produzi, colaborei, dei o corpo ao manifesto, não tomei nada por garantido. Outros exemplos? Na primeira semana, pedi documentação do projecto ao CTO, do qual ouvi a resposta "aqui nunca precisámos". Quando insisti que, enquanto membro novo da equipa, precisava eu, respondeu-me que iria "tratar disso". Passaram 3 meses, altura em que sugiro uma apresentação sobre documentação à equipa de desenvolvimento e apresentei várias ferramentas para rails e javascript que nos permitiam documentar o nosso código e apresentar a documentação em formato HTML... excepto para javascript, que não tinha um gerador de HTML fiável... e aí eu programei um. E passámos a ter documentação. Durante cerca de um ano implementámos scrum na equipa, por minha sugestão. Como eu disse, eu tava aqui para melhorar a mim e aos que me rodeavam. Jogador de equipa, camisa 10, distribuindo passes, "there is no I in TEAM".
Com o passar do tempo, a situação foi-se estagnando. Nunca cheguei a aprender da administração dos servidores. Nunca cheguei a assumir novas responsabilidades. O único projecto que me passou totalmente para as mãos, o desenvolvimento de uma REST API para a plataforma secundária-agora-principal, foi minado desde o início pelos membros anciãos da equipa, desde a escolha da framework (3 meses depois de iniciado o desenvolvimento) até à prioridade de integração no projecto principal (não está ainda em produção, e provavelmente vou sair da empresa sem que esteja). Passou-se o mesmo com as responsabilidades de administração do servidor, que nunca cheguei a tomar para mim. E com os outros, o que se passou?
- CTO: Com a perda de importância gradual da plataforma inicial foi cada vez tendo menos mão na parte do desenvolvimento, preocupando-se somente com a manutenção das iterações, integração contínua e administração do servidor. Escreveu alguns scripts para importar conteúdo externo de parceiros estratégicos; assumiu a posição de scrummaster nos nossos scrums, se bem que isso foi mais fruto da sua condição de CTO do que das suas qualidades de liderança naturais, as quais não possui; isso ficou bem patente na gestão dos conflitos pessoais e profissionais entre o ex-designer e o "outro", que chegou a incluir agressões verbais por e-mail. Nunca soube também gerir a descentralização de conhecimento na equipa, talvez devido à sua falta de interesse no assunto. Partilhar o seu conhecimento representava delegar tarefas e perder importância no grande esquema empresarial. Notei também o seu enfado com a parte do desenvolvimento, para a qual já não contribuía tão activamente, salvo as ocasionais correcções de erros de produção ou recolocação de ficheiros em pastas diferentes. E quando menciono "desenvolvimento" no seu caso quer isso dizer desenvolvimento do lado do servidor, porque os seus conhecimentos do lado do cliente foram sempre insatisfatórios: o HTML era algo circunstancial para ele, o CSS algo que não compreendia bem e abominava até (compreensível, sou tão pouco o maior fã), mas algo que eu não compreendia era como o seu javascript era tão pobre. Era tão pobre que ele delegava responsabilidades nesse departamento ao ex-designer, muito mais interesado nessa vertente. E: nunca soube separar a relação de amizade da de colega de trabalho com o ex-designer, algo que certamente não ajudou.
- Ex-designer: Com o envolvimento cada vez maior no desenvolvimento da nova plataforma, a sua importância aumentou. Como aconteceu esse aumento de envolvimento? Quando foi dado o "ok" para o início do desenvolvimento, o design apresentado ainda não tinha sido totalmente validado pelo resto dos responsáveis na empresa. Isso levou a que sugestões aparecessem na fase de apresentação de determindadas funcionalidades tais como o motor de busca, sugestões essas invasivas que criavam incerteza, tanto no desenvolvimento como no design. Eis que o ex-designer, já programador oficial, se fechou em copas quanto ao design, e começou a desenvolver a plataforma sozinho, de acordo com o que achava que seria melhor. Ou seja, foi desenhando e programando ao mesmo tempo sigilosamente. Debatia as suas decisões (quando debatia) com um círculo muito fechado de pessoas. Quando a plataforma foi lançada, era claro que o nosso amigo ex-designer se tinha tornado de facto parte integrante da equipa de desenvolvimento a tempo inteiro. Toda esta situação e a importância que adquiriu ajudou a que a sua atitude se tornasse cada vez mais pedante para com os seus colegas, excepto claro para com o seu grande amigo CTO. Escusado será dizer que ainda sofremos hoje tanto com as suas decisões técnicas, que tem sido refactorizadas há mais de um ano mas estão ainda longe de resolver tudo, como com as suas decisões relativas ao design, que por sugestão de um dos então investidores, teve que ser totalmente reformulado três meses depois. Falando de decisões técnicas, vou mencionar 2 das minhas preferidas:
- o sujeito, descontente com o estado do código javascript da plataforma anterior (e com razão, era esparguete até mais não), decidiu aplicar os seus conhecimentos adquiridos de programação para objectos ao código a ser executado no cliente, e desenvolve a sua mini-framework MVC para javascript, completa com renderização do lado do cliente utilizando uma biblioteca já na altura deprecada (sobre o que foi avisado). O desenvolvimento da framework incidiu bastante sobre aproximar a API de um objecto Javascript à de um objecto Ruby. A manutenção desta mini-framework MVC tem sido atribulada (a cada semana, aparece algum erro novo, ou algum método ou alguma assinatura de alguma API é removido, renomeado ou inserido). Está longe de ser uma ferramenta utilizada por todos os membros da equipa, devidos aos erros constantes provocados pelas mudanças. Agora vou só listar algumas frameworks open-source que pululam por aí: ember.js, backbone.js, angular.js . E concerteza há mais. Está tudo dito.
- o sujeito, descontente com a forma como a pesquisa era processada, com pedido Ajax GET do navegador enquanto os parâmetros de pesquisa eram guardados no parâmetro cardinal (#) do cliente (html5 hashchange) (e especialmente com esta última, por não ser uma solução suportada fora-da-caixa no Internet Explorer 7), decide alterar totalmente toda a estrutura, introduzindo o conceito de objecto de pesquisa, onde são persistidos os argumentos da pesquisa. O formulário GET da página inicial passou a formulário POST onde os parâmetros da procura vão directamente parar à base de dados, passando o formulário da página dos resultados a responder com PUT, sendo cada pesquisa uma actualização do estado da pesquisa no servidor. E assim reinventou-se a roda... Resultado? Recursos alocados para guardar algo que não deveria ser guardado e que não representa valor para a empresa (a pesquisa); guardando o estado na base de dados, fez com que efectivamente a pesquisa deixasse de ter estado no cliente. Não entendem o que quero dizer? Experimentem implementar uma solução assim, fazer 10 pesquisas, e depois carregar no botão do navegador para voltar atrás. Com e sem implementação Ajax da procura. Dica: as vossas 9 procuras anteriores perderam-se... Uma nota em relação à implementação inicial: deixámos de suportar o Internet Explorer 7. Parece que houve qualquer coisa a ver com o design que motivou a decisão... Quanto ao resto, só tenho isto a dizer: html5 history API.
- E onde estamos hoje? A sua posição de "Chefe Designer" que já não desenha junto com a importância para a manutenção do imenso código inconsistente que produziu tornou-o num elemento imprescindível para o parco futuro que esta empresa possa vir a ter. Tornou-se indispensável pelas piores razões. Defende com unhas e dentes o que desenvolveu e opõe-se veementemente à sua reformulação/substituição. E não desenha (repito-me).
- Outro: Nem sei bem o que dizer do terceiro elemento. Era claramente inexperiente quando chegou. Não pescava nem muito Rails nem muito Ruby. Nem tão pouco javascript. O javascript dele era horrível, tenho que ser sincero. Ele diria que sabia mais de C, e provavelmente teria razão. Era um terrível comunicador. Falava alto e num tom um pouco irritante. Como eu, era estrangeiro. Comunicava em inglês com a equipa porque não falava a língua do país. O seu inglês era cheio de erros e possuía um sotaque genuinamente terrível, sendo difícilmente compreendido até por ingleses. Não fez um mínimo esforço na aprendizagem da língua daqui, e teve oportunidades para isso, mas preferiu desinteressar-se do assunto e comprometer indirectamente a sua integração, tanto no país como no trabalho. Não sendo pedante, era algo fanfarrão.
- Por outro lado, sabia reconhecer as suas limitações, e tentava procurar alguém que lhe direccionasse. Não sendo muito independente no trabalho, compensava sendo consciente. Mas foi pessimamente integrado na equipa. E a comunicação foi só uma pequena parte. Foi sempre colocado em tarefas e projectos que lhe mantinham à margem das grandes responsabilidades. O seu papel nunca foi diminuído, porque sempre foi minimal. As suas ideias e sugestões eram geralmente rebatidas ou silenciosamente ignoradas. E algumas eram realmente boas sugestões. Exemplo? Contextualizar os commits do git relativamente à tarefa em questão, para que as listagens se compreendessem melhor. Só eu peguei nessa dica. O CTO nunca soube como o utilizar bem, vendo nele provavelmente alguém com um curso tirado num país de segunda categoria e em quem não reconhecia competência técnica nenhuma. Chegou mesmo a comentar que o ex-designer era melhor tecnicamente. O que talvez não fosse mentira, dependendo do contexto. Mas se eu nomeasse "waterfall" ao ex-designer, não sei bem o que me responderia. A propósito, a relação com o ex-designer foi especialmente atribulada. O ex-designer parecia partilhar da opinião relativa ao país de segunda categoria, mas era muito mais verbal. E o outro, não gostando de ficar atrás, puxava dos galões com o seu curso universitário adquirido, que era claramente algo que ficava a remoer na cabeça do ex-designer, de formação nem designer, nem programador. Todo este atrito se revelou péssimo para a equipa, motivou debates acesos sobre conceitos e metodologias, e-mails abertamente ofensivos e um clima de guerra fria dentro da equipa de IT, que no conjunto amputou a nossa relação tanto pessoal como profissional, e agravou a consideração já de si minimal que a equipa-núcleo nutria pelo "outro".
- Porém, no final, saiu de cena com a graça de quem nasce com o cú virado para a lua (com todo o mérito): Numa fase em que a empresa já o tentava amigavelmente "recolocar", decidiu tomar a iniciativa e encontrar ele colocação, e eis que surgiu uma oportunidade para trabalhar para a principal empresa de telecomunicações do país. Vai receber formação, mudar para uma área com mais saída (redes), vai manter o foco em Ruby, e no final vai ser um muito melhor profissional do que alguma vez teria sido ficando nesta empresa, porque vai estar integrado num sistema de avaliação mais impessoal e ao mesmo tempo menos falível, e onde as suas qualidades podem ser valorizadas e as deficiências colmatadas. Desejo-lhe sorte. É um rapaz que genuinamente quer aprender e ser melhor profissional, que não se coloca acima da equipa e que gosta de trabalhar, e sob as condições certas tem tudo para se tornar melhor profissional. Só tem a ganhar. Agora tem é que aprender a língua daqui e acabar com a falha de comunicação se quer vingar.
Avaliação da empresa
A empresa é um caos. Desorganizada em todos departamentos, dos quais só me foquei no que me diz respeito, mas onde todos contribuíram directa ou indirectamente para o desfecho que se avizinha. Passo a explicar: quando eu entrei na empresa, esta já estava algo estabelecida no mercado nacional com o produto principal, uma rede social para o mundo da música. Porém, já se sentia a pressão da competição internacional, e cada vez mais apareciam outro tipo de aplicações que giravam em torno de manter, disponibilizar e comercializar conteúdo musical online. A empresa achava que tinha um trunfo para se nivelar no seu produto seguinte: uma plataforma feita sobre a principal, que permitia licenciar rapidamente conteúdo musical para vários tipos de uso. A decisão inicial foi utilizar o conteúdo da plataforma principal, consequentemente limitando o escopo da ideia e dirigindo o desenvolvimento numa direcção que se provaria errada. Quando eu entrei, já tinha sido desenvolvida uma solução para estabelecer planos de preços para licenças na plataforma principal, apesar de não haver plataforma secundária nenhuma. Os constrangimentos começaram. Quando comecei a desenvolver o primeiro rascunho da plataforma, decidiu-se reutilizar a mesma base de código da plataforma principal. O constrangimento das adaptações anteriores já se encontrava lá, e conceptualmente argumentava-se ser o mais correcto, pois não se visualizava uma plataforma sem a outra. Gerou-se deste modo um monólito. Foi este monólito que foi lançado há cerca de um ano, com direito a conferência de imprensa, aperitivos, tudo. A ideia parecia ter sido validada. Mas, com o passar das semanas, reparou-se que ninguém licenciava conteúdo. Um mês passou, uma compra. Algo não parecia bem. Por esta altura, já trabalhava connosco alguém que supostamente iria "melhorar os nossos processos de negócio". Ele começou a introduzir conceitos completamente alienígenas naquela empresa, tais como "testes de usabilidade", "testes A/B", "métricas de usabilidade". Em 2 semanas conseguiu convencer todos os decisores de que o produto precisava de um design completamente novo (imaginem como isso não feriu o orgulho do ex-designer). Ao mesmo tempo a importância deste segundo produto começou a aumentar, começando a ser foco da estratégia de marketing da empresa, que por esta altura continuava à procura de mais investidores. Começaram a ser estabelecidas parcerias estratégicas com outras plataformas web de conteúdo musical, sendo este exportado para a base de dados da plataforma secundária, que passou a ter então uma mistura não muito consistente de conteúdo musical da plataforma musical sujeito a sincronização e conteúdo de parceiros assim devidamente marcados. Foi desta altura talvez o pior código-esparguete que jamais vi. As reuniões para aprovar as novas propostas de design intensificavam-se. Claramente havia uma facção dos decisores que estava permanentemente descontente com as propostas e outra que se colocava do lado do responsável pelo design. Enquanto isso, eu completava a actualização das duas plataformas de Rails 2 para Rails 3 (quem já teve que o fazer sabe que é um esforço hercúleo). Foi aí que tudo aconteceu ao mesmo tempo: o novo design foi finalmente aprovado, a actualização foi completada com sucesso e a equipa foi informada que a manutenção da plataforma principal iria terminar, passando o nosso foco para a plataforma secundária, que a partir daí iria se separar conceptualmente da sua irmã siamesa. Ficámos então com um monólito actualizado, 70% do qual nunca mais iriamos ver, e 30% do qual iria ser extraído para um projecto autónomo e independente. Para a semana seguinte foi então marcada uma reunião para apresentar à equipa em geral o novo design, no qual não tinham participado nem decidido. E esta foi talvez a reunião profissional mais surreal que já tive: para além de apresentarem o novo design, que repetia alguns dos erros do design anterior e acrescentava alguns novos (tais como botão para registo do utilizador no canto inferior direito!!), numa manobra de ilusão de colaboração, quiseram integrar o resto da equipa, permitindo-lhes escolher por voto a cor base da plataforma!! Limitaram a nossa escolha a 7 cores e 3 padrões também. Obviamente que a equipa, aterrada de pára-quedas nessa reunião, mal conseguiu esboçar uma opinião sobre o assunto. Para simbolizar o processo, deixo aqui a escolha de um colega meio-holandês: "Escolho o laranja, porque enfim, sou holandês".
Foi nesta altura que se começou a falar de que provavelmente iríamos necessitar de uma API externa, para facilitar a importação de conteúdo para a nossa plataforma. O outro estava encarregado da integração da autenticação na plataforma, e o ex-designar com a implementação do novo design. O CTO estava entretido com scripts de importação e manutenção do servidor. Eu fiquei encarregue da nova tarefa. Perguntaram-me se a API estaria pronta daí a 2 semanas. Apeteceu me rir. Mas comentei que precisava de tempo para analisar alternativas. Para mim, era claro que, ou se começava a separar as aplicações e as várias componentes, desfazendo o monólito, ou a API teria que ser feita em cima do monólito. Fui pela primeira opção, porque gosto de sofrer. Comuniquei que era impossível começar com a API sem pelo menos primeiro separar a base de dados existente em duas, uma para cada aplicação. Tarefa simples, pensei eu. O pesadelo que se tornou portar os dados de uma base de dados para a outra roubou-me 3 semanas. Quando terminei, comecei então a implementar a primeira versão da API, usando uma framework mais minimal que o Rails para o efeito, e programando um mapeamento de dados diferente para o efeito. Por esta altura, a empresa começava a dar os primeiros solavancos, quando o nosso "optimizador de processos" bateu com a porta, citando diferenças de direcção com o nosso CEO. Eu pensei comigo mesmo que todas as resistências na escolha do novo design e desagrado geral com o modo de fazer as coisas na empresa também contribuiu, não só para o seu fraco desempenho, como para a sua saída eventual. Com ele levou dois potenciais investidores. E quando o dinheiro prometido voou, foi logo marcada nova reunião. Foi comunicado que o "outro" iria ser "emprestado" para um projecto de um amigo do CEO enquanto se aguardava mais financiamento, e que o ex-designer iria pegar nas tarefas dele. Não faço a menor ideia o que ocupava o CTO. Mas, mais uma vez, a responsabilidade de uma das funcionalidades fulcrais no futuro da plataforma e da empresa iria passar para as mãos do ex-designer. Que logo nessa altura começou a mover esforços para detonar o meu trabalho. Reparou que o meu mapeamento para a base de dados não fazia tudo o que o mapeamento original fazia. No que lhe dei razão, era válido o que dizia. Depois questionava a minha escolha, porquê DataMapper e não o ActiveRecord original. Argumentei que queria experimentar uma coisa nova, mas que estava disposto a estudar possibilidades. Ele tomou por iniciativa substituir em um dia os modelos DataMapper pelos ActiveRecord. Como era de esperar, não o conseguiu. Aí pressionou o CTO para me fazer voltar atrás e fazer tudo com Rails. E aí foi quando pisaram um calo. Não era da competência dele me mandar fazer o que quer que fosse. Foi marcada reunião, em que os dois me tentaram demover, colocando argumentos que só expressavam a preguiça mental dos ditos cujos ("o Rails a gente já conhece", entre outras razões semelhantes). Bati o pé. Aí pressionaram-me. E eu reagi como animal agrilhoado: com agressividade. Disse-lhes que a tarefa era minha, a decisão era minha, que já a tinha tomado fazia meses, e que ninguém me ia dizer o que fazer por ter pesquisado no tema 3 dias quando eu tinha lá andado 3 meses. E terminei por dizer que da consistência do mapeamento com ActiveRecord encarregava-me eu. A reunião terminou em tom pesado. Mas daí a uma semana os modelos tinham sido portados com sucesso.
Mas isso representava outro problema: eu não podia simplesmente copiar as coisas de um lado para o outro; de alguma forma os modelos tinham que ser partilhados. E ainda não tínhamos desfeito o monólito completamente. Aí eu disse ao CTO: inviável sem separar as aplicações. E aí passou a minha sub-tarefa. Portei os ficheiros para a segunda aplicação. Depois portei o código para a segunda aplicação. Foi longo e moroso. Tal como o seguinte: passar o mapeamento da base de dados para uma biblioteca partilhada. Algo que saía do âmbito do Rails e o qual eu nunca tinha feito até altura. Mas consegui. A biblioteca funcionou, foi partilhada nos dois projectos (aplicação e API) e deste modo calei algumas bocas.
Com isto aproximava-se o Natal. E aí caíu a bomba: os investidores estavam a ficar impacientes. Queriam já estar mais acompanhados por essa altura. Ameaçaram fechar a torneira. Os empregados foram então chamados um por um, e foi-lhes comunicado que não poderíamos continuar a pagar aquele escritório, e que teríamos que transitar até ao final da semana seguinte (!) para um novo espaço. Para além disso, questionaram-me qual seria a minha disponibilidade para trabalhar a 50% até à próxima ronda de financiamento, daí a 3 meses. Pois é, a barra caíu em cima do pé. Disse que a disponibilidade era nenhuma. Tentaram demover-me, apelando ao meu espírito de equipa e ao facto de que o resto da equipa iria também sacrificar-se pelo bem comum. Cedi em parte: acordei trabalhar um mês em regime de 50%, ao que me foi respondido que, para adquirirem fundos, iriam tentar colocar-me num projecto externo por 2 meses para assegurar os fundos para me custear. Dezembro, mês do Pai Natal.
E cá nos encontramos em 2013. O lançamento das plataformas separadas anteriormente conhecidas como monólito foi cumprido no final de janeiro com sucesso, sensívelmente um ano depois do lançamento oficial da plataforma então secundária. A versão com a biblioteca partilhada aguarda ainda pela completação da área de utilizador que está a ser finalizada pelo ex-designer, tarefa essa que tem basicamente bloqueado tudo o resto, fruto de outras inconsistências na gestão das iterações ás quais o CTO não é estranho. Estou sem tarefas, em parte porque as fichas estão todas no lançamento dessa nova funcionalidade, em parte porque brevemente serei "transferido" por 2 meses para um projecto fora da empresa, mas perto do coração: um website para a loja de utensílios de cozinha da mãe do meu CEO. Porquê? Pois, qual é a empresa externa que tem o interesse de dispor de mim por um período tão curto como são 2 meses? Não encontrando ninguém para me custear, a solução acabou por vir de dentro. Deveras glamorosa.
Análise de Resultados
Aqui espero demonstrar que esta empresa, para além da falta de estrutura, foi vítima do princípio de Peter. Vejamos:
- CTO: Foi em tempos um mero desenvolvedor, com bastante competência até, julgando o grau de satisfação na resposta a dúvidas da equipa. Em questões de Ruby era claramente em quem a maior parte da equipa confiava. Porém, nunca provou qualidades de liderança: não soube moderar os conflitos internos, foi hesitante na tomada de decisões e não soube aproveitar as qualidades nem colmatar as deficiências dos membros da equipa. A responsabilidade que detinha em tarefas de administração do sistema impedia a sua participação naquilo que (ao que parece) fazia melhor: bater código. Demonstrava frequentemente comodismo na sua atitude. Não querendo concluir que foi promovido até ao seu mais elevado grau de incompetência, fico pelo menos com a ideia de que a sua produtividade estava claramente amputada.
- Ex-designer: Talvez o curto período de carreira mais bem-sucedido de sempre, saltou em 3 anos de estudante de cinema para estagiário de design para designer a tempo inteiro para designer/programador para programador, um verdadeiro camaleão. Vinha de um contexto completamente diferente dos outros membros, de um meio artístico, e agia desse modo com o projecto, tratando-o como a sua obra magna, a sua Mona Lisa.É um auto-didacta, e como tal tiro-lhe o chapéu pelo que aprendeu em tão curto espaço de tempo, mas há certas coisas que os tech-blogs não ensinam. Quando eu andei na universidade, programar era só uma parte do jogo; salvo a rara excepção para implementar algoritmos, nunca pude escrever código para projectos sozinho, estive sempre inserido em grupos, o que implicava metodologias de trabalho, que, obviamente, nem sempre eram implementadas de forma correcta, mas que à chegada da meta se revelaram lições importantes. Aqui incluo conceitos como documentação, modelação de processos, diagramas de arquitectura de software, análise de requisitos, conceitos completamente alienígenas para o meu colega. Como designer, sofreu com o mesmo tipo de falta de conhecimentos: ignorava a existência das heurísticas de usabilidade de Jakob Nielsen, conceitos básicos de interface homem-máquina, design adaptável; para ele o ecrã do seu Mac era uma tela por preencher. Frequentemente programava em sigilo absoluto e a acumulação de responsabilidades como designer e programador levava-o a confundir as suas tarefas. Quando penso nele lembro-me do Francis Ford Coppola: quando era um zé-ninguém e ninguém lhe valorizava sai-se com "O Padrinho"; quando lhe deram rédea livre e recursos ilimitados, gastou rios de dinheiro no "Apocalypse Now" e acabou por prejudicar os seus empregadores, tanto que nunca mais iria dispor de orçamentos daquele nível.
- Outro: Não tendo tanta experiência na matéria, era claramente um activo a valorizar, pois tinha os fundamentos base para ser competente a médio prazo. Acabou por ser vítima do princípio de Peter, pois a delegação de tarefas importantes implicava perda de controlo e importância dos outros membros da equipa, da qual não abdicavam levemente. Foi sempre mantido em projectos paralelos e tarefas secundárias por essa razão, tendo sido até ao fim o "primeiro a sair caso as coisas dessem para o torto". E foi mesmo. O facto de ser um estrangeiro que não dominava a língua do país não ajudou, obviamente. Mas, profissionalmente, representava um perigo directo para o ex-designer, que corria o risco de perder a sua influência como programador. E isso, penso eu, foi um factor determinante.
- Empresa: Altamente hierarquizada. O núcleo era composto pelo CEO e "chefes" dos vários departamentos (TI, finanças, comunicação, design) que tomavam todas as decisões entre eles, incluindo aquelas para as quais não tinham competência. Nunca conseguiram inserir com sucesso novos elementos neste grupo, geralmente vistos como disruptores da harmonia e espírito de camaradagem existente, principalmente quando palravam sobre "produtividade" e "métricas de análise de desempenho". O círculo de decisões era, portanto, altamente fechado. Por outro lado, passavam a imagem de ser uma empresa aberta e muito informal. Era efectivamente uma start-up, sem muita burocracia, onde ocasionalmente apareci de chinelo para trabalhar. Dos vários estagiários que passaram pela empresa, maioritariamente para geração de conteúdo e comunicação, todos eles gostaram do ambiente completamente relaxado, música ambiente e boa disposição. Mas ser "aberta" é outra coisa. Tinham uma visão totalmente utópica em termos de impacto que o projecto poderia ter, e não compreendiam que, na internet, execução e timing é tudo o que uma start-up tem; se o produto não cumpre o que lhes é vendido nas apresentações e rondas de financiamento na altura certa, só resta o desinteresse, e neste planeta não se tem uma segunda oportunidade para causar uma boa primeiro impressão. Não ter apostado no planeamento revelou-se o maior calcanhar de Aquiles da empresa: desde o lançamento do produto, em fevereiro de 2012, até hoje, ou seja, um ano, as iterações centraram-se em dívida técnica (desfazer o monólito) e reformulação do design e imagem do produto (um péssimo sinal, os verdadeiros designers sabem do que falo); não foi adicionada nenhuma nova característica, nenhum processo da navegação no site foi alterado ou melhorado. Os recursos foram concentrados maioritariamente no desenvolvimento e o marketing foi praticamente esquecido. Em um ano, fundamentalmente, não foi atingido nada de novo nem acrescentado valor ao produto. Aliás, em um ano, perdeu-se o efeito surpresa, e cada vez mais aparecem competidores que aparecem com modelos de licenciamento de conteúdo muito mais inovadores. Exemplo: um dos nossos casos de uso era o licenciamento de uma música para uso num vídeo do youtube através da nossa plataforma. Hoje em dia, o youtube tem um modelo muito melhor: rastreia os vídeos subidos, compara-os com a sua base de dados, identifica conteúdos e os seus autores, e comunica-lhes a utilização do conteúdo, permitindo-lhes vários tipos de soluções, entre elas bloquear o conteúdo ou inserção de anúncios comerciais no mesmo, lucrando indirectamente. Esta solução tornou o nosso produto completamente obsoleto em menos de um ano. É difícil analisar o caso da empresa sem conhecer o contexto, mas tomo a equipa-núcleo como a grande responsável pelo insucesso do produto.
Epitáfio
Não se iludam, já estou na procura de emprego há cerca de mais de 2 meses. Estas coisas levam tempo. É importante não cometer os erros anteriores. Passar de cavalo para burro não seria inteligente da minha parte. Vou ter que jogar bem com as cartas que me saíram: estou (ainda) empregado; pagam-me a integridade do salário; tenho alguns meses até a empresa finalmente concluir que a festa acabou e fechar as portas. Vou ter que aguentar os períodos de inércia associados a esta condição e a falta de motivação que já se instalou. E preparar-me para o próximo passo, colocando a minha atenção em projectos paralelos com esse intuito. Não será fácil, porque a barra está mais acima do que antes, e não vou aceitar qualquer gata borralheira esperando que se torne princesa. O que eu quero? Ser valorizado profissionalmente, alguém em que invistam. Quero organização e uma estrutura definida de responsabilidades. Quero trabalhar na web de amanhã, a pensar nos dispositivos móveis. Quero saber o que faz um bom líder, e saber se conseguiria algum dia assumir essa responsabilidade. Quero levar toda a experiência negativa que acumulei de modo a que não cometa os mesmos erros. E acima de tudo, quero fazer parte de um caso de sucesso. Tornei-me um pouco start-up-céptico. Penso que 90% delas não sabe do que se trata, seguem o último modelo da moda, seja ele rede social ou reinvenções do formato pergunta/resposta. Gostava de fazer parte dos 10% originais, que concebem o mundo de amanhã. Só isso. Espero que não seja pedir muito.
Se for, então que seja para a Google. Mal por mal... eheh, brincadeira.
Volto à tecnologia no próximo post. Até lá, portem-se.
Sem comentários:
Enviar um comentário