>

项目那点儿事儿

- 编辑:555彩票 -

项目那点儿事儿

项目那点儿事儿

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

 

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

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

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

1       开头就是个错,结尾还是错

春夜京都雨,

孤灯伴夜深。

妙得千百字,

写尽程序人。

 

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

 

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

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

 

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

 

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

 

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

 

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

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

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

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

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

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

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

 

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

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

2       怎么了?为什么?怎么办?

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

 

问题1:“客户需求老是变来变去!”

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

 

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

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

 

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

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

 

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

 

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

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

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

 

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

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

 

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

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

 

好了,又一堆问题是吧?继续百度。

还有吗?没有了就做吧,遇到了,继续百度。

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

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

 

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

 

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

 

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

 

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

 

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

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

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

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

 

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

 

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

3       需求分析猛于虎

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

3.1    人有人言,猿有猿语

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

 

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

 

笑了吗?我就没笑,它本来就不好笑。

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

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的老板,也成不了什么大事。

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

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

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

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

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

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

4.3    仓廪实而知礼节

好吧,我们看看程序员为什么要走?

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

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

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

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

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

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

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

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

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

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

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

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

4.4    精神文明建设很重要

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

这时候就要说到另一个问题:洗脑!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

5.1    一年之计在于晨

程序员们想一下,你们出过差吗?

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

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

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

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

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

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

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

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

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

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

5.2    擒贼擒王

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

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

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

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

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

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

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

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

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

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

让我们来分析分析吧。

5.3    负责任的签字

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

首先,我们的培训对象是谁?客户?废话!

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

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

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

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

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

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

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

那么,我们怎么办呢?

我的办法就是考试!

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

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

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

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

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

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

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

 

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

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

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

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

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

程序员就是自我管理自己的任务、自己的进度、自己的质量,如果非要有人逼着提交文档,程序员还得自己写设计文档和帮助文档。软件因为没有说明文档,也没有专门培训的人,实施人员、服务支持人员、销售人员谁也不会用,只能程序员自己去实施,有了问题自己去接客服电话。再说了,软件不稳定,其他部门的人都拒绝实施,谁想让客户劈头盖脸地骂啊。软件不稳定,老出问题,客服人员还不知道怎么解决,烦得要死,客服工资还低,推责任也得把问题推给开发部,只能程序员去做技术支持。这么多压力都给了程序员,还需求不断,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天才能搞定。当然,业务开发组组长也不是吃素的。业务开发组组长也是做开发出身的,到底难度有多大心里有数。而且业务功能就是业务开发组组长设计的,如何实现,会遇到什么难点,自己一清二楚。而且天天管这帮开发人员,谁能力高谁能力低,谁想偷懒,天天在一个办公室,谁不知道谁呀。所以,每个任务所需的时间,都会是业务开发组长在开发人员自己预估的时间基础之上进行调整,获得一个开发人员和业务开发组组长都能接受的任务时间段。然后根据每天的进度报告来随时调整这个时间,让开发进度尽量都能现实,而不是计划定好了就不能改。

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

本文由搞笑发布,转载请注明来源:项目那点儿事儿