十年总结(16):主动的自我改造(或者说转型?)
2009-09-09 13:30
323 查看
原文链接:http://blog.csdn.net/jinxfei/archive/2009/07/28/4386609.aspx
上一篇文章有一位朋友问我2005年是不是在转型,
是的,05年很压抑,的确在转型,前半年被迫转,后半年自己主动寻求改变,
面对挫折和失败能怎么办?
逃避?不是我想要的;无视?更不行!
我想做的是分析和证实,
分析失败的原因哪些应归咎于我,哪些应归咎于环境,
不为推脱责任,只是为了防止因为失败而导致过度的自卑,是为了挽救一定的自信心。
证实主要是希望搞清楚自己可以做到什么样,过去有错的地方应该如何改进。
分析是相对容易的,老板也经常跟我们做沙盘推演,复盘分析,从过去的错误中吸取教训,
而证实的过程却是迷茫而漫长的。
我有两个问题:
1、如何做出正确的决策?
2、如何将个人的力量,转化为团队的力量?
第一个问题对于很多人来说根本不成为问题,
可对于经历了一段挫折的我来说,这是一个很重要的命题。
因为有过失败,在做下一次决策的时候心里就会嘀咕:
我这样做没问题吧?不会又搞错吧?
就像打乒乓球,本来领先,然后被对手反超,这时候心理就会产生微妙的变化,
关于决策的正确性,具体来说,主要有两点需要反思:
1.1 关于设计的程度问题
受到04年重构、XP、敏捷等思想的影响,我一直在号召自己的团队消灭脏活,
(我们把具有设计和复用价值的代码称为累活,而把重复性劳动和特例代码称为脏活)
这导致一个后果,就是大家似乎都染上了点洁癖,
有些功能如果想不出好的可扩展方案,或者会破坏现有设计的“美感”,宁愿放弃不做。
遇到任何功能都想通用化,想一劳永逸,于是抽象、做成一个架构,考虑可扩展等等,
过度设计,导致开发团队总在做自己想做的(理想化),而不是应该做的,
这样开发出来的东西,深入进去看挺优雅的,但视角拉出来看整体,没什么用户需要的东西,就是一个架子。
我们总是希望在一个完美的架子上,把用户的需求很容易的纳入进来,事实上,完美是基本上不可实现的。
1.2 关于业务和技术的关系问题
相信每个入行几年的朋友们,都会听你的老板、上司或者资深同事唠叨过:
不要太关注技术,关注业务才能立于不败之地。
这句话好说,不好做,时间会证明这句话是对的,因为我现在也在向别人灌输这个理念了,
但业务真的比技术更难琢磨,更抽象,或者说,业务知识需要揣摩。
让一个技术专家和业务专家一起跟用户做一次需求沟通,那么两个人的理解肯定是不同的。
比如,我们的监控系统有一个拓扑图功能,有一次用户提出拓扑图需要具备“数据钻取”功能,
按照我的理解,钻取是一种复杂的数据分析手段,
我首先想到的是数据之间的层级关联关系如何管理,是自动发现还是手工配置?
如果自动发现技术上会有很大的难度,而如果手工配置,则界面应该比较复杂。
可我们的老板完全不这么理解,他认为只要实现“父-子”拓扑,并能够向下一层层展开即可,
让我觉得不可思议是,用户真的接受这种理解。
当然,这也许不是一个非常恰当的例子,但足以说明,
技术人员和业务人员之间,对同一套词汇的解释有很大的差异性,
了解业务,我觉得就是站在用户的角度考虑问题,站在行业的大背景下考虑问题。
关于第二个问题:如何将个人的力量,转化为团队的力量?
在人少的时候,大家都是哥们一样的,大家都把开发作为一种乐趣,在工作上有共同的价值观,
这是一种很美好的状态,每个人的效率都很高。
但团队肯定要变大,人多了,管理不善效率就会下降,事情就会失控,怎么办?
我在这方面想了很多,包括管理者的风格,宽严的尺度,团队的文化,制度的设置等等,
我一直向往一种比较理想的状态:那就是无为而治。
实际上这种想法还是有些来自于软件设计的框架思想,
设定适当的原则,纳入合适的人,每个人都为特定的目标而“主动”努力。
我一直在尝试这种方式,实践证明,在建造新的团队时(尤其是可塑性强的新毕业生组成的团队时),
这种方法非常有效,
但用于改造既有团队,则需要的时间和面对的阻力都要强一些。
我设定的原则很简单:
每个进入这个团队的人,都要求积极反馈、有效沟通、树立质量意识。
这样,经过一段时间的磨合,团队会形成一个自驱力,也就是不用管理者推动就可以向前走。
在这一年,看的书基本上都是温伯格的,有三本个人感觉帮助比较大:
《探索需求》
《你的灯亮着吗》
《成为技术领导者》
接下来我会做个专门的介绍
---
谈到“转型”,我相信多数人的第一反应是从“技术”转向“管理”,
我倒觉得未必一定如此。
我将转型定义为“思想的转变”
,是一种自我改造,结果是境界上的升华,是考虑问题的角度和处理问题的手段上的转变。
按照这种定义,我从05年开始主动的考虑“转型”,到现在很多年来都是处于“半管理”状态,
其间做过项目经理、部门经理、产品经理,
管理是我工作的职责,但一直没有成为100%,所以我也从来没有间断过开发。
不是不可以做到,而是觉得完全脱离开发不安全,也不甘心。
一定会有人说这是失败的转型,
可是我觉得,正是这样一种看待开发的观念,造成了大家对30岁的恐惧,
其实坊间不自觉的将开发视为下等工种,而将管理看作是上等工种(也许我选词不当,但我相信大家明白我的意思),
而你我都浸淫其间,受到这种文化的熏陶,所以才有这么多人刚入行,甚至没入行就在前瞻“转型”的问题,
可是,技术和管理应该是软件行业的两条腿,重要性是一样的才对,
有些人天生是技术达人,转向管理不仅是人才的损失,也让自己难受,
况且这种跨工种的转型(无论从技术转向管理,或者从管理转向技术),是有风险的,未必每个人都能胜任新的角色。
我希望,我也相信,随着中国软件行业的生态环境逐渐趋于合理,
我们的程序员,只要在一个方面做的足够的好,足够的精,哪里都少不了他的生存空间。
上一篇文章有一位朋友问我2005年是不是在转型,
是的,05年很压抑,的确在转型,前半年被迫转,后半年自己主动寻求改变,
面对挫折和失败能怎么办?
逃避?不是我想要的;无视?更不行!
我想做的是分析和证实,
分析失败的原因哪些应归咎于我,哪些应归咎于环境,
不为推脱责任,只是为了防止因为失败而导致过度的自卑,是为了挽救一定的自信心。
证实主要是希望搞清楚自己可以做到什么样,过去有错的地方应该如何改进。
分析是相对容易的,老板也经常跟我们做沙盘推演,复盘分析,从过去的错误中吸取教训,
而证实的过程却是迷茫而漫长的。
我有两个问题:
1、如何做出正确的决策?
2、如何将个人的力量,转化为团队的力量?
第一个问题对于很多人来说根本不成为问题,
可对于经历了一段挫折的我来说,这是一个很重要的命题。
因为有过失败,在做下一次决策的时候心里就会嘀咕:
我这样做没问题吧?不会又搞错吧?
就像打乒乓球,本来领先,然后被对手反超,这时候心理就会产生微妙的变化,
关于决策的正确性,具体来说,主要有两点需要反思:
1.1 关于设计的程度问题
受到04年重构、XP、敏捷等思想的影响,我一直在号召自己的团队消灭脏活,
(我们把具有设计和复用价值的代码称为累活,而把重复性劳动和特例代码称为脏活)
这导致一个后果,就是大家似乎都染上了点洁癖,
有些功能如果想不出好的可扩展方案,或者会破坏现有设计的“美感”,宁愿放弃不做。
遇到任何功能都想通用化,想一劳永逸,于是抽象、做成一个架构,考虑可扩展等等,
过度设计,导致开发团队总在做自己想做的(理想化),而不是应该做的,
这样开发出来的东西,深入进去看挺优雅的,但视角拉出来看整体,没什么用户需要的东西,就是一个架子。
我们总是希望在一个完美的架子上,把用户的需求很容易的纳入进来,事实上,完美是基本上不可实现的。
1.2 关于业务和技术的关系问题
相信每个入行几年的朋友们,都会听你的老板、上司或者资深同事唠叨过:
不要太关注技术,关注业务才能立于不败之地。
这句话好说,不好做,时间会证明这句话是对的,因为我现在也在向别人灌输这个理念了,
但业务真的比技术更难琢磨,更抽象,或者说,业务知识需要揣摩。
让一个技术专家和业务专家一起跟用户做一次需求沟通,那么两个人的理解肯定是不同的。
比如,我们的监控系统有一个拓扑图功能,有一次用户提出拓扑图需要具备“数据钻取”功能,
按照我的理解,钻取是一种复杂的数据分析手段,
我首先想到的是数据之间的层级关联关系如何管理,是自动发现还是手工配置?
如果自动发现技术上会有很大的难度,而如果手工配置,则界面应该比较复杂。
可我们的老板完全不这么理解,他认为只要实现“父-子”拓扑,并能够向下一层层展开即可,
让我觉得不可思议是,用户真的接受这种理解。
当然,这也许不是一个非常恰当的例子,但足以说明,
技术人员和业务人员之间,对同一套词汇的解释有很大的差异性,
了解业务,我觉得就是站在用户的角度考虑问题,站在行业的大背景下考虑问题。
关于第二个问题:如何将个人的力量,转化为团队的力量?
在人少的时候,大家都是哥们一样的,大家都把开发作为一种乐趣,在工作上有共同的价值观,
这是一种很美好的状态,每个人的效率都很高。
但团队肯定要变大,人多了,管理不善效率就会下降,事情就会失控,怎么办?
我在这方面想了很多,包括管理者的风格,宽严的尺度,团队的文化,制度的设置等等,
我一直向往一种比较理想的状态:那就是无为而治。
实际上这种想法还是有些来自于软件设计的框架思想,
设定适当的原则,纳入合适的人,每个人都为特定的目标而“主动”努力。
我一直在尝试这种方式,实践证明,在建造新的团队时(尤其是可塑性强的新毕业生组成的团队时),
这种方法非常有效,
但用于改造既有团队,则需要的时间和面对的阻力都要强一些。
我设定的原则很简单:
每个进入这个团队的人,都要求积极反馈、有效沟通、树立质量意识。
这样,经过一段时间的磨合,团队会形成一个自驱力,也就是不用管理者推动就可以向前走。
在这一年,看的书基本上都是温伯格的,有三本个人感觉帮助比较大:
《探索需求》
《你的灯亮着吗》
《成为技术领导者》
接下来我会做个专门的介绍
---
谈到“转型”,我相信多数人的第一反应是从“技术”转向“管理”,
我倒觉得未必一定如此。
我将转型定义为“思想的转变”
,是一种自我改造,结果是境界上的升华,是考虑问题的角度和处理问题的手段上的转变。
按照这种定义,我从05年开始主动的考虑“转型”,到现在很多年来都是处于“半管理”状态,
其间做过项目经理、部门经理、产品经理,
管理是我工作的职责,但一直没有成为100%,所以我也从来没有间断过开发。
不是不可以做到,而是觉得完全脱离开发不安全,也不甘心。
一定会有人说这是失败的转型,
可是我觉得,正是这样一种看待开发的观念,造成了大家对30岁的恐惧,
其实坊间不自觉的将开发视为下等工种,而将管理看作是上等工种(也许我选词不当,但我相信大家明白我的意思),
而你我都浸淫其间,受到这种文化的熏陶,所以才有这么多人刚入行,甚至没入行就在前瞻“转型”的问题,
可是,技术和管理应该是软件行业的两条腿,重要性是一样的才对,
有些人天生是技术达人,转向管理不仅是人才的损失,也让自己难受,
况且这种跨工种的转型(无论从技术转向管理,或者从管理转向技术),是有风险的,未必每个人都能胜任新的角色。
我希望,我也相信,随着中国软件行业的生态环境逐渐趋于合理,
我们的程序员,只要在一个方面做的足够的好,足够的精,哪里都少不了他的生存空间。
相关文章推荐
- 十年总结(16):主动的自我改造(或者说转型?)
- 看看别人研究生在做什么,在看看自己---推荐《我这十年》-----一个研究生的自我总结
- 我的十年总结——送给刚毕业的年轻朋友们(转)
- 转:十年总结-开篇:歇一歇,才能走的更远
- 我学习CRC32、CRC16、CRC原理和算法的总结(与WINRAR结果一致)
- Mysql学习总结(16)——Mysql之数据库设计规范
- com多接口调用------------自我总结
- js表单验证自我总结
- 由点及面--百度CRM团队敏捷转型实践分享总结 推荐
- Linux中的echo简介(自我总结)(44)
- 点阵字体 ASCII码 汉字库 自我学习 简单总结
- delphi中转换office word文件为HTML文件,或者其它类型的文件的一些总结
- elasticsearch内部原理自我总结
- 自我感觉。。第一阶段unity总结。。
- 游戏编程十年总结
- [测试十年]搜狗测试第一年:主动学习篇
- 十年工作总结
- 十年总结(20):售前养成计划(下) - 辽沈战役
- Android中SQLite以及ContentProvider自我学习、理解、失败之总结
- 随笔-uint8_t / uint16_t / uint32_t /uint64_t 是什么数据类型 - 大总结,看完全明白了