做软件开发项目规划时, 常会碰到助理问我一个问题, SA,SD和SE的差别在那里 ?
这 个问题我以前也有过, 还颇为困扰, 系统分析和系统设计及系统工程到底有什么差别 ? SA和SD的工作又有何不同 ? 这两者的养成教育又有何差异 ?在过去, SA,SD及SE的确很难区分, 甚至这些角色常常会透过软件工程师来混合发展。随着IT领域的发展, SA,SD及SE渐渐的成为了大型项目必需要的专业分工, 这三者间是有相当的差异的, 不管是养成过程, 甚或是未来的发展, 都大相径庭, 而要成为一名称职的PM, 是要能区分出这三者的差异, 才能妥善的安排工作的。
[SA System Analysis,系统分析师]
SA是 System Analysis 的缩写, 一般称为系统分析, 主要的工作就是透过一系列的分析工作, 把客户想要的结果产生方式, 以各种文件表达出来, 让开发团队可以根据这些文件实作出这个结果。
这样的解释比较文绉绉一点, 用个通俗一点的方式比喻, 就像是要做出一道宫保鸡丁时, 就会有食谱一样, 里面会介绍需要的材料及做菜的顺序, 然后里面也会强调要以怎样手法才能产生出某种效果, 以促进色香味。
这样的过程里, SA是较为偏重于在工作流程和处理逻辑的, 透过SA, 开发团队才可以理出整个系统的架构, 一种做事的脉络, 以及系统和工作间的关连性, 最重要的, 是这些结果都会被SA呈现在文件中, 而非放在少数人的脑袋里。
SA不仅止是要针对计算机里的东西去运作及规划, 还包括了现实世界里的实体流程及组织。在很多的情况下, 配合新系统的组织及流程, 是要由SA来执行的。总结起来, 在一个开发案里, SA执行以下的工作：
? 藉由系统需求书, 使用者的现有标准作业流程来建立出符合期望的新作业流程及搭配流程的系统功能及模块规划
? 依据功能及模块规划案, 定出初步的数据库内容及系统与使用者间的权限搭配规范
? 定出各个软件零件的规范, 如对象, 函数库, ...等等
? 设计新的标准作业流程, 并把系统功能或模块绑入这些流程中
? S.A依据客户的环境及需求, 寻找合适的SD来搭配
而SA也有以下的特色：
? 对于系统在怎样的环境及用什么开发工具, 并不十分在意, 良好的S.A产生出来的文件, 使用不同的开发工具都应该可以完成, 产生相同的结果, 但那一种最合适, 由SD决定
? SA偏重于流程及执行逻辑的表达
? SA着重于软件逻辑, 对开发工具的学习并不是十分重要, 所以会一种语言即可, 主要是以该语言工具来实践逻辑观。
? SA一定要有全局观, 也就是不能拘泥于一个角度或是一个局部去思考问题, 这一点是寻找优秀SA时最困难的。因为在规划模块及功能时, 一定要同时考虑到所有直接相关及间接相关的程序及逻辑问题, 因此要有全局观。
相较于SD, SA更侧重在逻辑及工作顺序搭配的表达, SA并不需要去关切使用什么操作系统或是什么开发工具, 如前特色所述, 好的SA文件, 可以用任何一种开发工具来实现。当然, SA不受限于IT技术, 但却会有专业领域的限制。
很少有SA同时专精于数个领域的, 熟悉汽车业运作规范的SA, 在金融业的开发案里, 就很难讨好, 反之亦然。但SD没有这种限制, 基本上SD可以和任何行业的项目开发团队配合运作。
会如此的原因是SA是偏重于流程及管理分析及重新再造工作的。而作业流程, 除了少数领域里共通性高, 在核心流程上, 是需要长期钻研的。前面提及的汽车及金融业就是一例。
所以, 一个SA必需具备以下的能力,资历及专业训练：
1. 至少熟悉一种程序开发语言
2. 熟悉软件工程, 对于开发工具的元素及特色熟悉
3. 对管理制度或作业流程设计熟悉
4. 熟悉UML或类似的系统描述工具
5. 逻辑能力良好
6. 良好的沟通能力, 主要作为了解需求之用
7. 相关的业界熟悉度
在三者之中, SA是最接近PM的, 所以SA在做生涯规划时, 不妨以PM做为下一个发展的专业目标。
[SD Systems Designer, 系统设计师]
一般来说, SD在生涯规划里, 并不是SA或是PM。当然, 一定要硬来一次也没有什么不可以, 但要走这条路, 就要趁早转职, 因为SD毕竟是较为幕后的工作, 在与客户的沟通协调上, 并不会有太高的要求, 也较不需要公司管理层面的全局观。
表 面上看起来, SD没有SA那么多的工作要求, 但实际上SD是最需要天赋的工作, 不管是画面的构成, 操作的手顺及调整, 甚至于组件的定义及对象的规范, 全都需要一些天赋。很多软件, 功能很强, 但怎么看怎么不顺眼, 或者怎么用就怎么憋扭, 功能带来的效益, 全都被这些毛病给遮盖掉了, 这就是SD的问题。
另外, SD也扮演了系统最佳化的推手。SA所规划出来的要求及布置, 都只是逻辑上的构思, 在不同的工具上, 可能有更好的方法可以表现, 也可能会难以展示, 这都需要藉由SD对使用环境及开发工具的了解, 来进行调整和规划。
举 例来说, 同样是一套财务软件, 在WINDOWS XP, MAC, X WINDOWS下, 就会有很不一样的展现模式和技巧。如果再搭配上不同的开发工具, 如C++, JAVA, .NET, PHP, ...那差异更多。对SA而言, 这些东西他都不用去考虑, 但SD就不同了, 这些不同的地方, 并不仅仅只是如此而已, 有时还会包括了开发成本及时间问题, SD的重要度, 由此可知。
在一个客制化项目里, SD的工作内容如下：
? 设计画面元素规范
? 设计页面结构及规则
? 设计系统操作画面, 并编定字段规范及防呆处理
? 设计权限管理与系统操作机制
? 撰写使用手册
? 调整DB之各项定义, 使其符合画面字段规范及操作搭配
? 配合SA撰写系统开发文件, 供程序员CODING之用
? 撰写UI(使用者接口)测试计划书
而做为一名称职的SD, 以下的条件, 是必要的：
1. 至少对一个操作系统极为熟悉, 对于这个操作系统的各个组件特性及API, 有充分的了解
2. 熟悉2种以上的开发工具, 而项目所需的工具, 必需是其擅长的之一, 其熟悉度包含了标准安装里的各个函数库, 系统常数, 对象定义, 语法, 主要的辅助工具开发厂商, 及重要的工具使用方法
3. 具一定的美学感
4. 至少能使用一种绘图工具软件
5. 曾经担任职业软件工程师三年以上
可以这样说, SA给了系统灵魂和神经系统, SD则是给了系统躯体和外观, 两者的结合, 才能产生出正确, 美观又好用的系统。如果你觉得自己是个不太爱和太多人打交道的IT人, 又对使用者接口有那么点执着及天赋, 那么, SD绝对是适合你的好选择。
[SE Systems Engineer, 系统工程师]
就某种角度来看, SE对PM而言, 算是万金油, 只要做IT项目, 那就一定用得上, 差别只是要选那一个专业的SE而已。系统建置安装要SE, 使用者环境要SE, 甚至到硬件选择及布建, 都要用到SE, 有什么IT项目跟这个没有关系呢 ?
当然, 虽然SE是到处都吃得开, 但相对的也是项目里面最沉默及少有声音的一群。他们的工作基本上就是建构出一个可以执行系统的环境, 系统要如何展现, SE可以给SA和SD一些建议, 但建议时机通常都是在系统运行出了些非系统可以掌握的问题后。
系统工程师基本条件上, 和SD最为接近, 但有一点不同, 就是不需要有很好的软件开发经验, 也就是不太需要会写程序。但要对操作系统, 服务器系统, 网络运用环境有相当程度的了解。
SE通常是三者中最为博学一员, 好的SE虽然不一定要程序写的呱呱叫, 但却不能对编程一无所知, 对操作系统及开发工具也要有一定的熟悉度, 甚至部份网管有关的工作也要有所涉猎, 所以算得上是项目里的万金油。
在项目里, SE所要执行的工作如下：
? 规划及建置系统执行环境
? 安装及设定使用者端环境
? SERVER安装及设定
? 提供环境设置竟见给SA及PM
? 最佳化系统可靠度及效度
? 撰写可靠度及效能测试计划书
? 对计算机及相关外围设备有一定熟悉度
而一名SE则有下列基本要求：
1. 至少熟悉一种操作系统, 尤其是让系统的设定及微调等相关技术
2. 至少熟悉一种网络服务器操作系统, 对如何设定及最佳化熟悉
3. 曾任软件工程师职务一年以上或熟悉一种开发工具
4. 对网络环境有一定的认识, 尤其是一些通讯设置
5. 熟悉可靠度及效能的评估方法, 并了解与系统环境相关之设定
基本上, 如果拥有了像SD一样的技术背景及个性, 但在美学上实在令人不敢恭维, 那么SE算是极佳的选择了。一般而言, SE的下一个生涯规划, 会比较偏重于技术性兵种, 像是DBA或是网管, 对于IT产品比较有狂热或爱好的人, SE是极佳的出路。
[在项目中的运用时机]
基 本上SE是万金油, 只要是IT的案子里就一定要塞一个SE进去, 因为没有IT项目不需要使用工程技术的, 差别只在使用何种工程技术而已。在软件包的导入项目里, SE负责处理软件使用环境, 解决非系统性问题, 安置及调整数据库和网络环境, 然后安装启动。所有系统运行所需要的条件, 都要由SE来解决和处理, 但这些工作全都不会出现在众人的面前, 但却又重要无比, 算得上是幕后的英雄。
会同时运用到SA,SD及SE的项目, 还是以客制化开发为主的。
在开发型项目里, SA团队要负责初期的需求调查及整体架构的规划, 将所有的系统开发工作内容转化成井井有条的文件, 并且适度的分割及派送, 并确保未来这些被分割的开发结果能够在未来可以正确运作。
SD 则在SA的文件中去寻求系统呈现的一致性, 易用性及保证开发工具可以正确无误的展现SA的要求结果。所以SD要负责操作界面的外观设计, 订定一致的展现规范, 设计系统操作画面及操作手顺, 同时配合SA完成系统开发文件。基本上, 开发文件中, 是包含系统使用手册初稿的。
SD在设计时, 必需与SA充分配合, 以确保设计的系统符合需求及运作要求。
除了上述的工作内容外, 这三者都要撰写测试计划, SA着重在于数据的流动符合原先规划的顺序及结果测试, SD则着重在操作画面中的防呆测试及操作接口的正确性, 而SE则在系统可靠度上进行规划。
我在MDE这个团队做了4年了，基于过去的经验，谈谈做MDE工作的感受吧。做MDE的工程师，和售前，售后，服务的工程师的工作有一定的相似性。MDE的全名是Market Development Engineering，所做的工作是帮助ISV在Sun的平台上进行开发，为他们进行移植，性能调优，测试提供技术支持，目标就是让ISV的产品在Sun的平台上运行得最好。MDE的工程师和服务部门的工程师是有区别的，服务部门的工程师按照合同为客户提供所需要的服务，比如帮助客户进行架构设计，进行系统开发等等，是工程项目的主体，而MDE的工程师是在项目中提供支持，支持客户（ISV）的工程师完成工作。MDE的工程师和做产品研发的工程师更是有区别了，不说大家也都明白。
目标和计划
MDE的工作需要我们积极主动地开展，而不是被动地等待。如何能作到积极主动呢？态度非常关键，我们需要用积极主动的态度，来驱动我们制订目标和计划，用目标和计划来保证积极主动的行动。我们每个财年都要做制订目标，这个目标里其实包括了三部分内容：为部门的目标所做的贡献；个人的目标；还有就是我们的客户计划。为部门的目标做贡献，很容易理解，但是怎么和个人的目标结合在一起呢？自己的兴趣在什么地方？自己需要在什么地方得到发展？能达到什么样的水平？举个例子，我们今年的重点是推动Solaris，我的强项是Java，我就希望自己今年在Solaris方面的技术水平得到提高，这就是我今年的目标。具体些，我会希望自己参加一个有深度的培训，学习1-2本经典的书，比如Solaris Internal；研究并掌握一项关键技术，比如Dtrace；发表一篇技术文章，比如如何使用Dtrace分析和解决I/O瓶径。客户的计划也是很重要的，我们的ISV最需要什么样的支持？困扰他们的是什么？他们今年的产品计划是什么样子？比如我有个ISV，他们打算把应用从某平台转到UNIX平台，我会了解他们计划在什么时候开始做移植工作，他们的应用是用C开发的还是Java，他们的客户对性能的要求是什么样子，他们要测试的硬件需求是什么样子，需要多少颗CPU的机器，多大的存贮等等。这些内容都是客户计划中的重要内容。
有的时候目标和计划的制订比较容易，但是完成计划会碰到困难。有人制订了发表3篇文章的计划，可是到Q3的时候还没有一个出来，问问情况，肯定会有很多理由，仔细分析，有些是真正的理由，有些则似乎是找的理由。我和一个同事聊过，我问他还有四个月，文章还没写，也没有具体的实施计划，所以说这个3篇文章的计划，倒象是一个愿望。这里有个关键的问题是行动没有和目标结合起来，也就是说没有具体行动的计划。怎么样才能够有具体的行动计划呢？可以给大家举两个人写文章的例子。一个是王昱，他在工作中感觉到很多人对J2EE的集群特性并不了解，于是就计划写这样的一篇文章，先是阅读一些文章，包括J2EE的规范等，然后把自己的思路写成幻灯片，感觉可以把幻灯片讲给听众了，再把内容填进去，写成最后的文章，最后发给相关的编辑进行审核，很快就发表了。另外的一个例子是张欢，她帮一个ISV解决了设置应用服务器SSL的问题，感觉这个问题很可能也会被其他的用户碰到，于是就把自己所碰到的问题，解决的方法，理出一个思路，然后整理成文章，最后是和编辑联系审核，发表得也很快。
管理时间
管理时间的概念里很重要的一点是，对于承诺的事情，要在规定的时间里提交结果。很多人都有这样的体会，原本计划做一件事情，在查资料的时候，发现里面有很多自己不熟悉的，于是顺着线索一路搜索下去，又是查资料，又是写测试程序，结果到了规定的时间，被问到为什么该提交的报告还没出来的时候，才发现自己在研究一个离原来的目标很远的题目，而且这个题目和自己原本的任务的关联性并不是很大。
另外一点是读邮件，相信大多数人都订阅了很多邮件列表，每天早上来的时候，会收到几十甚至是上百封邮件，怎么去看？如果按顺序从头看到尾，每封邮件都看，可能这一天都看不完邮件，那就什么都别做了。我也曾经有过这样的阶段，感觉自己一天都是邮件的奴隶了。我现在的做法是，针对技术邮件列表做过滤器，把和技术相关的放在一个特别的目录里，这样在看的时候，已经有很多都被过滤了，那些邮件基本上都不是紧急的，是作为信息来使用的，如果有时间我就会去看，如果没有就算了。处理收件夹中的邮件时，可以快速扫描标题和发件人，首先看紧急的，然后看其它的。对于能够在1分钟内就可以回的，马上回掉。如果需要等的时间比较长，比如几天，可以先给对放回个邮件，告知已经收到邮件，正在处理，可能会在几天后有结果。
做决定
做为MDE的工程师，每个人都是需要独立地和ISV工作的，每天都和ISV接触，可能做许多决定。那么怎么做这些决定呢？是不是都需要请示上级呢？如果没有规定好的流程或策略，我们自己怎么来做决定呢？首先要清楚自己能做决定的范围，以及规定好的流程和策略。如果是在自己的范围内，但是没有可依据的流程和策略，怎么办？playbook是一个帮助我们做决策的很好的工具。很多公司有会设置这样的playbook，而且还会逐级向下，在各个部门也建立playbook，playbook里会简明扼要地阐明公司或部门的发展目标或者优先级等。例如我们公司的playbook里确定了FY06的优先级是：
1. Make Money
2. Grow
3. Capitalize on Our Acquisitions
4. Leverage Our Partners
5. Re-enlisting Champions
6. Simplify Our Business
当我们遇到不知道该如何做决定的时候，就让playbook来帮助我们做决定。我们要做的事情和部门的目标是否一致？和公司的优先级是否吻合？playbook会告诉我们答案。
做决定还要及时。我们的工作中肯定会碰到些棘手的事情，难于做决定。有时，如果我们追求完美，一定要等待各个方面都充分准备好，或者是等待自己准备好，可能要过一年半载了。学会取舍，懂得“鱼和熊掌不可兼得”，用必要的丧失来（上大学的时候读过一本书，叫必要的丧失，是美国作家维尔斯特写的，当时感觉还是比较晦涩难懂）磨练心智，是成长过程中不可缺少的部分。
积极地沟通
有人说成功的职业人士有75%来自有效的沟通。沟通对于每个人都是重要的，尤其是对于MDE的工程师，因为我们要面临很多需要沟通的方面，而他们的角色还完全不同：内部的人员包括客户销售代表，合作伙伴销售，硬件销售，软件销售，产品开发工程师，产品维护工程师，外部的包括总代，集成商，ISV等各方面的商务和技术人员。和这些人的有效的沟通对我们的工作很关键。
我们在工作当中总会遇到这样那样的问题，如果问题是别人引起的，如何去提出（或解决）这些问题呢？有的人选择抱怨，或者强调客观理由，或者简单提出问题然后请对方解决。这些手段在大多数情况下都不能解决问题。比较有效的办法是首先确立一个比较好的心态，明白这个问题不是针对某个人的，就不会带着个人的情绪进来。然后客观地提出问题，还有，很重要的是能够提出建议，建议出一个解决该问题的方案。这样，非常有帮助于解决问题。
在我们和其他人沟通的过程中，有一点是需要我们特别注意的，就是避免产生让人吃惊的负面结果。比如说我在做一个移植的项目，ISV，我们的销售经理，我的老板，都知道这个项目，我也把SOW发给大家了，按计划在5月底完成。这里有个关键是某第三方软件目前还不支持Solaris，解决办法是联系这个第三方让他们移植，同时也劝说ISV采用一个开源的替代产品。我同时做这两方面的工作，但是不幸的是在5月30日的时候得知，第三方不同意移植，ISV也不愿意采用开源的产品。我只好写个邮件向大家汇报这个不幸的消息。其他的人可能都不知道其中的细节，销售可能还等着移植完成后在6月中旬投个标，这下全泡汤了。这就是让人吃惊的负面结果。如何避免呢？在开始的时候就通知所有相关的人，存在这样一个关键点，并说明其重要性，这样还可以发动大家一起来帮助我的工作，销售可能会申请经费帮助第三方移植，也可能会劝说ISV采用开源的产品，在5月底的时候很可能顺利完成移植。即使没有完成，大家也不会惊讶，因为大家都有心理预期了，都会提前做了准备。
说了这么多，都是软技巧方面的。我想大家都清楚，作为工程师，在技术上一定要过硬。有了坚实的技术背景，加上逐渐丰富的软技巧，大家一定会把这份工程师的工作做得非常出色的