rafanoronha.speaking()

Crachás

rafanoronha — Mon, 06 Sep 2010 00:39:14 +0000

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

Agile na Cascata: Cultura

rafanoronha — Mon, 30 Aug 2010 16:34:46 +0000

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?

O que ando lendo em meados de 08-10

rafanoronha — Sat, 28 Aug 2010 22:19:05 +0000

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?

No related posts.

Profissional de TI 2.0

rafanoronha — Mon, 23 Aug 2010 00:00:07 +0000

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.

Agile na Cascata: Quem é o cliente e onde foi parar o ROI

rafanoronha — Sun, 15 Aug 2010 03:20:22 +0000

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.

Errado é não errar

rafanoronha — Fri, 06 Aug 2010 12:27:42 +0000

Ontem o dia de trabalho terminou com uma conversa entre o André, o Felipe e eu.
Na conversa entrou em pauta gestão de pessoas e coisas do tipo.

Quando o assunto é a responsabilidade sobre problemas existentes e erros cometidos, sou da seguinte opinião:

O único erro condenável é o de não errar.
Se você não erra, isto quer dizer que:

Você não se arriscou
Você errou mas não percebeu o erro
Você errou mas não assumiu a responsabilidade
Você nunca erra. Será mesmo?

Exceto pelo erro da omissão, todos os outros erros são bons.
Errar te dará oportunidade de aprender, corrigir e evoluir.
Não errar, por outro lado, significa deixar de aprender e consequentemente deixar de melhorar.

Um ponto importante a ser citado é o seguinte:
É muito importante que a sua equipe valorize a transparência sobre a responsabilidade de problemas e erros cometidos.
Assumir um erro ou um resultado ruim deve ser visto com bons olhos, pois isto só tem a agregar com o comprometimento, dedicação e união da equipe.
Aprendi isto com o André, que constantemente assume os erros dele, além de ter uma clara percepção dos erros cometidos pela equipe como um todo.

Meu último erro é bem recente: não garanti o nivelamento das expectativas de auto-organização e o senso de responsabilidade da minha atual equipe, sobre o projeto em que estamos atuando.
Percebi o erro, sinalizei, e já estamos trabalhando para corrigí-lo.
E o aprendizado decorrente deste erro será de grande valor.

E você, qual foi o seu último erro?

Agile na Cascata: Fábrica?

rafanoronha — Sat, 31 Jul 2010 13:13:58 +0000

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

Outro dia li uma frase interessante no blog do Phillip Calçado:
Você pode ter de vestir uniforme de marinheiro, mas ainda é um pirata.

O objetivo deste post é chamar a atenção para o fato de que nem tudo é oito ou oitenta.
Enquadrar-se em um modelo não significa estar fadado a sofrer com as diculdades implicadas pelo modelo, ou limitar-se aos resultados normalmente alcançados sob este modelo.

O sucesso de um projeto depente diretamente de profissionais competentes.
Diversas outras variáveis podem interferir em seu resultado.
Mas nada é tão importante quanto a competência e os interesses das partes envolvidas.

Qualquer desenvolvedor de software competente terá arrepios ao ouvir falar do modelo de fábrica de software.
No entanto, nossa experiência tem mostrado que é possível sim atuar com sucesso sob este modelo.
Aqui a gente entra no escopo do primeiro valor do manifesto ágil:

Individuals and interactions over processes and tools

Se a sua equipe é formada por profissionais que conhecem os problemas existentes no modelo de fábrica, o fato é que estes profssionais possuem o discernimento necessário para interpretar e resolver problemas decorrentes do relacionamento entre cliente e fornecedor.

No dia-a-dia de projetos a equipe aprenderá as lições a serem aprendidas, e a tendência é que o relacionamento com o cliente melhore cada vez mais, a medida em que o fornecedor demonstra estar interessado em prestar um serviço diferenciado.

Resumindo: coloque bons profissionais para trabalhar, dê liberdade e autonomia a eles, amadureça o relacionamento com o cliente à medida em que algumas lições são aprendidas, e bons resultados tendem a aparecer.

Curiosidade:
Algo interessante na experiência de atuar em projetos de fábrica é o fato de que os clientes realmente acreditam que o modelo faz algum sentido.
É realmente divertido escutar e confrontar as opiniões dos gestores destes clientes.

Agile na Cascata: Contexto

rafanoronha — Thu, 29 Jul 2010 23:14:11 +0000

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

Aqui tentarei contextualizar o cenário que envolve as experiências que me levaram a escrever esta série de posts.

Nossa equipe

O SDC conta hoje com quase cem profissionais.

Somos um time multidisciplinar e que apóia o processo de desenvolvimento de modo iterativo e incremental.

O maior patrimônio de nossa equipe é a cultura:
Não possuímos níveis hieráriquicos rígidos, não tratamos nossos profissionais como recursos, não possuímos gerentes de projetos que micro-gerenciam atividades.
Isto porque valorizamos nossos profissionais e acreditamos que eles são completamente capazes de cuidar da organização de seus projetos.

Um de nossos maiores desafios tem sido escalar esta cultura, devido ao fato da equipe vir crescendo bastante para dar vazão às demandas de nossos clientes.

Nossos serviços

Atualmente nossa equipe atua em quatro verticais:

Outsourcing de Aplicações;
Agile;
Cloud Computing;
Fábrica de Software

O cliente

Esta série de posts é um apanhado das minhas experiências dentro do SDC.
Venho atendendo a um único cliente desde minha chegada ao SDC.
Trata-se de uma instituição financeira de grande porte.

Como eu disse no post de inauguração da série, grandes corporações estruturaram-se de modo que área de negócios e área de TI se conflitem, baseando seu relacionamento em um processo rígido e burocrático.

Agile na Cascata?

A motivação para compartilhar a experiência de minha equipe vem do fato de atuarmos em um cenário ainda um tanto quanto estranho para os partidários da Agilidade.

Nós reconhecemos a dificuldade de implantar Agile no cenário de outsourcing, (des)amparados pelo modelo de fábrica de software.
No entanto, temos tido sucesso na adaptação da cultura e práticas de agilidade a este cenário, e é sobre algumas das lições aprendidas que estarei escrevendo nesta série de posts.

Série de posts Agile na Cascata

rafanoronha — Wed, 14 Jul 2010 02:00:47 +0000

Nos próximos textos a serem publicados por aqui, estarei compartilhando algumas experiências vivenciadas por minha equipe, de algum tempo pra cá.

A idéia é mostrar como nós temos atendido demandas de projetos de software de um grande cliente do setor financeiro.

É de conhecimento da comunidade que grandes instituições financeiras tipicamente possuem uma área de TI burocratizada, que viciou-se em atender a área de negócios através de um modelo rígido e baseado em ciclos, também conhecido por waterfall.

O que estariam eu e minha equipe, agilistas ferrenhos, desempenhando dentro deste cenário?
Nos próximos posts!

(Inglês) isValid() doesn’t belong to the Domain

rafanoronha — Thu, 01 Jul 2010 03:08:00 +0000

Este texto está disponível apenas em Inglês.

(Inglês) And speaking about repositories…