十年总结（15）：产品化－有心杀敌，无力回天

houzeal

－－－

上一篇最后提到英语，英语对做技术的还是挺重要的，至少我觉得阅读很重要。
今年新来的三个毕业生，一参加工作我就要求他们看官方的文档，
一个是Maven＋Sonar，
一个是Struts，
一个是Rrdtool＋JRobin，

到今天一个月，已经有两位同志反映：英语文档也没有想象的那么难，
所以，的确没那么难。

－－－

2005年初，我与女朋友已经在一起度过了9个寒暑，03年买的房子，也在04年底装修完毕入住了，漂泊多年，终于有了家的感觉。
于是05年1月份，我们结婚了，不过在一起这么多年，结婚真的就是一种形式。

但2005年是我到目前为止，职业生涯中最最郁闷的一年，自信心不断的遭受打击，在强烈的自我怀疑中进行反思和改造。

2004年，公司确立的产品化目标，要将监控系统做成一个通用产品，
做代理（买国外公司的产品），毕竟是给别人做嫁衣裳，不值，不爽，
有自己的产品，就有核心竞争力，这是很多公司的梦想，只不过，梦醒才知是美梦还是噩梦。

我在华为的同学说：华为可以支持两百人的团队做研究两年，哪怕没有结果，小公司行吗？
不行，别说两百人，能够养两个做研究的人也很难，所以这是小公司做产品的软肋。

我年轻，我的老板其实也年轻，大家都是没有经验的，
2003年，公司在报表产品代理上挣了几百万，于是感觉前途一片光明，有了做产品的雄心壮志，
2004年，不断扩大的研发队伍很快将利润消耗一空，不甘心，
2005年上半年，为了扩大再生产，老板四处去找风投，可风投哪有那么容易拿到，没办法，只能收缩队伍，以战养战。

产品没做好，我心里也很难受，毕竟自己从头参与的，
做出来的东西，无论现在是强是弱，毕竟自己倾注心血，就像自己的孩子一样，有感情，
在公司里，经常觉得很压抑，
一方面，有些辜负了老板信任的那种感觉，
而另一方面，内心深处，却是不断的怀疑与自我批判。

以前只关心技术，工作很单纯，心性也很纯，只要想着只要努力，就能够把事情做好。
然而到这一年，很多人看形式不好离开了，公司也要削减开支，
于是越来越多的担子落到我肩上，越来越多的事情要我来决策，
因为产品研发进展的不太顺利，我开始不断的问自己：
我的能力有问题吗？
我的问题还是团队的问题？
团队的问题还是公司的问题？
公司的问题还是方向的问题？
很多问题想来想去，并没有一个所谓的正确答案。

老板虽然缩减了开支，但一直声明要坚持，我也就没有轻言放弃，中间也有过很多机会，都被我一一推掉了，
为了这有些傻傻的坚持，跟老婆讨论了很多次，也吵过好多次，
她认为良禽应择木而栖，君子不立于危墙之下，
而我是那种受人滴水之恩，当涌泉相报，宁人负我，我不负人的性格。
（05年房价已经涨不少，如果我等毕业后再攒钱，买房的时间应该在06年以后了，房价高了几倍，所以我一只有感恩的心）

最终，我对老婆说：
我对工作的坚持，和我对你的坚持是一样的，就是这样的性格，造就了我对工作的态度，同时也造就了对感情的态度。
我说的有道理吗？
有狡辩的嫌疑吗？

总之，我们的感情没有受到太大的影响，毕竟有扎实的基础，而且我们的生活也还过得去，
眼下没希望，于是老婆开始憧憬我给她描绘的美好未来，公司上市，挣大钱，或者在这个方向上成为专家。

而实际上，虽然我很乐观，一直很乐观，但当时的情形，我也非常清楚，公司上市是100％的妄想。
随着时间的流逝，到2005年下半年的时候，我逐渐失去了耐心，
让我烦躁的不是繁重的开发任务，而是公司在理想与现实间的心口不一，
公司每次开会都强调做产品的重要性，而日常工作又把打单放在第一位，
开发团队经常是疲于应付用户的演示需求，注意是“演示”需求，而不是“项目”需求。

销售到用户那听到一个什么想法，回来就让开发团队用“两周”时间做个DEMO，
做完这个DEMO，又作下一个DEMO。
大家想想，两周能够做出什么好东西，
于是时间就在一个又一个两周中浪费了，我多次提出，与其这样对付用户（反正用户也不会满意），还不如踏下心来认真做些东西，
老板表示理解，但我左右不了他的决定，
我也理解老板，面对项目，他销售的本能就不希望放弃，没有项目会让他觉得发自内心的不安。

本来应该在05年1月毕业的，由于工作忙，根本没有时间写论文答辩，
每天忙忙碌碌又觉得浑浑噩噩，一度怀疑自己的综合能力有问题，
种种因素，让我感觉到压力很大，于是抱怨开始多起来，跟老板的摩擦也多起来。

我已经在上研究生了，学习能解决我的问题吗，考PMP？考MBA？
直到有一天，一个偶然的机会读了温伯格的书，让我明白，“思考”是多么重要的人生课题。

－－－

我的一生中大事情上都算是挺顺利的，包括上学、工作、感情等方面，
05年是到目前为止最失败的一年，挫折的确能够激起人的反思和检讨。

四年以后再看当时的自己，的确很稚嫩，这一年的挫折，让我在后来的两年中成熟了很多，
其实任何一个公司追逐利益都是没有错的，
我们错在打着产品的旗号在做项目，于是做的不伦不类，
说是产品吧，没有完整的研发周期，
说是项目吧，又不愿意陷入到某一个用户的具体需求做定制，
脚踏两只船，最后只能死翘翘。

如果有哪位看官也面临小公司做产品的情况，建议你考虑以下几个问题：
1、公司要有足够的钱？
2、公司要有合适的人？（如果钱很多，可忽略此条）
3、这个方向有前途吗？
4、公司是不是在等这个产品吃饭？

做产品难，小公司做产品，更难。

houzeal

经过五个月左右的时间，终于把自己的十年总结写完了，
如果这是一个项目的话，那么它的预算和工期都大大超出了。
曾经只想通过四篇文章，简单回顾一下过去，没想到最终写了27篇。
十年并不是一个短暂的时光，但发生的真正有价值的事情却并不多，
我尽量保证每一篇都有一定的思考和意义在其中。

坚持写下来，需要不少的精力、毅力和耐心。还好，有很多朋友的支持，让我觉得自己的努力不是没事儿找事儿的无病呻吟，感谢各位的阅读、收藏和回复。 尤其是感谢博客编辑和论坛版主们的大力推荐，在已经发表的26篇中，有超过20篇曾得到过推荐，所以这一系列获得的关注，跟他们的工作密不可分！

回忆和总结是有价值的，曾经懵懂走过的路，如今看起来有如此多的缺憾，
我那么盲目的执着，又曾做出多少被动的选择，以及起起落落的自信心。
然而时光不再，后悔和自责都没有任何价值，留下这些文字，给后来的人当个参考吧，让看到的人能够少犯一些错误。
很多新人说向我学习，但我觉得新人更多的是要以我为鉴吧，争取从第一步就规划好自己的职业生涯。

不过还好，总体来讲，我也是不断进步的，我热爱思考，我很少悲观，我从不消极怠工，我热爱自己的工作， 人生最佳的工作时段也就三十年，第一个十年已经过去，下一个十年更加关键， 我要做出更加积极的人生规划，做出更多主动的选择，去大胆的实践和追求自己的梦想。

大家可能注意到，我写的文章里，纯技术所占的比重很少，多数都是工作中的思考和心得。这一方面跟我现在的工作内容有关，另一方面，也的确是我这么多年的一个切身感受，那就是：没有学不会的技术，但有学不完的技术。我并不是在宣扬技术无用论，相反，我对技术也有强烈的痴迷，但，记得我在一篇总结中说过的：情商更能左右一个人的发展。我们的程序员，是不是应该更早的抽出时间来关注一下非技术因素？比如，如何在团队中争取到主导地位？如何取得别人的信任？如何让你的工作得到更广泛的认可？

作为这个系列的终结，我把自己认为最最重要的几句话留在这里，与您共勉：
第一，人生最重要的课题是选择。
第二，不要给自己太多负面的心理暗示，心理暗示的可怕之处，就在于它是在不知不觉间产生作用。
第三，在职业生涯的某个阶段，职位比薪水更重要，因为职位决定了你可作的事情、可用的资源和面对的问题性质。在合适的时间，谋求一个合适的职位，可能是职业生涯从量变到质变的最有效的助力。
第四，只有你自认为强大的时候，别人才可能认为你强大。
第五，尽量不要在没有做一件事情之前说“我不能”。


－－－

总结完毕，接下来干什么呢？ 当然是继续努力工作，并寻找一个自己可以为之努力的方向，最近在构思“技术族谱”这个创意。 如果您还想继续关注我，可以访问我的博客。

最后，我有一个不情之请，如果您觉得我这几万字的总结和思考，给您带来过一点点参考价值，
希望您能够将这个系列的目录收藏，不为别的，因为您的收藏有助于更多的人看到这些文字。
不愿意收藏，回复一下也可以，总要让我看看都有谁路过了吧。
这一个个收藏和回复，权当是给我这半年心血的一点回报吧。

祝愿你我明日更比今日强！

houzeal

忠实的记录现在比回忆过去要痛苦的多， 不过既然都写了这么多，那就保证这一系列的完整性，这是倒数第二篇。

最近在CSDN上看到的一篇贴子：成功需要走十步的话，三五步之间最难走……， 这是少有的几篇让我看了以后有所触动，有所启发的文章。

现在的我，就是处在这不上不下的三五步之间，第四步，呵呵，不小心会走成死棋。当然，要说眼下的生活，也说的过去， 房子买的早，老婆有了，孩子很可爱，收入不高，但也不至于为生计发愁。 但是，和很多埋头走过十年的同行们的体会一样： 没有安全感，觉得偏离自己的理想太远，未来的方向不明确。 前几年感觉还不太明显，但这两年看到越来越多的同龄人走上了快车道，而我却一直在原地打转，如何超越自己？ 所以这种情形很让人心慌慌，导致很大的心理压力（谁能说自己不要强，谁没有理想，又有多少人没有虚荣心？）。

如何变得更成功？这是一个相当难的课题，甚至是一个悖论。 当你在问这个问题的时候，至少说明你自己不满足现状，你认为自己不够“成功”， 然后，描绘一副成功的蓝图比较容易，但怎么到达目的地，那就是走过去之后才有权说道的了。

由于思考如何走下去这方面的事情多了，所以最近写的文章也都是相关的主题，然后有人回帖说：
名和利能算做成功吗？
当然算了，我觉得对绝大多数人来说，名利双收就是巨大的成功！
ZangXT回的好：天下熙熙,皆为名来;天下攘攘,皆为利往！
我不是拜金主义者，但我十分清楚的知道，美好的生活需要适当的经济基础。 只有那些已经实现了终生财务自由的人，才有权利说我要为全人类的幸福而努力， 去做自己想做的事情，或者不做任何事情去享受生活。而对于我们普通人来说，只能是做好该做的事情，并努力把自己想做的事情变成一项事业，更好一点的，通过这项事业获取财务自由。


2008年，我参与了一个奥运重保项目，并在奥运前夕，将项目上线后，我离开了这家公司。

这次换工作，是比较奇怪的，本来我近期并没有主动辞职的计划，07年底到08年的时候，有猎头和朋友找过我几次，虽然几个机会待遇都挺好，但跟我所做的方向不一样就没有走。 我当时的队伍虽然不大，十几个人，但我完全可以掌控我要做的事情，所以我相信努力做下去会有一定的成果，后来呢，是我的领导把我推荐给了现在这家公司（当然，他们原来曾经是同事），然后也没正式面试就让我过去做产品经理。

这次换工作，谈不上好坏， 有好的一面，那就是团队大了很多，将近60人，公司也很支持这个方向，董事长看好这个方向，舍得投钱。 也有不好的一面，那就是，这个团队刚刚经过巨大的人事变动，队伍的战斗力很成问题。

一开始，我是抱着受熏陶的态度来的，毕竟公司更大，过了CMM 5，我想改善一下自己不规范的草根行为，后来，发现情况不太对，我努力成为一个观察者，认真的记录团队中所存在的问题，最近半年，我逐步在向一个推动者转变，制订规范、改善开发效率、为提高质量意识而筹划培训等等，在未来的一年里，我希望能够成为一个真正的领导者，无论从职务上还是从精神上，这也算是近期的一个目标吧。我也知道，有时候努力未必能够得到你想要的结果，但我最不愿意的就是被环境同化， 一年之后，要么是我让团队的面貌焕然一新，要么就是我离开的时候。如果要计算自己身上的优点，这积极的心态应该位列第一了。

总体来讲，我觉得，软件行业的形势，并没有很多人描绘的那样令人悲观， 其实每个行业都是类似的，上层的人总是少数， 当我们羡慕其它行业的时候，也要掂量一下，转行是不是就一定能够爬到那一层， 如果对这个行业不满意，应该尽早离开或者干脆别进来。

总结性的陈词，还是放在下一篇，也就是最后一篇吧，与第一篇相呼应。

chech28

这样的总结好的无话可说，赞！

houzeal

以上皆是 转帖 非本人！
作者 还有两篇 完成 此系列！

houzeal

原创  十年总结（23）：你是我生命中的精灵  收藏

此文于2009-09-14被推荐到CSDN首页
此文于2009-09-15被推荐到CSDN首页
如何被推荐？

对我过去感兴趣的朋友们，请看十年总结系列文章

－－－

2007年发生的事情很多，一件计划之中，却又在意料之外的大事，就是我老婆怀孕了。

人到而立之年，传宗接代的压力就开始凸显。
一方面双方父母都闲下来了，整天没事儿，就等着抱孙子呢，
另一方面，自己也必须做出决定，是走丁克路线还是走传统路线，因为大龄生产，对大人孩子都不好。

06年的时候，这件事情就被提上过议事日程，
但在怀孕早期，还不知道的时候，妈妈吃了一些有禁忌的药品，为了保险起见，最后还是做掉了。

07年又在商量的过程中怀孕了，这样也好，如果事事都精心计划，反而缺乏了生活的乐趣，
反正我平常不抽烟不喝酒，两个人除了熬夜都没有不良习惯，就要了这个孩子吧。


无论过去的生活曾经历过多少次改变，
背井离乡去上大学也好，
大学毕业进入社会也好，
从单身到恋爱，从恋爱到结婚，
比起家里多了一个小生命，那些变化对生活的影响，真的都不值一提。

孩子出生前，真的很担心，
一方面担心孩子健不健康，
一方面担心，自己是否能够成为一个合格的好爸爸。

孩子出生后，我这个新手老爸爱心泛滥，
本来就比较感性的我，在相当长的一段日子里，多愁善感的像个女人。
在第一个月里，我感叹最多的就是生命的神奇，每一天都有可见的变化发生在孩子身上。
我为她在百度上建了一个博客，发誓要记录女儿的成长，作为将来她成年的礼物。
记得上学时每次发誓写日记都坚持不过一个月，为了女儿，我现在已经坚持了一年半，并且乐此不疲。
孩子带给一个家庭欢乐和生机，同时也把我拉向了“堕落”的深渊。
以前我工作努力，业余时间有自己的学习计划，
从老婆怀孕开始，我的业余时间基本上就没动过书本。
到孩子出生以后，我更是全部的业余时间都泡在网上，
要么就是更新孩子的博客，要么就是挑选玩具和育儿资料。
我一年写了300多篇文章，处理了上千张照片，可想要耗费多少精力。

两年时间，不知不觉就溜走了，
本来应该在事业上有所斩获，有所突破的年龄，就这样被“虚度”了，
不过我一点都不后悔，因为“生活”才是人这一辈子的重心，
失去的事业机会还可以再去寻找，错失了孩子成长的瞬间，却再也不可能追回。

当然，为了孩子将来能有一个更好的生活环境，努力工作也是有必要的，
从现在开始，重新整装出发，向下一个目标努力。

－－－

父母之爱，真的是天性，
也许不见到自己的宝宝，这种天性永远不会流露。

我的女儿 靳开颜，音同 尽开颜，
取自毛泽东诗词《长征》：
更喜岷山千里雪，三军过后尽开颜。

二人世界有二人世界的好，要了孩子，有另一番好，
无论如何，没有孩子是永远也体会不到有孩子的好。

mentgmery

好帖,顶

houzeal

－－－

重庆项目结束后，团队的最后一名“元老级”成员离开了，她其实年初就提出来了，最终坚持做完了重庆的项目才走，的确很感谢她。每一次有早期加入的成员离开，我都会感到伤感，伤感之余就反思自己的坚持是否有价值。这最后一位元老的离开，表示一个时代过去了，我也应该反思作为带头人的失职之处。

我一直有一个信念，那就是要通过成就一项产品来成就自己。 于是有那么几年，我都没有计较过报酬，只是一门心思要做出一些成绩。 我也一直认为，或者说希望团队的成员也有相同的信念， 然而事实告诉我，这不太现实。

在此之前，我对领导者的理解有错误，或者说是片面的， 我过于关注作为领导者管理团队职能，而轻视了领导者为团队谋求的职能， 也就是说，经常只知道向别人提要求，却很少想拿什么来要求别人， 我以为公司会看到每个人的成绩，然而，能真正为员工考虑的公司，毕竟少啊！

这应该是我在管理方面的一次顿悟。


2007 年初，也就是重庆项目开始之前，我所在的公司被母公司全资收购， 借此机会，原公司老板把我负责的这一方向划成了一个二级部门，我就升级为部门经理。公司合并后，总公司对监控、运维管理（上一篇有朋友问是不是ITSM，对，就是这个方向）也挺感兴趣，在我们完成重庆项目后，公司就抛出了几个烟草的项目让我跟进（又要客串售前）， 而我这个二级部门所属的一级部门的领导，也想继续推进产品化，于是又开始新一轮的招聘总动员。

也不知道是我要求太高，还是人事发过来的简历太烂，招到合适的人还真不容易， 前前后后半年时间，总算把人手提到两位数以上了。


重新开始产品之路，与两年前相比，各方面的条件都好了很多， 但是，仅靠十几个人做产品，如果没有足够的时间，仍然是不现实的，而且，还是改不了边做产品边做项目的套路，这种情形似乎又与两年前完全相同，不过，最重要的差别是，产品的雏形已经成竹在胸，而当年，我也不确信应该做出什么来。


我精挑细选的团队成员，虽然大都不是什么牛人，但在做事风格上都比较相似，踏实、肯钻研。 大家遵循同样的工作模式： 我提出一个想法，分配给一个人去研究，给出可行性结论， 然后一起细化这个想法，确定实现程度和约束条件，再分给他去进行设计，
设计过程中进行反复的讨论，直至双方都充分理解和满意， 最后安排编码。

而我自己的时间，则主要分成三部分：
1、客串售前，不管乐不乐意现在都得干。
因为部门经理身上背负了公司的任务，和项目经理有较大的差异。
对项目经理的评价是项目完成情况，项目经理主要关心的是项目的进度、成本，所以项目经理会挑剔项目，
而部门是以收入为考核依据的，所以对项目就不能太挑剔了。
身份的转变，就会影响思考问题方式的转变，
同时，身份的转变，你遇到的问题也会改变。

2、构思产品的愿景。
包括研读业务相关的规范，如ITIL，结合用户的需求和期望，
规划产品的组成和开发步骤。

3、研究大量的开源项目
ITSM是很复杂的，在人少活多的情况下，我希望借助开源来提高开发速度。

简单说一下我的产品，总体上分为监控管理和运维管理两大平台，

监控管理平台，分为采集、处理、展示三大子系统，
采集子系统，主要和各类通信协议打交道，比如：jmx, snmp, jdbc, telnet, ftp, http等等，
可能还会采用perl或者shell写脚本，总之就是不惜一切代价获取数据。
处理部分，主要负责数据的归一化、持久化、告警分析，是以算法和计算为主的。
展示部分，是B/S架构的J2EE应用，总体难度不大，但界面比较杂。

运维管理平台的基础是工作流系统和CMDB，提供运维支持、日常办公支持、服务流程管理三个主要功能，
运维支持帮助维护人员做好做好值班管理和维护作业计划的定制和执行。
日常办公支持提供排单、申告、绩效考核、会议通告等类似OA的功能，我们称之为运维型OA。
服务流程管理就是根据ITIL规范，为用户定制运维相关的服务流程，
比如：变更管理、问题管理、事件管理等等。

研究了很多开源项目，印象比较深刻的有两个。

JBPM。
07年我看JBPM的时候，JBPM的官方文档比较简单（单论数量，比起HIBERNATE和SPRING算是非常寒酸的），
但我觉得这篇“user guide”写的非常好，如果能够认真从头看下来，那么使用JBPM不会再遇上大问题，
其实这个300K左右的文章，一周左右就可以搞定，在这上面花费的时间，绝对是值得的。
（这个观点已经在我的文章里出现N次了，大家别嫌罗嗦）

JBPM的user guide中有一章“Graph Oriented Programming”，我觉得是整篇文档的精髓所在，
有学习JBPM的朋友，建议一定精读之。

OneCMDB。
这是一个很小的开源项目（现在也不小了），实现了一个简单的配置管理数据库。
由于文档比较少，所以我直接在产品中整合了源码并做了比较深入的研究。

该项目的文档很少，而且主要用来定义“概念”，
什么是类别、什么是值、什么是关系、什么是属性、什么是配置项。
虽然所用笔墨不多，却很清晰的勾勒出项目的结构，
那么我自己写的设计文档，是不是也应该将问题域中的概念交代的明明白白，然后再去描述功能呢？


总之，这一阶段的工作还是比较开心的，团队在走向成熟，我也在走向成熟，
而我的Baby，不久也要出生了。

－－－

衷心感谢陪我走过产品研发这条路的每一个人。

在多数公司，检验成绩的主要标准是“市场”，而不是技术。

国内有多少公司在非法使用免费的开源项目？多数开源项目要求使用者也开放源码的。

大家怎么看待“我不过是个打工的”这句话？

houzeal

－－－

做完辽宁网通项目的售前之后，我得以暂时脱离售前队伍，全身心投入到重庆电信的一个项目中。

重庆，一个之前从没去过的城市，雾都、山城的名字，让它在我心中的形象增添了几分神秘色彩，
飞机冲破厚厚的云层，临近降落时看到起伏的地势和满眼的苍翠，我心里浮现出“喜欢”两个字。

走出机场后，闷热的天气，立刻让我美好的心情大打折扣，
天气预报说气温只有28度，但我感觉足有38度，
其实也不是特别热，而是特别潮湿，空气中似乎漂浮着看得到的水气，
北京的桑拿天比起这种天气，那真是小巫见大巫。
还好这种情况只持续了一天，我们戏称这是重庆为了欢迎我们的到来而特别展示其如水般温柔的一面。

重庆的植被很绿，那是因为雨水充足，将树叶冲洗的比较干净，
不像北京的树木，整个夏天灰蒙蒙的，一点都不生动。
进入市区，蜿蜒起伏的道路，依山势错落有致的高楼大厦，
让人觉得整座城市充满了灵性，似乎是有生命的。


这个项目共安排了五个人，我和小张先去，安排好住宿，第二拨人一周后到。
抵达第一天，晚上没事儿就去了朝天门，这里应该是重庆最繁华的地段之一，
两江交汇于此，很是壮观，恍惚间给人一种到了上海外滩的错觉。


由于项目不大，预算有限，我们计划在现场呆30－40天，住宾馆有点贵，于是想租一套三居室，
到中介那里转了一圈，发现都是最少三个月起租，
看了两套房，都不太满意，关键卫生什么的还要自己做，是个大问题。
后来在网上看到了重庆有很多短租公寓，挺合适的，于是就定了三间房。


住宿问题解决了，大家就全身心投入工作，我们用一周时间将程序主框架调试通过，
接下来就是协调用户开通权限，好让我们在各个主机上部署脚本采集数据。
这个项目钱不多，但用户所在的部门挺分散，监控点数量不多，但基本上BOSS相关的每个系统都涉及到了，
于是有那么一阵子，每天催用户赶快按要求赋予我们权限成了每日例行工作。

由于拿不到采集数据我们也就没有太多事情可干，于是大家都比较放松，
但我是很紧张的，因为这种拖延就意味着项目工期的拖延，不过也没有办法，只能每天不停的催用户。
晚上回到公寓后，因为天热大家都不愿意出去，就联网打游戏。
一开始有人提议玩帝国，我不感兴趣，而且五个人中有一个比较厉害，基本上玩起来别人就是被蹂躏，
后来我说玩极品飞车吧，反正大家都不太熟悉，于是下了经典的极品飞车5联网，打的不亦乐乎。

游戏这东西，我的感觉就是，没的玩的时候想玩，真让你放开了玩，很快也会意兴阑珊，
电脑游戏玩着没感觉了，还是去找街机游戏厅吧。
重庆的游戏厅比北京多，在住处附近就发现了三家，也很便宜，一块钱两个币，
玩来玩去，发现完全没有年轻时候的那种乐趣，倒是一种投篮机很招人喜欢，
既能锻炼身体玩的又尽兴，投篮机上的记录，被我们从三百来分提高到了六百多分，
估计再有人要超越就困难了。


重庆多美女，这话是半点都不假，我们住宿的地方在观音桥步行街旁边，
观音桥步行街也是很繁华的商业中心，四周都是大商场，
每天晚上来这里逛街的人络绎不绝，其中不乏让人眼前一亮的身影。

重庆美食以麻、辣为主，尤其是麻。
楼下的广场里有一条美食街，其中有一家卖酸辣粉的，
网上查到“杂酱”酸辣粉是最具特色的，可惜的是我每次去人家都卖完了。
重庆的饮食油非常大，包括火锅，感觉就是一锅辣椒油，在重庆，回收油似乎是一项合法的行业。

关于重庆的饮食业，我觉得一项比较神奇的成就是：本地快餐连锁店战胜了洋快餐。
重庆的“乡村鸡”快餐店，是我们解决工作餐的地方，人气比麦当劳、肯德基要火，
中式快餐，品种和口味都比北京常见的“合和谷”好很多。我当时就在想，是不是可以考虑在北京加盟一家店。

－－－

重庆这个项目做的很成功，不仅仅在与系统按计划上线、按时初验，也不在于用户给予我们的肯定和赞扬，
最重要的是这个项目使得一个年轻的队伍快速走向成熟。

参与这个项目的五个人，有两个毕业不到一年的学生，一个有两年工作经验，是在项目开始前不久才加入项目组的。
在团队管理方面，我最大的收获就在于 学会放手。

以前我是典型的“英雄式”的领导风格，有难题我就上，担心别人做不好，总爱把事情分析透彻了才交给别人去做。
但是这个项目开始的前两个月，我还在做辽宁项目的售前，所以没有多少精力参与，于是无意间改变了风格，
不少功能都是安排到人后，商定一个目标，具体采用什么手段让责任人自己去搞定。

比如有一项自定义视图的功能，我设想在Excel中设计好布局后，导入系统生成WEB界面，然后再给界面绑定展示的数据，
放在过去，我至少要把Excel导入这项技术做个可行性研究，确定一下用什么类库，再分给别人去做。
这一次由于没有时间，我就把自己的想法和架构要求写了个文档，让负责人自己去搞定技术探索和实现。

通过这样安排，我发现有些人蕴藏的潜力远比我想象的要大，
这种方式，不仅让我能够省心省力，对每一个人都是一种锻炼，能力可以得到充分的释放，从而获得更快的成长。


到达现场后，我继续放手让每个人去冲锋陷阵。
我把该系统的用户包干到人，每个人去跟自己负责的用户确认需求、讨论界面定制要求、做验收测试、签字，从头跟到尾，
我则负责解决任何人遇到的任何障碍和难题。


系统上线前要给用户进行培训，我安排每个人上台讲解自己负责的部分，
接到这样的任务，大家一开始都特紧张，但紧张中还透着一丝兴奋，
周末的时候，聚在公寓里大家饶有兴致的进行排练，一位同事还要拿相机录下来做分析。


放手，让我和我的团队共同成长，
压力，让真正优秀的人脱颖而出。

－－－

我听到过很多人抱怨新毕业生如何的弱，
我觉得，只要给予正确的指导，并给他们一个明确的目标，他们也常常回报给你惊喜。
自己亲手培养起来的毕业生，由于和你拥有相似的理念，我觉得是最佳工作伙伴。

美女、美景、美食，还有美好的团队，重庆给我的印象如此美好，
唯一美中不足的，就是我老婆当时怀孕几个月了，牵挂着我的心。

houzeal

－－－

从06年9月，到07年3月，半年左右的时间，去见了不少用户，
介绍用的PPT、成功案例、方案建议书等等售前资料都准备的比较齐备了，
不过没有哪个客户是签了约的。

老板的意思是说，电信客户下半年单子少，一般都在做来年的规划，我们做售前主要是为以后的项目联系埋下伏笔，
而我一直固执的认为，是因为我们还没有过硬的产品，跟用户的交流，更多的是停留在嘴皮子上，无法留下深刻印象，
虽然在跟用户的一次次沟通过程中，嘴皮子利索了，脸皮厚一些了，应变能力也强了，但“招摇撞骗”的感觉总是挥之不去。


07年的春节刚过完，还没有从慵懒中回过神来，老板就说这次有一个重要项目，要求我一定全程参与，
在没有单子签下来的时候，老板总爱把每个项目都说的很重要，都应该努力争取，我已经习惯了，
但这个项目不同，老板说这个项目机会具有“战略价值”，因为用户是辽宁电信，所以我们称之为“辽沈战役”。

接到去跟用户交流的通知挺突然的，而且公司恨不得让我们立刻出发，
原因是HP、IBM、BMC、中软等一些公司的前期交流都已经结束了，
我们公司本来不在邀请之列，是我们的销售（或者老板）又额外争取到了交流的机会。

于是，销售定了当天最快的飞机，我就在没有掌握项目任何信息的情况下去了。
这次的销售，不是原来搭档比较多的年轻销售，而是将近五十岁的老张，经验很丰富，
要不是因为老板跟客户方的一个主要负责人认识，需要避嫌，否则老板可能亲自上阵了。

在飞机上，我跟老张沟通了一下在没有任何项目信息的情况下如何演示，然后我就开始问这个项目的“战略意义”何在。
老张说在网通北方的几个省里，辽宁省跟总部的关系比较密切，如果能够拿下这个项目，做出效果来，
那么接下来拿着这个案例去说服总部在北方几省来个统签，应该是比较有希望的。

我们上午出发，马不停蹄的赶在下午一点半以前到达会场，结果只有两个维护人员参与，
讲完以后，老张又带我迅速拜访了用户的一条线上三个不同等级的领导。
在第二个领导那里，我把前面获取的信息结合以前在其它用户那里获取的思路，
整理成几点讲了一下，说的这位领导直点头，最后跟我们说：行啊，你们回去准备一份详细的方案发过来吧。
但到了最后一个领导，也是对这个项目最关键的领导那里，我把前面的思路一讲，他立即说你们理解的有偏差。

因为前面接触的几位领导，包括最初的那两个维护人员，都在强调EAI的监控如何重要，我也在顺着这个思路说，
（辽宁BOSS的所有系统都依赖于EAI，EAI的稳定性的确非常关键），
但到高层这里，他说EAI虽然重要，但也只是一个技术手段，我所关注的，是你们系统对平台层故障对业务和应用的影响分析能力，
比如一台主机出问题了，我不关心是哪块硬盘坏了或者是不是内存不足，那是维护人员需要去检查的，
我关心的是这台主机的问题，会导致哪些服务不能使用，比如是不是会影响用户充值，是不是会影响营业厅缴费？
对业务的影响程度决定了这个问题的优先级，从而影响我如何调派资源来处理问题，同时也影响对维护人员的工作考核。


无论怎样，此行争取到了与其它厂商一起参与后续竞标的资格，也算是不辱使命。
回来后，我就开始准备一个初步的方案，因为用户要求一周内提交。
这样的方案，每个厂商都要写，用户会整合厂家的思路，形成技术规范书，在发标的时候要求各厂家应答。

用户还要求我们在两个月内在现场搭一个测试环境，
这一点销售口头承诺了，但后来没有这么做，而是由老板出面邀请用户到北京来参观。
因为公司跟北京网通的关系比较好，06年做的项目用的效果也很好，老板竟然请了北京网通的一个领导来谈使用感受，
我在两个月的时间里针对辽宁的思路对系统做了诸多改造，总之是做足了文章。

辽宁用户借一次到北京开会的机会来参观了我们的系统，表示满意的同时提出了一些意见，
此后，我又根据用户的意见对系统做了些修改，然后跟销售专程到辽宁又做了一次汇报，
销售和老板从各种渠道探听的消息来看，用户对我们的表现还是很满意的。


但这个各方面看起来都很有戏的“辽沈战役”最终失败了，直接的原因，应该是报价问题，不是我们报的过高，而是报的过低。
根据前期探听的消息来看，项目的规模在100万到150万之间，HP、BMC等报价在300万左右的公司已经基本上是陪标了，
最有希望的两家公司：我们公司和另外一家公司，也是国内的一家小公司，咱们就叫他YL公司吧。

说起YL公司，和我的老板之间还有一段过往的恩怨情仇。2005年，老板想把开发转手的时候，曾经和YL公司谈过，但没有谈成，
原因是对方答应接手我们这些人，但要求老板必须注资多少，才能作为合作者的身份继续运作这个方向。

因此，在这次打标中碰上，老板特别想拿下合同，战胜对手，如果能成，也算出一口恶气。
然而，正所谓“关心则乱”，老板不仅重视这个合同的战略价值，又很重视这个合同的面子价值，
于是力排众议，不顾所有的反对意见，定了一个很低的价格。
结果，正是YL公司最终拿走了合同。

事后，老板为这事儿开会反思了好几次，也做了自我批评，
之所以低价却拿不到项目，应该是在一定程度上损害了用户的利益（项目总额小了，油水自然少）。


做完这次售前，我也有些心灰意冷，百无聊赖。
正好其它销售拿下了一个重庆电信的小单子，于是我又回去专心做项目了。
关于重庆的美食、美景和美女，将在下一篇中用非常愉悦的心情来描述。

－－－

这个项目是我跟的时间比较长，也比较深入的，
我也深深的理解了作为销售和售前，在用户面前所承担的压力，尤其是销售。
她们必须善于揣摩用户的心理，处理好用户内部各领导之间的关系，要想着如何投其所好，
也是很累的，心累。

YL公司中标之后，他们的技术总监给我打了几次电话，虽然没有明说（美其名曰一起聊聊），实际上是想让我过去，
后来他们的老总也给我打电话，意思就比较明确了，说有什么想法都好谈。
我考虑到：
1、不能在这个时候雪上加霜的跳槽。
2、跳也不能跳到这家公司，否则太不厚道了。
于是就没有搭这个茬。

从这件事可以看出一点，做技术兼作售前，因为接触的人多了，会有很多意想不到的机会。

houzeal

－－－

预期中的项目二期因为种种原因推迟了，
有经验的朋友们应该了解，除了软件公司在抢项目，动用自己的关系来影响用户的立项决策，
用户企业内部各部门之间也经常有斗争，谁掌握着更多的项目，就意味着更大的权利和利益。

新公司的老板倒不在乎，毕竟我们这块也不是公司的主营业务，
而且他觉得二期肯定会有，只是时间的问题，于是他让我做好一期的维护，有时间就对系统进行完善和扩展。

原来的公司（现在是合作公司）在剥离了研发部门以后，将更多的精力投入到售前和销售，
奈何没了做技术的支持，跟用户交流只剩下PPT了，连个像样的演示都拿不出，
见我这边项目结束，人都闲下来了，于是前老板赶紧张罗着让我去支持售前。


提到售前，就要说说跟我一起卖过来的一个人：南南，
他年龄挺大，具体岁数我没有具体问过，但应该跟我不在一个年代，
过来新公司以后，我跟他之间有些暗战，主要是争这个团队的控制权。

我的个性并不是特别强势，也不是热衷于权力斗争的那种性格，
但南南来到新公司后，表现出一种想上位的欲望，而我并不认为他可以让我信服，
于是暗地里较劲，当然，我是绝对不玩儿阴的。
新公司的老板可能也感觉到了，于是最后的结果是：他的主要精力转向售前，而我管理研发。
（南南是部队出身的，做事儿很敬业，很认真，我对他并没有什么成见，
他跟原来公司的老板是旧识，老板抓他过来可能也是给了他一些承诺，
再加上他的年龄，所以他觉得自己应该获得控制权，也是人之常情。 ）


既然南南转向售前了，那么为什么还要让我也去做售前工作？
让我踏踏实实来改善产品不好吗？
你们整天跟用户白话还不够，还要让我去跟用户吹牛，关键是，吹完卖什么？
（说售前是白话和吹牛，虽然有些夸大，但对很多小公司来说，也并不算过分夸张 ）

这些抱怨的话，我暗示过，摆上桌面谈过，老板一副“山人自有道理”的态度，给我罗列了不少理由：
1、  做产品的不接触市场，永远不可能成功（至理，我现在很认同）
2、  南南在售前方面还需历练（他南方人，说话口音重，而且一紧张有舌头轻微打结现象）
3、  为你好，锻炼你（这我也认可了）
4、 需要为下一个项目努力，否则大家都没饭吃。
（其实后来我明白这段经历让我受益颇多，但从回忆的的角度考虑，我还是要忠实的描述当时的心情 。）


做售前有两项主要工作：向客户介绍系统和编写文档。
因为刚毕业那阵子，我就有当培训讲师的经验，所以在人前讲话和写材料都不是问题，
当然了，如果没有这个潜质，也许老板压根不会让我上，因为毕竟客户也不是那么好糊弄的。

刚开始，我对售前工作多少有些许抵触心理，
一方面，是因为开发方面还有太多的事情要做，放下不管去干别的，总觉得不踏实，
另一方面，说实在的，也有些怵头。
不怵别的，只是做技术习惯了，人太实诚，跟用户吹牛的时候心里发虚，
就是我标题中所说的，刚出道，有点嫩 。

其实在05年初的时候，我就客串过一次售前，且被用户折磨的一塌糊涂，让我至今无法忘怀，
最主要的原因是：我太清楚软件的实际情况了！
让我站在台上侃侃而谈我们根本没有，或者根本不可能完成的功能，
这心理素质、应变能力和脸皮不经过一定的历练，还真难做到。
说实话，这方面的能力，甚至比编程更加重要 。


随着演讲次数的增加，我逐渐掌握了一些技巧，而这些技巧，同样可用于团队内的沟通上，
比如：要控制说话的速度，以便听众能够跟上你的思路。
比如：要跟听众形成良好的眼神互动，尤其有人提问的时候认真的看着他们。
比如：回答问题之前先肯定对方“您这个问题提得真好”，“您这个问题非常关键”。
比如：给出“否定”答案的时候要慎重，
即便你心知肚明这个东西没法做，也最好说：这个问题，我们回去和研发确认一下。
比如：如何移花接木，把A用户的一些想法灌输给B，用从B用户学到的知识回答C用户的问题。


如果说跟用户交流的兴趣还是逐渐增长的，那么参与投标写标书，则每次都是特痛苦的经历。
一般一套标书由商务点对点应答、资质证明、技术规范书的点对点应答、技术/方案建议书等几部分组成，
其中“技术点对点”和“技术建议书”的文档量都是重头戏，通常是由我包揽。

第一次写点对点应答的时候，我按实际情况，写了很多的“不满足”，结果立即遭到内部否决，
自此，我知道，无论能不能做，应答中原则上是不可以说不满足的（除非极特殊的情况），
因为别的公司也是这么干的，无论什么都能做，都以先拿下项目为目标。
这也可以算是发标方和应标方之间的默契和潜规则吧。
从此，我一直认为，投标拼的不是技术，而是关系和消息（消息在报价上非常重要） 。

本来不满足的事情写满足，让本来就枯燥的文档编写工作更加的痛苦不堪，
有些用户要求比较简单，只要写“满足”即可，而有些用户则要求对满足的条目解释如何满足，
这样就不得不绞尽脑汁的想或者查，如果要增加这样一个功能，该怎么做，能怎么做。


就这样，在以售前为主的工作中，走过了2006年，进入2007，我30周岁了。


－－－

在应标这件事儿上，我总怀疑用户是在故意折磨开发商，
发标以后，总是要求很短的时间内就交标（一般一周以内），
所以加班、熬夜写标书是常有的事儿。拼凑标书的感觉，真的很痛苦。

不过，如果有机会参与售前，面朝屏幕背朝人的程序员们，
勇敢的去尝试一下吧。

做开发的人多数比较单纯，信奉努力就有回报，
在这个基本信仰不变的前提下，适当注意策略和手段，应该会有更“公平”的回报。

houzeal

原创  十年总结（18）：2006，逐渐走出阴霾  收藏

对我过去感兴趣的朋友们，请看十年总结系列文章

－－－

我的这十年，可能 做出了很多错误决定，如果说这一点，还可以归结为时间的不可逆而无法证实的话，
那么我随波逐流的被动做出很多决定，则是不可否认的事实。

我在一开始就告诫过职场新人，步入职场，要做好规划，要走自己想走的路，
否则有一天，你会突然感到迷茫，到时候再做打算，选择已经不像一开始那么多，
因为在不知不觉间，你已经放弃了太多可能。

不过要做到这一点，的确不容易，做软件这一行，
有多少人致力于埋头钻研技术，以攀上一个又一个技术上的高峰为目标，
似乎忘记了应该从事业的角度设定一系列的里程碑。

年轻多好，因为很多机会，只对年轻人开放。


06年初，公司决定把软件部门出售给另外一家公司，
而曾经二十几人的软件部门，这时候只剩下了四个人。

如果我一直抱有感恩心情的老板都换了，我去还是不去，又是一次选择，
我相信，如果我不去，那么基本上就不会有人去。

然后老板找我谈话，他的意思是希望我们都过去，
因为他说这不是真正的出售，而是一种合作，另外一家公司的老板他是老相识，
他承认自己在管理开发方面存在不足，而另外一个公司在做电信的计费项目，开发氛围和管理方面应该没有问题，
这样两家公司一起推动这个方向，应该会给产品带来一些转机。
既然你都在这个方向上努力坚持了这么多年，如果你相信这个方向没有问题，就应该再坚持下去。

其实这话说到我心里去了，首先我一直认为这个方向没有问题，
更重要的是，做了三年的一个东西，不是说放手就能放手的，
也许换一家公司还可以做同样的事情，同样的方向，甚至获得更好的位置和报酬，
但就像初恋情结，并不是有人更加优秀，你就会轻易移情别恋的。

当然，老板在这几年里投入的几百万，如果我们不过去，那么这些投入就彻底玩完了，
所以，他希望我们过去，肯定也是有他的考虑。

不管怎么说，我还是留下来，带着开发的几个人过去了，
因为我还想证明一点：过去的失败，是不是环境的问题，人员不变的情况下，我要让下一个项目获得成功。


到新公司以后，新老板也不插手这块，终于有了持续的开发时间，
于是重新设计，尤其是界面基本上完全重做，
从3月到9月，半年的连续开发，一个项目顺利上线了，
这一次，终于感觉和用户站在了一个阵营，耳边少了用户不停的抱怨，取而代之的是对系统的肯定和改进建议，
05年被糟蹋的一塌糊涂的自信心，也在这个时候拾回来不少。

1月份过来的时候，有四个人，但其中一位因为家里的原因，4月份走了，实际上，这个项目也就三个人在做，
05年加班加的烦透了，这次并没有刻意安排加班，
只有临近上线的时候紧张了一个月，但也是每天下班晚一些而已。

但这个项目的成功，还远远不够，因为它毕竟只是一个项目，离产品化开发的目标还距离太远，
在这个项目中，本人又充当了一次超级coding高手的角色。
其实如果能够给程序员足够的尊重和物质保障，写代码，尤其是写高质量的代码，是非常快乐的事情。

06年初还不像现在，WEB方面没有那么多成熟的框架，ajax也远没有今天这么普及，
为了改善用户体验，我准备在展示层所有的关键页面都使用AJAX技术，
我也是05年才开始学习WEB相关的东西，对js,css等等都不太熟悉，
于是在很短的时间内，研究了如下技术：
DWR、CSS、VML、DOJO、JSON，XSLT，
最终确定了用DWR作为数据传输手段，json作为数据传输编码格式，用DOJO来完成前台控件开发这样一个模式。
（我有一篇简单的关于DOJO的文章 ，提到DOJO在js面向对象封装方面有独到之处）

我用DOJO开发了三套控件，其中最有特色的是一个拓扑图编辑和展示系统，
我对比过，在06年，很多网管都有拓扑图系统，但基本上都是基于C/S的，
我们实现的纯B/S的拓扑系统，在当时还是有一定的先进性的，这一设计，后来变成了我的研究生论文。

这个拓扑系统在浏览器中实现了MVC模式，
model是XML的拓扑描述，通过dwr加载和保存，描述拓扑图上的节点、连接线等信息，
view是VML，用于把模型展示层图形，
controller是javascript，当然使用DOJO做了封装，响应用户的操作，
然后修改模型，从而改变拓扑图的展示，比如拖拽、缩放、画线等等。
这一部分从可研到设计到完成，只用了四周的时间，光js代码就超过了200K，
也算是我比较神奇的发挥了，如果没有DOJO框架，真不知道会乱成什么样。


总之，通过这一个完整项目的顺利验收，
一方面让我的自信心得到恢复，至少相信自己可以推进项目取得成功，而不仅仅是技术达人，
另一方面让我在接触客户方面，有了更多经验，更了解项目的完整过程，
第三，它完善了我的知识体系，原本比较薄弱的WEB前台技术，像JS，CSS，都在这次项目中得到了充分的掌握。

06年10月，我的队伍又开始扩充，以应对接下来的二期，
没有了对自己的怀疑，也没有了公司的决策干扰，我发现一切似乎变得都顺利了，
（新公司的老板一直让我们完全独立，大小事务基本上由我全权决定，当然，招人的数量还是要通过老板拍板）。

我同时发现我的兴趣在逐渐转移，是很自然的，不是刻意为之，
因为在这次项目过程中，我充分认识到，只要有想法，技术上的实现并不是问题，
于是我开始更多的考虑把这个软件做成什么样，
虽然还是热衷于研究一些新的东西，但目标却有所不同，
研究的内容也不都是技术，还包括一些国际标准和规范。


我想，我终于获得了一次比较有价值的成长。

－－－

今天突然注意到，努力和奴隶的拼音是一样的，真是很有讽刺意味。

houzeal

有了互联网，下载很方便，于是每个人都有很多资料，不过资料过多也是一种负担。
当知识变成一种“收藏品”的时候，其价值可不会像“古董”一样越老越值钱啊!

什么书算是一本好书，值得收起来时时翻阅？
看看评论家们的溢美之词，似乎每一本书都是空前绝后，不读就是一生的遗憾，你信吗？
那位说了：现在的广告根本没法信。没错，你不信，我也不信。

我不敢奢望太多，一本书只要有一两个闪光点，有20％的 精彩 内容，我就很满足了。
可惜，现在市面上的书太多了，内容重复也相当严重，尤其是技术书籍。


接触到温伯格的书纯属偶然。

05年，老板每天都唠叨着要我关注业务，我也明白这个理儿，
于是从书架里翻出一本名为《探索需求》的书，准备拿回家去看。

一开始也没太在意，以为又是那种讲规范、将流程、讲文档格式的书，
后来发现书的内容主要说的是人的问题，而且行文比较随意，就读了下来。

没过多久，我在西单图书大厦又看到了一本名为《你的灯亮着吗？》的书，
发现和《探索需求》的作者是同一个人，于是就买了下来。

两次碰到同一个人，就开始对他产生兴趣，研究了一下，
发现03、04两年，清华大学出版社，陆续翻译出版了十几本温伯格的书，
于是在一次去清华找老师的时候，顺便买了几本，其中包括一本名为《成为技术领导者》的。

《成为技术领导者》这本书光是名字就吸引我买下来，
因为我虽然一直在做小小的领导，却自我感觉越来越不好，我相信我遇到了瓶颈，
而这本书，也许能够提供一些帮助。

下面的文字，选自05年我在MSN上的博客，能更准确的反映当时的心情：
经过最近不断阅读Winberg的书籍，我认为我的思维方式已经有所转变，
相比过去，遇到需要讨论的事件，不再脱口而出一些听似慷慨激昂，但不经推敲的话，
我会更多的思考，推迟话语出口的时间，组织自己的思维和用词。

我也会用更多的积极合作来代替过去无声的抵抗，
毕竟，每一次做事，都是对自己的一种锻炼，情况越是不利，我们越可以收获更多。

Winberg确实给了我思考的力量，他会让我们认识到虽然很平常，但我们多数人都没有理性的加以认识的人性。
虽然我不会有即刻的升华，但如果再有7年的体验、观察和思考，我相信我的35岁将会与众不同的。

欢迎大家读他的书。

－－－

《探索需求》
这本书是谁买来的，至今是个迷，在05年底离开公司的时候没有归还就成了我的私人财产。
从名字看，似乎暗示只有需求人员需要读这本书，实际上每个人读一下这本书都会有所补益，
因为我们每个人每天都在跟别人交换信息，实际上就是向别人提供需求，或者从别人那里获取需求。

这本书从始至终贯穿一个思想：降低信息的含混性。
书中阐述了含混性产生的原因，降低含混性的手段，以及度量含混性的方式。

书中第一章讲了一个“万无一失灭蟑器”的故事：
把蟑螂放在木块A上，然后用木块B用力拍打，则可以“万无一失”的杀灭蟑螂。
但问题的难点在于捉住蟑螂并将其放在木块A上，并在拍打之前保证其不能逃跑。

蟑螂就是需求（这个比喻倒是挺贴切，都很难驯服），
灭蟑器是影射那些声称能够把某些开发过程自动化的工具，
其实最重要的事情，还是得人来做，也就是如何抓住蟑螂（需求）。

《你的等亮着吗？》
这只是一本小册子，全书的宗旨是讲：如何思考、如何定义问题。
除了书名所指的故事，书中的其它故事留给我的印象并不太深刻，第一个故事甚至有些冗长，
而且有些外国的故事，放到中国感觉不可思议，也不可能发生。

但书中不时出现的总结性句子，总能让人觉得眼前一亮：
> 如果你找不出三处可能出错的地方，说明你没有真正理解问题
> 不要轻易给问题下结论，也不要忽略你的第一印象
> 当别人能够解决问题时候千万不要越俎代庖
> 如果某人能够解决该问题当他自己却不会遇到该问题时候，首要的是让他感受到该问题
> 任何解决问题方法都不可避免有副作用

这本书给问题下了明确的定义：问题其实就是你所期望的和你所体验到的之间的差别。
然后，这本书告诉我们：一定要找到真正的问题，而不是你所认为的问题。

下面就是标题故事：你的灯亮着吗？
最近，在日内瓦湖上的山脉中，建成了一条很长的汽车隧道。
在投入使用之前，总工程师想起来，她忘了警告汽车司机在进入隧道之前把车灯打开。
尽管隧道的照明设施很好，仍然需要预防停电的情况下发生灾难（在深山中这种意外是很可能发生的）。

于是人们做了一个标牌，上面写着：
警告：前有隧道请打开车头灯！

他们把标牌挂在隧道入口处，然后隧道如期通车了。既然问题已经解决了，大家都觉得很轻松。

从隧道东出口再往前400 米就是世界上风景最优美的度假胜地，从这里俯瞰，整个日内瓦湖都尽收眼底。
每天都有成百上千的游客在此处欣赏美景，放松他们疲惫的身体，也许享受一个美味的小“野餐”。
同时，每天当这几百名神清气爽的游客返回他们的汽车的时候，
都会有十来个或者更多的人们意外地发现汽车电池没电了――因为他们忘了关掉车灯！
警察们被迫用上他们所有的资源，好让车启动起来，或者把它们拖走。
游客们怨声载道，并且赌咒发誓要劝说他们所有的朋友都不要到瑞士来旅行。

像往常一样，我们会要求您暂停一下，回答这个问题：
这是谁的问题？
（a） 司机
（b） 乘客（如果有的话）
（c） 总工程师
（d） 警察
（e） 州长
（f） 汽车俱乐部
（g） 以上都不对
（h） 以上都对

这种类型的问题中――因为它有一个明确的“设计者”或者叫“工程师”――有一个很强的倾向就是认为这是她的问题。
在这件事中，不仅司机们认为这是工程师的问题，而且工程师可能也这么认为。
建筑师、工程师和其他设计者的职业道德中有这样一条：他们必须做好所有的事情。

在这个例子中，工程师考虑了她能够强加在司机及其乘客身上的很多种解决办法：
（1）    她可以在隧道尽头里一块标牌，写上：关掉车灯！
但是这样的话夜晚行车的人们也会关掉车灯??

（2） 她可以装作不知道，顺其自然??
不，这本来就是现状，并且政府官员们认为工程师的工作做的一团糟。

（3） 她可以在风景俯瞰处建造一个充电站。
但是要维护要花很多钱，并且如果它出了故障人们会更加恼火。

（4） 她可以授权一家私人公司经营充电站。
但是这会使风景区变得商业化，这是政府和游客绝对不会接受的。

（5） 她可以在隧道尽头树立一个表意更明确的标牌。

凭借她的直觉，工程师认为一定可以通过某种方法来书写一个更加明确的标牌。
她尝试了许多备选方案，最终得到了一个体现瑞士式简约的杰作：
如果这是白天，并且如果您的车灯开着，那么熄灭车灯；
如果天色已晚，并且如果您的车灯没开，那么打开车灯；
如果这是白天，并且如果您的车灯没开，那么就别打开；
如果天色已晚，并且如果您的车灯开着，那么就别关它。

等人们读完这个标牌，汽车早已经飞过围栏，并且咕噜咕噜地沉到湖底了
――这根本就不是一个可以接受的解决方法，难道说，还应该说说葬礼该怎么样？

必定有更好的方法！

事实上总工程师并没有把问题复杂化，她用了一种方法，“把问题当作他们的问题”――工程师只是起了一点辅助作用。
她假设司机们非常愿意解决这个问题，但是也许需要一点儿提醒。
她还假设司机们――如果他们通过了驾驶执照的考试――不可能是那种彻头彻尾的傻瓜。
他们所需要的只是在隧道尽头加一块标牌，写上：

您的灯亮着么？

《成为技术领导者——解决问题的有机方法》
“技术领导”，还是有些不同于传统“领导”的地方，
在中国，提起“领导”，想起的都是心机、权谋、勾心斗角等字眼，同时“领导”所拥有的权力又让人眼热，
而“技术领导”，并不那么好当，要有技术和人格双重魅力，靠的是服人而不是使人屈服。

实际上，书名的后半部分，说明这本书还是致力于如何解决问题的，也是关于如何思考的。
可惜的是，这本书被我借给别人以后再也没有回来，而现在，温伯格的书在所有的书店都没货了。

不过，经过时光的洗刷能够依然记住的，应该是真正有触动的东西，
对于我来讲，这本书收益如下：
1、一个人的发展之路不是线性的，而是跳跃性的，要直面挫折。
2、在解决问题的过程中，尽量不要站在别人的对立面。要制造一种这是“我们的问题”的感觉。
3、不仅要思考，而且要经常反思自己的思考过程，也就是关于思考的思考。

－－－

其实05年影响我的书还有一本，那就是《哈利波特与混血王子》，
这本书中提到的“大脑封闭术”，用来对付失眠和整理情绪挺有用的。
具体做法如下：
闭上眼睛，双眼内视，用意识去感受你的大脑，
你会发觉自己的大脑很紧张，就像握紧的拳头，
告诉自己的大脑放松，一层层的松开，尽量不去想任何事情，
慢慢的你就会发现自己进入一种很沉静的状态，这是一种很好的休息。

其实瑜伽和气功里都有类似的调节方式，
信不信，就见仁见智了。
－－－

非技术书籍中透露的思想，碰到中国人与事的特殊环境和文化，未必样样适合，谨记。

houzeal

做产品难，看起来不是我一个人的感受。
做面向个人的产品，受不了的是盗版，
做面向企业的产品，中国的企业市场靠的是关系，而且资金、需求的极端个性化都是障碍，
如果产品有一个绝佳的创意，那么经不住抄袭，
如果产品有一项核心技术，然而一直领先似乎不太现实，况且中国也不缺聪明人，

所以国产单机游戏没落了，无论是轩辕剑还是仙剑，网游火了，
所以中国没有像Ultraedit这样的个人软件精品，盗版业火了，
所以中国的软件行业少有属于自己的创新，互联网也是不断的跟着国外走，

有时候想想，没有自己的操作系统、没有自己的编程语言，没有自己的开发工具，中国软件还剩下啥？

也挺奇怪自己为什么总有这么多感慨，也许这就是开始变老了吧。

不过话说回来，作为软件行业的从业者，我是应该忧虑，
因为我们的命运多少是与中国软件的未来息息相关的。

百度、腾讯、华为，这些公司再牛，能养几个人，如果只有这么几家好的公司可供选择，如果中国软件的大环境不向好，
那么每年N万新程序员的成长计划（假定为程序员-->设计师-->架构师或者项目经理-->高管），
只能是水中月、镜中花。

如何改变，也许只有靠我们每一个人，本着“软件兴旺、匹夫有责”的信念，
如果有一天各位从底层走到高层，是否能够在自己可控的范围内，践行自己当初的理想？

－－－

话题扯的有些远，每每一动思考就是浮想联翩。

上一篇文章有一位朋友问我2005年是不是在转型，
是的，05年很压抑，的确在转型，前半年被迫转，后半年自己主动寻求改变，

面对挫折和失败能怎么办？
逃避？不是我想要的；无视？更不行！

我想做的是分析和证实，
分析失败的原因哪些应归咎于我，哪些应归咎于环境，
不为推脱责任，只是为了防止因为失败而导致过度的自卑，是为了挽救一定的自信心。
证实主要是希望搞清楚自己可以做到什么样，过去有错的地方应该如何改进。

分析是相对容易的，老板也经常跟我们做沙盘推演，复盘分析，从过去的错误中吸取教训，
而证实的过程却是迷茫而漫长的。

我有两个问题：
1、如何做出正确的决策？
2、如何将个人的力量，转化为团队的力量？

第一个问题对于很多人来说根本不成为问题，
可对于经历了一段挫折的我来说，这是一个很重要的命题。
因为有过失败，在做下一次决策的时候心里就会嘀咕：
我这样做没问题吧？不会又搞错吧？
就像打乒乓球，本来领先，然后被对手反超，这时候心理就会产生微妙的变化，

关于决策的正确性，具体来说，主要有两点需要反思：

1.1 关于设计的程度问题
受到04年重构、XP、敏捷等思想的影响，我一直在号召自己的团队消灭脏活，
（我们把具有设计和复用价值的代码称为累活，而把重复性劳动和特例代码称为脏活）
这导致一个后果，就是大家似乎都染上了点洁癖，
有些功能如果想不出好的可扩展方案，或者会破坏现有设计的“美感”，宁愿放弃不做。
遇到任何功能都想通用化，想一劳永逸，于是抽象、做成一个架构，考虑可扩展等等，

过度设计，导致开发团队总在做自己想做的（理想化），而不是应该做的，
这样开发出来的东西，深入进去看挺优雅的，但视角拉出来看整体，没什么用户需要的东西，就是一个架子。
我们总是希望在一个完美的架子上，把用户的需求很容易的纳入进来，事实上，完美是基本上不可实现的。


1.2 关于业务和技术的关系问题
相信每个入行几年的朋友们，都会听你的老板、上司或者资深同事唠叨过：
不要太关注技术，关注业务才能立于不败之地。

这句话好说，不好做，时间会证明这句话是对的，因为我现在也在向别人灌输这个理念了，
但业务真的比技术更难琢磨，更抽象，或者说，业务知识需要揣摩。
让一个技术专家和业务专家一起跟用户做一次需求沟通，那么两个人的理解肯定是不同的。

比如，我们的监控系统有一个拓扑图功能，有一次用户提出拓扑图需要具备“数据钻取”功能，
按照我的理解，钻取是一种复杂的数据分析手段，
我首先想到的是数据之间的层级关联关系如何管理，是自动发现还是手工配置？
如果自动发现技术上会有很大的难度，而如果手工配置，则界面应该比较复杂。

可我们的老板完全不这么理解，他认为只要实现“父－子”拓扑，并能够向下一层层展开即可，
让我觉得不可思议是，用户真的接受这种理解。

当然，这也许不是一个非常恰当的例子，但足以说明，
技术人员和业务人员之间，对同一套词汇的解释有很大的差异性，
了解业务，我觉得就是站在用户的角度考虑问题，站在行业的大背景下考虑问题。


关于第二个问题：如何将个人的力量，转化为团队的力量？
在人少的时候，大家都是哥们一样的，大家都把开发作为一种乐趣，在工作上有共同的价值观，
这是一种很美好的状态，每个人的效率都很高。
但团队肯定要变大，人多了，管理不善效率就会下降，事情就会失控，怎么办？

我在这方面想了很多，包括管理者的风格，宽严的尺度，团队的文化，制度的设置等等，
我一直向往一种比较理想的状态：那就是无为而治。
实际上这种想法还是有些来自于软件设计的框架思想，
设定适当的原则，纳入合适的人，每个人都为特定的目标而“主动”努力。

我一直在尝试这种方式，实践证明，在建造新的团队时（尤其是可塑性强的新毕业生组成的团队时），
这种方法非常有效，
但用于改造既有团队，则需要的时间和面对的阻力都要强一些。

我设定的原则很简单：
每个进入这个团队的人，都要求积极反馈、有效沟通、树立质量意识。
这样，经过一段时间的磨合，团队会形成一个自驱力，也就是不用管理者推动就可以向前走。

在这一年，看的书基本上都是温伯格的，有三本个人感觉帮助比较大：
《探索需求》
《你的灯亮着吗》
《成为技术领导者》
接下来我会做个专门的介绍

－－－

谈到“转型”，我相信多数人的第一反应是从“技术”转向“管理”，
我倒觉得未必一定如此。

我将转型定义为“思想的转变” ，是一种自我改造，结果是境界上的升华，是考虑问题的角度和处理问题的手段上的转变。

按照这种定义，我从05年开始主动的考虑“转型”，到现在很多年来都是处于“半管理”状态，
其间做过项目经理、部门经理、产品经理，
管理是我工作的职责，但一直没有成为100％，所以我也从来没有间断过开发。
不是不可以做到，而是觉得完全脱离开发不安全，也不甘心。

一定会有人说这是失败的转型，
可是我觉得，正是这样一种看待开发的观念，造成了大家对30岁的恐惧，
其实坊间不自觉的将开发视为下等工种，而将管理看作是上等工种（也许我选词不当，但我相信大家明白我的意思），
而你我都浸淫其间，受到这种文化的熏陶，所以才有这么多人刚入行，甚至没入行就在前瞻“转型”的问题，

可是，技术和管理应该是软件行业的两条腿，重要性是一样的才对，
有些人天生是技术达人，转向管理不仅是人才的损失，也让自己难受，
况且这种跨工种的转型（无论从技术转向管理，或者从管理转向技术），是有风险的，未必每个人都能胜任新的角色。

我希望，我也相信，随着中国软件行业的生态环境逐渐趋于合理，
我们的程序员，只要在一个方面做的足够的好，足够的精，哪里都少不了他的生存空间。


这一篇我自己看着都觉得晦涩，写出来不容易啊。