项目管理制度能带来什么并不是我们首要关心的，这其实是我们的需求带来的必要结果。没有项目管理制度，就相当于我决定要去看电影，但是没有定下看电影的时间、地点等要素，就无法顺利完成这个动作，这也就是我们在项目运转过程中遇到的问题，很多要素模糊或是缺乏根据，以至于项目进展不顺畅，员工效率低下。
为解决这个问题，我们在前期项目进行过程中，结合协作工具以及每个人的工作习惯，不断尝试符合自身发展的项目管理制度，并在此基础上，一步步促进制度规范化，最终完成了项目管理1.0，包含排期—汇报—完成整个过程的规范化要求，使我们的工作和管理步入新台阶。
文档说明
项目管理制度是公司团队为了便于统一管理项目运作，提高团队成员的工作效率和质量而制定。制定规范是为了让工作更有章程，更具可控性。本文档的制度规范是基于符合本公司企业文化以及工作模式所制定的，并以此为基础编写的可行性方案。
项目排期
/ 项目进度表 /
该表横轴是以周为单位的日期，纵轴主要分为团队工作、B端产品、C端产品三大类，其中包括具体的项目名称，固定项目列，向后延展周次，可以更直观的看到项目的周期进度变化。同时用色块区分不同岗位，加以文案辅助说明项目完成情况。团队工作固定为新媒体运营、行政项目运营、技术建设和团队建设4个分类，可查每个分类工作状态。
1.填写规范
- 进度条内容格式【预计进度百分比】【负责人】工作+状态，例:【97%】【裘】UI设计完成
【工作】描述分别为产品需求(原型)/UI设计/前端研发/后端研发/测试修复/发布交付/上线运营等
【状态】描述为确认、完成等
- 单元格固定大小，格内文字不出现两行
- 一个项目不超过2行进度条
2.颜色区分（见上图）
主要以4种颜色为主，区分项目研发进程的不同阶段，方便后续的统计。
/ 项目步骤表 /
该表横轴是工作进度，其中包括整个研发项目周期以及不同岗位的完成日期和天数，纵轴主要分为B端产品、C端产品两大类，其中包括具体的项目名称。其中添加版本号，可以查看每个研发项目的迭代周期以及项目不同阶段的完成情况。团队工作不在此处作以说明。
1.填写规范
日期格式为“年-月-日”；时间格式为“数值”，最小单位为0.5
2.颜色区分（见上图）
对应项目进度表的颜色进行分类统计。
项目流程
/ 任务说明 /
由于工作过程中的不同阶段会有不同的执行情况，所以用不同的任务类型分别管理需求的不同阶段。1.0适用版本，仅分三种类型来做初步的尝试。
1.开发任务
主要用于项目研发与bug修复创建任务，其中【研发中】包括项目研发、研发工程师自测和对接口；【测试中】表示产品测试；
【研发停止】表示项目因故停止或中断。
2.需求任务
主要用于项目类/日常需求类任务，其中【已停止】表示项目因故停止或中断。
3.日常任务
主要用于部门日常的协作管理类任务，其中【已停止】表示项目因故停止或中断。
通过配置任务的方式将不同需求阶段的连接性展示出来，实现需求的无缝衔接与流程自动化，在提高团队工作透明度的同时大大提升团队的整体工作效率。
/ 任务流程 /
1.规范任务流程，限制创建父任务
- 创建父任务角色：产品经理、UI设计、运营&行政创建需求任务；产品经理创建开发任务（研发可在已有的父任务下创建子任务）
- 同一项目开发进程中，在评论里进行交流的无需新建任务，除非重大的需求问题、新增的子任务、成为迭代版本的需求等
2.创建任务名称规范
- 需求任务：
【岗位任务】+版本号（无迭代可不写）+需求内容，例：【产品原型】1.0 需求&原型图
【项目名】+版本号（无迭代可不写）+说明，例：【SkywenWeb】3.0 官网项目
- 开发任务：
父任务：【版本号】+问题描述，例：【1.1】开发需求和BUG汇总
子任务：【模块名】+问题描述，例：【首页】根据提供的内容进行重新填充
- 日常任务
【分类名】+内容描述，例：【团队工作】周报工作试运行
【地区】+【姓名】+申报事物描述，例：【杭州】【lweein】F级人才认证+人才公寓
3.任务人员变更
任务的不同阶段，及时变更任务状态及相关负责人
变更同时，任务的负责人不能同时是任务的参与人（为保统计数据时更精确）
4. 结束任务规范
任务关闭结束时，作出及时反馈，评论进行描述并@到相关参与人员，说明任务的完成情况
- 评论规范
1.开发类：截图+客户反馈+研发bug情况描述+修复情况，部分细节可视具体任务而调整
2.设计类：版本号+设计结果，例：V1.0设计完成定稿
3.产品类：版本号+需求结果，例：V1.0需求冻结，V1.0文档定稿
4.运营/行政类：发布结果，例：文章已推送/已发表
/ 消息通知 /
根据公司的工作模式，在每个具体任务中，我们可以设置负责人，其他相关人员作为任务的参与人。当任务出现变化或评论等，对应的相关人员会收到通知，保证信息的及时分享。
- 评论任务时，不会通知到除负责人外任何身份的成员，只有在评论中@到某人时（无论被@成员是否参与项目），被@成员和负责人才会收到通知；回复消息等同于@
- 新建一个子任务相当于新建一个新的任务（目前选择派生关系）
简报方案
/ 日报制度 /
一般情况下，不用提交日报。遇到特殊的情况，比如团队成员在外办公，老板出差等，团队成员才需要提交日报。日报中进行说明今日工作、明日计划和今日工作难点。
1.【必填】今天完成了那些工作？
2.【必填】明天你计划做什么？要完成什么目标？
3.【选填】今天工作你遇到的困难是什么？希望得到哪些帮助？
/ 周报制度 /
周报用以说明每周的工作内容、下周的工作安排和本周的工作难点。此项可结合上述项目排期内容进行书写，书写过程中可以自我评估工作完成度，是否与排期吻合。在不断的重复对比中，完善提高自己的工作效率。同时可对周报编写提出成员宝贵的意见，为团队拥有更好的明天。
1.【必填】本周你完成了哪些工作？（建议每日进行草稿编辑当日工作内容）
2.【必填】下周你计划做什么？要完成什么目标？
3.【必填】本周工作你遇到的困难是什么？希望得到哪些帮助？
4.【选填】对周报编写的建议？
/ 月报制度 /
月报内容分为工作统计表、工作报告、项目问题和考勤记录。不需要团队所有成员编写，仅个别负责人需要编写。
1.工作统计表
基于worktile和语雀的数据搜集到的数据，进行必要的整理汇总，生成对应的数据图表，用数据来说明。表格横轴为数据，纵轴为项目名称/成员姓名，数据图的横纵轴根据具体的表格规格而变化。
| 数据 | |
|---|---|
| 项目名称/成员姓名 | 数值 |
2.工作报告
工作类型分为产品运营、产品开发和产品创新三部分，不同的负责人基于团队成员每周编写的周报进行整合编写成表格，横轴为团队成员姓名，纵轴为项目名称，单元格内进行工作内容说明及完成度总结；
| 成员姓名 | |
|---|---|
| 项目名称 | 工作内容 |
3.项目问题
此项内容主要为工作失误/延误和质量严重不足，具体为当月被老板监察出来的工作失误，被客户投诉反馈的工作失误，以及工作延误以及工作完成质量严重不足的。
4.考勤记录
记录公司成员的请假天数，横轴为日期和天数，纵轴为成员姓名。
| 日期 | 合计 | |
|---|---|---|
| 成员姓名 | 月/日（天） | 天数 |
案例运用
/ 开发案例 /
1.项目立项
和客户沟通确认，签订合同，在worktile平台建立项目。
2.需求阶段
产品经理与客户进行沟通，从而确认产品需求，创建一个标题为“【产品原型】版本号+需求内容”的【需求任务】。
添加产品经理为【负责人】，并配置与任务相关的【参与人】。通过评论进行交流需求方面的问题，在需求冻结时，评论“版本号+需求结果”并@相关人员结束任务，此条规范参见上文。
备注：无迭代可不写版本号，标题中内容描述可视具体情况而定义（下同）
3.设计阶段
在产品需求冻结后，进入设计阶段，创建一个标题为“【项目名字】版本号+UI设计”的【需求任务】。添加UI设计师为【负责人】，并配置与任务相关的【参与人】。通过评论进行交流设计方面的需求与意见，在设计定稿时，评论“版本号+设计结果”并@相关人员结束任务。此条规范参见上文。
4.研发阶段
设计定稿，进入产品研发阶段时，创建一个【开发任务】，添加研发工程师为【负责人】，并配置与任务相关的【参与人】。研发过程中涉及需求变动时，产品经理创建一个标题为“【版本号】+需求汇总”的父任务，同时分配给相应的研发工程师对应的子任务，标题为“【模块名】+问题描述”，研发工程师也可自行添加子任务。
研发工程师自测和对接口，以及产品测试阶段，产品经理创建一个标题为“【版本号】+Bug汇总”的父任务，研发工程师们可自行添加子任务。随着任务的进展及时更新任务状态。
整个项目开发进程中，通过评论进行交流需求、设计及研发过程中遇到的问题，在完成研发时，评论中描述原因并@相关人员结束任务。此条规范参见上文。
5.上线运营
在一个版本完成研发后，进行上线发布，进入运营维护阶段。针对客户和用户反馈，以及产品运行中遇到的问题，运营人员进行维护总结，上报问题给产品经理，创建任务进行新一轮的修改流程。
6.其他
结束每周的工作以后，每个岗位成员在简报中提交当周的工作任务进展、下周的工作计划及本周工作任务的难点。
/ 运营案例 /
1.项目立项
和客户沟通确认运营类的任务和文案，在worktile平台建立项目。
2.需求阶段
与客户进行沟通，把需求转化为文档，说明运营方式与文案，确认需求后，进入制作阶段。
**
3.制作阶段
根据任务性质，创建一个【需求任务】，添加运营人员为【负责人】，并配置与任务相关的【参与人】。标题为“【项目名称】+需求内容”的父任务，视情况创建子任务，规范同父任务。整个项目进程中，通过任务评论进行交流沟通，制作结束后，在评论中描述结束原因并@相关人员。此条规范同样参见上文。
4.上线运营
完成制作后，进行上线发布，进入维护阶段。针对客户和用户反馈，以及运行中遇到的问题，运营人员进行维护总结，创建任务进行新一轮的修改流程。
5.其他
结束每周的工作以后，每个岗位成员在简报中提交当周的工作任务进展、下周的工作计划及本周工作任务的难点。
方案思考
/ 项目排期 /
1.项目进度表
在实际使用中，发现管理者需要看的字段有时间、周期、岗位、项目进度等。在经过多次的研究调整后，最后采用了以甘特图的表格形式展现。以周和项目为单位，加以色块区分，更直观的看到项目在周期中不同阶段的进度变化。在一定程度上，也为成员在计划完成任务时做了合理的规划，保证工作的效率逐步提升。
2.项目步骤表
在使用进度表的同时发现了还需要对研发项目流程中不同阶段的工作进行说明，因此在这基础上添加了版本号，可以查看每个项目迭代的版本数量及每个迭代版本完成情况。同时添加研发项目中从产品到上线运营不同的阶段的用时和完成时间，可以更显眼的观察到每个迭代周期内成员的完成效率。
/ 项目流程 /
1.任务配置
在实际使用过程中，发现原有的通用配置中，集合了一个任务从计划到发布的全部流程，并不适用于我们团队现有的工作模式和协作方式。因此，我们采用根据项目性质进行设计任务类型，配置不同岗位的人员的方式。与此同时，给每个任务配置相对应的任务状态。
2.任务规范
在统计数据的分析时候，发现给予多人创建任务的权限，会引起部分数据混乱，故对人员创建权限进行了部分限制。进行这步操作的同时，发现合理有效的规范任务的格式，包括标题、负责人、评论等形式，对管理层查看实时状况也有了更舒适的体验，也方便统计者进行整理内容。
3.消息通知
基于worktile的功能和使用过程中，同时收集了公司成员们的使用体验及优化意见，在符合公司内部的制度，并提高团队协作有效性的情况下，研究讨论出了一套更高效、便捷的消息通知模式，减少成员们在使用过程中不必要的时间浪费，从而提高工作效率。
/ 简报方案 /
基于worktile和语雀的数据筛选统计整理，有效的查看团队成员当月任务的工作量和完成效率。数据统计作为一部分绩效考核和个人成长空间参考，一定程度上加强了成员们的工作上进心与责任感培养。管理者在查看简报时，产生对成员进行培养方向的思考；成员本人在看查看简报时，产生自我评估与工作预期及规划。
/ 制度总结 /
制度规范对整个团队工作非常重要且有意义，通过多次实践配置出新的项目模版，结合管理制度的合理运用，使得公司成员协作更加便利化、高效化。当然，以上可行性方案配置仅限本公司团队的工作模式，并不适用于所有公司的工作模式。项目管理的基础方案我们仍在继续完善制度，针对团队不同阶段的情况进行适当的调整和优化，争取团队成员们用着顺心，老板看着放心。
/ 版本展望 /
1.项目模版
2.0版本会新增所属迭代、优先级、标签等功能，更好的结合项目任务进行排期，进一步提升成员效率，解决部分任务疑虑。
2.任务配置及规范
1.0版本的任务类型及状态是根据当前的情况所配置的，规范也只针对目前的情况，随着使用的频率和遇到的问题的增加，需要及时更新规范的标准。2.0版本需要完善任务状态和任务规范，并且根据1.0版本使用过程中新出现的问题进行总结思考，制定出新的任务模版。
3.消息通知
1.0只配置和测试了PC端的模式，2.0版本将同步到移动端去，以及一些移动端没有研究测试到的其他消息通知类型。
4.简报方案
2.0主要针对月报制度进行完善，重点体现在几个工作统计表的呈现形式上需要进一步研究分析，包括筛选数据字段的必要性，进行总结完善。除此之外，规范一下其他表格的形式，找到更适合我们团队的模式。
总 结
以上就是我们项目管理制度的具体内容。制度总在实践中思考和诞生，也需要在实践中改进，在这套1.0制度正式在我们公司内部实行后，我们也必将产生新的想法，把它加入到今后的2.0 3.0 中，希望最终能走上最适合、最有助于项目和团队自身发展的道路。如果你对于项目管理制度规范化有任何的想法或建议，也可以留言探讨，期待您的建议为我们带来新的灵感。
