BCF - padrão ouro de comunicação

Desde sempre quando gerenciei e coordenei projetos, precisei me preocupar em acompanhar as Issues.

O termo “Issues” pode acabar sendo algo subjetivo as vezes, mas entenda como assuntos ou tópicos que necessitam de resolução. A resolução pode ser uma simples resposta, uma referência a um documento, uma ação dentro de um prazo limite ou qualquer coisa que possa ser registrada e ter um responsável atribuído.

A estrutura do BCF é voltada a tópicos, conforme abaixo: { "BCF_schema_2.1": { "topics": { "guid": "", "server_assigned_id": "", "creation_author": "", "title": "", "labels": [], "creation_date": "", "topic_status": "", "topic_type": "", "assigned_to": "", "priority": "", "description": "", "bim_snippet": { "snippet_type": "", "is_external": "", "reference": "", "reference_schema": "" }, "viewpoints": [ { "guid": "", "perspective_camera": { "camera_direction": "", "camera_up_vector": "", "field_of_view": "", "aspect_ratio": "" }, "lines": [ { "line": "" } ], "clipping_planes": [ { "clipping_plane": "" } ], "bitmaps": [ { "bitmap": "" } ], "snapshot": { "snapshot_type": "", "snapshot_data": "" }, "components": { "selection": { "component": { "ifc_guid": "", "originating_system": "", "authoring_tool_id": "" } }, "coloring": { "color": "", "components": [ { "component": { "ifc_guid": "" } } ] }, "visibility": { "default_visibility": "", "exceptions": [ { "component": { "ifc_guid": "", "originating_system": "", "authoring_tool_id": "" } } ], "view_setup_hints": { "spaces_visible": false, "space_boundaries_visible": false, "openings_visible": false } } } } ], "comments": [ { "guid": "", "date": "", "author": "", "comment": "", "viewpoint_guid": "", "topic_guid": "", "authorization": { "comment_actions": [ { "action": "" } ] } } ], "files": [ { "ifc_project": "", "file_name": "", "reference": "" } ], "authorization": { "topic_actions": [ { "action": "" } ], "comment_actions": [ { "action": "" } ], "viewpoint_actions": [ { "action": "" } ] } } } }  Como a principal atividade de um gerente ou coordenador de projetos é a comunicação, identificar a ferramenta necessária para ter uma comunicação efetiva e controle dessas Issues foi fundamental para mim. 

Antes de começar a explorar qualquer coisa relacionado a BIM, já havia desenvolvido internamente na DRCPro os processos de coordenação de projetos da equipe e, coincidência ou não, o nome que quis dar foi algo bem específico e de propósito mesmo: “FLUXO DE INFORMAÇÕES EM PROJETOS”.

O nome por si só não diz nada. Mas o nome já dava uma pista do que hoje posso afirmar, que na época o olhar já estava para a direção correta para resolver o problema. 

Os processos tinham todos por objetivo padronizar o recebimento, tratamento, envio e armazenamento de informações no departamento de desenvolvimento e coordenação de projetos da DRCPro.

Veja abaixo um exemplo de um desses processos (imagem dividida):

Processo 10 do Fluxo de informações de projetos da DRCPro Engenharia

Todos esses processos possuem na sua estrutura: origem da informação, local e forma de armazenamento (pasta, quadros de Monday), regras de organização, forma de controle, responsável por armazenar a informação e responsável por lidar com a informação e tomar ações.

Veja bem, esse conjunto de coisas, representa praticamente todas as necessidades de manipulação de informações num projeto. A equipe absorveu com perfeição o fluxo de trabalho e inclusive influenciamos escritórios parceiros a adotar práticas semelhantes.

O BCF como meio mais eficiente

A estrutura do BCF é perfeita. É uma afirmação forte e espero convencer os leitores dela. É o que acredito.

Responda algumas perguntas a si mesmo antes de prosseguir a leitura:

1. Quantos relatórios de compatibilização já recebeu ou enviou que possuíam imagens?
   

2. Quantos relatórios de compatibilização necessitam de respostas e respostas das respostas?
   

3. Quantas vezes já precisou separar um email em outros emails pois os tópicos se misturaram na conversa?
   

4. Quantas vezes já precisou delegar a alguém um tópico que necessita de solução e tem prazo pra ser feito?
   

5. Quantas vezes precisou resolver uma questão e referenciar arquivos, links, vistas num modelo?

Se você já se deparou com as situações acima eu acredito fortemente que vou te convencer.

Em outro momento podemos entrar nos detalhes de cada um dos dados possíveis de um tópico BCF, pois eu teria que dedicar alguns bons artigos para explicar ele como um todo. Talvez faça isso em algum outro artigo dependendo do interesse dos leitores, comente caso tenha interesse. Se quiser receber o PDF para você ver 100% da estrutura do seu BCF, comente nesse artigo e disponibilizarei. Se eu colocar link aqui, o LinkedIn irá prejudicar o artigo.

Para o momento, com uma leitura geral e rápida daquela estrutura do BCF, vemos vários itens que permitem lidar com as respostas das perguntas que coloquei antes e com os principais dilemas de organização de informações em uma Issue de projeto.

O BCF é o formato que a BuildingSmart preconiza como formato de colaboração BIM orientado a arquivo, em tradução livre. Agora vem a questão da tecnologia voltada ao BIM.

Acontece que os softwares de modelagem, eu diria que quase em sua totalidade, possuem capacidades de leitura e criação de tópicos BCF, com umas pequenas falhas ou fuga da especificação aqui e ali, mas altamente aderentes à especificação. 

Aí é que começa o problema. Os softwares de modelagem estão se tornando os softwares por onde você faz a criação e recebe os apontamentos, mas esses softwares NÃO SÃO feitos para fazer o acompanhamento e gestão das issues.

A causa desse problema, a meu ver, é justamente a colaboração orientada a arquivos. Quando isso ocorre, necessariamente um GED (gestor eletrônico de documentos) se torna o funil por onde as informações passam e consequentemente, o componente principal do CDE. O que não é a prática recomendada!

Na minha visão e também da PR 1015 e da BuildingSmart, o GED não deve ser o pivô para troca de informações, ele deve apenas ser um componente do CDE. O que fazer então se os softwares que manipulam corretamente os arquivos BCF, não são bons para organizar informação? Infelizmente o formato orientado a arquivo pode induzir a isso, mas há solução.

A solução é trazer esses arquivos BCF para ambientes colaborativos que por natureza possuem alta eficiência em manipulação da informação e gestão de Issues, bem como tornam a comunicação de formato adequado natural e fácil.

Esse é o ponto que nos encontramos hoje, onde os fluxos de trabalho interno possuem padronização que permitem sua integração com o formato BCF, que por sua vez é o formato que consideramos ideal para lidar com Issues durante o ciclo de vida de um projeto.

A especificação da BuildingSmart para o BCF é a base que usamos para fazer a integração tecnológica entre as plataformas de colaboração e os arquivos de compartilhamento de informações (clashs de projeto por exemplo). Veja a seguir um exemplo:

Gestão de BCF através do Monday. Integração desenvolvida pela Makedrive Tecnologia

Esta é a tela de controle de BCF dentro do Monday onde a Makedrive Tecnologia fez a integração com saída de software de clash para um ambiente altamente colaborativo e naturalmente direcionado a gestão de dados e comunicação.

Essa integração entre plataforma e formato aberto, realizado através de tecnologia própria, é o que permite trazer os fluxos de trabalho para mais próximo ao padrão OpenCDE da BuildingSmart, que será assunto para artigos posteriores.

Recomendo a quem queira ouvir, que adote como prática de gestão das suas issues o padrão BCF e que onde possível, faça as integrações entre ferramentas similar às que fizemos, pois facilitam muito o trabalho.

No futuro, pretendo trazer mais detalhes de como manipular esse tipo de arquivo e integrar isso nas ferramentas de Work OS.