最近从七月份还了那一大笔债务后，由于各种原因，公事、私事遭遇了很多事情，几近所有的事情都让人不爽，心情指数也急剧下降，但又苦于不知该如何叙述，更不知该向谁述说，总言之就是矛盾、复杂二词。于是开始对自己进行反思，今天先反思工作职责。
一. 关于工作职责，其实本来也可以很简单。
虽然我是公司在大陆地区唯一的一个研发部门经理，但由于我们公司的产品研发制度采取的是一种Matric模式的 管理制度，在这种制度下，从REQUIREMENT管理到SYSTEM ANALYSIS，再生成PRD，然后再到RD来做SD，并完成DEVELOP，然后交给QA，最近Release产品，每个环节都有很明确的分工，本身 来说，这应该是很标准、很完美的一套制度，而在这套“很完美”的制度下，由于，我并不需要处理太多的管理方面的工作，甚至也不需要我做太多的研发文档，所 以，一直以来我对自己的定位是：
1) 作为一个资深研发人员，负责公司核心技术产品的开发。
2) 协助SA & PM完成各种Spec or PRD document的撰写。
3) 对一些研发中的主要技术难点进行攻关。
4) 在协助Team下的员工（新同事或者老同事）完成一些他们无法完成的、或者是无法独立完成的工作。
5) 对Team下的员工做一些简单的激励和鼓励，如：阶段性的和Team下的员工一起打打球、唱唱歌什么的。
二. 在实际工作中碰到了问题
公司的制度是非常完美的，本来按上面讲的那样，我已经决定应该会工作得很快乐，并且绝对不应该产生“情绪”。然 而事实上，这套完美的制度在实际的操作与运营中，却又真的出现了很多不该出现的问题，最大的问题，我想应该跟所有的IT公司一样（或者说是跟所有的软件公 司一样），那就是Schedule的delay，并由此而引发各方面的不满。对于此很难用几句话来说明清楚，我只是想站在一个纯RD的角度来试得解释和说 明一下我的理解，同上配上我的一些不怎么make sense逻辑（由于最近一直很不爽，所以借机发泄一番），我认为导致目前的状况的原因，从简描述的话应该有以下几点:
1) 缺乏沟通；
2) 缺乏激励制度；
3) 产品研发管理中诸多环节无法得到很好的衔接；
4) 缺少起码的人文关怀；
以下是对于上述问题的一点我的理解（别的部门我无法对评论和指点，因为那不该是我去管的事情，所以，以下所有的观点仅仅针对大陆RD部门）
1 缺乏沟通
在这几点问题中，我把缺乏沟通放到了第一位是因为缺乏沟通直接导致了其他很多的问题。单纯的从RD部门来讲，缺 乏与HQ的沟通，缺乏跨部门之间的沟通，导致RD根本无从知道公司的运营状况，而这样的结果就是导致RD对自己的前景无法作出很好的判断（更别说是正确的 判断），在这样的背景下，有一句俗话更容易被放大，这句俗话就是“好事不出门，坏事传千里”，其结果就是直接导致部分“体质”较差的人“生病”。
而且对于这一点，我也必须数一数与此相关的“恶行”：
1.1. 公司层面
从来没有什么好消息。概念里根深蒂固的观念：RD不需要知道外面的任何事情。Sales拿到了什么单子，什么产品接了什么客户等等，从来不会有什么喜讯通告，更不会有人来告诉上海。
公司的对产品的一些规划、计划也从来没有到达过上海的RD，不管是讨论，还是结论。对于此，我听到下面的人抱怨最多的就是：
不知道自己在做什么东西，因为光从上海来讲，我们投入95% effort在做的东西没看出来有任何意义，相反投入5% effort 做的东西却基本上可以养活上海整个Office。
1.2. RD内部
a. 没有工作统筹说明。
由于有些工作过于细分，大多数情况下RD只需要根据定义好的Spec去做自己的部分功能即可，但如果能在功能启 动开发前就有一些统筹说明，岂不是更好？既有利于每位RD对整个产品的理解，从而更利于RD在实际开发时能更好的对相关功能，甚至Spec发挥、发扬，又 可让整个Spec更趋完善。
b. 不会有任何产品规划说明
比如：一到三月份做计划做UE；四到五月份计划做CMS等等，从来没有人会来告知RD。
c. 其他
当然这些跟前面讲的那些一样，事实上对于普通员工来讲，许多事情告不告知，就此本身来说可能都无可厚非，告知也 行，不告知也没什么不对，但是站在一个普通员工的立场来讲，如果你被告知一些可能本来他不需要知道的事情，无疑会让他对公司的未来更有期盼，更有期待，也 更让他觉得自己是公司的一部分，不夸张的说，就像是家的那种感觉。
1.3. 个人层面
作为RD Manager，本来我应该是充当一个桥梁的角色，来协调大陆RD与HQ的一些关系，但是很不幸，我没有做到这一点，我也曾经做到一些尝试，但结果显然没 有任何作用，而且基本上我除了07年在台湾的时候有幸和我的老板在新竹的会议室讨论过一次问题外，基本上从来没有再直接接受到主管的任何会议要求、管理方 面的询问、哪怕职责上的责骂（而对于这一点，有一位新竹的同事跟我讲他老是被他的老板责问，他觉得不爽，我就直接告诉他，老板会来问你，说明老板重视你， 老板要是不重视你，人家理都懒得来理你），即使有这些需要，那也都是通过一个第三方的人来做这些事情。而这样时间一长了后，我也变得越来越消极，也慢慢的 不再主动的去找我的老板。
再加上公司的Matrix产品研发管理制度，事实上，我也完全可以不必去对手下员工的Schedule等做什么 管理，因为有专门的PM、SA会去对每个RD去盯Schedule，我也只是大致知道下面每个人最近大致在做什么，至于做得怎么样？对不起，你可能需要去 问PM问SA；如果他们有问题，自然会来问我，没问题也不用我去管。
而最终现在的结果是部门内的沟通也越来越少，鸿沟越来越大。
有时候我自己总结也觉得自己需要再更加积极一点，但再想想以目前的管理制度，以实际的状况而言，我更觉得自己像 是一个名义上的Manager。因为没有参与到PM、SA的WBS assignment，更无法对手下的员工的Promotion、薪资等产生任何实际意义的影响，所以我无法也没必要无法对手下的人的工作内容、 Schedule进行管理及追踪。
所有我能做的也就是我前面讲的那样，几年后我对自己的职责定位就变成这样。
简单讲，我的表现是消极的，我对自己也是失望的，但我没办法改变现状。
1.4. 我的一点想法
实话实说，我是有一些怀念三、四年前在那种状态。
那时候比现在忙多了，而且动不动就加班，甚至是连续的通霄达旦。
那时候每个人的目标都很明确，因为每个人都知道自己在做什么事情，前景是什么可以看得一清二楚。
2 缺乏激励制度
对于激励机制，我想任何一个公司的任何一个人都无法否定它的意义，虽然考虑到其操作方式，可能每个公司都会有所 不同。但是在UniSVR虽然中间有很多的过程，而且从几年前开始到最近，我也有多次正式或非正式的向我的前后两任主管及公司总经理建议，但基本上每次得 到的答复都是标准而统一的：因为无法衡量。
而最近我们的总经理则是比我的两任主管多了一个说法，公司目前正在重新推广RD的执行效率的管理制度，也即 ClearQuest（由IBM Rational所推出的一套Defect & bug track tool），并由此参照每位RD所解决的Bug数目，及Task item的Reject & redo 次数，以评估RD的研发效率，且还有很重要一点是，如果要衡量她希望是不需介入人为的因素，以避免出现“我跟你谈得来，我就给你评价好一些；我跟他谈不 来，就给她评价差一些”等等状况。
但事实上不介入人力怎么可能做到？我深深的表示怀疑。
我也当场跟她说明了我对于此的一些看法：
ClearQuest的确可以在一定程序上呈现Task owner的工作及工作效率，但是由于我们的Defect & bug是由QA、PM、SA等submit的，而以公司目前对这几个职位的人员配置，
A. 这些人都无法在submit task的时候就能估出该task item的强度（什么是难的？什么是简单的）;
B. 更有甚者，其中的许多item都是错误的（如：QA测出一个bug，然后加上他们自己的一些理解submit上去，事实上真正的原因、甚至现象根本不是如此）;
C. 经常有许多状况是QA测出一个问题，然后由QA submit出来，然后RD来改，结果这个task item 可能被reject N次，但是无法避免的一个问题是QA在测出这个问题的时候，其实是一个复杂功能的第一步出错了，他还没法测到后面的无数个功能….
所以，我认为要靠类似ClearQuest这种Tool来评定一个Task owner的Performance，基本上其意义非常、非常的有限，它的意义更多的是管理层对公司每个产品线的投入的初略估算，也即类似于Time Card之类功能意义，以确定公司的哪个产品线人力投入与产出比例。
同时，我也再次向我们的总经理提出，对于RD如何实现KPI的几个要点（我的观点是要么继续什么考核制度都没有，要有就那没有人为判断的介入是做不到的），所以要谈激励机制，还必须从KPI谈起。
2.1 关于绩效考核机制
对绩效考核来说，无论是什么公司，一旦要想对技术人员进行考核，都普遍是一个难题，因为技术人员的许多工作都无法简单的量化处理，但是以UniSVR来讲，我觉得可以由以下几点做起。
2.1.1. ClearQuest为基础
2.1.2. 提升PM & SA submit enhancements的task 强度细分
这一点我觉得可以由两位以上的资深RD一起对此相关在Basic的程度上进行强度划分，有些功能的实现需要的可 能仅仅是时间；有些功能则可能会是一个Technical point；并配备一位（或者两位）具有相当资历的资深RD，以作为所有功能的Task owner，让其带领一个Team对此下的所有功能及Schedule进行负责，也即他（们）追踪RD开发进程及Schedule，并随时跟踪Team下 每个RD的各种状况：遇到问题了，是什么样的问题，如果能协助他们解决就给予一定的协助，如果因Schedule关系需要同时与Task owner并行Research的就并行Research，同时若是间出现状况，随时与PM & SA及其他资深RD进行沟通及必要的探讨。
2.1.3. 在现有的Matrix产品研发管理制度的基本上，引入一些更灵活的做法
其实说到这一点，我也有很多、很多、很多、很多的牢骚，因为这一点已经积累了很多年了，但是由于这套 Matrix管理制度的确也很完美（但事实上就跟《看上去很美》一样），所以，我也实在无法找到一些借口来直接批评这套制度，说起来也只能是不着边际的跟 人说说那套UniSVR到底是一家大公司，还是一家小公司？UniSVR到底是做产品（Product）的，还是做项目(Project)的？。
但是，我认为可以肯定的是，用Matrix有它的好处，不用也可以在一定程度上提升RD整体的效率和产出。这一点，有很多例子可循：
a) 工单系统
b) 上海电信数字家庭
c) 上海电信97帐务计费接口
d) 移动全球眼3GVAU
这些项目共同的特点是都没有真正实施那套Matrix流程。当然，当我这么说的时候，我们的总经理反驳我说 3GVAU是有的，因为从头到尾她有在追踪这个项目，且有参与PRD的撰写，但事实上我不这么认为，基本上这些项目都是在跟电信谈的时候就直接由RD一边 做Research，一边就直接着手实现的，没有一个真正有经过台湾那边的SA啊、SD啊什么的，而是由我负责，直接在上海成立一个独立的team来专门 负责相关功能的研发，这样的好处是在于：
a)整个team可以更紧密的合作
不再是大家各做各的，每个人做完一个工作后，交给HQ的PM，由他们来协调其他人负责的功能，然后这个做完这个功能的人再去做其它的工作，如此循环。
b)可以做到让整体功能在一定程度上无缝衔接
在原有制度下，基本上很少有人能将整个Project兼故起来的，无论是身在HQ的SA，还是这些在大陆做实际开发的RD。
RD是由于对整个Project or 产品的设计、规划、背景了解有限，无法做到统盘考量，许多功能与功能间的衔接无法兼故与周到；
SA是由于对Coding了解有限，所以当出现状况的时候很容易会出现除了提一些Suggestion外，不知该如何处理的情况；
而通常这种时候，最终搞到头来基本上都会变成是我一个人的事情，我需要对其他RD的问题逐个进行协助排查，乃至彻底解决，可是说实在的，我也有很多问题：
i. 由于分工关系，我对部分Spec也不是很清楚
ii. 我跟其它所有RD一样，同样是许多task的owner，我自己也有很多（更多）事情要做
iii. 我不是王进喜
c)更利于绩效的管理
直接有由HQ
补充：对于总经理所谓的3GVAU，（Mars不算在内，因为当时他在上海），而总经理所谓的PRD其实也就是一个初略的人力及Schedule安排而已，真正的PRD还是在产品初验前五天才初步成型（要做成什么样子，该有什么功能，一些关键功能该怎么实现等等），并在初验成功当天，在电信机房外，Mars和我们几个RD在做简单讨论后决定，暂时就只做成“如此这样”，其余一些功能可以不做的就不实现。
2.1.4. 提升QA人员的整体素量
由RD主导，并和QA一起制订出一套相对完善的测试规则，同时RD与QA定期或不定期的一起沟通、交流、探讨，并制订和完善整个产品线的FAQ。最好是由一些具一定RD背景的人来担任，如无法做到的话，可先由RD之间互测开始。
关于QA与RD之间的问题，请可参阅我的另一通牢骚：http://www.rosoo.net/
而无论是哪一点，我都觉得主导整个测试的都应该是RD，而非QA。
2.2 关于激励制度的尝试
这一点A是由如果，不是由
，而这所谓的经验，我回头想想也
我们公司的RD部门却一直无法得以实施，，但，这一点我想也是导致RD