项目那点儿事儿

项目那点儿事儿

 

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

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

2、  在谈需求的时候，可以迅速把原来做过的各个模块集成起来，以一个整体程序去给客户演示。

3、  如果在谈需求的时候，遇到一个没有做过的需求，也可以很清楚的向客户展示清楚它是如何实现的。我们原来的模块有流程图，有结构图，给客户看一下。现在的模块也画出流程图来，做为参考，再给客户讲，就清楚太多了。至少双方应该很清楚你的图中实现的方式和各种图符号表示的意思。另外，每个小功能都分成小模块小程序了，那么客户也只需要说清楚本个功能就可以了，不需要去和你解释与其它模块的联系。

4、  如果做到一定项目的量后，有一些项目就可以迅速的开发出来，开发完后，基本上可以不用测试。就可以直接上线了。

5、  每个程序猿做的事情是一定，分工合作的模式越来越明显。一个程序猿在武汉，另一个在南京，项目经理在北京，一样可以把手上的工作做完。

 

3.5    照进现实的理想

 

想象是美好的，但是现实是残酷的，因为：

1、  公司有这种能力的人吗？并不是所有人都有这种能力，而且这种人一般是需要老板自己发现，因为你不可能找一个工作了三年的人去面试，帮公司找出一个具有以上水平的人来。但是老板或者总经理一般不一定是做技术的。

2、  有这种能力的人，条件允许他利用一定时间，去完成这种完全看不到的东西吗？这些东西在初始的时候，有可能不但花费大量人力物力，而且本身不创造什么价值。有几个老板肯定这么做呢？

3、  我们说过，平台框架不可能适合每一个行业，因为如果为了一些功能的快速集成，就有可能把一个方便扩展的技术舍弃掉（打个比方，游戏行业做三维平台，一般不考虑多窗口的显示，但是房地产业可能就是需要的。你如果在游戏行业做平台，你完全不需要考虑多个窗口同时显示的情况，也不会为了以后如何扩展窗口而写太多代码），这些舍弃的技术十分有可能，在一些特定的项目中被客户提出来。框架有无法实现，或者实现起来比较困难的情况，程序猿们怎么看。老板怎么看？

4、  程序猿使用的过程中，毕竟增加了一些限制，他们接受吗？

 

所以，又有一些问题需要解决。

 

解决这种问题，是需要一个公司共同的努力得来的。但是，每个人努力的方向不同。

 

而如果一旦没有办法解决以上的问题，我建议也一定要尽量做到以下几点：

1、  简单的设计一定要做，时间再紧，也要做设计，理一下思路，考虑一下扩展。挺好。不要以时间为理由不做设计。因为你无法控制整个项目是按你的思路发展的。

2、  根据各个行业的不同，一定要想出一个办法和客户沟通。做界面也好，做演示也好，不能以麻烦为理由就少做需求沟通或者不做。

3、  一定要把所有工作，全部以时间点的形式通知到领导，通知到客户，因为，领导不一定懂技术，客户也可能不懂技术，他们可能认为，做软件就是写几行代码就行了。

 

 

最后，还有一条要强调：真正看清楚自己。

这一条最难做到，因为我一直在强调，项目本身有着太多的变化，受太多因素的制约。有时候，项目做的很烂，几乎随便点几个按钮就死机，也能验收。有时候，软件做的很好，客户工作人员用了两年了，还没验收。这些情况我都经历过。

但是当遇到这种情况的时候，你真的能本着客观的态度去看待吗？你真的不会和领导说“我上一个项目就是这么结的！”你真的会把这个项目的整个过程中遇到的困难客观的记录下来，然后形成后面的人的经验吗？我自己也是程序猿，也有着程序猿的虚荣心，我自己就做不到。

不但程序猿做不到，领导们也很少能做到，“上一个项目结了呀，为什么这个就是结不了”。

但是，从我这么多年的工作来看，上面的工作做了，比不做这些，平均起来会容易。

 

小结：对于需求分析，我们尽量要找到一种能与客户沟通的方式，然后，在开发过程中，首先尽量想办法不让客户随意变动需求，但是必须要变的话，我们还必须提供一种方便变化的机制。

4      治人不治，反其智

4.1    搬砖的程序员

我们再来说一说人员流动。

其实，每个行业都会有人员流动，据我实际观察，相对于售货员和搬砖的小工，程序员还是比较稳定的。但是为什么还是每个项目经理提到程序员的流动，总是咬牙切齿呢？

其实，我相信大家都知道，如果招个搬砖的小工，只需要简单几分钟告诉他，就可以上手干活了。但是招个程序员呢？产品核心、平台、框架、项目背景、客户……全部告诉一个老遍，花了一个月，最后，没准程序员还会告诉你，对不起，我觉得不合适，离职了。

这才是最让项目经理头疼的。

既然如此，我们就先想想如何解决这个表面问题吧。

从上面所说，我们害怕程序员流动，主要还是怕花在对程序员的入职培训上，就像上面所说的，我们不可能像招搬砖小工一样招程序员来用。

也就是说，如果我们可以用培训搬砖的方法来要求程序员，大家对上面的担心就少多了。

那我们来看看培训程序员大多是如何培训的。

前一星期，大多是给一堆项目相关文档、代码，让程序员看，然后指定一个“老程序员”来指导这个新来的。

第二星期，新程序员与老程序员相互交流。了解项目的相关情况。

第三星期，程序员可能面临去客户处了解需求。

第三四星期中间，程序员虽然已经开始干活，但是，经常会犯一些常见的错误。不得不总有一个老程序员跟在身后指点。

如果上面所说顺利，程序员也适应了公司的环境，谢天谢地，项目经理赶紧去老板哪夸一下自己慧眼识人吧，再顺便说说人事很给力，招到了这么合适的人，如果不顺利，培训和适应的时间就要增加到两个月，甚至试用期没过，就走人了。

既然提到不顺，我们看看哪里不顺利吧。

第一星期看文档、代码。项目经理为了节省自己的时间（因为他可能还在忙项目），直接给了程序员全部的文档、代码。然后就基本上不管了，而指定来指导这个新程序员的老程序员呢，也有自己的活，不可能花太多时间去指导新程序员，但是，我们也知道，在中国的教育体制下培养出来的孩子有几个自学能力强的？遇到问题怎么办？遇到问题不敢问怎么办？遇到问题总问人家烦了怎么办？指导的老程序员与新程序沟通有问题怎么办？

第二星期，新程序员与老程序员交流，全身心的交流？老程序员的活不干了？讲什么？是否讲的够用了？技术上新程序员和老程序员思想不一致怎么办？

第三星期，去客户哪，去了客户哪，客户的脾气，性格是否已经熟悉？客户有什么忌讳？客户所在地方好找吗？如果出差，出差手续办理流程谁教？

这些如果都没有问题，如果这时候程序员自己不想干了，走了怎么办？不走上手干活，干的活符合接口规范？符合编码规范？能看懂文档吗？会写文档吗？

问题又是一堆，怎么办呢？写文档吧。

有人笑了，上面一堆文档还没看完呢，你又让写文档，搞笑吧。非也非也，此文档非彼文档，这里说的文档是经验文档。和上面说的流程规范差不多。

又是规范？没错，又是规范，不过说清楚，和上面一样，不是砖家规范，而是程序员可以自己看懂的规范。

这种规范，其实就是人事部门搞的流程规范，人事部门一般流程都很“规范”，入职后先填什么表，交什么材料，什么签名，什么时候按手印都规定的比较清楚。那为什么程序员不能这么干呢？

你带第一个人的时候，和客户开会，写个会议记录可以吗？你给你程序员讲东西，写个培训记录可以吗？你帮他解决了技术点，或者他自己解决了技术点，写个问题记录可以吗？你给他们讲概要设计，讲的过程中，好多人会问题问题，整理一下形成文档可以吗？

这些记录文档全部整理好，分类放好，再来个新人，先看这些文档，总比直接看概要设计看代码不强多了？看完这些，再讲，至少时间上提高不少，如果在讲的过程中，遇到新问题，再次整理，这样，你培训新人的时间会越来越少（记住是少，不会没有的）。

想象一下，如果每个人来了都要找一个人培训，那么，他不但占用自己的时间，还要占用培训他的那个老程序员的时间，按上面说的，每来一个新人，培训时间就是2个人/月，如果来十个呢？

但是如果上面规范做的好，培训时间就算减少不了一半，也能减少三分之一。

其实项目经理和程序员不愿意这么做还有一个原因，如果真的这么做了，每个人都很容易被替代，那老板找个人把我替了怎么办？

说到这里，我想到一个真实的笑话：去年年底在网上看新闻，说有某汽车公司年底发了36个月的工资做为年级奖金，大家羡慕不已，突然有一个同事说：“这个公司老板真不会办事，一下子发36个月的钱，不怕员工跑了吗？”屋里先是静了一会，然后大家都笑了。员工跑了，你们公司年底发36个月的工资，你跑吗？你跑吧，你跑前告诉我，我去！

道理一样，你做的很优秀，老板找人替了你，行呀，那赶紧走吧，这么傻B的老板，也成不了什么大事。

4.2    二十一世纪不但缺人才，而且还缺人

好了，既然我们的程序员现在已经很容易的替换了，那就可以放松了，都走吧！谁爱走谁走，大不了从头开始再重新招人！

如果是这样，恭喜你，你的项目马上就跨了，为什么呢？因为程序员虽然可以像上面说的很容易替换了，但是别忘了，你在中国，中国人思想是最复杂的，容易替换是只是招来了人员后，替代起来方便一些，但是，程序员“不是你想买，想买就能买！”，招人，还是很复杂的。另外，真的要摆出一种上面的描述的态度，那没走的也估计马上就走了。

最重要的是，程序员都是比较敏感的，如果原来项目组十个人，半年之内走了五个，一个没招上来，他会怎么想？

4.3    仓廪实而知礼节

好吧，我们看看程序员为什么要走？

说到这里我突然想起网上一篇有关西游记的文章：话说唐僧师徒四人去西天取经，大家发现猪八戒同志是最差的，为什么呢，因为一遇到困难这个家伙就要跑，咱们回老家吧，别去西天了，太危险了！再说，我们是偷渡出来的，万一被抓了，回去没准要剥夺政治权利终身………当然，猪八戒同志也不一定知道他自己在说啥，只是证明，他对取经这件事，忠诚度最低。但为什么别人不闹呢，分析一下，得出结论，唐僧是如来的二徒弟，他命中注定是要去取经的，如果不取经，他就只是一个长安的大学教授，但是如果他一旦取经回来，他就是名传千古的教育家、思想家、中国佛学创始人、砖家…….所以他没问题，因为他对他的事业忠诚，孙大圣呢？他也没问题，他本来被人压在五行山下，是唐僧救他于水火之中，所以，只要唐僧要去西天取经，他就跟着去，即他是对唐僧（他的领导）忠诚，沙和尚呢？沙和尚其实就是一个管后勤的，他虽然也当过什么大将，但是还是一个小角色，平时也只能带着一群当兵的训练，还因为摔了个灯泡就把工作丢了，但是，在取经的时候，他的师父是金婵子，大哥是齐天大圣，二哥是天蓬元帅，上哪找这么好的团队去呀，四个人就能把一个皮包公司忽悠上市，所以他也没问题，因为他是对团队忠诚。好了，既然如此，我们看看猪八戒吧，猪八戒是人家新婚不久，小两口闹点矛盾，你们就把人家抓来了，给的还不是工资，给的是股份，天天出差，那谁干呀？有问题，赶紧回去吧，老婆孩子热坑头，有什么不好的，高老庄还有几亩薄田，够吃够喝了。所以猪八戒总是闹情绪，一出问题就赶紧12306定票！

分析完这些，项目经理们说说吧，你们手下的人同志们，有几个孙悟空，有几个沙和尚，有几个猪八戒呢？

我估计没有几个孙悟空吧，沙和尚有就不错了。所以说，为了我们的取经大业，我们得想办法让手下的猪八戒们踏实的跟我们去取经。

其实，现今社会，生活压力很大，程序员流动最大的原因就是工资，不信，你试试，如果竞争对手公司有一个程序员工资是八千，你给他一万六，你看他过来不？

但是一个公司发展，肯定不可能满足所有人的工资，这时候就是考验项目经理的时候了，经常听到有人抱怨：“老板总是舍不得出工资”，“人手总是不够”。“看到合适的，经常没办法招进来。”“……”说对了，想想项目的一个特性：项目受到预算、时间和资源的限制！没错，我工作了十五六年了，好像还没有遇到过要什么给什么的老板，也没遇到过要什么有什么的项目。

要知道，员工挣的工资都是老板出的，人之常情也是你拿的少了，老板就拿的多了。你是老板你也会尽量减少劳动成本的。所以，我们就要想清楚，你的团队中，哪些人是骨干，哪些人是过路的，哪些人是最好不要走的，哪些人是走不走都没有关系的。

判断好了之后，就把一定要保证骨干的工资水平，不要低于平均，这一点很重要。

有些人觉得自己会和唐僧一样有“人格魅力”，手下员工会像孙猴子一样对自己死心踏地，有这种想法是对的，但是切记不要当真！

管仲在几千年前就知道“仓廪实而知礼节”，我相信现在这个社会没有几个人比管仲更NB一些吧，尤其，现在的社会上，越来越少的人选择“舍生取义”的情况下，别幻想着有人会听你三寸不烂之舌，或者受你“滴水之恩”就工资减半的跟着你干！孙大圣之所以跟着唐僧大师，那是人家救了他的命。

所以说，大家都是先解决了温饱问题才谈理想道德的，他跟着你干项目，肯定先得是为了生活，如果你不能保证他的生活，或者别人能给他的生活水平比你高一个档次，基本上没有人会选择继续留在这里，就算有，也极少极少，找一个这样的人，估计比中五百万彩票的机率只高不低。如果他自己生活水平已经很高了，要吃有吃，要喝有喝，住着房躺着地，他会来你这？

所以说，骨干的工资一定要保证住，其它就看你的实际情况了，如果行业和老板好，你就可以把大家的工资水平维持住，如果不行，你可以稍低一些，但是太低还是不行的。

4.4    精神文明建设很重要

工资差不多了，程序员还是会走呀，毕竟，你对我也不可能有救命之恩，工资也不是很高，那我在哪干不干呀。

这时候就要说到另一个问题：洗脑！

别紧张，我们不是传销，这里的洗脑，不是说你要告诉程序员他要做什么，而是你要真的为程序员做些什么。

首先，你不能把自己当领导。这一点很重要。只是好多人想不到，包括一些小公司的老板，甚至开公司的目的就是为了权力大，原来受老板的气，现在自己干，我也是领导了，好了，张三今天帮我倒水，李四明天帮我买早点。当然没有几个人这么夸张，只是想清楚，你真的是领导吗？千万不要听欧美的一些什么讲座，不要想什么用其它的方法，想想共产党为什么能带领导人民建立新中国就成了，共产党的干部有几个上过学的，没有，只会一条，大家都是兄弟，有饭一块吃，有活一块干，上战场带头冲锋。你像国军一样，自己坐在司令部里，让手下的人去拼命，回来还得向你点头哈腰，可能吗？最重要的是，现在的程序员都是80后90后，从小就是被父母捧着长大的，受得了这个？招个人不容易，没必要因为这个搞几个。

其次，项目组要有一个轻松的气氛。程序员是一个很压抑的群体，因为程序员的前辈们都是黑灯半夜干活的，不然怎么把程序员里最NB的都叫“黑客”，所以，没点孤僻症，你好意思当程序员？既然如此，程序员的世界你永远不懂！既然如此，你就不要对程序员管的太多，比如，他们上班时间聊会天，上班时间出去抽支烟，我一般不建议管这些，因为有时候技术点解决不了，他们坐在电脑旁边老老实实也不出活。但是我不建议程序员上班时间太随便，因为，毕竟项目不是一个人干，有时候还需要和别人交流，你今天早上八点到晚上五点上班，他晚上八点到第二天早上七点上班，这两个程序连个面都不见，还怎么合作？

第三，学会夸奖程序员。在这里我只说一件事，我第一次先做设计后开发的时候，我的师父在技术例会上表扬了我，其实，我以前也经常不做设计就开始写代码的，他从来没有因为我不写设计直接写代码批评过我，但是他那次夸奖过我了后，我开始喜欢上了做设计。

第四，千万不要骂人，训人。我个人年轻的时候（毕竟，已经而立好几年了）经常控制不住自己的脾气，但是后来发现，发脾气的原因大多最终归于自己没能力，不是吗？有能力你为什么不把他教好，有能力你为什么招个这么没能力的人来？“给他讲了一百次了，还没听懂！”好多人说这话的时候，忘记了一点，给人讲东西，有两个主体，一个是你，一个是他，他没听懂，最多有一半是因为他笨，他理解不了，另一半以上的原因是你没讲清楚，不是吗？记得有一次爱因斯坦在一个大学里讲广义相对论，一位老妈妈来接自己的博士研究生女儿，他等爱因斯坦讲完课，问爱因斯坦：“听说你讲的是相对论，啥是相对论呀？”爱因斯坦想了想问她：“你在这等了多长时间了？”老妈妈说：“等了半个小时了。”爱因斯坦：“你觉得你等的时候长吗？”老妈妈：“长呀！”爱因斯坦又问：“你应该是接女儿回去过周末吧？”老妈妈说：“对呀。”爱因斯坦：“这次女儿回家住几天？”老妈妈：“就住两天！”爱因斯坦：“你觉得两天时间短吗？”老妈妈：“太短了。”爱因斯坦说：“好了，你现在明白相对论了吧？”老妈妈说：“爱因斯坦先生，看来他们把诺贝尔资金发给你是对的。”人家爱因斯坦都能把相对论和一个普通的老人讲清楚，你解释个观察者模式，解释个模板接口，讲了一百次都没有给你的同事解释清楚，是谁的原因？

第五，不要破坏团队的气氛。这一条你懂的，不解释！

4.5    授之以鱼，不如授之以渔

如果你带项目的时候，你的程序员工资问题都解决了，大家工作气氛也很轻松，基本就比较稳定了，但是还是会有人走的。因为这里还少了一样：成长！

怎么说呢？人往高处走，水往低处流，没有人愿意一辈子当码农的，甚至程序员这个title都是比较让人不爽的title。大家都希望自己“出人头地”，都想每天都有成就感。

毕竟，在北京新毕业的大学生（我只在北京工作过，相信其它地方的程序员大同小异），基本上不可能爱一行干一行，因为生活压力还是太大了，所以，我们就要让程序员干一行爱一行。

程序员行业还是容易成功的，因为程序员们不是每天在搬砖、活泥，而是每天都在做一些创造性的事情。

既然如此，项目经理应该在制定计划的时候，多给程序员设定一些“里程牌”，多找出一些“技术点”，多增加一些培训，多给他一些真正指点。

多设计一些里程牌很容易，只要你按我上面说的，把设计做好了，而不是让程序员自己去堆代码，很容易实现，因为大系统不可能短时间做出来，但是小模块是很容易实现的。

多找出一些技术点和上面类似，在技术可行性分析的时候，项目经理找出一些技术点让程序员去实验，这时候，最好让他们把实验成功的技术点封装好，方便以后调用。程序员有一个特点，特别希望别人用自己的“工具类”，双特别不喜欢用别的人工具类，如果你能把工具类抽象出来，找个程序员去实现，相信，他会特别高兴的。

多增加培训就不用说了，不用担心时间，如果项目开发周期紧张，直接把培训安排在周末都可以，如果你的培训是他想听的，他怎么都会抽出时间来的，不信，你把亚当斯（知道borlandC++吧？知道delphi吧？知道VJ++6.0吧？知道.Net吧？全是他设计开发的）请来做讲座，我估计我都可以把婚礼推迟。前提是真正能学到东西。

至于最后一项才是最有用的：真正的指点，其实这也是最考验一个项目经理，因为在中国，我们一般不太能愿意一个比自己还小的人去管理我们，所以在中国项目经理是最累的，因为他们经常是“项目经理+系统分析师”二合一的一种结合产物（我真的没见过一个公司招一群新毕业一两年的程序员就能干出什么大系统来的），既然，你是项目经理，你肯定比他们经验和技术都好一些。那么你就多和他们讲一些技术发展，讲一些技术点，讲一些设计开发思想，当然，最重要的是，你要多讲一些你的思想和思路上的变化。

不要担心程序员成长了会把你替换掉，“教会徒弟，饿死师父”是旧社会的事，现在，大多数产业都是在阳光产业，工作机会多的是。再说，你如果没有把你带的程序员培养起来，你的老板怎么把你的提到一个更高的位置上（他把你提起来后，没人能接得了你的工作，你还不是得兼着，能舒服的升职吗？）如果说，你们老板真的等你把徒弟培养出来了，然后把你开掉，那你就是必须走的，你们老板肯定没有大的梦想，你们公司也不可能成为什么大公司，如果遇到这种老板，你别等他赶你，自己先走吧。

 

小结：对于团队，我们尽量让团队的人有成就感，可以拿到一份适合自己的收入，愉快的工作，如果真的出现特殊情况，我们必须有一定规范把人员替换引起的损失降到最低。

5      不会沟通的人，就不会休息

5.1    一年之计在于晨

程序员们想一下，你们出过差吗？

如果不是只在一些特定的行业里待的程序员，好像回答都是肯定的，甚至有些人在回答完后还会加上一堆关于出差的评论“干挨踢的，能不出差？”“烦死了，刚出差完。”

如果你再问问他们出差的感受，一般是两种结果：项目经理或者负责人一般都特别不喜欢出差，普通的程序员外向的喜欢出差，内向的不喜欢出差。

我得出的结论不一定是对的，但是绝大多数人肯定是这样的。

为什么负责人一般不喜欢出差呢？听听他们自己的说法吧。“去了半天，没人接待，有人接待了，时间已经拖了很长了。”“去了之后附近的宾馆满了，我们只能在很远的地方租宾馆，单位的出差住宿费定的太低了。”“去了老找不到人，相当于在现场开发，人总是来看看就不管了，老板还总催着回来。”“我们在现场累死累活干了半个月，老板还总怀疑我们出去玩了。”“……”

这些问题看起来，都不是我们自己造成的，但是，就是你自己造成的！

“去了很长时间没人接待”：你去之前和客户沟通过吗？是电话说的，还是邮件短信说的？说清楚了吗？去的时间，目的大家都会通知，但是每天的日程你做计划了吗？做完后和客户沟通过了吗？如果他需要联系其它部门，他有通知吗？他有权力调动不？所以沟通的第一个要点是，你要把你的想法用邮件或者书面形式提交给客户，让他心里有数，而且，还要和他确认完再去出差，客户可能还有别的事，可能还会开会，可能客户单位会组织出去玩，可能客户单位会开职工大会，这些都会影响你出差计划，你真的知道吗？

“去了之后附近的宾馆满了！”这一点我就遇到过，我原来带一个小孩，他每次出差都在住宿和有麻烦，经常去了之后客户附近的宾馆都住满了，但是我出差的时候，就没有遇到过，后来打听了一下，他经常月底去那个客户处出差，而客户单位是个科研单位，每个月底都会有一批学生来实习。这个故事本身没有什么，只是说清楚，你是项目经理，项目的事你必须从头到尾都要了解，所有与本项目相关的事都要考虑清楚。项目经理是很累的，不过，真正做好项目管理工作后，你就NB大了，因为通往CEO的三条大路分别：市场经理、财务经理和项目经理。做技术的人里，离CEO最近的就是项目经理了。

“老板总怀疑我们出去玩了。”这一条就更是你自己的责任了。你的计划写好了吗？每天都按计划执行了吗？执行的情况向领导汇报了吗？等出了问题再向老板汇报？那你还怪谁？怀疑你出去玩了，废话，多疑点的老板都可能怀疑你回老家了或者去找新工作了。

所以，第一步，计划一定要认真写。第二步，计划一定要与老板和客户商量好。第三步一定要按计划执行。第四步，一旦发现可能遇到问题。第五步，汇报问题的时候一定要想好解决办法和建议一块汇报上去。最后一点最重要，别找理由，肯定有办法的，就算很蹩脚的办法也行，办法总比问题多的，关键是你要想。我们可能都知道唐俊，大多数人都说他是打工皇帝，大家要知道，他刚进微软的时候，也是一个普通的小职员，当时微软满是问题，所有人都在向领导提问题。唐俊也在提，只是他和其他人不一样，他在提出的每一个问题后面都加上了自己的意见。最后，一路提升，一直做到了微软的中国地区的总裁，但是，据他个人说，他提上去的意见，大多数是没有被采讷，但是他为什么被提起来呢？大家应该能想明白的。

5.2    擒贼擒王

记得我原来一个同事有一次出差回来，和我兴奋的说，“这次项目太NB了，我们做了三个版本：总工版本、主任版本、操作版本……他们谁来了，我们用谁的版本，这下这个项目肯定能结！”我听完笑了笑，心想这个项目结项很困难。果然，他们最后去验收的时候被扣在现场半个多月，还是老板请客协调才回来的，回来后又花了半个月修改才进行了的验收。

听到这里好多人不理解，已经很为客户着想了呀！怎么会呢？

还记得项目的特性其中有一条是以客户为中心吗？对了，客户是中心，但是如果有多个中心，你还能做事情吗？上面提到的总工版本、主任版本、操作版本确实是解决了总工、主任和技术人员在现场的矛盾，但是验收时谁说了算呢？如果验收结果是大家共同决定的，那无论哪个版本都肯定有2/3左右的客户不认可。2/3的客户都不同意，你能验收？

其实我一直建议，无论哪个项目，我们都要在一开始和客户协商好，对方的负责人是谁？一旦定了对方的责任人，我们就可以所有都听他的就可以了，如果他们内部有不同意见，让他们自己去处理，处理完后，再统一把意见给我们，也就是说，我们只对这个负责人负责，其它人提意见的时候，都告诉对方，请把意见转发给你们的负责人。

有些程序员觉得自己很有能力，总想着试图去帮客户平衡客户内部的关系，没用！有些客户连领导的话都不听，你觉得你能协调？

但是记着，这个负责人一定要选好，当然，不是你选，但是你可以建议！或者你可以了解，他在客户公司的职务，在客户公司的威望，在客户公司多长时间了。包括这个负责人的性格都是项目经理必须去了解的。

当然，如果客户选好了，不能换了。

你就要针对以上你调查的背景，提前想好一些应对措施。

如果客户负责人是一个小职员，没有什么权力，那你在做任何决定后，都要和他沟通清楚，然后由他再去汇报。而且，一定要让他有机会表现自己。要知道，他在领导面前越有好的表现，他的权力越大，他才有能力对项目做一些有利的帮助。

当然，我不想在这里多说什么，有什么细节，问百度大婶吧。总之，我想说清楚的是，不要让客户有多个中心！

5.3    负责任的签字

大家都知道，培训是最难的，经常培训好几回，客户还是反应不会用。我们还是分析一下为什么培训达不到效果。

首先，我们的培训对象是谁？客户？废话！

我们的培训对象是客户找到将来可能会使用或者可能会涉及到我们提交软件的人。那么这些人水平怎么样？我觉得水平肯定不会太差！因为客户无论是否懂电脑，都不可能找个白吃来干活。而现在，七八岁的孩子都能把电脑玩的滚瓜烂顺，又有几个人连电脑都不会用。会用电脑，操作你们做的软件，不会操作？

那为什么经常出现培训了四五次，客户还是反应不用会呢？

当然，我们不排除有些程序猿做出软件就是不好用，但是在我十几年的挨踢生涯中，我觉得这种软件还是比较少的。

那么我们就要仔细想想为什么了。

我们先看看来培训的是什么人吧。一般一个系统培训，在用户单位来的不外乎是三种人，一种是想学东西的，第二种就是被领导看中，抓壮丁来的。第三种是来混出勤，还有一种就是不识数的。想学东西的人就不用说了，你培训的再烂，他们都能学会的，这是我的经验，但是这种人比较少。记得我在国家气象局做项目的时候，有个同志都以介绍对象为诱惑，让我教他怎么操作软件。

第二种就不好说了，被领导看中，觉得他需要学，但是他不一定想学。更可怕的是，如果是一些企事业单位，好多人多一各不如少一事，所以从心里是抵触学习，这种不好对付。

第三种最麻烦，他就是来当混出勤的，他来了大多时候就是在看小说，玩游戏，打电话。你教了什么他不知道，你教没教他都不管。

那么，我们怎么办呢？

我的办法就是考试！

听起来我好像和神经病一样了。人家连你的讲座都不想听，你还要考试。但是，你仔细想想，

如果考试了，他是不是就签字了？如果考试了，他都能答的很好，是不是就证明他学会了？

但是这里还有一个问题，如果你能想到这些，客户就不能想到吗？如果他们想到了，很抵触这件事怎么办呢？

其实，还是要先考虑清楚，客户为什么不学？

如果学了就要用，那能不学就不学呀，别说客户没什么远大理想，你想想如果让你学如何使用联合收割机收割庄稼你学不学？

你也不会学是吧，那么更不要说那些来混时间的了。

其实，这也是考验项目经理的一个最重要的一点，你首先必须把考试这事提前说清楚，还要给考试结果提供一些奖品（奖品要有点诱惑力，记住，如果你验收不了，花的钱可能比买奖品多多了）。还要和客户领导说清楚，让他了解你是为了让大家更好的学习使用新系统。最后，也是最重要的，你要把自己的系统使用在每次和客户沟通时说清楚，把它带来的好处说清楚，还有最重要的一点，你一定时时去了解，客户中哪些人对这些感兴趣，哪些对这个项目十分反感。了解的越多，你将来选择培训和考试的时候，就越能得心应手。

 

小结：对于沟通，一定多站在对方角度上去考虑问题。多用对方能接受的方式去交流。