格格她爹讲程序之项目那点儿事儿

tinyfog 2014-05-20 01:51:09

******************************************************************************************************************
（显示不全，可以看我博客，或者看我的QQ空间）
*******************************************************************************************************************
项目那点儿事儿

首先，先说清楚，这篇文章仅是我的个人看法，如果有觉得说的不对，一、不许扔砖。二、如果必须扔砖，不许砸脸！三、如果必须砸脸，不许砸我的脸！

1 开头就是个错，结尾还是错
春夜京都雨，

孤灯伴夜深。

妙得千百字，

写尽程序人。

怎么说呢，不知道为什么今天有这么高的兴趣，想写点东西。

可能是白天看了一个笑话吧：

客户被绑，蒙眼，惊问：“想干什么？”，对方不语，鞭笞之，客户求饶：“别打，要钱？”，又一鞭，“十万够不？”，又一鞭，“一百万？”，又一鞭。客户崩溃：“你们TMD到底要啥？”“要什么？我帮你做项目，写代码的时候也很想知道你TMD到底想要啥！”

本来也不是什么太好笑的笑话，一般看看就算了，但是看完笑话，正赶上单位例会，个别项目遇到问题了，几个项目经理提出一堆老生常谈的事出来“客户需求老是变来变去！”，“有个别程序猿想离职！现在人又不好招”，“客户没说什么时候验收！上次去了也没人接待”，“……”

套用现在比较时髦的话来说，这都不叫事儿。因为，好像这些都是每个“挨踢人”经常遇到的事儿。不信上网搜索一下，类似的笑话多了。而且，我敢保证，如果哪个“挨踢人”“程序猿”敢说他没遇到这种事儿，我杀他全家！

我工作十几年了，除了中间有一两年，在做产品外，一直都是在做项目，参与过的项目，如果不论大小都算，估计不到一百，也有八十了。遇到的问题也多了去了。不过，细算下来，我觉得，一般分三类：需求变化、人员流动和客户协调。

说这些时，我想先明确一个概念：啥叫项目。

问问百度大婶：“项目是指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。”。

所以项目的特性也就很明显了：

1、项目开发是为了实现一个或一组特定目标

2、项目受到预算、时间和资源的限制

3、项目的复杂性和一次性

4、项目是以客户为中心的

在这几个特性中，我觉得，首先你得先明确的一个核心思想是第一项目和第三项目，“一个”“一次”，那说明了什么，很简单，项目这点儿事，一般是不可能重复的，最其码是不可能完全重复的。接下来要理解，“限制”，这个不用讲了吧。项目特性说的很清楚了，做项目本来就不可能想要什么就有什么。最后，理解“以客户为中心”，还用解释吗？让你干啥你就干啥。

2 怎么了？为什么？怎么办？
其实概念和道理大家都懂，但是一旦真正开始了，问题就不一样了，怎么说呢？如果按上面的概念来理解，我们的大学教程和书上说的内容很容易解决这些问题呀。

问题1：“客户需求老是变来变去！”

回答：“你在前期做需求分析的时候，要把需求分析搞清楚，要做到真正了解客户的业务，到做的时候，不就很容易了嘛。”

问题2：“有个别程序猿想离职！现在人又不好招”

回答：“你要一开始做的时候，就要先判定出每个程序猿的状况，首先要识人，然后才能用人，而且，在做项目时，就要想好人员流动的可能，留出人员的富余量。”

问题3 “客户没说什么时候验收！上次去了也没人接待”，

回答：“按合同上写的验收时间呀。做项目要有计划性，要把计划在初期做好，发给客户确认，客户确认没有问题了，就好办了。如果去客户处，要先和客户定好时间。”

大家听听，有问题吗？没有，百度大婶也是这么说的，不信你上网查一下。

但是，我们来看看程序猿按上面的要求去，会发生什么？

问题1，一开始做好需求分析，在客户哪泡了一个多月，所有流程都问清楚了，形成了《需求分析报告书》客户都看过了，都签字了。这样行吗？

不行！首先，客户签字的东西他真的全看过了吗？看过了，能看懂吗？看懂了，有没有他没想到的问题呢？有没有按程序猿的角度去看懂这些问题？这些需求是他一个人的意见，还是他公司所有人的意见？他能保证他确实对这些需求百分百负责吗？如果他签字完了，还是要改，你改不改吗？不改能验收不？

问题2，一开始，项目经理选好了合适的人，这些人都对公司十分忠诚，肯定不会出问题，还多招了一两个程序猿来做“备胎”，开始工作吧。这样行不？

不行！首先，什么叫合适的人？这些合适的人中间都不可能发生什么意外的事情？这些合适的人都没人父母没有兄弟姐妹，没有任何亲人，就算有，最近也不可能有事情？这些人真的情绪上都很稳定，受任何打击都没有问题？你们老板傻吗，还让你带两个备胎？你们的人力资源跟得上？你手下的人都特别听话，不可能有什么野心？

问题3，一开始，合同订清楚了，计划也清楚了，客户也都签字了，一切都按计划执行的，每次上线前和客户确认过了。可以吗？

不行！合同订清楚了，中国语言博大精深，合同的解释权归谁？客户签字了？所有人都签字吗？客户的领导签字了吗？客户的客户签字了吗？按计划执行的，计划的解释权归谁？客户就你一个项目，就这一件事，其它的活没有吗？客户的负责人不会换是吧？

好了，又一堆问题是吧？继续百度。

还有吗？没有了就做吧，遇到了，继续百度。

百度大婶确实啥都知道，如果百度大婶不知道，没准谷歌妹妹知道。

但是你确定每次都能从百度大婶和谷歌妹子哪得到答案吗？他们也都是听说的，而且是听好多人说的，如果有多回答，你听谁的？如果没有呢？如果有，但是时间已经不允许了怎么办？如果他们告诉你的答案是错的怎么办？

好了，问题出来了，解决吧，老板们都等着呢，因为每个程序猿遇到的问题，总有一天会反映到老板哪里，而上面也说了程序猿们是肯定会遇到上面所说的类似问题的，不可能有没遇到的，因为没遇到的，都让我灭族了呀。

老板们遇到问题了，真好，老板们都是有钱人，帮他们解决了问题，就能拿到好多钱，好多好多钱，好多好多好多好多好多钱。

既然如此，发明个方法吧。好的，解决的办法就是“规范”，有用吗？有呀，你上网查一下，好多人都是开公司，专业帮助各个公司解决“规范”问题，然后收一笔钱（看清楚，收一笔钱，和上面的一次性差不多）！老板高兴了，程序猿也高兴是吧？没有！！！！！！！！！！！！！！！！！

老板给了钱了，大家办事都规范了，项目不就都顺利验收了吗？怎么可能没有。但事实大部分如此呀。至少，我见到的，我听到的，我在网上查到的，成功的没有几个，大部分都失败了。

好吧，我们分析一下，我们先想一下这几个问题

首先，老板为什么要花钱制定规范，是为了让大家工作有条理，这样，软件可以由软件开发人员像装配工人一样，装配起来，形成流水线，但是这个理想，公司的中层理解了吗？公司的普通员工都理解吗？

其次，来帮忙搞规范的人，他们对公司的业务，公司的情况，公司的状况都很了解吗？比公司的员工还了解吗？

第三，形成的规范，可操作性怎么样？员工愿意执行它们吗？

所以，想了想之后，得出结论：项目管理这种事无解！大家洗洗睡吧。都十二点多了。

3 需求分析猛于虎
3.1 人有人言，猿有猿语
真的，项目管理真的无解！因为我们是中国人。中国人太聪明了，客户聪明到可以把合同上写的“时间设定功能”理解成“在一台电脑上设定了时间，其它电脑上都要调整过来，而且那些电脑都不一定要安装交付的程序。”这些你能想到？如果你能想到，变态的你见过不，上面的“时间设定功能”理解成“在一台电脑上设定了时间，其它电脑上都要调整过来，而且那些电脑都不一定与它联网。”你说你能想到？

有个大家都知道的笑话是这么说的：一个程序猿在海滩上发现了一盏神灯。他在灯上擦了几下，一个妖怪就从灯里跳出来说：“我是世界上法术最强的妖怪。我可以实现你的任何梦想，但现在，我只能满足你一个愿望。”程序猿摊开了一幅中东地图说：“我想让中东得到永久的和平。”妖怪答道：“哦，我没办法。自打创世纪以来，那里的战火就没有停息过。这世上几乎没有我办不到的事，但这件事除外。”程序猿于是说：“好吧，我是一个程序猿，为许多用户编写过程序。你能让他们把需求表述得更清楚些，并且让我们的软件项目有那么一两次按进度按成本完成吗？”妖怪说：“唔，我们还是来看中东地图吧。”

笑了吗？我就没笑，它本来就不好笑。

因为需求分析就是一件很傻的事，需求分析的问题也太多了，其实我一直不同意欧美一些砖家的理论，说什么中国没有哲学，扯！每个中国人都天生是一个哲学家。每个人都能把一句“我很好！”理解出十几种甚至几十种意思出来。

有时候，不止客户，程序猿们自己也有问题，还有一个笑话是这么说的：老婆给当程序猿的老公打电话：“下班顺路买三个包子带回来，如果看到卖西瓜的，买一个。” 当晚，程序猿老公手捧一个包子进了家门。。。老婆怒道：“你怎么就买了一个包子？！” 老公答曰：“因为看到了卖西瓜的。”

这又说明了什么？说明了有时候，不是客户说不清楚，而是程序猿自己理解错了，不信大家想一下，你能保证每次都能理解对客户的话吗？

好吧，既然情况如此，问题已经很清楚了，程序猿和客户不是不沟通，而不经常得不到有效的沟通。

为什么得不到有效的沟通呢？其实道理很简单，就是程序猿和客户理解的不一致，这是肯定的，两个不同的群体，有太多的东西理解起来是不一样，最简单的例子，正常人都是以1为开始数数，程序猿有时候就是以0开始数数的。再说，同一个群体的，也有可能想法不一致呢。

解决这个问题，也很简单，就是提供一个双方都能看得懂的沟通方式。最直接的方式，就是你把程序拿出来给客户看！

但是这绝对是扯蛋的，如果你都有现成的程序给客户看，你还做啥，不都做完了吗？所以，这不可能。

再就是做演示程序，这也是个方法，但是把所有功能，都做成演示版本？也不可能。

有一些项目经理，会只把界面写出来，给客户看，这也是一种办法，但是，只有界面，毕竟说明不了全部的问题。

接下来，就是最传统的画图了，但是这种方法在好多情况下被证明，是无法解决以上的问题的。因为既然有图，好多人也对同一个图产生许多不同的理解。

而且，最重要的是，一些图符号在不同的行业里，本身就代表着不同的意思，这就是为什么那些砖家搞不出合理的规范的一个原因，因为他们不懂公司的情况，也不懂业务，甚至不懂技术，更不知道这些符号在本行业中代表的意思，所以制定出来的规范，程序猿不能执行，不想执行，不愿执行。那么，如果我们制定的是规范，尽量不增加程序猿的负担，不增加程序猿的工作量，只给他们带来好处，他们愿意执行吗？肯定愿意呀，程序猿们虽然性格怪，但是都不傻！

其实，我给出的需求分析沟通的第一个招数就是签字。

我觉得大家应该能确定一件事：程序猿不可能故意把需求理解偏了（当然有偷懒的时候），客户更不可能故意不把问题说清楚（除非他就是想整你），但是，双方谈需求的时候，无法保证双方都足够重视这件事，所以签字，就是强迫大家重视这件事。

大家在谈项目的时候，做好签字工作呀，把大家理解的东西都以书面的形式写出来，由于要形成纸面上的内容，大家一般就不会乱说话了。

3.2 不负责任的签字
但是客户总是不签字。

说到这件事，程序猿一般只是强调客户不签字。但是从来不从自己身上找原因。

客户不签字，为什么不签字呢？要回答这个问题，先得看看程序猿是什么时候去找客户签字的，不用问，大多是项目验收出了问题，需求变化可能影响进度了，或者双方领导对当前的进度和演示效果不满意的时候，总之，一般是遇到问题的时候居多。那客户为什么签字，程序猿不傻，客户都傻吗？出了问题你找人家签字，责任全推到客户身上，别说原因不在客户，就是在，他会承认？

大家都不傻，所以，解决这个问题，最好的办法就是形成“规范”，这里提到的规范，不同于上面提到的砖家提出的规范，这里的规范就一条：每次到客户现场都带一张《现场记录单》，上面写清楚本次去干吗？客户意见。

说明一下：

1、这个的目的就是要客户形成习惯。有事，没事，全部带，如果只是去了看一下客户的办公环境也要带，只是给客户送个文件也要带。让客户认为，我们公司就是这么管理的，等达到哪次去了，没带单子，客户都觉得奇怪就说明生效了。这样，就是向客户表明，不是出了事在找责任人，而是每次我们公司都要求，这样，他提任何意见的时候都写在上面了，他至少提意见的时候会想一下。而程序猿也可以事后回去再慢慢理解，不会再出现包子和西瓜的笑话。

2、记录单的用途不是让客户不敢提意见，也不是让客户不能提意见，只是让客户提的意见写下来，让大家都清楚事件的变化，所以程序猿不要用“上次你说向东发展，这次怎么又向西。你签字的还在！”来和客户说事，程序猿只是把它们记录进记录单就行了，如果真发生客户反复改需求的事情，交给商务来处理。因为，程序猿又不知道项目是怎么签订的，也不知道双方的关系，即使有的知道了，但是你知道这个项目是否与其它项目有没有联系？所以程序猿是来做技术的，你踏实的做技术就行了，如果客户真的过份了，也不要在公开场合提这事，一块吃饭的时候，聊天的时候，表达出你的意思就行了。然后，再把事情和商务去谈，反正记录单上把前因后果都写清楚了。这些事情程序猿不要说太多，因为如果处理不好，客户要是对你有意见，想整你可有的是招儿。如果是商务谈，就方便多了，他们一般连客户吃没吃回扣他都知道。

3、记录单要留好，整理好。有哪些是提的意见的，哪些是打酱油的，哪些是夸你的，分类整理好，当然，最重要的还是客户提的意见和需求的变化。如果有相反的，比方上次说好用xp系统，做完了，又要win7系统，过几天又转回xp系统的，全放在一块。原件留在单位，上线的时候，带一份复印件过去，什么也别说，给客户放上一大叠提过的意见，他再提，就得更加谨慎了。

4、记录单上的记录一定要客观。不要在客户记录单上表达出任何观点。比方客户提出，要用自己的手机控制美国总统的空军一号，他如果真提你就记上就行了。不用在后面写上这个实现起来困难，更不要说这个需求太SB了。这些不是你的责任。你先记下来，SB不SB，大家心里清楚，客户的领导也清楚。

5、商务一开始就把这个制度和客户说清楚。商务说的时候，就说，我们程序开发过程很规范，有很规范的制度，绝对能保证开发进度。程序猿和客户说，这是公司的制度，主要是怕程序猿忘记每次出差的目的。总之，就是要告诉大家，我们的这个制度就是为了项目的推进。

如果按上面说的，一般情况下客户就会签字了，因为签字没有什么压力，而且，我们也没有拿这些去找他们麻烦。但是，既然他们没什么压力，只是提需求的时候会谨慎一些，但是还是会有好多需求变化呀。

3.3 你有万般变化，我有一定之规

在这里，我觉得有必要再说明一下，需求为什么会变？按上面说的，客户提需求已经很小心了，不会信口开河的提需求了，但是事实情况是，如果你的项目是演示性，论证性项目，可能还好，但是一旦是实用性项目，百分百是会发生需求变化的，影响需求的因素太多了，最其码软件一旦实用，就必须面对的是操作人员，操作人员的操作能力理解能力肯定是个变数，另外，操作人员面临的环境也是一个变数。还有就是行业中的一些特殊规则。我们既然知道砖家不可能比我们更了解开发，那么我们就要明白，我们不可能比各行各业的操作人员更了解行业规则。

最重要的是，我们肯定无法在短时间内把这些行业规则学清楚的，这样，需求，就一定会发生变化，让用户签字也只能是减少需求变化的一个方法，不可能完全避免，要知道，即使是客户签字，你做出来的东西，他根本用不了，你觉得他会验收吗？

所以，我们才需要做设计，提到设计，大家都会自然的想到著名的“四人帮”提出的设计模式，绝大多数的设计者都知道，并且利用其中的知识在进行设计，而设计模式出现的原因之一不就是因为考虑到需求的变化了吗？设计模式本来就是和敏捷开发相对的一个概念。

设计模式好多模式，就是考虑到以后会发生变化，提前留出接口。让大家在做完后，如果需求发生变化，不必修改原来的代码，就可以实现新的需求了。

举个例子来说，观察者模式，是把数据源和数据表现分开了，一开始，一个数据有一个表格的表现，有一个文本的表现。程序做好了，测试完了，如果客户提出，要增加一个三维表现，就只需要做一个三维的表现的模块，然后告诉数据源就可以了。不但原来的表格表现模块和文件表现模块的代码不需要修改。而且，原来的数据源代码也不需要修改。

有人会说，如果不使用它，也没有关系呀，只需要在数据源增加调用显示的地方。增加一行代码不就行了？没错，如果只是一处调用就完全没有问题，但是如果是多处调用呢？如果是多种方法调用呢？更重要的是，你修改了原来的代码，原来的测试已经做过了，还需要重头测试吗？你能确保这些吗？

道理如果真的是这样，那么，我们为什么不做设计呢？

同理，我们要先知道程序猿为什么不做设计，先回忆一下，我们当初学习软件工程的时候，上面怎么写的？软件是要先做设计，再做编码！没错，但是事实上，项目开始后不做设计直接上手写程序，是绝大部分程序猿的习惯！他们也知道这样不对，但是每次都能找到理由，“客户要求的工期太短了，又着急要东西！”，“需求总是变来变去的，没法写设计。”“……”但是真正原因呢？其实程序猿们摸着自己的良心问一下，有几个人能百分百确定，自己会做设计，能做设计！即使是能做设计，有几个愿意做设计？说白了，程序猿不做设计就是两个字：“笨”和“懒”。还能有什么？

先说“笨”，这个词用的其实不是很合适，我用这个词的主要目的是为了突出一下。这里笨的意思不是学不会，而是有些时候，有些程序猿还没达到该学这个的时候。

怎么说呢？程序猿是需要成长的，刚毕业的程序猿，能干活就不错了。尤其是国内现阶段的大学教育，我真的不相信每个程序猿一毕业就能很清楚的了解堆和栈的结构，线程和网络协议真正的内容。见的更多的是知道个select就觉得精通数据库了，能写个发送接收就说自己是网络开发高手了。操作过上百万条记录的数据库吗？知道TCP通讯包的格式吗？

就是这样，大多数连工作是啥样都不清楚，要他们做设计？

工作两三年，一般就有点意识了，因为这时，他们已经吃过亏了，需求总变来变去，好多代码重复的写。如果聪明一点儿的，有上进心一点的程序猿就会想一个问题：“怎么办？”但是，并不是每个程序猿都会这么想，因为每个人的情况和生活环境，以及生活方式不同。

想了怎么办呢？上网一查：设计模式、设计思想、构架、数据结构。答案很多，我说过，百度大婶知道的太多了。试一下吧。哪这么容易，如果真的这么容易，就不会有好多软件死在半路上了。

再来说说懒，其实这个意思太明显了，只是明显的表现出来的，不是一个方面，而是多个方面，第一种就是上面提到的，有些人意识到设计的重要性了，但是不想去学如何做设计。第二种是学了没学会，又不想去尝试着用。第三种是，学会了一些，但是觉得用起来太麻烦，所以就不用了。

我个人觉得，懒是人之常情，我也懒，明明A类直接调用B类一个接口就可以了，为什么还要增加个C类，来沟通呢。最重要的是，第一个写这些类的人就是多做了很多工作，只是方便以后而已，而以后还不知道是谁用，凭啥我“栽树”别人“乘凉”。如果再遇上个SB老板，觉得我做三天的工作，人家一天就能做完，我水平还不如他是吧？

所以，我一直觉得软件业分层是对的，每个好的团队，怎么也得有一个工作了十几年的程序猿吧，这个程序猿当然不能只是简单的工作了十几年而已，他必须真正了解设计（我就见过工作十几年，连个虚函数说不清楚的程序猿）。真正知道开发的真正意义，还必须在本行业里待过最少三年以上，这个我一定要解释一下，我记得原来面试的时候就见过一个做了十年软件开发的人，来我们公司找工作，和我说，我来是为了做构架，我问他，你知道我们公司是做啥的不？他说来的时候太着急，没看公司的网站。你连公司做什么都不知道，业务背景统统不知道，你说你来做构架，你做出来的东西能用吗？

第二种就是工作了三五年的，接下来才能是做了一两年，或者刚毕业的。有些老板喜欢用新毕业的，又能加班，又能出差，还听话，最重要的是便宜。当然，这不是说不行，得看你们公司是做什么，如果你们公司是外包，那完全没有问题，而且我建议你们工作五年以上的都不要考虑，招来，送出去就有钱挣。但是如果是自己有产品，就不一样了，如果是硬件产品，软件只是用来做个辅助，那要么用也只用网毕业的，或者毕业一两年的，要么最多需要一个三年的。

但是，如果你们就是软件公司，这种配置是必须的，如果暂时没有配置好开发人员，那就不要要求太多，毕竟，执行起来，确实是困难的。

人员配置齐了，你们的“架构师”需要做出一套，适合本行业大部分项目（大部分，全部项目是不可能的，跨行业也是有很大难度）的构架，构架的必须把常用的接口已经规定好了，如何扩展功能都写清楚了。

还有一个问题需要讲清楚，就是程序猿总是说做设计没有时间，而且，上面也说了，不是每个人都能做设计的，所以有一部分程序员项目一开始就着急写代码了，那么我想问的是：一开始就写代码，你没有不会的技术点吗？如果有，一部分人不会做设计，先做技术点不行吗？如果没有，你们不会让他先写几个工具类呀？

3.4 软件是由二级管和电阻电容组成的

项目来了，利用这个框架，再开发出需要的功能，就可以了。

听起来很简单，解释一下：

1、框架就是平时大家说的平台，平台一般包括了核心引擎，然后再制定好接口规范。打个比方来说，前几年MP3火的时候。好多厂家都做MP3，由于用的芯片是一样的，所以一开始大家就是把电池和按键等做好，再加个外壳就可以了，发展到后来，有一个厂家直接把芯片买来，把电池和按键等配件加好，形成一个个核心单元模块，直接卖给做MP3的厂家，这些厂家就是做成外壳，加个商标就可以了。在这里，播放芯片，就是引擎，电池和按键这些接口模块统一在一块，就叫平台。每种做好了，卖给用户的MP3，就可以称呼为项目。

2、扩展。通过上面的例子，我们可以清楚，平台不是做好模块，让大家形成接口，去互相调用，而是做好接口，自己去实现模块。例如，我们做一个MP3，如果所有都好了，做一个外壳就好了，如果觉得按键不好，换一种按键，只要按照平台要求的接口，做完就可以直接安装到MP3上，和播放芯片联动了。

3、前景。如果平台设计的合理，那么，我们不但很方便做出不同的MP3来，而且，在做了一段时间后，我们可以把不同的电池、按键、外壳任意变换，就可以形成不同的MP3，而不需要重新研发任何功能。

这么做好处多多呀：

1、如果框架设计好了，各个程序猿都可很明确自己的工作，及实现方式。大家协同分工，工作的效率可以大大提高。因为大家都是做的彼此独立的小模块，与其它人打交道的地方都很清楚。一个大的项目，真正意义的实现成多个小程序。一个人完成一个大程序可能性不大，但是

...全文