项目范围与客户需求管理失误，导致项目经理面对棘手问题

（一）项目范围与客户需求管理

项目范围
项目范围是对项目所期望的最终产品和可交付成果，以及为实现该产品和可交付成果所需各项具体工作的简明描述。项目范围的确定为成功实现项目目标定义了恰当的范畴，即规定或控制了具体的项目。恰当的范围界定对于项目成功是十分重要的。
项目范围定义是以范围规划的成果为依据，把项目的主要可交付产品和服务划分为更小的、更容易管理的单元，即形成工作分解结构(Work Breakdown Structure, WBS)。因此，范围定义的输入主要有：
项目范围定义是以范围规划的成果为依据，详细描述项目和产品的过程，并把结构写进详细的项目范围说明书中。
范围说明书： 这是项目范围规划过程中的主要输出成果，包括了前述的项目的合理性说明、项目成果描述、项目阶段目标、项目可交付产品或者服务清单等内容，是范围定义过程的主要依据之一。
制约因素： 即对项目组行为进行限制的因素和条件，如项目预算、范围、时间等。
前提条件： 即为了制定项目计划而必须假设能够在将来获得解决的一些条件，这些前提条件一般都是真实的、符合现实的、肯定的，也是可以解决的，但也存在未能如期解决的风险。
其他计划结果： 其他领域内的结果也可以作为确定范围定义时的一个参考因素。
历史资料： 其他IT项目或者相关项目及相关领域内项目的历史资料，也是在进行项目范围定义时参考的因素。
在进行范围定义时，经常使用的工具和技术有：
产品分析。每个应用领域都有一些通用的方法把高层的产品描述转变为切实的可交付的成果。产品分析包括许多技术，例如产品分解、系统分析、系统工程、价值工程、价值分析和功能分析等。
识别出多个可选方案。识别出可选方案是一种技术，该技术用来产生执行和完成项目工作的多种方法。在这个过程中可应用很多通用的管理方法，例如“头脑风暴法”和“横向思维法”。
专家判断法。每个应用领域都有一些专家，其经验可用于定义详细的项目范围说明书。他们的判断和专长可运用于任何技术细节。
一般，当完成项目范围定义后，下一步将根据项目范围说明书等，制作工作分解结构WBS。

需求管理（Requirement management）是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题，所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。 需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最
需求管理相关图片
需求管理相关图片
终产品同需求的最佳结合。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。
需求管理本就是一个动态的过程，离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。

（二）项目经理的棘手事情

项目实施小组组长刘冬华最近遇到了一件棘手的事情。客户方面的陆经理提出：你们的系统是英文界面，这是没法通过验收的，你们必须提供中英双语界面，因为系统日后的使用人员可能英文水平有限，如果没有中文界面，系统就不能正常使用。
　　而且，陆经理不打算为此增加额外的项目预算，原因有二：首先，你们当时投标的时候明确说过系统支持双语界面，所以我们公司的人都认为系统会提供双语界面，现在只有英语界面，这说不过去;第二，我们的项目预算已经确定，不可能再增加预算。我们之间是合作关系，如果非要斟酌合同的条款，那么可以，我们走正规的商务和法律途径。当然，我们希望能彼此理解互相配合，因为我们合作的路还长着呢。
　　刘冬华知道，如果不满足客户的要求，客户就不会验收项目，那么公司就会认为刘冬华的项目有问题;如果满足客户需求，则至少需要延误一个月时间，还需要聘请专业翻译公司，而项目中根本没有这笔预算，向公司申请这笔预算很可能会遭到领导的喝斥。
　　假如你是刘冬华，你怎么办?

分析：由于管理过程中出现疏漏，导致交付给客户的产品功能不全，既然是合同中提过支持双语界面，那么一定要完成。
此时需要由公司高层了解到项目现状，并申请资源继续完成功能，与客户验收方协商延期验收交付，并提示公司领导以项目交付验收为重。保证公司好的口碑，以待与客户今后有更多合作。

分析：这个属于对于最终交付产品，客户和项目方的理解有差异，没有最后的交付产品做出明确定义。我们也碰到过类似问题，跟客户协商、积极沟通，明确对于合同中交付产品指标的具体定义，并针对客户实际需求，设定新的交付指标，进行后续的变更方案，延长交付日期，成本这一部分双方协商解决。

分析：问题是因为在项目计划过程中有所遗漏导致的，提供中文界面已在合同中有清晰的规定，结合客户的态度，无论是否诉诸法律，该功能最终都是要交付的。
可以跟客户了解一下交付的紧急程度，如果对方并不急于验收项目，可以在接下来一个月里集中资源将该功能交付。否则，与客户讨论交付计划，先将已实现系统进行验收，后期再交付一个升级版本。

分析：合同范围约定必须提供的话，则说明目前没有形成客户满意的可交付物，则进行变更流程，达成交付物目的为先，尽管由此带来成本的增加。至于内部流程问题不宜暴露到客户面前。另外项目经理的一个重要任务是维护和客户的合作关系，因此走法律程序应视为消极的沟通方式。

分析：在这个案例中，在售前沟通时就已说明是双语合同，客户在验收过程中要求这点很正常，问题在与售前与售后没有充分的沟通，售后在研发过程中也没有注重合同要求，刘冬华一方面应及时向上级反映这个问题，说明问题的严重性，另一方面及时与客户进行沟通，选择一个折中的办法先进行验收，验收的过程中，对客户进行英文界面讲解，让客户对操作有基本的认识，同时加快翻译工作。

分析：为了满足客户的交付质量和交付进度，可以与客户协商，目前如果完成汉化功能，确实在目前的要求进度下是无法完成的，与客户协商在之后的售后服务中，做一次免费的汉化升级服务，同时在本次验收时提供免费的操作培训，包教包会。   

分析：这个问题出的莫名其妙，项目前期的需求范围审核哪去了？报价阶段中文版有没有报价？确实有这个问题了：1去找合同中说明不提供中文版本的漏洞，和客户协商分担成本 2没有漏洞 乖乖找领导汇报情况，挨喷，老实把中文版给人上了（别折腾来折腾去说明不是个人的责任，谁的责任干系人应该都知道，先扛着吧，会记你好的）

分析：对于刘冬华来说其实这其实不是什么棘手的问题，刘冬华只是一个实施小组的组长，这种问题应该没有做决策的权力吧。关键是要及时把情况反映给项目经理，并提出解决这个项目的一些方案，由项目经理或者公司高层来做决策，刘冬华按照公司的决策执行就可以。
这时候千万不能应为怕被公司责怪而拖延或者不把情况上报给上级，一定要第一时间说明情况。

分析：首先分析双方确定的项目范围，如果双语是在确定的项目范围内，则重新调整项目进度计划，并就由此出现的风险与客户做好沟通；如果双语不在确定的范围内，则与客户进行沟通，重新立项或者进行项目范围变更。

分析：在將問題上升到公司的層面前，需要先檢驗客戶需求文件，客戶對軟件的定性文件，從而確定到底是自己公司出現漏洞還是後續的客戶要求變更，解決方案如下：
1. 如果是自己公司在前期評估客戶需求文件時的紕漏，則此問題最大的責任人為項目經理，故需要速安排上報給公司上級&高層(把問題提升到公司的層面），主動站出承認錯誤，然後將已經準備好的糾正措施供高層決策。並主動跟客戶道歉(需要與本公司的高層人員一起面對)，釋放更新的計畫，驗收日期(可適當要求其先驗收中文版本，可適當說明：需要待中文版本驗收合格之後再找翻譯公司將其做成英文版本,及中文版本是基準)，然後再定義英文版本的計畫，驗收日期)
2. 如果是客戶要求的變更(在前期客戶沒有此要求，而是後期加入),在此問題最大的責任人為客戶，故也需要上報給公司上級&高層(把問題提升到公司的層面），然後將變更產生的相關成本，時間等都羅列出來，將更新的計畫定義清楚，然後再與客戶陸經理以上其公司人員進行溝通，最後得出具體的決策。此過程中需要重點注意：a. 需要提前將部分內容通知陸經理，讓其提前知曉；b. 爭取在兩個公司間做成”雙贏“，及不能為了此事情而影響到兩個公司的長期合作，後續合作，及要適當把握談判&處理問題的度.
以上为黄先生的回答比较全面：
刘冬华所面临的处境可想而知，问题肯定以及确定是刘冬华身上。
假如是我，我会按照黄先生说的之外增加1点
1、由于以后的长期合作，我会想尽办法说服陆经理是否先行验收，后续以补丁方式再发中文板，并承诺一个月内完成补丁。

分析：必须按项目合同条款执行，提供双语或中文界面。针对处理该问题带来的费用问题，应将事件提请公司层面讨论解决；针对周期与客户协商。
针对界面汉化的内容需与用户共同探讨，并不是所有的内容均需汉化，以较少工作量、缩短周期。若有后续项目，可在后续项目中逐步完成。
项目是双方共同的，本着更好的执行好项目的目的解决问题。
以后项目开始时，要作好项目范围界定，项目执行过程中，要作好质量检查。在项目里程碑处，要作项目合同需求达成情况的确认。

分析：1、研究招标文件和双方的合同,确定是否存在双语界面要求；
2、将事情的状况上报公司，并得到公司的指示；
3、与合同部一起跟业主就此问题进行有效沟通；
4、组织项目部人员对中文界面进行优化,尽可能降低成本.
5、增加该项目资源减少时间的拖延，并且最好保证质量，同时在修改时多与对方沟通，每次确认务必让对方确认。减少不必要的风险

分析：作为项目经理，刘冬华必须具备整体的把握能力和关键具体细节的敏锐度。
1、重新检查用户需求说明书，是否有双语的需求，并在项目合作协议中明确要求具备该项功能，如果没有那好说，希望对方增加预算或明确后期的市场预期，不能让范围蔓延镀金；
2、如果各方面的信息支撑必须提供该项功能而最终没有提供，那就说明该项功能并没有分解到工作分解结构中，并实施有效的监督管理，项目的实施出现了问题。记录该问题并处理的同时需要重新检查梳理是否还有类似的情况，这点很重要，及时收拢，避免风险的扩大。
3、考虑提交变更申请，提出补救措施，如项目组内人员加班，增加中文部份的添加（事实上中文比英文更合适，不需要专业的翻译公司）。
4、实施整体变更控制，调整项目管理计划和项目文件，如需调整成本基准、进度基准等，需要向干系人包括陆经理及时提出，并预测可能的延迟时间和成本，以取得理解和支持。组织项目团队严肃认真对待，争取将影响降到到最小程度。

分析：1、首先肯定要查标书和合同，确认是否有该功能承诺。
2、如果有明确的的承诺，在和客户进行充分沟通且项目应急储备金无法解决的情况下则应上报PMO或管理层升级处理（比如动用管理储备金）。总之合同承诺的要兑现。

这里更应引起注意的其实是该公司在项目管理中的一些问题：
1、需求的确认是否经过了有关干系人的评审确认。配置管理是否健全，有没有需求基线。
2、对于需求的跟踪有没有切实的关注与执行，需求跟踪矩阵有没有，还是只是个形式。
3、就算以上两点都没有引起重视，那在立项之初的风险识别中项目组有没有应急储备的准备，公司层面有没有对类似情况的其他应急预案。
总结一下问题：公司的项目管理的监管存在漏洞或不合理有待改进。PM的责任心和执行力有待加强。凡事预则立不预则废，对于一个项目来说，一个公司可能不在意一城一池的得失，就算赔了公司也未必就过不下去，但这其中暴漏更多的是监管失控问题。损失的是市场和口碑信誉。事前的预防永远胜于事后的补救，与大家共勉。

分析：1.查看合同确认是否项目问题
2.如是，找客户协商，先提交英文版，做好相关培训工作并协助用户使用过程中遇到的问题。
3.组织项目组内部成员和用户一起完成中文版的翻译，延迟一个月提交双语版给用户。并做好版本的升级工作
4.如翻译工作必须要找专业翻译公司，和客户协商好后找公司领导协商
5.项目结束后进行经验教训总结

分析：1、首先再次确认合同或协议中的双语界面的需求。
2、若确定，那么满足客户需求必须放在首要位置，这是生存和发展的基础。
3、接下来就是如何解决交付延期一个月、增加预算、领导呵斥这三个问题了。
4、对于交付延期：务必与客户友好协商，取得客户谅解，并允许延期一个月交付，毕竟后期的合作将会更多。同时若客户需紧急使用，可以先将英文版界面先行交付，在此期间需配备英文水平较高的操作人员。
5、对于预算增加和领导呵斥：首先考虑界面的汉化工作是不是可以公司内部消化，若可以，则增加的预算为内部员工的相关成本；若不行，则需专业的翻译公司参与。其次如实向上级反映工作的偏差并陈述满足客户需求的重要性及必要性，即便是被呵斥也务必取得上级的支持增加预算。
6、同时针对此次事件及时做反省与总结，以后做项目时引以为鉴。

分析：1.首先需要确认当时与客户确定的需求是英文界面还是双语界面
2.如果当时客户认可只需要英文界面，则与客户一起确认当时的需求，必要时动用必要的客户关系资源协调，陆经理如果软硬不吃，客户关系也解决不了问题时，将问题上升到更高管理层次解决
3.如果当时确定是需要中英文双语界面，则安排责任主体加班加点完成双语界面开发，以最小代价实现原有需求

分析：这是属于界定工作范围的案例，
工作范围源自合同和客户需求。目前，就双语界面还是单语界面问题，客户的需求的是明确的，你们的投标文件也是清晰的，这是属于项目组定义范围时出的偏差。
鉴于，客户的系统使用人员有可能英语程度比较低，该系统使用英语界面，会对客户生产和经营带来不可估量的影响，换句话说，客户接受英语界面是不现实的。唯一的办法就是开发双语界面。另外，接受领导呵斥完成项目与单语种界面得不到验收，二者的选择之间，也是以完成双语界面更佳。
开发双语界面会有情况，第一，延期一个月；第二，增加预算。第一个问题，需要与客户友好协商，争取客户的认同，为项目赢得时间。第二个问题，需要汇报给公司领导层，以受到呵斥为代价换来预算，最后完成项目，项目经理把做错了的事情弥补了，也是可圈可点。

分析：一，需要明白一个项目的实施不仅仅是实施团队内部的事情，还需要销售、客户、上级的共同参与。
二，软件功能不能满足合同条款的要求，应该及时告知上级领导和销售团队，并在内部商定好解决方案，再通过领导或销售与客户进行协商。有时实施团队解决不了的问题也许能通过商务的途径得到圆满的处理，所以做自己力所能及的事情很重要。
三，如验收期限很重要，可以跟客户协商先验收并签订备忘录的方式承诺验收后一两个月之内给予解决。合同条款是死的，但是作为项目实施承担方表现出来的诚意和态度往往能影响客户的判断。

分析：首先应看合同中是否明文规定了双语界面，如果合同中有此条款，那么就一定要执行。
1.上报公司高层领导，说明具体情况，请求下拨项目预算资金，当然自己也要承担一定的责任。
2.尽量与客户协商分阶段验收。如果客户坚决不改验收时间的话，那就得向领导要求多增加人手，尽量缩短验收时间了。客户说是以后要长期合作的，相信经过有效地沟通问题能够得到缓解。
3.确认问题的原因所在。既然合同中写了这个条款，那为什么最后没有执行，是哪个环节出了问题，查找出原因，以防以后再出现类似的问题。

分析：1、该问题属于大问题，当初投标的时候明确说过系统支持双语界面，那么当初签订合同的时候是否将这个要求写入了合同中了呢?所以项目经理需要再次确认一下所签订的合同，如果合同里确实有这条内容，那么刘某就必须尽快将问题报告给自己公司的上层，以求解决主要是翻译工作的预算，后续如果是自己的责任，应负荆请罪；
2、向自己公司汇报，说明情况，在公司层面制定解决方案，可以考虑通过多种途径解决，制定可能的解决方案，如分期执行，先验收，毕竟英文界面是不影响正常使用的，做改善计划或放入二期等；
3、在解决方案制定完成后，以项目经理的身份通告项目相关方，当前项目存在的问题，以及建议利益相关方进行会议沟通，上层领导一定要在场，在会议前需要提前和对方领导沟通好，临时让对方领导决定影响这么大的事情是没有结果的。
4、如果合同中的确有这一点，必须满足客户，必须向公司申请这笔预算；
6、真诚沟通，尽可能促成都作出让步，找到双方都能接受的平衡点，尽快验收。

分析：面对这种情况
1. 客户的需求是否在项目的合同，需求文件有所体现
2. 项目经理是否把握好按项目要求按项目实施方案实施
3. 同时向双方项目层领导进行沟通 ，或者双方负责项目的一起沟通 ，说明原因并提供相应解决方案，以求降低项目失败风险。
4. 对UI界面语言分歧的，只是潜在的风险但不是致命的，关键在于沟通 ，比如后续提供培训优质机制，或者付款方面提供折扣 等 毕竟后续还有相互配合的需要
5. 双方都拿出诚意，双方都作出让步找到双方都能接受的平衡点 。
6.最后完美结束项目。

分析：没有满足客户的要求, 责任是非常明确的. 如果在项目之初将客户要求清晰地转化为内部检查清单,或许就不会有这个乌龙事件了. 建议的补救措施如下:
1. 与客户洽谈是否可以分阶段验收,毕竟英文界面是不影响正常使用的.责任在供方.给客户一个可行的改善计划;
2. 找出当初为什么没有将中文界面纳入的根本原因
3. 将上述两点如实向领导汇报, 取得领导的认可和批准
4. 与客户作最终确认, 验收及确定改善计划   

分析：既然之前已表示有双语支持，有什么好说的，增加支持呗。这应该是项目实施方内部销售与项目实现人员之间协调的问题。很多公司的销售面对客户时信口开河，这是要付出代价的。向公司反映这一问题，相关责任还是需要明确的。
相关成本问题，这个其实很好解决，主要看合作双方的关系。很多客户存在预算审批，增加预算的流程是很复杂的，甚至不可能增加预算。如果双方关系稳定，完全可以在后续项目，如二期，或其他项目中，增摊这部分费用。

分析：从您的文字描述来看，当初投标的时候明确说过系统支持双语界面，那么当初签订合同的时候是否将这个要求写入了合同中了呢?所以项目经理需要再次确认一下所签订的合同，如果合同里确实有这条内容，那么刘某就必须尽快将问题报告给自己公司的上层（那么就是需求分析时漏了内容，这属于己方责任），以求解决（主要是翻译工作的预算）；如果在合同中确实未记录客户的这一要求，但当初投标时确实口头答应了客户的双语界面要求，那么客户作为自己的一个长期合作伙伴，那么自己应该负责处理此事的，这里在确认了问题的原因之后，还是需要与公司上层沟通，一同处理此事。

（三）对项目需求管理的认识和体会

　　做了那么多个项目，我深深感到对项目的需求把握管理好了，是项目成功的关键。对需求的管理大概有那么几个活动，首先是需求获取，这是一个确定和理解客户的需要和期望的过程，为实现项目目标而定义、记录、分析干系人的需求; 其次，是要求获得相关人员对需求的认可和承诺;最后，即使是需求确定下来之后，也不可避免得会有变更，如何控制和管理变更，是保障项目目标的实现的重要环节。
　　2010年，我担任了公司一个重要项目，老挝TAIS系统的项目经理，该项目是一个系统集成项目，在此之前，我并没有做过类似项目，为谨慎起见，严格按照需求管理的规范执行，收获了很多经验，也保证了项目的顺利交付。
　　1、需求获取 需求获取分为两个阶段，需求调查、需求定义。需求调查和需求定义在逻辑上存在先后关系，但实际工作中二者通常是迭代进行的。需求分析的工作则贯穿于“需求调查”和“需求定义”两个阶段。 需求调查的目的是通过各种途径获取用户的需求信息(原始材料)，产生《用户需求说明书》。
　　需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
　　在进行现场需求调查之前，我首先需要了解的是，这个项目是什么样的项目，大概做什么事情?并仔细阅读了售前阶段产生的所有文档资料，和售前阶段参与人员交流沟通，进一步了解项目是谁提出来的，目的是解决什么问题。
　　不单单听介绍，特别关注了与合同具有同等效力的那些文件，如技术协议，工作说明书(SOW)、实施方案等等。从而知道，该项目是一个老挝TAIS (THSCAN-ASYCUDA Integration Solution)项目是我司集装箱/车辆检查系统与海关数据系统整合解决方案的简称。目前在老挝境内，8个地点部署了6套车载式系统和2套组合式系统，老挝海关使用的海关自动化业务系统叫ASYCUDA，TAIS就是要实现NUCTECH扫描设备与海关数据系统的高度集成和信息共享。
　　了解都项目的业务领域之后，我又对客户干系人进行了分析，这样，就能保证正式调研需求时，能够选择一些典型的客户代表进行需求调研。刚开始没有经验，参与人员太多，提供的信息过于零散，减慢了收集需求的进度。后来我们制定了现场访谈计划，一次讨论不超过10人。效果就好多了。通过和客户的有效沟通，获取了大量的信息。
　　我发现，跟客户交流时，提的问题最好是开放式的，比如 “是否确认进度检查确认方式”比“如何确认进度检查确认方式”可以获得更多的信息。“项目计划编制完成后，是否征求下级部门意见，如果下级部门不接受上级部门分配的计划，如何协调和处理?”这样一个问题就可以了解客户的计划批准和协商过程。现场调研的工作很顺利，共去了3次。
　　除此之外，我们还参观了用户的工作流程，观察用户的操作。 初步的需求信息得到以后，要对需求进行分析。需求分析有很多方法，“问答分析法”、“结构化分析法”和“面向对象分析法”，总之，是要对得到的信息进行处理，提取这些信息间潜在的逻辑关系，分成不同的类别，这样才能充分理解它们。
　　这就要求项目经理不仅要尽可能记录客户信息，同时还要做一定的整理，否则，所有的讨论只剩下一个模糊的印象，需求仍然是一件遥远的事情。只有进行深入收集和分析，才可以消除任何冲突或不一致性。 信息量越大，对准确理解客户的需求越有帮助，但同时，对需求的分析也就越难。
　　对于软件项目，我认为这可能是最困难、最关键、最需要交流的工作。因为软件不是硬件，不是主板，显示卡之类看得到摸得着的东西，软件是思想，是理念，是规则，是对真实世界的抽象。软件项目的交付物是有形的，可又不同于其他行业，比如汽车的构造是固定的，其组成部分是不变的。而一个软件系统的模块划分则可以有多种方法，多种结构。这个特征导致对软件项目经理的抽象思维能力要求很高，要求要有较强的逻辑性。否则，就有可能表现为缺少全局概念，对项目整体的范围和业务系统把握不够，在项目过程中被客户牵着鼻子走，今天客户说要个什么功能，就添加个什么，明天要修改个什么，就跟着修改什么，被动至极。 将客户信息结构化，编写成需求文档。这是需求定义的工作。公司的《产品需求规格说明书》的主要内容包括：“ 产品介绍;描述用户群体的特征;定义产品的范围; 阐述产品应当遵循的标准或规范;定义产品中的角色;定义产品的功能性需求;定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求;”仅有这份需求文档还不够，我上现场调研时带了个美工，将我们和客户沟通好的软件部分用图形界面UI画了出来。 需求定义是需求获取中最“痛苦”的一件事情，为了尽量避免日后的扯皮，我们力图使每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，追究“是什么”和“为什么”的目的是获得正确、清楚的需求。对需求定义的标准大致如下： 需求存在二义性吗?2 需求文档的上下文有矛盾吗?2 需求完备吗?2 需求是必要的吗?2 需求可实现吗?2 需求可验证吗?2 需求的优先级确定了吗?2
　　2、 需求确认 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 在需求调研的过程中，我发现对项目范围的定义和当初了解的存在误差，这也是很正常的，因为未签订合同前，谁也不能做很深入的调研，只能了解个大概要求。但我们的原则是不轻易更改工作范围，只是在原来的框架内做一些小的调整。 而且每次和客户讨论之后，我们都写一份会议纪要，请客户签字确认。但即便如此，对需求的确认也是一件很让人头痛的事情。如何划定边界?做到什么程度就可以了?因为只有提供需求的人才能确定是否真正获取需求，我们都尽量请客户参与讨论并更正。 需求评审会议非常重要，但是以前几个项目的评审会都开得不很理想，大家事先不认真阅读文档，会上乱哄哄的，你说一句，我问一句，往往花费了很多时间，却啥结论也没有。这一次，我吸取了教训，组织了一个非常正规的需求评审会议，将部门领导、公司的业务专家、技术骨干都请来当评审人员。并自行设计了《评审准备表》和《评审记录表》。会前两天提前发了老挝项目的需求文档《老挝TAIS项目方案建议书》、《老挝TAIS项目调研报告》，发放了《评审准备表》，让大家提前将问题记录在评审准备表中，并反馈给我，我一直等到反馈意见收集的差不多了，才召开评审会。评审会开的很成功，效率很高。我让人整理了评审发现的问题，放在了评审记录表中，方便下去追踪。
　　3、 需求变更控制 需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。
　　需求变更难以避免，重要的是不能没有章法得变，要遵循一个标准的变更控制程序，使得变化有序起来。 如果不进行变更控制，那么，项目就不能得到及时的警告，常常会因为进度超期、预算超支而陷入泥潭，成为“烂尾”工程。但是变更实在太频繁，如果每次变更都走变更流程，也会大大影响项目进展。按照变更控制流程，需要对变更做影响分析等等。
　　既然变更在所难免，不可能只要有变更就执行严格的变更控制程序，这个过程也是有成本的，所以，和项目组成员讨论的结果，只有重大变更时，才执行变更控制程序。比如影响了项目里程碑的达到，工作量超出了原先估计的30%等等。
　　这样一来，既保证了变更的有序性，又保证了项目进展。 除此之外，我还对需求的稳定度做了一个度量，度量了原始需求的个数，增加、删除、更改的需求个数;并分散在项目各个阶段，如需求分析、概要设计、详细设计、编码阶段、测试阶段等等的需求数，并将每次需求变更的提出人、变更原因，是否走了正式的变更流程都记录了下来。一来是为以后的项目做参考，二来跟客户沟通时也有话说。不至于拿不出令人说服的事实和根据来。
　　比如这个项目，初始的软件需求共有142个，中间增加了21个，删除了6个，更改了34个。总体需求稳定度在30%左右，对于一个软件项目来说，就很不错了。 老挝项目于2011年12月底结束，项目获得了老挝海关的好评,目前系统运行正常，系统已经融入老挝海关工作流程，成为海关工作不可分割的一部分。公司也收回了该项目所有尾款，实现了公司的价值。
　　在此项目中，我们做到了一下几点：尽早开始需求调研，清晰进行需求定义，随时和客户进行沟通，及时记录需求变更，统计需求变更的影响和工作量。因此，项目进行得很成功，期间克服了很多困难，比如人手紧张，客户方接口人变动等等。但因为工作范围没有什么改变，需求一直在掌控之中，项目一直按计划执行和完成。