从立项到实施进行项目管理的具体操作有哪些Word文件下载.docx

从立项到实施进行项目管理的具体操作有哪些Word文件下载.docx

《从立项到实施进行项目管理的具体操作有哪些Word文件下载.docx》由会员分享，可在线阅读，更多相关《从立项到实施进行项目管理的具体操作有哪些Word文件下载.docx（7页珍藏版）》请在冰豆网上搜索。

当他们理解了产品的定位，一开始就知道大概的业务，对他们后期理解需求，绝对有很大的帮助，且能够站在技术实现的角度给产品设计提出很好的建议。

如此，何乐而不为？

此阶段产品人员一般要输出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.实时更新的TaskBoard

任务墙是很常规的任务跟踪方式。

网络上有很多此方法的解说，每个人在使用中都会创新和寻找适合自己的方式。

我的做法是：

买一张白板，放在项目组座位范围内。

买一些便利贴用来写任务。

横轴为任务状态：

todo（已分配在手上，还没开始着手做的）、doing（正在做的）、testing（已完成可提交测试的）、done（已测试完成可上线的）。

纵轴为姓名：

开发、产品、前端、UI等所有项目组成员。

每个人每天根据情况更新便利贴内容，并贴在相应的位置。

通常站会和TaskBorad结合使用。

站会时大家围着白板讨论。

诚然，项目性质和团队大小等因素不同，流程和操作方式也不尽相同。

比如toB项目跟toC项目，迭代流程会有较大差异。

除标准的流程和操作外，在日常的沟通工作中，或许应时刻谨记：

（1）多问观点背后的原因

当与开发、UI观点不一致时，先不要判断谁是谁非。

仔细聆听他人观点背后的原因、他为什么觉得应该是这样？

由此，可相互补充，使得方案更加完善。

且在沟通的过程中，能够帮助自己了解到开发、设计方面的知识，是很好的补充自己知识盲区的方式。

（2）荣辱与共，相互扶持

应该知道，同一项目组是荣辱与共，不问谁是谁非，只关注团队共同的成果的。

外界对每个人成果的评价，也是建立在团队成果的基础上。

因此团队成员之间应该是相互扶持，共同解决项目遇到的任何问题，而不是干产品的，需求完了就没自己什么事了；

开发做开发的，做不完是他们的错。

绝不是这样的。

以达到团队目标为基准，提高团队工作效率的方式方法就是最好的管理。

营造轻松快乐的工作环境，让团队在舒适的状态下高效运转的方式方法就是最好的管理。

@小麻雀 

。

题图来自Pexels，基于CC0协议