Início > Uncategorized > Quem estrutura o que?

Quem estrutura o que?

É o projeto que estrutura o processo ou, pelo contrário, é o processo que comanda tudo, organizando o projeto?

Costumo ler com satisfação os artigos que Roberto Damatta publica às quartas feiras no jornal O Globo. O do dia 4/4/2012, intitulado “Quem interpreta quem?” captou minha atenção de forma especial. Nele, três pequenas estórias dão o suporte a uma ideia básica.

Na primeira, ele relata a experiência em que assistiu, em Viena, à ópera “As Bodas de Fígaro”, de Mozart. Durante a apresentação ele pensava:

é a orquestra que interpreta Mozart ou, pelo contrário, é Mozart quem comanda tudo, interpretando a orquestra?

A segunda estória, com base no CD “Grande Cancioneiro Americano” gravado por Rod Steward e que ele sempre ouvia com grande prazer, é concluída assim:

Um dia, porém, entendi tudo. Quem cantava as músicas não era o Rod Steward. Muito pelo contrário, eram as canções que se cantavam por meio de sua voz.

O terceiro caso comenta uma ilustração do desenhista Bruce McCall sobre a premiação do Oscar, (achei o link: http://archives.newyorker.com/?i=2012-02-27) na qual os papeis estão invertidos: alguns Oscars “agigantados” estão comemorando o recebimento de estatuetas de humanos. Eis como ele encerra a estória:

Pergunta-se: é o premiado quem recebe o prêmio (e por ele fica marcado, como quer nossa vã filosofia) ou é o prêmio quem recebe o premiado, como sugere a ilustração de McCall?

Pensei muito sobre o artigo, sobre essa dúvida quase filosófica que sempre pode nos ocorrer quando um artista interpreta a obra de outro artista, como costuma ocorrer com frequência nas apresentações musicais e teatrais. O intérprete sempre tem que se doar, se deixar transportar para o ambiente da obra, de certa forma se deixar ser possuído pelo sentimento e intenção do autor. Estendendo a metáfora,

é o autor que cria seus personagens, ou seriam os personagens que se exprimem através do autor?

Muitos autores comentam que, à medida que a história se desenvolve eles perdem o controle sobre seus personagens que parecem adquirir vida própria.

Nós, profissionais de desenvolvimento de software, passamos muitas vezes por situações semelhantes. Situações em que, talvez sem perceber, utilizamos o conhecimento e a experiência de outros para produzir o resultado de nosso trabalho. Creio que podemos aprender com as artes, que já produziam espetáculos muito antes de o primeiro software ser elaborado. Para ilustrar a proposta, esboço a seguir um paralelo para duas situações que julgo significativas.

____________________________

A primeira está na raiz de nossa atividade! O que é desenvolver software? Numa visão abrangente (e simplificada) do problema, podemos dizer que

desenvolver software é transformar as necessidades e desejos de um grupo de pessoas em software.

As necessidades e desejos, assim como as pessoas responsáveis por sua definição, provavelmente são relacionados a um ou mais objetivos de negócio, que constituem a chave para o sucesso ou fracasso de nosso trabalho. Assim, nossa tarefa fundamental é entender as necessidades e desejos dessas pessoas no seu  contexto de negócio.

Que tipo de atitude devo tomar para essa tarefa? Sou eu que vou identificar e entender tudo (os outros participantes são coadjuvantes, fornecedores de informação); ou são as necessidades e desejos que se farão entender através de todo o grupo (do qual sou uma parte)?.

Você pode responder que isso não tem tanta importância assim, pois o que importa é o processo que será utilizado. Concordo que o processo é importante, mas, qualquer que seja o processo utilizado, o enfoque, o estado de espirito com que abordamos o assunto e participamos da equipe também são fundamentais para o sucesso.

Para entendermos toda a complexidade e sutileza dessa atividade, imagine uma companhia de teatro, com seus atores, o diretor, e a infraestrutura de apoio. É uma equipe profissional, já estabelecida no mercado teatral e reconhecida pelo público, que costuma prestigiar suas apresentações. A cia deseja encenar uma peça totalmente nova, e contratou um escritor para elaborar o texto e o roteiro. Sabe-se que será uma comédia, e um texto de duas páginas registra um resumo da história e um esboço dos principais personagens. A proposta é que seja uma criação coletiva, com a participação de todos, cabendo ao diretor a tarefa de direcionar o trabalho, especialmente nas situações de alternativas conflitantes;

Parece complicado? Nossa situação é bastante semelhante à do escritor acima. Somos contratados para escrever uma “peça” (o software) que deve atender às diversas necessidades de nossos “stakeholders”. Também será uma produção coletiva, pelo menos no que diz respeito à identificação e definição das necessidades.

À medida que nosso texto/software toma forma e as cenas/funcionalidades podem ser ensaiadas/utilizadas pelos atores/usuários o entendimento pode mudar, novas falas podem surgir, um personagem secundário pode ganhar importância não imaginada, teremos que mudar seu figurino e acrescentar novas cenas/funcionalidades.

Ao final, a peça/software poderá ser representada/utilizado sem a nossa participação, e nosso nome nem precisa estar nos créditos. Somos uma espécie de “ghost-writer”, e para que possamos cumprir nosso papel a contento e entregar o produto desejado, temos que estar em profunda sintonia com todo o grupo que nos contratou, deixar que os personagens e suas necessidades se manifestem através de nós.

E depois de tudo isso, não se pode garantir que a peça será um sucesso. É a vida!

“O correr da vida embrulha tudo. A vida é assim: esquenta e esfria, aperta e daí afrouxa, sossega e depois desinquieta. O que ela quer da gente é coragem.” 

Guimarães Rosa

____________________________

A segunda situação em que podemos utilizar uma metáfora semelhante à do artigo está relacionada com o processo que utilizamos para transformar as necessidades em software (e que pode abranger os procedimentos para se identificar e entender as necessidades, os requisitos).

Até uns trinta anos atrás a metodologia (como chamávamos nosso processo) utilizada era elaborada dentro da empresa, considerando suas características específicas. Se voltarmos um pouco mais no tempo – iniciei na área em 1965, pode-se dizer que sou da era do bit lascado Alegre – não existia uma metodologia definida formalmente; as atividades do dia a dia eram discutidas e definidas em grupo, à medida que o projeto avançava e os imprevistos surgiam (semelhante ao “daily meeting” do Scrum).

Hoje parece que estamos no extremo oposto, uma grande quantidade de processos estão disponíveis para serem utilizados, cada qual propondo sua forma específica de organizar o desenvolvimento de software. Creio que esse movimento de ir de um extremo ao outro foi positivo, considerando que passamos a ter diversas técnicas que podem ser úteis em muitas situações, todas documentadas e com treinamento disponível.

Como nos orientar para definir o processo a ser utilizado? devemos adotar um processo de mercado, um método ágil como Scrum ou Kanban, por exemplo? Podemos misturar práticas de processos diferentes? Neste caso, uma metáfora apropriada seria:

é o projeto que estrutura o processo ou, pelo contrário, é o processo que comanda tudo, organizando o projeto?

Creio que devemos adotar uma postura flexível, livre de qualquer dogma sobre o assunto, pois não existe uma solução ótima para todas as situações. (meu post anterior trata do assunto)

Entendo que a decisão deve ser orientada por diversos fatores como as características do projeto, as expectativas dos stakeholders/usuários, as habilidades da equipe de desenvolvimento e a cultura organizacional da empresa. O fundamental é que

a equipe deve estar à vontade para estruturar o processo como uma ferramenta para promover o sucesso do projeto, sem se prender a qualquer tipo de dogma.

____________________________

Conclusão

Gosto de pensar o desenvolvimento de software através de metáforas relacionadas com o ambiente artístico, como a produção de uma peça de teatro ou de um filme, com as quais compartilhamos muitas características em comum, sendo as mais importantes a imaterialidade do produto e a importância da criatividade para a elaboração do mesmo.

Creio que essas metáforas possibilitam a percepção da complexidade de nosso trabalho e da vulnerabilidade de nossos planos e expectativas de forma mais apropriada do que aquelas associadas com processos fabris ou da construção civil.

Temos muito a aprender com as artes. Mais do que julga nossa vã filosofia.

E você, o que acha? Concorda mas não muito, discorda. Compartilhe, assim evoluímos nosso conhecimento.

Categorias:Uncategorized
  1. Nenhum comentário ainda.
  1. No trackbacks yet.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: