升职!加薪!-产品经理也要学管理,效率工具来帮你.pdfVIP

升职 ! 加薪！ -产品经理也要学管理，效率工具来帮你 我喜欢我现在的职业，不只是因为互联网是我的兴趣所在，也是因为我很喜欢这种在没有明确管理 职权下却要切实参与到管理工作的挑战感。 年轻固然喜欢挑战，但我老了应该也一样会喜欢这种感觉，这应该是性格所致。 产品经理的产品设计能力是核心技能，但在很多团队中产品经理充当的角色都是复合性的，产品经 理对需求的把控能力可以决定项目的品相，而项目管理的能力则是决定整个项目能否完成甚至整个 团队能否稳定输出的关键。 刚巧最近的工作主要围绕的也是项目管理相关的内容，拿来做下个人的总结。 主要有两个方面： 1. 项目流程的管理优化。 2. 项目信息的沟通同步。 【项目流程的管理优化】 敏捷开发大行其道， scrum 等方法都在业内盛行，理论之上一切美好，落入到实际执行之中就有很多 不可控的问题。 我所理解到的原因三点如下： 1. 团队人员的意外变动： Feature 不同，开发人员也不同，项目组内不同成员的沟通门槛高度不一致，需要磨合，实际工 作中，经常性的会有人员变动：新成员的加入、老成员的离开都会带来问题。 2.共性的激励策略建立困难： 职务不同，绩效考核的标准、负责考核的管理者的不同都会带来阻碍。没有共性的激励策略会导 致协作过程中不同职务的人只会专注于减少自己的工作量。 3.跨部门协作、跨公司协作时存在的多方面不同步 合作性质的项目都存在工作时间同步困难，信息同步困难，工作计划同步困难，考核标准同步 困难。 问题主要针对两个层面：团队内部的协作流程和 跨团队的协作标准。 好的工作流程建立之后，标准自然生成，通过效率工具可以很好地解决以上两个层面的问题。 下面就讲下关于流程建立我的理解和效率工具的对比。 团队内部的协作流程 : 包括需求管理（产品主导）、版本或分支管理（开发主导）、 Bug 管理（测试主导） 需求管理： 1. 需求策划阶段：需求功能点的优先级划分明确 ,需求版本管理需有总表。迭代规划清晰，便于及 时调整以及后续规划，防止出现空闲时段。也避免开发架构出现问题。需求策划阶段就需要开发工 程师介入。 2. 立项阶段：需求工作量的准确评估，时间容错度提前订好，以免陷入无限期延期。 评估知会 Leader ，辅助定位时间，明确问题责任，如果评估有误是评估者的问题，如果评估 过长， Leader 未能指出，则是 Leader 责任。 3. 开发、测试阶段：灵活应变，每有变动必重新敲定时间点，开发工程师无法确定时间点的情况 可以先给出一个时间范围，讲明无法确定时间的原因，提供候能够确定工作量的时间点并在该点再 次评估确认。。 4. 上线后既下版本开发阶段，循环以上 3个步骤。周期可以适当延长。 5. 文档管理最好提供统一的日期或效率工具，可以使用 SVN 管理需求文档，也可以通过自己维护 文档版本号来管理，总之要第一时间纳入需求变更，第一时间通知项目组成员更新文档。 效率工具： Trello ： 优点：便于项目全部流程管理，跨终端访问便捷，对于协同工作效率提升明显。 缺点：对其他系统的接入协作相对而言不太友好。 Office ： 优点：通过 Excel 自建需求池，我之前一直使用的是这种方式，文档版本定义更自主。 缺点：版本管理、协同工作在国内当前环境下是需要借助其他工具实现。信息传递不够顺畅。 SVN: 优点：之前的项目中使用过 SVN 来管理文档，状态回滚、协作编辑、信息记录都非常便捷。 缺点：是 SVN 的更新逻辑在增量更新时节省空间且便捷，但对于文档这种需要频繁撰写修改模式的 文档管理，非常浪费服务器存储资源。 开发版本或分支管理 也是最近项目中同开发工程师讨论中收获的。感谢同事 WXP 。 1. 分支管理清晰，开发分支、测试分支、线上分支、代码总库。 2. 不同分支权限需明确，开发分支进入测试分支需要知会测试人员，测试人员与开发 Leader 共同 决定可否并入线上分支。 3. 记录信息：版本通过分支管理需做到可以回滚到变更前的状态啊。改动记录：修改人、修改 时间、测试人、测试时间都需明确，这样明确事故责任，使开发工程师形成自我代码管理验收的 意识。 4. 代码总库，每次提测前的版本