1、业务（需求）分析员
所谓业务（需求）分析员就是系统分析员的一部分工作。首先，在中国，我还没有听说，一个做不了系统分析的人能够做需求分析。
需求分析从本质上讲，是将客户的自然语言进行整理，增、删、修，然后映射到一个个开发人员能够理解的功能模块上。
所以，需求规格书并不是需求分析的结束，而只是需求分析的开始。工作做到需求规格书这一步，只能说是需求收集的告一段落。
设计一个系统结构是系统分析员的必备基本功，但如何将这些自然语言转化成系统的各个模块才是真功夫。
系统分析员如果依赖于别人去收集客户的需求，这是无法保证需求准确性的，特别是一些创新性的项目。面对客户提出的数以千计的要求，难以想象，一个没有充分系统结构设计经验的人员，能够从中收集到高质量的需求。
事实证明，软件工程的成功与否关键，已经从代码错误率变成了需求分析的失误率。
可以这样说，系统分析员就像这样一个建筑设计师，他和客户交谈后，设计出一个摩天大楼的模型，让客户看是否满意，然后交给下面的设计师，由他们完成详细设计——请注意，系统分析员不应局限在如何做编码规范、接口等这些详细事务上，系统分析员的核心工作是完成功能的设计。总结一下：需求分析的工作就是：需求规格说明书 + 概要设计书

2、系统分析员
系统分析员是一个设计团体，而不是一个人单干。摩天大厦有整体设计，还要有各个局部的设计。每个局部的设计方案应当能够描述采用何种技术，满足那些功能，和其他功能结合所采用的集成技术，以及需要多少成本等。这是狭义上的系统分析，是在概要设计的基础上，对每个模块的详细设计。

3、高级程序员
高级程序员拿到设计方案，首先是确定编码（接口）规范，然后是再次分解，他的产品应当是类和接口（在OO设计里）的功能表。

4、程序员
程序员该上场了。他无需知道更多东西了，高级程序员的产品已经足够他完成任务了。确实，真要能这么实现，高中生就能胜任。

5、项目经理
他的活不是技术。
我们有太多错误的定位了，特别是对软件开发的项目经理。他既不是系统分析员，也不是高级程序员，他是管理人员，或者说是服务人员，他的工作是保障整个开发团队持续、高效运转。他要紧密xx团队进展，发现滞后因素，寻找改进方法；这时，往往要运用激励与惩罚手段－－但现在我们的项目经理事实上缺乏这些手段，他们仅仅只是挂了一个项目经理的名头，对于改进工作流程xx没有权利。
项目经理还要与每个成员紧密沟通，了解大家的状态，不断给大家打气．．．．．．。
他是播种机，他是宣传队，他是旗帜。
如果深挖项目经理的角色，CMM更加全面的描述了整个团队的开发管理。当你发现，CMM没有涉及到如何进行需求收集，如何设计，如何测试，而全部都是如何管理需求，如何管理测试等等时，你也许会大失所望，但到这时，你才会明白技术与管理到底是怎样的关系。

6、项目顾问

先看一个笑话：一个旅客走进硅谷的一家宠物店，浏览展示的宠物。这时，走进一个顾客，对店主说："我要买一只C猴。"店主点了点头，抓出一只猴，递给顾客说：总共5000美元。这位旅客非常惊讶，走到店主跟前说："那只猴子也太贵了！"店主说："那只猴子能用C编程，非常快，代码紧凑高效，所以值那么多钱。" 这时，旅客看到了笼子中的另一只猴子，它标价10000美元。于是又问："这只更贵了！它能做什么？"店主回答："哦，那是一只C++猴；它会面向对象的编程，会用Visual C++，还懂得一点Java，是非常有用的。"

旅客又逛了一会儿，发现了第三只猴子，它独占一个笼子，脖子上的标价是50000美元。旅客倒抽一口气，问道："那只猴子比其他所有猴子加起来都贵！它究竟能做什么？"

店主说："我们也不知道它究竟能做什么，不过它是做项目顾问出身的。

项目顾问到底做什么 ，还真不好说。严格来说，项目顾问不属于软件团队，他只存于在乙方公司（卖软件的公司）。也有人叫售前顾问，或者有些公司干脆叫软件销售。按乙方公司商务性质的不同，可以分为三种，{dy}是拿现成的软件去卖，那么顾问一定懂这套软件能实现什么，以及相关的行业知识。第二是xx定制开发，那么顾问要能给客户出方案。第三是出租软件卖服务，也就是所谓的SAAS模式（software as a services),这样的人可能兼任客户服务工作。

7，项目实施。

很多公司把这个定位在{zdj0}的层次，主要工作是培训、数据收集与初始化，上线执行与问题解答。但其实最有价值的工作内容是：制定实施方案，把业务在系统中真正的用起来。特别是较复杂的业务，要先理顺了，再去想办法在系统中走。怎么整理业务，让业务与系统结合达到{zh0}使用效果 ，这个需要很高技巧。