不完全IT手册

发信人: lmchen (匪兵丁), 信区: WorkLife
标  题: 不完全IT手册（一）——引子
发信站: 水木社区 (Wed Jun 25 10:14:04 2008), 站内

http://chenleimin.blog.sohu.com/91036323.html

一直以来很想写这个系列，针对国内挨踢行业中的小组长，总结一些经常遇到的问题、困境以及需要注意到的问题。同时也是我对自己的一个总结与归纳。

作为一个挨踢行业的小头目，一般情况下带上三五个人，领导就交给你个硬骨头让你啃了，累死累活的做下来，客户很难缠，领导很滑头，跟着你混的兄弟闹着要辞职，经常遇到吧，很痛很难受。很多时候真的想撂挑子不干了，可是不挨踢，我们含能做什么呢？

我一度很向往各种软件工程的文章中所描述的优良开发环境，但是，我也发现更重要的是你需要一个适合你工作环境与客观条件的工作流程，金庸小说里有句话我修改一下：“那都是很好很好的，可是我不适用”（谁能不翻书就知道此话的原型，出处？）

所以我的系列叫做不完全IT手册，说的就是不具备各种客观条件下，我们这些挨踢的，怎么能少痛一些。

首先描述一下这个系列文章希望探讨和解决的问题吧：

1.客户总是不断的提出新的需求来，我这边刚刚连续加班了好几个月了，这都要上线实施了，客户忽然提出一个修改意见，而且还很难实现。去和领导说，领导墨迹半天，反正最后是必须按照用户说的做。

2.手边就这几个兄弟，还有干活很差的，和领导说了多少次人手不足人手不足，领导光答应不见补充，时不时还从我这个组抽调人，好容易补充一个进来，发现此人是个笨蛋，交给他干的活，还不如我自己晚上回家干呢，不够跟他废话的。

3.预定的日期根本不能交付，总是不断的发现新的BUG，这BUG简直是改不完了。

4.每次我都希望能做一些系统化、平台化的东西，希望代码可以复用，可总是因为各种客观原因，最后能复用的代码几乎和没有一样。

先写这么多吧，作为一个开头，说实在的，我也不知道后面会写成啥样子。


--

※ 来源:·水木社区 http://newsmth.net·[FROM: 211.154.5.*]



2008-06-26 | 不完全IT手册（二）——需求（1）

干咱们这行的，平时主要是做项目，做项目最重要的就是需求，以后的无数烦恼，都是因需求而生，需求采集的好不好，那简直是关键中的关键啊。

很多人（包括我自己），总是抱怨客户太难缠，什么都不懂，乱提要求，还蛮横的很，而且临到最后关头还乱提要求。这里当然有客户的问题，但恐怕更多的还是我们自己没有理解客户真正想要的是什么东西，才会出现各种南辕北辙的花花出来。

我把需求的交流分成两个大的阶段，第一阶段是合同还没有拿下来，你仅仅是作为一个售前技术支持的身份在和客户谈。这个时候，无论从你公司还是个人的利益出发，还是应该多装牛人为好，这未来的东西怎么美好怎么给用户描述，一切按照共产主义已经实现，物质极大丰富的状态来。看到这里估计好多人要摇头了，因为我们经常发现和我们合作的市场人员就是这么干的，最后签下来一个我们根本做不到的单子，为此而头疼啊头疼，怎么轮到我们自己也要这么做呢？没错，现在这个市场环境，吹牛皮是必须的，不吹牛皮是要饿肚子的，放心好了，我相信你作为一个技术出身的人员，你再怎么使劲吹，也吹的有限，你的骨子里，还是知道最后这个项目要你自己负责的，所以这牛皮你吹不破。

我重点想讲的是第二种，现在项目已经拿下或基本拿下了，这个时候就要很仔细很有耐心的去采集需求去了。这里首先避免两个误区：第一，来不及了，赶紧开工吧，这个我相信，再紧张的项目，多挤出一点时间来放在需求上都是必须的，你在需求上所花费的时间，绝对不会浪费，而你节省的那点时间，很可能未来给你带来巨大的麻烦。第二个大误区，千万不要以为你们那里谁谁谁去过用户那里几次，或者你自己去过几次，需求已经很清晰了（估计你的领导经常这么想）。我自己的痛苦教训告诉我，差远了，耐心，千万耐心，跟领导面前装傻，说你好多不懂呢，要求去见客户访谈。这个一般情况下领导会同意的。

注意一点，一定要去见最终客户，很多项目，层层转包，你的甲方并不是最终客户，甚至甲方的甲方的甲方都不是，没关系，你只要坚持见最终用户，一般都能实现的，无非人家让你说你是XX公司的而不是XX公司的，仅次而已。

有的项目确实见不到最终用户或根本就没有，那么你也要尽量的和最源头的人多交流，访谈，了解他的想法。有的项目，构思是虚拟的，你也要多和各方多聊聊，这个时候多装傻，多装孙子没关系。总比日后不得不装孙子强多了。

归根结底一句话：需求需求需求！！！！！！

今天先写这么多吧，下次写怎么采集需求，然后写需求的分析整理与持续跟踪。


2008-06-27 | 不完全IT手册（三）——需求（2）
首先很意外受到这么多人的支持，在此向忍受我大量错别字的朋友表示感谢和歉意。

在需求的第二部分，我主要想讲一个重点“真正的需求”。

经常，我们总会抱怨客户乱改需求，经常变来变去，根本不管我的项目已经进展到什么程度了，还经常提出一些颠覆性的需求来。我承认，这里很多时候确实是客户的问题，但也有很多时候，是我们自己没有采集到“真正的需求”。

有个经验是：想把某个行业的IT做好，首先要成为这个行业的专家。这句话很对很正确，同时也很空很废话，不是我们不想当，实在是当不了啊。不过，至少，加强对这个行业的了解，这个总是没有错的。我自己的窍门是多做访谈，这种访谈要盯住两种人，第一种是甲方的领导，访谈的重点是他想做什么，他想要什么东西，这种访谈可以更加务虚一些，不必纠缠于细节问题，还有一个重点是多了解你的同类产品或方案中，甲方领导更喜欢哪个，尤其是喜欢那个产品或方案的哪些特点。

第二个访谈重点是基层的具体工作人员，要了解的重点是他们现在是怎么操作的，这个时候，我希望你能暂时忘掉你所有关于IT的知识和经验，把自己当作一个学徒工，就是来学习他们现有的工作流程的。这点很重要，首先，你要知道，世界上没有凭空产生的工作流程，你所要开发的系统，一定是从他们旧有流程中演化出来的，虽然你的系统上线后，旧有流程将被抛弃，但所谓存在即合理，旧有流程一定有他的道理，而你的新流程，最好能尽量贴近旧有流程。其次一个好处，用户以后不是会经常变更需求么？你的系统框架，如果能够尽量的与他们现有框架及流程贴近，则他们的小改动，对你也是小改动，他们的大改动，对你也是大改动，这样，在发生需求变更的时候，也更好沟通一些。最后，你多和他们的基层工作人员建立联系，在后面的开发和维护过程当中，将为你减轻无数烦恼。

这里有个小技巧，尽量多的收集他们现有的各种单据，报表等一切书面上的东西（当然要看看哪些是必填的，哪些他们自己也不填），最好能做一次业务跟踪，因为这个就是他们现有的流程，现有的工作方式。

经常，在上面讲到的两个访谈重点当中，领导和基层人员的访谈内容，经常会有矛盾的地方，这太正常了，领导嘛，就是这样的，对底下的具体工作，未必比刚去过几次的你更熟悉，不过千万不要想当然的认为基层人员说的就是对的。对矛盾之处，多问问，一方面在客户处提升你的形象，另一方面，这矛盾之处也很可能是你未来的雷，先把它排除了吧。

最后，我来唐僧一下为什么要采集“真正的需求”：你将能够尽可能多的预测到他们未来的需求变更（注意我的用词不是“全部需求变更”），只要你在设计的时候有所准备（哪怕仅仅是想到而已），未来都会省事许多。白家二奶奶说的特好，这什么事挺好的时候，你要尽量往坏处想。

好了，现在你已经大概了解了你的客户想要一个什么东西，下面就该与客户交流你理解的是否正确了。然后就是对需求的持续跟踪（因为需求还是会变的，甚至到你交付之后，呵呵）。这个，就留给下一篇讲了，下一篇也是需求部分的最后一篇，然后进入设计篇。

2008-06-30 | 不完全IT手册（四）——需求（3）

很多看似偶然的事情，其实也有其必然性，就好像痿了那么多年的西班牙队，这次也雄起了一把，不过看看替补席上都坐了些什么人，大概也很正常吧。而我们抓需求的过程，也到了最后也是最关键的一步——与用户确认需求。这里的一个偶然的小失误，将必然的带来灾难性的后果。

还记得我在上一篇里让你忘掉所有的IT技能么，本篇请你依然保持这种状态，与客户确认需求的主要工作是编写和讲解《需求分析》，在大部分的情况下，这个报告是由我们自己编写的，在敲这个报告的时候，请你尽可能的少用IT词汇和IT概念，这个时候你键盘下的，应该仅仅是未来这是个什么东西，虽然你脑子中已经在想这东西怎么实现了。

我们经常抱怨客户不懂IT，沟通困难等等。不过我想说的是，客户不懂IT，天经地义，你讲的东西客户不理解，那么百分百是你自己的问题（当然，理论上是这么说，我自己有时候也有去找板砖的冲动）。你对未来系统的描述，需要尽量从客户的角度出发，用他们听得懂的语言，看得明白的图。

讲到了画图，这是一个小技巧，尽量多画图，对很多流程化的东西，画图将大大的加强读者对你文章的理解，很多人，可能不太擅长画图，不过幸好我们这个不是美院考试，没关系，几个框框，几个连线，远远比你堆砌一大堆文字有用的多。

另一个要注意的地方是最好做到标题明确，那个章节是讲哪部分的，从标题上一眼就能看出来，同时关于此部分的内容尽量的都在这个章节里面，不要不同的章节都说到了某件事情的某个方面。因为客户很可能也是分多人阅读的，每个人大概也只对和自己部门有关的事情感兴趣，他们中的大部分人都没有通读你全文的兴趣和义务。

第三点要注意的是，你需求文档写好了之后，一般来说是发给用户后等消息，这个时候我建议你主动一些，主动去多了解用户的想法，向各个方面的人了解，他们有的看了没看懂，有的根本没看，所以回向你提出各种古怪问题，这个时候千万别随便回答“文档中已经写了，你自己看吧”这种性质的话，有点耐心，慢慢回答，然后确认他们听明白了。这个过程很关键，因为你要知道，要是他们听明白了你的想法和构思，他们就能知道你的构思是否适合他们，同时以后提出的各种变更，他们自己首先会明白这个对你的影响是否很大。

第四，讲讲快速界面演示，就是你做一些只有界面的空壳出来，让用户看，这是一个很好的办法，有些项目不适用，不过如果适用的项目，我建议你尽量采用，但需要很唐僧的向用户强调，这个不是最终界面，后面会随着开发过程而有所改动的。

有的时候，你会有机会对你的方案进行一次正式讲解，这个时候主意分清来人的身份，分清主次，我就经历过一次讲解，讲解人在上面事无巨细的滔滔不绝，听讲的人在下面昏昏欲睡，最后人家啥也没听明白，人家不明白的后果就是不发言，不确认，拖着，最后受苦的还是你自己。

从道理上说，需求分析需要对方签字确认，但实际过程中一般都做不到，但做不到你也要嚷嚷，这么做的主要目的是要客户重视和你在需求上的沟通交流，现实中确实有这样的用户，他们那意思就是你先做着，等你做完了我再看，再告诉你哪不对。这是最让人头疼的一种类型，我能做的仅仅是恭喜你踩到雷了。

好了，以上工作差不多的时候，你也明白客户要什么了，客户也大概明白你准备做什么了，项目时间估计也耽误许多了，你一定很着急开始做设计编码工作了吧，没错，下一篇我们开始讲设计，不过你千万千万不要忘了，不管开发多紧张，持续的和用户保持沟通，看看他们有啥新想法，有一些阶段性的成果时（例如界面，报表等等），有条件时最好能找用户的人来看看，小技巧是最好找那些基层人员（即未来系统的实际使用人员），他们首先会有一些很好的意见，同时他们回去之后，会去宣传你的系统，宣传新的工作方法，替你在甲方用户群中完成洗脑工作。

2008-07-01 | 不完全IT手册（五）——设计（1）

首先必须明确的一点，“设计”这个流程是一个统称，这里其实包括很多小的任务明确的流程，即使按照最简单的分类方式，也可以分成概要设计和详细设计这两种。其次，设计流程没有，也不应该有明确的起止日期（你做任务计划是另一回事），在做需求的时候，对于一些很明确的东西，就已经可以开始做设计了，而即使到了测试阶段，随着变更的需求或你发现的BUG，依然要进行部分设计工作。

好了，废话说完，进入正题。

第一步工作，显然是让你的团队熟悉需求，文档发给大家看，然后自然是必不可少的讲解，给大家讲目标系统要实现什么东西，对你的团队而言，他们不必像你一样对客户流程滚瓜烂熟，但也一定要清楚大概是怎么回事。

第二步工作是模块划分，每个模块大致完成什么功能，由谁来做，基本上明确下来，注意这里仅仅是粗分，对模块之间的连接不必过多讨论，这个工作应该做的很快，有条件的写个小文档，没条件的大家开个碰头会讨论一下也没啥不可以。

第三步是一个重点了，就是对各个模块进行技术层面的设计工作，这里，我强烈建议当PM的不要自己写这方面的文档，一定是你计划让谁做这部分的开发，就让谁写设计文档，不要怕他写的差，写的不好你告诉他哪里不好，让他重写（这里我们假定员工的态度都是好的，关于这个问题将在后面的文章中重点说），这样做的重要意义是你能够知道他们自己在多大程度上理解了你的想法，没理解的部分，都是哪些没理解。这个时候千万不要为了省事自己写，一般情况下，你写的东西，他们不管懂了多少，都会跟你说他们懂了。

第四步，就是让他们自己来讲自己写的技术方案，你自己一定要听，如果有条件，你组内的成员也都来听，白板是必须的（什么，你们老板这个都不给买？那你早点辞职吧），有投影仪当然更好。设计人员自己讲，能引起他本人的足够重视以及加深他的理解，组内人员都来听，对后面的相互之间的合作将有莫大的好处。有的时候，第一遍讲的效果很不好，那么你就要组织这个人第二次讲，当然了，为了避免视听疲劳，可以只讲修改过的部分。讲的时候注意时间控制，有问题当然可以随时停下来讨论，但不要一讨论就没边了，必要时刻你要中断讨论。集思广益，独断专行，IT并不是一个讲民主的地方。

本篇的后半部分，说说另一个重点，任务如何分配。一般来说，作为PM，你总是这个组中技术水平最好的人（或者之一）。我看到有些PM总是将最重的模块留给自己，在为你的奉献精神鼓掌的同时，我对你的行为则很是摇头，一定一定要记住，作为一个猪头小队长，你最大的任务不是战斗，而是监督管理你的小队去战斗，你一定要有空闲时间抬起头来，看看你的小队成员干活干的怎么样了，看看小队以外的（客户，领导，其它小队？）都在干啥，如何与他们配合呼应等等，而这些，如果你自己扎在代码堆里，那么你就几乎看不到了。

当然，也不是说你就可以什么都不干了，端茶看报纸上QQ和MM视频了。首先我估计你也没那条件，领导也不答应，其次，项目中一些重点内容我看你还是自己把握才比较好（注意是技术重点，不是工作量重点），例如整个程序的架构、数据库结构、各个模块之间的数据接口等，不同的项目有不同的重点，这个相信你自己一定知道该把握什么。

下一篇，我来讲讲设计文档中都需要写一些什么东西，哪些东西是需要写的，哪些东西是可以简写或省略的。


2008-07-02 | 不完全IT手册（六）-设计（2）

毫无意外的，在本篇的开始依然用一点废话来回应大家的评论

有人评价说看了咱的文章语文水平有所下降，这个没办法了，我就这么高水平，您捏着鼻子看吧。有人说文章太简明了，对人的帮助不大，这个，似乎也是我的水平问题，我要是有本事写个东西，让新手迅速成为专家，那么匪兵就不是那个匪兵了。有兄弟说文档其实比代码难写，这个我也很同意，不过我觉得其实文档比代码更重要，虽然文档不能执行。还有兄弟说组内成员写文档很差，首先对你们全部用E文写文档汗一个，再拜一个，其次为后面的某篇文章爆个料，匪兵我自己一直认为对吃程序员这碗饭的人来说，不会写文档比不会写代码还要可怕，实在写不好文档的话，要不考虑一下早点该行？

废话说完，开始新的废话。

本篇主要讲讲设计文档都写一些什么东西，这里有个前提，对设计文档来说，理论上讲，没有任何东西是必须要写的，没有任何东西是必须写成什么样子的，也没有任何东西是写了一点都没用的，写什么，不写什么，怎么写，最关键的是看你的项目条件如何，项目规模如何这些因素，一般来说，越是庞大的项目，文档就需要写的越细致。所以我这次的文章，在列举一些我认为重要的部分同时，会同时说明这部分的意义及重要程度，请各位自己把握。

1.功能流程：这部分个人一直以为是概要设计中最重要的内容，其实这主要是将你前面需求文档中的流程给技术化了，主要描述对什么样的输入数据做什么样的判断，然后给出什么样的输出，中间去哪里取什么数据，怎么存储，怎么传输等。这一部分基本上就是程序框图了，你写的时候也不妨直接把框图画上去。注意这种流程最重要的是与功能有关的流程，项目无论大小都要写清楚，部分仅仅与算法有关的流程，则可以根据情况写，或者只写个接口或不写，这个主要看你详细设计要做到什么程度。非常重要，概要设计的基本内容。

2.数据流：主要描述数据流向，基本上也是以图为主，文字说明为辅，描述数据流的，这个东西在不同的系统框架下重要度不一样，有的框架下，这个东西很重要，有的则几乎可以省略。根据项目需要非常重要或不重要（晕）。

3.数据接口：主要是指各个模块之间的接口，即不同的开发人员之间的接口，还包括各种数据结构定义（数据库定义，数据文件定义等），在不同的模块（主要是指不同的人之间），明确他们之间如何进行数据交换及流程的转换。这个东西要么在你的系统中没有，只要有，就是非常重要的东西，而且建议你自己亲自审，一个字节一个字节的审，理论上不要有任何歧义才好。同时，以后万一有了修改，也尽量的要主意敲锣打鼓的让你整个项目组的人都知道。只要存在就非常重要，建议单独写文档。

4.用户界面：可以先画一些空界面出来，这个主要看项目需要和项目大小，报表，打印凭条，这个也是界面的一部分。重要，但同样看项目特点而定（再晕）。

5.错误处理：这里包括错误代码的定义和处理流程，关于错误代码，我个人的习惯是用8位数字，头两位是模块代码，次两位是子模块，后面四位留给程序员自己用顺序号来逐一区分所有的错误。最后我们统一做个函数处理这个错误。错误要分等级，最起码分成“错误”和“警告”两级，当然你也可以无限细分，最严重的自动拨打110啥的。重要，可以简单写，但一定要有。

6.类定义（或函数定义）：这个就基本上属于详细设计的内容了，对于重大项目或项目中的重点流程，这个东西还是很有必要的，而且现在这么多辅助设计工具，写这东西也不麻烦，也不造成重复劳动，所以这个虽然已经近似于编码了，但在设计阶段，能写还是写了吧。重要，在不严重增加工作量的前提下尽量写。

7.测试：包括测试流程和测试用例，有的时候甚至包括要开发一些专用测试工具，这个东西我个人比较建议在设计阶段就都规划好，不管你们公司有没有专门的测试团队，关于对你的系统如何进行测试，毕竟是你最了解。重要，反正你早晚都得做。

最后再说说概要设计和详细设计之间的关系，理论上说是先写概要，后写详细，没错，如果你的项目很重要很庞大，而且客观条件允许，那么就该这么写，但对于一些中小项目，或者不具备条件的，不妨把概要稍微写细一点，就开始编程了，这么做肯定有风险，不过考虑到成本，对小项目而言，这个风险可以承受。

预告：从项目进程上说，下面该讲堆代码了，不过代码千变万化，匪兵我自己也不是编程高手，所以取个巧，主要讲与代码有关的东西吧，版本控制，进度控制，以及测试相关内容。

2008-07-03 | 不完全IT手册（七）——开发

本篇的前缀废话实在太多，单独列个帖子给有闲的人自己看吧《一段关于设计阶段的讨论》http://chenleimin.blog.sohu.com/93553238.html

对于一个挨踢领域的猪头小队长来说，在开发阶段，你的身份将是周扒皮和救火队长的结合体，有的兄弟比较可怜，还要变身为全能战士，在这几种身份中间，请记住你的基本身份是周扒皮，其它都属于兼职，你最重要的任务就是盯进度。

我发现很多人（包括我自己在内）经常对开发阶段的时间表过于乐观，执行到后来，总是不能按期完成，而最要命的是，总是眼看就要完成了，实际上却一天一天拖下去，直到花儿都谢了。匪兵我没本事提出一个完整的进度管理方案出来，仅仅说几个我自己有体会的重点：

1.人为的多设立几个任务基准点，我很想给你条原则告诉你如何找基准点，可惜我自己也仅仅是凭经验，凭感觉，具体项目具体分析的，总之要设定几个小目标，多设定几个，这样你就能提前知道项目是否耽误了，耽误了多久，都耽误在什么地方上了，这样你就能及时调整部署。

2.先难后易，在项目的开始，尽早的预计开发工作中的难点，大致分成三个等级：A.不会做的；B.没做过，但估计会做；C.纯粹的垒转头的体力活。对于A，尽早，尽全力组织人去做公关，调动所有资源，同时做好调查，必要时请第三方帮忙做，为此要提前向老板诉苦、吹风（为啥？要预算啊），也可以做好绕开这个难题的技术方案。对于B，这个经常被很多人忽略，不过只要在安排开发工作时把这个放在前面，一般来说问题不大，对于C，你自己看着办吧。注意一点，所有需要外协的事情至少加半个等级。

3.及时进行单元测试，开发完哪部分，马上测试哪部分，不要等到代码都堆完了，再一起测试，到时候你死都不知道是怎么死的。

开发阶段第二重要的是版本控制，现在市面上能找到的版本控制工具很多很好用，你不必一定去寻找哪款最好，找一款你自己用的最熟悉的就可以了，版本控制的重点是执行，我经常看到有的项目组有版本控制工具，也建立了很全的制度，但经常借口开发紧张啊什么的，就忽略了版本控制的执行。所以说，你的版本控制方法可以简单（哪怕仅仅是在文件名目录名上增加版本号都可以），也可以功能并不强大，但一定一定要坚决执行，对于不按规定操作的情况，发现一个处理一个，不怕别人说你唐僧，不怕耽误事（能耽误多少啊）。

开发阶段的另一个重点是测试，很遗憾，匪兵我自己不太懂测试，或者说很不懂，我的经历中，要么测试做的不好，要么有专门的测试团队来跟我配合。我就讲讲找BUG的一些思路吧，首先，明确问题在哪里最重要，宁可多花点时间做个小工具啥的，也要大致区分错误在哪个模块当中，这里注意不要盲目的说哪个哪个流程执行的没问题，所以某个模块肯定没问题，这种判断很危险。其次，对于BUG，不要着急上手改，注意分析深层次的问题，注意分析改之后对其它模块的影响，反正BUG已经出了，也不差这点时间不是。第三，对于需要做大修改的地方，保持慎重的态度，有时候做到后来，发现原来的一些结构啥的不合理，需要大改，要么小修改凑合事，要么大修改让自己看着很爽，对后者请保持足够的慎重态度。

其它，当然还有要推广好的编程风格，注意写注释，写修改日志等等，相信你都知道，自己把握吧。

作为一个IT项目，开发之后就是测试与实施，不过匪兵我对后两者并没有什么特别的心得（我只会往上糊人力，有没有啥大牛给讲讲你的经验？），就不完全了吧。不过，幸好还有一些很有意思的话题，下一篇，我们来讲讲变更。

2008-07-07 | 不完全IT手册（八）——变更

谁能料到银石赛道上那么大的雨，谁能料到水木现在居然挂了，谁能料到匪兵我这第八篇隔了这么多天，谁能料到项目进行中会会出什么样的岔子。所以说，人在挨踢中，哪有不变更。

无论如何请你记住，不管什么样的变更，只要是你有所准备的，都不可怕。对此有深刻理解的兄弟姐妹，本篇后面的废话你不用看了。

最大，也是最让人头疼的变更一般是来自需求方面的变更。别管用户怎么向你拍胸脯保证，签字画押写血书（汗一个，你们有遇到过的么），那都没用，人家到时候说变就变了，比孙悟空都快。这种变更对项目显然是有伤害的，而我们能做的仅仅是将伤害降到最低。

首先一点，请复习需求篇，尽量去跟踪用户，深入的，细致的，去了解他们的工作流程，尽可能多的预测他们未来可能的变更之处及变更的方向。其次，尽量的将你的系统结构与用户的实际结构保持类似，这样只要用户不变出花来，你也不必重新浇水施肥了，虽然你可能做点剪枝的工作，不过那将轻松的多。这里匪兵我唐僧一下，请重视OO的方法，并且永远不要认为你已经对OO足够了解了。当然了，OO也并不是万能的，现实生活中，依然存在一些实际的东西，它们确实是过程式的，你非要用OO来解释，会把简单的事情搞复杂。第三，尽量和你的客户保持良好的沟通，这里有两层涵义，一是尽早的发现用户可能的变更，一是当有变更时，你可以尽量引导用户向超你有利的方向去引导。最后，请在你的体系结构中留下足够灵活的空间，减少“代码中写死”这种事情，预定义，继承，封装，重载这些概念要用好，尽量让你的系统结构保持低耦合。

技术层面的变更，这是一种非常常见但经常被忽视的变更。主要可能因为这种变更相对比较好处理。首先是因需求变更引起了你的体系结构的变更，这个在前面我们提过，匪兵我的建议是代码之前随便改，代码后期尽量慎重，只要能应付过去，尽量不要大修改，尽管这样会使整个结构变得很难看，但世事难料，我们虽然总是觉得系统是低耦合的，但现实中系统总是在我们忽略的地方保持高耦合。还有一种例如硬件设备的变更，数据库的变更，平台的变更等等。我个人的感觉是这方面的变更如果在写代码之前怎么变都无所谓，写了代码之后救要看运气了，有的时候是整个代码的重写。所以匪兵我的建议同样是慎重而已。

即便如此，这个世界上依然有太多我们无法预料，也很难处理的变更，我没本事提出一套完整的变更管理机制出来，我能给出的建议就是要冷静，越是这种时刻，越不要着急，不要很快的觉得自己已经想清楚了，开个小会就安排人手改，慢一点，多想想总是没坏处的。同时，测试要重新做，包括你认为根本不影响的模块最好也重新做一遍测试，至于测试部门的头打算砍了你，我这里倒是可以向你推销一种匪兵牌钢盔和防弹背心，套装有优惠哦。

广告：下一篇我们讲团队建设，这个是与项目没有直接关系，却能够决定项目成败的重大因素，当猪头小队长的，不可不察啊。


2008-07-09 | 不完全IT手册（九）——团队

做好一个项目，需要整个团队及团队以外的很多人共同努力，而搞砸一个项目，一个人就够了。

对于你的小队成员，在一般情况下，其实小队长没有啥管理权，你不能决定他们的人事任免，不能决定他们的奖惩升迁，你看的上的人，不是要辞职走人，就是领导要抽走，你看不上的，领导则一定要把这人放在你的团队中。有的时候，干脆连你看不上的人都加上，人手也是大大的不够。没办法啊，这就是现状，幸好在现状中，我们还是能做一点事情的。

团队的培养和建设是一个长期的过程，很多新手，刚刚加入团队的时候确实很不怎么样，不过人都有个适应过程的，有些人以后就会成为你的主力，有些人，你不管怎么培养他，都是在浪费彼此的时间。

看一个人有没有培养前途，首先悟性是最重要的，这个人会什么，懂啥技术，其实关系不大，IT就这么点东西，不会可以学嘛，有啥学不会的。悟性，这个概念有点玄，简单的说，首先是沟通和理解能力，你说的他肯听，听了之后能理解，理解了之后能执行，按照最低标准来衡量，这就足够了。其次是学习能力，学习能力中最重要的是能够触类旁通，否则如果一个人每个事情都要你教他一遍他才知道，那么你这个小队长就有的累了。

对于培养前途，匪兵自己有个小窍门，看文档，看这个人文档写的如何，也许一开始很差，不过你给他讲过之后看进步程度如何。第一，从这里你能很明显的感受到刚才我说过的“悟性”，第二，文档能写清楚，则代表他的思路就很清晰，能够和你有共同语言。第三，IT项目中大部分都是体力活，体力活中很重要的就是文档，文档也是你日常工作中非常重要的部分，一个能把文档写好的成员，将为你自己减轻无数压力，同时也很容易成为你团队中的主力。

这里会有一些特殊情况，首先，新手大都不爱写文档，这个时候就需要你变身为政委同志，谆谆诱导加威逼利诱，总之不管他本人意愿如何，要让他重视文档，哪怕你用一把左轮顶住他的太阳穴也在所不惜。其次，有些家伙确实文档写不好，不过他钻代码的能力很强，确实有一些别人很难解决的技术难题被他解决了，那么，这个人我建议你尽量用，但不要把他当作培养主力了（是不是有点厚黑了）。

团队建设中，很重要的一点就是要谅才使用，你手下就这么几个人，你想调整也没戏，也只好尽量发挥每个人的能量了，对于你认为能力较差的，尽量让他做一些比较外围，但工作量其实并不小的东西。匪兵我这里有个自己比较得意的实例，曾经组内有一个领导安排进来的能力很差的人，项目一开始，别人都在写设计了，我就先规划了几个测试工具，我简单写了方案后交给他开发，都是那种技术难度不大，对技术水平没啥要求，但工作量并不小的，主要是数据的模拟收发及按照一定规则的分析。后来他这个代码写的比较烂（大量的复制粘贴代码等等），不过简单改过一些小BUG之后，用起来还是没问题的。反正不是给客户的程序，能用就行了。项目后期，除了让他对那几个测试工具进行一些小修改，还可以让他帮忙测试（测试他就比较熟悉了，自己写的代码，自己也知道怎么用），还让他帮忙写了不少使用说明，虽然他写的使用说明有点惨不忍睹，不过好在基本素材都给你罗列出来了，我只是再把文章重新组织了一下，然后再对文字上做些修改即可了，无论如何比我自己从头写要轻松。最后我也轻松了，项目组其它成员也很满意（分担了一些本来该他们干但他们又不愿意干的工作嘛），这位关系户自己也很有成就感，简直就是琼瑶式结局啊。

良好的团队学习机制是提高团队凝聚力的一个很好的因素。当然，会有很多讲人事的培训或书教给你无数的理念和方法。那些当然是很好的，不过作为小队长的你，估计很多都做不到吧，匪兵我只讲一个小办法，这个办法是我自己实践过，且感觉效果非常不错的。定期的组织你的团队成员共同学习，时间以每周一次为好，也可以双周一次，每次由小队中一个成员来讲一个主题，主题由他自己选，随便他讲什么，与工作沾边即可，可以是技术前沿，编码技巧，对一个具体问题的解释，一些工作中的体会啥的，随便他讲什么都可以。每次一个人讲，大家轮流，讲之前提前一天公布讲的主题，要求主讲人做一些准备（讲稿,PPT等随便），时间安排上一半由主讲人讲，一半自由讨论，最好每个人都要发言。

这办法的好处首先体现在技术层面，假设你的团队是6个人，每周一次，我相信任何人在一个半月内的时间里总有一些很好的体会，而你的小队，每周都有一个非常现实的好东西由全队来分享。其次还体现在凝聚力层面，他加强了团队的吸引力，加强了团队的团结和默契程度。还有一个隐形的好处，你可以借机观察人，呵呵。

最后，一个小小的厚黑建议，即使你的小队很闲，也要让大家来起来很忙的样子，即使你的人勉强够用，也要经常找领导哭穷，要求补充人，嘿嘿。

广告：不完全IT手册写到这里，只剩最后一篇尾声了，匪兵我肚子里的墨水，基本上也就这些了，算上尾声，正好十篇，也算是不完全手册的一点完美之处吧。

2008-07-10 | 不完全IT手册（十）——尾声

实在想不到当初给自己写的一个总结性文章得到了这么多人的支持，很汗很惭愧，同时也很偷着乐。

匪兵我自己的工作经历不长不短，马上9年了，这期间还是比较坎坷的，也比较复杂，当过全职的程序员，技术支持，部门经理，项目经理，销售，总经理及老板，兼职过财务，HR，保洁及保安，历经过国企，私企，外资，股份制公司，公司规模从数人到数千人不等。技术领域同样是博而不精，会的东西很多，但真正拿的出手的很少。把这些告诉大家不是为了夸耀啥的（说实在的也没啥可夸的），只是说明一下我的工作背景，了解我的知识结构，好让大家了解到我为什么会重视某些而不重视某些。

感谢各位回复的牛人，都不同程度的指出了我文章中的各种不足，匪兵我很汗的同时，也很受教。很多牛人都看出了我知识体系中的不足之处，是的，匪兵我确实也有很多需要学习的地方，文章中确实有盲点，不过想到这个系列文章并不是想从头指导人怎么当一个小队长，也就释然了，不足就不足吧，还是只写我有切身体会的东西，而不写很多我不太懂的其它正确道理。

在这个系列文章的最后，说一点总结性的东西吧。

第一：其实任何项目做到一定程度，你需要关心的都是人，而不是什么什么技术，什么什么体系结构，更不是什么什么代码。你能够体会到如何与各种人打交道了，那么技术什么的都是次要的了。

第二：不要什么事情都亲历亲为，不要借口什么项目紧张啊什么的，在理论上，你应该尽量盯住所有的事情，但绝不该去操作所有的事情。知道拿破仑是怎么失败的么？

第三：多听听大家的意见，但你自己一定要有承担，有决断，集思广益，独断专行。

第四：不管遇到什么样的困难，首先请冷静，冲动是魔鬼，这里毕竟不是真正的战场，没有什么事情是非要马上做出决定的。

在文章的最后，请允许我想所有关注过这个系列文章的人提一个小小的与项目无关的建议：所谓做事先做人，我知道，做一个好人，很难，但有机会的时候，请你做一个好人，谢谢。