Cada tarefa deve ter um e somente um dono

Esse blog já introduziu o conceito de processos. Hoje quero dar ênfase na importância de cada tarefa de um processo ter um dono. E somente um.

Vou aproveitar o post anterior, em que são mencionadas as práticas arquiteturais e sobre o papel do arquiteto. É possível dizer que a arquitetura, no contexto da engenharia de software, é um processo. Neste, são recebidos os requisitos, que são analisados e discutidos, de forma a criar ou transformar a proposta arquitetural para o software. Como produtos de trabalho, podemos ter um documento de arquitetura e/ou modelos diversos, sugestões de aplicações de patterns, algum código de referência ou scaffolds (códigos comuns, baseados em modelos para resolver problemas simples e recorrentes), entre outros.

Dado que a arquitetura pode ser vista como um processo, a mesma é dividida em tarefas. Cada tarefa é de responsabilidade de uma única pessoa. Por que isso? Ora, se ninguém responder para uma tarefa, a mesma simplesmente não sai. É despriorizada ou esquecida. Alguém tem que assumir um compromisso perante o time que vai concluir aquele trabalho. E deve ser uma única pessoa. Não importa se duas ou mais vão executar a tarefa, se há muitos envolvidos. Apenas uma deveria responder por ela.

Ainda no exemplo da arquitetura, a definição arquitetural é responsabilidade do arquiteto. Se o mesmo é responsável por planejar, também deveria ser por acompanhar a sua entrega. Analogamente, na construção civil, podemos encontrar um "engenheiro responsável pela obra". Da mesma forma, o arquiteto de software deve acompanhar os trabalhos, para garantir que o que foi planejado será entregue.

Há várias preocupações no acompanhamento de uma tarefa. O arquiteto responsável, por exemplo, durante o processo de desenvolvimento, deveria avaliar se o time compreendeu as orientações arquiteturais, se todos entendem e sabem implementar os patterns propostos, se as dependências estão sendo honradas. Este tópico, em especial, eu preciso salientar: de nada adianta o arquiteto informar que a camada de negócios não pode depender da interface gráfica do software se o programador incluir uma s érie de bibliotecas gráficas na implementação dos serviços, gerando um acoplamento completamente desnecessário.

Ter um documento de arquitetura perfeito não garante a entrega. Para ter sucesso, o arquiteto deve observar o que está sendo feito e orientar, para ficar tudo em conformidade com o que foi planejado. E o arquiteto, insisto, deve falar também a língua do desenvolvimento. Como em qualquer processo de comunicação, o emissor da mensagem deve se preocupar se o(s) receptor(es) entende(m). Então, nada de arquiteto querer falar difícil, só para aparecer.

Entendo que pode haver algo não previsto e que precise ser repensado, mas o arquiteto deve ser envolvido e suas orientações devem ser seguidas. Isso tudo só funciona se o arquiteto se posicionar como responsável pela arquitetura. Não pode entregar um documento e sumir.

Sim, isso tem um preço. O arquiteto alocado mais tempo vai sair mais caro. Mas isso é relativo, já que no caso dele não acompanhar e o desenvolvimento não honrar o combinado, arrumar sairá muito mais caro. A propósito, alguém discute se pode tocar uma obra sem engenheiro civil ou arquiteto responsável?

Particularmente, entendo que os responsáveis devem ser especialistas. Responsável pelo banco de dados? Se for modelagem, um analista de dados; se for algo mais baixo nível, um DBA. Responsável pela infraestrutura e dimensionamento (sizing)? Um profissional de infra, especializado nisso (normalmente não seria o arquiteto de software, pois este é mais especializado em, pasmem, software e não em hardware, redes, sistemas operacionais e infra em geral...). Experiência de usuário? Outro elemento importantíssimo, que mereceria um especialista na área. Bom, acho que já deu para entender a ideia...

Provacações finais

Existe alguma atividade no seu projeto que está atrasada? A mesma tem um responsável? Tem apenas um? O responsável está apto a executar a tarefa? Tem conhecimento para isso? Foi treinado nisso?
Cada responsável acompanha a execução, quando o mesmo não é o principal executor?
Aliás, cada um, na organização, entende plenamente o que lhe compete? Sabe de suas responsabilidades? Isso fica explícito em algum lugar? Posso entrar na intranet da empresa e buscar por papeis e responsabilidades? Vou encontrar algo atualizado lá?

Comentários

Postagens mais visitadas deste blog

Documento de arquitetura

Requisitos conflitantes e dilemas no projeto de software

Arquitetura em projetos de aplicações em nuvem - noções iniciais