十年总结（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次了，大家别嫌罗嗦）

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

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

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


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

－－－

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

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

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

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