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

－－－

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

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

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

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

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

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

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

－－－

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

－－－

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

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

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

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

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

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


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