2015第27周周记：继续被批评

这个周末，又加了2天班。昨天从上午10点搞到晚上10点，之后同事请去吃夜宵。本来今天不想去的，但想想周一测试部门又等着新版本，于是今天也去公司加了几个小时的班。

项目实际上已经处于失控状态，至少在公司领导看来是这样的。上周二大boss叫了项目经理(就是我)，项目代表和其它相关人去他办公室开会，把每个人都批了一遍。虽然我刚来公司时就已经知道了领导只看结果不重过程，当时再一次深刻感受到。会议要求每个人发会议备忘给大boss。

从这次会议上看，很多方都有责任。首先我的责任是没有全局把控好时间——在公司，时效性是最重要的。其次是人员问题，其它部门扔了一个新手过来。但公司层面给我们的解释是项目不培养人，只用人——但事实呢？

我很想为自己辩解，事实上，这个项目，很多事我都亲力亲为。相对Alpha、Beta版本的项目经理，我除了继承着开发人员角色外，还担任着项目的管理角色。对于我自己的模块外，还要和多方扯皮，确认事务。比如，上周一个测试人员突然请假(虽然事出突出)，最后安排一个未接触这个项目的人来测试，连securtCRT也没用过。又比如项目中的新手，连svn也使用不畅，至于项目流程或业务能力，也是有很大的提高空间。如果再有这种事，我真的会提点心。——何况，我不想再有这类事发生了。这次，入坑了。

对于项目，我认为人员的技术水平要考虑的一个因素，如果时间紧急，不能有新人，如果有新手，时间上又得不到保证。 部门例会上主要以最近部门同事完成的一个事务做检讨。讲解了事务的来龙去脉，和其它部门的交互，特别是测试部门及该部门所反馈的意见。一来以实例说明开发流程，二来看看有哪些不足，如何避免。 后来让大家发表意见。 我是站在开发人员的角度来说的，特别想了解一下当遇到技术问题延期时公司层面会不会考虑，另外也想了解一下我们部门做的东西在外面使用的反馈情况，比如之前解决的网络问题，我是不知道在外面有没有在使用，使用得怎样。当我知道某一事时，大约是出了问题，而且一般都是较严重，较紧急的。

——但没有明确的答复。

对于我们这个部门，实在有太多想说的，但一时又不知从何说起。 我认为很大一部分原因是部门职能的定位。因为定位不清晰，有一些事务上无法确定界限，就会造成扯皮。有的部门十分擅长扯皮和推责任，而我们大多数人只想把事情做好而做了让步。但这在主管认识上认为是软弱的表现。如果真的很强势，每事按流程走，我估计公司整天都会在这些口舌之争上，而没心思干活。比如，对于其它部门提交的模块，我们一般没有按正规的流程验收，但我们提供的东西，都必须要有自测报告。像我，但凡和Linux有点关系的问题，都找我。比如有的业务程序本身有问题，但它运行在Linux之上，出了问题，就感受是平台的问题。像网络广播包，有的人不会去想程序逻辑上有无问题而直接认为是平台提供的网络socket函数，应该找平台的人。

由于部门职能的定位较杂，因此做的事就比较多。比如职能中有支持其它部门一项，年初时就友情支持总公司下属的子公司的同事。但功能却是其它部门的，这是公司组织构架所决定的。当其它部门有难题解决不了，就会派到我们部门。当其它部门人手不够，就会从我们部门抽调人员协助，明义上说是两个部门交互较多，我们部门的人去学习，以更好地方便工作。结果有一个人最后转岗了，人走了，事没走，原本是13个人干的活，变成12个人干了。凭什么你的部门说难招人就从我的部门抽人？你会说：你不会招人啊？那我反问一句：你不会招人啊？ 这些，真不知为什么会发生。

上周，小外甥女做了心脏手术，打电话给妹妹，说手术顺利。现在每天的费用都在1K以上，我转账的几千块，还不够顶一个星期。 出生月余就如此，只怪命运无常。有时，健健康康地生活，平平安安地上下班，也是一件幸福的事。 但愿一切安好。

2015.7.05 周日 晚上