Adam — aplicação WEB para reuniões assíncronas por áudio
Este artigo tem como objetivo ilustrar a documentação do projeto final na unidade curricular Projeto de Análise e Desenvolvimento no Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas Faculdade Senac Porto Alegre.
Resumo do Projeto
O ano de 2020 foi marcado por uma pandemia que afetou a vida humana e as relações dentro dos âmbitos familiar, educacional e das empresas. Referente às relações de trabalho, uma prática comum é a realização de reuniões, e, historicamente, elas eram, em sua grande maioria, presenciais. No cenário imposto pelas restrições de circulação, as reuniões virtuais passaram de opcionais para quase obrigatórias, e as pessoas precisaram se adaptar à nova realidade imposta.
Uma das adaptações possíveis pode ser aplicada às daily meetings, ou reuniões diárias, comum em equipes da área de Tecnologia da Informação, formadas por técnicos e analista de sistemas, por exemplo. Os objetivos dessas reuniões, também chamadas Daily Scrum quando se utiliza a metodologia ágil Scrum (Sommerville, 2011, p.73) nos projetos, é de ser breve e situar todos os envolvidos no andamento do trabalho diário, sem uma preocupação em detalhar possíveis impedimentos, que podem ser vistos em momento posterior.
Evitando-se realizar essas reuniões remotas em tempo real por vídeo, já que geralmente há uma certa demorar em todos estarem presentes, fora outras questões técnicas de falhas de equipamentos, o presente projeto demonstra o desenvolvimento de uma solução por áudio denominada ADAM — Async Daily Audio Meetings. Trata-se de um sistema web de envio e gerenciamento de áudios que auxilia tanto o coordenador de equipes na gestão dos áudios quanto os demais membros envolvidos no envio e reprodução desses áudios, visando o aumento da produtividade da equipe.
Definição do Problema
O projeto desenvolvido parte do seguinte cenário: equipes de trabalho compostas por times de desenvolvimento de software e infraestrutura de TI (Tecnologia da Informação), que realizavam daily meetings de forma presencial e que passaram a realizar de forma remota devido ao distanciamento social imposto pela pandemia iniciada em 2020. Tendo isso em vista, o coordenador de equipes deseja ter controle sobre os áudios e a equipe precisa manter o foco no envio e escuta destes áudios.
O problema aqui exposto foi inspirado na primeira reunião da equipe de TI na empresa em que o autor deste artigo passou a fazer parte no início de 2021. A equipe, formada pelas áreas de desenvolvimento e infraestrutura, possui membros que iniciam seus trabalhos em horários diferentes. Este fato tornava quase impraticável a realização de uma reunião remota diária simultânea. Além disso, reuniões por áudio ou vídeo contam com atrasos iniciais, causados tanto por motivos técnicos quanto pessoais.
O coordenador da equipe começou essa reunião solicitando que o tempo de gravação dos áudios enviados para o grupo de WhatsApp da equipe não ultrapassassem 1 minuto (antes estava estabelecido que seria de no máximo 2 minutos). O coordenador mostrou interesse em ter melhor controle desses áudios, para saber se todos enviavam e escutavam, e se respeitavam o tempo estabelecido. Além disso, seria interessante saber a quais projetos (que possuem tarefas em cards do Trello) os áudios estavam relacionados.
Product Discovery
A partir do relato do coordenador foi realizada a parte de Product Discovery deste projeto visando um MVP, ou seja, um Produto Mínimo Viável de um sistema que atendesse a essas necessidades e fosse útil para os demais membros da equipe. Deveria ser algo que os convencesse a parar de utilizar o WhatsApp, apesar de sua praticidade, e começassem a utilizar o ADAM. O relatório resumido do Product Discovery encontra-se no repositório da documentação do projeto.
O questionário da Discovery foi disponibilizado aos colegas de trabalho e respondido por 7 deles. As perguntas iniciais tratavam dos modos de reuniões diárias das quais eles já participaram e do grau de satisfação em cada um. Os modos eram reuniões presenciais, por vídeo e por áudio. Para todos estes modos, o grau de satisfação dos respondentes foi, na maioria, de “satisfeito” a “muito satisfeito”.
Em se tratando do modo remoto por “áudio”, a “Pergunta 06: Você participa ou já participou de reuniões diárias Remotas por Áudio?” resultou em 100% de respostas “sim”, uma vez que eram os membros da equipe de trabalho da qual o autor deste artigo participa. O grau de satisfação com este modo é apresentado no gráfico seguinte. O grau de satisfação varia de (1) Muito Baixa a (5) Muito Alta.
Ainda como parte integrante do Product Discovery, foram apresentadas possíveis funcionalidades do sistema, e se perguntou o grau de importância de cada uma, tanto do ponto de vista do coordenador quando do membro da equipe.
Os gráficos das respostas ajudaram na escolha de quais funcionalidades seriam implementadas para o MVP. O primeiro grupo de funcionalidades corresponde àquelas utilizadas por um coordenador, e o grau de importância/utilidade considerado variou de (1) Pouco Importante a (5) Muito Importante. Aquelas consideradas mais importantes são apresentadas nos gráficos a seguir.
Funcionalidade 01: Relatório de utilização do sistema pela equipe
Funcionalidade 02: Relatório de tempo dos áudios
Funcionalidade 03: Transcrição do áudio
Funcionalidade 04: Reconhecimento automático de nomes dos membros da equipe
Funcionalidade 05: Associação de palavras-chave a projetos em andamento (integração com sistema gerenciador de projeto — Trello ou similar)
O segundo grupo de funcionalidades corresponde àquelas utilizadas pelos membros em geral, e o grau de importância/utilidade considerado variou de (1) Pouco Importante a (5) Muito Importante. Aquelas consideradas mais importantes são apresentadas nos gráficos a seguir.
Funcionalidade 06: Gravar/escutar os áudios
Funcionalidade 07: Digitar texto (problemas com o áudio, deficiência auditiva)
Funcionalidade 08: Lembrete de envio do áudio diário
Funcionalidade 09: Notificação ao receber áudio da equipe
Funcionalidade 10: Notificação diferenciada ao receber áudio em que você foi citado
Projetos correlatos
Além do WhatsApp, mencionado anteriormente, demais aplicações de conversas ou reuniões (Telegram, Meet, Zoom, etc) são potenciais projetos correlatos. Aplicações de conversa por mensagens de texto, vídeo e áudio possuem a característica assíncrona que é a principal do ADAM, porém não possuem as funcionalidades que agregam valor ao negócio. Por exemplo, o WhatsApp permite a digitação pela voz, mas não grava um arquivo de áudio e, ao mesmo tempo, o envia junto com a transcrição.
Outro projeto possivelmente correlato a ser citado é o Daily, uma API (Interface de Programação de Aplicações, na tradução em português), que permite a desenvolvedores utilizarem funcionalidades em seus sites ou criarem sistemas para áudio e vídeo em tempo real. Uma particularidade deste sistema é a possibilidade de se utilizar somente áudio, o que torna seu custo menor nos planos pagos. Entretanto, como visto, o foco do Daily são reuniões em tempo real, diferentemente do objetivo do ADAM.
O quadro abaixo mostra a comparação das funcionalidades do ADAM com os sistemas correlatos mencionados.
Objetivos
O objetivo geral do projeto ADAM é fornecer ao coordenador e membros de equipes de TI de empresas um sistema dedicado de reuniões assíncronas por áudio, pelo qual o coordenador poderá gerenciar sua equipe e os membros poderão manter o foco no envio e recebimento dos áudios.
Os objetivos específicos do projeto são os seguintes:
- Melhorar o gerenciamento da equipe pelo coordenador através do controle de participação e frequência dos membros;
- Disponibilizar um sistema especializado para a empresa;
- Manter usuários (coordenador e membros) focados durante envio e reprodução dos áudios;
- Retomar a atenção do usuário ao ser notificado sobre o recebimento de novos áudios da equipe;
- Aumentar a atenção do usuário na escuta do áudio ao saber que possivelmente seu nome foi mencionado.
Stack Tecnológico
As metodologias e o stack tecnológico de desenvolvimento utilizados neste projeto são apresentados no esquema da figura abaixo. Cada um de seus itens e subitens são brevemente explicados e suas escolhas justificadas na sequência.
Metodologia Ágil
- SCRUM: utilizado o conceito de sprints, ou seja, ciclos de desenvolvimento de 2 semanas e entrega de software com valor ao cliente, para sua apreciação e apontamento de melhorias a serem desenvolvidas na próxima sprint. Uso de backlog com a identificação e priorização das funcionalidades (Sommerville, 2011, p.73).
Modelos e Arquiteturas
- Aplicação Web: o projeto foi pensado inicialmente para ser utilizado na web, no mesmo ambiente de trabalho de outras aplicações que os membros das equipes de TI utilizam diariamente. Sendo assim, se fez o uso de Web APIs disponíveis diretamente nos navegadores, ou de forma indireta através de pacotes e módulos instalados no backend e no frontend (conforme explicado mais abaixo nas respectivas seções).
- SPA: do inglês, Single Page Application, ou seja, uma Aplicação de Página única, que simula uma aplicação nativa de desktop, em que não há carregamentos de páginas ao trocar de rotas/funcionalidades. O SPA é possibilitado pelo uso do framework Angular, explicado mais abaixo.
Projeto
- Versionamento com Git e GitHub: Git é um sistema de versionamento distribuído (gratuito e de código aberto) utilizado no desenvolvimento de software para manter o histórico de alterações de código dos sistemas e facilitar a colaboração de desenvolvedores no mesmo código. O GitHub é uma plataforma de hospedagem de código que utiliza o Git para o versionamento. Ele possibilita a colaboração de desenvolvedores em projetos privados ou públicos.
- Gerenciamento de tarefas com Notion: aplicação web que permite anotações, gerenciamento de projetos e de tarefas. Neste projeto foi empregado para controle de tarefas das sprints o fluxo de trabalho Kanban, uma estrutura bastante utilizada para implementar o desenvolvimento de software ágil, dividindo num quadro as tarefas em status ‘a fazer’, ‘fazendo’ e ‘finalizadas’.
Modelagem
- Prototipação de telas com Figma: um editor gráfico colaborativo de prototipagem de projetos. A tela principal do ADAM foi pensada e desenhada no Figma, e será apresentada na seção Descrição da Solução.
- As entidades do banco de dados não relacional foram definidas diretamente em seu modelo físico (código) através da biblioteca Mongoose (explicada mais abaixo) na API backend. Para a manipulação no frontend dessas mesmas entidades através de objetos, foram definidas interfaces com o framework Angular.
Stack MEAN
A stack principal de desenvolvimento é conhecida pelo acrônimo MEAN, formada basicamente pelos sistemas MongoDB, Express, Angular e Node.js, que serão explicados nos correspondentes itens de Backend e Frontend.
Tanto para o backend como para o frontend a linguagem de programação principal é o JavaScript, uma linguagem interpretada e baseada em objetos com funções de primeira classe (em linhas gerais, as funções são tratadas como variáveis com o tipo function). Utilizou-se também para os dois ambientes o Visual Studio Code, um editor de código-fonte com suporte nativo para JavaScript, TypeScript e Node.js, e com funções de depuração, refatoração, formatação e auxílio na escrita de códigos através de snippets nativos ou de extensões.
Backend
- MongoDB: sistema de banco de dados não relacional (NoSQL) orientado a documentos em formato JSON. Em comparação aos bancos relacionais, os não relacionais possuem capacidade de escalabilidade de forma mais simples e econômica. Apesar de ser não relacional, é possível obter relacionamentos, como o muitos-para-muitos que foi utilizado neste projeto. Para a modelagem do banco foi utilizada a biblioteca Mongoose, que facilita operações de leitura e escrita no MongoDB. Para leitura e escrita de arquivos binários de áudio diretamente no MongoDB foi utilizada a especificação GridFS, que armazena arquivos em pedaços (chunks) e permite a reprodução no lado do usuário (frontend) por streaming, ou seja, sem a necessidade de o usuário obter todo o arquivo por meio de download e posterior reprodução.
- Express.js: framework utilizado no Node.js para construção de servidores com recursos mínimos. No projeto foi utilizado para a construção da API, permitindo o acesso do frontend ao backend da aplicação.
- Node.js: um ambiente de tempo de execução JavaScript orientado a eventos assíncronos, projetado para construir aplicações de rede escaláveis (ou seja, a demanda pode crescer sem afetar o desempenho). O Node.js pode ser estendido através de pacotes, como é o caso do Express.js e Mongoose, citados anteriormente. O gerenciamento dos pacotes é feito, por padrão, através do software npm. Outros pacotes utilizados especificamente para a parte de manipulação de arquivos binários de áudios no projeto foram os seguintes: formidable, um módulo responsável por fazer a análise (parse) de dados de formulários passados por requisições sobre o protocolo HTTP, principalmente para uploads de arquivos; e gridfs-stream, para leitura e gravação de arquivos em formato GridFS no banco MongoDB.
Frontend
- Angular: framework para a construção de sistemas web baseado em TypeScript. O TypeScript é uma linguagem construída em cima do JavaScript com adição de tipagem de variáveis, ou seja, possibilita ao JavaScript a definição de tipos. Juntamente com essa linguagem, o CSS e o HTML são usados no Angular para a construção dos componentes da página web do sistema.
- Web APIs: são interfaces de programação de aplicações (API) disponíveis para o desenvolvimento das aplicações para a Web ou sites. Os navegadores, por onde os usuários utilizam a aplicação ou site, têm acesso a métodos e interfaces (tipos de objetos) definidos nessas APIs. O link de referência das Web APIS citado acima, pertencente à MDN Web Docs, contém uma lista com a documentação de APIs e interfaces já com uso consagrado ou ainda as experimentais. Três dessas APIs formam os pilares para a realização do projeto ADAM, são elas:
- MediaStream Recording API: também referida como Media Recording API ou MediaRecorder API, é fortemente relacionada com a Media Capture and Streams API e a WebRTC API (Web Real-Time Communication), citadas aqui para conhecimento do leitor das diferentes APIs relacionadas à gravação, reprodução e streaming de mídias. Neste projeto, a MediaStream Recording API foi utilizada para a gravação do áudio do usuário através do uso da interface MediaRecorder, que capta os dados stream da interface MediaStream e torna disponível para processamento. Os dados são capturados como objetos Blob, ou seja, um objeto binário grande para arquivos tipo áudio, vídeo e imagem. O objeto Blob, após o fim da captação, é disponibilizado no navegador do usuário no elemento <audio>, cujo acesso é dado pela interface HTMLAudioElement.
- Web Speech API (Experimental): permite incluir dados de voz nas aplicações Web. Possui uma parte de síntese de fala (reprodução artificial da fala humana) e uma parte de reconhecimento de voz (Speech Recognition). A parte de reconhecimento de voz foi utilizada neste projeto para a solução de transcrição dos áudios. A interface utilizada é a SpeechRecognition, que possui funcionamento na parte de gravação do áudio similar ao que ocorre na MediaStream Recording. Esse áudio captado (stream) é então enviado para um servidor (do Google, por exemplo), depois é processado e o resultado é retornado para o navegador do usuário. Sendo assim, o uso neste projeto só é possível quando conectado à internet. O navegador utilizado no desenvolvimento do ADAM foi, em grande parte, o Chrome (versão 91) por ele disponibilizar compatibilidade com o Web Speech API de forma nativa. Testes em meados de 2021 mostraram que o Edge (versão 91, baseado no projeto Chromium) também possui suporte. Os resultados da transcrição são diferentes no Chrome e no Edge, o que sugere que a API de reconhecimento utilizada no servidor em cada navegador são diferentes. Com o Firefox (versão 89) não foi possível utilizar o reconhecimento de voz, mesmo habilitando uma opção específica para isso. Por se tratar do desenvolvimento de um MVP, foi utilizada a opção mais simples para o reconhecimento de voz, que é a disponibilizada de forma nativa nos navegadores mencionados. Existem outras APIs de reconhecimento de voz, tanto open-source como prioritárias. Alguns exemplos são o CMUSphinx, IBM Watson e Speech API do Bing.
- WebSocket API (WebSockets): tecnologia que permite uma sessão de comunicação interativa bidirecional entre um cliente (navegador do usuário) e um servidor. Mensagens orientadas a eventos (que captam mudanças de estado) podem ser entregues e recebidas de servidores sem a necessidade de se fazer requisições ao servidor e esperar uma resposta. O emprego de WebSockets neste projeto se dá pelo uso biblioteca Socket.io, instalada tanto no backend (Node.js) quanto no frontend. Como é mencionado na documentação desta biblioteca, o Socket.io não é uma implementação do WebSocket pura, embora utilize WebSocket como transporte quando possível. Uma das vantagens disso é que Socket.io seria mais confiável, pois utiliza a forma long-pooling (mantém aberta a conexão entre cliente e servidor) quando uma conexão WebSocket não puder ser estabelecida.
Validação
- Questionário: para os mesmos respondentes do questionário do Product Discovery, buscando verificar o atendimento aos objetivos geral e específicos do projeto.
Implantação
- Heroku: uma plataforma como serviço (PaaS), ou seja, um ecossistema para implantação (deploy) e hospedagem do backend e do frontend da aplicação. O sistema foi implantado nesta plataforma, porém não ficou operacional nesta versão de MVP.
Descrição da Solução
Visão Geral da Solução
A solução encontrada para desenvolver o projeto proposto é apresentada de forma esquemática na figura acima. De forma resumida, um usuário grava e envia seu áudio ou texto como forma de participação da daily meeting, reproduz áudios ou lê as mensagens de texto dos outros membros da equipe, e é notificado sobre o recebimento de áudios e se seu nome é mencionado em algum.
Funcionalidades desenvolvidas
A seção ‘Arquitetura’ mostra artefatos utilizados para se chegar na definição das funcionalidades do MVP. Inicialmente as funcionalidades elegidas foram (em negrito as que foram contempladas ao final da realização do MVP):
- Grava áudio
- Reproduz áudio
- Transcrição do áudio
- Reconhece palavras-chave
- Dashboard para gestão dos áudios
- Notifica recebimento de áudio
- Integra com sistema de gestão de projeto
- Lembra envio de áudio
O MVP contemplou a funcionalidade de reconhecimento de palavras-chave juntamente com a de notificação de recebimento de áudio em que a pessoa é citada. O MVP não contemplou as funcionalidades de integração com sistema de gestão de projeto e lembrete de envio de áudio.
Entidades principais
Foram definidas as seguintes entidades principais para o funcionamento do ADAM:
- Áudios (Audio)
- Equipes/Times (Team)
- Usuários (User)
As entidades e atributos estão definidos utilizando o idioma Inglês e trechos dos códigos são apresentados na seção ‘Arquitetura, Modelagem das entidades principais’.
Os usuários são especializados conforme o atributo ‘Perfil de usuário’ (role), podendo ser dividido em:
- Administrador
- Coordenador
- Membro
Cadastro
Na etapa de cadastro somente é permitido ao usuário escolher entre Coordenador e Membro. Um coordenador é também um membro, visto que também pode participar das reuniões.
Os usuários podem se cadastrar em equipes. O identificador (campo id) dessas equipes cadastradas é persistido no campo teams, que é um vetor de ids.
As equipes podem ter muitos membros inscritos, e isso é feito em um vetor com os ids de usuários (com perfil membro ou coordenador). Cada equipe tem um coordenador responsável, que é automaticamente cadastrado como membro no momento em que ele cria sua equipe.
Início da Daily Meeting
O ciclo de funcionamento principal do ADAM, que são as reuniões diárias remotas assíncronas, se inicia quando um membro de uma equipe (usuário) acessa o sistema para gravar e reproduzir áudios. Para membros que não são coordenadores, a primeira tela após o login é a da Daily Meeting, onde é possível observar a data (sem possibilidade de escolha).
Caso o membro já esteja cadastrado em uma equipe, os áudios ou textos dos outros membros já aparecem na lateral esquerda. Caso esteja cadastrado em mais de uma, é possível selecionar uma conforme a figura abaixo.
Levando em conta pessoas com problemas auditivos ou até questões técnicas, como indisponibilidade ou falhas nas entradas e saídas de áudio nos equipamentos, também foi implementada a possibilidade de digitar mensagens de texto. Além disso, é apresentada a transcrição do áudio caso esta funcionalidade da Web Speech API esteja disponível no navegador utilizado (conforme explicado na seção ‘Stack Tecnológico’). A figura abaixo contém a caixa de texto onde o membro pode editar uma transcrição para eventuais correções ou digitar e enviar somente um texto caso seja necessário.
A parte principal da tela contém o gravador e o player do áudio. Alterando a opção no canto superior direito da página, é possível alternar entre somente o envio de mensagem de texto e o envio de áudio com a transcrição. Ao selecionar o envio de áudio, o botão de gravação é ativado e o temporizador exibido.
Gravação e Reprodução dos Áudios
A gravação e reprodução do áudio (ou escrita e leitura do texto) é feita no frontend utilizando a MediaStream Recording API. A comunicação frontend-backend é feita através de protocolos HTTP e WebSockets. O protocolo HTTP realiza, basicamente, as ações GET para leitura de dados de usuários e áudios e POST para gravação dos dados.
No backend, o áudio gravado é recebido como um tipo multipart/form-data, próprio para o upload de arquivos. No momento do recebimento do arquivo junto com os dados, realizam-se duas etapas. Primeiro é feita a persistência do áudio em duas coleções do MongoDB específica para gravação: fs.files e fs.chunks. Na fs.files é gravada a referência do arquivo, e na fs.chunks são gravados os pedaços (chunks) do arquivo. Depois o id deste áudio é gravado na coleção Audio, que contém também campos como os ids de usuário e time.
Notificações
O protocolo WebSockets é utilizado, neste projeto, para comunicar o servidor que um áudio foi gravado e enviado, e, funcionando de forma análoga à uma sala de bate-papo virtual, avisar todos os membros da equipe (mensagem broadcast) que estão conectados ao mesmo tempo em uma sala (room) definida pela biblioteca Socket.io.
O ciclo de funcionamento do ADAM continua com a notificação de recebimento de um novo áudio/texto na equipe. Atualmente as notificações são feitas somente através de avisos visuais temporários. O membro pode reproduzir o áudio ou ler a mensagem de texto. Este item será marcado como ‘lido’, e um contador de mensagens mantém o usuário informado se ainda há mensagens não lidas.
O usuário que permanece conectado na aplicação pode, além de receber notificações de novas mensagens, ser notificado quando o seu nome é citado no áudio recebido. Isso é feito buscando-se por palavras-chave na transcrição ou mensagem escrita. As palavras-chaves utilizadas são o primeiro nome e o nome completo do usuário. Abaixo na figura são mostradas a notificação de recebimento e de citação em mensagem.
Além da notificação de citação, é mostrado no item do áudio correspondente um ícone representativo de que houve uma menção ao seu nome. Estes ícones podem ser observados na figura abaixo.
Dashboard do coordenador
O ciclo de funcionamento do ADAM pode durar o dia todo, dependendo das diferenças nos horários em que os membros iniciam seus trabalhos. O usuário com perfil de coordenador, quando exerce o papel de membro, também tem à disposição todas as funcionalidades acima descritas.
Como diferencial, os usuários coordenadores iniciam a aplicação em um dashboard (painel de controle) com o total de equipes que possui, total de membros e um gráfico com a distribuição de membros por equipe.
Ao selecionar uma equipe, são mostrados dois gráficos referentes à equipe selecionada. O primeiro mostra os áudios entregues e os faltantes do dia atual, conforme a quantidade de membros. O segundo mostra a frequência de envios diários por período. Como padrão o período apresentado compreende o início da criação da equipe até o dia atual.
Esta funcionalidade de dashboards foi primeiramente apresentada como geração de relatórios. Seguindo a sugestão de um respondente da Discovery, foram feitos relatórios em gráficos para o acompanhamento visual reunidos em um dashboard.
Arquitetura
Visão geral da Arquitetura do Sistema
A arquitetura do sistema está baseada nos protocolos, sistemas, bibliotecas e frameworks explicados na seção ‘Stack Tecnológico’ e apresentados no esquema da figura acima. As suas participações em algumas das funcionalidades foram explicadas e justificadas na seção ‘Descrição da Solução’.
Modelagem do Negócio
A partir do resultado do Product Discovery, iniciou-se a modelagem do negócio através da construção de artefatos que auxiliam na definição do MVP. Estes artefatos são explicados de forma detalhada no livro Lean Inception (Caroli, 2018). Os artefatos produzidos considerando a Lean Inception foram os seguintes:
- Visão do Produto: deve transmitir uma mensagem curta e clara para o cliente do que o sistema é e como se destaca em relação a outros similares (Caroli, 2018, p.127);
- É — Não é — Faz -Não faz: busca mostrar aspectos positivos e negativos quanto ao produto ser algo ou realizar funcionalidades (Caroli, 2018, p.129);
- Matriz Esforço X Valor de Negócio: adaptada neste artigo sem a parte de quantificação da experiência do usuário, busca definir a prioridade da funcionalidades iniciando aquelas que demandem menos esforço técnico e possibilitem maior valor para o negócio (Caroli, 2018, p.159).
- Canvas MVP: a etapa final da modelagem segundo a Lean Inception, onde o MVP e suas funcionalidades são detalhados (Caroli, 2018, p.223);
Abaixo são apresentados os artefatos produzidos, que também se encontram no repositório da documentação do projeto.
Visão do Produto
Foi elaborado o seguinte artefato:
PARA uma equipe de Tecnologia da Informação com pessoas que iniciam o trabalho em horários diferentes,
QUE realiza Daily Meetings remotas
O ADAM — Async Daily Audio Meetings
É UM sistema web de envio e gerenciamento de áudios
QUE auxilia o coordenador na gestão de áudios e assuntos e aumenta a produtividade da equipe.
AO CONTRÁRIO do WhatsApp e do Telegram,
O ADAM é dedicado para reuniões remotas por áudio para manter o foco da equipe.
Produto É — Não é — Faz -Não faz
Foi elaborado o seguinte artefato apresentando as características principais que definem o que o sistema é e o que não é, além do que ele faz e o que não faz. Conforme citado na seção ‘Descrição da Solução’, as funcionalidades de integração com sistema de gestão de projeto e lembrete de envio de áudio não foram contempladas.
Matriz Esforço X Valor de Negócio
A partir do canvas MVP, as funcionalidades foram distribuídas conforme o grau de esforço e o seu valor de negócio inicialmente pensados, resultando na matriz apresentada na figura seguinte.
Canvas MVP
Foi elaborado o seguinte quadro MVP, trazendo, entre outros elementos, as personas segmentadas, as jornadas e as funcionalidades definidas a partir do Product Discovery. Conforme citado na seção ‘Descrição da Solução’, as funcionalidades de integração com sistema de gestão de projeto e lembrete de envio de áudio não foram contempladas.
Protótipo da tela principal
De posse das funcionalidades principais na visão dos membros de equipes, foi pensada e desenhada a tela principal, apresentada na figura abaixo. A versão final é semelhante ao protótipo, mas optou-se por mudança nas cores utilizadas, e alguns formatos como o dos players de áudio foram adaptados conforme o que os navegadores já disponibilizavam como padrão. Para além do MVP poderá ser pensado em personalização desses players.
Modelagem das entidades principais
As entidades definidas para o funcionamento do ADAM são:
- Áudios (Audio)
- Equipes/Times (Team)
- Usuários (User)
As entidades e atributos estão definidos utilizando o idioma Inglês e trechos dos códigos são apresentados abaixo.
Repositórios do sistema
Os arquivos de código-fonte do sistema estão hospedados no GitHub e podem ser acessados através dos links abaixo:
Backend API: https://github.com/adam-audio-meetings/adam-api
Frontend: https://github.com/adam-audio-meetings/adam-web
Validação
Relembrando, o objetivo geral do projeto ADAM era o de proporcionar ao coordenador melhor gerência sobre sua equipe e aos membros manter o foco no envio e recebimento dos áudios, possibilitando também seu auto gerenciamento.
Estratégia
Os objetivos do projeto foram validados através de demonstração do sistema em vídeo e posterior preenchimento de questionário para os mesmos respondentes da Product Discovery, os possíveis usuários reais.
Consolidação dos Dados Coletados
O questionário de validação foi respondido por 4 participantes. O primeiro grupo de objetivos corresponde àqueles voltados para a empresa e o coordenador, e o grau de concordância considerado variou de (1) Discordo totalmente a (5) Concordo totalmente. As respostas a essas afirmações são apresentadas nos gráficos a seguir.
Objetivo 01: Melhorar o gerenciamento da equipe pelo coordenador através do controle de participação e frequência dos membros
Objetivo 02: Disponibilizar um sistema especializado para a empresa, ao invés do uso de ferramentas gerais como o WhatsApp
Objetivo 03: Sobre a funcionalidade ‘Gravar/escutar os áudios’, o sistema atende o objetivo de manter usuários (coordenador e membros) focados durante envio e reprodução dos áudios (sem distrações/interrupções)
O segundo grupo de objetivos corresponde àqueles voltados para os membros em geral, e o grau de concordância considerado variou de (1) Discordo totalmente a (5) Concordo totalmente. Todas as respostas a essas afirmações foram o grau máximo, e correspondem ao gráfico mais abaixo.
Objetivo 04: Sobre a funcionalidade ‘Gravar/escutar os áudios’, o sistema atende o objetivo de manter usuários (coordenador e membros) focados durante envio e reprodução dos áudios (sem distrações/interrupções)
Objetivo 05: Sobre a funcionalidade ‘Notificação ao receber áudio da equipe’, o sistema atende o objetivo de retomar a atenção do usuário ao ser notificado sobre o recebimento de novos áudios da equipe
Objetivo 06: Sobre a funcionalidade ‘Notificação diferenciada ao receber áudio em que você foi citado’, é atendido o objetivo de aumentar a atenção do usuário na escuta do áudio ao saber que possivelmente seu nome foi mencionado
Objetivo Geral: De forma geral, o sistema é diferente do que só utilizar o WhatsApp, pois tem funcionalidades específicas. Além disso, oferece uma ferramenta oficial e dedicada para a empresa/equipe e facilita ao coordenador acompanhar o andamento da equipe, assim como auxilia a equipe no seu autogerenciamento
Conclusões
A nova realidade imposta em 2020 pela pandemia fez com que as empresas procurassem soluções às reuniões presencias. Sistemas como Google Meet e Zoom foram largamente utilizados. Mais especificamente em relação às reuniões diárias bastante comuns em empresas com equipes de TI, devido à sua característica de ser rápida e objetiva, a solução mais simples e prática a se pensar é um sistema de troca de mensagens por áudio, como o WhatsApp.
Para além da simples utilização desses sistemas, buscou-se uma solução que, além do que entregam os sistemas correlatos analisados, houvesse agregação de valor tanto para a empresa quanto para o coordenador e os membros das equipes. O valor agregado pode ser traduzido em maior produtividade uma vez que se tem, a princípio, mais foco na realização da mesma tarefa, e maior controle no gerenciamento feito pelo coordenador. Para a empresa é possibilitada uma ferramenta padronizada e com fim específico, onde também é possível manter maior controle de sua utilização bem como ter um histórico em áudio e transcrito de cada jornada de trabalho.
Confrontando-se os dados coletados com os objetivos do projeto, verificou-se que o sistema atendeu plenamente os objetivos geral e específicos. Pelo menos para esse grupo reduzido de respondentes a utilização do ADAM pode substituir o uso de sistemas de troca de mensagens de propósito geral, uma vez que possui funcionalidades específicas consideradas úteis. Além disso, pode se tornar a ferramenta oficial e dedicada para uma empresa no que tange a comunicação rápida por áudio nesta versão remota das já consolidadas daily meetings.
Limitações do Projeto e Perspectivas Futuras
O projeto possui como limitação técnica neste MVP a utilização somente dentro de uma empresa (cliente), por meio de uma implantação local ou em nuvem dedicada. Isso porque não foram definidos namespaces na biblioteca Socket.io, o que permitiria mais de uma empresas pudesse coexistir sem que seus membros tivessem acesso a equipes de outras. Há essa possibilidade, mas não foi implementada.
O tráfego de dados pode em streaming não foi medido para saber a estimativa de custo para implantação do projeto. Em se percebendo uma utilidade comercial, esta análise deverá ser feita. Um ponto de partida poderia ser a tabela de preços da API daily citada neste trabalho.
Em se tratando das funcionalidades realizadas, a identificação do membro através tão somente de seu nome pode gerar notificações de menção para pessoas com o mesmo nome. Os colegas de trabalho conseguem depreender de quem se trata pelo contexto ou alguma outra identificação que acompanhe seu nome, mas para aumentar a acurácia do sistema, pode-se permitir que os usuários definam quais palavras-chave os identificam.
Além de palavras-chave para a identificação de usuários, poderia ser permitido ao coordenador incluir palavras-chaves relacionadas a projetos em andamento. Isso levaria à uma próxima recomendação de funcionalidade que foi pensada incialmente neste projeto mas não foi desenvolvida, que é a de integração de projetos em andamento com o sistemas de gerenciamento de tarefas.
Referências Bibliográficas
Caroli, Paulo. Lean Inception: como alinhar pessoas e construir o produto certo / Paulo Caroli.-1ª edição atualizada -São Paulo: Editora Caroli, 2018.
Sommerville, Ian. Software engineering / Ian Sommerville.-9th ed. Addison-Wesley, 2011.
As referências utilizando links correspondem a palavras ou trechos sublinhados neste documento digital.
