30 abril 2011

Gestão Pública e Agile: Quem deve mudar?



Tenho andado cada vez mais sem paciência com burocracias, regras sem sentido e culturas organizacionais enferrujadas. Mas sei que volta e meia perco um pouco da razão e pareço arrogante e radical com algumas ironias e sarcasmos. Por isso vou tentar me controlar um pouco nesse comentário.

O que me fez levantar da cama pra escrever nesse sábado foi o texto tuitado pelo @julioprotzek sobre a opinião de um advogado americano a respeito de porque Agile não funciona no setor público.

Já discuti muito esse assunto. É sempre um ponto levantado quando se fala sobre ágil em órgãos púbicos - coisa que fiz um bocado nos dois últimos anos.

Em poucas palavras o argumento é que como processos ágeis não são preditivos - não se comprometem desde o início com o resultado exato que o projeto vai ter no final - eles não se encaixam na estrutura de decisão que as entidades governamentais usam para contratar.

O governo precisa saber exatamente quanto vai custar, quando vai ficar pronto, e o que vai receber, nos mínimos detalhes. Isso por dois motivos: primeiro porque ele precisa comparar os fornecedores candidatos de forma imparcial e transparente, e segundo porque, se alguma coisa der errado, ele precisa ter alguém para responsabilizar.

(Interessante ver que os problemas são os mesmos aqui e lá)



A princípio, o argumento parece fazer sentido, mas acho que possui uma incoerência muito profunda.


As mudanças que a tecnologia da informação vem impondo ao mundo têm nos ensinado muito a respeito das velhas formas que usamos para 'administrá-lo'. O conflito entre pirataria e direitos autorais, entre o conceito trabalhista protestante e a ética hacker, entre a 'liberdade' de imprensa e as mídias sociais e as próprias relações econômicas, comerciais e legais num mundo onde as fronteiras geográficas importam (bem!) menos que as virtuais.

Enfim, o mundo está reaprendendo a viver, agora que a tecnologia expões teias de aranha bem densas na formas como estávamos acostumados a organizar a sociedade.

O processo de criação e engenharia não fica de fora dessa. Métodos iterativos de trabalho, baseados em feedback e confiança, equipes auto-organizadas e processos decisórios participativos são alguns exemplos de mudanças que Agile vem nos apresentando.

Continuar usando técnicas industriais para desenvolver software não vai funcionar! Chega de bater cabeça!

Então quando se diz que Agile não se encaixa nos processos de gestão que órgão públicos utilizam, pergunto: quem deve mudar?

Só pra não perder a oportunidade de ser um pouco sarcástico, deixo esse vídeo muito muito pertinente, em que tropecei agora a pouco quando estava na frente do computador quase quase desistindo de escrever esse texto. Enjoy!



Tuite esse texto.

4 comentários:

  1. Parece bem óbvio quem precisa mudar, mas parece-me bem mais óbvio ainda que quem precisa mudar nao se deu conta disso.
    Espero que a Sea continue plantando as sementinhas...

    ResponderExcluir
  2. As regras rígidas de contratação de serviços dos governos existem para tentar diminuir a corrupção.

    Métodos ágeis não podem perder seu foco em software de qualidade funcionando para se preocupar com controle de corrupção.

    ResponderExcluir
  3. A famosa APF que é tão pedida pelo governo não é confiável.
    Aqui no sul tem empresas que ganharam licitações de projetos de escopo fechado e utilizam Scrum.
    Concordo com colega Adolfo, a cultura ágil não poder perder o foco em desenvolvimento de produto com qualidade e funcional para se preocupar com controle de corrupção.

    ResponderExcluir
  4. Acho que uma resposta à questão apresentada pelo artigo seria: ambos precisam mudar.
    No caso da administração pública, diversas iniciativas em prol da desburocratização e da qualidade dos serviços prestados pelo setor público podem ser acompanhadas pela sociedade no site gespublica.gov.br. Como simples exemplos, vide o caso da desburocratização da ANCINE e o manifesto chamado "Carta de Brasília".
    No caso do Agile, muito se fala em medição/análise do valor do software para a organização e seus clientes. Como exemplo, os três keynotes do Agile Brazil 2011 (Jim Highsmith, Joshua Kerievisk e Vinicius Teles) emitiram diversas mensagens para a comunidade ágil: "O valor de um software para os negócios deve ser demonstrável", "Não adianta muito ser produtivo, eficiente e profissional (fazer certo) desenvolvendo o software errado", "A felicidade dos usuários deve ser considerada no desenvolvimento de software" e "Ágil não deve ser um fim em si mesmo".

    ResponderExcluir