专访荣浩：流程的永恒之道

http://www.csdn.net/article/2014-09-10/2821606

 

<iframe src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2014-09-10%2F2821606&amp;type=3&amp;count=&amp;appkey=&amp;title=%E4%B8%80%E4%B8%AA%E5%9C%A8%E7%BC%96%E7%A8%8B%E7%9A%84%E8%B7%AF%E4%B8%8A%E8%B5%B0%E4%BA%86%E5%BE%88%E4%B9%85%E5%BE%88%E4%B9%85%E7%9A%84%E4%BA%BA%EF%BC%8C%E8%91%97%E6%9C%89%E5%90%84%E7%B1%BB%E6%8A%80%E6%9C%AF%E4%B9%A6%E7%B1%8D%EF%BC%8C%E5%8D%B4%E5%9C%A8%E5%B7%A5%E4%BD%9C%E4%B9%8B%E4%BD%99%E5%86%99%E4%BA%86%E4%B8%80%E6%9C%AC%E5%B0%8F%E8%AF%B4%E3%80%8A%E5%BC%A0%E5%B0%8F%E5%BA%86%EF%BC%8C%E5%9C%A8%E8%B7%AF%E4%B8%8A%E3%80%8B%EF%BC%8C%E8%8E%B7%E5%BE%97%E7%BD%91%E5%8F%8B%E7%83%AD%E6%8D%A7%E3%80%82%E7%A4%BE%E5%8C%BA%E4%B9%8B%E6%98%9F53%E6%9C%9F%E9%87%87%E8%AE%BF%E4%BA%86%E7%A8%8B%E5%BA%8F%E5%91%98%E3%80%81%E5%92%A8%E8%AF%A2%E5%B8%88%E3%80%81%E4%BA%A7%E5%93%81%E7%BB%8F%E7%90%86%E5%92%8C%E5%88%9B%E4%B8%9A%E8%80%85%E8%8D%A3%E6%B5%A9%EF%BC%8C%E7%9C%8B%E4%BB%96%E6%98%AF%E4%B8%80%E8%B7%AF%E5%A6%82%E4%BD%95%E8%B5%B0%E6%9D%A5%E7%9A%84%E3%80%82&amp;pic=&amp;ralateUid=&amp;language=zh_cn&amp;rnd=1451887432920" frameborder="0" scrolling="no" width="22" height="16"></iframe>摘要：一个在编程的路上走了很久很久的人，著有各类技术书籍，却在工作之余写了一本小说《张小庆，在路上》，获得网友热捧。社区之星53期采访了程序员、咨询师、产品经理和创业者荣浩，看他是一路如何走来的。

荣浩（博客），现在和小伙伴一起创业51daifan。曾在东方易维担任工作流产品经理、ThoughtWorks咨询师、腾讯产品经理、去哪儿产品经理等。喜欢写画，分别在《中堂闲话》、《程序员》、InfoQ、《软件世界》发表散文和技术文章数十篇，参与了满江红团队Seam 2.0 Reference的翻译，《企业级AJAX》和《Spring攻略》中文版译者之一，和辛鹏合著《流程的永恒之道——工作流及BPM技术的理论、规范、模式及最佳实践》一书，在敏捷中国2012做过话题分享，小说《张小庆，在路上》作者。喜欢折腾。

人生，在于尝试不同的生活方式

CSDN：请和大家介绍下你和目前所从事的工作，以及你的职场之路。

荣浩：谈到我的从工作经历，可以通过两个途径来说：

从程序员的角度来说：高中的时候喜欢上写作，大学时喜欢上编程，大学毕业后先在一家翻译公司做内部系统，因为内部系统应用到工作流系统，所以随后就到了东方易维专门开发工作流系统，写代码，带团队写代码，到负责整个工作流产品；然后到ThoughtWorks，和一帮牛人写代码，写Java/写PHP/写Ruby/写C/写Flex/写JS和CSS，做咨询；然后离职，写半年小说；然后到互联网、腾讯、项目经理、云计算、台风系统、写C++、产品经理、问问、搜索线并入搜狗；然后在去哪儿，负责小黄人业务线。现在，开始创业，做51daifan。

以时间和职场晋升来谈：我是05年参加工作的，最开始在一家翻译公司做公司内部的办公自动化系统，java程序员，工作很轻松，不加班。但这不是我想要的，刚好工作中涉及到工作流的实现，第二年就去了专门的工作流公司东方易维，从程序员开始，高级程序员，最后就直接负责了公司的工作流产品。在这个过程中开始带领一个团队，慢慢就在团队中引入一些敏捷实践，然后感觉这方面还有很多东西需要提高，接下来就去了ThoughtWorks，ThoughtWorks待了3年，尝试了各种各样的新技术和编程语言，这时候就开始想往产品方面去发展，希望自己能够负责一个业务，就去了腾讯，去了去哪儿，变成产品经理，负责一个业务线了。现在，创业，51daifan，又有新的体味。

整个的工作过程就是这样，总之就是总不能满足，总是想做各种的尝试，人生，也许就在于不同的生活方式尝试吧。

CSDN：你在17岁那年，从死神手中夺回了生命，这件事情对你有什么影响吗？程序员应该以怎样的态度对待自己的身体？

荣浩：最大的影响是体会到绝望到死的心境，那是完全看不到希望的挣扎。印象很深刻的是一个阳光很好的早上，前面外科住院部的楼下，躺着一具尸体，两个保安站在旁边，尸体上盖着一层白布。消息很快传开，死者是外汇局局长，保外就医，直接从楼上跳下来。那个早上，我和赵海宁盯着那具尸体看了好久，我想，妈的，我这么想活着，他那么亲亲一跳，就死了。不仅仅是程序员，所有的人都应该对自己的身体好一点。可是，这话说过之后又有谁真正在意呢。

CSDN：你对代码有着怎样的情感？对丰富的编程语言是否有特别的喜好？

荣浩：能在一家快速发展的公司观察整个交易系统的变迁是一件很有意思的事情，代码如何组织和拆解，业务如何组织和拆解、团队如何组织和拆解，这三者都有着密切的关系。有时候，面对业务的快速发展，我们必须快速上线功能，而功能和代码质量，有时候就是矛盾的，就看那个优先级更高，不存在银弹。

学过很多编程语言，很多时候都能找到似曾相似的感觉，之前做过Swing编程，后来就发现Flex编程，JS编程，App编程都是类似的，基于事件的系统编程，后来写51daifan第一个App版本用了2个周末就完成上线了。

CSDN：对于工作，随时要根据工作需求的改变而要学习新内容，你在学习一个新东西的时候说过：“很多时候，你觉得太难，只是因为你不了解它。”对此你还有什么心得和体会可分享？

荣浩：这件事一个最简单的例子是，没有耐心看完一篇超过1000字的技术文章，大多时候我们都直奔主题，找出示例代码，复制，看看能不能工作，都想通过最小成本找出问题的解决方法，当代码不能工作的时候就觉得这件事很难，而实际上，只要多花一点点时间阅读理解原理，就不再困难。

在我的博文《三个人的2012-工作篇 》中，我进行了全方面的分享，请点击这里查看。

CSDN：听说您最近在一个特产分享网站，可否简单介绍下这个事情，以及你的心得和体会。

荣浩：我做的特产分享网站叫51daifan，它开始于腾讯。在那个被雾霾围绕的帝都中午，几个IT民工在马路牙子上感慨中午该吃些什么，其时麦当劳刚刚被央视曝光使用隔夜油，大家情绪激动纷纷对这种行径表示谴责，一转身，几个人全去了麦当劳。地沟油、毒奶粉、瘦肉精、皮鞋果冻，在这个神奇的地方，人人都是化学家。如何才能吃的放心，我们在公司论坛里看到，经常有朋友分享自己家产的特产，这些特产都是自己或亲人直接从地里收获上来的，于是，我们想，能不能做一个分享平台，能够把这些信息分享给更多和我们有相同苦恼的朋友。

51daifan就这样上路了，最开始是刘炎炎分享她家的自产蜂蜜，出人意料，100瓶蜂蜜一抢而空；接下来，nana家的稻花香大米丰收了，两次共分享出15000斤；然后是小栋家的赣南脐橙，黄亮家的黑木耳，娟子家的苹果梨.....

之所以现在以51daifan来创业，是因为我自己就是51dafan的重度用户，我喜欢这个事情，我觉得做这个事情特别有意义。我们的网址在pyshuo.com，微信公共账号是51daifan，欢迎大家加入我们的社区，一起来分享自己家的特产。

流程的永恒之道

CSDN：由于《流程的永恒之道》一书的主要内容是你擅长的，原本只计划半年，后来你用了四年时间，原因是什么？是什么让你坚持下来的？

荣浩：是因为写作过程中想找出技术要解决的问题和发展历史，即技术一定是解决问题而存在的，只有理解了我们要解决的问题，才能真正理解技术。这就促使自己阅读了大量管理书籍，最后这本书也变成了管理学和技术的合体。

我能说之所以能够坚持下来是因为图灵有高额违约金嘛。

CSDN：你做过的项目有很多，不难发现有很多开发者一听到规范和流程就头疼，项目计划也是比较随意，延期现象比较常见，出现这些的原因是什么？有什么好的解决方案吗？

荣浩：这些问题实际上是由公司面临的不同情况决定的，项目小，几个人，简单的沟通就能搞定；系统大，几十上百人协作，那么没有规范和流程就一定会出问题。没有好的解决方案，只有case by case比较合适的解决方案。以下是自己通过总结自己所做过的项目，和得出一些项目管理经验：

我的第一个项目是在2005年，那是一家市场占有率前三的本地化翻译公司，公司的信息部门只有两个人：老大和我，我们一起开发公司内部的协同办公系统。要解决的问题很简单：由于公司发展迅速，以前单纯依靠纸质单据和邮件分派和追踪任务已经越来越让项目经理和财务不堪重负，迫切需要将这些工作给自动化。系统的技术架构也很简单： jsp+javabean+mysql。没有专门的开发计划，基本开发流程是这样的：每周一我们访谈一个业务部门经理，了解他的需求，周中开发，开发中有任何问题都可以直接找业务经理，周五的时候系统上测试环境，再和业务经理坐到一起看一下是否满足了他的需求。系统就一直这样不紧不慢的开发着，老板办公室就在我们身后，一有时间老板就会和我们一起使用该系统。整个开发过程只有一个细节让我印象深刻，就是对任务估算工作量时，不管我估算多少，老大都会给我乘以3，一次要给业务表单增加一个字段，老大问我需要多长时间，我说不就是增加数据库字段吗10分钟，结果老大给了我半天时间，老大说，增加字段确实只需要几分钟，但打开编辑器需要时间吧，集中注意力需要时间吧，改完了启动系统测试需要时间吧，测试完了和业务经理确认需求需要时间吧，我们估算的是完成整个事情的时间而不仅仅是编码的时间。

这个项目完成时获得了公司上下的一致好评，从公司老板到业务经理，每个人都非常满意，而让我感到唯一遗憾的却是身为IT人员竟然从来都没有加过班。

回想起来，这个项目之所以成功固然是因为技术简单和系统不复杂（我们甚至都不需要 SVN，完全依靠脚本同步代码），但最重要的还是持续交付和持续的用户反馈，老板和业务经理每周都能看到新功能的上线，这增强了他们的信心，同时反馈几乎每天都在进行，并且他们很快都能看到这是否是他们想要的。

第二个项目在2006年，这一年我换工作了，因为当时我认为不加班的程序员不是好程序员。新公司在上地，是一家做协同办公业务平台的公司，最开始去的是项目部，一开始很为业务平台这个概念着迷，因为当写程序时最先不是写代码而是用代码生成器生成代码，并且生成完的代码马上可以运行！第一个项目是丰田公司的销售管理系统，我们创新的使用了当时最热的Ajax技术，我们完全是用技术热情加上周末时间完成对原有功能的 Ajax增强，这个项目获得了用户极高的评价，因为当大多数web系统还在使用点击 /刷新的方式进行交互时，我们却可以直接拖拽完成操作了。如果在当时，我会认为是技术的创新让项目获得了成功，但是现在，我会用渐进式增强这个词，即只有在完成用户所需要的核心功能（什么叫核心功能，即缺少这个功能系统不能工作）后才开始对系统用户体验、性能进行渐进式优化。

第三个项目是在公司的平台部，这里部门经理正准备对原有的业务平台进行重写，原先业务平台的技术框架是：jsp+struts+ojb+sqlserver，新的技术框架定义为： ajax+freemarker+webwork+spring+hibernate。这让我兴奋，因为新的技术框架几乎是当时最流行的技术。加部门经理共有三个开发人员（所以沟通一直不是问题），老大使用project来管理项目，每个人负责一个模块，估算以周为单位，最初计划是 5个月交付，功能直接就是老平台的翻版换的只是技术实现，但是 5个月后进行测试和项目试用时却发现了大量缺陷，最后几乎用了半年时间才将缺陷收敛，产品发布计划延期半年。回顾这个项目，需求没有进行详细的分解和评审导致实现与需求不一致似乎是项目延期最重要的问题，然而更深的思考却是我们需不需因为技术原因开始新产品的开发，在不影响用户使用的情况下对原业务平台进行渐进式增强是否更加合适。即我们在启动项目时更多关注的应该是用户价值（只有有用户价值用户才会买单公司才有收益）。

第四个项目是我负责的，这个项目几乎是上一个项目的翻版，重写公司的工作流产品：支持更多的工作流模式，更易集成的api和管理界面，唯一不同的是这个项目采用了很多敏捷里的实践：持续集成、单元测试、站会、迭代，但这些实践均不影响这个项目最终的失败。同样是该不该重写这个项目的问题，在公司资金链紧张、时间要求紧、新产品相比竞品没有突出特性的情况下，这个项目从一开始就决定了失败。如果没有特别充足的理由就不要重写产品，这几乎成为我目前最重要的一条原则，尤其要从公司全局的角度看待产品不能局限在技术。现在，只要谁一说到要重写产品，而给出的仅仅是技术原因，我就会两股加紧，冷汗直流。在对项目完全负责的情况下，我另一点深刻感受就是人的重要性，对团队中的每个人员，作为leader 你都需要知道他的需求是什么，没有人愿意做机器人，在一次对某一技术方案简单粗暴拍板后，一个核心技术人员流失了，这成了压垮这个项目的最后一根稻草。

08年底去了一家新公司，新公司采用敏捷实践。第一个项目很成功，几乎是敏捷项目的一个成功范例，需求分析、迭代、持续集成、结对、客户 showcase、持续交付，项目甚至提前半个月完成。唯一美中不足的是项目二期时新团队由于一期文档很少带来了很多困扰。突出的感受是：团队人员有了角色、有了分工也就有了流程。现在，到了一个新的部门或中心，第一件事情往往就是梳理项目开发流程，定义出每个人的角色，职责不清是互相埋怨之源。

第二个项目是咨询项目，略去不表。第三个项目是分布式团队，一部分团队在国外，一部分团队在国内，最开始一切顺利，但在上线前一个月遇到了严重的性能问题，陷入了一片混乱当中，所有人都不知道我们离上线还有多远，还有哪些工作需要完成，优先级都是什么，项目经理甚至自己都失去对整个项目的把控，她不知道项目上线究竟需要满足什么条件，于是一次次在等待国外团队优化后的测试结果，于是一次次的测试结果不满意，于是项目在一次次的下周二上线的空头承诺中成了整个公司的笑柄。这个项目回顾起来就是团队遇到挫折时放弃了计划，迭代没有了，故事墙没有了，所有人都在等待，而项目经理为了不让开发人员被公司收回还不得不想一些优先级不高的任务给团队完成装着我们很忙。教训就是，任何情况下都不能放弃计划，计划是项目之本。其他包括团队能不分布式就不要分布式，如果必须分布式那么一定要从架构开发任务上进行隔离，尽量减少两个团队之间的交互（很多项目经理进入到部门之后推进项目制，其实也是同样的原则，团队大了就要拆解，产品代码多了也要模块化，尽量减少团队之间、模块之间的交互，做到能够各自独立演进和发布）。尽早进行实际环境的测试，越早越好。测试越早进行越好，测试环境越贴近产品环境越好，这一原则什么时候强调都不过分（我们上线前的测试才发现严重的性能问题）。

第三个项目是幸运的，因为他们有钱，能够等待，在多等待了大半年后系统终于上线。而第四个项目就没有这么走运了，这个项目是一个在线 saas CRM系统的重写，而且有着强时间约束（如果半年不能交付，将错过该系统客户每年做预算的窗口期），看吧，又是重写，又是时间约束，这几乎总预示着它厄运难逃。表面上看项目是在一次中期的架构重写中崩溃了，重写耗去了团队太多的时间，而由于对未知领域知识的不正确估算（需要学习）再次令项目雪上加霜，项目目标又不能变化，要在六个月后上线，但更深层的原因还是项目开始之前没有决策正确，真的要重写产品吗？老产品确实界面很丑、一些功能没有，但这些不能渐进式增强进行吗，一定要重新开始吗？重写使用新团队，他们对该业务领域并没有经验，过去系统遇到的坑他们不清楚，他们的计划因为少考虑了一些情况是否显得过于乐观？这个项目的其他问题包括项目计划一直没有发生变化，尽管所有人都认为在规定日期到来之前不可能交付，但这个日期却没有发生变化。最后不得不说这是一个技术强大的团队，一切都做到了自动化，甚至部署产品环境也是一键完成，但是这些在项目目标失败的情况下显得黯然失色。而客户贷款做这个项目则让很多团队成员良心不安。

来到腾讯，来到soso，最重要的收获是对运维有了新的认识，以前曾经认为devops就是自动化部署，全功能团队，现在发现它关乎架构：一条搜索的badcase是否能够很快找出错误的原因？是抓取失败，是索引时丢失，还是相关性排序不好？关乎监控和报警，我们能否很快从监控中定位出原因？关乎组织结构，前台开发，后台架构，基础架构，运维测试团队都是分离的，如何协作才能使团队合作的成本最低而整体利益最大化？

回顾往事，保尔柯察金说：如何才能不虚度光阴，只有为共产主义奋斗终身；柯景腾说：唯有沈佳宜让我怀念；而我想说的是：

l做任何项目之前一定要想清楚为什么要做这个项目，一定要想清楚这个项目的价值是对用户和公司的（尤其需要跳出站到一个比较高的层次看项目），一定要想清楚项目的约束（时间约束、人员约束）,不仅是项目开始之前要想，过程中要不断回顾；；

• 项目任何时候都必须有计划，对所有干系人透明；
• 项目一定是持续交付和持续反馈的，不允许黑盒出现；
• 测试和运维一定要尽早介入；
• 从每个团队成员的角度出发关注所有人的利益实现共赢。

CSDN：项目管理部是在项目队伍不够成熟的前提下才产生的，它既起主导作用，也有辅佐作用，并且项目管理部，对公司的所有项目组统一负责，你眼中的项目管理部是怎样的？

荣浩：如果不理解业务，单纯的做项目管理，那么项目管理部在业务线里的位置会很尴尬。但是存在即有道理，为老大们提供整体的项目视图，做项目的过程改进，都非常有价值，只是这种价值很难量化。身边有很多在项目管理部的朋友，他们会苦恼如何衡量自己的价值。

CSDN：你是否认为，对需求的正确理解将直接影响项目开发的后续工作。实际情况，往往是用户自身对需求的认识也并非总是清楚的和一尘不变的，该怎么办？

荣浩：没有人会对需求的理解一步到位，我甚至认为根本不存在所谓正确的需求，实现需求的过程一定是一个不断认知和习得新知识的过程。

你对程序员进行文档的组织、编写、维护工作持什么样的态度呢？这是否会影响coding呢？尤其是在来自客户和市场的压力十分严峻的时候。这是一个很现实的问题。

我们现在会留时间进行文档的编写，也是对一段开发的总结和回顾，无论多大压力，开发总要有节奏，不能总绷着一根弦，否则就断了。

CSDN：对Review程序员的代码和工作，你一般是如何做的呢？

荣浩：在TW的时候，每天半小时CodeReview。现在，我们在提测前会对各自负责的模块一起做CodeReview。可以没有持续集成，可以没有UT，但CodeReview是必须要做的。

CSDN：对于代码的规范以及注释的书写，你有何心得和体会分享？

荣浩：没有硬性要求，但团队的风格要一致，代码必须要所有人都能读懂。

张小庆，在路上

CSDN：写这个小说的缘由、目的是什么？是写给谁看的？

荣浩：一直以来，我的梦想就是能够写自己的小说，高中时，在当地杂志和报纸上发表过几篇文章，那时的目的很单纯，就是想引起喜欢女生的注意；大学时，开始疯狂的看小说，最喜欢的是余华，他的文字能让我在合上全书时发出长长的一声的感叹；大三时，突然开始自己写了篇中篇小说，给北京文学投稿，没有回应，于是发表在了榕树下；工作了，身边充斥着的是厚厚薄薄的技术书籍，小说开始变得遥远，但我依旧能够时常记起那些温暖过我的小说人物们；现在，我越来越发现，我 们生活在一个很小说的年代，而现在的小说们，却源自生活低于生活，在穿越在科幻，我想，这正是个写小说的好年代，你不需要加工，生活本来就是小说，荒诞而黑色。

于是，就有了这篇《张小庆，在路上》的小说，计划分为四卷，分别是：开始、奋斗、迷茫和平淡，它讲述了一个普通程序员的生活，一个处于社会底层的小人物，他的喜怒哀乐，他的生活。

为什么要写这篇小说，理由很多，但我想最重要的是：喜欢！我不想在我老去的时候，对我孙子说，知道吗，你爷爷年轻的时候文章写得很好，如果那时写小 说去了，一定是个大作家。这话听起来就很虚伪，给人一种生不逢时的感觉，但是去他妈的生不逢时，与其那时后悔，不如现在开始，来吧，在路上的张小庆。

总的来说。就是想写，似乎也没有目的，因为觉得自己是文艺青年，文艺青年总要写点东西什么的，很想做一件事情的时候就去做了，就是这样。写给未来的自己看，到时候，再看到这些文字，可以对自己说，看，那时候的自己，年轻真好。

CSDN：听说你写了一半又重写，为什么？期间还有哪些困难？又是如何克服的？

荣浩：重写的原因其实是因为写的不好，太细节，没有主线，连我爸爸都读不下了，他总担心我会写出个一百万字出来。其他没有困难，因为是我想做的事情。我爱人说我是一个特别爱折腾的人。

CSDN：小说中，讲了张小庆的爱情、工作和生活等，最受大家关注的是什么内容？而你最青睐的是哪部分？为什么？

荣浩：其实想表达的是自己在那段时间的一种生活状态，所以可能和很多人有共鸣吧。自己对这个小说其实到现在还是很难满意。很多想表达的东西没有表达出来，而随着年龄的增长，对当时的一些事情也有了新的看法和认知。希望能够过一段时间，回过头来，再写写自己新的感触。

CSDN：如今这本书已完结，而且获得了读者的一致认可，你现在最大的感悟是什么？

荣浩：做一件自己喜欢的事情和找一个自己喜欢的妹子一样不容易，且行且珍惜。

未来

CSDN：对于未来你有什么样的规划和期许？是否还有出书或写小说的计划？

荣浩：对于未来，还是希望能够不断碰到自己喜欢做的事情，去尝试，去做。希望能够把51daifan做成一个很好的分享社区。

对于小说，希望在自己修改满意的时候能够出版《张小庆，在路上》。什么时候能够修改满意呢？不知道，也许明年，也许后年，谁知道呢，也许，过程才是最重要的。修改小说的过程也是不断修改自己认知的过程。

CSDN：你是什么时候接触CSDN的？它对你学习和工作都带来哪些影响？同时，对CSDN有什么建议？

荣浩：接触CSDN是在上大学的时候，01年，还有《程序员》杂志，当时就想自己什么时候能在《程序员》上发表文章，后来这个愿望就实现了。04年第一次接触spring也是在《程序员》，希望CSDN越办越好，因为我的好多朋友都在CSDN，能够提供更多的高质量文章。

最后，想说：有喜欢的事情赶快去做吧，很多事情，做起来就会发现没有那么难，就像和妹子表白，真的就是一层窗户纸。

若想获悉荣浩更多动态，请关注：

CSDN博客： 点击进入  新浪微博： 点击进入