20 julho 2008

Profissão: analista de sistemas

Quando me perguntam por aí qual a minha profissão, ou quando preciso responder isso em algum formulário “genérico”, costumo responder: Analista de Sistemas. É uma resposta também “genérica”, rápida, que não exige maiores explicações e satisfaz a maioria das perguntas - normalmente feitas apenas por obrigação.


Embora seja um termo meio “genérico” demais - e até obsoleto sob certos pontos de vista - ainda o utilizamos em muitos contextos, como no debate sobre a regulamentação da profissão. Não pretendo aqui entrar no mérito dessa discussão, mas refletir sobre o significado do termo em si, questão um pouco mais fundamental, cuja reflexão pode alimentar e influenciar opniões sobre o assunto.

Afinal, o que faz um analista de sistemas? Ora, se interpretarmos ao pé da letra, deve ser alguém que estuda sistemas e o divide (corta, quebra) em outros menores, mais simples, para que se possa compreendê-los mais facilmente. Não é difícil encaixar nessa definição alguns papeis e funções que costumamos ver em projetos de software tradicionais.

O “analista de requisitos” esclarece os detalhes de um dado domínio, através de modelos, diagramas e descrições. Seu “sistema” são os processos do cliente. O arquiteto analisa o problema em módulos, componentes, camadas, e outros recortes. Seu “sistema” é um programa, (ou vários) visto como um todo. O programador divide cada funcionalidade e operação em funções, procedimentos, estruturas de dados e instruções.

A visão tradicional de um analista de sistemas passa, de um modo ou de outro, por um desses aspectos. Ou por todos ao mesmo tempo, considerando-os especializações, ou rumos a se seguir dentro da profissão. Enxerga “o sistema”, portanto, como toda essa “coisa” que automatiza (informatiza) os processos do cliente.

Em metodologias ágeis costumamos identificar um número menor de papéis, ou especializações, criado uma visão mais holística de equipe, que ressalta valores como interdisciplinaridade, auto-organização, habilidades sociais, lideranças, etc.

Mas, se por um lado tem-se menos tipos de “analistas”, por outro enxergamos mais “sistemas” a serem analisados, compreendidos e geridos. Ou pelo menos um sistema mais completo, que vai além dos saberes técnicos que são ensinados nas faculdades de tecnologia - cursos focados em teorias e técnicas matemáticas, exatas, objetivas.




Essas metodologias reconhecem outros sistemas extremamente relevantes aos processos de desenvolvimento. Aspectos humanos e organizacionais, jogos de intenções e interesses, forças políticas, estruturas sociais e questões motivacionais. Um emaranhado de fatores que compõem o ambiente e a cultura da empresa, e que fazem parte do inconsciente coletivo da equipe. Questões importantíssimas e determinantes para o sucesso de qualquer projeto.

Um arquiteto pode estar mais preocupado com seu ego do que com o bom andamento do projeto, ao propor uma solução complexa demais; um gestor pode estar mais interessado em seguir uma tendência de pensamento com que sua gestão já se comprometeu; um programador pode não tirar uma dúvida importante de projeto com o cliente pela estrutura de comunicação que se criou; ou pode não sinalizar sobre um problema que identificou no design por causa de sua baixa auto-estima junto à equipe.

O desenvolvimento de software é acima de tudo uma atividade criativa, de aprendizado coletivo e de auto-conhecimento para todos: clientes, usuários, programadores. Ao mesmo tempo que a equipe está aprendendo os detalhes tecnológicos envolvidos na solução, usuários estão aprendendo a ver de forma mais clara seus processos de trabalho. A equipe como um todo (incluindo cliente e usuário) está aprendendo a se comunicar e a colaborar para desenvolver uma visão única e coesa do “sistema”, aprimorando seu processo de trabalho a cada dia (melhoria contínua).

Sob esse novo ponto de vista, a expressão “analista de sistemas” ganha uma conotação integral, levando em conta um sistema mais âmplo, que precisa ser não apenas analisado, mas percebido, compreendido, refletido e gerido.

02 julho 2008

Programação em par

Essa talvez seja a prática mais demorada de se aprender em XP. Não que seja extensa ou complicada. Nada disso.


A questão é que, para se compreender a prática de verdade, é preciso primeiro acreditar nela.

O pensamento mais imediato, claro, é sempre imaginar que se gasta o dobro para realizar a mesma tarefa. Esse pensamento não está certo. Porque a programação é uma tarefa criativa e não respeita à lei "quanto mais gente, mais trabalho se realiza". Nesse caso, a qualidade do código produzido interfere muito na produtividade dos próximos passos. Então vale muito mais a pena "gastar" o dobro da atenção sobre cada parte dele.

Não é fácil argumentar sobre isso, nem é esse o meu propósito aqui. Quem já experimentou programação em par "na veia" vê isso com uma clareza impressionante. Mas pra quem está iniciando, acreditar nisso não é tão natural.

Quanto mais se acredita, melhor se pratica. Quanto melhor se pratica, mais se acredita. Mais um ciclo virtuoso que costuma estar presente em XP.

Aqui está um screencast muito interessante pela própria "inovação tecnológica" da idéia. Mais interessante ainda pela forma como consegue expor uma seção de programação em par tão de perto. Quase que se participa dela. Impressionante!

(Sugestão: assista em full-screen)


Cola: Real-Time Shared Editing from Mustafa K. Isik on Vimeo.

A programação em par, quando acontece fluida, assemelha-se muito a uma conversa, ou uma seção de design, onde se discute a modelagem do sistema com papel e lápis. Se a programação for guiada por testes ainda por cima, aí é que a coisa fica bonita!

Alguém se habilita pra gravar algumas seções com foco mais metodológico que tecnológico, usando TDD, BDD, etc.?