焦油坑---走出软件作坊：三五个人十来条枪 如何成为开发正规军（十八）

我有一个以前的同事。过去他总认为能成事的人什么时候都能成事，不能成事的人你再扶他也成不了事。所以他带领人的方法一般是他以身作则，你如果有悟性，你就照着他做，如果你看不出来，那么你就自己一个人玩着去，能玩成什么样玩成什么样。

我主张的是：普通人通过使用一定的方法和规则，做事情虽然无法做到优秀，但也至少能保持一定水准，不会把事情做烂。如果任由普通人自己去想自己去 做，这要管理者何用？作为管理软件开发公司，其管理思想，竞争不过管理咨询公司，其技术实力，又没有技术门槛，属于那种规模化生产实施服务的类型。所以， 管理软件开发公司要想成长，必须走规模化路线。而规模化路线就需要依靠大量的普通人才，而非个别的英雄。英雄是很难找到大量人才的，而且优秀的人才其成本 也高，更约束的无法规模扩张。这和规模化路线有悖。

所以，他带出来的兵都是单兵作战能力很高，都属于那种能救火队员型，有问题冲上去嘁哩喀喳就搞定。领导是很喜欢这样的人才的，因为这样的人是多面 手，是特种战士，把一个人随便往哪一扔都能把项目完成的很好，很省成本。但是这样的人才有个特点，没有一年半载，这样的人培养不出来。而且这样的人往往都 游兵散勇似的，一遇到必须合作的事情就变扭，老觉得其他人办事都不放心，都觉得别人做的没他预想的那么好，还不如自己一个人都包办了快速且省事。

而我带出来的兵都是团队作战型，每次做事，都需要好几个各自发展专业的人配合，一个人还搞不定。就好像开发的时候用开源的框架，本来只想使用A框 架，没想到A框架使用了B框架，B框架使用了C框架，最后软件没多大，倒是框架很大。虽然我都是极力推行四套马车4人一个小组，而且可以看项目进展安排不 断调度组合，但终究不如一个特种战士那样自由。但有一个好处就是做事专业，发挥稳定，培养成长快，好招聘好留人团队稳定，薪资成本也低。

隔了这么多年，我的电话也换了，他的电话我也没记住。我们就这样断了联系。

突然，上个星期五，他给我发了封邮件。说他偶尔看到了我的博客，写的不错（不知道是不是真的不错，反正他以前一直反对我的这种思路），希望我能写些关于需求管理的文章。

我赶快根据他邮件中留给我的联系方式联系到了他。

我问他：你怎么找到我的博客的？

他说：这几年越来越不好做。客户对开发对实施对服务的质量要求越来越高，一个人去现场边修改边实施，客户觉得付那么多钱不合算，怎么着也得派一个团 队来实施。但是，团队实施没有人手啊。培养一个人一年都上不了手，对于我们来说团队实施就不合算了。但客户就要团队实施，不团队实施就无法接单。所以，我 现在也在找一些如何团队开发实施的文章，无意就找到了你的博客。

我们现在也是文档化管理。从需求调研到需求确认到需求设计到需求开发，每一个环节我们都是和客户文档确认，大家都觉得没有问题了双方看法一致才开 发。一开始使用就发现需要修改的东西很多，而不修改又导致客户无法使用下去，最后不断修改，导致实施周期长，结果还跟过去一样，质量也没提高，周期也没有 缩短。所以，比较迷茫，是不是哪里做的有问题？你一直挺注重过程管理，看你写了那么多文章，肯定这么多年你一直在研究这方面，所以我估计你有一些好的方 法。

我说：我这些天写博客，接到不少网友的评论，他们也强烈希望我能写一篇关于需求管理的文章。我过去也有一些只言片语的积累，所以这次我就准备写一篇以了大家心愿。

当我开始动笔写这篇博客的时候，我脑海里直接的就是《人月神话》中最著名的一段话（不好意思，其实我没有看过人月神话，不知道作者提供了什么解决方法解决需求难题）：

人类史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧去挣脱束缚，到最后它们都沉到了坑底。

这段话描写的栩栩如生，和我们日常遇到的需求困境如出一辙。

中国人的需求很特别，好像事情都特别赶人都特别忙似的，都寥寥数语就以为他的需求已经说清楚而且你也肯定明白了，到底能不能实现，实现后能不能可操作可执行，都是匆匆一个见面一个电话几句MSN几句MAIL然后就等着软件开发出来用。

我看到日本人花费一年的时间反复和客户讨论需求，深入到生产一线天天蹲点，还派人拿专业的测量工具来记录，如拿秒表记录操作的时间，拿摄相机拍摄操 作流程，有大量的过程检测指标需要15分钟确认一次，很是认真，然后才设计解决问题的软件功能。对于每个操作的软件界面也是反复和客户确认，如何更容易理 解更方便操作。

我见到许多国内项目经理调研没个方法，东一榔头西一棒槌，需求调研像是开座谈会，一屋子人，有干系的人都请来开会。有最终操作用户，有部门管理者， 有大老板，有二老板，有计算机室，好几个部门。每个人站的角度，层次都不同，关注的问题重点也不同，眼光长远也不同，有人悲观有人乐观，有人不懂装懂，有 人不懂瞎嚷嚷，有的部门影响力大气粗的不行，有的部门比较势力小唯唯诺诺，有的部门不愿意多干就推来推去反正不是他部门的事情，到底是哪个部门的事情需要 大领导来定，但可惜大领导没来，有的部门怕自己那点内部发小财被破坏了就故意找各种各样的困难还说的头头是道，于是一帮人叽叽喳喳，没个结论。有时候开会 开多了，实在说不过去了，必须要有一个结论，于是每个人的意见都上了需求本，回来一整理，没法弄。

我曾经参与过一个项目就遇到了这样一个情形，最后拖的时间太长，项目主导方认为没什么利益可赚，而客户冲突利益太多，就放弃这个项目了。

“表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当他们相互纠缠和积累在一起的时候，团队的行动就会变得越来越慢。”对于问题的我们很难看到本质，不过，如果我们想解决问题，就必须试图先去了解问题。

这是《人月神话》中的一段话，我从网上找到的，估计那个项目经理很遗憾没有看到这句话。

风水轮流转呀。真不小心，新一轮领导换届，新领导上台。这个项目又被作为领导新政提了出来。（注意，不是政府换届，而是企业领导换届。我从来没有做过政府的单子）

这回，项目主导方变成了我们。我成了项目经理。但是，除了这位新领导，过去的那帮人还是那帮人，我仍然要解决这帮人。（我的一位助手笑称这帮人是成 事不足败事有余。上一次我是挂名，他是真正参加了上一次的项目每一次开会。这次，我找他做助手，希望他的上一次经验能给我提供帮助）

我这次没有像我的助手上次项目一样，让计算机室帮忙到业务部门要这信息那表格。

我首先向计算机室要了一份全企业的部门组织结构图。我先看看这个盘子到底多大。我曾经刚出道的时候就遇到一次滑铁卢，半路地杀出来一个部门领导竟然严重影响了项目走向。

这次，我把全体部门都纳入思考范围内，了解我这个项目和各个部门的关系。最后我按项目关系紧密程度把客户各个部门排了一张表，每个部门的负责人的名 字，联系电话我都要到，每个负责人的年龄，每个负责人的性格，我通过晚上请计算机室没有结婚的小伙吃羊肉串了解了个一清二楚，谁说话算话，谁比较和事佬， 谁比较见风倒，谁和谁不对付。想问问他们大老板是怎么看这个项目的，想达到什么目标，他说他也不清楚。

我先去亲自找最容易配合我的那个部门（我并没有采用聚众开座谈会的形式，而是单个击破法）。但他不是和我这个项目关联最紧密的部门。但他最容易突破。

他和我发了一下午的闷气，有对企业现状的灰心与不满，有对理想做法的想象，希望我能在这次项目中把他的想法全部实现了。

不过这次聊天我也受益匪浅，对这个企业的各种来龙去脉了解了许多，使我在以后的小心翼翼项目推进中避免了很多人为的障碍。

但这不是我这次找他谈的真正目的。他絮叨了一下午，我临走时才说出了我的目的：我需要把他这个部门的报表和单据收集回去。

他很配合，把他的得力干将叫了过来准备安排，我说别了，我跟着他去自己收集，这样我对您的需求也理解的更深更直观一些。

于是，我跟着他的得力干将，一位36-37岁的中年女士一一到每个重要的人的桌边，我和每个人都讲明了我的来意，他们将他们手头的报表和单据全都拿 给了我。有EXCEL的，有WORD的，有每月PPT述职报告，有纸张的，有电脑软件上的报表都打印出来，有电脑软件上的数据输入，我就帮他们COPY屏 幕打印放到我的U盘上。

我一个人一个人的边收集边问，通过他们给我的表格，我就大致知道了他们的工作岗位内容。

然后，我问：哪些表格是你最常用的。

于是，那个人就帮我挑出了好几张。

然后，我依次把最常用的，次常用的，偶尔用的报表都分了类。

我又提出了问题：哪些报表影响你的考核和奖金工资福利之类？

他又帮我挑出来一些。

我又对着他挑出来的影响他的考核的报表，拿起每一张问他：在这张报表中，你最关注哪几个指标？

他一一指出来。我顺着他的指，边和他交流这些指标的关联关系。

然后我拿着这些指标问他，这些指标是怎么的数据是怎么得来的。

他就帮我从这一堆的电子的、纸张的单据中找了出来，并且解释怎么输入的。

然后我对着每一个单据都问他这个单据的使用频率，是每天、每周、每月、每季还是每半年、每年。是每天（周、月、季、半年、年）的期初做、期末做、还是平时做？哪个频率高？高到什么程度？

这样，我就明白了每个人主要真正做哪些事，怎么做，最后怎么考核，哪些事最重要，哪些事每天做，哪些事频率最高。

常用的功能，重要的功能，性能压力大的功能，稳定性要求高的功能、数据精确要求高功能，易操作性要求高的的功能，就是从这些提问回答中自然浮现出来的。

我的那个助手用笔在笔记本上不断记录，手累的最后回来都说手写的都抽筋，告诉我下次不要这么快，让他好记录全一些。还给我看，为了记得快，字都写的有些现在不认识了，还得靠回忆，整理起来特费劲。我说，行，行，我一定注意。

我们回到宾馆后，先制作了一份草稿，粗略的列出来这个部门的组织结构、人员岗位角色说明、业务流程图、考核报表。第二天，然后针对这次项目，把这次项目相关的详细描述出来，并且把核心业务流程和非核心业务流程分开。

第三天上午，我们又去了那个部门，针对每个报表间的钩稽关系，每张单据录入的每一项录入要求、默认值、必填项、唯一约束、录入校验、单据状态、可选值都做了详细调研。

在交谈中，我们又发现了一些流程，这些流程都是些特殊处理流程。我们也发现了一些异常的操作，是发生特殊业务时候的土处理，我们都如实记录了下来。 有时候，你专门问他异常流程的时候，他反而回答不出来。大部分人没有系统性思维，都是以事论事，讲到哪里想到哪里。所以发现异常流程，发现新流程，全靠调 研人自己细心发现和甄别。可能，他无意的一句话，你直追着下去就会发现他日常处理的空白和漏洞和矛盾的地方。

第三天下午，我们继续工作，单个人访谈，把每个人工作中认为最想解决的问题都提出来，但只能说5个，能想到哪些就说哪些，我们一一记录。

第四天，我们把我们过去画好的组织结构、人员岗位角色说明、业务流程图，经过昨天的调研，又修改补充了一些，在整理的时候，我们用红圈标好了业务处 理漏洞和矛盾的地方，并且对这些地方都提出了改进建议。把他们每个人认为最想解决的问题都考虑进流程和业务单据报表中，建议增加什么流程、建议增加什么单 据、建议增加什么报表，谁来做，怎么做，谁来监督，怎么考核。

一份优化好的流程展现出来了。

第五天，我们又去了客户那里。这次，我们组织了部门座谈会。我们给他们整个部门都讲解了我们梳理过的流程现状，给他们说明漏洞和矛盾，给他们说明我们提出的方案。

座谈会非常顺利，全在我们的意料掌控之中。他们非常惊讶我们能在短期内画出这么专业的流程图，其理解透彻度比他们自己还要清楚。而且对他们问题的把 握准确，对他们问题的解决思路之巧妙，都不禁赞叹我们。每个人的疑问和建议都融入了我们的流程改进思考之中。客户部门给与了我们很高的评价。

接下来，我并没有把这种方法扩展到其他客户业务部门的调研。而是我把这份调查报告又给了他们大老板演示了一次。他们的大老板从来没见过这样专业的调 研，赶快召集各部门头头都来开会，乐的喜笑颜开， 大赞这钱花的值，他们只想到上套软件，没想到上软件讲究这么大，他们自己都没有如此明晰专业的流程图。他们的大老板赶快让我给他也COPY一份，如获珍 宝。

有了大老板的肯定，我做一个部门的调研，就给他们的大老板发一个报告邮件。邮件抄送给调研的业务部门负责人。

我所有的调研一帆风顺，各个部门配合极好。上一次项目的扯皮推搡都不见了。

我的助手说：你这个人有点邪门。

我一笑。