English version below

========================
No começo do blog eu havia decidido blogar em inglês. Depois resolvi escrever em português. Agora resolvi fazer o blog bilingue. Já começou dando trabalho, pois fiquei pensando em como fazer, aí resolvi instalar um blog virgem e importar os posts daqui para começar a blogar em inglês, depois fiquei pensando no trabalho que ia dar manter dois blogs e resolvi hoje ir por um caminho mais simples: criei duas categorias no blog e reclassifiquei todos os posts.

Espero conseguir manter um bom equilíbrio entre posts em inglês e em português.

Quem quiser acompanhar somente os posts em português, o link do feed está aí ao lado.

========================
At the beginning of this blog I decided to blog in English. Later I changed to Portuguese. Now I’ve decided to make my blog bilingual. And it started giving me extra work, since I decided to start a fresh new blog and import all posts from here to start to blog in English. Thinking about how much work it is to maintain two blogs I’ve decided for a simpler way: just created two new categories and reclassified all posts.

I hope I can keep a good balance between English and Portugues posts.

For those willing to follow only the posts written in English, please use the feed link at the sidebar.

Acabo de ler o “The Logic of Failure“, de Dietrich Dorner, professor de psicologia da Universidade Otto-Friedrich, na Alemanha.

A escrita tem um pouco de sotaque, dá pra perceber que é um alemão escrevendo em inglês, mas o livro é interessante. O subtítulo “recognizing and avoiding error in complex situations” explica do que se trata o livro, mas parece que o autor concentrou maior foco em “recognizing” e menos em “avoiding”. Uma boa avaliação desse livro, com a qual eu tendo a concordar, pode ser vista em:

http://www-users.cs.york.ac.uk/~susan/bib/nf/d/dtrchdrn.htm

This is the first half of a potentially excellent book. Dörner uses computer simulations (more or less sophisticated versions of Sim City) to test under laboratory conditions how real people solve complex problems. These are problems where the variables to be controlled are linked in a non-linear manner, and where new problems can arise as a result of solving the old problems. Real world problems, that is. And most people are pretty useless at it, too, with their well-meaning interventions soon driving the (simulated) populations into disastrous famines or recessions.
…
All these results appear to be based on detailed experiments and observations. But then Dörner presents a (to my mind) rather oversimplified and overgeneralised model of problem solving, and claims that people should follow this when tackling complex problems. What appears to be missing at this point is a similar set of experiments to validate this model. Where is the comparison of the performance of a control population, and people who use the model?

Sobre previsões de leigos e especialistas, ele comenta um caso interessante, dái o título desse post. Ele fala sobre como leigos e especialistas fazem previsões sobre alguma coisa (bolsa de valores, crescimento da economia, crescimento da população, inflação, etc.). Normalmente essas previsões são feitas tendo um conjunto de dados reais e extrapolando os dados para o futuro. Basicamente a diferença entre leigos e especialistas é que os especialistas conhecem mais curvas para usar na extrapolação. Por outro lado, leigos e especialistas são iguais no seu lado humano. Nesse ponto ele apresenta um cenário muito ilustrativo dessa questão humana. Imagine um especialista com a imcubência de fazer a previsão de crescimento da frota de carros de uma cidade. Agora imagine que esse especialista leva todos os dias 10 minutos para achar uma vaga para estacionar o carro quando vai trabalhar. Numa situação como essa é muito provável que esse especialista “puxe” sua previsão para baixo.

Outro dia me deparei com um post no blog da 37signals sobre sistemas complexos que trazia uma citação de John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

Fuçando um pouco descobri que esse John Gall, um pediatra, escreveu em 1978 um livro chamado “Systemantics, How Systems Really Work and Especially How They Fail” com um conjunto de leis que regem quaisquer tipos de sistemas, que podem ser desde de programas de computador até o corpo humano, o universo, uma cidade, uma empresa, etc.

O livro é uma espécie de paródia ou crítica à teoria de sistemas que foi criada por Ludwig von Bertalanffy, um biólogo austríaco, no início do século passado.

Systemantics teve uma segunda edição, “Systemantics: The Underground Text of Systems Lore”:

E na terceira edição foi rebatizado como “The Systems Bible: The Beginner’s Guide to Systems Large and Small”:

Apesar de ser uma paródia, no estilo das Leis de Murphy, ou mesmo por ser uma paródia, as leis de Systemantics fazem refletir, principalmente quando as lemos pensando em desenvolvimento de siistemas e produtos de internet.

Além da citação do início desse post, gosto particularmente das leis abaixo, que refletem muito a forma de pensar das metologias ágeis:

• The Functional Indeterminacy Theorem (F.I.T.): In complex systems, malfunction and even total non-function may not be detectable for long periods, if ever.
• The mode of failure of a complex system cannot ordinarily be predicted from its structure.
• The larger the system, the greater the probability of unexpected failure.
• Colossal systems foster colossal errors.
• Choose your systems with care.

As 5 primeiras leis são bem interessantes também:

• The Primal Scenario or Basic Datum of Experience: Systems in general work poorly or not at all. (Complicated systems seldom exceed five percent efficiency.)
• The Fundamental Theorem: New systems generate new problems.
• The Law of Conservation of Anergy [sic]: The total amount of anergy in the universe is constant. (”Anergy” = ‘human energy’)
• Laws of Growth: Systems tend to grow, and as they grow, they encroach.
• The Generalized Uncertainty Principle: Systems display antics. (Complicated systems produce unexpected outcomes. The total behavior of large systems cannot be predicted.)

Uma lista mais completa das leis pode ser encontrada em:

http://en.wikipedia.org/wiki/Systemantics

E nos links abaixo há a lista de leis com alguns comentários:

http://www.laetusinpraesens.org/docs/systfail.php
http://www.draftymanor.com/bart/systems1.htm
http://www.ece.osu.edu/~fasiha/systemantics

Esse post é só para fazer um link para um texto muito interessante do Akita sobre vários temas que ele e eu temos conversado ultimamente sobre gestão de desenvolvimento de produtos de tecnologia:

Off-Topic: O Manifesto Ágil, ou Como se Tornar o Google

Quando lemos sobre como funciona a colaboração e o auto-gerenciamento em times que adotaram metodologias ágeis, sobre como tudo funciona de forma democrática, ficamos com a impressão que os desenvolvedores foram os primeiros a abraçar esses conceitos e que o difícil foi fazer a alta gerência aceitar.

Paul Glen, um consultor sobre liderança de geeks que disponibiliza vários artigos sobre o tema, escreveu um artigo entitulado “Sometimes It Takes a Tyrant to Support Collaboration” onde ele explica que muitas vezes a colaboração precisa ser defendida pelo líder em função de alguns tipos de comportamentos que são prejudiciais ao grupo. Ele dá também algumas formas de lidar com esse tipo de comportamento.

Eu gostaria de ir um pouco além e escrever sobre o que, ao meu ver, seriam as causas desses comportamentos inadequados que podem por em risco a colaboração em um time que adotou metodologias ágeis.

Há dois aspectos do trabalho de desenvolvimento de sistemas não colaborativo que tenho visto como sendo as raízes desses comportamentos inadequados:

• falsa sensação de poder: o trabalho técnico isolado dá uma falsa sensação de poder. Se somente uma pessoa sabe fazer determinado trabalho técnico, ela começa a se sentir indispensável e acredita que seu emprego está garantido. Por outro lado, gerentes não gostam de se sentir reféns. É natural que o gerente queira que mais pessoas conheçam o trabalho de outras pessoas do time para que, na ausência de uma dessas pessoas, o time não fique capenga. As metodologias ágeis pressupõem a colaboração, chegando ao ponto de usar a programação pareada. Isso é um risco para aqueles que acham que o fato de só eles saberem determinada parte do sistema é uma garantia de emprego.

• deficiências escondidas: o trabalho técnico isolado dá a oportunidade de esconder deficiências. Um desenvolvedor que tenha alguma deficiência, por não ter seu código revisto por outras pessoas pode facilmente esconder suas deficiências. Esse é outro cenário que um gerente não quer ver. Deficiênciais técnicas podem ser danosas não só do ponto de vista de produtividade, ou seja, algo demorar mais para ser feito do que deveria, mas também do ponto de vista de qualidade, pois código feito por desenvolvedores que escondem deficiências tem um potencial enorme de dar defeito. As metodologias ágeis, por meio da intensa colaboração que deve ser praticada, expõe as deficiências, o que também pode ser uma ameaça para alguns desenvolvedores.

Quando da implementação de metodologia ágil, pode acontecer de uma ou mais pessoas do time se sentirem ameaçadas pelos efeitos da colaboração em função dos aspectos acima e, numa situação como essa, acabarem optando por procurar outro emprego. Esse é um risco conhecido. Ken Schwaber, um dos criadores do Scrum, menciona que é esperado até 20% de turn over quando da implementação de metodologias ágeis. Ele também menciona que até 40% da gerência pode ir embora. Já comentei sobre o tema da mudança de papel do gerente nas metodologias ágeis.

Por isso, apesar de soar estranho, às vezes é mesmo necessário ser um ditador para garantir que a colaboração prevaleça em seu time.

Another change I’ll make at YAPMB is that I won’t discuss exclusively about Product Management. I’ll write about other topics in which I have interest.

And one topic that I love is swimming. More about it in other posts.

And I’ll start to post in my mother tongue, Portuguese.

Long time no see… I’m terrible sorry for the long time without posting. I’ve been quite busy at work lately. But I intend to be back to writing with an acceptable frequency.

And in order to do so, I’ve decided to make a few changes on YAPMB.

The first one is that I’ll start to write in Portuguese as well. So some post, those written in English, will be targeted to a broader audience, while others, written in Portuguese, will be targeted to the Brazilian audience.

So, in a few minutes, the first post in Portuguese.