Sistema de informação em saúde pública

Fonte: Wikiversidade

Sinasc. O Sistema de Informações sobre Nascidos Vivos (SINASC) foi implantado oficialmente a partir de 1990, com o objetivo de coletar dados sobre os nascimentos ocorridos em todo o território nacional e fornecer informações sobre natalidade para todos os níveis do Sistema de Saúde. Um SIS é um conjunto de componentes que atuam de forma integrada, através de mecanismos de coleta, processamento, análise e transmissão da informação necessária e oportuna para implementar processos de decisões no Sistema de Saúde.

Introdução e Justificativa[editar | editar código-fonte]

Smart Cities [editar | editar código-fonte]

Cidades Inteligentes se baseiam em um uso intenso de tecnologia para uma melhor gestão dos recursos e qualidade de vida, com foco no hábito de recolher, analisar e trabalhar dados obtidos pela diversidade do cotidiano cosmopolita com o foco em sustentabilidade.

É possível encontrar cidades  em construção que já são classificadas como Smart Cities. Como por exemplo, Songdo na Coréia do Sul. Songdo está prevista a ser concluída em 2021 e se origina de um governo -  Lee Myung-bak - que acreditava na sustentabilidade e na baixa emissão de carbono como uma estratégia econômica. Dessa forma, a cidade terá prédios espaçados, grandes parques e ciclovias. Além disso, tecnologias práticas, como lixeiras que sugam os detritos direto para a área de tratamento adequada, tubulações que diferenciam água potável de água não potável e telões em ambientes públicos e privados com dados importantes, o que leva ao uso inteligente de serviços como a saúde, já que é possível saber qual o hospital adequado naquele momento.[1][2]

Saúde Pública[editar | editar código-fonte]

Após coleta de dados de usuários do sistema público de saúde do Distrito Federal, e também conforme análise dos pontos de vista e o pitch traçado para o problema, a equipe ideou a proposta de um aplicativo que trabalhe com o feedback das pessoas que utilizam os hospitais da rede pública. Ao entrevistar algumas pessoas diretamente nos hospitais notamos que as opiniões, sugestões e feedbacks construtivos se perdiam em meio ao atendimento de má qualidade e a situação precária do sistema de saúde. A ouvidoria de saúde do Distrito Federal não informa o teor das denúncias e reclamações prestadas ao serviço público, e também exige validação presencial dos dados referentes pessoais referentes a consultas, exames e cirurgias [3]. Nesse viés o aplicativo trabalharia de forma transparente, com o intuito de dar voz às reclamações, feedbacks e sugestões referentes ao sistema de saúde pública do Distrito Federal.  

Como tornar Brasília uma cidade mais inteligente? [editar | editar código-fonte]

Tornar Brasília uma cidade mais inteligente não implica necessariamente na resolução de todos os problemas da cidade, mas sim em como a nossa população e a nossa gestão utiliza da tecnologia para lidar com esses problemas.

Até porque Brasília é um sistema complexo que abrange dentro de si vários outros sistemas multifacetados e esse tipo de sistemas possuem em comum a aparição de problemas complexos, ou seja, problemas que não possuem uma solução exata, mas sim aproximações.

Dentre os diversos problemas complexos que Brasília precisa resolver, nosso time escolheu trabalhar em um que é o responsável por um grande impacto negativo na cidade, que é a má gestão da saúde pública.

Através de entrevistas no modelo de Design Thinking aos pacientes dos hospitais públicos do DF percebemos que uma importante causa para esse problema é a falta de mecanismos para comunicação entre os pacientes e a administração do hospital, a qual causa um distanciamento entre esses dois grupos, fazendo com que haja uma falta de informação para os pacientes sobre o hospital e também uma falta de informação dos pacientes sobre os problemas do hospital para a administração ( os pacientes são a melhor fonte para diagnosticar os problemas dos hospitais públicos, já que eles que enfrentam essa realidade).[4]

Portanto uma forma de tornar Brasília uma cidade mais inteligente é através do desenvolvimento de um mecanismo que auxilie na comunicação dos pacientes com a administração dos hospitais públicos.  

Objetivos[editar | editar código-fonte]

Gerais[editar | editar código-fonte]

Tornar Brasília uma cidade mais inteligente;

Impactar de forma positiva a saúde pública em Brasília;

Resolver, em partes, o problema da ouvidoria ser longe e não passar confiança de resolução dos problemas dos pacientes. 

Específicos[editar | editar código-fonte]

Entender como não se sentir ouvido impacta na vida dos pacientes dos hospitais públicos;

Prototipar um aplicativo que possa ser utilizado pelo nosso público-alvo;

Verificar a viabilidade do projeto;

Tomar consciência da alimentação de dados do sistema proposto.

Hipóteses[editar | editar código-fonte]

A solução para o problema exposto é um site porque as pessoas estão acostumadas a usá-los;

O programa terá boa aceitação pois será rápido e eficiente na função a qual se presta;

Os usuários do hospital estarão dispostos a responder as questões para poder usar o WiFi gratuito do estabelecimento;

O programa chamará atenção do governo e da imprensa;

Funcionários do hospital, incluindo médicos e enfermeiros, não usarão o sinal de internet no seu turno de trabalho.

Riscos[editar | editar código-fonte]

  • O público-alvo não aderir ao projeto;
  • O protótipo não alcançar a simplicidade procurada;
  • A equipe não conseguir seguir o plano de ação;
  • A comunicação entre as partes não ser efetiva;
  • O aplicativo não atingir a visibilidade esperada;

Plano de Ação[editar | editar código-fonte]

Para realizar as entregas do protótipo, a equipe se organizou por meio de liderança descentralizada e metas individuais. Dividimos o plano de ação quanto à acompanhamento e discussão em: 

  • Reuniões presenciais semanais, com horário fixo na semana e duração de 1 hora, onde atualizamos a ferramenta de gestão de atividades Trello e criamos novo backlog do produto;
  • Reuniões não-presenciais semanais, com horário flexível no final de semana e duração de 1 a 3 horas, feitas através da ferramenta Discord. Assim, discutimos o andamento do projeto, dúvidas, sugestões e quaisquer outros pontos referentes à prototipagem. 

Quanto à obtenção de dados em: 

  • Uso dos registros das atas e das atividades postadas na Wikiversidade, na primeira fase de contato com o público alvo;
  • Pesquisação quali-quantitativa;
  • Pesquisa de campo, com grupos de 2 ou 3 pessoas, onde iremos validar o primeiro protótipo. 

Quanto à organização dos dados, em: 

  • Criação de ata para cada reunião, em maior extensão durante a idealização do produto, onde tivemos que reestruturá-lo diversas vezes;
  • Atualização semanal da ferramenta Drive, onde escrevermos colaborativamente e em tempo real antes de postar na Wikiversidade em definitivo.

O problema[editar | editar código-fonte]

Descrição do problema específico desse time[editar | editar código-fonte]

Os hospitais públicos possuem uma gama de deficiências e problemas estruturais, tanto na sua parte física quanto gestão. É visível nos jornais o descaso público, filas gigantescas, pacientes que esperam durantes horas - dias - meses - anos para serem atendidos ou realizarem suas cirurgias, a falta de informação e os médicos que trabalham em horários divergentes dos informados da sua jornada. Dentre tantos problemas relatados visíveis e parecendo não ter saída, os usuários do sistema público de saúde se queixam de suas reclamações não serem ouvidas. A ouvidoria, por mais que seja um portal acessível e que diz ser transparente, aparenta descaso com a população, os cidadãos não observam nenhum tipo de melhora. Mas ao mesmo tempo, esta pode não ter a vontade e poder necessários para trazer essa gama de insatisfações do público à tona e procurar maneiras de resolver. As informações se perdem na fala, mas não são concretizadas em um lugar que qualquer um possa acessar e validar suas dores. Há a necessidade de concretizar essas reclamações e estas serem ouvidas. 

Descrição dos pontos de vista dos usuários[editar | editar código-fonte]

O ponto de vista é provavelmente uma das partes mais desafiadoras do projeto. Nele existe a necessidade de delimitar o problema e decidir o caminho que o projeto deverá  prosseguir a partir dos depoimentos coletados nas entrevistas realizadas nos hospitais.

Anteriormente à decisão de qual problema atacar, realizamos entrevistas, as quais alguns relatos e o modelo podem ser encontrados no apêndice A. Essas entrevistas foram feitas de maneira informal para encontrar informações mais verídicas do escopo e tentar nos aproximar deles, evitando a todo custo parecer que queremos apenas dados para gráficos, mas que queremos entender o que acontece para encontrar uma solução prototipável. O ponto de vista deixa claro quem serão os usuários, quais são suas necessidades e gera insights a partir das observações realizadas. Estes podem ser encontrados logo abaixo: 

Funcionários[editar | editar código-fonte]

Precisam de: motivação.

Porque: o atendimento desmotivado e não especializado leva a atraso nos processos e desgaste nas relações cliente/colaborador, o que piora a experiência de ambos.

Pessoas que realizam exames[editar | editar código-fonte]

Precisam de: horários que sejam cumpridos e local de fácil acesso para reclamar

Porque: esperam muito tempo mesmo com o atendimento marcado e a ouvidoria é longe.

Público geral[editar | editar código-fonte]

Precisam de: informações sobre o tempo médio de espera de um hospital.

Porque: têm muitos compromissos e acabam perdendo tempo em uma espera tão grande.

Sociedade[editar | editar código-fonte]

Precisa de: uma maneira efetiva de cobrar os administradores dos recursos públicos da saúde.

Porque: com a cobrança, fruto da consciência da realidade, a saúde tende a melhorar pelo receio do político ou secretário de perder seus votos e cargos.

Os pacientes dos hospitais públicos[editar | editar código-fonte]

Precisam de: uma forma de mobilizar as pessoas para lutarem pela saúde.

Porque: com a conscientização da população podem se abrir os olhos do governo para investir na saúde.

Relatórios e outros dados secundários de suporte[editar | editar código-fonte]

Os dados relatados pelos usuários do sistema público de saúde do Distrito Federal condizem totalmente com a realidade, podendo ser validados pelo Relatório de Fiscalização de Hospitais, documento produzido pelo Ministério Público do Distrito Federal e Territórios (MPDFT). O estudo realizado entre março e outubro de 2016 em alguns hospitais de Brasília incluindo o HRT e o HRAN , aponta falhas graves nos hospitais da rede pública: má distribuição dos profissionais, tecnologias obsoletas, falta de manutenção dos equipamentos entre outros problemas que expõe pacientes e servidores a riscos extremos.[5]

A equipe achou suficiente para a definição e entendimento do problema que fossem realizadas as primeiras entrevistas. Estas foram realizadas nos hospitais HRAN (Hospital Regional da Asa Norte)  e de HRT ( Hospital Regional de Taguatinga), tomando como base a metodologia de entrevista do Design Thinking, onde o objetivo principal é estimular o diálogo sobre assuntos relevantes seguindo um protocolo pré determinado que pode ser flexibilizado em função da conversa. [FONTE] O usuário é encorajado a relatar suas experiências de forma espontânea para que o entrevistador  possa  gerar insights através da linguagem verbal e não verbal relatada, e assim compreender melhor o que foi dito. Recolhemos no total 14 depoimentos, totalizando 10 horas de entrevistas com o público alvo.

O cenário observado pela equipe foi de precariedade, e os relatos recorriam sobre os seguintes aspectos:

  • Pessoas sem informação sobre o quadro de médicos;
  • Pessoas que esperavam mais de 5 horas para ser atendidas;
  • Crianças que não foram atendidas, exceto se seu caso fosse gravíssimo (casos próximos à morte);
  • Pessoas com glaucoma esperando as consultas depois das que tem horário agendado;
  • Grávidas realocadas de hospital próximo ao trabalho de parto;

Descrição do protótipo 1[editar | editar código-fonte]

O protótipo é um aplicativo que terá como inputs a avaliação dos usuários dos hospitais públicos e como outputs um conjunto de informações transparentes em forma de relatórios e comentários. 

Nome do aplicativo: FalaSUS

Funções[editar | editar código-fonte]

  1. Avaliação das especialidades de cada hospital cadastrado;
  2. Espaço de texto livre para comentários gerais acerca do hospital, com filtros de palavras ofensivas e de baixo calão.

Aparência[editar | editar código-fonte]

O design site foi desenvolvido para ser acessível. Por isso o fundo branco com letras pretas, letras e símbolos muito grandes e frases curtas. O objetivo do site é que ele funcione também com leitores de tela, então todas as imagens terão legendas adaptadas a esses leitores, para que deficientes visuais e pessoas com dificuldade na leitura possam acompanhar o processo.

Tela 1: Para evitar que pessoas mal intencionadas, essa página pede um tipo de identificação do usuário. Fica a critério do usuário escolher entre email e número de telefone.
Tela 2: Funciona como uma central de informações. Essa tela possibilitará o usuário escolher entre um pequeno tutorial sobre o site e seu objetivo, fazer a avaliação do hospital e ver avaliações já feitas.
Tela 3: Essa é a tela que aparece para o usuário se ele decidir ver avaliações anteriores ou fazer a sua própria e mostra os nomes dos hospitais públicos do DF através de lista suspensa
Tela 4: O usuário decide então qual especialidade do hospital deseja avaliar/consultar com um sistema de pesquisa similar ao de pesquisa por hospital.
Tela 5: Seguiremos agora pelas telas do usuário que decidiu por avaliar o hospital. Para saber a avaliação do hospital ao longo dos anos é feita a pequisa sobre a última vez no hospital. A avaliação será feita com base nessa visita passada.
Tela 6: Primeiras perguntas da avaliação. Quanto mais feliz o desenho selecionado, mais o usuário está satisfeito com aquele aspecto do hospital. As perguntas foram desenvolvidas com base nas reclamações mais frequentes nas pesquisas de campo.
Tela 7: Segundo grupo de perguntas seguindo o modelo da página anterior.
Tela 8: Última pergunta que funciona com um sistema de sim ou não e fornece um dado importante de satisfação para os administradores.
Tela 9: Aqui o usuário poderá abordar temas que não foram explicitados nas perguntas objetivas. O campo de comentário terá um filtro para palavrões e nomes de servidores.
Tela 10: O usuário que optar por ver as avaliações irá direto para essa página depois de escolher a especialidade (tela 4). Mas o usuários que fizeram a avaliação também será direcionado para ela depois da tela9. Essa página destaca o comentário com o qual mais usuários concordaram e abre a possibilidade para ver os outros.
Tela 11: O sistema converte então as "carinhas" para estrelas em cada pergunta, oferecendo uma média. Observação: pode haver estrelas fracionadas.
Tela 12: Segunda parte de perguntas avaliadas
Tela 13: Tela de despedida do usuário e liberação da internet proveniente do Wifi.

Validação do protótipo 1[editar | editar código-fonte]

A primeira validação feita fora realizada através da entrevista oral com nosso público alvo utilizando o nosso protótipo de telas anexados acima.

Todos os entrevistados se interessaram pelo site, principalmente por verem alguma medida sendo pensada para resolver os seus problemas que por muito tempo foram negligenciados e não valorizados pelo governo e pelas pessoas que não dependem de tal serviço. Porém surgiram alguns feedbacks e alguns insights para que nosso site fosse mais efetivo e conseguisse realmente resolver parte dos problemas da saúde pública do DF.

Um dos principais feedbacks recebidos fora: " Ok, através desse site deixaremos transparente nossa opinião, mas como isso voltará para nós em melhorias?". Vimos que precisamos estruturar melhor a forma de lidar com as informações colhidas para que a administração pública pudesse criar plano de ações para atender as reclamações dos pacientes.

Um insight para que as informações levantadas fossem mais relevantes fora: " como o site estará interagindo pessoas, através dele poderiam ser divulgadas manifestações, passeatas, etc" , porém tal insight não será aplicada no protótipo 2 na primeira atualização do sistema, pois queremos lançar o site com a mínima proposta viável possível

Elaboração do protótipo 2[editar | editar código-fonte]

Após a validação do protótipo 1, vimos que nosso site precisava se estruturar de forma mais precisa para que os dados colhidos por esse chegassem de forma mais simples e clara para a administração da saúde pública e essa pudesse criar planos de ação mais assertivos para resolver os problemas diagnosticados pelos pacientes.

Para isso usamos duas metodologias: a metodologia 5w2h e o Service Design.

5W2H[editar | editar código-fonte]

Essa metodologia prega que através de sete perguntas conseguimos definir melhor como seria o funcionamento de nosso próximo protótipo.

What - Será feito um site de extração de feedbacks dos pacientes sobre os hospitais públicos para que haja um diagnóstico melhor fundamentado sobre os problemas da saúde pública no DF.

Why - Isso será feito para que os pacientes se sintam ouvidos e que ganhem mais poder para atuar efetivamente em soluções para o serviço público.

Where - Tal site estará presente nos hospitais públicos ao serem anexados ao acesso ao wifi desses e presente em uma hospedeiro para que o site possa ser acessado através de seu URL em qualquer localidade geográfica.

When - Será feito durante a disciplina de Projetos de Sistema de Produção 2 e aplicado o mais rápido possível à rede pública de hospitais do Distrito Federal.

Who - O site será criado por nosso time, um desenvolvedor, um web designer e com parcerias com a secretaria da saúde, o Governo do Distrito Federal e com imprensa.

How - A extração de feedbacks será feita através de perguntas, agora reduzimos de 5 tópicos para 2 tópicos mais importantes (atraso no atendimento e disponibilidade de medicamentos) para a otimização da informação gerada tornando essa mais simples e clara para que a administração possa ser mais efetiva na resolução dos problemas encontrados.

Para que esses feedbacks recebidos voltem como soluções para a população serão utilizadas nossas parcerias para que a imprensa divulgue as informações coletadas com o intuito de gerar pressão pública e que a secretaria da saúde e o GDF tenham relatórios e gráficos suficientes para executarem medidas administrativas assertivas para a resolução dos problemas levantados.

How much - Para montar toda estrutura necessária para a criação e implementação de nosso site precisamos de modens, fios, roteadores, repetidores, servidor, dados em nuvem, permissão pública e de hospedagem do site.

Service Design[editar | editar código-fonte]

É a representação visual dos principais movimentos de um serviço que se repete, que envolve muitos atores e possui um cliente.[6] É uma forma de perceber a jornada do cliente e o que fazer no projeto para que esse tenha a melhor experiência possível.

No nosso caso consideramos como clientes os três que teriam benefício com o projeto: pacientes dos hospitais, veículos de mídia e administração pública.

Validação do protótipo 2[editar | editar código-fonte]

Para recolher feedback com relação ao segundo protótipo, fomos ao HRT (Hospital Regional de Taguatinga) e HRAN (Hospital Regional da Asa Norte).

HRT - 18 entrevistados, divididos em 2 grupos de idade

  • 5 pessoas com mais de 30 anos sem celular no hospital no dia em que foram abordadas
  • 7 pessoas com mais de 30 anos com celular no hospital no dia em que foram abordadas
  • 6 pessoas com menos de 30 anos com celular no hospital no dia em que foram abordados

Entre os grupos:

  • 4 pessoas afirmaram que não tem um celular com acesso a internet, logo, eles não seriam nosso público alvo;
  • 5 pessoas possuem celular, porém não gostam de usar, afirmando usar apenas quando estritamente necessário;
  • 1 pessoa atentou para o fato que andar com celular grande na mão é uma situação de risco em regiões periféricas;
  • 1 pessoa atentou para o fato que médicos, enfermeiros e demais servidores do hospital mexem em celular no horário de trabalho, deixando o paciente como segunda prioridade. Esse inclusive disse que viu uma pessoa morrer porque o médico que estava próximo disse que não era área dele e continuou a mexer no celular;
  • 1 pessoa já usou a ouvidoria do hospital e , apesar de ter obtido resposta, não achou que sua reclamação teve algum efeito no funcionamento do hospital - ele se referia ao HUB (Hospital Universitário de Brasília);
  • 5 pessoas estavam mexendo em um celular com acesso a internet no momento que foram abordadas e mostraram muito interesse no acesso ao WiFi. Todas elas eram jovens com aproximadamente menos de 30 anos;
  • 3 pessoas adoraram o banco de dados e acham que as informações de feedback ao hospital deveriam ser mais transparentes e melhor organizadas;
  • 4 acreditam que o contato com a mídia e com o governo pode fazer com que as reclamações voltem como melhorias;
  • 3 pessoas acreditaram que todas as perguntas do protótipo eram relevantes e deveriam ser mantidas;

HRAN - 20 pessoas, divididas em 3 grupos de idade:

  • 4 pessoas com menos de 30 anos;
  • 10 pessoas com mais de 30 anos e menos de 50;
  • 6 pessoas com mais de 50 anos.

Todas as pessoas entrevistadas estavam com seus aparelhos telefônicos com acesso à internet.

Desses grupos, obtivemos que:

  • 16 nos 3 grupos disseram que usariam o aplicativo e esperam ver mudanças reais apenas a longo prazo, mas sem perder as esperança;
  • 1 no grupo abaixo de 30 comentou a necessidade de existir um sistema que alimentasse monetariamente a ideia;
  • 1 no grupo abaixo de 30 sugeriu a restrição do uso do wifi, evitando perder o foco e responderem a pesquisa sem franqueza apenas para utilizar o wifi - ele mesmo o faria;
  • 3 no grupo entre 30 e 50 gostariam de ter a informação do que está acontecendo nos campos da saúde e educação de forma mais fácil e simples pelo site, as pessoas teriam obrigação de saber se fosse tão simples e num lugar só a informação;
  • 1 no grupo acima de 50 enfatizou que o funcionário público precisa ser valorizado e essa pesquisa também faria entender onde o funcionário precisa de motivação;
  • 2 no grupo acima de 50 acharam o site de fácil navegação;
  • 3 pessoas dos 3 grupos acreditam que o problema é uma figura política específica e só pode ser resolvido por esta ou pela próxima.

Considerações finais[editar | editar código-fonte]

Conclui-se que nosso público alvo são usuários jovens da rede pública. Porém, com o constante aumento da digitalização, a tendência é que no futuro a maioria das pessoas se encaixem nesse grupo de pessoas interessadas por acesso digital. Atualmente, porém, o aplicativo deixaria de fora parte dos pacientes, já que esses não são digitalizados.

Dentro do grupo interessados no Wi-Fi, percebe-se grande empatia com a ideia de acesso à Internet wireless no hospital, bem como com a ideia do site. As pessoas clamam por serem ouvidas e se sentem ignoradas mesmo quando são respondidas pelas ouvidorias; a necessidade de expor a informação e não somente relatá-las ao próprio provedor do serviço de saúde é iminente quando se trata do setor público; nesse setor, como há desfiguração na relação vendedor-consumidor e a concorrência entre hospitais públicos não impõe pressão na qualidade de seus serviços, como no caso do setor privado, mostra-se fundamental a pressão nos governantes (e ocupantes de cargos de liderança no governo) por meio de redes sociais, mídias tradicionais e outros meios de acesso à informação.

Com um captador de percepções direto na fonte do problema, como o site proposto e prototipado nesse projeto, a compilação de informações de alta relevância se torna possível; e a exposição da situação dos hospitais torna-se não mais restrita a situações alarmantes para motivar presença de repórteres de televisão ou jornal nos locais; uma mídia tradicional, como as citadas poderão ter acesso a situações recorrentes que muitas vezes passariam despercebidas e jamais retornariam como feedback para o sistema melhorar.

Referências[editar | editar código-fonte]

  1. STRICKLAND, ELIZA  Cisco bets on South Korean smart city.  IEEE Spectrum, vol.: 48, páginas: 11-12, agosto de 2011. 
  2. California Institute for Smart Communities. (2001). Smart Communities Guide Book. Disponível em: http://www.smartcommunities.org/guidebook.html. 
  3. Governo do Distrito Federal. Ouvidoria do SESDF [Internet]. Secretária de Estado de Saúde do Distrito Federal. 2017. Disponível em: http://www.saude.df.gov.br/ouvidoria.html
  4. Equipe Pegcar. Cidades inteligentes: o que são e onde estão no Brasil? [Internet]. Lugar de publicação: Pegcar Blog. 11 de abril de 2016. Disponível em: https://pegcar.com/blog/cidades-inteligentes-no-brasil/
  5. AUGUSTO, Otávio. Com graves falhas, saúde pública sofre até com infestação de piolhos. Lugar de Publicação: Correio Braziliense. 06 de março de 2017. Disponível em: http://www.correiobraziliense.com.br/app/noticia/cidades/2017/03/06/interna_cidadesdf,578358/com-graves-falhas-saude-publica-sofre-ate-com-infestacao-de-piolhos.shtml.
  6. Bitner, M.J., A.L. Ostrom and F.N. Morgan (2008). Service blueprinting: A practical technique for service innovation. California Management Review, 50(3), 66-94.

Apêndice[editar | editar código-fonte]

Lições aprendidas[editar | editar código-fonte]

Um grupo formado por pessoas excepcionais pode não dar o resultado esperado se suas atividades não são delegadas ou não existe um foco claro dado por um deles;

Reuniões diárias são difíceis e semanais muito espaçadas, nosso ponto ótimo foi de 2 por semana.

Feedback deve ser feito a cada ciclo de atividades;

Atritos devem ser resolvidos o mais rápido possível a fim de evitar mágoas e falhas de comunicação futuras;

Entregas semanais nem sempre são fáceis de gerir, devemos aprender a balancear os projetos com as demais partes da vida.

Para que uma reunião tenha a eficácia procurada, as pessoas já devem vir com o seu ponto de vista a debater.