Gravity is a constraint. If you’re a designing an airplane, it would be a lot easier without gravity as a concern, but hey, it’s not going away.

A problem is solvable. A constraint must be lived with.

…

The art is in telling them apart.

Source: Problems and constraints

This post always reminds me of that old saying that tell us pick our battles carefully. Specially if the battle is a constraint.

When people are pressured to meet targets they have three ways to respond:

1. Improve the system
2. Distort the system
3. Distort the data

Fonte: Jason Yip’s blog

Yip is reading what seems to be a very good book on variation, Understanding Variation: The Key to Managing Chaos. In this book the author Donald J. Wheeler, according to an Amazon.com reviewer, “provides managers a rational way to look at daily, weekly, monthly, and yearly figures and tell whether the actions they take have resulted in improvement”. It seems to be a very interesting book from what Yip’s been posting:

• Shewart’s rules for the presentation of data
• On presenting data
• Wheeler’s simplified terminology for Statistical Process Control

Understanding Variation

Well, another book for my future reading list. Hopefully it will have a Kindle version soon.

Under pressure

Going back to the “under pressure” topic:

When people are pressured to meet targets they have three ways to respond:

1. Improve the system
2. Distort the system
3. Distort the data

Fonte: Jason Yip’s blog

That’s a good way to see the possible outcomes of a group of people under pressure.

I like to use balloon as a metaphor to help understand under pressure situations.

Balloon

Here’s why:

• there’s pressure from inside and from outside.
• pressure from inside and from outside needs to be balanced.
• to much pressure from the inside or to little pressure from outside and balloon explodes.
• to much pressure from the outside or to little pressure from inside and the balloon explodes unless it is one of those balloons where the more outside pressure it gets the harder it is to explode.

Lessons learned

• There’s no such thing as “no pressure”. A group of people needs pressure from outside (the goal, the target date, lack of resources) as well as from inside (motivation) to exist and do things, just like a balloon.
• Inside pressure and outside pressure needs to be balanced with some tendency to have a bit more pressure from the outside.
• Under pressure, a group of people either explode or get stronger.

Dr. Atul Gawande escreveu um livro sobre o tema onde ele conta várias histórias sobre o uso de checklists. A argumentação para o uso de checklists é que qualquer ser humano falha, mesmo os mais especialistas.

The Checklist Manifesto

No livro ele conta a história do Dr. Peter Pronovost, um especialista em cuidados intensivos do hospital Johns Hopkins em Baltimore. Pacientes de UTIs em sua maioria tem um acesso à sua corrente sangüínea por onde são ministrados os remédios. Esse acesso é chamado de cateter venoso central. Em 2001, 1 em cada 9 cateteres venosos da UTI do hospital Johns Hopkins acabava infectado, prolongando a permanência do paciente na UTI, piorando seu quadro e, às vezes, levando-o à morte.

Cateter venoso central

Dr. Pronovost resolveu pegar emprestado uma rotina usada por pilotos de avião para garantir que tudo está ok para a decolagem, os checklists. Ao ser instalado um cateter venoso, há 5 pontos que devem ser observados:

• lavar as mãos com sabonete bactericida;
• limpar a pele do paciente com clorexidina antiséptica;
• cobrir o corpo do paciente com tecido estéril;
• usar máscara, chapéu e luvas estéreis;
• colocar uma proteção estéril sobre o catéter.

Esses passos são muito simples e parecia ser desnecessário fazer um checklist, mas o Dr. Pronovost resolveu fazer uma experiência. Ele deu o checklist para as enfermeiras da UTI e pediu que elas ticassem cada item feito pelo médico e chamassem a atenção do médico que esquecia de fazer algum dos itens.

Os resultados foram surpreendentes: depois de um ano o índice de infecções em cateteres venosos centrais caiu de 11% para 0%. Dr. Pronovost fez as contas, dois anos depois a prática do checklist havia evitado 43 infecções, 8 mortes e economizado dois milhões de dólares.

Segundo o Dr. Gawande:

Nós admitimos que erros e descuidos acontecem – até mesmo alguns devastadores. Contudo, nós acreditamos que nosso trabalho é muito complexo para ser reduzido a um checklist.

Fica aí a dica do Dr. Pronovost e Dr. Gawande: será que não podemos usar checklist para as operações de TI?

Dr. Pronovost

Dr. Gawande

Todo ambiente de operação de TI é sujeito a mudança: aplicação de um patch, mudança de parâmetros de configuração, instalação de novos softwares, etc. Essas mudanças podem ser controladas pelo processo de gestão de mudanças. E o checklist é o parceiro ideal para um processo de mudança eficaz.

========================
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.

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.

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 sistemas 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

Fecho esse post com uma lei específica sobre evolução que é bem apropriada aos sistemas desenvolvidos usando metodologias ágeis:

As evolution is the only system known to produce intelligent behaviour, it is to be preferred.

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

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.

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.

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.