三个人的2012-工作篇
初六的早晨，刚从老家回来，坐在出租屋的阳台上，阳光灿烂，竟然是北京难得的好天气。距离上次写年终总结已经过去好久，打开博客，发现上次写年终总结已经是四年前的事情。上次写总结的时候还是在东直门温暖的办公室里，随着年龄的增长，觉得时间过得越来越快，四年时间，发生了太多太多的事情：有小孩了，换工作了，最重要的，是三十了。三十，意味着很多事情，古人说，三十而立，对我来说，更重要的是有了更多的责任，不仅仅是家庭，工作也如是。
年初负责的第一个项目是配置管理组的运维自动化项目，简单的说就是将之前手工管理的20多台机器使用puppet管理起来。想一想，命运真是讽刺，就在一年前，在上一家公司，自己还对持续集成工具不太感冒，不愿去学，甚至认为有些太难：机器环境的管理、构建工具、jenkins、puppet/chef、shell，觉得这些东西太琐碎，一心只想写代码。换了工作，阴差阳错，先到配置管理组工作一段时间，必须学习这些东西，过程就不多说了，只有一个感悟：很多时候，你觉得太难，只是因为你不了解它。用了两周时间，将整个puppet环境搭建起来，一切皆SVN，一切皆代码。
接下来的第二个项目是负责调研搜索新架构的自动化发布方案，这是跨部门的合作项目，大大小小跨越20多个项目组，这其中还包括了运维同事、测试同事和云计算基础服务的同事，调研一礼拜，实际上事前准备了很长时间，仅仅那一周的调研计划就修改了四版，系统整理了整个新架构的架构方式，和对方领导达成一致，取得他们的支持，了解大家的期望：开发同事希望能够更快更有效率的发布代码，测试同事希望测试的代码与发布的代码同源，运维同事希望发布过程能够遵从规范可控，当大家对共同的目标达成一致时，方案就顺理成章了：持续集成服务器负责一键编译测试打包上传到包服务器，包服务器保存所有的预发布包，预发布包经过测试后才转为发布包，发布包透过发布系统一键推送到Torca集群调度系统，Torca完成最终集群的发布调度。相比老架构，感觉新架构最明显的提升是：下载、索引和检索三大模块被分离成各自独立的服务，独立演进；统一的数据管理平台，以前追踪badcase很难判定是哪个模块处理数据出了问题，现在透过数据管理平台，数据处理过程被可视化可追踪；统一的脚本执行系统，所有脚本以及执行过程透明可视化；云计算平台，XFS文件系统、Xcube数据库、Torca集群调度、mapreduce并行计算，这些服务大大简化了上层应用的开发。越来越体会到架构的本质：随着系统的演进，我们需要不断进行系统的分解，做到服务的独立演化。当然当时也有困惑：当所有的希望都被压在新架构身上，毕其功于一役，现网老架构停止开发运营时，项目的风险可想而知。做完这个项目，感悟有两个：一是机会只青睐有准备的人；二是跨部门沟通一定要找到共同的利益点，一定要多换位思考。
4月份，准备调回项目管理组，去云计算基础架构部做项目经理。在配置管理组的最后一个项目是Jenkins的报表系统，只有一周半时间，最开始准备使用scala，考虑到后续维护最后使用了java，好久没有编码了，找回久违的感觉：打印出IDE的快捷键，搭建开发环境、测试环境和产品环境，jenkins一键自动部署，数据库版本管理，TDD，一周半的时间就上线第一个版本，最后还不得不赞一下jenkins的rest api。感悟是：感谢一期开发时间只有一周半，这使得我们不断思考到底我们要做些什么，哪些是我们最紧急最需要的，哪些是锦上添花的，一期上线后，唯一也是最大的好处就是：我们再也不用手动统计和发送构建周报了，每个礼拜一再也不用那么忙碌了。时间盒，很重要。
终于转回了项目经理，去云计算，牛人聚集的地方。首先仍旧是补课：计算机原理、Linux系统编程、C++ primer，一个都不能少。去了没多久，出现了一起事故：搜索模块对云计算SDK的依赖是源代码依赖，云计算有5个产品，但是一个产品单独发布时与之前的SDK不兼容，一发布就直接导致了大量搜索模块的无法编译。正好由我负责来推动解决这个问题，立了一个发布流程规范化项目：通过规范化发布流程、增加自动化集成测试，减少云计算平台的发布风险。所有SDK统一打基线发布，发布前必须进行自动化集成测试，server发布时也要与所有SDK版本进行兼容性测试。随着项目的进行，逐渐融入了这个部门：这是一个工程师文化非常强烈的部门，所有人都在技术上追求卓越，加班到10点以后是非常常见的事情，单元测试覆盖率令人惊讶的全部达到85%，但是很多同事一听到规范和流程就头疼，项目计划也是比较随意，延期比较常见，另外因为之前发布版本升级比较随意，也会经常受到上游兄弟部门的投诉，有很多次出现问题，兄弟部门抱怨云计算平台不稳定，而仔细检查后发现很多时候是使用的方式不对，比如查找文件时使用了遍历。逐渐意识到，部门最大的问题其实是缺少产品运营，大家的关注点全部集中在产品本身上（吞吐量、最大存放文件数、强一致性），或多或少的忽略了用户。5月下旬，风神项目启动，项目目标是搭建台风统一的监控平台和自动化部署框架，打造一站式的台风服务。开始在项目中引入项目管理的实践，WBS是最基本的了，迭代计划找到开发节奏、回顾、每个迭代结束后都努力向线上发布版本，实现持续交付，工程上则将开发环境与线上环境进行了隔离。效果都还不错，但思考更多的还是，我们还应该做些什么。产品发布规范化，必须通过自动兼容性测试和周知用户；集群环境的修改必须可被审计，暂时不能自动化，那么先必须周知部门内同事或结对操作；监控有风神项目，但集群运营、用户数据、可用率日报也需要发送；开发、测试和线上环境互相隔离；定期和用户进行主动沟通，了解他们的问题。这段经历的感悟很简单：产品的核心在于运营，作为服务部门，我们交付的一定是用户满意度而不是产品。
紧跟着，新架构还未上线，组织结构调整来了，喜欢ls的直率：我现在的任务很简单，就是看到哪里有山头就把它给平了，所有人都必须听我的，所有人的思路必须一致。
在敏捷中国大会发表了演讲《百年历史看管理》，这个session足足准备了2个月时间，重新思考了流程、组织结构和人之间的关系。从20世纪初到40年代，管理科学完成了从无到有的第一个阶段发展，这个阶段最重要的成就就是将管理作为一门科学建立起来，发现了管理的三要素：工作流程、组织结构和人，并振聋发聩的告诉所有人：管理是可以学习的。我们可以看到，所谓管理，都不过是在流程、组织结构和人这三者之中进行权衡调节，管理没有固定模式，只有不同企业根据不同情况在这三者间权衡裁剪罢了。如果说管理科学的第一个阶段是在探讨如何正确的做事，如何提高工作的效率，那么50到60年代这二十年管理科学的第二个阶段则是在探讨如何做正确的事：以顾客为中心、做事之前一定要想清楚做事的目的。管理至此也终于有了一个完整的定义：做正确的事、正确的做事。从70年代开始，管理科学进入第三个发展阶段，在这个阶段，首先提出的思想就是没有银弹，管理是一门艺术需要柔性，接下来就是流程的内涵开始延伸，不再是单纯的工作流程，而是面向顾客，强调端到端满足顾客需求的整个过程，这个过程在全球化背景下越来越强调企业之间的协调、强调整个面向交付生态系统的协调，业务流程的概念被提出。进入新世纪，不管是更合理组织结构的思考（扁平化），还是对人的推崇（乔布斯、创新）抑或是业务流程效率的竞争（供应链），都明白无误的告诉我们：管理只有恒久的问题，没有终结的答案。
9月份调整到新的部门：搜搜问问。先负责的是后台组的项目管理。新团队，老人只有一个，士气低下，缺少文档，上百个服务，光维护就非常困难，重写计划。从回顾会议开始，持续改进。这段时间的感悟是：提升团队士气的最好方式就是帮助大家成功，任何一点成绩都值得鼓励。我们引入了持续集成和自动化发布，鼓励同事做总结和分享；引入了自动化测试，鼓励同事做汇报，帮助review ppt；积极的让大家做有态度的程序员，对产品进行思考和反馈，把团队精神传递到部门经理，让部门经理进行鼓励。可以自豪的说，后台组是现在问问最有战斗力的团队。还有一点最重要的感悟是：一定是团队leader决定团队是否给力，幸运的是，我们有一个非常优秀的leader。
12月份开始负责部门的社区化运营项目。这和今年工作的感悟是一致的，产品的核心在于运营，这正是我想做的。项目立项一定要有一个NB的名字，我们就叫黑暗骑士。这个项目同样面对很多的挑战，目前最大的挑战还是在于人，团队的信心目前还没有建立，年后可能还会有人提出离职，而招人又是如此的困难，所以，上班第二天的第一件事是回顾会议。团队年前第一个版本发的很有挫折感，需求反复修改，开发人员都心灰意冷，所以，感悟是：一份优秀的需求文档是一切合理计划的起点。
1月份组织了技术中心的部门年会节目，我们原创的小品《非问勿扰》获得了二等奖。把新人都变为主角，这也算团队建设的一部分。
依然在不停思考，对问问来说，我们还应该做些什么。传统问答模式作为搜索引擎的补充是否已经走到了尽头？SNS的问答模式是否值得探索？与微博是否有更深的整合方式，或者，它们本身就是一种产品的两种展现方式？新浪微什么的探索是否还不够大胆？在移动端，独立的app没有前景，如何和微信更有力的结合。
终于到了可以结尾的段落，还有一件事情似乎忘了总结，那就是我们写了长达四年的那本书《流程的永恒之道-一个工作流和BPM项目的实战》，什么也不说了，一个例子来说明为什么值得期待：当我们把房管局及各委办局的数据和流程用BPM全部打通后，客户却依旧坚持要手动盖章走人工流程，BPM实施技术根本就不是瓶颈，瓶颈依旧是人啊。今年上半年一定出版。之所以写了四年，是因为写着写着总觉得知道的越来越不够，不断读书和补充内容，真是，那时年少，无知者无畏，唉。
2013，黑暗骑士崛起！