1.你认为项目经理是什么？主要职责？
项目经理需要利用沟通管理的能力，完成项目从启动、规划、执行、监控、收尾的全过程，保证在规定的范围成本时间下输出可交付成果。
项目经理需要负责项目全周期管理
- 包括对项目进行总体规划和阶段设计
- 分配项目组各角色的责任与权限
- 了解各成员的能力及技术擅长点，便于将合适的需求分配给合适的成员去处理，规避风险
- 需求评审时需要大致了解需求的难易程度及技术的侧重点，前期资源的给到时间，便于后期的需求分配，尽量减少等待的时间。而像前后台需要联调的需求尽量把时间安排到一起，方便前后台对协议。
- 组织团队周期会议、跟踪成员工作进度及质量
项目经理不是说把项目排出去就OK了，而是需要去掌握整个项目的进度，如果有风险要及时发现并处理 - 定期汇报项目工作进度。
2. 项目经理应该具备哪些技能？
- 领域落地：指将理论知识在项目中实际落地，需要具备该领域的配套知识
比如游戏管理至少要了解游戏的开发流程、盖楼至少要清楚从画图纸到封楼顶的整个步骤，这一条对于项目经理来说往往是比较难的，因为行业之间有门槛，一个房地产的高级项目经理，想做游戏项目管理，属于跨领域，他需要学习这个领域的知识才可以运用管理技术 - 个人能力：领导力，指导、激励和带领团队所需的知识、技能和行为，可帮助组织达成业务目标；
- 沟通能力，即人际关系技能
- 实际处理问题的能力：包括但不限于如何处理紧急需求；是否能够识别并控制项目风险；如何解决项目延期；如何处理团队冲突。
3. 如何处理紧急需求
确定真正的优先级
当我们遇到一个死限或者高压的需求，首先要确定时间、资源成本、范围、质量中究竟谁是最重要的，这真的是一个进度优先的问题吗，确定哪些是不可以被动摇的，以及哪些是可以协商的。
负荷度(加班)
尽量是项目成员感知到项目进度之后主动提出来的加班，而不是我们施压去九九六。
80%-90% 110% 120%(警戒线) ：正常打代码的时间一天是8小时，当达到110%的负荷度的时候，基本就是上限了。如果达到了120%，这时候就会发现第二天就会来的晚了，或者请假了，毕竟人的精力是有限的。
缓冲
压力越大时间越紧反而越需要缓冲，这个缓冲已经不仅仅是一个时间管理的工具，而是风险管理的工具。
- 有关缓冲的误区：
有了缓冲，估算可以马虎点；
太紧了，没余地留缓冲；
上次缓冲没用，这次也算了； - 缓冲的作用：
【1】应对需求变更
在互联网行业，变更几乎是很容易出现的，对于一些日常的变更，团队一般会采取加班来处理小小的变更，但当此时的负荷度已经达到110-120，就很难有多余的时间来处理变更，因此我们更需要给到这一部分的缓冲时间；
【2】应对估算不足
【3】应对请假
比如元旦和春节前后就会出现一些请假的情况。 - 缓冲包括：迭代内的缓冲，迭代间的缓冲
范围缩减
即使进行了上述的一系列操作，还可能此时实际进度很赶，需要风险的识别和风险的规避，此时需要一些预案规避风险。范围缩减作为紧急预案，列入风险管理。
项目经理需要懂业务，需求分析，用户视角提出一些可能的建议。
可以被缩减的范围：
- 用户在初始阶段触达不到的需求
- 少量用户才会用到的非核心需求
范围缩减需要与合作方沟通和确认。
是否采取预案，需要设定触发的条件和时机，也和迭代计划相配合。
采用了上述所有工具，还是赶不上进度，沟通是极为重要的。
沟通对象：关键干系人（如外部合作方，领导层）
沟通时间：整个沟通是连贯的，从立项开始同步。
过程同步-》风险预告-》及时坦诚
4.如何控制项目风险
- 首先要规划项目中可能遇到的风险，例如：需求蔓延、人员变动、技术难点、项目延期等；
- 其次要制定风险应对措施和流程，如何应对这些风险，谁来应对，谁来负责等；
- 再次要做好风险预警，发现有预警的苗头要及时控制，采取应对措施；
- 最后是风险出现之后要按照流程解决风险，并且风险的情况及时汇报给相关干系人。
5.如何解决项目延期
项目延期除去一些客观的因素，常见的延期的原因主要是以下几个方面：
项目预估时间偏差
这其实是最重点的问题，百分之六十以上的项目延期就是因为预估时间出现问题。基本上在需求确认过程中会开一个评审会，讲解需求并评审每个功能预期的时间。但是这个评审往往只预估了理想状态下的开发时间，忽略了一些技术难点，调试，联调，测试所需要的时间。或者开发前期设计稿重构稿ready的时间，开发过程中依赖的其他接口ready的时间。
针对这种问题的解决方案：
1.有明确的排期表，其中记录几个比较重要的里程碑时间节点，以及具体到每月每人的任务线，当然也是在对工作量有较为准确的前提下去完成这个工作。任务线确定了之后一但遇到首个任务延期的情况就要及时找出问题并且判断后面一些任务中可能遇到类似的事情。
2.确定项目结束时，每个人需要提交的东西。比如设计稿，交互原型，版本代码，测试报告等然后根据这个输出过程将项目分解成各个活动，并根据项目中活动的逻辑关系来排列活动顺序，使得各项目成员在其相应的工期内能够按时完成并给到交付结果，相应给到缓冲时间而不会导致衔接过程中出现等待的情况。
3.需求文档尽量描述详细，使得评估需求的时间能够尽量准确。控制后期的需求变更和新增需求。
个人能力水平差异
比如评需求的时候是leader去评估，但此时并不确定是谁来做这个需求。可能一个需求评估了2天时间，但其实是之前一个活动的复用+改动，但是在排期的时候，可能项目经理会排期给另一个人，但当前开发的同学对之前的逻辑都不清楚，光熟悉就需要一天的时间，这就会导致需求的延期。
或者同一个需求，高工做5天，一个新同学做依然5天，这样也是会有延期的风险，因为每个人本身对项目的熟悉程度以及各人技能是不同的。
解决方案：
1.尽量项目在评估时，能够确定开发同学，并根据其能力确定适合的评估时间。
2.若遇到紧急的需求，要按照时间情况将其分配给合适的同学。
需求变更或新增需求
很多时候在开发过程中难免会遇到对现有需求进行更变或者新增需求，可能修改点的工作量并不是非常大，但是积少成多之后也会对项目进程有一定的影响。
产品同学在前期尽量详细的描述需求相关信息，在开发过程中尽量减少需求的变更，即使有变更也应该尽早提出。对于项目末期的变更，尽量重新走变更流程，后期迭代。
开发或测试人员对需求理解有偏差
这种情况往往是因为沟通不到位导致的，沟通在任何团队任何项目中都是大问题，所有电话落实的沟通问题，一定要尽快落实到书面凭证，例如产品经理及时将沟通问题落实到需求单，避免后期开发和测试同学理解有误。
6.如何处理团队冲突
事实上团队冲突是不可避免的，项目经理要辨别出人的不同个性，向员工表述每种风格的价值，当冲突双方讨论试图分析申诉或冲突的原因时，应持有客观的态度沟通解决，针对问题就事论事，应多换位思考。
常用的冲突解决方案：
- 合作：合作是一种理想的解决冲突的方法。就是说冲突双方既考虑和维护自己的要求和利益， 又要充分考虑和维护对方的要求和利益，并最终达成共识。最后可以达到双赢的结果，形成大欢喜的局面。
- 妥协：是为了寻求一种解决方案，能够暂时或部分解决冲突，寻找能让各方都在一定程度上满意的方案，但这种方法有时会导致双输的局面
- 缓和：缓和是指努力排除冲突中的不良情绪，它的实现要通过 强调意见一致的方面，淡化意见不同的方面。缓和并不足以解决冲突，但 却能够说服双方继续留在谈判桌上，相当于求同存异，因为还存在解决问题的可能。在缓和的过程中，一方可能会牺性自己的目标以满足另一方的需求。
- 命令：以牺牲其他方为代价，推行某一方的观点；通常是利用权力来强行解决紧急问题，这种方法通常导致赢输的局面。
7.领导力具体是指？
在项目各阶段，项目经理可以采取持续强化各阶段目标的方式，来为项目团队指明方向。
动员人员，例如项目启动大会，激发斗志、鼓舞人心。
统一意志，传递信心和力量，统一团队思想和行动，努力交付预期成果。
8.影响项目成功的关键因素
用户参与：不接二手需求
高层管理者的支持
清晰的需求描述
9.如何处理需求变更
需求变更的原因
需求定义不准确；对需求理解有分歧
业务需求改变；项目周期过长
需求变更的来源
内部来源：产品考虑不周，设计变更，临时需求；
开发：技术方案变更
外部来源：老板需求；市场政策变化；
如何应对需求变更
【1】首先是摆正心态，应对需求变更的第一要点就是让整个团队都知道需求变更是经常发生的事，是再正常不过的事。
项目经理需要引导团队去思考两个问题：
这个变更如何处理；
下次如何预防这类需求的变更不再发生。
不要因为需求变更去争吵，不要去回避需求变更。
【2】预防为主，从需求源头做起
当团队摆正心态之后，接下来就是应对需求变更了。
客户口中的需求，常常会站在他们的立场上提出来，而且经常提需求的时候也提解决方案，换句话说他们对于什么是需求什么是解决方案分不清楚。举个例子，有次运营同学提出要在页面显眼的地方加广告位，经过沟通他们原始需求是想增加营销活动的用户参与度。但问题来了，不是每个营销活动都适合放到首页，每个营销活动对应的客户群体是不一样的。最后我们的做法是改进了广告位的显示逻辑，让不同的营销活动显示给相关的特定人群。
实际操作中，针对不同类型的项目，项目经理可以有如下的应对：
实施类项目：
在同时存在产品经理和项目经理的团队中，项目经理不要把需求沟通的工作全权交给产品经理，项目经理也需要参与到需求收集、理解需求、讨论需求。
尽量获得一手需求，站在项目落地风险的角度，帮助产品经理一起识别客户的伪需求和不合理的需求。要有质疑的勇气，否则等到错误的需求流转到交付团队，到时变更成本更高。产品类项目：
需求的相关工作以产品经理为主导，项目经理可以少操些心，但是当交付时发现需求频繁变更时，项目经理需要多留意需求分析阶段产品经理的产出物了。
【3】 重视原型稿评审，重视需求确认
- 对于实施类项目：把做好的原型稿和视觉稿尽早的展示给客户，并且和客户进行需求确认，邮件签字等确认方式均可。
- 对于产品类项目：重视原型稿和视觉稿评审。
要让问题在项目早期暴露出来，问题发现越晚，处理成本越高。
【4】预留时间buff
既然需求变更是不可避免的事实，那么项目经理在排期时就要留有一定时间的buff，这个buff的具体时间可以依照你对客户的认知，对需求的理解，专家判断或者与团队成员讨论得出。
【5】 接不接受变更，按照流程来
实施类项目：需要有一个是否接受客户需求变更的流程，收到需求变更后，项目经理组织团队先评估需求变更将产生的新成本，按照项目的具体情况决策是否接受变更。（由项目核心团队，或决策委员会bbc决策）
-
产品类项目：更多的矛盾集中点在要做的功能太多，资源太少。这时候制定合适的优先级规则就尤为重要了。
如果产品功能不多，涉及团队规模较小，一般就是产品经理、项目经理、研发和测试负责人组成的核心团队做决策即可。如果功能点较多，涉及的团队也较广，这时候就需要对优先级规则进行量化，一般从如下几个方面入手：
1）带来的新收入
2）影响的用户数，
3）提升用户的活跃度，
4）投入的人力成本，
5）投入的时间成本，
6）功能的权重。
简单来说就是哪个性价比高先做哪个。
有了功能的优先级之后，再根据现有功能实现的具体进度，挑选哪些功能往后放，新出现的需求插到哪个版本里面去。
【6】从四要素思考处理方案
如果团队决定接受这个需求，那么接下来就要看团队怎么处理这个需求了，项目经理可以从四要素出发，看下能改变哪一个要素
- 是降低系统的质量要求？比如留些bug以后处理
- 是改变项目的交付范围？比如多了一个进来总得砍一个出去。
- 是延长项目的交付时间？
- 还是改变实现功能的方式？
另外，重要的是需要将变更的后续跟进方案同步到整个团队，并且存档变更记录。
经常遇到小范围讨论完就改掉的情况，但测试人员并没有通知到位，导致上线后才发现问题，项目经理需要有机制去避免这种情况。
