示例结构： http://114.67.82.250/display/Ts/Team_Space项目管理方法-总结概要项目经理的工作包括这些方面： 需求、团队日常、任务、文档。
需求管理：完成“需求”是核心目标，流程化、风险可控化是手段。 团队规范：项目经理需要整理出“团队规范”、书面化标准，以明确要求，避免反复口头传达要求。 任务管理：任务可跟进，是达成“需求”、项目正常运转的保障。 文档管理：需要引导明确要求，组织好文件存放的层级结构，以可持续的更新。 是项目长治久安的保障。 需求各阶段管理需求沟通
细节工作可以下发，但项目经理要对需求内容整体都了解 将需求汇总到项目组的“需求跟踪表”中。 建立该需求的临时资料svn目录，如：“4.55精品商务经济座积分”，保存需求文档及后续文档。 立项完成《开发方案》、wbs、流程图、样式设计（RP软件），示例： 后续重要沟通结论、识别的新问题，及时补充到《开发方案》或专有主题的文档。 避免单个开发人员总揽方案，而没有多人评审环节，这样容易出现功能设计风险问题。 《开发方案》中包含功能设计、风险点、待沟通问题、对接项目组及负责人及时间点、性能、可用性等的考虑。 将风险点加入项目组的“风险跟踪”中。 将开发、测试、上线时间点、对接时间点、uat测试时间等加入“需求里程碑跟踪”表。要求产品经理也要关注与其相关的时间点。 开发开发人员对《开发方案》中不够详细的详细处理流程，使用易交流的方式补全。 完成srs，完成输入输出等详细约束、定义 代码分支开发，sql脚本、部署说明文档，按代码分支保存。 将分支名加入“代码分支跟踪表” 测试测试人员梳理测试点，以达到理解一致。需要考虑上线后的验证方法、过程。有需要功能开发帮助测试验证的内容，提前提出。 使用工具记录、处理bug 预验收、培训上线前需要及时组织产品经理、业务人员，对功能做uat测试，培训（立项时预约时间点）。可有效减少体验问题。 发布准备上线发布步骤、清单等信息，准备线上验证点、步骤、时间点计划。 安排一人整体协调发布过程。 涉及外部联调，提前准备接口地址、账号等信息。 线上跟踪上线后，一周内需要关注相关功能的错误日志、服务日志。有问题优先解决。 更新“代码分支跟踪表” 更新“线上服务配置信息汇总”，包括配置参数、日志关键字等。 将《开发方案》的功能点细则，合并到“业务规则”文档 更新“功能日常维护人员表” 更新“依赖的接口及汇总、依赖的接口及汇总”，包括接口、数据的外部项目组负责人、接口地址等信息。 新上线的项目，要更新“线上发布记录” 日常运维项目上线后，可考虑加入系统的监控系统，如“数据量变化监控功能” 响应业务部门对功能的咨询 响应其它项目组对接口、业务的咨询 处理线上问题、bug 尽量及时处理旧问题，避免合并到新问题一起处理。 业务咨询的问题，及时补充到“业务规则”或“用户手册（单独空间）”。 其它注意点某需求分拆多次上线的，要跟踪多次对应的时间点。 一个需求中，既有新功能，又有对原功能的修改时，要考虑修改原功能产生的风险大小，如果大的话，分拆上线是否可以减小风险。 修改多个原有功能时，也要考虑产生的风险大小，是否可以分拆上线，减少风险。因为分拆后，可以及时验证、关注该功能点的影响。 需求分期模板
投入产出分析、结项项目的目的是产出效益。在可能的情况下，接收需求前分析投入产出，是否值得做。 在新项目上线初步稳定后，结项、评估实际投入产出效益。之后转为维护与优化项目。 大的版本变更需求，作为独立项目开启，评估投入产出效益。之后重新变为“维护与优化项目”。 团队管理目标：团队高效高质完成任务，提升团队成员能力。 “需求跟踪表”
|
redmine | wiki | |
方便记录、关联详情 | 是 | |
方便层级管理 | 是 | |
方便跟踪工时 | 是 | |
操作简单 | 是 |
IT现有redmine体系 没有很好讲解设计原则，项目组可操作性差。
redmine项目，应以部门、项目组为管理主体，方便他们集中管理。
业务需求、IT产品需求、项目组版本任务，彼此关联。
年度计划，需要提前录入“IT需求”项目做跟踪管理 。
项目组任务包括：需求工时、临时任务（线上bug、问题分析、待处理bug或优化、支持外部工时）、日常任务（日常任务、周期任务）。
某类临时任务，能提前识别并指派的，就归为日常任务。
如果使用redmine替代qc记录bug，则一个redmine项目记新需求工时、临时任务，另一个记bug跟踪。
使用“跟踪任务”列（或“跟踪”=“任务跟踪”，推荐前一种方式），识别每个人在处理哪些任务。每个人同时在处理的任务数应在3~5个以内。“跟踪任务”另可加自定义属性“质量打分”（1~5分，用于绩效计算=计划工时*“质量打分”）
redmine任务管理有一个问题：添加子任务时，会把父任务的计划日期、计划工时覆盖掉，所以需要3个新属性来记录（当子任务尚未全创建完时）。
或配置不随子任务变化。
需求的里程碑，也可以创建一条redmine任务（“跟踪”=“里程碑”），跟踪时间点。 相比不如在wiki里直观。
方式一（推荐）：排在“测试”期间，按人建bug修复任务。发布也是一样，按人建任务。
方式二：开发任务工时包含bug修复工时，但计划完成时间仅指编码实现。
使用方法： 创建任务跟踪
wiki为主，svn为辅的方式管理文档。
svn里按需求分文件夹，命名类似如下：
上线时，将svn目录中的文档拆分、合并到wiki中（开发方案、数据字典、线上服务信息、配置账号等）。
开发方案 分为两个：一个概要（功能点与规则，上线后合并到 业务规则）、另一个是详细设计（补充细节规则、实现逻辑，上线后合并到开发方案）
测试整理的文档，存在 测试文档
备选方案：某功能的”开发方案“，做为该功能的“业务规则”的子节点。
关于“业务规则”的书写，建议项目经理先做几次示范，以后的再分配给成员做，并自己检查修正后使用。
任务 | 文档 | 补充文档 | 代码 | 测试、bug | 部署 |
redmine wiki | wiki | svn文档 | git | qc或redmine | |
使用svn的话，操作繁琐，不方便频繁变更、高效交流。不建议组织一个很大的文件，在svn里频率更新。
使用wiki的话，部分文档类型不够强大，还是需要线下再处理一些文档（excel、word、project、思维导图、流程图等）。
功能 | 优点 | 缺点 | ||
文档管理 | confluence | 方便分享、协作 | ||
文档管理 | word、excel | |||
文件管理 | git | 分布式版本管理 | ||
文件管理 | svn | 适合修改频率低文档管理 | ||
文件管理 | 网盘 | |||
文件管理 | 共享目录 | 快捷、临时用途 | 访问限制不好控制 | |
任务管理 | jira | 适合敏捷 | ||
任务管理 | redmine | 操作略复杂 | ||
任务管理 | 禅道 | |||
任务管理 | confluence | 无法层级管理、工时登记 | ||
任务管理 | project、excel | 适合临时计划 | 不利于长期汇总 | |
示例：0使用说明
1.在”技术分享“下创建文档
2.为技术文档添加技术名词标签
3.在”技术分享“页面，可以按标签搜索文档
|
|
工作量跟踪表
