短短一周的时间，就有将近百位学友参与黄金问答活动，老学友们结合实际工作场景给出了条理分明、贴合实际的解决方案，非常感谢这些管理经验丰富的大咖们的慷慨解答，也感谢工作上有困惑的伙伴提出了自己的问题。
在这里和大家分享一下这一周来的优质问答汇总，希望能从他人视角和看法中找到适合自己解决方案。
作为奖励，参与提交问答表单的学友，Amy都将在4月10日以前为您积攒相应的积分。
01
项目管理篇
Q1：大家一向认为需求变更对开发商或集成商来说是个非常负面的因素。然而在软件项目管理过程中，时常面对用户的需求变更，如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，用户的耐性渐渐消逝，研发人员的势气也越来越低落，最后所有人都在等待一个结果：项目最好马上结束。面对以上情况，项目经理如何做好项目需求变更管理，并提升项目团队的势气和积极性?
Q1精彩回答如下：
张瞳：
首先这个问题的根源是项目启动阶段需求不明确。在项目启动、合同签订阶段明确项目范围、内容，最好可以将项目分为咨询设计阶段和软件开发阶段，在咨询设计阶段就明确项目范围及需求。这样可以避免在项目需求变更中，甲乙双方账户扯皮的问题。
其次，在项目初始阶段需求明确的情况下，项目进行中产生需求变更，需要明确是真的需求变更还是产品质量的问题。如果是需求变更，需求变更要有明确的需求变更记录，需要重新评估时间和进度，双方打成一致意见。
第三，如果是产品质量问题，比如有些该有的逻辑、表单查询功能，则需要项目组进行评估工作量，赶工或者增加资源完成。
宋春伟：
1.做好工作任务书，确定项目范围，明确工作边际减少镀金和范围蔓延的情况出现。
2.严格把控需求变更，做好变更文档记录，需求变更需要提前评估影响，严格执行变更流程。
3.阶段性交付产物，项目启动之初，划分项目阶段和里程碑，按里程碑阶段进行项目交付以提高项目成员对工作成果认可。
郭文晋：
任何项目需求变更在所难免，重要的是如何评估变更所需要的effort,对项目时间，质量，成本的影响，充分跟相关干系人沟通（客户，项目组两头），最终针对变更内容及新的项目计划达成一致。
对于因为项目范围变更对项目团队带来的负面影响，应该充分了解客户对变更需求的目的，对整个business的好处，用这些来激励团队，让大家知道实现这些变更带来的价值。
周岩：
1、明确交付边界：需求变更很大的原因是因为在项目创建之初提出的项目范围，甲方不是很明确，结果到了项目中后期，甲方发现这不是他们需要的东西，于是提出了需求变更。这个时候，需要选取一个时间，跟甲方以及相关干系人整体开一个会，重新明确项目边界，交付范围，甚至要加上验证方法。先划一道线。
2、留存好需求变更记录表：理论来说，每一次需求变更都代表进度或者成本的变化，这两种变化，在使用需求变更表之后，可以明确的找客户增加费用或者时间，这样我们在项目上就不是一个被动的位置。
3、阶段交付，带甲方一起玩，让甲方有参与感，阶段交付是敏捷开发的一种核心手段，有两个好处：好处1：当甲方知道你的开发进程的时候，他就会有参与感，时间长了他就会帮你来想一些事情，提前发现问题或者减少需求变更；好处2：由于甲方提前入场，也会不断的提出反馈，这些反馈都会刺激到自己的开发，自己开发得到反馈之后，知道自己开发的系统有人再用，就会觉得自己有价值，情绪也会相对好转。
大概就以上3个办法：划一条线，消除被动，客户参与。
王心诚：
您好，您提的这个场景我亲身经历过，也做过总结，针对您提的这几方面说一下我的想法：
1.您对需求变更的认知有些片面，需求变更不一定就是负面的，也可能是正面的商机，也可能成为与客户谈判的筹码，引来新的投资或项目，当您第一印象就认定负面的话，很难把事情做好，还会因此丢掉有利的一面。
2.对于需求来说，跟计划一样是渐进明细的，所以变更在所难免，根据您的描述，感觉研发团队过早的接触到了需求，在实施过程中可能缺少了必要的评估和谈判环节，拿到需求变更后，要清楚客户为什么提，要解决什么问题，这个需求都考虑了哪些方面等等，有倾向性的做评估，有目的性的做谈判，可以在范围上就削减掉不必要的工作量。
3.要明确项目目标和客户目标，以及二者的偏差点，围绕目标来做文章，贴近核心目标的主动做，中等距离的协商做，偏远距离的尽量不做，放入后续项目中。
4.寻求项目组外部的帮助，比如有的客户有业务部门和技术部门，也有相关流程，满足合规性要求的，或者公司领导和销售参与配合。
5.寻求工程负责人的帮助，最好是会议形式，领导一般会抓大放小，关注效果和工期。
6.最重要一点，是留痕，一定要留痕和落地，口头和微信都不能算正式的需求提出，对于避免不了的需求变更，要分析好影响，严打需求反复，在项目例会上可选择性提出。
7.团队的士气和积极性，和需求变更没有必然联系，可适当的团建，做好工作任务方面部署，关心团队成员生活和期望，适当设定奖惩规则等等，都可以改善团队氛围。
临时就想到这么多，希望可以帮助到您。
Q2：工程项目管理中常见的“老赖”，本属于其合同范围内的工作事项完成一小部分后就找种种理由拒绝继续履行合同要求，申请增加资源和时间投入等等。因项目交付节点在即，投资人不得不追加资金投入造成成本超支，该如何处理？
Q2精彩回答如下：
刘明明：
我理解这个问题是在问投资人该如何处理，下面是我的一些思考。首先我们要尽量在合同里把工作内容，交付时间，付款条件，违约责任等写清楚，俗话说先小人后君子。后两者可起到震慑作用。之后要保持对项目的控制，譬如定期跟踪进度等，让对方看到我们是在严肃认真的做这件事，以维持相应的震慑。如果拖延会导致对方收不到款，甚至赔偿，对方通常会比较严肃认真的看待。当然，我们要维护两个及以上供应商，确保谈不拢的情况下可以有新的供应商接盘。另外要注意生态系统的建设，建立一个良性的循环:合理的报价，专业的施工，双赢的完工。过低的报价很可能带来这样的局面，选供应商的时候要慎重。
吴长宇：
1、合同条款做好约束，条款细节，明确罚则。
2、老赖建立名单，加入到供应商黑名单。
3、约束面前不乏人情，做好私下沟通。
4、项目计划制定上，预留风险。外紧内松。
陶钧：
加强竞争，对此类乙方可以建立类似合格供方清单类的列表，需定期记录、评价和动态调整，结合评级和惩罚措施。同时对合同进行分类管理，这种乙方需加强管理，结合定期下厂监制、飞行检查等措施。如果都不起效果，而他又不是唯一供应商，取消阶段供货资格，再犯指数延长取消资格等。
王鑫：
在我工程项目管理过程中，该现象确有发生，但不属于常态。我觉得这个问题解决起来应当相对系统来看。首先，扩大战略集采范围，所有供应商都不应该是只签一次合同，只有一次履约，从长期合作上和从更大纵深上给与一定约束。其次，如果确是第一次合作，适当在其进场前做好策划方案审批，明确要求，确立奖惩，奖惩都要做到，可以用一些不上台面的手段，把奖惩落实下去，起码要让供应商明白我们可以落实下去。再次，建立适合的约谈机制。最后就是对总包的把控，让总包可以为我所用，可以临时补上，留住后路，在对该单位不给力时有后补可以上，如果你说的是总包，那就要提前签第三方劳务公司，可以随时补上的那种，不一定要用，但是制约力很强。以上，不成熟的见解，请指正。
Q3：我遇到的是视频会议管理，目前我们公司有80多个视频会议室，很多视频会议室前期并未按照规范建立，都是个性化的。 现在如何快速的进行视频会议的统一规范管理，比较头疼。需要从建设、标准化运维以及后期维护方面入手。另外就是如何很好的进行日常的运维监管？后续运维是统一运维还是各自运维？
Q3精彩回答如下：
张瞳：
1、出视频会议室管理制度，从公司层面明确视频会议室的管理方法和形式。
2、对所有视频会议室重新规划，确认哪些是统一管理，哪些是由各部门统一管理。
3、对视频会议室的用途，使用客户群进行划分，并对视频会议的软件，硬件，网络进行划分，进行资源统筹和使用。
宋春伟：
1.梳理当前每个视频会议室基本情况，设备，网络，座位，楼层等等信息。
2.制定视频会议室预约制度，明确预约时间人数。
3.落实会议室设备资产卡片，定期盘点。
4.制定每个会议室检维修计划，落实到相关部门。
王心诚：
您好，针对您提的问题，我阐述一下我的看法：
1.先要明确总体思路，针对这些会议室求同存异，把相同的地方做成标准化，差异的地方做个性化。
2.第二步做标准化，将个性化的会议室逐步切换成标准化
3.运维也是这样的思路。
很多事很难一步到位的，都需要先适应再改变，希望可以帮到您。
Q4：我们给客户做的软件产品实施项目，客户要求配合梳理需求，可是如果梳理需求上线工期无法保证。不梳理的话客户自己提供很慢，也会影响工期。怎么处理更合适？
Q4精彩回答如下：
刘明明：
是否可以将 配合梳理需求 当做一个变更来处理？即列出为了完成这个变更，我们需要额外花这么多钱，延长这么多时间，让客户自己决定要不要你们配合。要的话，工时就相应的延长了，不再是问题。不要的话，按原计划走。如果客户自行梳理后改需求，这又是一个变更，可以继续聊需要增加的钱和时间，让客户自行决定是否更改。
张瞳：
这个问题，归根结底，是软件实施前有没有咨询及流程梳理合同的问题。
如果软件公司有话语权，直接与用户签订咨询及流程梳理合同，调整项目范围及工期。
如果软件厂商没有话语权，还是战略投入项目，那就与用户沟通好需求梳理的时间及工期，如果客户同意时间和工期，那就做项目变更，如果客户不同意，可以让用户引进外部资源，比如咨询实施公司。
最终建议是在项目前期梳理好需求，并签订需求分析报告。为需求变更提供依据。同时前期明确需求，避免项目因为需求不明确而进行的返工。
范清清：
一: 肯定要梳理，如果不梳理，本身客户梳理比较慢，而且容易出现反复和超出范围的情况;
二: 建议在合同中约定梳理需求的时间段和交付形式，通过正式的评审或汇报确定需求，避免后续扯皮和推诿;
三: 可以分期交付，每期完成交付后，交客户使用同时再次回顾后续需求，尽量在开发实施之前控制相应的变更;
需要双方互相理解和支持才能顺利完成项目
吴长宇：
1、如果此项工作属于计划内内容工作，说明计划不合理，未合理安排。申请变更计划。
2、如果此项工作属于计划外内容工作，申请项目范围变更，调整投入和时间计划。
3、按合理的项目管理方式开展，不要把问题自己消化，公开讨论、明确责任。有利于项目下一步开展。
吴坚：
这种情况下以为采用敏捷开发较为合适，派出产品人选同客户梳理需求，这个是必要的，因为是后续项目开展的前提。然后项目团队根据产品人选梳理的需求快速迭代开发。周期性与客户确认阶段性交付结果，需求的澄清与项目的开发错峰并行，可很大程度上提高项目进度，周期性地与客户确认阶段性成果，也减小了最终交付与原始需求不一致的风险。
Q5：工程项目管理中，安全与进度，质量与成本，常常是一对矛盾，而各种复杂的工程关系很难做好各方面平衡，如何客观评价项目各个目标的实现。安全做的很好，进度没确保。质量做的很好，可成本突破了。这种情况如何处理更加合适？
Q5精彩回答如下：
赵鹏健：
质量、进度、成本本身就是互相矛盾 互相制约，首先质量是肯定要保证的，我们通过合同或者行业标准，质量标准采取对照检测及监控，发现问题修复问题，避免返工，对进度造成影响。其次是进度要编制出进度计划，按照计划于实际进度相比较，找出问题，进行调整措施，避免工期延长造成成本超支。成本控制做好按照资源分配，时刻调节。
张宝栋：
质量和成本之间的平衡
事前和相关方一起进行成本效益分析.、质量规划，找出质量和成本之间的最优平衡点，尽量用最少的成本做最适用的质量，并在相关文件中明确。
安全和进度之间的平衡
在工程项目管理中，安全生产至关重要，绝不能在牺牲安全的前提下缩短工期，在日常工作中要加强安全生产培训、检查等工作，使企业形成一套管理体系和文化，对于如何保证进度，可事先制定进度计划，加强流程和过程管理，并优化资源调度能力和进度规划水平，让资源配置与进度关联起来；对风险点提前制定应急措施和缓冲区，保证时间安排的合理性。
庞梦远：
这个问题涉及到怎样衡量一个项目的成功。根据P2里面的定义，项目是经过商业可行性论证的。这里的商业可行性论证主要是指项目的目标与预算投入是需要匹配的。否则，没有成本保证的项目，肯定是失败的项目。
02
产品管理篇
Q1：在各部门提出的产品需求出现矛盾的时候，如何进行调节和平衡？
Q1精彩回答如下：
魏中辉：
首先与各个部门负责人进行沟通，获取清晰的产品需求和优先级；
其次进行归纳总结，对需求进行分类整理；
最后召开各个部门负责人参加的会议，大家统一共识。
陶钧：
可以看看是否互相之间是矛盾的，是否存在方案能够解决这两个矛盾体，如果确实解决不了存在直接性矛盾的话，可以底下先让各部门进行平衡，如果实在确定不了的话，可以提交交公司的技术委员会或者产品委员会进行决策，当然在提交上回之前，我们需要对它进行一个排级，排优先级的时候需要一些量化的指标，而这些指标的话应该是比较有代表性的。
Q2：需求提出的很散乱，而上线时间要求很严格，没有时间进行需求调研和分析，却又希望保证高质量，如何平衡？
孙大为：
引导需求方和领导确认必须要做的需求，标注优先级。建议使用tower等办公协同软件把进行中的和即将做的需求都分别列出来，告诉需求方或者领导他们的需求讲在哪个版本上线。在仅有的时间内只完成最重要的优先级高需求点，剩余需求由后期迭代完成
Q3：和老板对产品规划意见不合，如何提升向上管理能力？
Q3精彩回答如下：
李建辉：
首先要明确和老板的产品规划是哪个层次上的分歧，是战略层次的还是具体产品功能或者形态上的，如果是战略层的就需要和老板站在同一高度审视问题，前提是你尽量多的掌握同样的信息，才能在同一层次讨论，如果是产品层次的需要自己有充分的调研和数据。
孙大为：
方案一 引导老板用 用户的眼光去看产品规划；
方案二 用数据说话，告诉老板咱们的不足，应该优先处理哪个模块的需求优化，而不是做新需求；
方案三 做用户反馈系统，定期整理给老板看哪些问题提的多，根据用户和市场的导向不断修正自己公司产品的规划；
但要注意领导的需求也是需求可以变化方式完成，不要全部拒绝。
需要提升的是与领导沟通的能力。
Q4：小公司一般不会专设产品经理，项目经理通常也扮演产品经理的角色，这类“兼职”产品经理在现实的项目经历中如何更好的履行产品经理的职责？
陶钧：
首先要明确和老板的产品规划是哪个层次上的分歧，是战略层次的还是具体产品功能或者形态上的，如果是战略层的就需要和老板站在同一高度审视问题，前提是你尽量多的掌握同样的信息，才能在同一层次讨论，如果是产品层次的需要自己有充分的调研和数据。
产品经理跟项目经理的职责本应该是分开的，因为产品经理更多的是代表客户表达对于产品的一个诉求和需求，是价值，而项目经理更多的是代表团队需要提高团队的效率。
如果实在是因为公司的安排导致两个岗位重合，而且需要说怎么做好产品经理的话？也就是说侧重做好了产品经理，这样的话可能在产品方面要投入更多的精力。
同时做需求这块的事，其实很多时候一个公司的产品经理并没有做需求决策的能力，或者说没有这个资格，很多时候是有提出去一个需求清单排列好，由产品委员会或者公司决策委员会来共同决定一些事情的。
Q5：客户需求变更频繁，有一些明显不合理，回绝之后。客户找领导，领导直接答应，遇见些没底线的领导需要如何处理？作为产品经理，既要对产品负责，又要对领导和客户负责，遇到这种情况该怎么处理好呢？
庞梦远：
首先，出现这种问题的原因在于权责不清。产品经理对产品负责，领导对结果负责。应明确跟客户说明。其次，建立需求变更评审委员会，规范客户提的需求。最后，大家目标一致，遇到问题先充分沟通后再做决策。
03
敏捷管理
Q1：我是做软件测试的，公司在采用敏捷管理方法，虽然敏捷测试比起传统的测试方法存在着许多优势，但它也有不足之处，其中之一就是有时它会在每个Sprint临结束时对质量保证（QA）团队产生了过多的压力，最终可能会导致Sprint的溢出。我对敏捷接触不深，想请问下，这是个必然的弊端还是有解决之道的呢？
吴坚：
Sprint工作的溢出应该发生在中后期的阶段，估计是因为随着sprint的增多，交付工作的增多，需要测试的用例越来越多，从而导致测试时间的不断增长，所以sprint中的工作就会溢出。我个人理解这不是必然弊端，而是敏捷开发过程中的伴生现象，传统的开发过程是在项目开发完成之后统一的测试周期进行测试，所以时间是可计划的。敏捷开发中的测试工作可以对用例做分级管理，并在每个sprint与开发团队沟通测试用例的测试优先级，这样可以保证每个sprint的测试时间不溢出的情况下测试到每个sprint优先级最高的用例，从而对整体的交付质量做到最大的保证。当然所有开发完成之后可以整体组织一次回归测试，不过这取决于之前的测试发现的缺陷情况。
Q2：我们公司属于传统行业，近期领导想要引入敏捷管理方法，拿我们团队作为试点。然而实际工作中团队成员好几个都不愿意更新Sprint Blacklog,每日站会也表达模糊。虽然流程上都是按敏捷方法在实施，但实际效果却始终差强人意。有什么方法可以帮改变现状？
陶钧：
这个问题要是先弄清楚，到底是团队成员不知道怎样去更新迭代代办事项，不知道怎样去站会表达；或者说是知道怎么表达，就是认为这件事没有价值，所以就不去执行；或者是其他的什么情况？如果是第一种情况的话，是对游戏规则不太了解，需要教练带着走一轮，让腾讯熟悉一下情况，等团队熟练了，以后再要团队自己操作。如果是因为po对产品代办事项解释的不清楚，导致迭代代办事项不够好的情况下，就需要po解释清楚。总之，先弄清楚原因才是后面找到解决问题办法的源头。
Q3：我公司团队在组建之初开发是十分敏捷的，几乎每个人都能独当一面，能够解决各种各样的问题，而且一个产品从策划到上线的时间周期都很短。然而，随着产品的逐步成熟，团队的逐渐壮大，遇到了各种各样的问题，原本敏捷开发的团队似乎消失不见了，各类角色引入后团队效率不增反降。是由于敏捷开发只适合于小公司小团队，还是说我的敏捷方式需要Update呢？症结何在？求解。
吴坚：
看起来关键是各角色的引入导致了效率的下降，问题中没有明确说有哪些角色，不过看起来是增加了决策的流程节点，估计初始目的是为了把控质量和提高交付水平，建议对此种决策过程做出调整，找出各种限制条件下可以接受的最优情况。
Q4：如果领导不熟悉敏捷理念，在团队中推广敏捷实践，可能会困难重重，想把敏捷落地，敏捷的做法和理念会和领导带团队的领导方式相冲突，在这种情况下，敏捷适不适合这个团队？这个团队还要不要做敏捷？该怎么打破这个局面？
陶钧：
如果说领导不熟悉敏捷概念的话，敏捷是比较难实现的。这个时候不能说就不去做一件事，因为他有难度，应该可能对你领导要进行一些培训，而且要请领导们营造一个敏捷的环境，让大家都了解这样去做敏捷，这样才能事半功倍。
Q5：Agile在电信级产品的研发中不是特别适合，应如何分解大项目，使Agile更有效？
吴坚：
是否使用敏捷，个人认为取决于是否需要，而不是为了敏捷而敏捷。个人的观点认为两种情况下适用，一是需求的高度不确定性，导致没有办法按照传统的项目流程进行开发，所以就将可明确的需求进行整理并交由开发团队开发，从而尽快地推进项目的进行；二是为了周期性的与客户确认阶段性的交付成果，让客户及时了解项目的进展并确认交付满足客户需求。具体到电信产品的研发中也可以适用，可以采用功能块分解任务的办法，比如以流程的跑通来定义sprint，之后再骨干功能完成的基础上不断地丰富周边功能。
04
团队软技能篇
Q1：在一个咨询项目中，一名团队成员被委派担任现场负责人角色，在项目管理过程中，就项目问题解决方案时常采用头脑风暴的形式讨论后决议。现有另一名工作资历和项目管理经验比现场负责人深的项目成员，时常会提出个人的项目实战问题解决方案，并对项目负责人的某些方案提出异议，风头明显盖过了现场负责人。对于以上情况，作为一名合格的项目现场负责人，如何进行有效的项目管理和项目团队成员管理？
Q1精彩回答如下：
周文玲：
1.私下与现场实战经验强的人沟通，尊重并采纳部分意见，同时头脑风暴的决议，加上该人的意见综合考虑去践行。
2.加强团队凝聚力，作为负责人需要考虑每个人的感受，为加强对每个人了解，多聚餐了解下每个人的经历。
3.将头脑风暴的方式换成不记名投票，让更多好建议被采纳且去实践。
吴坚：
头脑风暴的讨论形式为单独沟通。与项目组成员沟通之后，根据团队的意见形成最终和最优的方案，并付诸实行。对提出有效见解的项目成员给予鼓励和肯定。
Q2：在项目进行过程中，经常遇到下属抱怨。公司亦无法满足员工激励。这时应如何做到有效沟通，保障项目正常交付的同时，满足下属员工的激励需求？
周文玲：
1.私下与现场实战经验强的人沟通，尊重并采纳部分意见，同时头脑风暴的决议，加上该人的意见综合考虑去践行。
2.加强团队凝聚力，作为负责人需要考虑每个人的感受，为加强对每个人了解，多聚餐了解下每个人的经历。
3.将头脑风暴的方式换成不记名投票，让更多好建议被采纳且去实践。
Q3：受困于公司体制，项目经理权限很小，因而在项目推动过程中，难以充分调动干系人的动力，因此当在职能型矩阵的体系中，如何发挥干系人的积极性和主观能动性？
吴坚：
这是弱矩阵型组织面临的主要问题，项目经理没有被充分授权，或由于历史原因的惯性导致项目推动能力不强，个人意见是将相关干系人的利益诉求纳入项目管理的任务之中，将之关注点作为项目的任务去执行，从而加大干系人对项目的关注度。
Q4：团队管理时，如何平衡老员工的指导作用与新员工的执行能力带来的绩效评价？
Q4精彩回答如下：
周文玲：
老员工的经验不一定都能适用现有的项目，所以需要根据实际情况分析并采纳。新员工执行过程由于经验欠缺，对于问题处理没有实际有效方法，处理问题总是会很慢且延期。老员工带新员工，加强团队凝聚力，整体提升团队人员工作效率。
魏中辉：
对于核心员工要积极尊重其工作能力，使其发挥相应的带头作用；对于新员工要鼓励其学习能力和执行能力，使其迅速成长。
Q5：现在的项目过程较短，人员滚动复用率较高。如何能在多个微小项目之间更加合理的分配资源？
Q5精彩回答如下：
刘明明：
将这些项目适当归类，变成项目集，尽量项目集内复用人员，降低大家对流动的感受。
吴坚：
使用资源管理矩阵，将资源在项目上的时效性进行精细化管理，从而做到各个项目的精准资源使用。
在活动期间，每天下午Amy也发起了话题讨论的小社群，鼓励学友进行每日管理话题研讨，感谢参与的每一个伙伴，利用空隙时间，相互交流分享经验，不断提升自我。Amy会给予参与讨论活跃度最高的学员PDU奖励，获奖者Amy会在4月11日前单独私信~
不少学友提出了新的管理问题，点击“阅读原文“快来帮帮他们吧！给出你的建议~