rafanoronha.speaking()

Uma das atividades chave de um gestor é delegar responsabilidades.
Acredito que uma das diferenças entre um gestor bom e um gestor ruim está na forma com que ele exerce esta atividade.

O crachá de um profissional por si só não deve credenciá-lo responsável por coisa alguma.
E a primeira coisa que um gestor incompetente faz é delegar responsabilidades conforme o crachá dos profissionais de sua equipe.

O crachá é importante na hora de contratar.
Você contrata um profissional apostando em seu futuro, de acordo com os feitos que ele já obteve.
Daí em diante, cabe a este profissional demonstrar sua competência e o interesse por assumir novos desafios e responsabilidades.

Outro erro comum é o de centralizar responsabilidades.
Ao centralizar responsabilidades em um profissional, isentamos o restante da equipe de contribuir com o trabalho.
E se o profissional não se demonstrar suficientemente competente ou comprometido, os objetivos de negócio de sua organização estarão em maus lençóis.

Agora vamos à lição mais difícil.
Lembrando que o que está em contexto é o mercado de TI, onde existem os chamados profissionais do conhecimento.
Faz algum sentido centralizar responsabilidades de acordo com a estrutura hierárquica de sua empresa?

O gerente de projetos é o responsável pelo projeto.
Parabéns, você acaba de arriscar o projeto colocando-o nas costas de uma única pessoa, quando esta responsabilidade poderia ser compartilhada entre toda a equipe.

Descentralizar responsabilidades também significa favorecer o crescimento e consequente comprometimento dos profissionais de sua equipe.
Lembrando que serão estes profissionais os responsáveis pelo sucesso de sua organização.

Bom, esta foi apenas uma rápida exposição de algumas das idéias que tenho aprendido no dia-a-dia de uma equipe gerida por um gestor competente (link para o blog do figura).

Cascata Caracol by Arqueos, on Flickr

Este é o quarto post da série Agile na Cascata.
Recentemente o twitter me trouxe isto: Manifesto for Half-Arsed Agile Software Development

Depois, foi a vez de eu me deparar com este comentário do Davy Brion.

Após alguma reflexão, ficam as perguntas:
As grandes corporações estão preparadas para repensar a condução de projetos de software?
Aquelas que não repensarem, pagarão um preço alto?

Um profissional de TI acima da média precisa estar sempre antenado em inovações, tecnologias, etc.
Além disso também precisamos estudar disciplinas de gestão, principalmente de pessoas.

Por isso resolvi estruturar uma nova tag no meu blog: O que ando lendo.
A idéia é fazer esta pergunta uma vez por mês, ou algo do tipo.

Em agosto de 2010 eu estou lendo Write Great Code Volume 1: Understanding the Machine.
Me interessei pelo livro por ser apaixonado por ciência da computação.
A leitura tem sido muito agradável, e estou aprendendo bastante coisa.

E você, o que anda lendo em meados de 08-10?

Quem já trabalhou comigo sabe que para mim a única coisa indispensável para o sucesso de um projeto é a presença de pessoas competentes compartilhando de um objetivo em comum.

A verdade é que atualmente não tem sido nada fácil encontrar no mercado de TI profissionais devidamente qualificados.
Acredito que este problema vem da interminável demanda por profissionais existente no mercado.
Se não faltam oportunidades para os profissionais atuarem, perdeu-se o mais importante dos incentivos para a correta formação destes profissionais.

A consequência deste problema é o cenário que temos hoje na indústria de TI.
Resolvi então classificar dois tipos de profissionais existentes em nosso mercado:

1) O profissional comum.
Este profissional aprendeu o suficiente para desempenhar o seu papel dentro das milhares de oportunidades mercado afora.
Ele tende a ser acomodado e desinteressado por inovações.
Seus conhecimentos técnicos são limitados e o seu trabalho se restringe a executar atividades conforme o processo de trabalho de sua organização.

2) O profissional 2.0.
Este profissional tende a ser inquieto e interessado por inovações.
Seus conhecimentos técnicos ganham profundidade com o passar do tempo e o seu trabalho transcende a execução de atividades, englobando o entendimento do porque as coisas estão onde estão e o interesse pela evolução contínua e pelo cumprimento de objetivos e alcance de resultados.

TI está presente em diferentes tipos de organizações, em diferentes formas.
O que eu arrisco dizer é que, qualquer que seja a finalidade ou forma de sua TI, existe uma premissa para que ela maximize seus resultados: a existência de profissionais de TI 2.0, e a existência de uma nova cultura de gestão, que alguns já começam a chamar de gestão 2.0.

Este é o terceiro post da série Agile na Cascata.

Existe uma questão existencial na adoção de Agilidade debaixo do modelo de fábrica de software:
Quem é o cliente?

Embora o cliente final de um projeto de software seja a área de negócios da empresa que contrata nossos serviços, o responsável pela contratação e relacionamento com a fábrica é a área de TI (ok, nenhuma novidade, já que a idéia é que a fábrica forneça um serviço que proporcione maior vazão às demandas da área de TI).

O problema está na compatibilidade da agilidade com este cenário.
Recapitulando dois dos valores do manifesto ágil:

Working software over comprehensive documentation
Customer collaboration over contract negotiation

Se o fornecedor do cliente final (área de negócios) é a área de TI da empresa, cabe a ambos definirem como se dará a negociação, planejamento, gerenciamento e execução dos projetos que atenderão as necessidades de negócio.

O resultado disto é:
Uma vez que a fábrica de software baseie a prestação de seu serviço em processos e métodos ágeis, o primeiro a ganhar com a natureza do modelo ágil é a área de TI, o nosso cliente.
A área de negócios, por sua vez, continuará dependendo de seu relacionamento com a área de TI para conseguir uma fatia da promessa de software entregue mais cedo e com frequência.

Um relacionamento TI X Fábrica baseado em pilares flexíveis independe de um relacionamento Negócios X TI baseado em pilares flexíveis.
Na prática, mesmo que a fábrica consiga reduzir o apego à documentação formal, ou realizar entregas em pacotes, a agilidade não existirá em sua plenitude enquanto a área de TI não repensar o seu relacionamento com a área de Negócios.

Este relacionamento burocrático também impõe limitações ao processo de trabalho da fábrica:
Um projeto de software sempre será restringido por uma especificação formal, o que faz com que as práticas ágeis se limitem à construção daquilo que foi anteriormente definido.

Concluindo:
Se os projetos do cliente se desenrolam sobre processos rígidos e burocráticos, a adoção de agilidade por parte do fornecedor será bastante limitada.
Na prática, a agilidade será útil para gerenciar a conformidade do projeto com o cronograma exigido pelo cliente.
Já os benefícios prometidos por um ambiente verdadeiramente ágil não podem ser garantidos, uma vez que os valores do manifesto ágil estão colocados em xeque.