ISO 19650-2 made easy (or so)

#0039: Seguindo na discussão dos conceitos trazidos pela ISO 19650, vamos discutir a parte 2 do texto que trata da fase de entrega de ativos e o que tem de possível novidade no processo.

Delivery (1/7)

Na primeira parte da discussão sobre a 19650 tratamos dos conceitos básicos que a ISO de organização e digitalização da informação trouxe ao fazer referência aos requisitos diversos, contêineres e tudo que faça referência a informação.

Aquela velha história, para quem não sabe para onde ir qualquer caminho serve, e é exatamente isto que a parte 1 tenta evitar dando um caminho das pedras em termos de referências e objetivos.

A segunda parte desta ISO já tem uma abordagem um pouco mais pragmática e discorre da necessidade de se pensar o processo de entrega do ativo com alguns insights muito interessantes.

O objetivo do texto aqui não é entrar na bunda do mosquito de cada um dos itens descritos na norma, até porque para isso é mais fácil escrever um livro.

O importante destas discussões é analisar que assim como a tecnologia evolui, esses processos também estão evoluindo e vão necessariamente ser revistos de tempos em tempos, mas o que gosto do processo da 19650 é que algumas coisas vão ser atemporais, e é nessas questões atemporais que quero focar.

Assim como comentei na primeira parte da discussão, alguns conceitos só fizeram sentido quando buscamos os conceitos originais da PAS 1192. Já no caso da parte 2 só fez sentido mesmo quando fomos para o pau do dia a dia.

Então vamos parar de enrolar e iniciar a discussão daquilo que considero o mais importante da parte 2 em termos de conceitos, obviamente tem mais coisa, mas aí não da para ter tudo mastigado na vida.

Conte até oito (2/7)

A parte 2 define oito momentos de gestão de informação para entrega de ativos, vou utilizar os termos originais da tradução de 2019, mas adianto que virão algumas mudanças na revisão da ABNT quando ela for lançada:

• 1. Avaliação e necessidade: com base na estratégia do negócio, necessidades do empreendimento e os requisitos da organização é gerado os requisitos de informação do projeto, só aqui dá para ter no mínimo uma dissertação de mestrado a respeito em detalhes, tem muita coisa, recomendo a leitura do texto original para entender bem o que falam.

• 2. RFP: estabelecido os requisitos de informação do projeto que vai ter no mínimo as datas de entrega, padrões, procedimentos, compartilhamento de info e o CDE, aí é gerar a famosa Request for Proposal (RFP) - aquele documento que não deveria ter 200 páginas de um manual de software 😉 - aqui é onde o contratante define suas regras.

• 3. Resposta RFP: quem foi convidado a participar do certame vai analisar a RFP e gerar a sua proposta de resposta ao que o contratante está pedindo. Um grande grandessíssimo erro que é muito comum mercado é o contratante achar que é papel do contratado harmonizar e se adaptar a tudo que foi pedido, pelo contrário, é papel do contratante receber todas as respostas de propostas e harmonizar o conteúdo.

• 4. Contratação: Na harmonização que o contratante está fazendo fatalmente vão surgir temas e tópicos para adaptação nas propostas recebidas, vai ter gente que não vai aceitar um ou outro termos, mas aí é questão de negociação. Uma dica: seja humilde, ninguém é um deus onisciente. Sempre haverá coisas para modificar tanto pelo contratante quanto pelo contratado, ninguém é perfeito e não é o fim do mundo ouvir uma sugestão ou crítica no processo, minimamente estamos todos aprendendo.

• 5. Mobilização: Contratos assinados, esta é uma fase que o TI das empresas chora, hora de subir todos os sistemas, parametrizar e configurar as coisas, liberar acessos, instalar isto e aquilo e se você não tiver alguém no perfil faca na caveira no TI, desculpa o francês, mas fodeu. Roda presa no TI é a pior coisa que existe, vai te obrigar a pegar o facão e abrir a mata você mesmo.

• 6. Produção colaborativa: Sistemas e acessos liberados e testados, hora de começar a gerar informação, aqui é produção seguinte os estados de compartilhamento dentro do CDE. Outra parte que é um tratato que deve ser lido no texto original.

• 7. Revisão: Produtos gerados é hora de enviar para o querido cliente, claro, você contratado faça sua revisão interna para saber se está cumprindo aquilo que foi combinado na RFP, mas se você é contratante, sua vez de analisar e ver se o contratado está cumprindo tudo. Um conceito interessante aqui é rejeitar todo o contêiner de informação caso tenha algo para arrumar (briga a vista entre os projetistas se isso não for bem tratado no kickoff do projeto).

• 8. Encerramento: tudo deu certo, finalizado as coisas, hora de sentar o time e fazer a retrospectiva do projeto e registro do que deu certo, o que deu errado e assim escrever a base dos ativos organizacionais da empresa.

Resumido bem por cima, sem detalhes, vai por aí.

Não gere mais informação do que solicitado (3/7)

Regra número um da 19650: não gere mais informação do que foi solicitado.

Quem está na frente do desenvolvimento de projetos muitas vezes tem ali os seus templates todos configurados, componentes altamente inteligentes desenvolvidos, folhas, tabelas e materiais todos já customizados e pronto para encarar qualquer projeto.

Aí que está né, o contratante foi lá e solicitou um IFC com as informações principais que ele precisa para rodar o processo dele, mas como a empresa de projetos desenvolveu todo o template sem pensar e configurar a saída para um formato aberto, a pessoa apertou um botão com uma configuração qualquer de exportação e enviou para o contratante.

Pronto, adiantou absolutamente nada ter pensado em requisitos de organização, projeto, troca de informação, proposta bem formatada e ppt bonito se você está enviando coisas que não fazem o menor sentido para o seu cliente.

Muitas vezes existe sim um preciosismo na hora de gerar os modelos e queremos mostrar que sabemos o que estamos fazendo, tem um lado de CX na história de encantar o cliente, surpreender etc., mas neste caso é uma faca de dois gumes, por quê? Alguém vai ter que gastar energia analisando se o que foi feito está de acordo com as solicitações e, como dificilmente as coisas são apertar um botão e está pronto sem formatação, você está diminuindo a sua margem no projeto por algo que o cliente não vai te pagar a mais. Tirando o fato de que você vai correr o risco do cliente te pedir isso 100% vezes no futuro sem te pagar a mais.

No final do dia o que mais acontece é o contratante perceber que faltou alguma coisa, mas fica a dica sobre não gerar mais informação do que foi solicitado.

Capacity / Capability (4/7)

Um dos conceitos mais legais da 19650 é a questão do capacity / capability ou capacidade e competência.

Muitas e muitas vezes as empresas pedem em suas RFPs atestados de capacidade sobre o que a empresa já fez no passado esquecendo de uma regra de ouro dos investimentos: ganhos no passado não são garantia de ganhos futuros.

O ponto que a ISO estabelece é que se deve ter um processo de validação não só da capacidade da empresa de entregar o que está prometendo, mas também da competência do quadro de profissionais que vai participar do projeto.

Afinal, se a empresa fez um projeto qualquer em 1980 e nunca mais fez mais nada parecido com aquilo mesmo que isto esteja no portfolio dela não quer dizer muita coisa em 2022. Outro ponto aqui é que a empresa pode também ter feito dez estádios para a copa do mundo, mas e se grande parte do time que participou dos projetos saiu? Entenderam o ponto?

Pensar formas de ter requisitos a serem cumpridos tanto para empresas quanto para profissionais é uma maneira inteligente de mitigar o risco de contratar alguém que não vai dar conta do recado no futuro.

Evoluindo a discussão o problema mesmo é confirmar que os profissionais têm as competências técnicas necessárias para executar as tarefas. Principalmente com a massificação da informação pela internet é a coisa mais simples do mundo aparecer alguém com um certificado.

Se postou o certificado no LinkedIn então é garantia de que o profissional aprendeu tudo e é o novo messias do seu projeto, pode confiar. (#ironia)

MIDP TIDP (5/7)

O que vai acontecer é que na sua RFP você tem as datas marcos do projeto e um guia do que deve ser executado, com base nisso cada contratado vai analisar e gerar os seus próprios planos de entrega das tarefas a serem executadas.

Será papel então do contratante harmonizar os planos de entrega das tarefas para formar o plano de entrega geral do projeto. Na 19650 existem dois termos para aumentar a sopa de letrinhas para definir essas coisas, são eles:

• Task Information Delivery: Plano de entrega de tarefas que nada mais é do que o plano da contratada para gerar a informação que o contratante esta solicitando. Ali tem que ter quem são os responsáveis por fazer as coisas, os contêineres de informação que serão entregues, as dependências, durações e datas de entrega. E um item que vou deixar para o próximo tópico: level of information needed.

• Master Information Delivery Plan: Plano de entrega de informação que nada mais é do que a combinação de cada plano de entrega das tarefas (TIDP) e harmonização das coisas definindo as responsabilidades na visão macro do projeto, dependências, tempo que a contratante precisa para analisar as coisas e assim vai.

Particularmente o processo definido na ISO é bem cascatinha e isto acho que em algum momento vai ter que ser modernizado para novas práticas de gestão de projetos por fluxo, agilidade etc.

Eu gosto mais da ideia de ter um backlog de contêineres com priorização semanal e remanejamento das atividades e prioridades através de sprints de trabalho, o problema para ser solucionado aqui é você ter squads de trabalho de empresas diferentes, com culturas diferentes, trabalhando em conjunto, pode ser a receita para o desastre.

Nas vezes em que utilizamos isto em times internos da mesma empresa, digamos que a squad foi embora para casa em sexta-feira de entrega de projeto as 17hrs e os cascatinhas de outros projetos vararam a noite no café já escrevendo e-mail para o cliente pedindo desculpas pelo atraso.

Aqui é onde tem mais margem para discussão e proposições.

Nivel de Informação necessário (6/7)

Um dos conceitos mais bacanas desta ISO foi o de estabelecer um conceito objetivo para descrição da extensão e granularidade da informação em um objeto / projeto.

Quantas vezes recebi RFP dizendo que o projeto deveria ser entregue no LOD 400 ou várias tabelinhas por disciplina pedindo LOD 300, 350, 200, etc. Felizmente o mercado vai amadurecendo, este tipo de métrica no passado se fazia necessário porque ninguém sabia pedir ou solicitar BIM.

O grande problema do LOD é a sua subjetividade, em sala de aula até brinco com os alunos mostrando imagens e pedindo para eles definirem o LOD do que estava sendo mostrado: nunca teve consenso e sempre teve discussão.

Então quando chega o Nível de Informação Necessário e estabelece que o negócio tem que ser objetivo, facilita horrores para todo mundo. Um exemplo: os componentes de arquitetura devem ter menos de 10000 polígonos, as informações de acordo com as tabelas de objetivos e o Psets_Common de suas categorias/vegetais/etiquetas preenchidos respeitando a nomenclatura estabelecida no projeto.

Simplificar as coisas não é ser simplório, podem existir mil outras maneiras de representar este conceito, o grande ponto aqui é fazer todo mundo entender o que está sendo solicitado e evitar que os times gerem mais informações do que foi estabelecido.

A dor do entendimento (7/7)

Existem mil outros detalhes que poderiam ter sido abordados aqui, mas para entender o que se passa na parte 2 da 19650 já está bom tamanho.

Lembrando sempre que a beleza desta ISO é que ela é adaptável ao seu mundo, pense bem antes de sair desenvolvendo 100% do que a norma está recomendando, em muitos processos é dar um tiro de canhão para matar um formiga.

Vamos conversando e falando mais sobre o tema durante o ano, tem muita bacana para acontecer ainda.

Se você chegou até aqui parabéns! Pode começar o ano fazendo uma boa ação também e seguir o canal e compartilhar este conteúdo 😊

Obrigado,

Abs.

Tiago Ricotta

Publicado em 12 de Janeiro de 2022 às 16:48