总结了几个当年让我耿耿于怀的面试问题。首先，这些问题大部分出于传统软件项目公司，有些不适用于当下流行的互联网公司。因为互联网公司讲的是敏捷，快速迭代，拥抱变化，所以很多流程也就简化了，但是简化并不代表没有，一些方法论是的放之四海而皆准的。其次，这些问题都是开放性问题，仅代表一家之言，如有疑义欢迎留言。

怎样控制需求变更？

在项目中，需求变更问题最为突出。但对待需求变更的态度，不能一概而论。可遵循了解－变更－分析－评估－控制的原则。

了解：了解变更的业务细节，即功能变化，然后了解用户背后的真实用意。

分析：分析需求变更的原因，我总结了以下四种

1，用户在需求调研期间经验不足，项目组人员对业务也不熟悉，用户提不出合理需求，项目组也无法给出专业的意见。这种情况，用户看到系统模型出来后，或者试运行的时候，会有个需求爆发期。

2，用户见异思迁，随时竞品分析，随时有新想法。

3，没有抓住关键项目关系人，遗漏了需求，或者项目关系人之间需求产生了冲突。

4，客观因素的改变：关联系统升级，换领导，缩短工期，预算减少等。

评估：评估需求的重要性，难易度，紧急度，及变更对项目的影响。从PMBOK理论来看项目管理有四个制约因素：时间，质量，范围，成本。如果需求变更确定要做，必定是以牺牲这四者的一个或若干个为前提的。这个一定要跟用户说清楚，并得到认可的。

控制：其实就是流程的控制了，详见下一个问题。

举例子：

（面试时，先说方法论，然后举例说明；你不主动说，面试官也会问，积累几个例子是必要的，否则如果项目经验不多的人，一紧张就卡壳）：

第1种：我之前做过一个报销系统，需要打印报销单，报销单后面再附发票给财务报销。当初做需求的时候就说打印出来，因为财务用Excel表格多，就拍脑袋说打印成Excel格式。等到试运行的时候，财务发现收到的打印报销单与系统上审批通过的报销数据不吻合。于是要求，把Excel格式修改为PDF格式。但是正好我们的服务器原因，装不了PDF。于是我们分析下来，其实财务就担心员工修改报销单的金额，以为打成PDF就改不了。我们是这么解释的，我们公司是IT公司，如果有心要改数据，还能改不了吗？如果仅是预防不小心的修改，我们可以使Excel输出为加锁状态，至少可以防止不小心修改的可能性。后来经过多次交涉，财务还是同意了。在这里想说的是，谈需求的人，一定要立场坚定，自信满满。如果你的口气带有一丝的顾虑，就会被强势的用户逼上不归路。

第2种：给政府做项目，系统雏形出来后阶段性汇报，信息中心负责人大叫说你们的UI太丑了，别人的产品都有好几套皮肤。我们单位比他们级别高，用的系统还比他们丑，太没面子了。这种典型的见异思迁，关键还不是核心功能。会后我们也是极力说服，首先我们有更重要的功能要做，其次我们有了解过竞品，虽然皮肤做得好看，但是功能不如我们的好用。劝说用户应该把注意力集中在核心功能上。实再说服不了，就要用进度，质量等因素来给予压力。

第3，4种：难拒绝的需求。这种例子很多，比如项目做了一半换局长了，新官上任三把，提出创意点，下面的人就开始想功能。 某部门领导，做需求调研时，说没想法。系统一上线，想法很多。当然，有人说这个在敏捷里就不是问题，快速迭代，拥抱变化嘛！但我想说的是，即使是敏捷也不是需求随意变更的。

怎样实施需求变更？

PMOBOK中需求变更控制流程，跟信息系统项目管理师的理论大同小异：

了解变更{获得正式书面的变更请求}

综合评估变更影响

准备处理变更的方案

通知项目干系人

批准或拒绝变更

更新项目管理计划和项目文件

通知受变更影响的干系人

跟踪变更的实施情况

在没有系统学习这些理论之前，我有些点做到了，但往往又忽略了些你以为不重要的东西。而正是这些细节，在后面影响了项目进度。所以这些步骤，必须烂熟于心。举个例子：

我现在负责一个项目，我以前只做软件管理，现在还涉及一些module开发.这个模块指的是硬件设备，不是软件系统里的模块。在我们设备里有一个芯片，由美国Team来开发，每次固件升级也有走正规的需求变更管控流程。照理说如果这块芯片有重大变化，我们是需要知道的。但却没有人来通知我们Team。以至于测试组在做测试的时候，芯片crash的频率很高。后来调研了一段时间，把各种数据发给美国团队看。人家倒好，发了封邮件过来说，我们这块芯片要求的固件最低版本是118，你们现在的是98，明显不行呀！关键是，没人跟我们团队任何一个工程师说过这种问题啊。这种问题就是因为没有通知受变更影响的干系人引起的。因此强调下上面的变更控制流程每一步都有存在的必要性。

你不是说你会写PPT吗？给甲方做阶段性汇报，甲方高层领导也在场，PPT要怎么写？

这是一家乙方公司的副总问我的问题。首先我问，做的是哪个阶段的汇报，然后再根据具体问题具体分析。 我这里要强调的是，我一直以为阶段汇报是个坑，没想到那句甲方高层领导在场才是考点。当我把某个阶段性汇报的细节说完之后，面试官又重复了一句甲方领导也在场，这不算是会写PPT，我懵了。后来面试算是过了，但是给我的level 跟我想象中的有差距，我还是拒了。不过那次面试我回味了很久，后来领悟了。

沟通对象不一样，说话方式不一样。跟级别越高的人说话越是要重点简洁；跟HR说话，你说多点，她会觉得你很专业。

在这次面试中，为了体现我的专业知识很熟练，于是我事无巨细，面面俱到。但是他听了一会就打断我，说我在背书。（而其实我当时在职的外企单位面试我时，正是因为我的面面俱到，觉得我专业。也许是当时面试官级别不一样；又或是当初找工作时，工作年限不多，职位的level不一样吧；还有就是这家单位是国企，做事风格不一样。）

而后他又问给甲方做汇报，说领导也在场。我注意的是工作内容的汇报，但我相信面试官想听到的是说哪些内容给甲方领导听。比如说，做了这个系统给甲方单位带来了什么效益之类的。

项目实施受阻怎么破？

项目实施受阻，其实就是系统试运行，但是没人愿意用。系统要是没人用，再好的系统都走到了尽头。对于甲方负责人来说，单位花了那么多钱，确没给单位带来效益的提高，这个压力很大。对于乙方单位来说，如果系统没人用，最直接就是以后没回头生意了，如果项目实施很重要。做项目很多时候也是上层决策，而具体工作人员相当于数据的录入者，所以谁也不高兴增加工作量。

对此，首先试运行前要做好充分测试，保证系统质量；其次争取最高领导的支持；做好甲方单位操作人员，维护人员的培训；要准备好试运行方案，包括各种辅助管理制度，应急预案等。

这里两个小提示，1，培训不仅仅是开个大会培训就好了，培训会结束后，各种沟通渠道走起来。甚至需要深入一线。后期服务的到位，才能让系统健康运行起来。2，在系统上线前，项目组可以先放一批数据到系统里，有了数据的系统就有生命。在深入一线时，可以用这些数据生成各种报表，让工作人员认识到，系统的好处。

怎样做收集竞品？

这是一家私企单位问的，算是给我开阔了思路。之前一直是乙方单位、私企。这家单位不是专业的软件公司，但是有个比较大的软件部门，负责公司内部系统的研发。面试官问我怎么做竞品分析，主要是讲渠道，而不是说竞品分析方法。我回答：从市场部，客户那里拿到对手的方案；通过网络搜索试用版，视频演示。面试官给我补充了一条：在网上找到合适的系统，，然后打电话说企业有意向购买，叫对方先过来装个试用版。（在此我感慨下乙方有时就是这么可怜，这个方法仁者见仁了，我也不评价什么，仅给大家提供一个思路）

公司产品很多，业务部门都提需求，都说自己的需求很重要。产品经理那需求堆积如山，开发进度严重拖后，开发人员身心疲惫。如何让有限的开发团队来面对无限的业务需求呢？

这个问题来源于合资互联网公司，我觉得这个应该是产品经理怎么来确定需求的优先级的问题。如果产品经理没有很好的业务知识来判断需求的重要级别，优先级别，那我们就用数据说话。把需求都记录下来，问问需求提出者，这个需求做完后能产生什么效益。让对方给个数据，再把这个数据跟绩效挂勾。顺便提下，现在很多稍大的私企工资都是跟绩效挂勾的。外企也有，但是只影响年终奖，但是私企的话，直接影响当月工资或季度奖金，而季度奖很多都是从月薪的一部分。所以有了绩效考核制度，相信部门提需求时，会三思而行，这样需求质量也会高很多。

你做过的最有挑战的项目，成功的项目，学到最多的项目

这是一家私企单位问的，我觉得这种问法也很经典。一下子可以看出你的项目经验是否丰富，是否在项目结束时有做过经验总结教训。具体项目内容，还需大家自己去总结归纳了。

如何处理集体面试

一家大型外企，唯一一次碰到这种形式的面试。就是一个面试官，好几个面试人。不知道怎么表现自己，自以为很礼貌的听别人把话说完，最后发现自己想说的都被别人说完了。因为笔者经验不多，只想发表一下事后的感想。

1，在面试的时候听完别人的发言，能抓住重点。

2，如果要发言的内容，被别人讲过了。那就引用自身的经验来补充说明。