Reuniões virtuais com webmeeting e webconferencing

Reduzir custos do trabalho colaborativo e de reuniões.
Acelerar a troca de informações e a concepção de soluções.
Reduzir custos com viajens e telefonia.
O leitor Acácio Centeno enviou um bom texto sobre como conseguir tudo isso.
 

WebConference usando software livre.
WebConference e WebMeeting são tipos de softwares de CSCW (Computer Supported Cooperative Work), ou seja, softwares que permitem que pessoas separadas geograficamente possam trabalhar em conjunto.
As principais funcionalidades oferecidas por este tipo de sw são:
Audio/Vídeo conferência, Compartilhamento de aplicações, Quadro Branco Virtual e compartilhamento de arquivos.
Isto tem sido muito usado por empresas para redução de custos, evitanto deslocamentos e gastos com passagens e diárias.
Usando estes programas, profissionais dispersos podem fazer reuniões com vídeo conferência e compartilhamento de aplicações, como uma apresentação de PowerPoint por exemplo.
A funcionalidade de quadro branco procura imitar um quadro real, onde todos podem escrever ou desenhar à mão livre (em geral usando Tablets).
Outro cenário que tem se tornado comum são palestras e treinamentos pela net.
Usando as mesmas ferramentas, uma pessoa pode falar e fazer uma apresentação para pessoas em qualquer lugar do mundo simultâneamente.
No caso de treinamento de funcionários no uso de um software, ela pode compartilhar uma sessão do sw e demonstrar passo a passo como fazer as atividades.
Outra vantagem deste tipo de sistema é que ele permite gravar as reuniões, sendo gerados vídeos digitais que podem ser facilmente armazenados ou transmitidos, funcionando como atas eletrônicas.
Alguns permitem também a criação de questionários para que os participantes possam dar suas opiniões sobre as palestras ou mesmo para que o palestrante possa testar a compreensão do conteúdo.
Por fim, temos o cenário do teletrabalho, especialmente em áreas de serviços de conteúdo, como a informática.
Há softwares sendo desenvolvidos, por exemplo, para permitir Peer Revision, uma atividade essencial da eXtreme Programming, por pares remotos, além de ser uma forma barata e ágil para fazer consultorias, onde o consultor pode mostrar como fazer ou mesmo assumir o controle da máquina remota e auxiliar o usuário na consecução de alguma tarefa.
Eu fiz uma pesquisa inicial sobre o assunto.
Encontrei alguns softwares proprietários como os da Citrix (WebMeeting e WebConferece) que são considerados os melhores.
Outros como o Gather Place oferecem um serviço onde o cliente não tem que instalar software algum para usar.
Ele usa um applet java como viewer, assim, o coordenador apenas envia a URL da reunião para os participantes e eles podem acessá-la usando qualquer browser.
Outra vantagem deste programa é que ele permite escolher quais aplicativos serão vistos pelos clientes, assim o coordenador tem mais privacidade.
Por fim, ele escalona a imagem para caber na resolução de tela do cliente, caso a resolução do coordenador seja mail alta.
A CloudMeeting oferece um serviço em reais (R$) para usuários brasileiros, o que é importante para não ficar vulnerável à oscilação cambial.
No mundo open source, encontrei um programa no sourceforge chamado WebHuddle que é bem completo, mas um pouco “desajeitado” se comparado aos proprietários. (NR: a interface não é tão polida. Veja uma reportagem sobre ele aqui e teste um demo aqui ).
Mas o projeto que mais me chamou a atenção foi o Access Grid .
Este projeto foi financiado pelo governo americano e permite montar estruturas altamente profissionais, sendo usado atualmente por diversas entidades de pesquisa, universidades e órgãos governamentais nos EUA.
Mas o preço a pagar por tanta sofisticação é a complexidade, além de ser extremamente exigente em termos de hardware.
Além disso, para usá-lo é preciso requisitar um assinatura digital para os mantenedores do projeto (o que demora cerca de dois dias).
Outro tipo de ferramenta de CSCW importante e que complementa a funcionalide deste tipo de tecnologia são os groupwares que permitem agendar reuniões.
Mas este tipo de software já está bastante difundido, então nem pesquisei muito sobre o assunto.
Contudo, uma empresa querendo oferecer o serviço de WebMeeting para seus clientes com certeza teria que integrar sua soluções com o groupware dele.
Embora atualmente a tecnologia de WebMeeting esteja sendo mais usada por empresas para reduzir custos com deslocamento, acredito que a tecnologia deva ganhar proporções bem maiores no futuro.
Com o tempo, este tipo de tecnologia poderia substituir completamente os sistemas telefônicos empresariais (PABX) por oferecer uma série de vantagens: comunicação segura, que pode ser armazenada ou transmitida, que não tem limitação no número de participantes e que permite o compartilhamento de aplicações além de ter custo muito baixo independentemente da distância entre os participantes.
Até mesmo na vida privada este tipo de tecnologia deve substituir os Instant Messengers que temos atualmente, permitindo, por exemplo, que um filho único desnaturado que se mudou para o Rio Grande do Sul converse com seus pais no Pará e lhes mostre as fotos tiradas no último final de semana, por exemplo.
Na verdade esta tecnologia, associada a outras como Virtualização e Paravirtualização vão mudar bastante a forma com que serviços de informática são oferecidos.
Atualmente, o modelo dominante para serviços de informática é ter departamentos de TI em cada empresa, mas em um futuro próximo, digamos daqui a cinco anos, o modelo dominante deverá ser uma evolução das atuais ASPs, Applications Solution Providers.
Neste modelo as ASPs oferecerão também todos os serviços de comunicação e segurança.
As empresas clientes contratam apenas os serviços e deixarão de ter que se preocupar com o gerenciamento de hardware, software, tecnologia, treinamento, recrutamento de pessoas, segurança de informações, etc.
Deverá haver um pequeno número de provedoras de TI em escala nacional ou até mesmo global, como as atuais provedoras de telefonia, que abocanharão praticamente todo o mercado.
Nestas empresas, o fluxo de trabalho será totalmente digital.
Vamos imaginar um cenário hipotético para exemplificar as tecnologias já disponíveis hoje (inclusive em software livre) podem ser usadas para operar uma empresa como essa.
Por exemplo, um gerente de redes fora de sua sala de trabalho é notificado pelo IDS em seu PDA com WiFi que houve uma tentativa de ataque a um dos servidores.
Usando o PDA ele acessa o servidor (que na verdade é uma máquina virtual) e verifica os logs.
Ainda no PDA, ele aciona o aplicativo de groupware e convoca uma reunião on-line com os demais gerentes espalhados pela área de cobertura da empresa.
Nisto ele volta para sua sala e prepara uma pequena apresentação para mostrar o que foi detectado.
Na hora marcada para reunião, o programa de groupware o avisa e aciona o programa de WebMeeting, além de colocar seu status como “em reunião” automaticamente no sistema de comunicação interno, baseado em VoIP, que passa a gravar as ligações feitas para ele até o fim da reunião, como uma secretária eletrônica.
Na reunião, ele faz a apresentação para seus colaboradores, e abre a para discussão sobre como evitar que este tipo de ataque se repita.
À medida que as sugestões vão sendo dadas, ele as anota em um quadro branco virtual.
Para esclarecer algumas dúvidas levantadas pelos participantes sobre o ataque, ele acessa o servidor virtual e todos podem ver os logs e pedir mais informações.
Chegada a uma conclusão, ele define um cronograma de ação em um software de gerenciamento de projetos e todos recebem suas tarefas automaticamente por email.
Ao fim da reunião ele anexa os arquivos gerados, bem como o vídeo da reunião, ao sistema de gerenciamento de ocorrências.
Enquanto a reunião acontecia, em um dos clientes da empresa um PC apresentou problemas.
O usuário entrou em contato com a empresa e esta enviou um equipamento de contingência, juntamente com um técnico para configurá-lo.
O técnico alocado para o serviço é notificado em seu PDA de que deverá se dirigir para a empresa do cliente e qual era a imagem de software sendo utilizada pelo cliente (quais os softwares que ele contratou).
Ao chegar na empresa, o técnico instala a CPU substituta, configura a rede e acessa o servidor de imagens.
Ele baixa a imagem para o computador local, que passa a executá-la como uma máquina virtual.
O técnico também configura o acesso aos arquivos do usuário, que ficam armazenados nos servidores da ASP, bem como suas contas de VoIP, groupware e WebMessaging.
Em questão de poucas horas, senão minutos, o cliente dispunha de um ambiente de trabalho idêntico ao anterior, inclusive com seus arquivos.
Além disso, os PDAs ganharão uma importância maior nas empresas, especialmente a medida que começarem a estar conectados em redes WiFi.
Durante o tempo em que o computador do cliente estava indisponível, suas chamadas telefônicas eram automaticamente roteadas para seu PDA e ele podia acessar os serviços empresarias, como groupware, ERP e CRM e VoIP pelo aparelho.
Tudo isso usando um telefone bluetooth.
Ao sair da empresa, seu PDA, que também é telefone celular, passa a funcionar como um blackberry e a conectivade continua a mesma.
De volta a nossa empresa hipotética, é detectado um bug no software oferecido a outro cliente.
O gerente do projeto é notificado e convoca uma reunião com os analistas.
Estes discutem o problema e alocam um deles para projetar a solução.
Uma vez tendo a solução, o analista entra em contato com os programadores, que são prestadores de serviço na Índia.
Devido ao fuso horário, os programadores não estão na empresa deles, por isso o analista grava um vídeo onde demonstra o problema e a solução encontrada.
Ele anexa este vídeo, juntamente com uma proposta de cronograma no sistema de gerenciamento de bugs do sistema, que notifica automaticamente os programadores do erro encontrado.
Na Índia, ao chegar pra trabalhar, os programadores espalhados em três cidades diferentes lêem o relato do bug e o material gerado pelo analista.
Eles começam então a desenvolver a solução em pares, usando técnicas de Remote eXtreme Programming.
Uma vez tendo chegado a um ponto considerado satisfatório, notificam o analista e este pode testar o branch aberto na árvore do SCM do projeto.
Se aprovado, ele avisa aos programadores que eles podem fazer o merge da solução no branch principal da aplicação e gerar uma nova versão de distribuição do aplicativo.
A próxima vez que o usuário final do sistema acessá-lo, o programa identificará automaticamente a existência de uma nova versão e fará o download do patch.
Isto tudo pode inclusive acontecer em background para não prejudicar o trabalho do cliente.
Bom, este exercício de futurologia pode parecer ficção científica, mas na verdade, como falei, todas as tecnologias necessárias já estão disponíveis.
Na realidade, mesmo hoje, em empresas brasileiras, este cenário não é tão irreal assim.
Eu percebi isso um dia há mais ou menos um ano, quando trabalhava na CDP (Companhia Docas do Pará) em Belém.
Minha função era de analista de negócio / sistema do sistema de controle dos portos administrados pela empresa, o SCAP (Sistema de Controle e Administração Portuária).
Eu (e mais quatro analistas) entrava em contato com os usuários finais, via como funcionava o fluxo de trabalho, propunha uma solução informatizada e enviava o projeto para os programadores.
Um dia um usuário do porto de Santarém, cidade à oeste do estado, me “ligou” pelo Skype para pedir uma melhoria no sistema de coletores.
Só para tornar claro como o sistema funcionava, vou dar uma breve explicação:
Um coletor é um aparelho portátil com uma tela de mais ou menos 5 centímetros, munido de leitor de código de barras, teclado e conexão WiFi.
Neste aparelho, que usa um chip Intel 486 com memória EPROM, instalávamos uma versão especial do DOS para sistemas embarcados e nele uma versão do Lynx, que é um browser em modo texto.
Quando um caminhão chegava na portaria do porto, ele devia trazer consigo uma AE, Autorização de Entrada, que era um papel impresso pelo exportador usando o sistema via web.
Neste documento havia, além das informações sobre a carga para conferência visual do GP (Guarda Portuário), um código de barras com o número (criptografado) da AE.
O GP então usava o coletor para “dar um tiro” no código de barras, isto é, ler o número e este número era enviado na forma de uma requisição SOAP-XML por um canal SSL por WiFi para uma antena no teto da portaria.
De lá, seguia por cabo LAN para os roteadores do porto e deles para a antena da Embratel.
Esta antena enviava para outra antena e de lá para o satélite.
Do satélite a informação seguia para a rede da Embratel em Belém até chegar aos nossos servidores.
O nosso servidor de webservices processava a requisição e via se a ordem era válida retornando uma resposta também em HTML que seria exibida na tela do coletor.
Quando os deuses da tecnologia ajudavam e não havia interferência no sinal ou tráfego excessivo na rede, todo o processo de ida e volta ocorria em menos de um segundo, dando a sensação de tempo real para o usuário.
Este mesmo equipamento era usado ao longo de todo o processo de exportação e importação, por uma série de outros papéis de usuário, como os fiéis de armazém e os controladores de embarque em um processo similar ao descrito.
Pois bem, voltemos a história.
Como eu conhecia a todos em Santarém e já havia estado lá várias vezes, um destes fiéis de armazém se sentiu à vontade para pedir uma melhoria no sistema.
Fez isso usando o programa de telefonia via web, eu anotei a solicitação dele no nosso sistema de gerenciamento de ocorrências por volta das 10 h da manhã e passei a pensar numa solução, que na verdade era bem simples.
O resultado foi uma alteração no diagrama de fluxo de atividades que modelava o processo e a modificação de duas classes no diagrama de classes.
Por volta das 12h30min, antes de sair para o almoço, entrei em contato com um dos programadores do sistema, que morava em São Paulo, também pelo Skype.
Expliquei o problema e passei as modificações.
Às 15h ele me disse pelo programa de mensagens instantâneas que a solução estava pronta e pediu que eu testasse.
Eu testei, vi que estava correto e passei pro sistema em produção.
Como era um sistema Web, o deployment era automático, por isso, antes mesmo de ter tempo de ligar para o cliente pelo Skype, ele me mandou uma mensagem pelo programa de mensagens instantâneas para agradecer a prontidão na resposta da solução.
Isto era mais ou menos 15h30min.
Veja bem que todo o processo se deu entre três pessoas em três cidades diferentes e que neste caso estavam em três fusos horários diferentes, porque São Paulo estava em horário de verão e, portanto, uma hora adiantada em relação a Belém, e Santarém é uma hora atrasada em relação ao horário da capital.
De certa forma, podemos comparando este cenário com o proposto anteriormente, o cliente em Santarém era o cliente final, eu era o analista da ASP (neste caso o departamento de informática da CDP, a SUPINF, funcionava do ponto de vista do cliente como uma ASP) e o programador free lancer em São Paulo responsável pela implementação representava o papel do terceirizado na Índia.
A única diferença é que tive que passar as modificações como imagens anexadas em um email e não em uma sessão de software compartilhado.
Outros cenários em que a tecnologia de VoIP nos ajudou bastante na CDP foi em reuniões com uma empresa paulista responsável por desenvolver nossos controles de acesso biométricos, ou seja, as catracas (ou torniquetes como se fala em SP) que controlavam por impressão digital o acesso de pessoas às áreas alfandegadas.
Embora neste caso, como a solução envolvia hardware além de software, o fluxo não fosse perfeito, porque as vezes tínhamos que enviar um equipamento pra São Paulo e esperar o retorno.
Ainda assim, a tecnologia de Videoconferência foi útil uma vez, pois tínhamos na equipe um colega que era formado em Engenharia Elétrica e, por isso, ficou responsável em lidar com a empresa fornecedora.
Uma vez usamos uma câmera digital doméstica como webcam para transmitir o vídeo do circuito impresso para o engenheiro em São Paulo e eles conversaram sobre o que poderia ser o problema apenas vendo as imagens e o colega passando para ele as referência de alguns componentes.
Na verdade, acabo de lembrar de um caso de uso que estudamos no MBA sobre a Burti Solutions que exemplifica bem o meu ponto de vista.
A Burti é uma empresa brasileira que trabalha com serviços de arte gráfica para as maiores agências publicitárias do Brasil (todas em São Paulo).
No início dos anos 1990, o processo dela era assim:
1. O cliente criava um arquivo usando seus softwares proprietários;
2. Este arquivo, que era imenso, era enviado na forma de vários disquetes por motoboy até a Burti;
3. Um funcionário da Burti tentava acessar o arquivo e, se nada desse errado, como um disquete corrompido, imprimia uma versão do arquivo no Offset.
4. O motoboy levava esta cópia até a agência publicitária;
5. O gerente da campanha examinava o resultado e, se aprovado, autorizada a impressão em larga escala.
Porém, quase nunca a aprovação vinha na primeira tentativa.
Normalmente ele iria querer alterar alguma coisa, seja porque não tinha gostado do resultado impresso ou porque tinha tido uma idéia de última hora.
Neste caso, todo o processo se repetia quantas vezes fossem necessárias.
Este processo tinha uma série de deficiências, mas as principais eram:
1. Como o tempo de cada iteração era alto, em geral horas, e como as campanhas tinham que estar disponível até um determinado deadline imposto pelas editoras às agências de publicidade, em geral o resultado final não era o que o gerente da campanha queria, simplesmente porque não havia tempo hábil;
2. O processo era extremamente caro. Cada impressão em Offset representava um custo muito alto tanto para a Burti quanto para a agência.
3. Havia uma grande gama de softwares diferentes usados pelos clientes e ficava difícil suportar todos os formatos de arquivos.
4. As vezes os motoboys sofriam acidentes o que complicava ainda mais todo o processo de logística.
Foi então que a empresa antecipou o conceito de ASP e teve uma idéia genial e absolutamente audaciosa, pioneira no mundo.
Ela queria que o gerente da campanha estivesse em contato direto online e em tempo real com o funcionário da Burti, que deixaria de ser um operador de máquina para virar um consultor de impressão.
Além disso, ela queria que seus clientes usassem um conjunto de ferramentas padronizados, para evitar o problema 3.
Para isso, ela pesquisou uma solução de hardware e software que pudesse colocar os dois em contato e quais ferramentas abrangeriam todo o processo de produção publicitário.
Ela chegou em uma solução que usava o Macintosh como plataforma e um conjunto de softwares da Adobe, como o Freehand e o Photoshop, além de um pacote pioneiro de WebMeeting.
Mas como convencer clientes diferentes a usar a plataforma que ela julgava ser ideal?
Para isso, ela mudou seu modelo de negócio.
Agora os clientes não pagariam mais por cada impressão individual, mas pagariam uma assinatura para serem clientes dos serviços de impressão da empresa.
Ao assinar o serviço, eles recebiam inteiramente grátis todos os meios necessários para acessar a TransBurti, o Mac, o conjunto de software, o Modem, etc.
Tudo isso era instalado na empresa pela própria Burti, que também dava treinamento em como usar as ferramentas.
Esta mudança no modelo de negócio se baseia no conceito de marketing chamado “Prover os furos e não as brocas”.
Este conceito surgiu com uma empresa americana que fabricava brocas.
Ela percebeu que o serviço de atendimento ao cliente recebia muitas queixas de clientes que tinham comprado as brocas erradas para o serviço e por isso não tinham conseguido atingir o objetivo desejado e culpavam a empresa por isso.
Eles perceberam então que o que o cliente queria eram os furos e não as brocas e se tornou uma “provedora de furos”, ou seja, ela tinha uma equipe altamente treinada de profissionais que sabiam exatamente quais brocas usar e como fazer os furos e os clientes contratavam o serviço destes profissionais em vez de comprar as brocas.
Além disso, como ela faria para conectar os participantes?
Estamos falando de 1993, nesta época ainda não havia nem internet discada no Brasil.
Para resolver este problema ela comprou uma antena de dados WiFi e a instalou no alto de um prédio em São Paulo, tornando-se a TransBurti a primeira rede WiFi Wan em uso comercial no mundo.
Esta solução que ainda hoje, mais de 10 anos depois é de tirar o fôlego, resolveu as principais demandas tanto das agências quanto da própria Burti.
Agora o fluxo de trabalho era:
1. O gerente entrava online com o consultor da Burti e mostrava o projeto original. O consultor, altamente especializado no que fazia, conhecia as principais armadilhas da impressão offset e propunha mudanças para que o resultado impresso fosse realmente o que o gerente queria.
2. Se o gerente aceitasse as modificações, o próprio consultor as fazia online, em frente ao gerente.
3. Somente quando eles entravam em acordo sobre o resultado final a impressão era feita e era enviada diretamente às editoras que iriam publicar as campanhas.
Isto elimina as idas e vindas, os formatos de arquivo exdrúxulos, os custos proibitivos, as impressões mal feitas, etc.
Com isso a Burti se tornou praticamente um monopólio e depois, com a ampliação da rede para Buenos Aires e Ciudad del Mexico, ela se tornou a líder em toda a América Latina.
Bom, acabei escrevendo bem mais do que o planejado.
Mas o ponto é que o fluxo de trabalho nas empresas vai mudar de forma brutal nos próximos anos e eu queria sugerir que você escrevesse matérias no seu blog sobre as tecnologias que permitirão estas mudanças e quais as soluções open-source disponíveis para isso.