说起周会，可能大多数的团队，都在以流水账的形式汇报自己的工作：A做了什么、B做了什么……以此类推。如果有特殊的情况，则简单说一下，具体的方案也要等到会后讨论了。周报也是类似，我们越来越强调周报要“简单”、“简短”，背后也是不希望再以流水账的形式说自己做了什么，久而久之，不仅写的人疲惫，看的人也没什么兴趣在周报上面了，只会复制粘贴一下重点，然后继续发团队周报。

这其实是一个不太好的趋势，那就是团队的工作越来越业务化了，每个人都在从事自己的事情，自然就谈不上团队中的“横向互动”。对于技术团队来说，尤其是做数据的技术团队，如果越来越没有技术的感觉，那么不仅周会周报流于形式，技术人员的成长性和发展性，也很难继续搞下去。

周会和周报的目的，其实在于技术上的协同：技术风险、最新行业情况、CodeReview、干货分享等等。其实如果换个形式，让大家自由讲述工作中的困惑，或者是一些未来发展的探讨，那么气氛可能立刻就不一样了。周会和周报有必要吗？肯定是有的，但不定期的技术分享&自我批评，提醒团队成员改进不合理的地方，营造开诚布公、透明的团队氛围，才是周会周报形式的核心。

关于团队协作

团队协作中，最怕的是“将就”。“将就”对技术团队，尤其是数据技术团队来说，是一种非常不利于成长和发展的事情。很难想象一个没有技术追求的团队，能开发出一个健壮的、可维护性好、可扩展性好的数据模型。久而久之，曾经埋下的坑，都要一个一个填上，团队的发展速度，在泥泞的“坑”中，只会越走越慢。

很多工作是需要跨团队组织的，我们必须要承认这点；但跨团队组织就一定存在不合理的地方，我们同样需要承认这点。对于一线工程师而言，团队协作的难点是最清楚的，必须要鼓励大家提出解决问题的方案，简单写写PRD也好、写一段文字描述也罢，总之要把自己的想法说清楚。大部分情况下，一线工程师如果能说清楚的事情，推广起来也就不那么难了。如果方案合理可落地，那么剩下的工作就需要交给主管去协调，或者是开发资源遇到了瓶颈，也需要主管去协调。如果一堆大头兵在相互协调资源，很难想象这个团队会解决什么实质性的问题。

关于风险管理

最近公司一直在提倡Leader来写代码，虽然评价不一，但确实在某种程度上反映了Leader有些脱离技术的现实。因为很多时候，仅仅协调资源是不够的，能够深入到系统中、深入到技术细节中，带来技术上实实在在改变的Leader，同样非常重要。

风险管理，就立足如此。当前部门的技术栈如何、开发-线上流程有无问题、数据质量监控做的怎么样、出了问题能不能及时定位和查清楚原因？方方面面的情况，非常考验一个Leader的风险意识，以及团队责任心。

什么样的团队是好的团队？有很强凝聚力，目标一致，每个人都有较高积极性投入工作，能够在分工中发挥各自优势和潜力，这就是好的团队。而未雨绸缪、提前识别项目中的技术风险，协调研发资源投入项目，及时消除技术风险，这就是好的风险管理动作。

关于文档撰写

业务做的久了，很多同学就非常排斥写文档了，因为这只会拖慢工作的速度，影响自己的产出，这很现实。小团队可以这样，但人数一旦多了起来，通过口口相传，或者是定期的培训，就已经不足以快速的共享和传播知识了。而在每个项目结束后，及时把工作内容沉淀到文档上，或者是公共平台上，就显得非常有必要。

并不一定说这是强制的工作，只能提倡把文档沉淀的时间也加入到项目排期中。对于管理者，可以随时了解技术和项目的细节，补足宏观思考的漏洞；对于开发者，能够快速了解项目的背景、过程、风险及应对。“一个人很强”，只代表了个人的战斗力；“整个团队很强”，才是真的强。

关于价值观和沟通

阿里总是在各种场合强调价值观，不少人有负面的看法，但价值观的本意，是传达一种“建国理念”。很多非阿里人，来到阿里后，通常会有一种非常不适应的感觉，似乎一件事情，从头到尾，都要自己负责，非常的“不专业”。其实，对于一个公司而言，做大了，内部的管理，就是一定是个不小的问题。对于价值观产生比较负面看法，也是站在行业通识的角度上进行评价，而非深入到企业发展的核心。

价值观的本意，是在传达一种“建国理念”，阿里是一家市场化思路主导的公司，而非计划经济主导。在对内的管理上，提倡员工激发主观能动性，通过个人的能力，来寻找更多志同道合的人，来做一些有价值的事情。换句话说，虽然我们在阿里这家大公司里，但我们的部门，本质上仍是一个创业部门，阿里公司本身，就是一个封闭的小市场。

在市场化的创业环境中，沟通、干练，非常重要，所以要以价值观的形式传达下去。

很多工程师被提拔到管理岗后，依然喜欢撸起袖子自己干，而不是指导员工解决问题，其实本质就是给自己留退路：干不好管理，还可以回来做一线工程师。但如果学不会放手，就学不会新的技能：技术前瞻性和技术广度，很快你自己就会成为团队的天花板。有时候“背水一战”是对管理者的最好的鞭策。

关于CR和故障

作为技术团队，代码写的好不好，风格是不是统一了起来，注释是否完整，CR机制是否完善，故障管理是否畅通，直接决定了我们的工作效率。由于很多细节工作交给了一线员工，所以管理者可能没有办法了解每一个技术细节，因此需要经常和员工们进行沟通，指导写代码的风格，但是这里要强调是指导，而不是命令和安排。

CR和故障管理，看起来是孤立的工作，业务压力大的时候，往往成为累赘。但是这个过程不走，就无法真的掌握一线代码的运行情况，给未来的维护，埋下种种多的坑。

|0xFF 管理从来都不是一件比写代码简单的事

是的，管理从来都不是一件比写代码简单的事。

很多人，能力很强，做事也非常棒，但到了晋升的时候，往往被卡住，认为组织对自己不公平。但如果看晋升的规则，大体就是两点：技术能力可以跨部门复用，或者是能够领导部门内的重点项目。再总结一下，就是你要能把自己的能力推广给其他人，而不仅仅是自己强。

把合适的人安排在合适的位置，公司的发展因人成事，“授之以鱼不如授之以渔”。

管理也是一种学问：如何面对负面情绪、如何调动团队氛围、如何指导部门技术发展、如何为部门寻找更多的资源支持…… 归根结底，就是如何带领部门走的更远。就像写代码一样，如果不是从小事一点一滴的积累，如果不是夜夜反思自己刻苦读书，如果不是经常寻找同行交流内心的困扰，如果不是经过实战从而“知行合一”的话，晋升的一点小问题，终会变成职业生涯的大事情。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！

作为产品经理项目管理是很重要的一个能力，互联网行业有的公司即使有专门的项目经理，大多项目经理主要是组织会议，协调资源，在项目过程中很难关注到细节，所以作为产品经理做好项目管理是必备的一个技能

一、引言

项目组的成员一般是临时虚拟小组，小组成员之间一般没有上下级关系，作为产品经理如何利用有限的资源，有限的时间内完成需求的上线。这考验产品经理的组织协调能力，沟通能力等。

产品经理与项目经理的区别：

项目经理是对具体的某个项目负责，传统行业和互联网行业的项目经理职责也不相同，互联网行业的项目经理大多是协调资源，组织会议，不对具体的需求负责。

但传统行业的项目经理权利更多些，会对具体的项目需求跟进，比如浪潮的项目经理，因为他们的产品是根据客户需求定制化的，所以要有专门项目经理来跟进从客户需求到落地。

像B端行业有的公司刚起步，就是由项目经理来跟进客户完成一个case，慢慢产品化以后，才会有产品经理来将项目产品化。

通俗一点说，项目是根据某个客户专门定制，产品是所有的客户都用一个产品，一般不会给定制。

传统与互联网行业的项目区别：

项目的开发流程一般包含项目评审、项目立项，项目排期，项目跟进，项目上线等流程。

传统公司项目的周期一般会比较长，短的项目3个月，半年，更长的项目有1年，2年….所以传统行业的项目管理会有专门的项目经理负责，产品经理一般仅负责将需求传递清楚就可以，项目中遇到的问题都会找项目经理协调解决。

但互联网行业的项目经理大多是产品经理兼顾，所以作为互联网的产品经理一定要学习软件工程相关的知识，了解软件开发流程，这样在项目过程中才能更好的来掌舵。

互联网行业的项目一般周期较短，每周、甚至每天都会有上线。所以一般的团队都会采取敏捷开发模式，每天都会开站例会，了解项目进度以及遇到的问题，产品经理需要快速响应协调项目中遇到的问题。

二、具备的能力

在项目管理过程，产品经理需要具备什么的能力呢？

1、需求掌控力

当资源有限不能满足所有需求时，需要我们确认需求的优先级，先做哪个功能模块，哪个功能可以后续再做，产品经理就是需求的掌舵者，需要我们有能力和经验来控制需求。

同时需要了解开发的预估工作量是否合理，有的需求可能1天就搞定的，开发需要2天时间，所以产品经理要了解技术相关的知识，这样也会对开发给的工期有一个判断。

2、沟通协调能力

项目开展需要开发、测试、UI、运维等不同职能的同事共同合作，产品经理是项目的发起者，对外沟通协调的活肯定是产品经理负责，高效的沟通能使事情做到事半功倍。

3、风险评估能力

某个功能无法实现或者实现以后不能达到预期，项目开发时有技术同事请假不能如期上线……这些都需要产品经理想到备选方案，如果不能如期上线会有什么影响， 是否需要提前预警，这都需要产品经理提前想到并做出相应对策。

4、时间管理能力

项目中的时间管理与个人的时间管理相比还是有难度的，作为项目的推动人需要及时了解项目进度情况。可以采用每天开站例会的形式，项目所有的小伙伴都参加，遇到的问题，需要协调的资源都能够及时的暴露出来。所以作为产品经理不但要管理好自己的时间，也要为整个项目做好时间管理。

5、自我驱动能力

我们是需求的创造者，团队中所有的人，包括领导都是帮助我们实现需求落地的资源，所以一定要主动去了解项目情况，当前团队中小伙伴遇到什么问题，主动去解决，需要跨部门协调的事情尽快去协调，不要因为我们的问题影响项目进度。

三、需求宣讲

需求准备好了，接下来就要召集项目组的成员进行需求宣讲了，需求宣讲阶段都需要做什么注意什么呢？

1、提前预定会议室

需求宣讲前我们也需要做好准备工作，比如有的公司会议室资源很紧张，需要我们提前预定会议室，根据人数来预定合适的会议室。避免大家都准备好听需求了，但还没有会议室的尴尬场面。

2、提前发邮件

对于重要的需求，若参加的人比较多，特别是如果有领导需要参加，提前定好会议室以后再发一封邮件。邮件中可以将准备好的原型或文档发给大家，让大家提前了解需求的情况，不会因为不了解需求在会上浪费时间，同时邮件提醒也能够让大家内心更重视这次会议。

3、需求宣讲

正式宣讲需求前需要先介绍一下需求的背景，让大家了解为什么要做这个需求，能够带来什么效果。可以画一个业务流程图或数据流程图，能够很清晰了解业务的流程，也方便大家提问题。

因为听需求的小伙伴大多是技术和测试同学，他们的思维很严谨，提出的问题有可能我们没有想到。但是我们不要有抵抗心理，他们也是在帮助我们将需求完善，所以要耐心的接受，若会上没有好的方案，可以会后再思考一下，将需求进行细化。

四、需求排期

因为要涉及多个职能部门的合作，一般宣讲会上不会给出排期，技术一般是要分析技术的实现方案后再评估工期，而测试依赖技术的提测时间，所以需要会后与他们再沟通具体的项目排期。

1、全面：需要注意的是要将每个角色需要的时间都计算在内，比如UI的时间，因为前端开发依赖于UI设计稿，所以作为产品经理要将每个角色做的事情理清，不要因为落了某个角色的排期而影响到整个项目。

若项目比较复杂，有多个功能模块，需要为大家梳理先做哪个功能。

2、小步快跑：可以选择重点并且比较独立的功能模块先开发，开发完一个功能模块就可以提交测试，这样能够项目小步快跑。

不要一个项目所有的功能全部开发完再提测，不但浪费资源并且工作效率很低。

3、排期工具：若项目比较复杂，开发周期长，可以使用甘特图来跟进项目进度，能够全局的了解每个节点使用的时间，同时也方便给领导汇报。

4、发送邮件：不要以大家口头为主，特别是涉及的项目成员比较多的时候，很难记得各个时间点。需要我们确认完排期后发邮件给项目组成员，让大家知晓什么时间点交付什么，同时也作为项目跟进的一个依据，领导也会清楚了解项目情况。

五、项目跟进

确定了排期，大家可以开始动工了，一般的项目的流程包含UI设计，确定接口数量、开发接口、开发功能、用例评审、技术联调、项目提测、产品验收、上线等几个 阶段，各个阶段进展情况如何、遇到什么问题等都需要产品经理实时关注。此时产品经理就是桥梁作用，及时解决项目中遇到的问题，为大家提供支持。

1、项目例会

互联网公司一般都采用SCRUM敏捷开发模式，将需求拆解不同的子任务，每个子任务指定负责人及时间。每天固定时间召开项目站例会，这样能够实时了解项目进展情况，当天遇到的问题当天解决，避免因为信息不对称造成项目延期。

项目站例会注意几点：

1、所有项目组成员参加：不论级别高低，所有项目组成员都要参加，因为一个项目是由大家共同完成，缺少哪一环节都完成不了，每个成员都需要了解当前项目的进度情况。这样信息才能了解的更全面，若有的小伙伴不来参加会议，有可能就有问题没有暴露出来，所以参会的人一定要全面。

2、固定时间点：一般都是在早晨就开始例会，了解当天的任务情况。确定一个固定时间点，不要今天是早晨开，明天是下午开，平时大家也比较忙，这样没有固定的时间，很难人会召集全。所以一定要确定一个固定的时间，这样也方便大家预留出会议时间。

3、时间控制在15分钟以内：例会时若有问题需要再讨论，可以组织相关人单独讨论，不要因为部分人有的问题耽误大家时间。因为每天都会开，都是当天遇到的问题，所以要高效，会议时间最好控制在15分钟以内。

目标就是高效解决当天遇到的问题,能一起沟通的事情就不要单独沟通。比如一个需求的改动，会涉及UI、测试都需要改，而不是只和技术讲就可以了。

2、UI设计阶段

1、提前沟通设计风格

在与UI设计师沟通需求时，将原型提供给UI设计师外，还需要将对设计页面的要求或者可以参考的素材给到设计师。

提前沟通好想要的页面风格，如果你不说想要什么风格，UI设计师会根据自己的喜好来设计页面，有可能和你想要的偏差比较大。所以一定要提前沟通风格，不要等设计完成了再提。

2、确定排期

UI设计师确定工期一般是根据页面的多少来确定 ，所以与UI设计师沟通前需要单独将需要设计的页面准备好。与开发看的原型不太一样，若有一些页面仅是文案不同，但页面布局相同就不要再提交给UI再设计了。

与UI确定排期时一定要将修改的时间预留出来。一般UI初稿完成后，需要产品经理与部门的同事或业务方来确认初稿。每个人对UI风格的看法也会不同，需要将不同人的建议综合考虑一下，最终给UI输出修改建议，这个过程是需要时间的，所以要将这个时间预留出来。

3、文案确定

页面中的文案最好提前确定，如运营活动页面中的文案是需要产品经理与运营确认的，提前与运营确认相关页面的文案，保证页面中的文案是准确的。若文案不准确，开发时有可能以UI给出的文案来开发，还得再二次修改。

虽然改文案对于开发比较容易，但还得再和测试沟通，这样就增加了沟通成本，所以能够提前确定文案在提交给UI时就要明确。

4、实时跟进

若设计的页面比较多时，可以在间隔一段时间与UI设计师了解一下进度，看一看页面设计的风格是否满意。

若不满意可以提前沟通，不要等最后全部交付的时候再提出修改，不但浪费时间，设计师对你工作的能力也会有看法。所以一些小细节处理好会省去许多麻烦。

3、确认接口

一个新的项目包含功能模块比较多，逻辑比较复杂，需要产品经理与技术共同沟通接口的具体情况。沟通的时候需要前端技术与后端技术都参与，梳理每一个功能时是否需要新的接口，老的接口是否能满足需求。

有的小伙伴可能会有疑问，确认接口的事技术之间明确就可以了，为什么还要产品经理参加呢？

1、了解工作量：通过接口数量能够大概知道工作的强度如何 。

2、了解底层逻辑：通过了解接口情况方便我们理解技术的底层逻辑，后续开发过程跟进会更轻松。

3、解答技术问题：对于一个新功能技术有些业务逻辑可能不确定，数据不知如何取值，这需要我们来解答。

4、跨部门沟通：有的接口是需要跨部门协调解决的，需要我们去沟通解决。

基于以上几点，在确定接口范围的时候尽量与开发共同确认，只有更清楚技术开发的逻辑跟进项目才会更加游刃有余。

4、用例评审

用例评审工作主要是由测试工程师组织，在项目开始开发，未提测之前测试工程师需要编写测试用例，为测试做准备。

用例评审是项目开发节点中一项重要的工作，能够让技术、测试达成共识。测试时确认BUG的依据就是测试用例，所以避免在测试过程中因bug确认产生分歧，在测试用例准备阶段一定要全面，并且要与技术达成一致。

在用例评审时会有需求拿不准的情况，产品经理需要为测试、技术同学答疑，使大家对需求疑问点达到共识。这样减少因沟通不明确导致项目延期。

5、项目提测

1、提前检查功能流程

项目终于开发完成进入提测阶段了，此时项目已经完成了70%，产品经理在提测前需要与开发梳理一遍流程，是否与需求预期相符。

因为有的公司开发流程比较严格，若提测的功能与预期功能不符，测试可以直接打回。如果发生这样的情况属于开发事故，可能会影响到开发的KPI。

开发工程师的技术水平和对业务的理解能力不同，有的技术会比较负责任，开发过程中及时与产品经理沟通开发情况。但有的技术开发过程中一直很安静，有问题还不好意思问。

所以需要产品经理主动去了解，在提测前和技术检查一遍流程，避免提测以后无法测试的情况。

2、UI验收

若是前端的功能，前端开发工程师开发完以后，不要忘记UI验收环节。每家公司UI验收流程都不同，规模大一点的公司，UI同事专门负责某个业务，流程也相对完善一些，当前端开发完以后UI工程师就会主动跟进UI效果。

但有的公司UI设计师要同时负责很多的业务，没有时间验收，但作为产品经理一定要主动去PUSH这件事。

80%前端开发完以后与UI效果图不符，比如字体、字号、颜色与效果图有偏差，虽然这是细节问题，不修改也影响不大，但这样的意识是需要产品经理来协助大家来建立的。

只有项目各个环节都做到位，项目的结果才会更好，不要忽略每一处细节。

6、产品验收

测试结束后，上线前产品一定要有验收环节，这次验收不仅产品经理验收，更重要的是需求提出方来验收。

需求预期的情况与最后完成的效果可能会有差距，通过验收能够让业务方了解产品实现情况。若有问题随时改，不要等到上线后与预期的效果差距太大而产生不愉快。所以在项目过程中也需要及时与需求方沟通和汇报项目进展情况的，让大家都要心里有个准备。

需求方验收后可能会提出问题，若是比较好优化的协调技术及时调整，若有的问题实现起来困难会影响工期，与业务方沟通可以放在下一个版本迭代。

双方达成一致后准备上线工作。

六、上线前准备

1、准备上线素材

产品的类型不同，上线前的准备工作也有所不同。

像APP类型产品，需要准备上传应用市场审核的资料，如版本说明、应用商店素材图、logo等。每个平台应用商店的账号、密码等都需要提前准备。

提前让技术准备好安装包，各个渠道的包都需要提供，以方便上传应用市场。

2、准备培训材料：

针对于B端产品，除了版本说明外，因为B端系统操作往往会比较复杂，需要准备好相关的操作文档，有的还需要给用户培训，有的公司有专门培训部门，有的公司是需要产品经理给用户培训的。

3、发上线邮件

上线前一定要给需求提出方、领导、项目组成员、协同部门发上线提醒邮件，邮件中需要包含本次上线的内容，操作说明，以及感谢大家的配合。

发邮件能够让大家了解产品上线的功能，同时也感谢项目组成员的辛苦付出，下一次项目大家会更加配合。

七、复盘总结

项目上线后，除了跟进项目数据外，还要找合适时间召集项目组成员开一个复盘总结会，在整个项目过程中哪里出问题或做的不够完美，可以在会上沟通。复盘会议注意事项有哪些呢？

1、不要开成批斗会

复盘是为了总结项目中的不足与优点，接下来的项目如何做会更好，而不是批斗会，比如因为某个开发请假导致项目没有按时上线，虽然是个人的问题，但不要针对个人，而是从流程上去分析如何避免类似情况。

2、提前准备

往往复盘会开的时间会比较久，原因是边界感不清晰，说到一个问题时可能就会发散。这需要主持会议的人提前做准备。可以准备一个PPT，将项目重要节点进行回顾，将问题做总结，这样会议目标更清晰有序，同时也能够控制好会议时间。

3、总结邮件

开完复盘会以后，将问题总结梳理，将大家一致达成的结果发出来，比如需要如何优化项目流程，可以都在邮件中体现出来，这样具有仪式感的同时，也会按照结论来执行。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！

本文是一个系列文，主要是将我自己目前产品工作中踩过的坑和遇到的困难进行反思和总结，然后将其输出为一个工作规范。同时也因为我现在负责公司产品组管理的工作，制定相关的规范和准则，一来可以约束自己，形成良好的工作方式和流程；二来可以约束团队，方便新人工作和成长更加具有科学性和条理性。初步定的内容和模块大概有三个大模块，九个 小细项，希望我能坚持写完。

1、多需求、多项目管理

一般来说以单独的系统作为一个项目，每个产品可能或多或少会接触两个以上的系统，也就是要同时处理多个项目，对多个项目进行管理。

• 项目启动：为什么要做这个事情？动机是什么？目的是什么？需要准备什么内容？
• 项目规划：如何实施这个项目？这个问题包含了多个子问题？项目团队要做什么？需要什么样的资源？什么时候开始做？谁来做？什么地点做？等等……
• 项目执行与监控：执行之前的计划，根据分解的目标来进行逐步完成，对执行的情况进行控制，控制的过程就是围绕着质量，成本和时间来进行的。
• 项目收尾：最大限度的积累项目的经验，总结教训，为下一次的项目争取更多的资源并做好准备。

从项目管理的生命周期入手，产品在项目启动的环节要注意需求的收集与分析，需要给出足够的理由和证据去调动资源开发某个需求，此处要注意一些特殊化的定制需求，有时候往往是这类看似可拒绝，又不可拒绝的需求总是会让团队陷入一些困境。尽量从一些行业通用标准和一些用户信息反馈去落实，该不该做，哪怕是未来可能会翻篇也要做的就在项目启动前面注明未来的改动，让大家提前有一些心理准备和缓冲。

项目规划这一块尽量按照敏捷的思想去实践，往往很多时候项目延期并不直接是产品的问题，但是良好的规划和用户故事的拆解，会让团队对项目的进度和计划有更细致和具象的了解，有利于让大家了解具体要工作的内容和要花费的时间。此处除了要求严格用TAPD实行敏捷迭代的要求之外，也推荐大家去看看WBS相关的内容。

WBS是指将项目产出物（或项目目标）逐层细分为更小、更易管理的子项目或项目要素，直到分解出的要素非常详尽，能够支持下一步的项目活动分析与定义为止的一种方法。

项目的执行和监控就是日常提到的一些产品跟进和信息补充，这一块比较容易出问题的就是需求文档或者描述的调整没有及时同步和更新，导致开发做了新的东西（私下沟通的）但是需求文档中还是旧的描述，到时候测试进行验收的时候容易出现一些矛盾。所以要么就及时修改需求文档的东西，要么就是联合开发和测试一起讲一下变化的东西是什么，当然我依然是建议需要记录相关的变化。

除此之外，项目的跟进还可以体现在“产品亲自验收”，“每日站会”，“及时更新操作手册等文档”，“及时汇报项目风险和难点”，“广播相关进度和内容”等等。

项目的收尾主要就是下面讲到的一些产品发布和上线后要做的东西，在这里如果继续讲有点重复的味道。所以主要就是关注几个词：

• 复盘总结；
• 数据分析；
• 文档梳理；

其实总结下来就是：回顾和记录。回顾就是复盘，记录就是翻出文档，继续完善文档。

2、产品发布

a. 制定发布方案

由于公司采用敏捷开发的模式，产品版本的发布频率较常规的产品发布频率会高很多，但是由于B端业务的复杂性和关联性，建议“少发版本，多合迭代”。

一个迭代会有一些更新内容，可能重要也可能不太重要，但是一个迭代完成了之后都会形成一个提测版本交给测试，测试完成之后就可以对此迭代的需求做一个“已完成”的状态标识，但是却不一定要发正式生产版本。因为生产版本可能涉及或者影响的东西比较多，频繁上生产版本会耽误用户的使用，同时可能会造成一些配置或者数据的问题。

所以，我们合理地结合各方面因素，将几个迭代的内容或者诸多需求合并到一起然后再确认发布正式生产版本，其中的工作则可以概括为：制定发布方案。

制定发布方案并非是指临近要发版本了，然后去制定要怎么发，什么时间发这么简单，而是在需求收集设计过程中结合目前已经在开发的需求，综合考量去制定相关的计划。一般的，发布方案应该考虑或者包括以下内容：

1. 制定上线检查清单，主要是评估产品是否满足上线标准，以及是否有遗漏重要环节，包括以下内容 ：

• 回归测试：这部分一般测试团队会去做并且会给出测试报告，建议各位产品经理在产品自测阶段一定要自己对核心流程、核心功能充分回归测试，确认是否完整可用；
• 时间选择：上线时间的选择很重要，WMS需要考虑到会不会因为发布版本而对实际生产作业影响，一般会挑选仓库上班前或者下班后或者午休时间等发布。而其他系统的发布也要考量到是否会影响到用户的使用，最好制作一份时间表；
• 文案：所有文案是否明确无歧义，并且合规？比如一些词语“账户、帐户， 登录、登陆”的确认，如果有一些系统需要做多语言切换，则需要确认语言的翻译是否准确，是否到位等；
• 相关文档的准备：帮助文档、SOP文档是否完善，新功能的上线会增加用户的学习成本，好的SOP或者帮助文档可以尽快让客户熟悉系统，同时也能为后续岗位变动的同事提供相关的指导；

2. 通知与协作，主要是通知和培训相关干系人，公布相关系统新功能和特性，减少沟通不畅带来的损失。

• 运营团队：SOP文档制作、仓库作业人员的培训是否到位，一般由产品经理与运营团队培训，然后由运营同事进行SOP文档的完善和调整；
• 客服团队：新功能的用法，可能存在的异常情况，以及能解决什么相关的问题等；
• 技术团队：产品发布上线干系人确认，谁来发布版本，谁来验证版本发布是否完成，谁来对出现的意外情况负责，同时是否需要制定紧急应对方案等；
• 其他团队：其他团队如果需要了解系统的更新和内容可以与产品沟通，或者提前联系参与相关的培训即可；

3. 预案和整理，上线前的准备和上线后内容的整理。
产品上线过程存有不成功的风险，针对这种情况，要准备好相关的预案，比如：

• 发布失败怎么处理？
• 大量用户投诉该怎么办？
• 无法访问，导致业务受到影响要怎么办？

发布上线之后，还有这么几件事情需要抓紧去做整理，包括：

• 测试过程中，需求变更了，更新/补充需求文档；
• 针对本次版本未实现的需求、未解决bug的收集；
• 相关文档的整理归档，形成相关的资料库等；

b. 发布你的产品

产品发布环节主要是分为两个大类：一个是规划，一个是执行；规划其实在第一步的时候就讲到了，制定好完整的产品发布方案，有了方案就是有了规划，就可以对自己即将要做的事情进行统筹和管理。

执行则是实际作业中需要去坚决执行的操作，对于发布产品来说，产品经理要做的大概有以下内容：

• 制定好发布方案（前提条件）；
• 确认执行方案中的内容，如果有调整需要进行补充说明；
• 积极主动，跟进相关的进度；

这里以WMS的产品发布上线为例，讲解一下产品经理在发布产品的时候大概要做什么工作。

WMS版本发布上线职能图

WMS的产品使用者是仓库的人员，但是仓库人员往往并不在身边，需要由运营部代为了解系统的更新，所以和运营部沟通，将他们理解为用户。召开这种培训会议和产品版本上线更新的内容有关系，如果一个版本更新的内容较多，需要实际演示讲解才能让用户接受和理解，那么就需要召开这种培训会议；如果一个版本更新的内容较少，而且对基础流程和业务没有什么影响，那么可能只需要提前发邮件通知一下用户即可，无需召开会议。

召开培训会议之后，还需要对会议纪要进行记录和保管，以便公示给更多的人了解。而培训会议的内容可以直接演示，也可以用PPT配合演示，只需要能让受培训者快速知晓更新的内容即可。总结来说，WMS产品的发布，需要做以下几点：

• 确认是否要培训用户，如果要则召开培训会议，如果不要则直接邮件提前告知更新内容和要点；
• 将版本发布的时间，范围等报告出来，确认相关的干系人知晓此事；
• 将本次版本涉及到的更新和调整邮件的形式发送，如果之前进行了培训会议，则此更新和调整内容作为会议纪要一并发出；
• 提前通知开发、测试和运维同事准备相关的代码文件等，按制定的时间进行发布；
• 发布之后，及时通知测试同事进行验证，并且给出验证结果（一般没问题反馈就是没问题）；

其他系统的产品发布和WMS的也是大同小异，制定产品发布方案和计划是首要，其他的只是按流程办事罢了。

产品发布方案和计划主要可以理解为对上线发布做一个自查表清单，清单可以用Excel表的形式，每一次发布就是一个Sheet文件，然后可以截图记录在TAPD中进行归档。

WMS产品发布上线自查表

3、产品上线后

对于C端产品来说，产品上线之后一般会关注一些点击率，增长率还有成交率等等，但是对于B端产品，尤其是我们公司的产品来说，产品上线后的监控、验证，能做的其实并不多的。

如果需要对一些关键信息进行监控、收集及分析，则需要在上线前就制定相关的验收计划，直到上线之后就可以去验证计划是否达到了，否则没有规划和计划也无法做到什么有效的验收。

一般我们可能更多的是针对产品上线之后做一个用户访谈或者用户反馈。通过对几个典型用户的访谈，去了解上线了某个版本之后对Ta们工作的一些提升和改进有哪些，同时还有什么是不够的、还能继续优化。以此来与用户拉近关系，不仅能收集到一些有用的需求，同时还能增强用户对产品的好感，会让人觉得这是一个靠谱的产品经理做出来的靠谱的产品。

除了用户访谈之外，也可以多关注每周测试运维反馈的生产问题报告，看看上线之后，是否以前暴露的一些问题还会出现，同样的，测试运维的同事也可以经常性地做一些用户调查、访谈，因为Ta们也是对产品离得最近的人之一。
除了上述讲到关于产品迭代优化方面的内容，产品经理还要关注一些收尾的细节工作。

例如上线了某个新功能之后，操作手册是否有及时维护，背后的业务逻辑是否有文档记录，其中遗漏的点是否有记录然后规划到下一个迭代或者未来的需求池中，涉及到的改动和调整是否有及时广播和通知到位……

这些都是很琐碎但是却很重要的事情，因为产品从0到1的终点，并不是上线，真正来说，做产品是没有终点的，任何时候都处在过程中。

最后，我建议针对大版本的迭代上线之后，要让产品经理自己输出一个复盘记录，对其中的一些难点，收获，不足之处进行总结，然后与内部同事进行分享。这是快速提高自己产品能力的一个手段之一，同时还能让其他同事更加深入地了解到你所负责的产品是怎么样的，加强产品组内部沟通，也会让产品决策有更广、更全的依据。

复盘记录可以用文字，也可以用PPT，无论是总结能力，还是PPT能力，或者是演讲表达能力，都是需要在日常工作中进行积累的。

没有舞台，就给自己创造舞台；走的人多了，自然会有路；经历的项目多了，自然会成为一个好产品！

后记

这些内容是我之前在公司的WIKI中摘出来的，全部都是当时我自己在工作之余思考和沉淀下来的内容，大概过了一年之后再来看，有点感慨。

一年可以做成很多事，一年也可以做不成很多事。

很早的时候我对产品组管理充满斗志和热血，觉得克己复礼，以身作则就会带来很多积极或者很具有突破性的变革。但是现实似乎并没有想象中的轻松和自然，阻碍有很多，打击也会有很多，至于效果呢，也不能一厢情愿。

逐渐的我开始意识到，计划只是成功的负一楼，而执行也不过就是刚逃离底下看到点阳光，登顶是一次又一次的尝试和打磨，所以不会再为见到一点阳光就欣喜，上升一层就觉得快要触顶。

前路还有很长，晒出这些内容，只是对一年前的自己做一个回顾。现在回头看一下，还是很高兴，因为这条路似乎还没走歪，甚至也走得挺快的。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！