项目管理：四套马车--团队配合

在写这本书的过程中我和大量的网友进行了多方的交流探讨，发现大家所在的软件团队都存在着这样一种普遍现象：

大部分网友所在的公司，开发人员仅3~5人，多的在10人左右。别看就这几条枪，还从售前支持、软件开发、测试、打包发布、文档编写，到实施安装、培训、技术支持都做。

这还不算什么，而且几乎是一个人负责一个产品或一个项目，一个人从头跟到尾，而且负责多个客户的维护工作。

这还不算什么，而且随时老板会找来八竿子打不着的新活，要得还挺紧，突然要开发，打乱了所有的计划，最后都懒得按计划行事，每天撞钟，老板有事就吩咐，没事就上网，还不让听歌，当然更不让打游戏。甚至还不让看技术书籍，呵斥不干工作。只能上网装作在工作。

老板和员工互相斗智斗勇，在年终奖、报销、出差、平时福利上啊，都明争暗斗。老板卡的紧，员工就在项目和产品上下药，还不知道是谁占了谁便宜，谁给谁打了工。

员工一边在刻苦钻研各种开发工具，阅读源代码，学习做Demo例子，阅读UML、设计模式、单元测试、敏捷编程等，一边却懒得修改现在公司的产品，有问题就打补丁，客户不嚷嚷就懒得修改，代码不优化，界面不友好，架构没架构，封装不封装……

但是，在讨论中，我时时都强烈感觉到，大家是想把产品开发好，把开发过程管理得井井有条，但是都心有余而力不足。阅读了N多软件工程的书籍，从重型方法到轻型方法都阅读了，但都无法把现在的开发状态一点点扭转好。

许多人想闹革命，把现在的这些产品和团队都砸塌，然后重新来过，但这只是梦想，说说而已。不然只能希冀下一次跳槽，能找到一个好的公司，把自己平生所学全部发挥出来，但这好像也只是梦想，因为交流了一下，大家彼此的境况基本相同。

一些极端主义者自己开了公司，才发现不持家不知道油盐贵，现在自己和手下变成了老板和员工的关系，照样走了过去的老路。

更有一些极端主义者辞职，自己做软件，最后由于生活拮据或做做后发现这个软件没什么意义，就丢弃了自己的梦想，随便找一家公司开始沉默撞钟。

一些聪明的家伙，有的到了外企，有的进了大的网游公司，有的进了外包公司，有的进了大网站公司，都是讲究大规模开发的公司，希望能找到一条中国式团队开发产品保障之路。

兄弟，作为小软件公司，我们真的无能为力了么？我们真的只能成为炮灰么？

但是，中国软件行业内大部分都是这样的公司。从每年CSDN的程序员调查都可以看到，中国软件公司大部分都保持在这种开发团队规模，开发人员大部分都是毕业1~3年的学生。

我们是在等待时间让团队变得成熟么？我们是在等待时间让团队变得综合实力增强么？

依我看，作为中国软件群体最大组成部分的小软件公司，需要的不是UML/RUP/CMM这些重型方法，不是前几年大家关注的小组开发方法，也不是敏捷编程这样的结对方法，我们都无法有这样的资源实现这样的方法。

但是，想想看，星星之火可以燎原。红军能从爬雪山过草地起家，最后解放全中国。我们就真的找不到方法？

也许我们需要想，就我们目前能拥有的权力和资源，我们如何一点点改进。我们需要的是从游击队到兄弟连，从兄弟连到正规军的方法。我们现在还是游击队，一个队长领了一帮游兵散勇，有的人甚至没有枪还背着大刀，有的人还没杀过鬼子。

首先，得把我们这伙游击队变成兄弟连。

我常常观看国际著名的CS战队的比赛录像，他们配合得多好啊。如果他们都单兵作战，那么早就死翘翘了。这和咱们的软件开发多么相像。我们多么向往这种默契的配合，打得多么流畅。我们要的就是这个。他们不也就几个人么？

让我们来分析分析吧。

我们想好好地专心开发软件，但我们的时间都被实施安装、培训、技术支持占去了，怎么能把这些开发以外的东西剥离掉呢？

现在得问问：为什么我们的时间都被实施安装、培训、技术支持占去了呢？

很简单，因为我们根本没有需求记录工具，哪家客户提的需求，当时为什么提，是为了解决什么问题，都没有记录下来。可能是客户的一个电话，可能是老板的一个电话，也可能是实施部门的一个实施工作报告中提到了。程序员看到了，觉得能改，就改掉了。当然，没有专门分配任务的人管理进度和分配任务，也没有专门负责设计的人员先做设计，程序员自己就改掉了。

一个改变了的功能，却没有帮助说明文档。为什么？因为没有文档人员。一个改变了的功能到底好不好使用，改动出了问题没有，不知道。因为没有测试人员。

程序员就是自我管理自己的任务、自己的进度、自己的质量，如果非要有人逼着提交文档，程序员还得自己写设计文档和帮助文档。软件因为没有说明文档，也没有专门培训的人，实施人员、服务支持人员、销售人员谁也不会用，只能程序员自己去实施，有了问题自己去接客服电话。再说了，软件不稳定，其他部门的人都拒绝实施，谁想让客户劈头盖脸地骂啊。软件不稳定，老出问题，客服人员还不知道怎么解决，烦得要死，客服工资还低，推责任也得把问题推给开发部，只能程序员去做技术支持。这么多压力都给了程序员，还需求不断，Bug不断，程序员也没有时间修改，客户抱怨，老板抱怨，实施人员抱怨，服务支持人员抱怨，销售人员抱怨，程序员简直没法活了。

怎么能把这个“结”解开呢？

首先得要有帮助说明文档，让实施部门的人会使用软件了，这样程序员就不用自己亲自出差做实施、培训了。这样就有时间能修改Bug和需求了。只要Bug减少，实施人员就没有理由拒绝实施。不会？不会，有帮助说明啊。还不会？我们从开发部派一个专门的人给你们天天培训啊，不怕你们学不会。这下没理由不实施了吧。

Bug能减少吗？软件这个东西有个怪圈，往往是修改100个老Bug，就会出现20个新Bug，这哪天才是个头啊。看来必须要请一个专门的测试人员来测试，才能快速地减少Bug，保证软件达到可实施的要求。

但是测试人员怎么知道这是个Bug呢？什么算正常的，什么算不正常的，谁知道？有没有个评测的标准呢？看来必须要请一个专门的设计人员把软件的正确流程和正确数据状态都详细写下来，这样才能判断是不是Bug。

看看我们这几个程序员，有半路出家自学的，有吊儿郎当踢一下才动一下的，有说了三遍也不明白的，就这么些程序员，就是让他们专心开发编码，也未必能让软件稳定下来。看来还须要增加一个牛人，让他写核心代码和公共代码，其他人只管调用函数，实现客户UI操作和辅助功能。这种技术牛水平高的人能保证产品整体质量，其他水平参次不齐的人少写代码或写辅助代码，即使有了问题也影响不大。开发领域我们有句常话叫做：“代码越少越稳定”，说的就是这个道理。

在程序员修改代码的过程中，如果有服务人员又把电话转给程序员怎么办？这不程序员又没有时间完善软件了么？谁能把这一工作分担下来呢？ 

从以上分析来看，我们需要这样几个人：

编写帮助文档的人；

搞内部培训的人；

测试员；

软件设计文档编写人员；

核心代码和公共代码编写人员；

比服务部更懂软件的支持人员。

测试人员可以兼任支持，帮助文档编写人员可以兼任内部培训。反正测试人员天天和程序员待在一起，又在天天测试软件的各个功能，肯定做支持很牛。再说了，测试人员兼任支持后，还可以倾听到第一线客户的实际操作反馈，就更能知道该怎么测试了，这是一举两得的事情。让帮助编写人员兼任内部支持，反正帮助文档是他自己写的，到底实施人员能不能看懂，自己的文档写的实用不实用，自己一讲就明白了，这个兼任也对编写文档很有好处。

有网友又说了：这样梦幻的团队，是可遇不可求的。现实中，就连最基本的程序员，找个合格的也不容易——聪明伶俐的养不住，经验丰富的养不起，迟钝呆傻的没法要，碰上心术不正的还够你喝一壶的！

其实，我们的研发团队也不怎么大，我们公司本身也是一个很典型的中小企业。我们也和大多数的软件公司一样，既有定制项目，也有产品开发。

一般，一个产品或一个项目，由一名业务开发组组长、一名主程、一名辅程组成。如果项目简单，基本就是由一名业务开发组组长和一名主程构成，业务开发组组长和主程都要写代码。如果项目比较中型一些，就需要组长、主程、辅程三个人了。业务开发组组长负责设计、任务分配、任务调度、人员调度、质量控制、进度控制。主程和辅程就专门开发代码。业务开发组组长和项目经理差不多。有的项目经理偏向于开发经理，有的项目经理偏向于售前经理，有的项目经理偏向于纯粹的项目组织、协调、报告。

有几个产品，就会有几个这样配对的开发团队。而一个中小软件公司，往往同时开展的也就是3～4个项目，2～3个产品。这样算来，一个这样开发规模的团队，也就是10个开发人员。这样的开发人员数量，在中国软件开发行当，算是很常见的人数。当然，有些网友说他们公司就两个开发人员，这类更小的作坊还提不到团队的层次。组织组织，三人以上才能称得上组织。

通常，研发部会有一到两名项目经理。

我们公司老承接一些大的合作开发集成项目，经常需要有人去客户现场和其他合作伙伴一起开会、讨论、提交方案、工作量报告、工作进度报告。总需要有人去跑这些项目协调会。

另外，销售打单的时候，客户总会提出一些技术性的问题或某个需求能不能做的疑问，销售也模棱两可，不知道是能做还是不能做，于是总会拉上一名项目经理。有关产品的、技术的、开发周期、工作量估算、项目团队组成的内容由研发部的项目经理来写，关于价格和商务条件上的由销售来写。在打单过程中须要讲解产品或回答客户产品疑问，都让这名项目经理来兼任售前支持。

对于项目型的，项目经理有时还担任需求调研经理，使用需求调研方法产出需求说明书。不过，有时业务开发组长也做，主要看业务开发组长在客户面前的沟通能力。因为业务开发组长是开发人员出身，但技术一般，业务知识很熟，管理能力差不多够管理1~2人，工作年限长一些，工作经验也多一些，但有些人比较内向，不善于与客户调研沟通，就不适合做需求调研。所以谁来做，得看具体人。不过按职责来看，项目经理和业务开发组组长都要能做需求调研。

然后就是公共代码开发人员，一般就一个人。对于企业管理软件的开发，框架的开发和维护，公共代码的开发，高难度的问题跟踪，需要高性能的设计，需要高扩展性的设计，需要高稳定性的代码，需要高安全的代码，需要高并发的操作，需要复杂代码重构。需要性能优化，不知道的技术API，都可以寻求这位公共代码开发人员的帮助。

他还负责新技术跟踪、新技术介绍、新技术试验。但这个新技术必须是用于改进公司现有产品和对现有客户的服务。新技术的跟踪必须上报给技术总监，以防不符合公司目标盲目跟踪或跟踪方法和思路不对。对有利于现有开发的新技术，可以筹备好培训课，由研发部经理安排时间，让公共代码人员给研发部全体人员讲解。如果大家认可这种方法，就会选择适当的时机在产品中引入。

研发部的测试人员，一般也兼任配置人员，产品打包、产品安装测试、产品发布、版本分支管理、源代码备份、历史版本归档方面都由他来管理。

研发部的测试人员，还兼任着服务部门对口的技术支持人员。如果有服务部门解决不了的技术问题，可以转给研发部的他。因为测试人员整天和开发人员在一起，还天天测试程序，所以他对软件的了解比服务部门的小姑娘深入得多，所以服务部门解决不了的问题，找他准没错。如果不设这个兼职，服务部门有问题搞不定，肯定会直接找开发人员，这就打乱了开发进程了。

而且兼职是有很多好处的。如果他不兼任技术支持，他就不了解客户是怎么使用的，测试也是瞎测试。测试做的时间长了，就有思维定势，往往就脱离了普通用户的思考方式。这样，普通用户容易出现的操作问题，他却测试不出来。所以让测试人员兼任技术支持，可以使他经常保持对直接用户的真切感觉。

当研发部没有人专管产品打包发布的时候，程序员只能自己发布版本。但程序员关注的是技术和编码，对于版本控制就不太敏感。打了一个包，觉得改动也不大，现在客户急着要修补某个Bug，就赶快修改完打包一个。但版本号却不改变，导致一个版本号代码不同错误不同，让服务人员支持起来很莫名其妙。

由测试人员控制产品版本发布，能不能发布，就是测试员说了算。测试员感觉质量没有达到，就有权不发布。在很多软件作坊，程序员权力很大，一个老哥从头到尾负责整个项目，项目质量如何，全看这位老哥自己的素质和责任心了。为了不让项目质量和特定人密切相关，使公司研发保持连贯性水准，必须做到专业分工，互相配合互相牵制。

一般，研发部也就配1~2名测试人员，根据同时并行的项目及产品开发和开发的强度来定。我们并不要求产品质量马上达到国际一流水准。我们做行业企业管理软件开发，是在客户质量要求、客户签单额、竞争对手质量水准这三者的博弈上做到一个质量的平衡。我们无法像微软那样开发与测试人员的比例达到1:1。研发部所有的产品和项目，都由这几名测试人员负责所有的测试工作，包括编写测试案例，编写测试结果，参与项目的需求测试、设计测试。

研发部的文档正规化，由文案人员来负责。项目经理经常要提交给客户一些文档，而项目经理往往是技术出身，文档工作水平不行，于是文档的正规化、美化、文字校对、空格段落措辞标点符号，都由文案人员制作。帮助文档也由文案负责，这些文档包括有版本更新说明帮助、安全配置帮助、系统维护管理帮助、基础数据配置与维护帮助、业务功能操作帮助、软件操作演示视频、产品简介PPT、产品演示版，都由文案人员来做。为了防止文案人员不懂产品而写产品帮助，需求说明书、设计说明书这些文档性的工作也由文案人员来做。文案人员还兼任产品辅助测试，主要是作为一个普通的操作者来测试，在制作演示版的过程中模拟客户流程客户数据来进行操作录入，测试出普通使用中的Bug。一般，一个专业的测试人员，经常呆在软件的环境中，思维就会有一种定势，但实际的用户并不那样操作，但测试人员自身感不到。而文案人员就能充当普通用户来进行测试。我们招聘文案人员时也没有强调会什么软件，文案写得好就OK。他们确实是最普通的用户，他们的困惑和操作手法能代表大量的普通用户。而一个研发部，文案人员也往往是1~2名，随并行的项目数量和规模来定。

所以说，一个研发部，一名研发部经理，1~2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案，也就是5~6人，完全符合一个软件作坊的人员数量。有时候团队小了，研发部经理就是项目经理，公共代码开发人员就是主程，这样，一个开发团队也就是3~4人就OK了。但方法照样能用起来。因为我所讲的方法也就是适应于这四套马车的组织架构。每个人都身兼数职，而且都对自身的提高非常有好处，而不是给他身上堆砌毫不关联的工作内容。每一项职责都能互相互补，整体提高他的岗位专业性。

作为业务开发组组长，他很大的一个职责就是功能设计、开发任务安排、调度和产品质量管理。

业务开发组组长在功能设计方面详细负责功能点清单整理、功能优先级划分、详细功能说明书编写。

首先，业务开发组组长会从需求管理系统、Bug管理系统中复查需求与Bug，决定本开发周期内哪些需求和Bug将要被完善。

业务开发组组长会对筛选出来的需求与Bug都标示好功能的重要性优先级。

在业务开发组组长划分完功能优先级以后，如果某个功能复杂，就会再被拆分粒度，直到复杂度都差不多均匀。业务开发组组长就能预估出一个大概的项目开发周期。根据以往的团队经验，也能预估出给集中测试的时间和给集中文档测试打包发布的时间。这样，整个软件什么时候能最终做出来，业务开发组组长是有个预估的。如果一个团队是新组建的，每个人的能力还不清楚，预估就会有偏差，需要磨合才能得到经验值。如何磨合，我也会在以后讲到。

在实际分配开发人员的时候，就是根据这个总目标完成时间来倒推时间的。倒推出来的，有每个功能的完成时间周期，而项目经理对于某个特定的开发人员的能力预估也有一个时间，而开发人员自己对完成这个功能也有一个预估时间。开发人员怕完不成任务被追究，往往会把完成时间往后放1/3，甚至有人想偷懒干自己的活，会更多出自己预估时间的一倍，也就是说，自己觉得3天能完成，就说6天才能搞定。当然，业务开发组组长也不是吃素的。业务开发组组长也是做开发出身的，到底难度有多大心里有数。而且业务功能就是业务开发组组长设计的，如何实现，会遇到什么难点，自己一清二楚。而且天天管这帮开发人员，谁能力高谁能力低，谁想偷懒，天天在一个办公室，谁不知道谁呀。所以，每个任务所需的时间，都会是业务开发组长在开发人员自己预估的时间基础之上进行调整，获得一个开发人员和业务开发组组长都能接受的任务时间段。然后根据每天的进度报告来随时调整这个时间，让开发进度尽量都能现实，而不是计划定好了就不能改。

对于保证项目进度，还必须有一个条件，这就是：不允许开发人员在客户现场开发，更不允许开发人员和业务开发组组长不在一起。

开发人员在客户现场，往往开发进度和功能需求变更容易受客户控制，致使开发团队做的计划和设计都被客户视为扯淡的东西。开发人员不满客户的做法，但在现场又没有办法，只好敷衍，权且应付。本来是一个理性的设计，却被客户自以为是的好做法推翻。软件的什么扩展性啊、兼容性啊，都被扔在了一边。来客户现场，就要听这个特定客户的，你必须口对口服务这个特定客户，你如果和他讲其他客户怎么办，他才不管呢，反正他付了你的钱，在你眼中他必须是你唯一的客户。

另外，开发人员在客户现场开发，就无法实现每日构建每日测试。开发，是个团队配合的事情。一个软件，并不是只有开发人员就能全部完成的（许多老板都误认为有开发人员就行）。缺少了测试，质量就无法保证；缺少了文档，产品就是光秃秃的软件。而许多老板还以为测试和文档可以在代码编写完后做，真是对软件质量如何保证一无所知。

我们不允许开发人员和业务开发组长分离。因为在开发当中，设计文档不是代码，机器运行完就只有一种结果。每个业务开发组长的文档水平有高低，每个人的思路也不同。我们经常会遇到一个现象，就是用邮件、MSN沟通老出误会，而且若不及时调整，误会就越来越大，后来干脆气愤地直接打电话。而打电话呢，有时还不行，你问他理解了么，他说理解了，你根本看不到他的表情，你猜测不到他是真理解了还是假理解了。你以为他理解正确了，他也以为自己理解正确了。你问他进度，他说没有问题。开发出来了，测试人员又有自己的理解，到底这三者理解的是不是一个东西，谁都没个准。只有业务开发组组长和团队工作在一起，每天能看到实际的软件，能面对面和每个人交流反馈，才不至于代码开发完毕一看：不行！有许多刚当上业务开发组组长的朋友，往往和手下搞得很僵硬。手下认为他一天三变，频繁推翻自己的代码，很气愤。而业务开发组组长认为手下的理解能力低，多次讲都讲不清楚，还跟自己顶嘴，还不如自己去开发代码省事。完了，又回到程序员的思路上了。

我也不允许开发团队出现多种技术。多种技术，会让团队成本升高，每个人都得会多种技术。而我们做企业管理软件，要想赚钱，必须实行大规模低成本开发，这是我和老板都认同的一种思路。所以，我们必须使用最常用最普通的技术，除非没有办法。我曾经有一个手下，怕自己跳槽没有竞争力，于是老学习流行技术。PHP火的时候，他就学PHP；Ruby火的时候，他就学Ruby。如今网游和嵌入、通信、无线很火，他就开始学C。手机开发火的时候就学J2ME。而且他还想有实际的开发经验，以在应聘中说自己拿这门技术做过什么。于是他想尽办法在项目中引入这些技术。说：用.net，我没法保证性能和稳定性，所以我必须使用VC++。唬谁呢？大家都是搞开发出身的，这个借口未免太可笑。

我也不允许团队使用最新技术。我们只使用最合适的技术。我们不让客户为不需要的新技术而买单。客户的水平只能管理SQL Server这样的数据库，我们就绝不使用Oracle。如果客户要求在Unix上运行，我们就使用JAVA开发。我们谨慎地评价和引入框架，核心都在围绕着客户能不能进行简单维护，我们有没有显著好处，我们面临的最棘手的问题能不能得到很好的解决。如果只能解决我们不怎么紧急的问题，如果只能解决我们通过人工或管理就能解决的问题，这样的技术我们就不引入。一切的一切，都在围绕速度、成本、质量寻找解决方法。

根据功能列表清单、功能优先级、详细设计说明书，业务开发组组长就会按照自己团队当前每个人的工作量来适当分配任务，调度任务。根据这个任务列表统计分析哪些任务超期了，哪些任务完工了，哪些任务还没有开工，哪些任务正在进行当中，来判别开发人员的开发进度和工作量。

每天下午5点，业务开发组组长都要询问一下自己手下的开发进展。因为有的人不喜欢主动说自己遇到了什么问题，总喜欢自己去到处找答案，延误了正常的开发计划。所以，开发组长必须每天下午5点主动问遇到了什么问题，是不是很棘手，能不能保证进度。如果不能保证，业务开发组组长就会想办法，是全小组一起诊断出谋划策，还是寻求公共代码开发员，还是寻求研发部经理。为什么是下午5点？主要因为5:30~6:00就下班了。如果快下班了你才去问，大家心思早就不在这里了，谁都想赶快下班回家，问题就被隔了一夜，留了个不清楚的尾巴。如果在5点钟询问，有了问题，如果此问题业务开发组组长有经历，他会很快决定该怎么解决。如果详细听完了此问题的来龙去脉，业务开发组长也无法决定，但他已经弄清楚了问题所在，会在晚上思考，第二天来一上班就有了决定。这就叫做一点都不耽误。

业务开发组组长会每日主动向研发部经理报告进度，并且简要说明一下现有问题和解决思路。进度列表中标明今日关闭的任务，以及还没有关闭的任务。这样，研发部经理会思考：项目已经开始了这么多天，还有这么多任务没有完成，到期能不能完成，他就会思考是不是要做些调整。

有网友问到：“你们都用到了什么设计工具和管理工具？”比如，问我现在的团队使用什么UML工具、什么压力测试工具、什么数据库设计工具、什么版本管理工具、什么需求管理工具、什么进度管理工具、什么Bug管理工具。许多人觉得一个正规的开发团队应该使用如Rose、Together、LoadRunner、PowerDesigner、VSS、CVS、SVN、ClearRequest等等。

在他们眼里可能觉得一个团队，只要用上先进的工具就会成为一支装备了机关枪的军队。就跟我们客户的想法一样，以为只要上了这套ERP软件，自己的管理就上了一个台阶，盈利就会提升。这个想法真是奇怪，就如同一个人拿了一把屠龙刀，人没砍到，倒是把自己砍伤了。一把好厨子的刀，到了不会做菜的人手里，仍然做不出好菜，就这么浅显的道理，但大家还是要去幻想工具的力量。

我们团队人也不多，而且一人兼任了多个角色，实在没有更多时间折腾这些大块头的工具。UML工具、数据库设计工具，需求管理工具，能上的都上，最后也没解决问题，倒把自己和自己的团队累的半死。

我在设计方面使用了PPT+WORD+脑图+Excel的描述方法。

因为很多需求都是这个支那个叉出来的。程序员往往想了这头想不了那头。这就是人的思考的周密性差异。

想让人能从千丝万缕中理出头绪，于是脑图软件上场。把各个分支来龙去脉表现清楚。

到了描述某个节点的时候，PPT上手。一页PPT相当于一个界面窗口。每页PPT的图形模仿了菜单、输入框、按钮。按钮按下，还可以跳转到其他的PPT页上，和软件操作流程非常相似。

PPT让程序员很直观地看到未来软件做出来是什么样子。关于PPT的详细描述，如字段、流程、特殊注意事项、特殊控制事项，都用WORD说明为好。

遇到有报表功能的时候，用Excel把报表画出来，让程序员喜闻乐见。

这样，由表及里，从概要到详细，从分支到关联，都表述OK。客户也能明白，程序员也能明白，实施人员也能明白，老板也能明白——这一点非常重要。虽然老板不懂软件，但他要干涉软件，他如果不明白，他就不知道这帮家伙到底在干嘛，是在真正干活还是在偷懒，到底工作量是大是小，软件功能是复杂还是简单。老板如果不明白，他在给予资源和时间上就会很谨慎，会处处设防。这是许多项目经理都忽略了的大事。还拿UML做秀，谁也看不懂，谁也用不了，白花费时间画那些好看的图。这就是中国的现状，我们站哪个山头就唱哪个山头的歌，有效解决问题提高销售收入才是我们的根本任务，我们得不抱怨不幻想踏实地推进，解决问题。

老板明白了，天平就开始向开发部倾斜了。资源，当然也就容易申请了。

画这些Excel+PPT+脑图+WORD，当然很费时间，直到引进了日本外包开发过程管理后我才发现，我们的解决方法和强调质量的日本人的做法非常相似。于是，我申请了一个名额，把过去做实施的一个项目经理（他居然还会写点SQL，从数据库查数据，调整个报表。实在太强了）调入开发部，专门编写这些文件。

开发部开始蒸蒸日上。项目经理、开发人员、测试兼技术支持已经到位。工具也已用的不亦乐乎，深入到了公司的每个部门。每个部门都按照标准描述方法和标准流程走。现在，连实施人员都会画Excel报表格式、PPT界面。

此外，我们还使用了需求管理工具来管理来自各个方面的需求；使用了Bug管理工具管理需求；使用了任务管理工具管理任务。

这样来看，我们程序员每天在干嘛？就是在满足客户需求和修改Bug。而这些内容就是程序员的每日工作任务。所以，我们用了一套Bug管理软件，然后分别安装了3个目录，分别用于管理需求、Bug、任务。

在数据库设计方面，我们并没有使用PowerDesigner之类的工具。因为我们在设计理念上不推崇使用外键关联，而且我们有自己的业务实体设计器，所以对于数据表的描述和关系，我们都用自己开发的业务实体设计器的数据表做了存储。

我们也没有那么多人力和时间，编写完详细功能说明书、数据流操作说明书还有精力定义代码接口、参数、类，画什么时序图。所以我们只用WORD编写了详细功能说明书、数据流操作说明书而已，用版本管理工具把文档管理起来。Rose之类的就没有使用。

在版本控制方面，我们使用了版本控制工具来控制设计文档和源代码的版本。

我们还使用了自动每日构建工具，每天晚上整体编译。

在测试方面，我们的测试人手也不足，1~2个测试人员需要测试开发部所有的产品和项目，他们又要做测试案例，又要重现错误，又要做测试报告，还要兼任技术支持。过去也尝试用过自动化测试工具，但编写自动化脚本就费了不少劲，还不如自己手工测试来得爽，就没怎么用起来。但我相信，自动化测试工具要正常用起来是非常好的工具。已经用了自动每日构建工具，不用自动测试，就太浪费晚上的时间了。以后找机会还得把这个工具推行起来。

不过，我们倒是使用了一些压力测试工具，模拟同时并发访问，同时插入数据，同时取数，模拟网速限制。有时候找不到乘手的压力测试工具，就自己写一个小功能，如模拟断线异常，模拟线程争抢。

还有Setup打包安装工具，相信这个工具大家都在使用，现在很多打包工具都能写一些安装脚本，我就不赘述了。

我们还自己写了一个版本自动更新工具，当监测到客户端版本不一致的时候，会自动与服务器同步。而服务器端也会监测是否可以连上互联网，如果可以，就会自动检测和我们的FTP更新服务器上的版本是否一致，如果不一致，就会自动更新服务器端。过去我们没有这个工具的时候，往往客户那里出的问题就是由于老版本的某个漏洞没有修复造成异常，而版本却无法自动升级。现在有了这个工具后，全国的客户，只要有新版本发布，都会自动更新，无须人工干涉，许多问题，很多用户都还不知道就已经修复了，提高了我们的客户满意度。

有网友曾问过我：你们是怎么把工具使用起来的，我们这里想用但怎么也推动不起来，大家还是习惯一个IDE搞定。

我说：没有动力谁干啊。我决定推行的第一个工具是Bug管理、需求管理、任务管理工具。但推行的目的可能和大家想的不太一样。软件是有Bug，但老板不太在乎这个，因为有单子签，质量也过得去，款项能结回来，其他的老板不会在意的。各个部门都能提需求，销售提的、老板提的、实施提的、服务提的，散落在各处没有个地方汇总，但老板时不时就会问起修改得怎么样了，为什么还没修改好，啥时候软件能修改完。老板不知道研发部这些家伙到底在干吗，在捣腾什么，是不是在欺负他不懂编程糊弄他，研发过去也拿不出什么有根有据的文档来向他说明，所以他对于研发团队一直不信任，疑神疑鬼，也不给涨工资。本来，做软件就不是他心中所想，只不过由于阴差阳错就进入了软件圈子（生存期碰上单子就得做）。所以我上工具是为了能明确报告研发部到底做了些什么，到底做的程度如何，希望他能放心，希望他能看到研发人员的工作辛苦和努力，希望他能在涨薪水的时候心中有数。没有驱动力的事情我们从来不干。

 

附录 《狼的智慧》特怀曼·L·托尔利

笔者注：近几年，狼性文化被人们误读了不少，所以希望与大家分享这篇文章。

狼的十大处世哲学

卧薪尝胆

狼不会为了所谓的尊严在自己弱小时攻击比自己强大的东西。

众狼一心

狼如果不得不面对比自己强大的东西，必群而攻之。

自知之明

狼也很想当兽王，但狼知道自己是狼不是老虎。

顺水行舟

狼知道如何用最小的代价，换取最大的回报。

同进同退

狼虽然通常独自活动，但狼却是最团结的动物，你不会发现有哪只狼在同伴受伤时独自逃走。

表里如一

狼也很想当一个善良的动物，但狼也知道自己的胃只能消化肉，所以狼唯一能做的只有干干净净地吃掉每次的猎物，而某些自认为是善良的动物却总在酒店饭庄里做一些不是“太善良”的事。

知己知彼

狼尊重每个对手，狼在每次攻击前都会去了解对手，而不会轻视它，所以狼一生的攻击很少失误。

狼亦钟情

公狼会在母狼怀孕后，一直保护母狼，直到小狼有独立能力。而不像某些自诩为“唯一有感情”的动物，在妻子怀孕后，在外花天酒地。所以狼很不满人把那些不钟情的人称之为狼心狗肺！因为这不公平！！

授狼以渔

狼会在小狼有独立能力的时候坚决离开它，因为狼知道，如果当不成狼，就只能当羊了。

自由可贵

狼不会为了嗟来之食而不顾尊严地向主人摇头晃尾。因为狼知道，绝不可有傲气，但不可无傲骨，所以狼有时也会独自哼哼自由歌。

狼之团队精神

多么壮丽的场面！广阔无垠的旷野上，一群狼踏着积雪寻找猎物。它们最常用的一种行进方法是单列行进，一匹挨一匹。领头狼的体力消耗最大。作为开路先锋，他在松软的雪地上率先冲开一条小路，以便让后边的狼保存体力。领头狼累了时，便会让到一边，让紧跟在身后的那匹狼接替它的位置。这样它就可以跟在队尾，轻松一下，养精蓄锐，迎接新的挑战。

在夜里，没有哪一种声音比狼群异乎寻常的音乐般的嚎叫更阴森、凄楚、可怕而又动听的了。狼嚎的原因也许是为打破一切等级界线提供时间、场合和机会。狼群的社会秩序非常牢固，每个成员都明白自己的作用和地位。我们观察狼群进食时，能看到类似屈膝行礼、鞠躬、哀叫和拥抱的声音和动作——一切都依每个成员在狼群中的地位而定。但是当狼在一起嚎叫时，一切等级界线都消失了，它们仿佛在宣告：“我们是一个整体，但是个个都与众不同，所以最好不要惹我们。”任何听过狼群奇妙的合唱的人都会证明，它们的这种信息表达得十分清楚。

人类的组织和家庭更是如此，如果其中的每个个体个性不是被扼杀而是被大加赞扬，那么它就更令人敬畏。每位成员都应通过发挥特有的才智和力量来肩负起对团体应尽的义务。通过表现个体的独特性及尊重、鼓励其他成员表现自我，整个集体定会变得强大而令人敬畏。

狼是最善交际的食肉动物之一。它们并不仅仅依赖某种单一的交流方式，而是随意使用各种方法。它们嚎叫、用鼻尖相互挨擦、用舌头舔、采取支配或从属的身体姿态，使用包括唇、眼、面部表情及尾巴位置在内的复杂精细的身体语言或利用气味来传递信息。 

如果人类像狼一样努力培养并运用有效的交流技能，我们能避免多少暴力、误解和失败？！

有时候没有信任可能也有交流，然而，没有表达清楚的交流则不可能有信任。家庭和其他组织、团体可以通过开诚布公的沟通和交流来解决问题，没有沟通它们就会出现机能障碍。