实习生离职引发的思考：1. 到底该如何的、更好的去凝聚大家的向心力？2. 到底该如何的去协调我的下属和我的上司之间的一些关系？3. 到底是否有必要重新审视对自己工作职责的定位？ 这篇文章写于2010年元旦，当时公司与苏州大学研究生院软件学院有人才输出协议，公司每年固定支持一笔费用给学校，然后其软件学院下的软件工程专业的研 究生，在第一年完成理论学习后，会直接到来我公司实习，实习期为２年，公司会负责所有来我公司实习的学习的学费，同时每月支付一笔实习费，实习期满后，有 优先录用这些实习生的权利。 但是08年年初过来的这一批学生基本上全部在实习期满后选择离开，原因很多，也很复杂，但作为这两年来一直带领着他们工作的部门主管，我真的觉得很痛心。 现在，又过去了两年多，这些人有的去了大公司（如：华为），有的跳了几次槽（但还在IT界），有的当了公务员，有的不知所终，但不管如何，再次祝福他们吧。同时，我自己也需要好好的继续总结。 以下为当时的原文： －－－－－－－－－－－－－－－－－－－－－－－－－－ 今天看到一篇博文，讲述的实习生的事情，心想在过去两年里前前后后有11位来自苏大的实习生在公司工作和实习，但是到现在真正留下的只有一个人，我 作为研发的主管也真是感到的无比的心痛，无可否认这些人中有表现比较好的，也有表现比较差的，但总的来说绝大多数人都差不多在公司工作了将近两年，对公司 的产品研发相关技术、流程都已经有了相当的了解，但最终的结果实在是一个非常大的遗憾，这中间的因素也真的很多，很复杂。既然他们最终选择离开，那我也只 有祝福他们。同时也一直在思考： 1. 到底该如何的、更好的去凝聚大家的向心力？ 2. 到底该如何的去协调我的下属和我的上司之间的一些关系？ 3. 到底是否有必要重新审视对自己工作职责的定位？ 如果要在这一点上做调整真的很难，但又真的很重要，尤其是现在已经开始着手激励制度的试行，而且以最近发生的几件事情（离职报告、考勤制度等等）来 看，这决非这么简单的事情，我只是尝试着去做一点点的调整，但事实上即使仅仅如此，就已经困难重重，每个公司内部都会有层层的利害关系，说难听点可能都会 有一些比较官僚的制度，尤其是将你所需做的一件事情是需要跨部门的时候，更甚之…… 下为原文： —————————————————————— 跳槽？跳槽！ —————————————————————— 今天，我在微软全球技术中心实习的时候的同学兼同事告诉我他跳槽了，跳到了UBI去做游戏。理由有很多：工作太累，加班没有补贴，做得活太detail，没法对软件开发和软件工程形成一个宏观的理解，不可能转成正式员工…… 从他那里也了解到，由于GTEC换了新的大老板，Dennis Lam已经去其他地方工作了，大老板正在竭力压缩开支，免费的工作餐取消了，报销车费取消 了，正式员工也是能不雇佣就不雇佣，待遇已经今非昔比。去年我在的DSV组的同事，现在走的走，散的散，重组的重组，还剩下十几个人了。想当时我在那里实 习的时候，鼎盛时期DSV组有三十多个人，是Microsoft GTEC最大的组，没想到仅仅半年时间，现在却“人心惶惶”，真是时过境迁阿。虽然仅仅 实习了八个月，虽然最后没有选择留在微软，但是那毕竟是我的第一个工作的地方，就像一个人的启蒙老师一样，始终都还有一份感情，始终都还想着有朝一日能再 回Microsoft效力。 但是再想想，很多人尤其是vendor从GTEC跳槽也不是偶然的，工作强度高我是深入体会的，虽然理论上每天只需要工作八个小时，但是很多同事都是一天 干一天半的活，晚上加班到十点是正常的。当时凭着自己对Microsoft的激情，倒也干得任劳任怨。可是，仅仅是激情就够了么？激情过后，剩下的是什么 呢？ 考虑的再多一点，现在好多的外资IT企业，尤其是一些享有国际声誉的知名大型IT企业，近年来在中国都建立分公司，或者“研发中心”。凭着“还说得过去的 薪水”和企业本身的名声，把大量中国的优秀IT人才揽于麾下，与此同时，具体工作的内容呢？很多都是与公司的核心技术根本不沾边的内容。还有些更直接，做 外包。记得某号称“玻璃巨人”的IT企业中国软件部门领导在同济大学软件学院做报告的时候更是赤裸裸的宣称“在中国这个环境下做软件，只能做外包。”。这 样拿着中国的优秀软件人才当廉价劳动力赚钱的外企，进去了除了能得到个听起来还不错的名声——“世界五百强XX公司员工”——之外，得到的还有什么呢？暑 假的时候我有幸在国内某个做国产系统支持软件的公司实习。实话实说，与那个公司的员工交流的时候，感觉他们的smart程度至少要比 Microsoft Guys低一个档次。国内最一流的软件人才都去了外企，留下了二流三流做中国的核心技术。这或许也是中国软件产业落后的一个原因 吧。。。
团队建设
最近从七月份还了那一大笔债务后，由于各种原因，公事、私事遭遇了很多事情，几近所有的事情都让人不爽，心情指数也急剧下降，但又苦于不知该如何叙述，更不知该向谁述说，总言之就是矛盾、复杂二词。于是开始对自己进行反思，今天先反思工作职责。 一. 关于工作职责，其实本来也可以很简单。 虽然我是公司在大陆地区唯一的一个研发部门经理，但由于我们公司的产品研发制度采取的是一种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% […]
关于职责工作的反思（草稿）
这也是我在多年前针对公司的一些研发与测试之间的各种状况而发表的一点个人看法，原先po在我的另一个网站：http://www.rosoo.net/a/200909/7475.html。而事实上对于这个话题其实一直以来都是一个很大的课题，而且每个人，或者每种角色对此的看法都不尽相同，同时我相信这个话题也会一直延续下去，不管是数十年前，还是现在，亦或数十年后，永远都不会停止。同时，在这几年来又有持续出现一些与这个话题相关的讨论，如：“单元测试要做多细？”，一个测试人员的反思!，当然，还有更尖锐、直白的一个讲法：我们需要专职的QA吗？ 这都说明了同一件事情：测试很重要，但具体测试的该怎么做？甚至谁来做？我们需要持续的、不断的探讨。另外，我还需要再声明一下的是，我讲的只是基于我个人所在的环境及当时的经历，在不同的环境，不同的经历，不同的时间，都会有不同的结论，简单讲就是：这一切都没什么对错，你只需要找到最适合你现在的状况的一种做法。 以下为原文： －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 鉴于公司目前的QA没有一个是拥有RD的背景，且在submit defect & bug的时候经常会出现一些非常低级的描述错误。 举个最简单的例子： a) 看不到图像。QA submit一个bug说是看不到图像，但基本上没有一个QA会在bug现象里说明看不到图像的时候，Server有没有流量？Client有没有流量？相反许多时候，加了说明可能又是错误的。 b) PTZ不Work or delay。 c) 没有收到警报。几乎从来没人会认真的去观察哪底是哪一段的错误导致没有收到警报，是设备没发出来？还是UniArgus Server的几种可能性？ …. 当然，我这么说并不意味着我作为UniArgus整体产品开发的RD主要负责人想推卸责任，我只是觉得如果把所 有的责任都推到RD的身上，所有的问题都是由于RD在开发时没有做好测试而导致的这种说法感觉有些不能接受。可以肯定的是RD的确需要加强 integration test，但还有很多时候QA的整体能力和素质也有待提高，UniArgus的产品就这么一些功能，QA每天都很辛苦的重复重复再重复的测试，对于许多问 题其实我觉得他们早就应该很有“经验”了（QA应该早已很清楚出现一些常见的问题的时候可能是什么原因导致的，应该怎么去确定，也即诸如之前一直在上海强 调的FAQ管理），不过话又说回来，如果我是一个QA的话，每天就这么“机械的重复”，也是很容易会麻目的，所以坦诚的说，事实上我也很难去怪QA（因为 其实在这一点上，RD和QA是完全一样的），更何况UniSVR的QA就这么几个人，他们每天都那么忙，而且以目前的状况他们不可能把对Program的 理解上升的RD程度。 因此，考虑到实际的状况，我的观点是： 1. 测试规则的制订 如果要定测试规则的话，应该是由RD和QA一起来定才会比较合理，QA会告诉RD他们是怎么进行测试的，而RD 则可以真正的将所有功能的关联起来，因为RD可以将功能直接细到哪几行Code，而这些Code可能会影响到其他哪些功能，这样的规矩才是真正完善的规 矩，同时这也有助于提升QA测试的完美程度。 2. RD和QA需要定期or 不定期的保持沟通 这一方面是由于目前的UniArgus整体产品并没有真正定型，所以有时候的一些修改可能是颠覆性的修改，那样的话，与此相关的功能肯定需要重测，同时测试规则也可能需要重新定义。 另一方面，RD应该保持对QA做一些基础的、必要的training，并整理和完善与产品相关的一些FAQ。 3. 规则外的一些测试 RD的优点是对整个产品的流程比QA更清楚，但有许多许多时候这个优点其实是最大的一个缺点。就是因为RD太清 楚一个大功能的每个步骤，第一个做什么，第二步做什么，最后才能做什么，常常有状况是RD自己测没什么问题的功能，一到了QA就问题百出，所以，在测试上 还必须加入并加强规则外的一些测试。 4. 最后当然是政策的执行