8.8 KiB
8.8 KiB
项目管理系统 - 产品需求文档 (PRD)
1.0 项目背景
当前公司的项目管理与任务跟进方式存在诸多痛点。信息主要依赖企业微信、微加云及WPS共享文档等多种分散的工具进行汇报和汇总，导致了以下核心问题：
- 信息孤岛与“两张皮”现象: 项目的实际执行情况与汇报内容严重脱节。如会议中提到，“汇报情况跟实际情况有点脱节是吧？现在说相当于两张皮那意思”。
- 缺乏统一视图: 管理层（如孙院）无法在一个统一的平台上看到所有项目的全貌，包括进度、里程碑、财务数据和风险，导致决策缺乏数据支持。
- 流程混乱且不可持续: 目前依赖人工（如童老师）手动汇总各方周报，效率低下且易出错。使用共享文档进行多人协作时，版本冲突和数据覆盖问题频发，如“5个人同时给你一回，我天你这个合并的工作砍了去了”。
- 责任不明确: 任务的责任人、牵头人界定模糊，多个负责人导致“三个和尚没水吃”的局面。许多任务甚至未正式下达，导致负责人不知情。
- 缺乏过程管理: 现有模式只有简单的结果汇报，缺少对项目过程的跟踪、复盘与分析机制，如“做到有没有总结，没有分析，也没有，比如说咱复盘一下，对啥都没有”。
因此，亟需建立一套轻量、高效、权责清晰的任务与项目管理系统，以替代现有的混乱模式，确保管理制度能够落地，并为管理层提供有效的决策支持。
2.0 目标用户与核心场景
| 目标用户 | 核心诉求与场景 |
|---|---|
| 高层管理者 (孙院/孙总) | 诉求: 快速、全面地掌握所有项目的宏观状态，进行有效督办和决策。 场景: 在周会或日常工作中，通过系统仪表盘查看各项目的整体办结率、滞后率、关键风险，并能下钻查看具体任务的最新进展汇报。 |
| 项目牵头人 (各业务线负责人) | 诉求: 监督自己所负责的多个项目的进展，确保项目经理有效推进。 场景: 定期（如每周）在系统中查看自己名下项目的任务列表，跟进重点事项，对项目经理提交的汇报进行审核和评论。 |
| 项目经理/责任人 (具体执行者) | 诉求: 清晰地接收和管理任务，便捷地汇报工作进展。 场景: 在系统中接收任务指派，分解任务，并定期（如每周）在对应任务下填写工作内容、下周计划和遇到的问题。 |
| 董事长办公室/助理 (信息汇总者) | 诉求: 从繁琐的手动汇总工作中解放出来，高效生成汇报材料。 场景: 系统能自动聚合各项目的周报信息，一键生成结构化的汇报，供办公室整理后向高层汇报。 |
3.0 原始需求梳理 (会议原话)
- 现状问题: “上次孙愿意说说，你看你们这个汇报情况，当时就跟那个谁彭松说汇报情况跟实际情况有点脱节是吧？现在说相当于两张皮那意思。”
- 数据割裂: “缺少一个就是财务信息，就是指他那边比如说广西广州那边应该是负责招商是吧？但实际上招了几个也没有没有很具象...成本也好，进度也好，什么里程碑它都其实是分开的。”
- 管理制度缺失: “第一个先得出一个任务管理办法...有了这个任务的管理制度达成共识，才说我们的系统要做成啥样，是配合这套制度走的。”
- 工具瓶颈: “共享文档...肯定乱套了...你这5个人同时给你一回...合并的工作砍了去了”，“WPS两个版本，个人版，那是小钱儿，企业版那是大钱儿，那都是几十万起。”
- 任务状态模糊: “事项来说有大有小...有抽象有具体...有的是非常明确了就可以往下做了...有的是这玩意都没有分解，目标都没有定，有的甚至还是孙孙悦这边的一个idea。”
- 责任界定不清: “责任人定多个，这个事就跟没定人一样。”
4.0 需求要点抽象
基于以上讨论，新的项目管理系统需满足以下核心需求：
- 任务全生命周期管理: 系统必须支持从想法（Idea）、待讨论、正式立项、执行、汇报到关闭的完整流程。
- 结构化的汇报机制: 替代自由填写的共享文档，提供结构化的在线汇报模板，强制要求填写关键信息（本周进展、下周计划、问题与风险）。
- 清晰的权责体系: 每个任务有且只有一个主要责任人，可设定多个协作人或牵头人，但权责必须明确。
- 分层级的视图与报告: 为不同角色的用户提供定制化的数据视图。高层看宏观仪表盘，牵头人看项目列表，执行人看个人待办。
- 制度先行，系统辅助: 系统设计必须紧密配合即将制定的《任务管理办法》，成为制度落地的工具，而非简单的信息记录。
- 轻量化与易用性: 避免过度复杂的“大系统”，操作应直观便捷，降低用户的学习和使用门槛。
5.0 产品详细需求
| 模块 | 功能点 | 详细描述 | 优先级 |
|---|---|---|---|
| 任务管理 | 任务分类与状态 | 1. 任务需支持分类标签，如：“想法/备忘”、“待讨论”、“已立项/执行中”。 2. 状态至少包括：待处理、进行中、已完成、已延期、已关闭。 |
高 |
| 任务立项 | 1. 提供一个简化的立项表单，包含：任务名称、目标、责任人、牵头人、截止日期、所需资源等。 2. 支持一个简易的审批流程，如责任人确认接收任务。 |
高 | |
| 任务汇报 | 1. 在每个任务下设独立的汇报区。 2. 汇报时需填写固定字段：进展描述、遇到的问题、下周计划。 3. 所有历史汇报记录按时间线清晰展示，不可随意修改。 |
高 | |
| 用户与权限 | 角色定义 | 系统预设“高层管理者”、“牵头人”、“责任人”、“办公室助理”等角色，并可自定义权限。 | 高 |
| 仪表盘与报告 | 领导视图 | 1. 为“高层管理者”提供一个全局仪表盘。 2. 展示关键指标：任务总数、延期率、办结率、各项目/负责人名下的任务分布。 |
高 |
| 自动汇总报告 | 1. 支持按周、按月、按项目、按负责人等维度筛选并导出汇报汇总。 2. 导出格式可为Word或PDF，方便二次编辑和存档。 |
中 | |
| 系统管理 | 组织架构 | 支持根据公司的实际组织架构（如按分院、按公司、按项目组）维护人员信息。 | 中 |
6.0 核心业务流程图 (Mermaid)
以下是建议的任务管理核心流程：
graph TD
A[想法产生/会议决议] --> B{任务分类};
B -->|作为备忘录| C[录入系统, 标记为想法];
B -->|需进一步讨论| D[录入系统, 标记为待讨论];
B -->|明确可执行| E[发起任务立项];
D --> F[相关人员进行讨论/确认];
F -->|确认执行| E;
F -->|暂不执行| G[归档];
E --> H[填写立项信息目标责任人DDL];
H --> I[责任人确认接收];
I --> J[任务进入执行中状态];
J --> K{责任人定期汇报};
K -->|提交周报| L[系统记录汇报历史];
L --> M[牵头人/管理者审阅并评论];
M --> J;
J --> N{达到截止日期};
N -->|任务完成| O[提交办结申请];
O --> P[牵头人审核通过];
P --> Q[任务状态变更为已完成];
N -->|未完成| R[任务状态自动标记为已延期];
R --> J;
7.0 待办事项与责任人
根据会议内容，当前需立即跟进的行动项如下：
| # | 待办事项 | 责任人/协作方 | 提及的截止日期 |
|---|---|---|---|
| 1 | 梳理并分类现有任务清单: 将孙总提及的所有事项，按“想法”、“待讨论”、“可执行”三个类别进行初步划分。 | 说话人3, 张老师 | - |
| 2 | 起草《任务管理办法》草案: 制定一套正式的管理制度，明确汇报机制、频率和各方职责，为新系统奠定基础。 | 说话人2 (建议), 需孙院牵头 | - |
| 3 | 形成系统建设建议并与孙院沟通: 基于本次讨论，整理一份关于建设轻量级任务管理系统的正式建议，向孙院汇报并获取决策。 | 说话人2 | 近两天 |
| 4 | 敲定短期内的过渡方案: 在系统上线前，采用“一人一文档”或“一项目一文档”的方式，由办公室每周手动合并，以规避共享协作冲突。 | 说话人3 | 立即执行 |
| 5 | 组织参观考察活动: 协调并安排与张远的参观事宜。 | 说话人1 | 周二或周三下午 |