| 编辑推荐: |
| 本文来自于人人都是产品经理，文中说到了对产品的定位，有条不紊的项目实施阶段，迭代的步伐。 |
|
项目管理的作用对象是项目团队（当然也有项目外部的干系人，本文只针对项目团队），最好的项目管理应该是让团队有清晰统一的目标、亲密无间的团队协作，团队成员各司其职，在舒适的心理状态下（良好的人际关系），同仇敌忾，为同一目标不懈努力。这一前提的关键是经过不断探索和磨合，找到适合团队的项目管理最佳实践，并雷打不动地执行最佳实践。由此，团队将越来越好，越来越亲密无间。
下面总结梳理一下我自己跟踪项目的最佳实践。正是因为这个最佳实践，让团队中的每个人每天在逗逼开心中，完成着几乎不可能的进度。期望也对大家有帮助：
一、项目立项阶段：一致认同的产品定位
虽然此阶段还不涉及写代码等实现层面的工作，但对产品定位的清晰认识和认同，是帮助团队成员在后期实现中寻找成就感、理解细节需求的必要条件。
若仅在后期实现时，开发人员才接触到产品，他们一定会被淹没在细节需求和如何实现需求中，最后演变成，他们自己不知道自己做的是个神马东西。如此，成就感何来？当他们理解了产品的定位，一开始就知道大概的业务，对他们后期理解需求，绝对有很大的帮助，且能够站在技术实现的角度给产品设计提出很好的建议。如此，何乐而不为？
此阶段产品人员一般要输出MRD BRD 竞品分析等文档，但对项目组来说，一份精简的产品规划书就够了。具体有哪些内容，可参考上一篇文章《如何用一份产品规划书代替BRD、MRD
竞品分析？》或下图：
通过项目组内评审讨论，达成共识的产品规划书，是此阶段的最终产物。
二. 项目实施阶段：有条不紊的迭代步伐
1. 清晰的迭代流程
清晰的迭代流程，标准的迭代周期帮助团队成员掌握工作的步伐，保证大家在同一频道上。
每次版本迭代逃不掉的流程有：
每一阶段都有特定的参与人和输出产物：
（1）如何进行版本规划以确定需求范围？
产品经理根据自己的判断，以一个月为周期（视情况而定，不同公司、团队，
长度不同），从backlog中挑出若干个优先级高的需求，形成细化版的版本需求列表。版本需求列表与backlog的区别在于，产品对每个需求的细节逻辑经过了更深入的细化和描述，能够很清楚地告诉团队，这个功能是做什么的，业务逻辑是怎样的，方便团队判断技术难度和研发周期。
产品出具此列表后，召集团队进行评审。评审过程中，一般会砍掉或替换一些需求。经过评审后，团队就此次迭代的目标和范围有了清晰的认识和共识。除非非常极端的情况，达成共识的需求列表不轻易做变更。
（2）如何细化需求？
迭代范围确定后，进入需求细化、PRD设计阶段。
细化需求的步骤是什么？应该注意的点有哪些？可参考文章《当我们接到一个新需求点时，应遵循的需求分析步骤有哪些？》。不再赘述。
（3）如何管控研发阶段？
进入研发阶段后，工作的大头从产品转向研发。此时管控的对象从自己转向了别人。最好的管控就是积极参与到他们的工作中。为此，产品应积极参与到研发工作中，主要有两点：一是，积极帮助研发人员理解需求，有求必应，帮助研发解决一切影响他们工作的外部因素（此时像一个“家庭管家”的角色）；二是，帮助研发人员走查测试功能点，这不仅帮助研发节省时间和精力，也将大部分问题扼杀在摇篮里，减轻后期测试的风险。
（4）如何管控测试工作？
测试工作有两部分重要的工作内容：一是编写测试用例，通常需求确定提交研发后，测试人员开始进行此项工作。此时，产品要积极帮助测试人员理解需求，保证用例的全面准确性。要知道，高质量的测试用例，是高质量测试结果的前提。若迭代时间允许，团队可就编写完的测试用例进行评审，评审的过程又是项目组理解需求，发现问题的一次机会。第二项主要的测试工作就是，对版本功能进行测试验收，并出具测试报告。在研发人员提交测试人员前，产品应先走查主流程是否走通。只有主流程通常后，才可正式提测。
（5）如何组织内部测试？
测试完成后，测试人员出具正式测试报告。产品根据测试报告，判定是否可上线（通常结果都是YES，因为影响上线的大bug应在早期就发现并解决，不可能留到最后才发现）。若需要组织内部测试，则先更新内测环境，并通知安排相关部门进行内测。这一步骤是可选的，如此次迭代属于技术上的化造，则无需内测。
（6）如何进行上线验收？
内测结束后，重要的bug修修补补后，即可上线正式部署，部署后产品需第一时间在正式环境走查。此步骤必不可少，产品千万不可偷懒，认为测试都测过了，不用走查。走查的目的是，避免因部署系统时，参数配置错误导致的bug。这些bug在测试时，无法覆盖。
（7）如何对外发布？
验收无问题后，功能就算正式上线，要面向用户使用了。此时需要产品给运营、市场等外部干系人正式发出发布说明。说明一般交代此次更新的功能是什么？有什么注意事项等。
2. 轻巧灵活的站会
同步信息是保证大家齐力同心目标一致的前提。站会无疑是很有效的信息同步方式。
（1）组织者
由产品经理把控和组织
（2）频率
至少两天一次。若觉得有必要，如每天都有新功能完成（这可是很重要的节点和信息呢），可一天一次。
（3）长度
时间长度应掌控在十五分钟以内，最长不要超过20分钟，否则，就丧失了效率。我一般控制在十分钟内。
（4）时间
一般为早上上班十五分钟后或晚上快下班前，不建议选择一天中的中间时刻。
（5）主题
主题有三个，即昨日进展、今日安排、问题障碍。
昨日进展指每个人昨日任务的完成情况，如XX功能已做完；XX功能完成40%等。
今日安排指每个人今日要做的任务有哪些？通常是大功能的拆分，由技术负责人进行并分派给各个研发负责。
问题障碍指每个人在完成任务时遇到的问题 或项目组遇到的外部影响因素。
这三个主题帮助项目组成员了解其他人的工作情况，也帮每个人了解项目的状况。对问题和障碍，若需要群策群力，则大家一起讨论解决；若只是小范围的问题，则进行点对点的沟通解决；若涉及到外部影响因素，则产品要积极进行推进和解决。
（6）决议
有会议就应该有决议。此决议可用于领带汇报，也可同步到项目组交流群。每次站会开完后，产品话几分钟时间输出总结：
应注意， 站会不是大家向项目主管汇报工作的形式，而是项目组内相互同步信息的信息交换机制，产品经理作为组织者，要做好气氛的调节。比如一句逗逼的话语和表情结束会议，也开启了小伙伴们一天的美好心情。
3. 实时更新的Task Board
任务墙是很常规的任务跟踪方式。网络上有很多此方法的解说，每个人在使用中都会创新和寻找适合自己的方式。我的做法是：
买一张白板，放在项目组座位范围内。买一些便利贴用来写任务。
横轴为任务状态：todo（已分配在手上，还没开始着手做的）、doing（正在做的）、testing（已完成可提交测试的）、done（已测试完成可上线的）。纵轴为姓名：开发、产品、前端、UI
等所有项目组成员。
每个人每天根据情况更新便利贴内容，并贴在相应的位置。
通常站会和Task Borad结合使用。站会时大家围着白板讨论。
诚然，项目性质和团队大小等因素不同，流程和操作方式也不尽相同。比如toB项目跟toC项目，迭代流程会有较大差异。
除标准的流程和操作外，在日常的沟通工作中，或许应时刻谨记：
（1）多问观点背后的原因
当与开发、UI观点不一致时，先不要判断谁是谁非。仔细聆听他人观点背后的原因、他为什么觉得应该是这样？由此，可相互补充，使得方案更加完善。且在沟通的过程中，能够帮助自己了解到开发、设计方面的知识，是很好的补充自己知识盲区的方式。
（2）荣辱与共，相互扶持
应该知道，同一项目组是荣辱与共，不问谁是谁非，只关注团队共同的成果的。外界对每个人成果的评价，也是建立在团队成果的基础上。因此团队成员之间应该是相互扶持，共同解决项目遇到的任何问题，而不是干产品的，需求完了就没自己什么事了；开发做开发的，做不完是他们的错。绝不是这样的。
以达到团队目标为基准，提高团队工作效率的方式方法就是最好的管理。营造轻松快乐的工作环境，让团队在舒适的状态下高效运转的方式方法就是最好的管理。 |
