【写在前面的话】
你好，我是邱岳。
产品会客厅是一个实战问答的板块，我想要创造的是一个集思广益、共同探讨问题、答疑解惑的互动环境。
在前三周的文章中，我们一起模拟了产品从规划到立项的整个过程。我根据自己的经验，试着总结了一些注意事项。
实际上，这些只是产品经理会面对的一小部分。当你真正地参与到这个过程中，你就会发现，无论前期准备得多么充分，规划得多么完美，难免还是会遇到各种各样、具体而琐碎的问题。
我也经常读到读者朋友给我的留言，大家会谈及一些在实际工作遇见的问题。很感谢朋友们对我的信任，只不过，简单的三言两语并不能完整地表述出我具体的处理方式和思考。
所以，我会在“产品会客厅”这个板块中，把一些具体的实战问题选出来。我和池老师会先给出一些自己的思考与解答，也希望更多的朋友可以加入我们，一起去尝试在更多的实战场景解答问题，共同成长和精进。
今天的这位同学遇见了一个问题。在产品从规划到发布的过程中，作为立项人，需要把握整个项目的节奏。在一些需要推动产品工作进行的时刻，没有项目管理经验，应该注意哪些问题，又如何推动团队一起完成呢？
无论是产品经理还是运营，只要你需要掌控项目整体的进度，就难免会需要在各个节点去推动事情的发生。那么说，怎样以自己的身份做好产品规划、立项并最终推进产品的实施和迭代呢。今天，我们就一起来看一看。
【第三期问题】
恭喜第二期的幸运用户 @laulend™，你的提问被抽取成为本周的实战问题。极客时间将送出价值68元的极客福袋一份。1个工作日之内，工作人员会与你取得联系。
用户留言
邱岳回信
谢谢你的问题。
我想起来刚入行不久时的一件事，那时我跟着前辈一起做项目，在项目组中需要跟其他部门的产品经理协作，那个产品经理能力有一些问题，大家都不太喜欢他。我在一次公开场合很不客气地挑起了跟他的冲突，说得他哑口无言。
事后，带着我做项目的前辈把我叫到一边，翻出公司发的笔记本，那个本子上的每一页上都印有不同的职场鸡汤，他翻了一会儿，找到一页指给我看，我清楚地记得，那一页上印的鸡汤是：“不要让自己的队友失败”。
这个前辈慢条斯理地跟我说，那个产品经理有他的问题，我们都看到了，可我们现在是队友，不能让自己的队友失败。在心态上，你不应该想着打垮他或取代他，而是应该帮他。
我之所以想把这个故事讲给你听，是因为，从你的问题中我似乎读到了不安和抱怨。我不知道具体情况，所以没办法评价你问题中产品岗位上的同事。但我想不腰疼地给你第一个建议是，与其代替他做所有的事情，你不如想办法帮助他，让他负起自己的责任。
帮助一个人的方法有很多，比如提醒他，要求他，建议他，甚至换掉他，但我觉得，替他做事情并不是一个好方法。
你的 1、2、3、5 四个问题，在我的理解中是同一个问题，就是：怎样以运营的身份做好产品规划、立项并最终推进产品的实施和迭代。
你在问题里提到怎样确定规范，把控环节，将流程打通。听起来你所在的公司或许没有一套强制执行的标准流程规范。那我的建议是，由你们自己讨论和商定项目流程。
你可以自己来做项目经理，召集大家一起讨论，将每个流程环节以及环节的产出物定义清楚。比如在你提出需求之后，需要产品经理和设计一起产出方案，可能是 PRD，也可能是原型图，甚至是白板草图和口头描述，不论是什么形式，根据团队的情况达成一致就好。
然后保证需求的提出方，也就是你自己，还有工程师都能对这一产出物有统一理解，然后投入开发，上线前由整个团队一起做简单的测试并发布。在讨论并达成一致的基础之上，这些环节可以跟大家协调分工，大家各司其职，各尽其能。
至于你的第4个问题：运营做立项人是否合适？我觉得合适。就像专栏开篇词提到的那样：并没有任何一件推动公司前进的事务能够泾渭分明地划分职能责任。
在问题的开头，你提到了自己作为立项人时，立项过程遇到的种种困难，这样的困难对其他的职能岗位来说也是一样的，甚至由于业务的不相通也许会更难。
而运营作为距离用户最近的人，也可以更敏锐地感知到用户需求，在与各个职能打交道的时候，也可以及时调整产品的细节。
我从你问题的描述中，能感受到你想把事情做成的热情，这股热情如果能成为支撑你主动承担更多责任，解决团队问题的驱动力，或许你会有更多意想不到的收获。你在问题中提到付出，包括付出更多精力和时间，我相信这些付出终会是值得的，希望你能再坚持一下。
谢谢你的支持，希望这个回答能带给你一点启发，祝你的工作早日变得顺心起来。
邱岳
2018.08.24
【精选分享】
恭喜用户@刘祯 @ qc精灵鼠 的留言被选为精选分享，极客时间将为你送出价值68元的极客福袋一份。一个工作日之内，工作人员会与你取得联系。
【课后问题】
精选留言
2018-08-24 10:18:56
首先我认为作为一个好的项目管理者要具备以下特点：
1、 被公司赋予与职责相匹配的临时性权利
2、 对项目全链路的细致了解
3、 良好的沟通与协作能力
4、 优秀的项目节奏感，宏观上能把控关键性节点，微观上能深入各业务部门解决其面对问题
其次通常我做为项目管理者会进行如下准备：
1、 梳理该项目涉及的全部业务部门，并明确部门负责人以及业务对接人
2、 明确团队KPI、各部门KPI以及KPI统计口径、定义
3、 制定各部门工作任务清单并明确输出物以及时间节点
4、 梳理往期类型项目风险点及建议解决方案
5、 组件项目对接人，负责人钉钉群，并明确项目期间会议机制
最后在项目推进过程中我认为应该避免如下几个坑:
1、 不要成为单纯的进度跟进人，而应深入业务部门去了解业务开展的困难或问题所在，这样才能通过项目管理人的角色调动资源来帮助相关部门解决问题
2、 要充分与各业务对接人展开协作，不要孤军奋战，他们是你最有利的抓手
3、 不要让项目进度成为只有你一个人知道的秘密，每天都要通过邮件或钉钉群同步项目最新进度，近期重要待做事项以及可能存在的风险点。
以上就是个人做项目管理人的一些经验之谈，此外我认为项目管理者的“稳定的价值输出能力”也是重中之重，通俗的来说就是你这个人一定要靠谱，但凡业务部门提出的问题，件件有着落，事事有回音。
2018-08-30 15:43:25
我觉得做需求评审有3个阶段十分重要
第一，在评审前，做好产品基本功
1、根据不同产品定位解决不同，认清楚需要解决的问题，比如说如果是商业产品，那么是否满足也无妨的需求就很重要，如果你是工具类的产品，那就就要着重分析每个方案背后的用户心理，准备好可以证明用户心理的证据。
2、对产品方案优缺点有认知，每个方案都有其优异差别，评审的过程也是一次取舍的过程，不要一味鼓吹某个方案的好坏。
3、和技术开发做好沟通，方案操作难度，投入产出是否划算，技术是否能给出更优解。
4、逻辑清晰的需求文档，不论是拿给谁看都能知道你的逻辑很重要。同时在做一份评审大纲，方便参与评审的人员统一标准来评判，也能快速达成统一。
5、推敲你的细节，是否整个流程没有细节性遗漏，小心评审会上被细节问题问到哑口无言。
第二、评审中，注意表达，注意情绪，控制好节奏
1、先讲清楚业务背景，把大家快堵带入方案，一切不讲背景的会议都是瞎扯淡。
2、讲清楚方案，为什么是这个方案，不是其他的，你都考虑到了哪些问题。
3、对不易理解的逻辑，使用流程图、演示图，别让大家坐在那瞎想。
4、集中火力只讨论该讨论的，比如之前有个需求还没做...这些事情私下讨论。
5、如果开发一口回绝某个问题，那就需要权衡是否值得投入，记住：没有开发不能做的事情，只有不值得做的事情。
6、做好会议纪要！以便会后讨论和修改
第三、评审后，保持持续跟进，反复review
1、评审结束了，但是上线还早，接下来需要不断的review，检查每一处细节。
2、如果需求有变更，做好更新记录，相关合作人员做好沟通，别自己改了，设计和开发都不知道你改了。
3、跟进开发计划和进度
4、准备后续的需求
要切记，完成任务不重要，重要的是要让开发觉得你是个好产品经理。
2018-08-24 16:06:14
一句 【不要让自己的队友失败】深深的打动了我，我之前坚持了大概一个半月，一直没能把事情推进下去，可能是我确实有点着急，也有一些抱怨和痛苦在里面，不安来自于项目推动不下去，我的开辟没法交代，人是自私的，出问题了，一旦推进不下去会本能的排斥和嫌弃对方，其实我们需要的是更多的耐心和倾听，无论对方是谁……我确实在提醒多次后也想过放弃他们、想过自己取代，但我明白，这些终究不是长久之计，内心是很想大家一起好好合作的，因为合作共赢，专业的人做专业的事，《乐观的投资者》这一段话一直在脑海中回旋。最近一直在思考，合作不好，问题出在哪里？大部分来自于不信任，产品和运营和研发之间的不信任，加上产品、运营不沟通，我作为需求方也没尊重人，当产品不找我对需求的时候，我也不会主动找他们沟通，从本质上就觉得他们很差，带上了有色眼镜，中午研发还跟我说，产品要换，整体能力太弱，其实我明白，大家都不再信任他们了，想想，还是挺无奈的，现在我换了个思维，给他们时间，根据我的需求和运营计划让他们做规划，我来把控，哪怕是能力弱一点，但多一些耐心、可以去包容他们…现在我的业绩可能更多会是从不依赖产品来产出，给产品更多的时间，如果他们能成长，我想我会在看到不一样的自己。
最后，再次感谢二爷。我好像知道未来该怎么做了…
2018-08-24 19:56:02
可能自己就是这样的性格，那些我们曾以为的个性到头来让自己吃了太多亏。
我们不是变得圆滑，我们只是为了实现目标学会变通，换种更合适的方式不是更好么。
这句鸡汤真的令人感动，产品从来不是一个人的，彰显了自己，冷落了他人，如何在未来取信于团队呢？
此外，二爷的回答真的很有条理，而我的方式却太简单了，二爷愿意花这么多时间和经历来设身处地思考，身为局外人，都有很多感触。
再次感谢。
2020-04-06 11:29:10
突然想到《亲密关系》这本书，所有你期望对方改变的 其实是 你内心深处(童年时期)未得到满足的需要 的表现特征，与其从表面安慰或看似解决问题，不如溯源 明白自己内心真正需要什么~
谢谢你 邱岳童鞋~
2018-08-24 10:57:28
1.「不要让自己的队友失败」,不好意思，这句是今天最大的收获，听着有莫名的感动，谢谢二爷。
2.今日份问题的思考：
这个问题让我想起来前段时间那个开发和产品打架的视频，不管真假吧，我觉得这种冲突在项目中很常见，开发、测试、产品，简直就是「冤家三角」。
针对这种问题，我的思考是，这不是某个人的问题，是大家的问题，或者说是大家的沟通的问题，先不管对错，既然大家有碰撞，就说明大家都在为项目着想，从这点来说，大家的出发点都是好的，那就是应该鼓励和提倡的。
比如现在这个问题中的开发，是为了节省公司资源，避免无用功，产品呢，是为了拉活，只是方法上有点无视规则。
我的建议是：「事前充分沟通，决策后坚决执行」，充分发表意见并不一定是谁说服谁，谁赢谁输，是按当前方案提前考虑好所有可能出现的问题，然后针对每个问题考虑清楚对应的风险是否可以接受，以及准备好出现这种问题的应对方案，如果这些能达成一致，那么就去做就好了，如果达不成，换方案。
3.最后，沟通很重要，沟通时不要带感情色彩。
以上，欢迎沟通交流，公众号「sylan215」
2020-05-21 17:05:15
2019-01-17 00:04:14
现如今出现的问题是，我会直接面对客户的沟通，产品需求需要自己对接，有时发现产品沟通出现问题，但也没法说清谁的过失。
你要做的太多，需求什么都去做，会导致本身这个岗位的同事心有抱怨，但你不去做项目又会延期。
一个项目的进度跟你考核关联，所以做起来沟通不畅，做的比较吃力。跟产品需求的讨论过如何高效沟通，但最终没有效果。遇到问题，还是会把我拉到一线，帮他去回答客户的疑问，以及开发需求沟通。
感觉事情做的有些混乱，跟别的部门的协同，也是你自己去沟通，忙的焦头烂额，却并没什么好处可言。还会让别人理解成你在越权，没摆正自己位置。
哈！有时觉得自己善于沟通需求，整理文档需求，但自己性格急躁，有时会情绪化。但也是这个比较讨喜，因为真实有温度。
想从事做产品方向，做一款自己的产品，不求多么精彩，只想有个成就感。
太晚了，就说到这。
2018-09-09 18:16:39
2018-08-30 19:00:10
今天我想问的问题是：我现在一个产品拿到手上后，常常是觉得它好，但是又不确定它的好，好在哪里，所以在这个情况下，我们要关注的哪些点？
另外，竞品分析和产品分析有什么区别呢，怎么做一个有效的竞品分析呢？
谢谢二爷帮忙解答。
2023-01-06 22:10:35
2022-02-13 07:53:52
2021-11-12 22:40:10
2021-09-24 11:09:35
2020-03-21 17:48:22
2019-03-12 14:45:01
产品出成果是大家的，作为产品方应该跟开发好好讲讲项目背景，做某个功能的价值，并且要强调开发做了这个功能会带来多少价值，并且是一些能够量化的价值，开发最怕的就是自己吭哧吭哧做了个功能，然后没人用，甚至都没让上线，这岂不让开发寒心？开发以后肯定会有抵触心理呀，因为会觉得自己做的事情没有价值。
而作为开发也需要站在产品的角度考虑问题，需要给出产品能做或者不能做的理由，以及即使做了有哪些风险，这个风险产品能不能承担？开发如果把这些都讲明白了，会帮助产品做出更好的决策，也会做出更有价值的事情，而不是产品说什么，不想做就一个句不行，然后就没了，即使答应了下来也是稀里糊涂的做，这就失去了做这个功能的意义。
2019-01-08 10:55:16