软件项目管理重在于需求分析，需求分析不“拍脑袋”

（一）项目需求分析

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解：需求分析指需求的分析、定义过程。

（二）项目需求分析过程

需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.
问题识别
就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行时所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
分析与综合
逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
制订规格说明书
即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.
评审
对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。

（三）项目需求分析方法

需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发. 

原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

（四）如何做好“拍脑袋”项目的需求分析

案例正文：某一政府项目，属于领导“拍脑袋”型项目。由于该项目较小，领导交其下面工作人员办理，并委托我公司承担该项目的建设，但政府方面相关人员对项目只是有一个总体的设想，虽经多次沟通，我们仍无法得到具体的需求，他们仅是一直强调要用过以后才能提出问题。
对此类项目，如何才能获取客户的具体需求？ 

分析：正因为项目干系人均只有大概映像，作为政府的代建类公司恰好大有作为！建议：
一、原则上“到位不越位，用权不越权、出场不炫耀、做事不争功”做好只有你们能做好的，弥补干系人缺陷的。
二、做业务上“先处理干系人好心情再说事情、先顺通情绪再顺理智”就非常好办，不要要求政府等什么都懂。
三、理论上把干系人看作同自己一样的平常人，正是缺点让他们一个个显得可爱，互相包容、互相支持工作最好。
四、请先克服写此案例的基本观念，本人曾经有此类念头，现后悔莫及。

分析：“你提方案，我拍板，你执行----其余的不要来烦我”－－一语中的
前期的需求还是要明确的，领导定基调，我们做具体干系人调研。
1.根据基本范围和组织结构图，确定干系人清单
2.基于关键干系人，访谈了解需求
3.如果干系人众多，基于访谈需求，再设计个调研问卷
这样你的需求就明确了，并且对方会觉得你做事有章法，没有破绽。
再然后，你需求清晰了，做什么方案就是你的拿手好戏了。

分析：最明确的决策方式，就是做选择题！
不得不提及的是，政府工作人员是不可能喜欢做这种具体问答题和论述题的，也不屑于----所以他们一直强调要用过以后才能提出问题。
余下的就是被委托的开发商的责任了！开发商有合约责任根据政府的大体设想，拟定几个具体的方案，帮助业主决定用哪种。
成熟的公司和项目经理，自然会明白且会帮助业主明白她到底要什么-----这个过程中，项目经理们会得到自己想要的东西的，如项目利润。
我曾经做的一个山东济南项目，业主主动提及“你提方案，我拍板，你执行----其余的不要来烦我”。

分析：需求分析对于做项目的人来说，主要是明确做什么、怎样做、做到什么程度；化解不明的风险；
对于发起人来说，选择所需的；
既然情况是这样的，就可以根据以前做过的类似的项目让发起人选择一部分，如果不能明确的，就不妨连“机会成本”一起算上，因为这种风险本来就来自发起人，他理所当然的应该承当一部分。

分析：其实我们每个人都一样，都喜欢做选择题而不喜欢做问答题和论述题，所以论述题分多。
这些政府相关人员也是一样，他们的水平可想而知，能说出个大概的需求设想就不错了。而对于被委托的开发商而言，靠的就应该是在项目开发上的专业水平，所以可以根据政府的大体设想，拟定几个具体的方案，给他们解释一下，让他们选，这样他们就会觉得轻松了，也就会选了，不过在过程当中他们渐渐的经过学习观察，肯定还会提出不少变更，要做好心理准备。
作为专业的开放公司，不但要明确理解客户的需求，还应该帮助客户明确需求。

分析：按照国际惯例,这显然是一个前期规划性项目,只有一个概念性的东西,此时需要乙方有较高的水平,通过乙方从前期调研到可行性研究到立项到项目组织到施工到投入运营全过程负责,由于只有大致概念和方向,因而需要乙方及时与甲方沟通确定下一步工作,整个项目在渐进过程中具体实施,到项目组织阶段基本上能够有一个明细,有的可能在实施过程中才有一个明细,此时才知道,甲方需要的是个什么项目而乙方应该做的是一个什么项目.
这类项目做起来难度较大,因而利润相对丰厚,而从本案例来看,有政府背景支持,应该利润不是问题.如何把这个项目做好让领导有面子才是问题.祝你们好运! 

  

分析：现明确项目本身的特点，包括立项的情由和干系人特点等。
”拍脑袋“ 体现了项目本身的重要性。 因此在承担此项目前应该衡量自己的能力和项目本身所带给您的压力（各方面的）。
现在很多用户本身不喜欢去做需求，他们只有大致的想法。而项目需求又是直接决定产品属性，项目经理必须做好需求分析。
鉴于项目特性，初期选择原型的开发方法，之后再根据具体情况选择不同的开发方法。（动态调整比生吃某一中开发方法要好）
其理由是：
1。初期项目需求不定，项目团队分析人员需要不断和用户等沟通，并开发原型，以验证客户的想法。
2。拍脑袋的事情，需要逐级化解风险。
3。让用户承担部分责任。

（五）做好项目需求分析，是项目管理的重中之重

01
项目需求分析是系统分析和软件设计阶段之间的桥梁。
主要表现在两方面：
需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整。
需求规格说明又是软件开发设计、以及实现和测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量，提高软件系统的稳定性和健全性。
可见需求分析的重要性，项目需求分析大致有四个过程
1、需求分析过程
需求过程包括需求开发和需求管理两个部分：
需求开发：开发前期的管理，与客户的沟通过程，包括需求获取、需求分析、编写需求和需求验证等。
需求管理：软件项目开发过程中控制和维持需求约定的活动。包括变更控制、版本控制、需求跟踪、需求状态跟踪等。
2、需求的层次
需求的层次包括：业务需求、用户需求、功能需求、非功能需求等。
3、需求开发阶段的重点
提取业务对象
业务对象(Business Object，BO)是对数据进行检索和处理的组件。是简单的真实世界的软件抽象。业务对象通常位于中间层或者业务逻辑层。
提取业务流程
业务流程，是为达到特定的价值目标而由不同的人分别共同完成的一系列活动。活动之间不仅有严格的先后顺序限定，而且活动的内容、方式、责任等也都必须有明确的安排和界定，以使不同活动在不同岗位角色之间进行转手交接成为可能。活动与活动之间在时间和空间上的转移可以有较大的跨度。而狭义的业务流程，则认为它仅仅是与客户价值的满足相联系的一系列活动。
性能需求
在分析的前期应该注意客户对所开发软件的技术性能指标，如存储容量限制、运行时间限制、安全保密性等。
环境需求
环境需求是指软件平台运行时的环境的要求，如硬件方面：机型、外部设备、数据通信接口;软件方面：系统软件，包括操作系统、网络软件等；使用方面：操作人员需要什么样的技术水平，应具备那些条件。
用户界面需求
为用户界面细致地规定到达的要求。
4、 需求分析的任务
需求分析的主要任务是借助于当前系统的逻辑模型导出目标系统的逻辑模型，其流程如下：
确定对系统的综合需求（功能、性能、运行、扩充需求）
制作产品需求文档 (PRD)
分析系统的数据需求（概念模型、数据字典、规范化）
导出目标系统的详细的逻辑模型（数据流图、数据字典、主要功能描述）
开发原形系统

02
如何有效进行项目管理?
项目根据项目需求确定目标，主要是项目目标的制定、分解和职责分工。目标管理要求每一个分目标都有明确的责任主体。因此，预定总体目标之后，需要重新审查现有团队结构，进行目标分解，并明确目标责任者和协调关系。分目标要具体量化，便于考核;分清轻重缓急。
目标管理是系统性工程，如果事先没有一个详尽的计划，很难将各项工作协调一致。因此，计划是目标实施过程中不可缺少的一部分。目标管理是一项所有成员都要参与设定自已的具体目标，然后各就各位把计划执行的过程。并且，上级主管要进行阶段性考查，根据实际情况作出一些调控，以便顺利的完成目标。
这里推荐自下而上的预算方法
自下而上方法要求运用WBS（Work Breakdown Structure，工作分解结构）对项目的所有工作任务的时间和预算进行仔细考察。最初，预算是针对资源（团队成员的工作时间、硬件的配置）进行的，项目经理在此之上再加上适当的间接费用（如培训费用、管理费用、不可预见费等）以及项目要达到的利润目标就形成了项目的总预算。自下而上的预算方法要求全面考虑所有涉及到的工作任务，更适用于项目的初期与中期，它能准备地评估项目的成本，与真实费用相差在5% ~ 10%之间。
要是项目部分有外包的情况，还需要考虑接口联调的工作量。
笔者有次做移动客户端跟服务端联调接口时，本来计划10个接口一天内联调完的，可是那天只联调了一个接口。
有的公司为了接口开发成本，服务端开发人员开发的接口，没有经过测试人员测试就直接跟客户端联调了。
记得那次，服务端开发人员说接口开发好了，可以联调，他直接打包发布都平台，也没有自己先测试一下，结果我一调，直接报500了。
他再打包发布，这样一来就浪费了很多不必要的时间，更离谱的是，接口返回数据格式竟然不是客户端想要的。
……
所以，做系统需求评估时，要注意联调的工作量。
做好项目需求分析，才是项目管理的重中之重。，只要做好了，才能更好的做好软件开发，开发人员才不会了因为频繁的需求改动而抓狂，有更多的时间和精力去处理更有意义的事情。