笔者任职顾问的公司最近上线了一个千人使用的系统，同时使用人数也有八百人，看着近十人的开发团队忙碌了一年多，终于完成任务，于是兴起邀请他们一起喝个下午茶，叙说一下其中酸甜苦辣的念头。
这个团队相当有默契，核心成员的合作时间超过 4 年以上，该系统的上一个版本也是他们开发的，各个基本功夫扎实，总能完成所赋予的大小任务。最难能可贵的是他们勇于尝试新技术的魄力与孜孜不倦地自我充实。
访谈纪要
在这次的访谈过程中，笔者想要记录一下信息人的甘苦，并没有什么技术研究，或是系统建置的理论分析，你可以将之当做他山之石，或是茶余饭后，看看我们的亲身经历，或许会让大家心有戚戚。
在闲聊的过程中，我们不拘型式，也没有预设主题，仅仅是喝咖啡聊是非。但事后笔者将之以系统访谈分析、设计、程序撰写、除错、上线维护等面向来分门别类地整理，并未照大伙儿聊天的先后顺序。
另外，为了让发言者畅所欲言，所以在此笔者不以真实姓名标示，仅以甲、乙、丙等代为称呼，避免无谓的纷争。以下是这次访谈的纪要：
一进到会议室，看到黑板上留着不知哪位同事写的：
「As long as your house has windows, it won’t be safe」
笔者为这位仁兄一语双关的幽默乐了一会。但系统开发人员似乎都背负着这种原罪，使用者从其它方面所获得的认知往往会成为他评断系统好坏的成见，在他无法评断系统开发团队的技术优劣时，这种认知是沟通时潜在的危机。
笔者另外听到我们部分的系统功能被使用者评为：「你要培养你的耐心，除了钓鱼外，还可以用这个系统。」又为之一乐，应该有人写个屏幕保护程序，在前端机器等待服务器响应时，自动切换成钓鱼游戏，那个使用者就会成为全世界最有耐心的人。
系统分析以及与使用者的互动
甲：使用者根本不晓得他要什么，要不断地修改需求。最惨的是明明有提这个需求，等我们开发了一半，他居然又不要这个需求，还死不承认他有说过，真是被使用者出卖了。
大家都颇认同此点，唉， MIS 是支持单位，很难要公司营运的主力单位为他们所提的需求明细立下切结书，系统分析一改再改似乎屡见不鲜，虽然对象导向分析设计尝试要解决这个问题，但要用得好，似乎还有一大段路要走。
乙：使用者可能会很烦，任何鸡毛蒜皮的事都问你，我们变成全面性的顾问，连非系统的问题都来了，包括不会用中文输入法、屏幕没插电、网络线没接。
丙：因为使用者的计算机基本素养很差，计算机的问题没厘清就气急败坏地诘问我们，问问题时还夹杂不清。
丁：我就发生过想要透过屏幕左下角的「开始」来叫出「控制台」来查看使用者的「打印机」设定。但在移鼠标的过程中，就被使用者粗暴地将手拍开，还咆哮说：「你们只会重开机，还会什么」。
唉，计算机要是像电视就好了，我们总是要承受使用者在操控计算机时所招受的挫折，在他们屡试屡败灰头土脸时，我们就成了宣泄的窗口。
戊：使用者没有建置系统的时程观念，往往一提出五分钟后就要看结果。
这就考验大伙儿的抗压性了，尤其在对方来头很大又义正辞严的时候，若随着需求起舞，势必让系统支离破碎，但若要从整体架构来思考，若该系统不是一两个人在开发，而需要整个团队沟通协调，这势必旷日费时。
甲：异常处理比正常处理还困难，且技术不清楚，还吹毛求疵。
丁：一些辅助的技术人员，从自己的角度出发，不尊重系统开发人员的考虑，尚未了解整个系统就透过管理高层影响原来的架构设计。
在整个企业的各信息部门间，似乎弥漫着文人相轻的烟硝味，带笔者进入这个企业的前辈就曾有「叫他们去死好了！」的名句，至今仍流传在我们开发人员之间，大家朗朗上口。我们都有个感觉，「不怕完全不懂的，但怕懂一半的。」除了半瓶水晃荡外，最怕他还想主导系统。
甲：建置一个系统好像生自己的孩子，自己掌控酝酿过程，很有趣味与成就感。
庚：当我把繁杂的工作利用系统的种种功能，如 SQL Server 的 Job、OS 的 Schedule 简化，自动化后，有很大的成就感。
哇，整个聊天过程中，如此的「甘」味，真是凤毛麟角。但能大声地说：「OOO 系统是我做的。」…爽！
甲：系统分析师要清楚每个程设师的风格，否则很难沟通协调。
己：程设师也要清楚系统分析师的风格啊。
团队开发就需要十足的默契，单打独斗的信息系统恐怕很难符合众人的需求，但若团队成员一直走马换将，恐怕做出来的程序错误比功能还多，安抚内部成员比安抚使用者还累。
丙：最麻烦的是使用者派系林立，彼此对系统的需求不同，各方提出的需求竟然还互相冲突。这造成系统多了一大堆选项
丙：使用者若个性好恶强烈，配合意愿低，鼠标点选都嫌麻烦，尤其是在 DOS 与 Windows 接口转换时，要求 Windows 的程序要长得像 DOS，至今都还要浏览器去模拟。
这位同事就这样熬了六年，怪不得他是笔者所见过最强的 VB 程序设计师。相信你只要能把 DOS 的环境写得像 Windows，Windows 的环境模拟的像 DOS，IE 浏览器还要兼具两者的特性，就一定能练就不少特异功能
辛:像我以前待的公司主管们都有共通的想法，觉得IT部门是最会花钱的单位，所以他们在做决定都以省钱为目的，这我并不反对，但是有时候太过头了。
辛:举个例子，主机代管去找那些名不见经传的小公司，结果发生假日大断线找不到人去解决，或者公司不愿意装防火墙，等到被黑客入侵时才知道问题的严重性…(族繁不及备载)。所以常常都是事先的建议都不被采纳，等到发生问题后才在跳脚，何必呢！？
系统设计
甲：我们很难估量系统规格，如 RAM、CPU 数目，尤其人数多，系统复杂。
唉，笔者还见过当初 ERP 系统的使用规格是 180 人同时上线，但「专业的」ERP 顾问团队导入的 Unix 机器上线操过 18 个人就不行了，CRM 部分只要第二个人进入就 JSP Timeout，好个「千万级 PC」。
另一个案例是原本 32 颗 CPU 的机器，发现程序本身平行运算处理不佳，在超过四颗 CPU 后，效能不增反降，只好将该机器切成八台逻辑机器来跑，早知买 8 台 4 颗 CPU 的机器还比较便宜。
多大的需求要多大的硬件，这一直是个恼人的问题。毕竟多个人进入系统后所产生的交互作用不是你我可以轻易估算得出来。而如何厘清效能瓶颈更是困难，最怕的是花了大钱扩增了硬件，但毫无起色。
程序撰写
丁：系统分析一直在变，程序代码就改写不完。尤其是系统分析时没预留弹性或是导错方向，常导致程序代码必须做结构性的修改。
唉，使用者追着分析师跑，分析师追着程序员跑，一个躲一个啊。
乙：开发工具与架构一直变，如 VB 变 VB.NET，ASP 变 ASP.NET，DAO -> RDO -> ADO -> ADO.NET
丙：辅助的资源不足，现在还好一点，例如微软提供了完整的 DHTML 的网站在线说明，让我可以找到各种语法的使用方式，但往往有一些少用的技术很难找到明确的说明。
说到此点，大家都有一肚子苦水，别的行业是随着经验累积，做起事来越来越顺手，我们却总要隔一段时间就归零一次，韧性不强，兴趣不高还真难混得好。
丙：我们没有专门的文件撰写人员，总是有些拉拉杂杂的事要做，干扰程序撰写。
己：我们还少专业的测试人员，以及客服(Help Desk)和美工，使用者嫌我们设计的画面太丑，设计时还不可有政治影射，如不可太多的红色、蓝色、绿色、橘色、黄色…等等。
丁：可能还需要专门负责教育训练的人。我们就曾在教育训练的过程中被使用者抱怨过，我们对功能说明的用词与他们所习惯的说法不同，以致于他们全都有听没有懂。
不知谁补了一句：「唉，还不能七个颜色都用上喔，那有性暗示。」笔者对于此点也有经验，我所认识的一位高强的网站开发人员，他不分昼夜地完成了某个企业的网站后，主管阶层觉得太不专业了，因此增聘了一个美术人员，整个网站于是改头换面。大家都觉得这真是最专业的网站了，在总经理巡视时，高阶主管力捧这个美工人员，但却漏了介绍这个程序设计师。唉，情何以堪啊。
乙：太多的资源都是英文的，学习时间拉长。
辛：我觉得台湾这里可以找到程序技术的资源太少了，可能是以前待的公司经常接触对岸的工程师，所以有的时候找一些文章都直接上对岸的网站寻找，都会有意想不到的收获。
丙：当开发架构不好时，如开发工具的除错环境不完整，会让整个开发过程的困难度大幅提升。
不仅技术常常归零，重新学习的路还布满荆棘。
丙：开发的环境与使用者的环境不同，而使用者的环境每个人都不同，如屏幕分辨率(这只是个举例说明)，要顾及到所有人的个人化设定很困难。
笔者所在的企业体，其上千个使用者都不具备信息专业，但每个人的独立性都很高，都是高学历，具个人风格，我们无法强制他们有什么用什么。只好提供接口程序有大量选择性，每个人可以各自依喜好设定，所以程序不仅要具功能面，还要有高度的亲合力。
测试与除错
丙：很难做压力测试，若在一开始的设计架构若不适合，之后要调整很困难，但一开始又很难做压力测试。
我们这个团队似乎还缺一个架构工程师，但在国内很难累积经验，因为大家都是关着门做自己的系统，少有专业的顾问团队可以一起参与，在建构的系统有限，见识不广经验不足的情况下，要有称职的架构工程师很难，
丁：使用者的错误回报通常只是最后的状态，对于「事发经过」常是一问三不知。我们总必需在事后扮演福尔摩斯，从各种蛛丝马迹重建犯罪现场，也因此必需在各种系统中留下大量的 LOG。
看到此处你可以想见一个系统除了满足应有的使用者需求外，我们还要加多少东西在里面吗？忘了告诉你，监控人员要我们的系统在不同的例外状况发生时，要会唱不同的歌，因为我们有一百多个系统要监控，眼睛看不到，耳朵要听到。
上线维护
庚：每次在问题发生时，如数据库效能不足，总觉得工具不够。现在的系统已经太过复杂，很难厘清前因后果。
甲：当问题发生时，往往很紧急，无法及时厘清问题。
乙：常常是管理人员立刻重开机，或是将丛集系统(Cluster)系统 Move Group 到另外一台机器上，这让所有的证据都消失了。
庚：我们的工具大都是看到一些现象，但这是几百个使用者互动的结果，还有多个伺服程序特有的习性我们不熟悉，很难在当下治本，往往只能头痛医头的方式，立刻排除问题。但老问题常常会重复上演。
微软的效能调教制式教材上标示着各项成功元素所占的百分率：先前的经验 19%、解决问题的能力 22%、监控的能力 16%、产品的熟悉程度 26%、计算机的相关知识 13%、运气 4%。天啊，你是全世界最强的信息人员，若上苍不眷顾，还是有 4% 的机会不得成功。
甲：新旧系统平行上线时，要同时运行合作很麻烦，尤其在两个系统间的数据交换。
乙：还会有人事安排的问题，新系统上线往往要评估人力精简的好处，我们要与被精简掉的人谈需求。
丙：只要死不承认系统是自己做的就可以了。
现代版的请君入瓮。信息人员不但技术要好，连交际手腕都需要具备…大家对此只能苦笑了。
庚：新旧系统要兼容，并行操作，取代很困难，系统开发时很难具备未来技术所需要的弹性。
戊：新旧系统交换时，数据不合，很难整合。
尤其是有一大堆违章建筑的陈年老系统，其中有一大堆你不熟的老技术，混乱的数据结构…开发这个系统的人早已经离职，不见踪影，到你手上已经是好几代的前辈交接过，这是公司里最著名的杀手级应用程序，不是它太好了，把竞争者都逐出市场，而是太糟了，所有接手的工程师都以离职为最后依归，而你为什么会接到这个烫手山芋，因为是新进的菜鸟，苦啊！
好了，幸好只有三小时，苦水吐到此。不知你是否有稍微算一下，身为一个信息人要具备多少功夫，才能让使用者满意我们所建置的系统。
在将近三个小时的访谈中，笔者发现团队成员的 EQ 都很高，这个甘苦谈还真苦，但整个过程中笑声不断，对于解决问题各个都乐在其中，提供了系统的质量保证。下次若还有机会，我们再换个主题聊聊。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=925578
