O “Modelo de Responsabilidade” tenta descrever como nós, humanos,  geralmente nos comportamos face aos problemas que encontramos diariamente. Acho que este modelo descreve algo que nasce conosco, as atitudes e sentimentos que foram cultivados durante milhões de anos de evolução.

Ora vamos lá ao modelo…

Quando encontramos um problema, começamos com a “Negação“:
Negação: O código compila no meu computador, não há problema nenhum.

Depois da negação, passamos para a fase de “Atirar com as culpas“:
“Atirar com as culpas“: O problema é da especificação Java que deveria permitir fazer isso…

E continuamos para a fase seguinte, a “justificação“:
“Justificação“: Ah, pensava que era possível fazer isto, uma vez vi isso no código do António…

A “Vergonha” é a fase que se segue, onde muitos vêm a oportunidade de desistir:
“Vergonha“: Aii, sou mesmo mau programador, não nasci para isto…. (Boa oportunidade para “Desistir“: Vou mudar para manager )

Depois destas fases, se não desistirmos, temos dois caminhos que podemos seguir: A “Obrigação” ou a “Responsabilização“:

“Obrigação” : Ok, já percebi que tenho de corrigir o erro… Diz-me o que posso fazer para o corrigir.

“Responsabilização“: Não vou ficar aqui à espera que alguém corrija este erro, vou ler a especificação Java para ver como posso resolver o problema e vou corrigir este erro ainda hoje.

Ficam alguns links com mais sobre o assunto;

http://www.selfishprogramming.com/2008/09/26/challenge-your-personal-agility/

http://www.christopheravery.com/responsibility-process

The reason for the fall of empires and civilizations throughout history is … because their societies got too complex and gridlocked to be managed.

Isn’t the same with Software?

“Survival of the Simplest“

Um mês antes do grande lançamento a equipa responsável pela comunicação pergunta ao desenvolvimento: “Quando é que o produto vai estar pronto? Precisamos de uma data para comunicar ao público o grande lançamento”.

A equipa de desenvolvimento respondeu qualquer coisa como: “Já está 85% feito.”

Com uma contas, o gestor de projecto prevê que dentro de um mês o produto estará pronto para o mercado. E foi com esse pressuposto que a equipa de comunicação anunciou a data do lançamento “imprevisível” do grande lançamento no site, no blog, no Facebook, no Twitter e no Youtube.

Mas será que aconteceu o pior?

No dia de lançamento (segundo as expectativas da equipa de comunicação), a equipa de desenvolvimento diz que não é possível lançar o produto hoje.

Infelizmente para a equipa, a data de lançamento calhou a uma Sexta-Feira, quando já todos andavam atacados com o stress pre-release. Depois do problema escalado, a direcção da empresa pede gentilmente que se esforcem ao máximo durante o fim de semana para lançar o produto na próxima Segunda-Feira. Até lhes ofereceu recompensas financeiras.

O produto é lançado na Segunda-Feira, mas apesar do incentivo financeiro,  a equipa perdeu muita motivação com este acontecimento. O overtime e sensação de “falha” é sempre um desmotivador e não há dinheiro que “mexa” nessa psicologia.

Agora, porque é que eu gosto das metodologias ágeis para desenvolvimento de software? Não vou aqui falar de tudo, é claro, mas apenas de um ponto que acho importante no contexto desta história tão comum.

Disciplina nas entregas (e tudo que o processo traz de borla)

• A trabalhar com iterações que produzem Software “utilizável”  e com um conjunto de funcionalidades conhecidas, a equipa ganharia disciplina nas datas de entrega (Com uma gestão apropriada da equipa).
• Se as iterações tivessem duração de 3 semanas e a equipa confiasse que necessitava de uma iteração para atingir um conjunto de funcionalidades, que somadas às produzidas nas iterações anteriores igualavam as funcionalidades mínimas para lançar o produto, então a equipa de comunicação poderia estar confiante ao anunciar a data do grande lançamento

Será este ponto importante para repensar algumas metodologias de desenvolvimento de Software? Ou assumimos a postura da  negação: “Ahh, podia ser pior se tivéssemos marcado um evento com a comunicação social e grandes investidores.”?  :)

* Refiro-me aqui às técnicas que apenas são reconhecidas como boas práticas dentro da empresa um por um grupo restrito de empresas.

Para o demonstrar, considerem as seguinte conversas:

Programador – “Vou conseguir terminar o módulo A a tempo”

Gestor de Projecto – “Sim, muito bem. Mas conseguirás fazer também a documentação a tempo?”

Pensem que isto vos está a acontecer e tentem perceber o roadblock que foi colocado apenas no vosso caminho?

Agora no mesmo cenário mas como uma atitude mais positiva:

Programador – “Vou conseguir terminar o módulo A a tempo”

Gestor de Projecto – “Sim, muito bem e agora temos de nos focar também em entregar a documentação a tempo? Do que precisamos?”

Pensem agora nesta última conversa. Qual delas será a mais construtiva, colaborativa, positiva e inteligente?

Este poderá ser a história de muitas equipas em muitos projectos. É uma história de uma equipa de desenvolvimento de software que trabalhou para uma pequena empresa de fogões de sala. Eles ganharam um contrato de um projecto para integrar uma aplicação Web, desenvolvida em Java, com o Twitter. O projecto deveria estar pronto em 6 meses, sob pena de perderem 10 000€ por mês de atraso.

A empresa cliente vai experimentar utilizar o Twitter para aumentar as vendas e querem integrar o site com o Twitter. A cliente quer utilizar palavras chave associadas aos produtos para actualizar várias contas do Twitter. Cada actualização automática tem palavras chave de um produto e um link para a página do mesmo.

Depois de alguma pesquisa e análise, decidiram utilizar o Twitter4J, uma biblioteca de software em Java para abstracção da API Restful do Twitter.

Não tinham qualquer conhecimento na biblioteca Twitter4J. Inicialmente estimaram que demorariam cerca de 2 meses para ganhar o conhecimento e experiência necessária para fazer algo do género em seis meses.

Depois de um pequeno brainstorming chegaram a duas alternativas para colmatar a falta de experiência e eliminar, ou reduzir, qualquer risco de atraso.

Alternativa 1 – Contratar um consultor com conhecimento em Twitter4J para trabalhar no projecto durante dois meses que custaria ao projecto cerca de 15 000 euros.

Alternativa 2 – Assumir o atraso de 2 meses que custaria cerca de 20 000 euros.

Como ambas as alternativas custavam bastante dinheiro à equipa, eles decidiram seguir por outro caminho mais arriscado, mas que nunca poderia custar mais que a segunda alternativa. A alternativa seguida foi:

Alternativa 3 – Começar já a desenvolver qualquer coisa, e se tiveram alguma questão bloqueante utilizam as mailing-list do Twitter4J e da API Restful do Twitter.

Eles seguiram com a terceira alternativa, e qualquer dúvida eles colocavam questões nas mailing-lists, tendo não acesso a um consultor, mas a centenas de consultores que lhes respondiam quase imediatamente.

A equipa consegui terminar o projecto com um atraso de 1/2 mês, o que significou um prejuízo para equipa de cerca de 5 000, comparados com os 15 000 da primeira alternativa e os 15 000 da segunda.

Acham que  nesta história o conhecimento foi quase gratuito?

Disclaimer: Isto é mesmo só uma história

“An effective team has to be able to respond quickly[...] And for that, we need a forum for robust dialogue.

A formally constituted team comes from the desire to work collaboratively [...] There is a shared commitment to goals that has the support of individual team members, and in turn supports them.

An effective team [...] contrasts with a more common hierarchical approach to business goals, “the command-and-control approach.”

The effective team are [...] The Magnificent Seven rather than The Good, The Bad and The Ugly.

To have and effective teams [...]Businesses need to shift from individual bonuses to team-based bonuses, to flatten out their reporting structure.

What may not be a Team? [...] A committee is a weak variant of a team [...] A team [...] is the opposite of a committee in that it has a unifying purpose and values to which all members ascribe, despite their position within the organization.

How to build a team? [...] Peer mentoring is a team learning system that lets people teach each other [...] Workshops have their place in leadership development, but most corporations don’t have a significant way to transfer that knowledge into skills.”

Peer Mentorig [...] challenges people to take ownership of their careers. As long as no direct reporting is involved, it works magically.

How a effective team looks like?[...] include enough people, and a good cross-section of skills. We call it collective intelligence. The worst thing to do is try to figure out things by yourself.

Ainda no mesmo artigo são sugeridas oito características de uma boa equipa:

EIGHT TEAM MUST-HAVES

1. Must have a meaningful purpose that all members care about.
2. Can’t be too large. Some experts suggest capping at 20. Field cautions against there being too little work for all members.
3. Needs a diverse set of skills appropriate to the goals.
4. Needs to be physically together. Even having some team members on different floors can hurt the team.
5. Succeeds or fails together. No stars or scapegoats.
6. Shares leadership. Of course there is one leader, but he or she should be willing to step aside when another team member’s skills are required.
7. Has strong shared norms and expectations of behaviour. These are soft skills that often need to be taught.
8. Needs time. “You lose advantages if you hurry,” Prof. Field says. “Slow it down for the process to work.”

Artigo original:

http://www.financialpost.com/story.html?id=2258320

Uma Community of Practice é uma forma de criar e renovar conhecimento nas organizações. É por vezes uma solução na transformação de modelos de desenvolvimento de Software Waterffal para modelos mais ágeis e lean. Ao eliminar equipas especializadas (Testers, Architects, Developers, Designers) as pessoas podem perder as condições ideais para se especializarem em assuntos e áreas de interesse profissional.  Não acho que o facto de as equipas serem multidisciplinares e trabalharem em todos os aspectos do desenvolvimento do Software, seja justificação para acabar com o conhecimento que é criado através destas equipas.

Os Testers geralmente pesquisam e desenvolvem soluções que lhes permitem melhorar os testes de Software. Os Architects pesquisam e desenvolvem conceitos de Software que, sendo implementados, criam valor no produto. Os Developers pesquisam e desenvolvem soluções que  possam proporcionar um aumento de eficiência no seu trabalho. Acho que é importante que se continue a ter as condições para criar este tipo de conhecimento e uma das formas de o conseguir é através de Communites of Practice.

Ficam aqui alguns recursos sobre o assunto:

• Cultivating Communities of Practice: A Guide to Managing Knowledge – Seven Principles for Cultivating Communities of Practice
• Cultivating communities of practice: a guide to managing knowledge – Google Books
• Communities of Practice: The Organizational Frontier
• Wikipedia

Vídeo:

Caterpillar- Collaboration Through Communities of Practice

Slides:

Communities of Practice: Conversations To Collaboration

O Scrum Guide: http://www.scrumalliance.org/resource_download/598

Para uma rápida introdução ao Scrum deixo também este vídeo:

Intranets today reflect one view point – that of management – and are not platforms for dissent or debate.  After Blogs, wikis and other voice-giving technologies appear, this will change. However, the question remains: will the change be welcomed?”

[...]

These tools reduce management’s ability to exert unilateral control and will be used to express some level of negativity.

Por exemplo, será que o Management está disposto a reportar a toda a organização que o projecto XPTO está atrasado e estão a “cortar” na qualidade para o entregar a tempo?

Antes de utilizar tecnologias “Enterprise 2.0″, como wikis ou blogs, acho que existe um um princípio fundamental que deveria ser seguido pelas pessoas na organização: “Transparência”. Quando existem múltiplos canais, múltiplas plataformas e múltiplos níveis de “reporting” é fácil comunicar progresso “falso” nos projectos. Não acho que este falso reporting seja motivado pela falta de desejo nas pessoas em fazerem um bom trabalho, mas sim por outros factores.

E também, o que me diriam se eu fosse o vosso Management e vos “recomendasse” a utilização de um wiki e depois nunca o utilizasse ou ignorasse o que por lá está escrito?