There’s a Seth Godin’s post that I always use as a reference:
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.
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.
Jason Yip just reminded me about the “under pressure” situation:
When people are pressured to meet targets they have three ways to respond: Improve the system Distort the system Distort the data
When people are pressured to meet targets they have three ways to respond:
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:
Understanding Variation
Well, another book for my future reading list. Hopefully it will have a Kindle version soon.
Going back to the “under pressure” topic:
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:
Se os checklists são úteis para médicos e pilotos de avião, por que não o seriam para operação de TI?
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:
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.
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.
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 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.phphttp://www.draftymanor.com/bart/systems1.htmhttp://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.
As evolution is the only system known to produce intelligent behaviour, it is to be preferred.
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:
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.
