蜗牛派作为产品经理项目管理是很重要的一个能力，互联网行业有的公司即使有专门的项目经理，大多项目经理主要是组织会议，协调资源，在项目过程中很难关注到细节，所以作为产品经理做好项目管理是必备的一个技能
一、引言
项目组的成员一般是临时虚拟小组，小组成员之间一般没有上下级关系，作为产品经理如何利用有限的资源，有限的时间内完成需求的上线。这考验产品经理的组织协调能力，沟通能力等。
产品经理与项目经理的区别：
项目经理是对具体的某个项目负责，传统行业和互联网行业的项目经理职责也不相同，互联网行业的项目经理大多是协调资源，组织会议，不对具体的需求负责。
但传统行业的项目经理权利更多些，会对具体的项目需求跟进，比如浪潮的项目经理，因为他们的产品是根据客户需求定制化的，所以要有专门项目经理来跟进从客户需求到落地。
像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、总结邮件
开完复盘会以后，将问题总结梳理，将大家一致达成的结果发出来，比如需要如何优化项目流程，可以都在邮件中体现出来，这样具有仪式感的同时，也会按照结论来执行。
