十年总结（22）：告别最后一位元老级人物，轮回到一个新起点
对我过去感兴趣的朋友们，请看十年总结系列文章
－－－
重庆项目结束后，团队的最后一名“元老级”成员离开了，
她其实年初就提出来了，最终坚持做完了重庆的项目才走，的确很感谢她。
每一次有早期加入的成员离开，我都会感到伤感，伤感之余就反思自己的坚持是否有价值。
这最后一位元老的离开，表示一个时代过去了，我也应该反思作为带头人的失职之处。
我一直有一个信念，那就是要通过成就一项产品来成就自己。
于是有那么几年，我都没有计较过报酬，只是一门心思要做出一些成绩。
我也一直认为，或者说希望团队的成员也有相同的信念，
然而事实告诉我，这不太现实。
在此之前，我对领导者的理解有错误，或者说是片面的，
我过于关注作为领导者管理团队职能，而轻视了领导者为团队谋求的职能，
也就是说，经常只知道向别人提要求，却很少想拿什么来要求别人，
我以为公司会看到每个人的成绩，然而，能真正为员工考虑的公司，毕竟少啊！
这应该是我在管理方面的一次顿悟。
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次了，大家别嫌罗嗦http://blog.csdn.net/jinxfei/archive/2009/08/28/4491731.aspx）
JBPM的user guide中有一章“Graph Oriented Programming”，我觉得是整篇文档的精髓所在，
有学习JBPM的朋友，建议一定精读之。
OneCMDB。
这是一个很小的开源项目（现在也不小了），实现了一个简单的配置管理数据库。
由于文档比较少，所以我直接在产品中整合了源码并做了比较深入的研究。
该项目的文档很少，而且主要用来定义“概念”，
什么是类别、什么是值、什么是关系、什么是属性、什么是配置项。
虽然所用笔墨不多，却很清晰的勾勒出项目的结构，
那么我自己写的设计文档，是不是也应该将问题域中的概念交代的明明白白，然后再去描述功能呢？
总之，这一阶段的工作还是比较开心的，团队在走向成熟，我也在走向成熟，
而我的Baby，不久也要出生了。
－－－
衷心感谢陪我走过产品研发这条路的每一个人。
在多数公司，检验成绩的主要标准是“市场”，而不是技术。
国内有多少公司在非法使用免费的开源项目？多数开源项目要求使用者也开放源码的。
大家怎么看待“我不过是个打工的”这句话？
[解决办法]
sf
[解决办法]
没有了么？写得很好 呵呵 你这产品听着和我们公司的bsm很像。。。。。
[解决办法]
十年总结系列文章
值得一看啊，看看前辈的过去
[解决办法]
lz真是有心人。
[解决办法]
see see
[解决办法]
cc
[解决办法]
“我不过是个打工的”
最近自己经历了一次职场的变动 现在的我的想法只有一个,就是"开心地工作" 在这个基础上,再成就自己的事业心.
其实工作中需要的是"职业",无论你喜欢还是不喜欢,但是你的做法必须要职业,做到职业了,也就没有“我不过是个打工的”这个说辞了
[解决办法]
关注每一个细节!!!
[解决办法]
学学前辈的经验
[解决办法]
感觉关于“开源”这方面，国人比不上外国人，别人说开源就是开源，而我们就只知道用别人的源码，而自己的东西却从来不开源（当然不排除有这样的好人）。
[解决办法]
楼主的十年总结系列文章看完了，感觉楼主太厉害了！
感觉楼主的责任心很强、态度很端正，同时感觉楼主一定很忙吧，想了解一下楼主这样的牛人时间是怎么安排的（比如工作时间、生活时间、学习时间）。
[解决办法]
写的很不错。。。 记得LZ 帮过我不少忙
祝福你将有的宝宝健康
[解决办法]
跟随楼主
[解决办法]
你儿子两岁了！！！
[解决办法]
我不过是个打工的——这状态很好。
公司吗，司--做事情的地方。公司--大家一起做事情的地方。有自己的最求，最好不要强加在别人身上。对一个员工而言，你能要求他同生共死？反正我做不到跟公司同生共死的。
有人说这句话，不是很好么？人家把工作方针亮给你。以后安排工作的时候，记得注意就好了。如果不能完成，你也很好办。大家都方便，没什么恩怨之说。不过，你要是XP的那种团队，这样的人明显不适合。
不过，职场上，说这句话，恐怕都有背景的。有可挖掘的东西。这也是一个manager要解决的问题。
[解决办法]
我不过是过来打酱油的...LZ的生活的确跟偶们普通的码农不一样 不过看完之后也是种对未来的憧憬啊...
我不过是打工的...有点推卸责任的意思 不过很正确 很直接的说明了公司的利益不是自己的利益 自己只关系公司给他的利益 同样 自己只是被公司使用 本身没有对这个公司任何的期望在里面 自然 如果出了问题或者需要决定 这种人也不会承担的...毕竟只是打工的
[解决办法]
说自己是个打工的,并不是推卸责任,就连唐骏,李开复都是打工的
而是要清楚虽然是个打工的,但是在不同的职位,就要有相应的责任和义务
[解决办法]
我记得楼主有一篇叫做“怀着创业的心去打工”。
[解决办法]
宝贵经验
[解决办法]
支持一下
[解决办法]
欣赏LZ的态度 加油！
[解决办法]
我不过是个打工的-------------感觉有点推卸责任
----------------------------------------------------
这句话说出的时候一定是和老板冲突 或者受到什么委屈
我感觉只要自己尽职尽责完成任务 没有老板闲的没事给你找茬
（可能我刚入社会 入世很浅 没遇到大风大浪）
[解决办法]
