按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
…………………………………………………………Page 46……………………………………………………………
第 3 章 团队缺乏的不只是管理
员，你应该正视这次机会。
我沉默了许久。我想明白了两件事：从公司的角度上，
我必须接受这个职务；从个人的角度上，我需要接受这个
职务。于是，我问了我的第一个问题：“什么是增值税发
票？”
P&J 笑了。接下来我们开始讨论经营问题。第二天
P&J 飞回郑州。五个月后我升任西南区总经理，一年后，
西南区做到六个分区市场中业绩第二。此后我辞职回到郑
州，再一次从开发人员做起。
“什么是增值税发票？”意味着从技术到经营的角色
转变。这个问题本身带来的并不是能力的提升，但如果我
提不出这个问题，我将没有可能理解经营与市场。
尽管弹性分工非常有效，然而真正做弹性分工却并非
易事。蚂蚁的角色转换是本能的，而 P&J 却不得不花两
天时间来说服我。因而更应当留意团队成员“自激”式的
角色转换，知道他是不是真的想（而不是需要）转变一下角
色，这样起码可以省去你两天的功夫。
然而能提问“什么是增值税发票”的愚公毕竟不是太
多，大多数时候他们在“箕畚运于渤海之尾”，如果实在
闲得厉害，他们可能会去发明翅膀，而不是思考“什么是
增值税发票？”
更好的选择是明确分工，而不是弹性分工。你应该明
白，重要角色的更替通常是极具风险的，例如项目经理或
…42
…………………………………………………………Page 47……………………………………………………………
『大道至简』
者开发经理；频繁的开发人员的调度也会直接影响到工程
的质量和进度。
如果所有人都在思考“什么是增值税发票”，那么你
的组织机构将立即溃散。
因此，明确分工是你的管理职责。做管理≠做伯乐。
…43
…………………………………………………………Page 48……………………………………………………………
第4章 流于形式的沟通
“足下求速化之术，不于其人，乃以访愈，是所谓借
听于聋，求道于盲。”
——唐·韩愈《答陈生书》
1。 客户不会用 C ，难道就会用 UML 吗？
我们总是要先接触客户的，是的，如果不这样，我们
将无法确知要做什么。
作为开发人员，可能更希望客户能学习或者精通 C
语言，这样客户就知道开发人员正在做什么，以及有多么
地勤劳。或者，这样的客户还能以 C 语言的方式告诉开
发人员他们究竟想要什么。
然而要求客户学习 C 语言明显是自杀式的行为。在
客户（ 的代表） 学会用 C 语言来向开发人员描述他们的需求
之前，可能他就已经被老板开掉了。因此没有客户会笨到
愿意用 C 语言来描述他们的需求。
C 语言是程序员与计算机交流的语言，而不是他与客
户交流的语言。程序员面对的是计算机，但计算机不是客
户。
因此在前面所提到的 R 模型中，开发人员最好不要
…44
…………………………………………………………Page 49……………………………………………………………
『大道至简』
直接面对客户。项目经理有这样的一种优势：他可以不用
了解 C 语言，也可以用一种非 C 的语言来与客户交流（ 比
如说汉语） 。
——或者你更愿意开发人员尽早地进入状态，那么你
可以让开发人员以需求调研的身份出现在客户面前。但
是，请注意这个人员的角色将变成“需求调研”，如果他
不能适应这种转变，那就别让他去。——那会是灾难的开
始。
要深入项目的需求阶段的项目经理或者调研人员，被
要求深谙项目所涉的业务。但这往往我们所做不到的，因
为我们是软件公司，而不是做这些（客户的）业务的公司。
这时惯常的做法是聘请行业咨询公司（ 或者个人） 来介入
需求阶段，协助了解和分析需求。
他们总是很喜欢把事情搞得很复杂，所以他们会说这
一切的过程有个专用名词，“En。。。 这叫需求建模”他们很
专业地说。
现在你应该发现了差距。比如我们的项目经理，以及
那个被调来充当调研角色的程序员，他们就不会什么“需
求建模”。
接下来咨询公司会与我们的客户一起做业务建模，然
后再做业务到需求的映射，再抽取需求并完成需求建模。
他们做业务建模的时候，可能使用一些客户业务范畴内的
符号和标识；而在做需求建模时，则需要使用一些软件行
…45
…………………………………………………………Page 50……………………………………………………………
第 4 章 流于形式的沟通
业中（ 的设计和分析人员） 习惯的符号和标识。
这些符号和标识也有个专用名称，“En。。。 这个叫模型
语言（ML） 。”他们无时无刻不在向你展现他们的专业（这已
经是他们还存在的唯一原因了） 。
如果他们更加专业，他们会告诉你他们用的是 UML 。
向你介绍这个名词的时候，他们的眼镜或者眼睛里通常将
大放异彩。
①
UML 是模型世界里的世界语 。
到现在为止，你应该看到，咨询公司除了把问题搞得
更加复杂之外，他们仍然需要面对最直接的问题：与客户
如何交流？
他们的解决之道是模型语言。
有什么差别吗？
程序员不能要求客户会 C Language ，难道需求分析师
们就能要求客户会 Modeling Language 吗？！
2。 项目文档真的可以用甲骨文来写
独 孤 木 （http：//javaworld。。tw/） 曾 经 在 一 篇
《UML； OOAD and RUP 》中讨论到 UML 实际应用中的问
题。其中的两个问题是：
① 现实的情况未必如此。但UML 这个名词起码显示了它本源性的
期望：Unified Modeling Language（ 统一模型语言） 。
…46
…………………………………………………………Page 51……………………………………………………………
『大道至简』
） “大部分的使用者，以及客户的信息人员，其实
并没有足够的能力，来确认这些文件（User Case）
的正确性与完整性。”
） “除了客户不了解UML ，OOAD 跟 RUP 以外，
另外一个更糟糕的现象就是 project team 里面
的人也不懂。”
这实在是很有趣的事。
看来在一些情况下，在项目中使用 UML 只是完全不
懂的老板，以及什么都懂的博士的主意，而真实的场景中
去做事的那些客户与项目成员，其实是未见得就能用好
UML 的。
仅以 UML 的 User Case 来说，由“用例图”和“用
例规约”组成。规约跟我们写的需求说明书差不多，不过
更加细节罢了，而且还有一套相应的方法论来阐述如果去
实作。图则很简单，就是几个图形符号来描述系统边界和
角色关系。
显然甲骨文也能描述范围与关系。例如甲骨文中的
① ，这个边界就定义
“家”这个字，就是上有房子下有猪
得很好；在古文中，“三”通常是泛指，跟UML 图中的线
条上标注的那个“* ”是同义的，而甲骨文中“众”这个
① 至于是“内有猪”还是“下有猪”的问题，不是我们要争论的。
有些考古学家根据甲骨文的象形来认为古人与家猪是杂居的，但
我想那时的猪可能还比较野性，因此这种可能性还是小些。
…47
…………………………………………………………Page 52……………………………………………………………
第 4 章 流于形式的沟通
字，就是日字下立有三个人，也就是在同一个日头下做事
的很多人即为“众”，这个关系也描述得很确切。
所以只要你运用得法，甲骨文一样可以用来画用例图
和写用例规约。同样的，只要约定一套“语法”，你同样
可以用甲骨文来做活动图、类图、构件图……以及这些图
相关的规约。相比来说，古巴比伦人使用的楔形文字“象
形性”差一些，因此我不建议用它来画用例图。
既然甲骨文可以用来做为一种模型语言（ 同时它也是
一种文字和口头的语言） ，那么，如果你的项目中面对的
对象是商周文化的考古学家，以及你的项目组都由精通这
种语言的成员构成，这时你就可以用甲骨文来做项目文
档，以及画各种模型图例。
你要明白，要让考古学家看懂用例图，难度远大于看
懂甲骨文。与其要求他们学一种语言，不如使用他们那个
世界的通用语（ 当然，前提你的项目组也懂得这种语言） 。
在韩愈的《答陈生书》中，他因自己不会“速