a.       业务与技术方案

xxxxxx项目成功的关键在于公司的品牌，但由于签单时以该品牌对客户承诺太多，导致客户对我们要求明显高于该项目实际本身，先期对客户做的政府网站规划里，大部分用到微软产品，是以省政府的整个电子政务投资做的规划，即xxxxxx市政府电子政务信息化系统方案，在此方案中使用微软产品数十款，一期网站需要sharepoint,但最终的xxxxxx市预算只有xxW，经过协商与沟通交流，改为xxxxxx市政府门户网站解决方案内容。项目确定阶段一定要明确我们多少钱能做什么，不要对客户承诺过于太多，导致客户先期就认为很多就是我们应该做的，甚至有些还做的不到位。例如：帮助他们输入数据，与别人几百万的项目做比较。在项目后期，客户稍有不满就说开始承诺说要建成xx那样，现在不说多了，至少跟省的差不多吧。但这两个地方的门户网站投资都在百万。

b.       项目经验与成本估算

   在公司没有相应资源以及相关项目经验的情况下，很难对项目做出正确的成本与实施周期估算，项目确定时期很难对需要的人员数，相应的技术支持做出估算，主要因素为人员都还不到位，也不能对其技术水平做出正确的判断，即使人员到位，刚组建的团队，在协作方面也会有较大的困难，所以很难对项目的周期做出估算，成本也难以控制。

需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键

总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况：

但责任不完全在客户，毕竟客户在软件方面的知识不多，也没有相关的经验，心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。

例：xxxxxx网站需求调研阶段，预期两周，但实际只有一周不到，一方面，客户忙于自身工作，又不是专业人士，当问其需求时，只会说你们做吧，做了我们看，提不出丝毫需求，只知道自己网站排名落后，需要重做网站，唯一的知道的就是要做站群系统，虽然也引导客户明确需求，但客户对需求不够重视，认为我们写的就行，持不否定也不肯定态度，最终的基本栏目都确定不了。

随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。

例：在考虑系统架构时，明确的是主子站关系，但主站所实现的功能与子站的功能不能确定，包括网站风格上也没有参考意见，给美工与程序带来很大困难，可能客户本身对软件公司做项目有所了解，对我们提出的所有功能与建议都持中立态度，造成工作无法确定，只能参考现有政府网站以及新闻系统功能进行制作，当网站基本成形，有框架时，客户发现有些地方不能和其它地市一样，甚至有较大改动，但我们的软件功能与数据库已基本确定，所以变动很大，有些功能基本费掉，有些功能要全新开发，造成了软件项目中的三边项目：边做计划;边写代码;边修改计划

例：xxxxxx网站新闻模块，在需求调研时都明确了，数据采集录入，我们理解的是人工数据采集手动录入，而客户理解的是自己设置采集目标，自动采集。

a) 需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。

b) 需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。

c) 需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。

d) 对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，

比如新闻录入三级标题功能，因为属于政府部门比较专业的细节问题，需求分析开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。

e) 项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。

f) 此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排有人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，认为他已经真正的理解并认可了设计。

a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。

b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。

c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。

d) 需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生

e) 需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。

f) 需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题

g) 帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解

h) 最后，需求分析报告一定要双方共同签字确认

项目在制作期与客户沟通太少，客户不主动，我们也没有主动沟通，后来在培训期间客户直接说我们签过单后就没人管这个事了，造成很大被动，也成为后来主站较大调整的一大因素，但客户提不出需求，期间沟通与开始需求调研一样，不会有太多收获，但产品在开发过程中又难以让客户看到实际效果，因此项目初期的需求调研是重中之重，如果需求调研做好了，中间只需要简单沟通即可。

在与客户沟通过程中，特别是验收期内，将会出现非常多的需求变更情况，其中有些需求是当初没考虑好，有些需求是迫切的（比如发现ＢＵＧ后提的），有些需求是无理的而且困难度大，有些需求则是没有意义的，有些需求是技术上达不到的，有些需求是必要的，有些是合理的，有些是合理但不必要的，……。因为需求的变更必然引起工作量的增加和人员的调配，有时处理不好就会使得项目验收遥遥无期甚至和客户关系变僵，所以此时就需要很有技巧地说不和点头，但该项目前期对客户承诺过多，如果直接说不，可能就直接导致客户关系变僵，项目中止，客户也多方面施压 （如果不按先期承诺的，合同都不会签，领导就要中止合同），所以大部分需求变更都满足了。

在与客户沟通时所谈到内容，都要存档备案，特别是关于需求变更方面的，都要有案可查。该项目需求变更次数很多，每次都很琐碎，我们每次记录的都没有规范备案，有些忘记记录，造成档案不全，需求变更修改后，版本控制出现问题。

项目在实施过程中，客户一定要指定专人负责项目，而在该项目中，客户方负责人权利不够，没有起到协调人员的作用，也没有起到负责项目的作用，我们在该项目中没有与用户进行直接对应关系的沟通也是前期需求调研时出现困难的原因，在客户那里就是领导布置下来的，但没有人愿意去完成，用他们自己的话就是谁想学东西了，就操操心，做好又没有什么奖励，做的不好还要倒霉，这成为该项目需求不清的主要原因，所以项目一开始就应该强制客户指定专人负责与我们直接沟通，对该项目直接负责。

由于该项目采用的ASP.NET技术，所以对网站美工人员的要求较高，需要美工人员有较好的程序阅读能力，才能良好的与程序员进行协作，但此方面人才非常缺乏，又加上以前没有任何配合实施项目的经验，所以在整个过程中大部分时间是在学习与沟通，而美工起到的作用甚至只是画张图而已，大量工作压到了程序方面，而程序方面在需要调整美工的地方缺少经验，所以一开始人员的不足，以及团队合作经验的缺少，导致项目进展缓慢。

技术人员在项目中与商务人员的协作是项目中比较重要的环节，业务人员应该根据项目成本与技术人员做详细分析，确认项目的可行性，在项目实施过程中需要协助技术人员对客户的不合理要求做出拒绝，尽量减少需求变更。