Foi um papo entre o professor Costas Lapavitsas - pesquisador do relacionamento entre finanças e desenvolvimento; o jornalista Paul Mason - analista dos movimentos sociais recentes e a influência da tecnologia; Mariana Mazzucato - pesquisadora da relação entre governo e desenvolvimento; e Seumas Milne - um crítico do modelo de livre mercado e observador das mudanças na América Latina no século XXI; facilitado pelo Ben Chu - editor de economia do jornal The Independent; sobre como transformar a economia pós-crise. Gente bacana e assunto interessante.
Eis algumas das trocas que rolaram (traduções minhas):
Esse é um ótimo ponto! Muitas vezes quando se fala do papel do investidor na sociedade, esquecemos que o maior investidor em tecnologia (e na maioria dos outros campos) é o próprio estado, financiando através de impostos. Quem defende uma menor participação do estado na economia, deveria articular como, então, essas grandes apostas serão feitas. Por outro lado, quando a iniciativa privada defende um aumento do direito das empresas em detrimento do direito dos cidadão alegando o interesse de seus acionistas, convenientemente esquece que quem investiu na tecnologia de base (seja diretamente, seja por investimentos em educação e outros) é exatamente o cidadão/contribuinte. Creio que nesse sentido, qualquer desejo da sociedade de regular esses setores seja legítimo e que o discurso do "estado mínimo" seja no melhor dos casos míope, e no pior dos casos age com má fé.
Então, agora, além do estado gerando valor fora da estrutura do mercado, a tecnologia permite que as pessoas também criem valor fora da economia de mercado, construindo em cima da "plataforma" criada pelo investimento público. E o que vemos são as empresas - construídas na lógica de mercado do século passado - tentando justificar a sua existência criando monopólios sobre a informação, mas esses monopólios são destruídos instantaneamente quando uma solução Livre aparece.
Mariana apresenta um exemplo de como ainda hoje, o investimento de base é desproporcionalmente feito pelo capital público. É interessante notar que o BNDES - extremamente criticado no Brasil e as vezes citado como um exemplo de dinheiro público sendo desperdiçado - na verdade gera retornos enormes para o tesouro público, e é observado no exterior como um agente de inovação, servindo até de modelo para o governo Obama.
O que eu aprendi nesse papo foi de que tem muita gente que vê a tecnologia como a força que vai salvar a economia do vício financista que se desenvolveu, aonde empresas e bancos se preocupam mais em maximizar retornos do que gerar valor para a sociedade. Isso é o que o modelo atual os incentiva a fazer, e os painelistas debateram as saídas para isso.
Costas traz uma visão mais estrutural, aonde o sistema financeiro deve assumir um papel social e aonde as empresas não se tornem no fundo "instituições financeiras" (uma tendência que tanto ele quando Mariana observaram).
Mariana destacou que os bancos de investimento privados tem um retorno insignificante para a sociedade quando comparados com os bancos de desenvolvimento (como o BNDES), mas mesmo, assim - e talvez exatamente por isso - os bancos de desenvolvimento são constantemente criticados.
Paul demonstrou, ainda, que o modelo atual só se mantém estável por que ainda consegue forçar práticas monopolísticas em cima de estruturas que são intrinsecamente anti-capitalistas, como Software Livre e peer-to-peer. Ele acredita que um novo modelo pós crise deverá surgir de uma colaboração entre essa nova sociedade conectada, o mercado e um governo central.
Finalmente Seamas destacou como os países do Sul Global desenvolveram nos últimos 10 anos, modelos alterativos aos modelos dos países desenvolvidos.
Achei muito interessante ver que a tecnologia, mesmo sem necessariamente fazer parte da discussão sobre a economia pós-crise, apareceu espontaneamente e como existem ângulos novos a ser explorados. Talvez o mais fascinante destes seja a relação entre o dogma de "retorno para o acionista" sendo contrastado com o "retorno para a sociedade", uma vez que a sociedade investiu massivamente em muitas das tecnologias que viabilizaram essa transformação que observamos. É uma discussão que acho extremamente pertinente no Brasil, pois agora temos uma economia que começa a gerar capital para investir, mas se depara com a crença de que o Estado não dve investir em tecnologia, enquanto assiste países desenvolvidos colhendo o fruto deste investimento.
Eu tenho a minha opinião, mas estou interessado em ouvir outras. O que você acha?
Para evitar o clichê de começar com um post dando oi para o mundo e prometendo blogar frequentemente, optei por começar com algo mais útil e algo que eu aprendi a fazer na escola: Uma redação sobre as minhas férias.
Esse ano começou estranho, eu passei 3 semanas trabalhando no escritório da ThoughtWorks no Equador, seguido de 3 semanas de férias e isso gerou uma sensação que tudo que aconteceu até agora foi no vácuo que existe entre 2013 e 2014, mas é claro que não. O ano já andou, e eu aprendi e relembrei muitas coisas que vale a pena compartilhar.
O Arquiteto, o Gerente e o Elefante
Na minha estada no Equador, me pediram para fazer o papel de gerente em um projeto que já estava rodando quando eu comecei. Eu não gosto de ter o papel de gerente de projeto. É algo que não acho que faça bem e que não me permite fazer as coisas que realmente gosto, mas as vezes é bom sair da zona de conforto e era o que precisava ser feito, então abracei a tarefa e tentei fazer o melhor que pude.
Por outro lado, por não estar lá no começo do projeto, tinha uma visão apenas parcial do que havia acontecido até a minha chegada. Se por um lado é saudável estar ciente disso, por outro eu sempre estava com a impressão que havia algo faltando no projeto. A líder técnica que estava no projeto desde o início tinha esse contexto, mas estava sobrecarregada com obrigações tanto no projeto quanto fora dele, e assim a gente acabava só falando o absolutamente essencial.
Eu assumi que esse "algo faltando" era algo que aconteceu antes da minha chegada, mas na verdade era algo mais básico que isso. Apesar de termos objetivos bem definidos para o projeto, todas as conversas pareciam truncadas. O elefante na sala era uma tensão que eu nunca havia percebido, mas que é importante e saudável. O gerente de projetos tem uma responsabilidade principal: garantir que o projeto é entregue no prazo. O líder técnico tem uma responsabilidade principal: garantir a qualidade da arquitetura e do código. Muitas vezes esses objetivos são incompatíveis e o gerente e o líder técnico tem que conversar e entender o que importa no contexto em que estão. Talvez essa seja a decisão mais importante do projeto. Uma vez que tivemos a conversa, as nuvens clarearam e tudo ficou fácil.
Qualidade Clássica e Romântica
Nas minhas férias eu reli um dos "livros da minha vida": Zen e a Arte da Manutenção de Motocicletas. No livro o autor, Robert Pirsig, debate o que, de acordo com ele, é um dos "grandes temas da humanidade" nos anos 70, a aparente dicotomia entre a Arte e Ciência. Os "bacanas" desprezavam a ciência como algo "feio" e os "nerds" tomavam quem não apreciava a ciência por "burros".
Pirsig argumenta que os dois extremos estão unidos pela Qualidade - seja clássica (ciência) ou romântica (arte) - que não pode ser explicada por nenhum dos dois campos e que, na verdade "gera" ambos. Ele explica isso muito melhor que eu, é claro. Mas o que eu achei interessante em relação às ideias mais modernas no mundo da agilidade é que ele argumenta que qualidade é algo que não pode ser medido: "É só olhar que você vê!", e prevê a unificação dos dois campos.
Isso me lembrou muito as ideias mais modernas de design, que sugerem que a única medida de sucesso é o feedback do usuário - quando o usuário olha, ele vê se tem ou não tem Qualidade. O melhor design que vemos hoje é quando essas ideias são implementadas e realmente parece uma intersecção entre arte e ciência. Lendo o livro quase 40 anos depois que ele foi escrito, parece engraçado o quanto ele se adere a conceitos que não só seriam formalizados 15 anos atrás e popularizados muito depois.
E de certa forma me faz pensar que o que estamos fazendo faz sentido.
Esse é um post de uma série que eu compartilhei internamente na ThoughtWorks uns anos atrás. Eu escrevi em inglês, então republico assim, mas se a série acabar sendo bem popular, eu prometo traduzir tudo.
Estimation. Just the mention of the word can make developers roll their eyes and even question why bother altogether. Indeed, estimations are usually hasted guesses based on shaky assumptions. JK Werner advocates that we shouldn't even call it estimating, as this frames the thinking into cost and time, when this type of analysis can only be attempted when we add a predicted velocity to the relative sizes of stories. What we usually do in estimation sessions is actually simply relative-sizing stories.
The debate about this activity usually revolves around the trade-off between waste of developers time vs. project predictability. For me this misses the point. In my opinion, the real value of sizing stories lie in the time-boxed discussion about the specific implementation of stories and the identification of the challenges and risks of a project that come up in these conversations. Many times, important design decisions are evaluated for the first time in story sizing sessions and this allows the delivery team to avoid spending time with impractical solutions. The resulting sizes may be an educated guess, but are merely one of the outcomes of a valuable activity.
Of course, there is still the problem that sizing can take time and, quite honestly, be boring. To be effective, sizing sessions should be a high-energy affair. This can mean the cheap thrill of coffee and cake (good to bring developers in to the room), but ultimately it requires some preparation so each story is well understood by the Business Analyst and it is introduced in a quick and interesting way. It is important to keep it snappy. In order to save some time, it may be possible to group stories about the same subject together. It avoids repeating the context every time, but, in the other hand, can create big dependency chains since developers tend to assume other stories of the same group have been played.
To keep the energy at a high level - particularly when estimating big batches of stories - it can be good to use "Pomodoro Sessions". The idea is to use concepts of The Pomodoro Technique to break the effort in constant intervals and work trough the story list this way. You can break a 2-hour time slot (the usual time of a inception session) into 25 minutes - 5 minutes break - 25 minutes - 10 minutes break - 25 minutes - 5 minutes break - 25 minutes (or the reminder of the 2 hours). The reason why the last session duration can vary is that some sessions (or breaks) may overrun. Sessions will naturally overrun because it is not productive to break discussions when the 25 minutes are up (in fact, it can be a real energy killer), so you probably want to finish discussing a story (and estimate it) and then go into a break. People tend to wander off and get distracted during the breaks, so be prepared to get everyone committed to come back on time and harass people if they don't.
Having pomodoro-sized sessions allowed developers to be engaged by removing the anxiety of an endless session. It helps in cases where you need to bring particular people only for some specific stories, or when you can't keep the same group for the whole time. You can also track how many stories the team averages in each interval so you can actually know how many you will need to get trough a batch of stories. As with anything, use judgement about when to Pomodoro: Do not hesitate to have a longer session if energy is high and the team is particularly focused. The important thing is getting the end result of engaged developers having meaningful discussions with the least possible waste.