友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
软件工程实践者的思想(PDF格式)-第4部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
是他的过错呢？如果因为不知道而出了问题，那管理者首
先应该自省才是。
第二条则是公平性的体现。不管是针对谁，制度都是
一样的，没有情面可讲的，常说的“特殊情况特殊处理”
在制度面前行不通。规矩一旦被破坏就形同虚设，反而被
员工作为笑柄，用来类比其它的制度。如此一来，整个的
制度也就离崩溃不远了。反过来，在已经被破坏了制度面
前，若再做杀鸡儆猴状，那猴子是被吓着了，不平声、怨
愤声也就跟着出来了。
因此最好的方法是赶紧修订制度，而不是修理人。
所以，经常的情况下，动摇了制度的人不是犯错的员
工，而是管理者自己。如果在制度面前，既做得到“人性
…33
…………………………………………………………Page 38……………………………………………………………
第 3 章 团队缺乏的不只是管理
化”，又做得到“公平性”，那么当管理者的便可以多做几
次黑脸的包龙图，而脖子上的脑袋便可以比李离顶得长久
一些。
5。 “那我们就开始开发吧”
现在，公司的组织机构和制度建设已经完成① 了，在
这个组织机构里，我们已经有了一个或者多个团队。接下
来，我们要真正的开始团队建设了。
这是任务。因为正在读书的你，和我一样，是要拉齐
七八杆枪，开始做工程的了。而在这一切开始之前，再之
前的时间里，我还想知道一件事：你知道如何做工程吗？
我们先来回顾一下。
前一章说的是编程，EN ，那实在简单，愚公式的工
作。我们先不管愚公们的水平如何，以及够不够勤快，反
正，他们会编程就是了。
上一章呢，说的是一部分懒人“创造”或“寻找”到
一些编程的方法。这些懒人们可能来源于做得太老的、或
者太累的愚公，或者是……一些看着愚公们着急，又被闲
出毛病了人。反正他们找了一些方法出来，而我们的愚公
们也已经学会了这些方法。
现在，有了会（ 比较快速地）编程的愚公，而且有了公
司，我们完成了组织机构建设，我们还找到了一名（或好
① 这里的“完成”是指告一段落，或者说是阶段性的结束了。完
成，并不等于完善。而完美，则更是无可企及。
…34
…………………………………………………………Page 39……………………………………………………………
『大道至简』
多名） 项目经理，他们一不怕死，二不怕苦……对了，更
为可喜的是我们还有了开发部：对内，我们订了一套规章
制度；对外，我们还拿到了项目单子。
“那我们就开始开发吧”——你就这样给我说。
很久以前，很久很久以前，人们都是这样做的。拿到
项目单子，然后“那我们就开始开发吧”。这样的事出现
得很自然，因为积极的愚公们总是有挖山不止的欲望。所
以他们一看到项目单子，第一个反应就是：那我们就开始
开发吧。
做了这么多年项目，我现在一听到这句话，就哆嗦。
6。 组织的学问：角色
现在先考察一下你的公司，在整个系统里面，有没有
这样的人：他既不归任何人管理，也不管理任何的他人。
如果有，那么就早早地把他开掉好了。
这样的人在组织机构中是一个盲点，或者空洞。按照
我的观点来看，他在组织中不担任任何的角色，既然“不
是角色”，那么当然要开掉。
在任何错误被归咎于员工之前，管理者应该先想想是
不是自己的问题。
是的。你可能很快发现问题出在了管理者。因为管理
者没有确定组织机构模式，或者没有为组织中的成员进行
…35
…………………………………………………………Page 40……………………………………………………………
第 3 章 团队缺乏的不只是管理
角色定位和分工。如果这样，出现“既不能令，又不受命”
的人就是必然的事了。
同样的道理，在工程开始“做”之前就得先把“角色”
确定好。——可能部分角色是组织机构相关的，例如“部
门经理”和“开发人员”；而有些就需要临时授命。
对于一个项目来说，第一个授命的人的当然是“项目
经理”。接下来的事件就复杂得多了。按照微软的惯例，
授命项目经理的同时，会有“产品经理”、“开发经理”、
“市场经理”以及“文档化和培训负责人”。这当然不表
明至少需要 5 个人才能构成团队，在大量角色从项目团队
中抽取与剥离后，我们可以得到一个精减的团队模型① （在
后面我会把它叫“R模型② ”）：
① 我非常不情愿给出一个模型来让读者跟随，但如果没有这样的
一个模型，我想接下来的讲述可能会令很多人如坠雾里。明确的
组织机构，既是团队的关键，也是我们思考问题的基础。
② 我试图找一个单词来表现这个模型的简单和粗糙。我得到的一
个建议是Rough（粗糙的） 。然而我更愿意溯源到这个单词在古英语
中的形态（Ruh） ，希望我这样一再强调，能让你真正地注意到：“R
模型”是一个原始而且粗糙的东西。
…36
…………………………………………………………Page 41……………………………………………………………
『大道至简』
更上层管理
品质部门 文档和培训 客服部门 市场部门
开发团队
开发经理
项目经理
开发人员
在保障这样一个组织机构模式的过程中，有几点是需
要注意的：
） 如果项目针对直接客户，而且没有产品化的可能
性（或必要性） ，那么可以将与市场（ 以及市场部门）
相关的问题和角色先暂时放在一边。
） 已经存在于开发团队中的成员，不适合在品质部
门中兼任角色。
） 项目经理应致力于减少团队中开发角色与其它
部门的沟通，必要时开发经理应该站在开发人员
之前进行部门间的交互。
） 品质部门、文档和培训部门和客服部门应该主要
由有专门培训的人员构成，尽管开发人员可以
（或者经常会）参与文档、培训和客服工作，但这
也通常是他们最不能胜任的角色。
这是中小型规模的公司和团队的参考组织机构模型，
对大型团队并不适用。
…37
…………………………………………………………Page 42……………………………………………………………
第 3 章 团队缺乏的不只是管理
在这个模型中，我们仍然看到了一个至少由三个人构
成团队。其中，在开发经理和开发人员之间，既存在主从
关系，也存在协作关系。而项目经理，则在团队中处于领
导者、组织者和团队保障者的地位。
如果非得要精简到两个角色的团队模式，那么这种情
况下，通常是开发经理兼任项目经理，因此这位开发经理
一定要能清楚地区分这种双层角色的身份：在任何时候，
明确自己是在进行“团队内协作”、还是“团队管理（和组
织） ”、还是在与“团队外交流”。
如果这个开发经理总是混淆自己的角色，那么，我建
议，换人吧。
7。 跟随蚂蚁。但不要栽进蚂蚁洞里。
团队真的需要管理吗？
这经常是“经营”开发团队的管理者最容易给错答案
的问题。这些管理者兢兢业业，试图细化每一个管理环节，
将自己的意愿贯彻到……EN ，CPU 里去。
实际上，开发团队并不需管理。或者说，在你还没有
弄清楚状况之前，不要去管它。
温伯格（Gerald M。 Weinberg）在“给软件开发经理的建
议”中提到了这样一个问题：开发经理如何面对一个并非
由他亲自雇佣成员的团队。温伯格的回答是：
） 与成员面谈，让他们签约受雇于你；
） 或者，解聘他们；
…38
…………………………………………………………Page 43……………………………………………………………
『大道至简』
） 再或者，放弃这个职位。
温伯格的意思是“没办法管就不管”。温伯格当然可
以有更多的选择，他总可以找到适合自己管的公司。然而
目前，你可能是唯一的人选。或者你原本就期待这个角色
很久了，当然不能象温伯格一样放弃。
你得找办法来解决团队问题。
“签约”这样的事，在大多数环境下是行不通的。要
知道，既然他们与公司的签约保证不了他们工作的质量，
同样与你的这份签约也不会。协议并不能建立管理者与被
管理者的信任，而只是确保了这种关系。
但是你应该相信我，在你接手这个团队之前，上一任
经理也确保了这种关系。然而团队失败了，否则不会换作
是你。
所以告诉团队成员“现在轮到我管理你们了”，根本
就是一句废话。或者在你来之前，他们就已经知道你要来
了。
小的时候，我就喜欢观察蚂蚁。我喜欢看它们成群结
队地搬着东西穿过小路，或者水沟。我尝试用木棍导引它
们改变行动的路线，然而不久之后，它们就会翻过那根木
棍，按照既定的路线行进。
禀性难移，要改变一个人都难，何况是改变一个团队
的既定习惯。
如果有一群开发人员象蚂蚁一样辛勒地工作着，那
…39
…………………………………………………………Page 44……………………………………………………………
第 3 章 团队缺乏的不只是管理
么，先不要打扰他们。你应该跟随他们，看看他们是如何
做的。发现规律，分析这个规律的价值，最后再尝试改变
它们（ 的一些负面价值的规律） 。
所以你要紧紧地跟随他们。——除了一个地方。那地
方是你去不得的，那就是蚂蚁洞。
显然，你不是开发者，你是管理人员。所以尽管你是
团队中的角色，但千万记得离蚂蚁洞远点。你在洞外张望，
可以发现问题；你在洞内，就只有做“循规蹈矩”的蚂蚁。
管理者是那个可以在洞外放木棍的人。
8。 “什么是增值税发票？”
现在你已经足够地观察了你的团队，你知道这个团队
存在问题，你也知道你需要改变。当然，你也知道这种改
变并不是放一根木棍那么简单。
你已经确定了组织结构，确定了组织中的角色，还有
了一个团队（5 个？或者 10 个？） 的人。所以作为项目经理，
你需要先分工。
在分工之前，那个团队只能算是一个没有组织与合作
的群体（所以英文中群是 Group ，而开发团队是 Team） 。
被优先考虑的是弹性分工。每一个人都被要求做一颗
革命的螺丝钉，哪里需要哪里拧。所以弹性分工总是被放
在企业节省人力资本的第一要务上。然而我们真的会做弹
…40
…………………………………………………………Page 45……………………………………………………………
『大道至简』
性分工吗？
蚂蚁的分工模式之一就是弹性分工。一只蚂蚁搬食物
往回走时，碰到下一只蚂蚁，会把食物交给它，自己再回
头；碰到上游的蚂蚁时，将食物接过来，再交给下一只蚂
蚁。蚂蚁要在哪个位置换手不一定，唯一固定的是起始点
和目的地。
确定被“弹性分工”的员工需要可以快速地转换到新
的角色，但首要考察的并不是他是否“有能力”胜任这个
角色。能力可以通过学习来增强，而角色的转换，则首先
是思想的转换。
1997 年，P&J 的公司打算全面拓展市场，我随他一
起到了成都。当时我是开发部的三个主力开发人员之一，
因此在原定计划里，我是到成都组建西南区开发部（或技
术中心） 。然而在两周之后，P&J 发现总公司的运作存在
问题，因此他必须回郑州。P&J 决定将成都市场的问题全
权交给我，换而言之，我必须出任成都办事处经理。
我对市场一窍不通，也不懂得公司的经营与管理。但
很明显，做办事处经理不是做技术，这与我（ 当时的）个人
意愿是相背的。于是我拒而不受。理由也很充分：我不会
做市场。
P&J 用了两天的时间来说服我，直到在临回郑州的前
一晚我仍未能接受这个任命。这时他告诉我：即使是做开
发，也是需要了解市场的，你必须知道用户想要什么，你
必须理解你的客户。因此你如果想要做一个好的开发人
…41
…………………………………………………………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。。。 这叫需求建模”他们很
专业地说。
现在你应该发现了差距。比如我们的项目经理，以及
那个被调来充当调研角色的程序员，他们就不会什么“需
求建模”。
接下来咨询公司会与我们的客户一起做业务建模，然
后再做业务到需求的映射，再抽取需求并完成需求建�
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！