上一篇文章讲诉了如果你想成为一个新手PM该具备哪些基本的技能或者专业知识，那么现在就来讲讲产品经理一些比较宏观上的东西，对于新手，讲到太具体的工具或专业术语是比较难以理解的，所以先从宏观角度来说说。
对于互联网行业来说，产品你可以简单理解为一个解决方案，那么用专业术语来说，它应该是一个满足用户需求的一个可交付成果的软件或服务。
产品是我们项目中重要的一部分，从项目立项开始，就开始着和我们产品息息相关的一切活动存在，那么产品是从什么时候开始的，以及整个产品的生命周期又是怎样的，以下我先列举部分说明
产品的生命周期指的是从产品开始到产品退出市场的整个周期，是由一系列的阶段构成的，我一般会将这个周期分为以下几个阶段(和网上的有区别，个人意见)：
1.初步设计阶段：通俗的说，这个时候的产品很可能连张图都没有，你需要对产品的明确需求及潜在需求形成文档，由上至下将需求分解为模块--功能--工作包，这里有个原则，下一级的需求总和相加应该是等于上一级的需求总和，如果出现偏差，则加以分析是否出现没有涵盖的场景分支或异常情况，对应做出变更。在所有需求明确之后形成对应文档(PRD、BRD、MRD、原型图、竞品分析、行业报告等等各种文档)。
2.研发阶段：这个阶段简单理解为一个开发产品的阶段，就是运用组织内的资源完成一个可交付成果，这个阶段根据不同的开发模式会有不同的区别，最终都是按照事先约定好的需求范围进行开发，最终验收交付。
3.导入阶段：暂时不讲
4.上升阶段：暂时不讲
5.成熟阶段：暂时不讲
6.衰退阶段：暂时不讲
7.退出市场：暂时不讲
3-7的阶段对于新手的PM来说涉及到的面及内容及知识点十分广泛，后面有空再更新，结合实际情况，现在在职的产品经理极少数是走完整个产品生命周期的，而且互联网流动性高，大概两年一跳槽。
初步设计阶段
从项目立项开始，你就必须开始着手最重要的东西--需求收集(当然还会有一些竞品分析、行业报告、各种分析报告等，这里默认产品是符合当前事业环境因素下经过论证的可交付成果或服务)，你应该运用一些合理的方法让你的工作变得更加流畅及条理，提升你的工作效率。
1.识别相关方
第一件事情是识别相关方，就是要明确你的需求是从哪里来的，你要满足哪些人或群体的需求，有多少个相关方会对你需求的范围产生影响，建立一个相关方文档，以便你日后跟踪需求的时候遗忘需求从哪来，在一般中小企业中，需求一般是直接来源于老板、甲方干系人，大的公司一般是来源于N个相关方、用户及项目经理。
2.如何收集需求
对应的相关方已经明确那么接下来就是如何收集的问题，收集需求的时候应该引导相关方表诉合理的需求(需要什么，想要什么，期望什么)，并且记录下来转化为产品需求，分析哪些需求是合理的，哪些需求在整个项目的成本、时间范围内难以实现的，一些不合理异想天开的需求要向相关方说明利害关系，最终把笼统和抽象的需求转化为可理解、可量化的文档，并按一定的逻辑关系进行优先级排序。
3.定义产品的范围
以书面形式对收集的需求进行评估分析，然后传递给必要的相关方，得到最终确认，并以此为准(产品的范围定义不明确会影响到下面任意一项工作)。
4.分解需求
把最终和相关方确认的需求进行分解，把整个产品分解到较小及便于管理的可交付成果，也称工作包。(一般是3-7层)。
5.落实每个工作包
一个工作包可以由多人来完成，但只有一个最终负责人，绩效评估就看该工作包的进度及质量是否与计划匹配，对应挂钩责任人的绩效或奖金。对工作量进行评估，这里可以采取很多方法，用的最多就是凭借以往类似项目的经验(组织过程资产)来进行评估，找出关键路径，同时看看是否有不关联的活动可以进行时间上的优化(注意赶工或快速跟进都会带来一定风险，现在的形势一般工期都很紧不能太理想化)，再和开发校对工期进行适当调整。如果团队资源比较优质及充足，可以使用三点估算法完成工时评估，即：(最悲观工期+4*平均工期+最乐观工期)/6，这样评估出来的工期大概率会在这个值左右两边浮动，对比纯靠经验主义去判断要准确得多，很多产品工作五六年，靠的完全就是经验，并没有一些系统的知识理论去支撑他的观点，所以作为合格的产品经理，你需要多学习一些科学的知识体系，对你的工作及成长有非常大的帮助甚至产生质变。
6.制定开发计划
如果是瀑布型的开发模式则需要对全盘进行计划，如果是敏捷开发模式则把最近两个迭代周期的可交付成果做出具体的规划，对未来的计划点到即可(遵循越远越粗略的原则)，因为敏捷开发关注的是近期的可交付成果，对应输出开发计划文档，建议无论是哪种开发模式，都要严格按照进度进行执行(假如一开始就不按照制定的计划来执行，那么该产品的开发阶段大概率以延期或失败告终)。
7.沟通
如何和你的团队沟通，方式有很多种，包括邮件、项目工具、会议、私聊等等。目的只有一个，清晰阐述你的需求，最好的方式是在每个迭代周期之前进行需求会议(有些时候开发会参与部分需求评审会议)，不理解的当面说清楚，通过图文并茂方式直观展示产品原型交互，再以书面形式把需求文档等文件发送至开发手中，也可以上传到Git或者SVN供开发下载，有些产品经理做得一手好文档，却不愿意或者没有和开发开会交流的习惯，这是非常不科学的，后面带来的问题就是经常对需求产生歧义，然后返工，工期延误，后面连沟通的时间都没有，恶性循环，延期交付是必然的事情。等开发都明白需求了，就可以着手下一个阶段了。
研发阶段
开发产品这个过程当中产品经理需要做的活多且杂，并且具有一定重复性。如果采用瀑布型开发则需要对产品整体进行非常严格的把控，这些都需要在开发之前做好规划，应对可能因为不同风险带来的问题。进度、质量、成本永远是一大难题，一方的改变会影响到另外两个因素(当然你可以是个不负责任的员工，增加公司成本、适量投入更多资源)。结合实际经验，尽量在短周期内对每个工作包的质量进行验证，这样可以提早发现问题，尽早解决，产品经理应该是要以积极的态度去面对问题，而不是采取消极或者睁只眼闭只眼的态度。
1.执行开发及监控
对于开发来说这是执行阶段，对于产品经理来说，这个阶段是执行和监控交替进行着，你需要在开发的交付成果上进行追踪，问题日志和开发进度表几乎是你每天必须更新的两个文件。问题日志主要记录开发人员在开发过程中对需求有哪些不明确或者不理解，以便你可以及时的更新你的相关文档(需求文档、原型图等)，技术问题留给技术经理或主管去处理，你的职责是确保每个需求都在原定的可交付成果上得以实现，而并不是浪费时间和精力在技术问题上(有些从技术转产品的童鞋老是会较劲技术上的问题，本末倒置)。开发进度表是你对进度把控的一个重要工具，你应该对可能产生延期的工作进行预警，告知开发应该采取行动来避免延期，而不是等到最后时刻才来质问开发为什么没完成工作，预防胜于纠正或补救。
2.测试
在这个过程当中，你应该和你的测试人员进行密切沟通，以保证交付成果是按照需求文档定义的需求范围来进行测试，任何质量的偏差，都应该被记录在测试文档当中，测试文档应当每天进行更新供开发人员查看，如果在此时发现问题(如需求不明确未含概情况，异常情况未被说明)，则应当先对问题进行分析评估，然后制定变更方案，如果该方案不影响到最初需求范围基准，则在选择最优解决方案后进行变更，如果该方案对原有需求范围基准会产生影响，则需要通知需求相关方，然后与相关方进行需求评审后再进行变更，如果按照你自己的经验主义进行变更，有可能会带来返工的可能性。
3.交付验收
在测试通过后，你应该把可交付成果移交给你的验收人(客户或老板或项目经理等等相关方)进行验收，并且附上你的产品说明书、测试报告等等文档(视具体情况而定)。
4.结合实际情况分享整个过程当中遇到的一些问题及解决方案
4.1 bug太多，纠正活动时长太长，影响进度
bug分两种，一种是对技术层面带来的Bug，这种与开发本身的职业素养有关，也与技术经理的面试过程有关，应该与技术经理加强沟通，通过培训或其他的方法来对该成员进行辅导，给予一定期限让他提升技术水平，同时建议技术经理是否要改进面试流程，比如机试，这种情况与产品经理没有直接关系，你也不是这个方面的职能经理。另一种bug是因为对需求理解偏差所导致的，这种情况下第一步是先检查你的需求文档，看是否有语句不清晰或者歧义，在确定原因后再和开发进行沟通，然后纠正bug，其实这两种情况第二种是可以通过有效沟通极大的减少发生的概率，从而最大概率增加产品的如期验收。
4.2 工时评估太长，与相关方要求的实际工期期望不符
比如老板要求3个月完成该产品的研发，第4个月初就需要投入市场进行运营或者交付给客户，可是你实际评估的工期是4个月甚至是5个月，那么这个时候需要和相关方进行沟通。第一，要告知相关方，产品研发周期存在客观的一个最短时间(简单点来说组织资源达到一定量之后开发周期不会因增加资源而缩短)。第二，请把你估算工期的所有依据文件及工具方法展现给你的相关方查阅，这些数据必须是经过科学的论证或者工具计算得出的，这就是为什么你需要知识体系去支撑你的原因(你连最基本的估算时间方法都不会，心里虚不虚)，靠经验主义往往是没办法说服客户和老板的，而一旦一堆客观的数据和事实依据放在眼前，相关方自己也会权衡利弊，最终协商达成一致的工期。第三种就是最坏的方法了，和相关方一起查阅你的需求范围文档，看看是否有需求范围可以进行裁剪的，对应进行裁剪达到缩短工期的目的。
4.3 开发抱怨工作量太多，干活不给力
排除开发人员本身的技术水平后，你会发现多数是因为对工作量错误评估或对需求理解不透彻而造成的，开发加班多，满负荷甚至超负荷状态工作，自然抱怨多，从源头上去解决这个问题，运用沟通管理及科学的评估方法就可以极大概率去避免这种问题的发生(风险是一直存在的，只能尽量避免)
4.4 相关方临时的需求变更(改动或增加)
现实工作中，这种情况还是蛮多的，这种情况一旦发生，不用慌，凡事总有方法解决。首先是分析评估这个需求是否合理。
1)如果需求不合理，说明理由并拒绝变更
2)如果需求合理，请先判断该需求是否会对需求范围基准产生影响，如果不影响就开始评估工作量，输出变更需求文档要求开发执行，最后以书面告知相关方有可能会影响原计划中的进度
2.1)如果是影响到需求范围基准的，请先召集所有相关方参加需求评审会对该变更进行评估，在达成一致意见之后，制定可以满足该需求的开发计划，并书面告知所有相关方该变更会影响到原计划进度，然后更新输出你的开发进度表及需求文档，再执行开发。
3)如果该需求很紧急(或因为产品最初设计缺陷带来的需求缺失)，会影响到生产环境使用情况，产品经理应该迅速制定临时解决方案，并命令开发立即执行变更，测试通过后立即更新当前产品，然后书面通知所有相关方产品在某个时间点进行了一次紧急的变更，事后更新对应的文档，然后对临时变更的部分需求进行风险评估。
4.5 团队内有人员带着火药味来质疑需求的合理性
经常会看到开发和产品经理吵架(打架也有)的问题，其实一部分是沟通带来的，一部分是产品经理本身不具备良好的职业素养所造成的。沟通上述已经提过了，按照沟通的方法来解决就可以。而关于职业素养，解决冲突是产品经理必须掌握的，一般遇到和团队成员冲突，首先是保持心平静和的心态，然后你拿出当时做需求评审的会议记录，需求调研、需求分析等文档和开发一起查阅，告知开发你的理由及合理性从何而来，这些也是经过充分的论证，说话语调平缓带有磁性，不要以教育或批评的说教方式说话，说到这里就好了，不要说你怎么没认真开会不听讲这类的废话，不利于解决事情的话不要说，人是整个环节当中最难把控的事，如果你情商太低或者太怕事，建议不要当产品经理，你会被虐得体无完肤。
暂时就先说这么多吧
网友评论