Manual de Operaciones
Descargar esta plantilla
Generado el 2026-08-31 · Descargar todas las plantillas
Procesos Operativos Fundamentales
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 Los procesos operativos críticos DEBEN estar documentados de modo que la continuidad no dependa de conocimiento tácito de personas específicas.
- 7.7.2 Los procesos operativos críticos NO DEBEN depender exclusivamente de la memoria individual, la buena voluntad o la transmisión informal.
- 7.6.3 El Manual de Operaciones DEBE definir, como mínimo:
¿Por qué documentar los procesos críticos?
Si un proceso solo existe en la cabeza de una persona, la comunidad depende de que esa persona aparezca — para siempre. Documentar los procesos críticos por escrito, con responsables nombrados, es lo que convierte el conocimiento privado en un activo comunitario que sobrevive a traspasos, ausencias y salidas.
Cómo rellenar esto
Para cada proceso crítico recurrente (incorporación, salida, publicación de propuestas, registro de contribuciones, cadencia de reuniones, gestión de tesorería, revisión de accesos a plataformas), nombra un responsable y una breve descripción.
| Proceso | Quién | Detalle |
|---|---|---|
| <Incorporación de miembros> | <rol> | <ver Protocolo de Incorporación (Capa 1)> |
| <Salida de miembros> | <rol> | <ver Protocolo de Salida y Separación (Capa 1)> |
| <Publicación de propuestas> | <rol> | <ver Protocolo de Gobernanza (Capa 2)> |
| <Registro de contribuciones> | <rol> | <ver Protocolo de Economía Interna (Capa 3)> |
| <Reunión recurrente> | <facilitador/a> | <publicación de agenda; actas; seguimiento de acciones> |
| <Gestión de tesorería> | <administrador/a de finanzas> | <ver Reglamento de Tesorería (Capa 3)> |
| <Revisión de accesos a plataformas> | <administrador/a de infraestructura> | <cadencia de revisión; revocación de accesos para miembros que han salido> |
Qué cubrir
- 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.)
Ejemplos
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.
Ejemplos, no recomendaciones. Sus respuestas serán las suyas.
Responsabilidades Temporales y 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 Las responsabilidades temporales o ad-hoc DEBEN estar explícitamente acotadas en el tiempo y NO DEBEN convertirse en continuas sin una definición formal de rol.
- 7.1.4 Ninguna responsabilidad continua PUEDE existir sin un rol explícito, y ninguna persona PUEDE ser responsabilizada por obligaciones que no estén formalmente asignadas a un rol.
- 7.7.1 Las responsabilidades continuas NO DEBEN existir sin un rol explícito.
¿Por qué limitar las responsabilidades temporales?
Las tareas ad-hoc se solidifican silenciosamente en trabajos permanentes no remunerados — generalmente sobre quien dijo que sí una vez. Un límite temporal estricto y una revisión obligatoria marcan la diferencia entre "cubrí durante una semana" y "aparentemente este es mi rol ahora."
Cómo rellenar esto
Establece que toda responsabilidad temporal DEBE estar acotada en el tiempo al asignarla, documentada, revisada antes del vencimiento, y formalizada o terminada.
Cuando una tarea o responsabilidad se asigna temporalmente, DEBE:
- <Estar explícitamente acotada en el tiempo desde el inicio (fecha de fin específica o condición de finalización).>
- <Documentarse como temporal en el momento de la asignación.>
- <Revisarse antes de la fecha de fin; convertirse en un rol formal o terminarse.>
<Duración máxima de cualquier responsabilidad temporal antes de que DEBA asignarse formalmente o terminarse — p. ej. 90 días.> Si una responsabilidad temporal no tiene responsable después de su fecha de fin, caduca; no se transfiere implícitamente.
Qué cubrir
- 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.)
Ejemplos
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.
Ejemplos, no recomendaciones. Sus respuestas serán las suyas.
Interfaces entre Roles y Dominios
Where does one role's work end and the next one's begin?
Cláusulas RCOS 7.6.3, 7.3.4
¿Por qué mapear los traspasos explícitamente?
La mayoría de los fallos operativos no ocurren dentro de un rol sino entre roles — en las fronteras donde el trabajo pasa de un responsable al siguiente. Nombrar los traspasos convierte dependencias invisibles en dependencias revisables, y previene los fallos de "yo pensaba que lo tenías tú".
Cómo rellenar esto
Para cada par de roles que se pasan trabajo entre sí, nombra el traspaso y el tipo de trabajo transferido.
| De | A | Traspaso |
|---|---|---|
| <rol> | <rol> | <qué se traspasa> |
| <rol> | <rol> | <...> |
Qué cubrir
- 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?
Ejemplos
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.
Ejemplos, no recomendaciones. Sus respuestas serán las suyas.
Límites de Carga de Trabajo
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 El tiempo, la atención, la capacidad de coordinación y el trabajo emocional DEBEN tratarse como recursos finitos y limitados.
- 7.4.2 La comunidad DEBE definir límites explícitos de carga de trabajo, incluyendo:
- 7.4.3 Los límites de carga de trabajo DEBEN ser revisables y ajustables mediante un proceso de gobernanza autorizado.
- 7.4.4 La sobrecarga persistente, el riesgo de agotamiento, la no-participación crónica o la dependencia de personas que funcionan en exceso DEBEN activar procesos de revisión o reparación según lo definido en la Capa 4.
- 7.7.3 La carga de reuniones, la carga de coordinación y el trabajo no remunerado o invisible DEBEN estar acotados y ser revisables.
¿Por qué hacer explícitos los límites de carga de trabajo?
La carga de coordinación ilimitada es el modo de fallo predeterminado de las comunidades voluntarias — quema silenciosamente a los miembros más comprometidos hasta que se van. Límites explícitos y revisables hacen de la capacidad una preocupación compartida en lugar de una carga privada.
Cómo rellenar esto
Establece límites para la carga de reuniones, carga de roles, expectativas de tiempo de respuesta, y el camino para renegociar responsabilidades.
- Carga de reuniones: <cadencia de reuniones recurrentes y duración máxima; reglas para reuniones extraordinarias.>
- Carga de roles: <tope si lo hay; regla para señalar sobrecarga; plazo de resolución.>
- Expectativas de tiempo de respuesta: <asíncrono no urgente; operativo urgente; crítico para la seguridad.>
- Renegociación y alivio: <proceso para redistribuir responsabilidades; plazo de resolución.>
- Sobrecarga persistente: <cómo se detecta la sobrecarga persistente, el riesgo de agotamiento, la no participación crónica o la dependencia de personas que sobrefuncionan, y cómo se deriva al proceso de revisión o reparación de la Capa 4.>
Qué cubrir
- 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?
Ejemplos
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.
Ejemplos, no recomendaciones. Sus respuestas serán las suyas.
Continuidad Operativa
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 qué planificar la continuidad ahora?
Una comunidad que depende de una persona irremplazable está a una enfermedad, un conflicto o una salida de distancia del colapso. Nombrar los puntos únicos de fallo — con honestidad — e incorporar el traspaso en cada rol es lo que permite a la comunidad sobrevivir a sus fundadores.
Cómo rellenar esto
Nombra honestamente los puntos únicos de fallo actuales. Establece el requisito de traspaso para cada rol y la cadencia de revisión de continuidad.
- Estado actual: <lista honesta de puntos únicos de fallo; plan de reclutamiento para reducir la concentración.>
- Mecanismos de traspaso: <referencia a los requisitos de traspaso por rol en el Registro de Roles; el traspaso DEBE completarse antes de que un rol quede vacante.>
- Cadencia de revisión de continuidad: <trimestral; ad hoc ante cambio de rol.>
Qué cubrir
- 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?
Ejemplos
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.
Ejemplos, no recomendaciones. Sus respuestas serán las suyas.
Flujo de Información y Anti-Monopolización
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
- 7.3.5 El flujo de información DEBE diseñarse para prevenir el control de acceso indebido, los cuellos de botella o la dependencia de intermediarios informales.
- 7.7.4 Las reglas de acceso a la información DEBEN ser explícitas y aplicables.
- 7.3.2 Las reglas de documentación DEBEN especificar, como mínimo:
¿Por qué tratar el acceso a la información como un asunto de gobernanza?
Quien controla el acceso a la información controla la comunidad, lo pretenda o no. Hacer explícitas las reglas de acceso — y prohibir los puntos únicos de acceso — es lo que impide que los guardianes informales acumulen el tipo de poder que el sistema de gobernanza se supone que debe controlar.
Cómo rellenar esto
Indica qué registros están abiertos a todos los Miembros Plenos, el plazo de respuesta para solicitudes de información, y la regla contra los puntos únicos de acceso para información relevante de gobernanza.
- <Decisiones de gobernanza accesibles para todos los Miembros Plenos.>
- <Actas de reuniones publicadas en un plazo de X horas.>
- <Estado de membresía y asignaciones de roles accesibles.>
- <Registros de contribuciones accesibles.>
- <Plazo de respuesta a solicitudes de información.>
- <Retener el acceso a información a la que los miembros tienen derecho es un activador de rendición de cuentas según la Capa 4.>
- <Ningún rol o individuo PUEDE ser el único punto de acceso para información requerida por otros titulares de roles.>
Qué cubrir
- 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?
Ejemplos
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.
Ejemplos, no recomendaciones. Sus respuestas serán las suyas.
Ubicaciones de Documentación y Procedimientos de Actualización
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 qué nombrar dónde vive cada documento?
Si nadie puede decir dónde está la versión canónica de algo, no hay versión canónica. Nombrar la ubicación, el responsable y la cadencia de revisión de cada tipo de documento es lo que hace que la memoria de la comunidad sea auditable en lugar de folclórica.
Cómo rellenar esto
Para cada tipo de documento, nombra la ubicación canónica, el responsable y la cadencia de revisión.
| Tipo de documento | Ubicación | Responsable | Cadencia de revisión |
|---|---|---|---|
| <Artefactos RCOS> | <ubicación> | <responsable> | <cadencia> |
| <Registro de miembros> | <ubicación> | <responsable> | <cadencia> |
| <Actas de reuniones> | <ubicación> | <responsable> | <cadencia> |
| <Propuestas de gobernanza> | <ubicación> | <responsable> | <cadencia> |
| <Registros de contribuciones> | <ubicación> | <responsable> | <cadencia> |
Qué cubrir
- 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?
Ejemplos
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.
Ejemplos, no recomendaciones. Sus respuestas serán las suyas.
Registro de Ratificación
- Adoptado: <AAAA-MM-DD>
- Tipo de decisión: Estratégica
- Versión: <versión>
- Registro de decisión: <enlace al registro de decisión>