思考控

《程序员》杂志的“一分钟先生”专栏之前曾约稿，有两个主题可供选择：制定绩效目标或如何进行绩效面谈。本打算两个主题都写写的，但碍于时间有限，最终只写了一个主题：《制定绩效目标的几个重要因素》。进入12月，想必各个公司或组织都会开展年终绩效考核，我这里也不例外。 ...

我个人一直追求高效的工作，无论是在职场中的哪个环节，在我眼中总是应该有提效的空间的，我甚至感觉我在这方面似乎形成了一种偏执，有些时候一看到低效的环节，我就有些情绪激动^_^。 ...

Mail(在这个时代，Mail默认的含义早已变成了Email，也就是电子邮件)是我们在工作中常用的表达和沟通方式之一。与IM工具、拿起电话直接Call、会议等相比，Mail容许相关干系人用更多的时间去了解背景、理解问题和思考解决方案，而不用立即予以答复。 ...

时间是人类最宝贵的财富之一，我十分认同这点，因此我在个人时间管理以及工作效率上也是一直追求持续改善的，期望能在最短的时间内产出更多有价值的成果，尤其是工作时间里。 ...

本文是笔者发表在《程序员》杂志2012年11期上的那篇“制定绩效目标的几个重要因素”文章的完整版。 软件开发是一种创造性的工作，这种工作的成果具有不确定性且很难量化，因此经理们在给员工制定绩效目标时多没有统一标准(即便有也不一定准确，而且在一定程度上还可能会扼杀创造性)，所采用的方法也是五花八门。不过即便如此，经理们也没有放弃寻找一种更为适合软件开发领域绩效目标制定的方法。笔者也是其中一份子，在这里我将就如何制定出合理的绩效目标，与大家分享一下我的工作实践。 ...

时间真是过得飞快，遥想一年前的这个时候我们在产品线的知识管理试水有了一点成绩，便在组织内力推知识管理。领导经过权衡后，也认同了知识管理的重要性， 并随即安排人在组织内部快速建立起了知识库。在最初的一两个月里，临时的知识管理负责人热情很高，做得还算不错，初步地将知识库是什么、如何使用以及组织 知识管理的第一版规范和大家交待清楚了。但随着热情的消逝，知识库管理也随波逐流了，知识管理开始变得名存实亡，这种状态持续了大半年。 ...

上周得知今年一个重点项目跳票了！项目计划正在重新修订中，原计划今年10月末完成的项目很可能因此推迟到明年上旬了。 工作这么多年，印象中除了一些短期小项目外，50人月以上的项目就少有未跳票的，无论是我带的项目还是其他负责人带的项目，莫不如此。无论是产品负责人，还是项目负责人，高质量按期交付都是第一目标。但残酷的现实真切地摆在我们面前。问题到底出在哪里呢？ ...

昨天中午收到图灵出版的《布道之道 – 引领团队拥抱技术创新》一书，晚上就迫不及待地翻看开来。这是我读过的第一本有关推动组织内部技术变更/创新实践方面的书，感觉书作者对受众的分类很是准 确到位，很多布道技巧也十分值得借鉴。但就我个人多年来的体验来看，组织内部技术布道的结果，不仅仅与受众的类型有关，还与布道者自身的资历、所担任的角 色、组织内部的文化和环境、布道路线以及布道时机和对象的选择有一定关系。下面就是我在这方面的一些粗略心得。 ...

气氛太平静，投石起波澜。 昨天下午无意中在内部发起了一场关于"何时发布版本"的论战。 论战的背景是这样的：部门内部有这样的一个项目A，它的目标是开发出可被其他项目或产品复用的组件(这里就暂称之为组件吧，我们内部称这类组件为可复用资产)。这个项目已经开发了大半年了，目前处于收尾阶段，绝大部分开发工作已经完成。测试(包括压力测试等)已经测试过至少一轮了；我们的产品线近期准备复用项目A成产出的这些组件，我们希望得到这些组件的某个发布版本。 ...

这周五我做了一件"恶事" – 劝退了一名员工。这样的事情在部门成立10年的历史中发生的次数都是屈指可数的，但却真实地让我给碰到了。 ...