Manual de Operações
Baixar este modelo
Gerado em 2026-08-31 · Baixar todos os modelos
Processos Operacionais Essenciais
Which things have to keep happening every week — and are they written down anywhere?
Cláusulas RCOS 7.3.4, 7.7.2, 7.6.3
- 7.3.4 Processos operacionais críticos DEVEM ser documentados de tal forma que a continuidade não dependa de conhecimento tácito mantido por indivíduos específicos.
- 7.7.2 Processos operacionais críticos NÃO DEVEM depender exclusivamente da memória individual, da boa vontade ou da transmissão informal.
- 7.6.3 O Manual de Operações DEVE definir, no mínimo:
Por que documentar processos críticos?
Se um processo só existe na cabeça de uma pessoa, a comunidade depende dela aparecer — para sempre. Escrever os processos críticos, com pessoas responsáveis nomeadas, é o que transforma conhecimento privado em um ativo comunitário que sobrevive a transições, ausências e saídas.
Como preencher
Para cada processo crítico recorrente (acolhimento, saída, publicação de propostas, registro de contribuições, cadência de reuniões, gestão de tesouraria, revisão de acesso a plataformas), nomeie uma pessoa responsável e uma breve descrição.
| Processo | Quem | Detalhe |
|---|---|---|
| <Acolhimento de membros> | <papel> | <ver Protocolo de Acolhimento (Camada 1)> |
| <Saída de membros> | <papel> | <ver Protocolo de Saída e Separação (Camada 1)> |
| <Publicação de propostas> | <papel> | <ver Protocolo de Governança (Camada 2)> |
| <Registro de contribuições> | <papel> | <ver Protocolo de Economia Interna (Camada 3)> |
| <Reunião recorrente> | <facilitador(a)> | <publicação de pauta; notas; acompanhamento de ações> |
| <Gestão de tesouraria> | <responsável financeiro> | <ver Regulamento de Tesouraria (Camada 3)> |
| <Revisão de acesso a plataformas> | <responsável por infraestrutura> | <cadência de revisão; revogação de acesso de membros que saíram> |
O que abordar
- Which processes have to keep happening for the community to work — onboarding, exit, publishing proposals, recording contributions, running meetings, managing money, reviewing platform access, and anything else?
- For each process: which role owns it, and what does it involve in two or three sentences?
- For each process: where are the steps written down, so someone new could carry it out without asking the person who usually does it? (Where our documents live in general is its own question.)
- Which of these still depends on one person's memory or goodwill — and who will write it up, by when?
- How do we keep each written process up to date when the way we actually do it changes? (Handoffs between roles are their own question.)
Exemplos
Our core processes are member onboarding and member exit (Membership Admin, following those protocols), proposal publication (Governance Secretary), contribution recording (Contribution Steward), the weekly meeting (rotating facilitator: agenda, notes, action list), treasury management (Finance Steward) and platform access review (Infrastructure Steward, monthly, removing exited members). Each has a one-page checklist in the shared handbook that a new role holder can follow without help, and the owner updates it within a week of any change in practice.
Exemplos, não recomendações. As respostas de vocês serão de vocês.
Responsabilidades Temporárias e Ad-Hoc
How do we stop a temporary favour becoming somebody's permanent unpaid job?
Cláusulas RCOS 7.1.5, 7.1.4, 7.7.1
- 7.1.5 Responsabilidades temporárias ou pontuais DEVEM ter um prazo explícito e NÃO DEVEM se tornar contínuas sem a definição formal de um papel.
- 7.1.4 Nenhuma responsabilidade contínua PODE existir sem um papel explícito, e nenhuma pessoa PODE ser responsabilizada por responsabilidades que não foram formalmente atribuídas a um papel.
- 7.7.1 Responsabilidades contínuas NÃO DEVEM existir sem um papel explícito.
Por que limitar as responsabilidades temporárias?
Tarefas ad-hoc silenciosamente se cristalizam em trabalhos permanentes não remunerados — geralmente sobre quem disse sim uma vez. Um prazo rígido e uma revisão obrigatória fazem a diferença entre "cobri por uma semana" e "aparentemente esse é o meu papel agora".
Como preencher
Estabeleça que qualquer responsabilidade temporária DEVE ter prazo definido na atribuição, ser documentada, revisada antes da expiração e formalizada ou encerrada.
Quando uma tarefa ou responsabilidade for atribuída temporariamente, ela DEVE ser:
- <Explicitamente limitada no tempo desde o início (data final específica ou condição de conclusão).>
- <Documentada como temporária no momento da atribuição.>
- <Revisada antes da data final; convertida em papel formal ou encerrada.>
<Duração máxima de qualquer responsabilidade temporária antes que precise ser formalmente atribuída ou encerrada — por exemplo, 90 dias.> Se uma responsabilidade temporária não tiver responsável após sua data final, ela expira; não é transferida implicitamente.
O que abordar
- When someone takes on a temporary task, how is its end set — a date, or a clear condition that marks it done?
- Where is it recorded as temporary at the moment it is handed out, and by whom?
- What is the longest a temporary responsibility may run, extensions included, before it must become a formal role or stop?
- Who checks on it before the end date, and how is it either ended or turned into a proper role? (Defining the new role is a Role Registry question.)
Exemplos
Every temporary task is given with an end date or a clear "done when" condition and logged as temporary on the task board by whoever assigns it. A week before it ends, the assigner and the person doing it check in: the task either ends, or it is proposed as a new role for the Role Registry. No temporary responsibility may run longer than 90 days in total, extensions included.
Exemplos, não recomendações. As respostas de vocês serão de vocês.
Interfaces entre Papéis e Domínios
Where does one role's work end and the next one's begin?
Cláusulas RCOS 7.6.3, 7.3.4
Por que mapear as transições explicitamente?
A maioria das falhas operacionais não acontece dentro de um papel, mas entre papéis — nas fronteiras onde o trabalho passa de um responsável para outro. Nomear as transições transforma dependências invisíveis em revisáveis e evita falhas do tipo "achei que você tivesse cuidado disso".
Como preencher
Para cada par de papéis que passa trabalho entre si, nomeie a transição e o tipo de trabalho transferido.
| De | Para | Transição |
|---|---|---|
| <papel> | <papel> | <o que é entregue> |
| <papel> | <papel> | <...> |
O que abordar
- Which roles regularly pass work to each other?
- For each handoff: what is handed over, in which direction, and how does the receiving role know it has arrived?
- At what point does the work stop being the first role's responsibility and become the next one's?
- Where does work pass between a role and a meeting — for example, a decision that a role must then carry out?
- When a handoff gets dropped, who notices and who sorts it out?
Exemplos
Membership Admin to Infrastructure Steward: when a new member's trial starts, the admin posts their details in the access channel and the steward sets up accounts within three days; on exit the same route removes them. Finance Steward to Contribution Steward: at each month-end the finance steward shares amounts paid in so contribution records can be reconciled. Governance meeting to role holders: each adopted decision is assigned to a named role in the notes, and that role confirms it has picked it up.
Exemplos, não recomendações. As respostas de vocês serão de vocês.
Limites de Carga de Trabalho
How much time, meeting and care can we ask of one person — and what happens when someone is overloaded?
Cláusulas RCOS 7.4.1, 7.4.2, 7.4.3, 7.4.4, 7.7.3
- 7.4.1 Tempo, atenção, capacidade de coordenação e trabalho emocional DEVEM ser tratados como recursos finitos e limitados.
- 7.4.2 A comunidade DEVE definir limites explícitos de carga de trabalho, incluindo:
- 7.4.3 Os limites de carga de trabalho DEVEM ser revisáveis e ajustáveis por meio de um processo de governança autorizado.
- 7.4.4 Sobrecarga persistente, risco de esgotamento, não participação crônica ou dependência de indivíduos que assumem funções em excesso DEVEM acionar processos de revisão ou reparo, conforme definido na Camada 4.
- 7.7.3 A carga de reuniões, o ônus de coordenação e o trabalho não remunerado ou invisível DEVEM ser limitados e revisáveis.
Por que tornar os limites de carga explícitos?
Carga de coordenação sem limites é o modo padrão de falha de comunidades voluntárias — ela silenciosamente esgota as pessoas mais comprometidas até que elas saiam. Limites explícitos e revisáveis fazem da capacidade uma preocupação compartilhada em vez de um fardo privado.
Como preencher
Defina limites para carga de reuniões, carga de papéis, expectativas de tempo de resposta e o caminho para renegociar responsabilidades.
- Carga de reuniões: <cadência das reuniões recorrentes e duração máxima; regras para reuniões extraordinárias.>
- Carga de papéis: <limite, se houver; regra para sinalizar sobrecarga; janela de resolução.>
- Expectativas de tempo de resposta: <assíncrono não urgente; operacional urgente; crítico para a segurança.>
- Renegociação e alívio: <processo para redistribuir responsabilidades; janela de resolução.>
- Sobrecarga persistente: <como a sobrecarga persistente, o risco de esgotamento, a não participação crônica ou a dependência de pessoas que assumem funções em excesso são detectados, e como são encaminhados ao processo de revisão ou reparação da Camada 4.>
O que abordar
- How much meeting time can we ask of one person — how often, how long, and what counts as an extra meeting?
- How many roles or hours a week may one person carry — counting unseen work like hosting, cleaning up or emotional support?
- What reply times do we expect — for everyday messages, urgent operational matters and safety issues — and when is nobody expected to answer?
- When someone says they are overloaded, how is their work covered, handed on or shared out — and how quickly?
- What signs tell us there is a pattern — lasting overload, burnout, members going quiet, or everything resting on a few people — and which review or repair process does that start?
- How often do we review these limits, and how are they changed?
Exemplos
Recurring meetings take up at most four hours a month per person; an extra meeting needs 72 hours' notice. Nobody holds more than two roles or about eight hours a week, care and hosting work included. Messages get a reply within three days, urgent operational ones within a day, safety issues at once. Anyone can say they are overloaded, and their tasks are reshared within two weeks; overload flagged twice in a quarter goes to our review-and-repair process. These limits are reviewed yearly and changed by proposal.
Exemplos, não recomendações. As respostas de vocês serão de vocês.
Continuidade Operacional
If any one of us disappeared for a month, what would stop working?
Cláusulas RCOS 7.5.1, 7.5.2, 7.5.3
Por que planejar a continuidade agora?
Uma comunidade que depende de uma pessoa insubstituível está a uma doença, um conflito ou uma saída do colapso. Nomear os pontos únicos de falha — honestamente — e incorporar a transição em cada papel é o que mantém a comunidade sobrevivendo aos seus fundadores.
Como preencher
Nomeie os atuais pontos únicos de falha honestamente. Estabeleça a exigência de transição para cada papel e a cadência de revisão da continuidade.
- Estado atual: <lista honesta de pontos únicos de falha; plano de recrutamento para reduzir a concentração.>
- Mecanismos de transição: <consulte as exigências de transição por papel no Registro de Papéis; a transição DEVE ser concluída antes que um papel seja desocupado.>
- Cadência de revisão da continuidade: <trimestral; ad hoc em caso de mudança de papel.>
O que abordar
- Honestly, who or what is a single point of failure today — a person, account, key or skill that only one of us has?
- For each one: what is our plan to share it, and by when?
- For each core role and process: is the procedure written down, and what must be handed over before the holder leaves?
- Who backs up each core role — and where is a backup not yet possible?
- How often do we review this, and what else triggers a review, such as a role changing hands?
Exemplos
Today only one member can access the bank account and only one understands the water system. By March a second bank signatory will be added, and the water system will have a written guide and a trained deputy. Every core role has a named backup and a handover checklist that must be completed before the holder steps down. The Infrastructure Steward reviews this list every quarter and whenever a role changes hands.
Exemplos, não recomendações. As respostas de vocês serão de vocês.
Fluxo de Informação e Antibloqueio de Acesso
How do we make sure nobody has to go through one person to find something out?
Cláusulas RCOS 7.3.5, 7.7.4, 7.3.2
Por que tratar o acesso à informação como uma questão de governança?
Quem controla o acesso à informação controla a comunidade, querendo ou não. Tornar as regras de acesso explícitas — e proibir pontos únicos de acesso — é o que impede que guardiões informais acumulem o tipo de poder que o sistema de governança deveria conter.
Como preencher
Estabeleça quais registros são abertos a todos os Membros Plenos, a janela de resposta para solicitações de informação e a regra contra pontos únicos de acesso a informações relevantes para a governança.
- <Decisões de governança acessíveis a todos os Membros Plenos.>
- <Notas de reuniões publicadas em até X horas.>
- <Estado de adesão e atribuições de papéis acessíveis.>
- <Registros de contribuições acessíveis.>
- <Janela de resposta para solicitações de informação.>
- <Negar acesso a informações às quais os membros têm direito é um gatilho de responsabilização sob a Camada 4.>
- <Nenhum papel ou indivíduo PODE ser o único ponto de acesso a informações requeridas por outros responsáveis por papéis.>
O que abordar
- Which records can every Full Member open directly, without asking anyone — decisions, meeting notes, roles, membership, contributions? (Restricted and private records are their own question.)
- How soon after a meeting must notes and decisions be published?
- When someone asks for information they are entitled to, who must answer, and within how long?
- How do we make sure no single person or role is the only way in to information others need — passwords, files, contacts?
- What happens when someone holds back information a member is entitled to?
Exemplos
Every Full Member can read decisions, meeting notes, role assignments, membership status and contribution records in the shared drive without asking anyone. Meeting notes are posted within 48 hours. Any other request for information a member is entitled to is answered within five days. Every shared account and folder has at least two people with access, and withholding information a member is entitled to is treated as an accountability issue under our conflict process.
Exemplos, não recomendações. As respostas de vocês serão de vocês.
Localização da Documentação e Procedimentos de Atualização
What do we write down, where, and who may read it — and can every decision be traced to who made it and how?
Cláusulas RCOS 7.3.1, 7.3.2, 7.3.3, 7.8.1
Por que nomear onde cada documento vive?
Se ninguém consegue dizer onde mora a versão canônica de algo, não há versão canônica. Nomear a localização, a pessoa responsável e a cadência de revisão para cada tipo de documento é o que torna a memória da comunidade auditável em vez de folclórica.
Como preencher
Para cada tipo de documento, nomeie a localização canônica, a pessoa responsável e a cadência de revisão.
| Tipo de documento | Localização | Responsável | Cadência de revisão |
|---|---|---|---|
| <Artefatos RCOS> | <localização> | <responsável> | <cadência> |
| <Registro de membros> | <localização> | <responsável> | <cadência> |
| <Notas de reuniões> | <localização> | <responsável> | <cadência> |
| <Propostas de governança> | <localização> | <responsável> | <cadência> |
| <Registros de contribuições> | <localização> | <responsável> | <cadência> |
O que abordar
- For each kind of record — our governance documents, member registry, meeting notes, proposals, contribution records: where does the official copy live, who keeps it, and how often is it reviewed?
- What must be written down about decisions, roles, day-to-day operations and shared obligations — what does each record have to contain at minimum?
- Who may read which records, and which are restricted for privacy — on what grounds, and who may still see them?
- When must a new record be published or announced, and to whom?
- Does every decision record say what type of decision it was and which area it covers, who had the authority, how it was decided and by what threshold, the outcome, and when it takes effect?
- Where can anyone find, written down, our roles, who may decide what, our meeting types, and our access and privacy rules?
Exemplos
Governance documents, the member registry and proposals live in the shared drive, kept by the Secretary and reviewed yearly; meeting notes and contribution records live on the wiki, kept by each facilitator and the Contribution Steward and reviewed quarterly. Every decision record states its type and area, who decided, the mechanism and threshold, the outcome and its start date, and is announced within three days. Members can read everything except health, safeguarding and conflict records, which only the people involved and two named stewards may see.
Exemplos, não recomendações. As respostas de vocês serão de vocês.
Registro de Ratificação
- Adotado em: <AAAA-MM-DD>
- Tipo de decisão: Estratégica
- Versão: <versão>
- Registro da decisão: <link para o registro da decisão>