2024年两个考察产品经理执行力和抗压性的实战面试题.doc

两个考查产品经理执行力和抗压性的实战面试题？

涂照锐的回答 Q1：
1. PM先安排产品经理分别联系任务团体（运行需求方），确定大体的需求，然后确定组员（BU为单位），叫在一起项目KICK OFF；
2. 与UED确定基本交互层，即大体要的东西是长啥样的；
3. 与DEV确定支撑系统的重要功效；
4. 将UED与DEV拉在一起，确定最后要实现的功效，UED与DEV的联合形式，产出功效表，大体时间表（并与需求方最后确认）；
5. DBA设计数据REVIEW形式与逻辑，SQA负责build基础数据表，与DEV的联合方式；
6. SCM确定运行时间，或者资源提供？看重要职能了~
7. 包括开发的团体，按照最后实现功效评定资源，提供时间表：包括各方接入的时间点，与产品物（项目甘特图）；运行方提供，同时期并行运行（预热--》使用？）时间表；
8. 此时已各就各位，再叫在一起KICK OFF，项目正式开始，PM按照项目甘特图监控进度~ 直到项目完成

Q2：

因为要上线大推（尚有CCAV），因此不可儿戏，有关迅速迭代啊，加班啊这些不是根本处理措施。因为要实现的东西，假如缩水了，会起到极大的负效应。因此：

运行能开启的部分就先行开启了，其他的，迅速项目开启会，确定需求与要实现的功效：
1. 确定该项目包括到研发部分，详细的功效点，以及预估实现时间；（2天）
2. 确定各功效点的核心节点，然后分包为外部专业软件外包企业，功效多，一家要求时间完不成的话，就继续分，以此类推~ 自己企业也做并行开发（加班是肯定的，但不要指望新人当奇兵，尽也许用老将，最多以老带新）；（单个分包不能超出7天）
3. 7天后收货，联合测试，BUG修复：上线前必须确保流程完全走通（冒烟+回归 测试），如有BUG，主流程BUG优先处理；产品经理同时准备产品文档；（2-3天）
4. 如有运行开启，运行与所有有关方一起加入，体验或正式使用；产品经理完善产品文档（1天）
5. 上线前最后综合准备（1-2天）

一共13-14天，确保按时上线；然后整顿各方外包产品，设定企业掌握所有外包移交的时间表；

最后使劲BS一下CEO，然后要求大幅涨工资；老板若欣然同意，提出离职----因为这个老板做事一没计划，二没标准，以后会更麻烦；假如这个项目你能圆满完成的话，去家愈加好的企业，或者自己创业吧~ grace的回答 我也来说说
第一问题：
1、在需求并不完全明确的情况下，从需求的起源方，搜集需求，分析需求，然后形成需求列表。在需求列表确认后，开始撰写PRD文档和原型的设计。在完成PRD和原型之后，一定要与你的需求起源方，有关的产品人员讨论和确定。
2、在与需求方达成共识后，要组织一个需求分析会，在需求分析会时，召集运行、UED、DEV、SQA、DBA、SCM以及其他线PM共同参加，对你的产品PRD和原型进行讨论和评定。
1）假如不能在会上达成共识，确定要调整内容，及调整时间，下次碰头会的时间。会后总结目前存在的问题，对方案进行调整，准备进行下一次讨论。
2）假如对处理方案能达成共识，在当场要确认，设计，制作，开发，测试的人员及工期。同时要对执行过程中的风险进行评定（例如，你需要使用短信通道进行测试，成果短信通道不可用，是否能在测试时间协调可用）。
3、依照需求分析会确定人员和工期，通过某些项目管理工具（例如Project）统计，并通过邮件等方式把项目进度公告所有人。
4、在整个设计，制作和开发过程中，需要跟踪每个人员的完成进度，并提示完成日期。中间一旦有请假，或其他事情延后，要尽力协调有关人员追回进度，假如不能追回进度，需要延期，也应提前发邮件通知大家。
5、在项目设计完，需要产品经理确认功效和设计格调后，再转交制作，防止开发完成后，设计不合理再做调整。测试时，产品经理一定要参加测试，测试是最轻易发觉问题的。
6、在测试完成后，应当请其他产品线的PM及产品需求方进行验收，验收通过方能上线，验收不通过，要对问题进行评定和调整。

第二个问题：
既然是CEO钦点的项目，并且大约会调集全企业1/3的资源来完成，目前完全授权给你，时间只有两周。该项目在两周上线之后会在CCTV以及各大门户投广告来推广。
以上阐明该项目非常重要，并且时间比较紧迫。
处理措施：
1、“最近企业技术研发体系新人较多。”阐明大家都不太了解，关系比较陌生。能够借用下班时间，请大家一起吃个饭。目标有2个，一是熟悉大家，拉进关系，利于工作的开展。二是借机阐明项目标重要，希望大家尽力配合。（至于吃饭的发票企业能报销最佳，不能报销能够自己负担）
2、“面临着十一国庆长假，”其实这是同时也是一个赶进度的机会。
1）首先要跟CEO商议，项目时间紧迫，国庆长假加班要给以优厚待遇。（例如：按国家要求发放加班费，予以午餐报销，报销往返打车费等等）。
2）与项目标每一位技术人员协商加班。同时自己也会陪同技术一起加班，随时依照技术的需要解答产品问题。
3）在加班过程中，积极协助项目测试。
要以自己的行动去感染每一个人，希望他们看到你忙碌的样子，也不会丢下你和整个产品不顾的。

补充一下第二问题：
前面只回答了某些协调资源的事情，哪些都是事情的铺垫，是为了事情愈加好，更顺利的进展。
下面回答项目实行处理方案。
1、对于项目标所有需求进行列表，然后按优先级进行排序。先把重要的核心需求和功效提炼出来，作为一期开发，其他非必须，锦上添花的东西能够进行二期迭代。
2、产品的prd文档和原型利用2天时间完成，并与CEO、运行及其他产品线PM，进行首轮沟通讨论。
3、对首轮讨论中的问题进行微调，然后召集设计、制作、开发、测试等召开产品需求分析会。讲解产品功效，并论述产品重要性及时间的紧急。并阐明完成的上线日期。当初让有关人员确定对应的工期，例如设计1-2天，制作1天，开发3-5天。同时能够考虑无需设计的后台功效技术提前投入开发，在设计完成部分的时候，制作先切图，然后交给技术，各部门同时进行。对于设计和开发的周期控制在5-7天内
4、对于时间比较担心的能够考虑晚上或长假加班完成。在技术完成部分功效时，提前搭建环境，介入测试。在测试时，邀请企业不太忙的人员参加测试，例如前台，助理类的。
5、整个项目大体的时间规划为：
产品的定义和原型（包括讨论会）：3-4天
界面设计：1-2天
界面制作：1天
产品开发：3-5天
产品测试：3-5天
因为会包括某些功效能够同时进行，例如在设计时，技术要完成数据库建模，架构的规划等。
在2周时间，虽然有些担心，不过假如参加人员都比较负责的话，足以完成。
因为项目比较重要，为了万无一失，尽也许提前1,2天完成。也就是能够利用长假加班，项目完成后可调休或要加班费。 志一的回答 已经有答案几乎涵盖了能用到的措施，那我从另一个方面回答一下。第一个问题，拢住人心才是首要先决条件，否则后边那堆答案极难执行顺畅，说的再好也只是说说而已。某些答案隐含着一个假设，那就是题目中的8个部门或职位，每个都能按照你的思绪都能无误的执行，在这么的企业一定很爽。第二个问题的大多数答案还是比较现实的，当然无论争取多少资源，满足需求所花费的时间是硬性条件，完美协调和执行的情况下也无法完成的需求，只能砍（不要忘掉《人月神话》）。

梁斗、汪渊、另有见地、外墙等这些把人放在第一位的答案说的是精髓，很奇怪为何都没有支持票或者极少支持票，这些人才是真正有过协调经验并且很现实的。

HR或者部门面试官，每个人对被面试者的技能考查点都不一样，但一定要清楚这个职位在目前企业环境下，最重要的能力是什么。按照这个题目和背景来说，协调资源的能力最重要，详细的技术层面操作是次要，假如弄反了的话，很有也许发觉这个人常常面对各种拖沓而一筹莫展。 杨振宇的回答 看完这个题目以及楼上众多前辈们的精辟回答，不禁让自己有一个豁然开朗的感觉（因为有遇到过这么的困惑），同时也借着这个机会整顿一下自己的思绪：

Q1:假如一个项目，需要协调运行、UED、DEV、SQA、DBA、SCM以及其他线PM这些资源协同完成，并且目前需求并不完全明确，需要的资源情况也不明，你打算怎样来推进？讲讲详细的做法和详细的步骤。

1 有关产品经理的定位在各个企业都不一样，有的仅仅是做一下市场调查，出一份筹划方案就完事了（简称：产品筹划）；

有的是需要对整个产品周期都有所了解（包括需求搜集、筹划、研发、测试、运行及推广），这么的人不要求这些都是NO.1（不过得明白产品过程的每个阶段的重心在哪里，能够很好的介入并负担重要责任），假如再厉害点的包括财务流程、上市包装、与VC的沟通等等都需要一定的了解（简称：CEO）；

有的是更多是不停的在为领导和市场人员在做各类PPT和文档，这么的产品经理在诸多国企里面很轻易出现（简称：文秘）；

尚有的仅仅是依照需求方的需求进行某些文档的整顿（轻易发生在某些强势的需求方的情况下，简称：需求经理）

有的企业是项目经理说了算，有的是产品经理为整个产品负责，尚有的相互博弈打架，都有的。

就我个人的经历感受，在各种的情况下，最重要的一项能力是：沟通。你负责的时候，没有措施很好的沟通其他人，产品推进不了你急的想砍人；你被安排做自己不喜欢的事情时候，更是缺乏了与上位者的沟通。“得人心者得天下”啊，看看三国的刘备，文不如卧龙凤雏、武不如五虎，可是江山还是他们家的。并且中国人也有一个心态：熟人好办事。

烦琐了上面这么一通，第一步要做的事情就是拼命的与你这个产品也许产生交集的部门和人员拼命的沟通熟悉（各种措施因人而异，因环境而异。PS：这点给自己的感触很深，新换一家单位的时候，本来说好产品的责任人是我，可是背面大老板插手后换了他人，开始尚有点想不开，事后想想赛翁失马啊），了解他们的性格，长短处等。

2 第一步的基础打好之后，下面一步就得体现产品经理自己功底的时候，需求不明确（很正常的，有的时候一个产品和项目标发生就是需求方或者老板的一句话，一个想法产生），因此资源情况当然也没措施一下子明确了，那么我们所能做的第二件事情就是自己动手做SWOT了（骂完娘之后），这个过程就能体现产品经理功底了，一个好的产品经理他需要有着丰富的知识面和一定的行业预见性，前往不要依照目前的情况去做分析，等你做完了给开发搞完后，投放市场，傻眼了，一堆的同质产品或者是技术更新换代了。

3 做完SWOT之后，第三步还不急着找各个职能单位，做一下产品项目标商业模式梳理（虽然诸多人都以为流量有了背面什么都有了），不过在没有一个好的商业模式的梳理情况下，你根本无法对这个产品的发展远景心理有底，你怎么能够去做下一步给大家画饼的事情呢？再说了，有再多的流量数据有什么用，转化不了钱的东西就是个面子工程。（因此说面子工程能够跳过这步）

4 上面有说到，下一步就是召集各个部门，给大家开始画饼了，总不能又要马儿跑又不给吃草吧，近期的收益拿不出来总得给大家个盼头吧，这么调动大家的胃口，下面的事情就更顺了。

5 下面要做的事情就是常规软件工程中要做的事情了（同时各个企业也也许有自己的通例，假如没有的话就按自己最拿手的方式做），无非就是需求细化，场景模拟，模块划分，模型设计，界面交互设计，测试用例设计等等，先后次序不一样罢了。

6 最后一点，熟悉产品过程中什么时候最重要，这个时候的这个事情一定得自己亲自参加抓，其他的时候大的方向和里程碑就好了，否则你也不是超人也不要去做诸葛亮。

Q2：假如另外一个项目，是CEO钦点的项目，并且大约会调集全企业1/3的资源来完成，目前完全授权给你，时间只有两周。最近企业技术研发体系新人较多，同时面临着十一国庆长假，该项目在两周上线之后会在CCTV以及各大门户投广告来推广。你会怎么做？

1 还是做项目，因此你要先去了解这个项目标背景，这个很重要，尤其是大BOSS参加的项目，是面子工程还是产品必须有竞争力，还是一炮必须红，还是为了某人晋升捞政绩用的，等等··

2 了解完背景之后，心里盘算一下对策，了解一下老大能够给的各种增援的底线，没有上头的增援，轻易下手做事情最后累死，得罪死人和背黑锅的肯定是自己。

3 打仗同样的知自知彼（知自部分能够参考偶Q1的部分以及其他前辈老大的回帖），下一步就抓住核心点尽善尽美（假如项目标所有的都核心那只能咬牙去抗了，谁让我们打工呢？），同时依照老大的支持（或者妥协），要枪要人要粮饷（只要对项目有利的都要）。

4 周围都准备好了，下面就先来一下动员大会（详细形式各异，拉拢也行，立威也可，许诺也可），然后就开始咬牙攻克了，反正这么艰巨的任务搞砸了自己也得挂，就如一句话说的“司令说三天内假如没有拿下XX高地就毙了我，再这之前我会先毙了你这个师长”。

5 一般来说两周左右的突击是能够承受的，但落实执行，定期review，修正、调整，推进项目达成预期目标

Q2：
1、梳理明确项目成本，以及可调用的资源明细（前者依照项目难度评定，后者可直接boss明确）
2、其他的跟Q1的流程差不多，只是时间更担心，加班加点免不了。处理方案：1）争取各组leader支持。2）为团体组员争取需要争取的，如加班费、调休、奖金等等，处理后勤问题。3）做好团体组员时间管理，盯紧每个时间节点陈义的回答 没有产品经理经验，只有项目管理经验，因此只谈第二题。

第一步，明确任务目标：怎么来评定这个任务是否完成了？确定自己对任务目标没有误解。

第二步，迅速完成可行性分析。虽然"当艰巨的任务来临的时候，不要试图去逃避"的说法很正确，不过不进行可行性分析就接收一个如此重要的任务是不负责任的。假如无法按时完成被指派的任务，那么能够看看二八标准是否有效，就是说，有无也许用20%的人工，达成80%的效果，80%的效果对该任务来说是不是一个可接收的效果。另外，需要权衡预期收益和风险：假如该项目虽然失败损失也很小，但假如成功收益却很大，那虽然风险再大也要上；反之，假如项目失败带来损失巨大，但项目成功只是锦上添些小花，那只有在风险非常小的时候才能够继续该项目。

最后，假如无法完成任务，找出能最小化损失的措施，向CEO报告。千万不要等到两周后用事实去告诉CEO这是个不也许完成的任务。

第三步，列出达成目标所需完成的所有任务，确保没有遗漏，更细致地估量每个任务的工时，为每个任务指定一个责任人。这里有一个平衡，假如任务划分太粗，估量任务所需人工就会有比较大的误差，假如划分太细，也许两周还不够作计划用的。

第四步，执行计划，并依据详细情况调整计划。

不过说回来，以为上述情况并不像题目中说的那样会常常出现。目前大型互联网企业1/3的人最少几千，几千人去完成一个只有两周周期的工作，最也许出现的情况就是给的时间还不够作计划用的。有也许完成的工作，要么是个例行的工作，常常干的，已经有积累好的流程了；要么这个工作不需要交互，任务之间没有依赖（例如组织几千人上街宣传自己的产品，10大城市两周行），其他的任务基本没有也许。道理很简单，一个人一年能干完的工作，365个人一天能干完吗？

另外，互联网企业仿佛更倾向于短平快打法，先投入少许人手开启，然后逐渐完善，极少有一下子砸进去1/3人手的（并且只是两周的周期）。

很好奇大家竟然把详细时间分派都写出来了，难道作计划不懂得详细任务是什么就能确定期间安排？ Kelly的回答 A1
了解清楚项目标需求背景及目标（最少自己心里明白是个什么事儿）；结合实际情况，哪些步骤的流程是规范化的不会影响项目标进度，而哪些步骤又有也许出现问题；针对也许拖延进度的步骤，提前和有关主管打下招呼（有这么个事，让他们有所心理准备），无须太正式，毕竟此时需求不明确。

A2加班是肯定的全力执行，及时的沟通、协调、推进问题处理也是肯定的在时间和人员一定的情况下，质量和成本做对应的让步，尝试和老板沟通该情况，减少其心里预期冯顺的回答 Q1.
先出冗余版需求大纲；推进运行先去和渠道搭档、CP等先行沟通需求大纲，汇总各方意见形成反馈；与研发、QA、运行等沟通需求大纲，形成反馈；依照各方与需求会议反馈明确之前无法确认的需求，实在无法确定的需求，做减法留给下一版择机而上，出新的需求v1.0；和老大们开会沟通需求v1.0，形成需求v1.1，并排出有关时间表；再次召开需求会议，与研发、QA、运行等有关人员开需求PK会议，PK资源，依照会议反馈，形成需求v1.2（大多还是做减法），并依照v1.2形成新的时间表；和老大们开会沟通需求v1.2，形成需求v1.3（定版），形成新的时间表；邀请研发、QA、运行等有关人员开产品需求会议，完善时间表，明确时间点；一直求各方有关人员帮你依照时间表按时完成产品的release版。

Q2.
运行先行沟通与推进合作搭档做好推广准备；产品组形成需求初版大纲(0.5d)，与CEO等老大们PK需求初版大纲，并形成定版需求大纲与需求v1.0(0.5d)；与研发、QA、运行等有关人员召开需求会议PK需求v1.0，反馈，形成需求v1.1(0.5d)；与CEO等老大们PK需求v1.1，反馈，形成需求v1.2与时间表(0.5d)；与研发、QA、运行等有关人员召开需求会议分派需求任务与安排时间点（0.5d）；研发、运行、UI等同时进行，研发5d，运行推广方案与计划1d，定稿1d，UI1d，QA2d。修复bug2d。ps：核心时间点——确定版需求什么时候出？研发什么时候完成？推广计划什么时候确定（cctv等都会放假，不会加班等你们方案的）？release版什么时候出来？
加班肯定的，产品同学们需要天天陪同大家加班，研发也需要时刻加班，QA尽也许调休吧（研发前期能够休息），UI前期加班，放假最少需要能够联系上在家工作，运行中期稍微轻松点。结束后请大家聚聚餐吧。
研发尽也许用老人，人不够用年轻的，外包提议不要（沟通太辛苦了）。 快刀青衣的回答这个问题真好。
两种场景都非常常见。
个人的一点见解，两种场景里，产品经理的角色完全不一样。
1.产品经理类似万金油的角色，这就要求之前在企业各个部门内部都有良好的人脉和资源。向上探听领导的大体意见，平级跨部门注意私下沟通和书面邮件相结合。一定要先私下沟通好，再群发邮件，要不一定会被某一个人给拖死的。
2.产品经理更像一个leader去推进，气场要强，做到有理有据，私下里是朋友，不过这件事情上必须按照产品的时间进度去做。哪怕加班。要让大家有一荣俱荣一损俱损的感觉，哪怕江湖气某些都没关系。张玮的回答 第一个问题没有明确阐明期限，也没说清楚规模。然而在牵扯到这么多部门的项目中，很也许是一个比较复杂的项目。假如需求不明确，同时不了解工作细节，极难争取到有关部门的重视，成果就是导致资源不足，项目花了很长时间，延迟到让任何人都以为这是个拖沓的项目。
那么核心是分解项目。从步骤来说，首先是明确需求，找到最核心需求的人和最高的决议者，再将需求分解，尽也许的将非核心功效安排到二期、三期，只保存核心功效，驱动较少的部门也易于协调资源。尽快上线，项目见效之后进行2、3期的开发。个人以为想一步到位，协同这么多部门同时进行是不太现实的。

第二个问题，有经验的话，从1/3人力，有也许在两周内完成的项目来看，能够估量出项目标规模大小，也许这是一个1-2百人的企业，三五十个研发人员的项目，并且这是个刚才拿到融资的创业企业，否则1-2百人的企业没有实力上cctv和大门户广告的资金。再少的人不需要做规划，说一句加班就行了。再多的人，也挤不进一个项目里。那么这种情况，首先驱动老板出面，抓住最核心的3-5个骨干开会，然后通过这几个骨干去充实团体，让他们去驱动更多的人。这么看下来，其实这个项目我以为还是简单的。因为第一个很也许是一个已经比较正规的大企业，制度和流程上的扯皮是很轻易发生的。第二个尚有点灵活性。 张晓庆（Marian）的回答 这是不错的面试题，我喜欢，也值得思考。作为一个非产品经理，我的回答是

Q1：一般来说作为一个产品经理，必须先花一段时间去和运行打交道，重复推进得出一个合理的spec框架，然后是跟DEV，SQA，DBA进行项目讨论，把需求明确、细化，对于某些矛盾或不明确的需求再跟SCM尚有其他的PM商议讨论，不过一定要明确项目标目标和方向，不能偏激某一方增减项目标功效和质量，同时有关的框架的设计方面自然是需要和UED设计去沟通。我不是很清楚互联网产品的操作，不过相信跟软件产品是有共通之处的，在目前企业学习到了流程化管理，在时间紧迫的情况下，分阶段进行需求细化，责任到人。所此前期的需求分析很重要，项目标进度分派一定要合理有效，这就是一个好的产品经理应当做到的，有效沟通，合理分派，领导管理。

Q2：在紧迫的时间内去完成一个项目，同时面临长假，需要产品经理去做好灵敏管理。

假如把项目做得有创新意识，吸引眼球无疑是产品经理最需要关心的事。借判别的竞争对手的产品择优补拙，打破常归思维去考虑自身产品，做好第一步需求上的工作，然后去跟技术讨论分析需求的内容，把需求划分阶段进行处理，哪些重要的需求在什么时间点去完成，责任到人很重要，就算是两周时间，每个需求点明确，每个人的任务明晰，项目还是能照常公布的。这中间需求不能有太大的变动，否则影响项目标进度也是时有的事。 汪渊的回答 大家都写的比较多，估量都已经涵盖了所有也许的方式。但个人以为，做产品经理和项目经理时间久了，更多的是依据个人的气质和能力。没有一个标准答案，有人快刀斩乱麻，有人细水长流，总之能把问题处理就是好措施。详细还要看所在企业的环境和文化。分清主次，把握核心，及时通报，信息透明，扩张资源，做到这几点，基本上这项目哪怕不成，也不是你的责任了。 wosoun的回答Q1
1. 明确项目目标，重要是产品的需求、完成时间。拉几个了解能力、动手能力强的PM和技术责任人，和项目发起人进行重复沟通，渐进明晰确定产品需求。中间也许经历数次PK，一定要充足了解发起人对项目标期望。产出重要是和发起人沟通确认的产品需求，和发起人的授权（有授权才能名正言顺的协调资源）。
2. 确定产品方案（能够和1一起沟通）和技术方案。产品方案要发起人通过，技术方案具备可行性。同时，据此向发起人要求项目资源。
3. 人员分工和项目计划制定。什么WBS分解、核心途径法等，产出项目实行计划，和核心里程碑。需要和发起人确认（发起人一般会压时间，那就要资源呗）。
4. 项目实行监控和风险管理。
运行、UED、DEV神马的都是用来障眼的，答题最核心的做整体项目标措施，有产品经理经验和PMP知识就能够了。
假如真要执行，那就没那么轻易了。看前面的这阵势，这个项目得30+号人。要有很强的了解能力（领导要什么，了解偏了白干了。当然，也有也许领导跑偏了...），沟通能力（对上、对资源）、很缜密的逻辑思维能力（否则项目计划不靠谱）、很强的执行力（项目计划和实际进度，你懂的）。另外，需要有较为丰富的经验，最少包括到的部门业务要略懂。最佳有靠谱的好基友。

Q2
1. 和发起人（也许是CEO哦），确认项目目标。
2. 和项目骨干确认项目所需资源（不存在不可行性，那就要可行所需的资源，不够问CEO要呀）和项目计划。
3. 和发起人沟通项目激励方案（激励这么单纯的东西，一定要谈呀）。
4. 项目开启会，鸡血一定要管够，并且要随时准备补血。
5. 项目实行监控，15分钟晨会呀神马的，周期短监控频率要相对高一点。
6. 不要以为这么就结束了，找上你的好基友，一起想想在这要人命的2周里搞点啥短小精干的娱乐让大家保持欢愉的战斗面貌吧~
题目标前提假如是PM新人，那就是耍流氓，做这个纯粹找死。
另外，能上CCTV的，都必须是非常成熟的产品吧，那这2周能干点啥呢？有陷阱。

好吧，我认可这2道题目包括的场景，我在某项目里全遇到了，比第一个题目标假设复杂3倍，时间没有第二个题目这么坑爹，但还是很紧急呀。王宇鹏的回答 推荐一本书 压力下的角逐 书中作者是开发ps3和xbox360 的cpu的首席架构师, 在时间紧迫的情况下要开发出2个产品并且是自己打自己的产品,假如做到, 我以为很重要一点是创新管理. 王圣佳的回答 技术出身的小鬼，从来没做过pm，午夜里尝试看看。
A1: （假设企业里有好人缘，沟通无障碍）
首先把手头的东西写下来，理一下思绪。
所有的需求：按时间次序排列，分别理出已经明确的和估量也许会有的会包括到的部门：详细到人。所有手头能够调动的资源：包括资金，时间，人员安排等。

依照已经能够预见的需求，先把能确定的事情确定下来，能做的先做起来。
找架构师讨论。定下基础框架。找DBA，有也许的话数据库也能够开始设计。前端的话，假如详细功效还不明确，能够大体先制定颜色格调，logo之类的，做出原型页面。依照以上这些，了解需要哪些人，也许要多少服务器，也许要用到哪些大型软件工具，需要多少钱，多少时间，分别怎么花。也许会需要的人（开发测试等等）能够开始提前联系起来。这些人也许会包括多个方面技术以及多个正在进行的别的项目。尽快确定需求，做出更详细的产品规划。做用户调研，研究数据导向之类的。重要时间线要衔接好，毕竟不也许所有的人都整装待命在那里等你。注意细节，确保在适当的时候在适当的地方有适当的人。假如是牵涉到IT以外的业务的话，例如进销存，物流供应链等，那也许更复杂些。
大体想到这些。。各位指教。 江南刀客的回答拜读完上面的答案，有一点很怀疑？哪个PM有这么大面子能让一大帮子人陪你国庆加七天班。CEO都不一定有这么大面子。尤其是手上没有考核权，我以为极难调动这么的高强度作战，并且还需求不明。我反正没遇到过，只能告诉面试官实战中这种事情我搞不定Ivy.Fan的回答 只回答第一个问题吧。

Q1:假如一个项目，需要协调运行、UED、DEV、SQA、DBA、SCM以及其他线PM这些资源协同完成，并且目前需求并不完全明确，需要的资源情况也不明，你打算怎样来推进？讲讲详细的做法和详细的步骤。

答：这个过程不是一般的产品经理能负责的，假如这个产品经理负责这些，他的角色和项目经理几乎没有区分。整个过程是一个软件周期要走的所有流程，首先要明确软件周期的重要性。

整个项目流程需要参加的角色：需求设计、产品设计、开发负责、测试负责、总项目负责（此处不单单拿产品经理说吧）

1、 需求调研阶段
2、 设计阶段
……
均要通过阶段性评审来确认，并且完全按WBS来执行。

附：腾讯也不是每个项目每个部门都有项目经理的角色，我了解的信息，有些项目有些部门，腾讯的项目经理角色的工作只是天天发邮件，甚至诸多都是刚毕业的学生。产品经理对项目标跟踪也只是大阶段性，详细都由技术leader来执行和掌控。

荷荷堂的回答 Q1:
1，先确定【目标人群，产品目标，商业目标】，然后立项，组队。
2，召集所有组员，开头脑风暴会议，讨论需求。宣讲【目标人群，产品目标，商业目标】，然后每个人扮演用户角色来畅谈需求。
公投小组长。运行、UED、DEV、SQA、DBA、SCM，以及其他pm，每块公投一名小组长or责任人。
会议结束后整顿需求，建立角色模型，将需求阐明发给组员。
3，第二次召集所有组员，用角色扮演的方式宣讲需求。让他们再提意见，最后汇总，形成需求文档。
4，征集其他pm意见，并将需求划分至功效模块，提取每个功效模块的特性。
5，写产品列表，依照roi进行排序。（roi即投资回报率，评定roi需要运行，开发，设计，boss等方面的小组长一起配合，例如：预估商业收益/用户满意度，运行预估运行效果，开发设计等预估工作难度、工作量等）
6，在各小组预估的时候，同时开始流程设计，原型设计。找具备代表性的用户（一般是运行，用研，pm，以及热心用户）来评审lowfi原型。征求各方意见，做好原型迭代。
7，将排好序的产品列表以及原型发给所有组员，充足开展会前讨论。对也许发生的“无法实现”做好准备。
8，第三次召集所有组员，宣讲产品列表，演示lowfi原型，让大家充足了解需求以及自己的工作目标。像播放电影同样宣讲原型，然后看完“电影”后各自回去做工作计划的初稿。
9，第四次召集所有组员，宣讲各自的工作计划。明确什么时候做什么，怎么做，做多长时间。
不能明确的地方，统计下来。召集教授组，协助提提议。实在无法了解的地方，深入阐明或修改需求（诸多时候只是换一个诠释方式，标准性的不能改）。实在无法实现的地方（尤其是技术方面），预估工作量，修改roi预算，调整子产品的次序。
10，在大家都做好计划，明确各自该干什么，怎么干，开始正式项目进程。
项目正式开启后，要做孙子，做到有求必应，确保沟通到位。
11，遇到突发情况-----各个团体情况不一，详细问题详细分析了。不过有一点必须明确，工作计划没有执行到位的，要立即着手处理，请教授协助也好，沟通也好，调整计划也好。产品目标以及deadline是pm的底线。
12，最后就是随时配合做测试吧：）

===========================================
Q2：
1，明确目标与需求。把这个项目分解，划分子产品线，做好产品架构。
2，召集对此项目感兴趣的组员，报名参加（因为ceo钦点的项目，轻易赶鸭子上架，但人多未必是好事，往往强扭的瓜不甜。因此个人倾向于投名状的措施。有热情的来参加，没热情的就免了。国庆有事的人也免了。不过能够邀请ceo发个总动员的邮件或演讲，借用ceo 的个人魅力，组织团体，唤起斗志）
3，将报名者召集起来，让他们自己选择参加哪条子产品线。每条子产品线布署pm，pd，po等角色。明确每个人的职责。
设新人组，新人假如足够多的话，每个人配一个做助手（用xp结对编程原理，三分钟自由速配方式）。假如不足够多，两、三人合用一个助手。
设教授组，专门负责技术攻关的处理方案。
设统筹组，负责子产品之间的整合，并负责处理扯皮问题。
4，用srcum的方式进行产品的实现。（也就是Q1的那几步，在时间压力下2345步可省略）
5，此间工作重点在跟踪进度上。每个pm以及统筹组组员，在天天收工前报告进度，口述出现的问题以及问题是怎么处理的。
6，如有突发情况，召集教授组提供方案进行攻坚，拉动统筹组协商处理。
7，仍然是以产品目标与deadline为底线。做项目，尤其是大项目，无法追求尽善尽美，核心是这个产品能突显明显特性，满足最重要的用户目标与商业目标。
8，另外，请几个PLMM cos女仆装，负责端茶送水喂点心。 史飞的回答大企业里这么的场景是很常见，不过我其实好奇的是——有什么成功的产品，当初的背景是这两个问题里描述的那样的。

虽然跑题了，但实在是想懂得呀。天宇的回答 谈谈我的见解，

第一个问题：问题的核心是首先明确需求，能够和需求提出方，譬如：运行，老板，用户，客户或者其他部门先行沟通，了解他们想要达成的目标或者功效，然后再进行产品的规划或设计，产品需求确定后，评定优先级，再和后端或者协作部门沟通评定期间节点等详细细节；

第二个问题：在需求已基本明确，但时间比较紧的情况下，首先进行需求的筛选哪些要做哪些能够不做（了解上面的想法，老板的，直接间接领导的，考虑周全后再和上面沟通）；在确定要做的情况下，再进行各部门工作内容优先级的评定，什么先做，什么后做，譬如设计分批给到重构，重构分批给到研发等，研发先进行后台模块的设计等。