http://www.csdn.net/article/2014-09-10/2821606
Rong Hao ( blog ), is now starting 51daifan with his friends. Worked as workflow product manager, ThoughtWorks consultant, Tencent product manager, Qunar product manager, etc. Likes to write and draw, published dozens of essays and technical articles in "Zhongtang Gossip", "Programmer", InfoQ, "Software World", and participated in the translation of the Seam 2.0 Reference of the Manjianghong team, "Enterprise AJAX" and "Spring Raiders" "One of the translators of the Chinese version, co-authored with Xin Peng "The Eternal Way of Process - Theory, Specification, Mode and Best Practice of Workflow and BPM Technology", and shared topics in Agile China 2012, novel Author of "Zhang Xiaoqing, On the Road". Like to toss.
Life is about trying a different way of life
CSDN: Please tell us about you, your current work, and your career path.
Rong Hao: When it comes to my work experience, there are two ways:
From the programmer's point of view: I liked writing when I was in high school, and I liked programming when I was in college. After graduating from college, I worked as an internal system in a translation company. Because the internal system was applied to the workflow system, I went to Dongfang Yiwei Specialty. Develop a workflow system, write code, lead a team to write code, and take charge of the entire workflow product; then go to ThoughtWorks, write code with a bunch of great people, write Java/write PHP/write Ruby/write C/write Flex/write JS and CSS , do consulting; then leave and write a novel for half a year; then go to the Internet, Tencent, project manager, cloud computing, typhoon system, write C++, product manager, ask, search line and merge into Sogou; then where to go, responsible for Minions Business Line. Now, start a business and do 51daifan.
Talk about time and career advancement: I started working in 2005. I started working in a translation company as an internal office automation system, as a java programmer. The job is very easy and I don't work overtime. But this is not what I want. It happens that the realization of workflow is involved in the work. In the second year, I went to Dongfang Yiwei, a specialized workflow company, starting from programmers, senior programmers, and finally directly responsible for the company's work. Stream products. During this process, I started to lead a team, and slowly introduced some agile practices into the team. Then I felt that there are still many things to improve in this area. Then I went to ThoughtWorks. I stayed in ThoughtWorks for 3 years and tried various At this time, I began to want to develop products. I hoped that I could be in charge of a business, so I went to Tencent, where I went, and became a product manager, responsible for a business line. Now, the entrepreneur, 51daifan, has a new taste.
The whole work process is like this. In short, I can't be satisfied. I always want to make various attempts. Life may be about trying different lifestyles.
CSDN: When you were 17 years old, you took your life back from the god of death. Did this matter have any effect on you? How should programmers treat their bodies?
Rong Hao: The biggest impact is to experience the state of despair to death, which is a struggle with no hope at all. What impressed me was that on a sunny morning, downstairs in the surgical inpatient department in front, lay a corpse, two security guards stood beside it, and the corpse was covered with a layer of white cloth. The news spread quickly that the deceased was the director of the foreign exchange bureau, who was released on medical parole and jumped directly from the upstairs. That morning, Zhao Haining and I stared at the corpse for a long time, and I thought, "Damn, I want to live so much, and he died with such a kiss." Not just programmers, all people should be kind to their bodies. But who really cares after saying that.
CSDN: How do you feel about code? Have a particular preference for rich programming languages?
Rong Hao: It is very interesting to be able to observe the changes of the entire transaction system in a fast-growing company. How the code is organized and disassembled, how the business is organized and disassembled, and how the team is organized and disassembled, all three have a close relationship. Sometimes, in the face of the rapid development of the business, we must quickly launch the function, and the function and code quality are sometimes contradictory. It depends on which priority is higher, and there is no silver bullet.
I have learned a lot of programming languages, and I can often find a similar feeling. I have done Swing programming before, and later found that Flex programming, JS programming, and App programming are all similar, event-based system programming, and later wrote 51daifan first. The App version took 2 weekends to complete the launch.
CSDN: For work, you need to learn new content at any time according to changes in work requirements. When you learned a new thing, you said: "Many times, you think it's too difficult, just because you don't understand it." Do you have any thoughts and experiences to share?
Rong Hao: The simplest example of this is that we have no patience to read a technical article with more than 1,000 words. Most of the time we go straight to the topic, find out the sample code, copy it, see if it works, and we all want to pass Finding the solution to the problem at the least cost is difficult when the code does not work, but in fact, as long as you spend a little more time reading and understanding the principle, it is no longer difficult.
In my blog post "Three People's 2012-Work", I have shared all aspects, please click here to view.
CSDN: I heard that you have been on a special product sharing website recently, can you briefly introduce this matter, as well as your experience and experience.
Rong Hao: The specialty product sharing website I created is called 51daifan, which started from Tencent. At noon in the imperial capital surrounded by smog, a few IT migrant workers sighed on the roadside with emotion about what to eat at noon. At that time, McDonald's had just been exposed by CCTV for using overnight oil. Everyone was emotional and condemned this behavior. Turning around, Several people all went to McDonald's. Waste oil, poisoned milk powder, clenbuterol, shoe jelly, in this magical place, everyone is a chemist. How can we eat with confidence? We have seen in the company forum that friends often share the special products of their own family. These special products are directly harvested from the fields by themselves or their relatives. Therefore, we thought, can we make a sharing platform, We can share this information with more friends who have the same troubles as us.
51daifan went on the road like this. At the beginning, Liu Yanyan shared her home-produced honey. Unexpectedly, 100 bottles of honey were sold out. Next, the nana family's rice flower fragrant rice was harvested, and a total of 15,000 catties were shared twice; then Gannan navel oranges from Xiaodong's family, black fungus from Huang Liang's family, apple pears from Juanzi's family...
The reason why I started my business with 51dafan now is because I am a heavy user of 51dafan myself. I like this thing, and I think it is very meaningful to do this thing. Our website is pyshuo.com, and the WeChat public account is 51daifan. You are welcome to join our community and share your own specialties.
The eternal way of process
CSDN: Since the main content of the book "The Eternal Way of Process" is what you are good at, it was only planned for half a year, and then you spent four years. What is the reason? What kept you going?
Rong Hao: It is because in the process of writing, I want to find out the problems and development history that technology needs to solve. That is, technology must exist to solve problems. Only when we understand the problems we want to solve can we truly understand technology. This prompted myself to read a lot of management books, and finally this book became a combination of management and technology.
I can say that the reason why I was able to persevere was because Turing had a high liquidated damages.
CSDN: You have done a lot of projects. It is not difficult to find that many developers have a headache when they hear the specifications and processes. The project plan is also relatively random, and delays are relatively common. What are the reasons for these? Is there any good solution?
Rong Hao: These problems are actually determined by the different situations faced by the company. The project is small and a few people can handle it with simple communication; the system is large and dozens of people work together. If there is no standard and process, there will be problems. There is no good solution, only case by case more appropriate solutions. The following is a summary of the projects I have done, and some project management experience:
My first project was in 2005. It was a localization translation company with the top three market shares. There were only two people in the company's information department: the boss and me. We developed the company's internal collaborative office system together. The problem to be solved is simple: As the company grows rapidly, the task of assigning and tracking tasks that used to be purely paper documents and mail has become increasingly overwhelmed by project managers and finance, and there is an urgent need to automate these tasks. The technical architecture of the system is also very simple: jsp+javabean+mysql. There is no special development plan, the basic development process is as follows: every Monday we interview a business manager to understand his needs, develop in the middle of the week, if there is any problem in development, you can directly contact the business manager, and test on the system on Friday environment and sit down with the business manager to see if his needs are met. The system has been developed in this way, the boss's office is behind us, and the boss will use the system with us whenever he has time. There is only one detail in the entire development process that impressed me, that is, when estimating the workload of a task, no matter how much I estimate, the boss will multiply it by 3, and add a field to the business form at a time. It takes 10 minutes to add a database field, and the boss gave me half a day. The boss said that adding a field really only takes a few minutes, but it takes time to open the editor, it takes time to concentrate, and it takes time to start the system test after the change. Time, it will take time to confirm the requirements with the business manager after testing, we estimate the time to complete the whole thing and not just the time to code.
When the project was completed, it won unanimous praise from the whole company. From the company owner to the business manager, everyone was very satisfied. The only regret I felt was that as an IT staff, I never worked overtime.
In retrospect, this project was successful because the technology was simple and the system was not complicated (we didn't even need SVN, we completely relied on scripts to synchronize the code), but the most important thing was continuous delivery and continuous user feedback , the boss and business manager every time Seeing new features go live every week has boosted their confidence, while feedback is happening almost every day, and they can quickly see if it's what they want.
第二个项目在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：你是否认为，对需求的正确理解将直接影响项目开发的后续工作。实际情况，往往是用户自身对需求的认识也并非总是清楚的和一尘不变的，该怎么办？
荣浩：没有人会对需求的理解一步到位，我甚至认为根本不存在所谓正确的需求，实现需求的过程一定是一个不断认知和习得新知识的过程。
你对程序员进行文档的组织、编写、维护工作持什么样的态度呢？这是否会影响coding呢？尤其是在来自客户和市场的压力十分严峻的时候。这是一个很现实的问题。
我们现在会留时间进行文档的编写，也是对一段开发的总结和回顾，无论多大压力，开发总要有节奏，不能总绷着一根弦，否则就断了。
CSDN：对Review程序员的代码和工作，你一般是如何做的呢？
荣浩：在TW的时候，每天半小时CodeReview。现在，我们在提测前会对各自负责的模块一起做CodeReview。可以没有持续集成，可以没有UT，但CodeReview是必须要做的。
CSDN：对于代码的规范以及注释的书写，你有何心得和体会分享？
荣浩：没有硬性要求，但团队的风格要一致，代码必须要所有人都能读懂。
张小庆，在路上
CSDN：写这个小说的缘由、目的是什么？是写给谁看的？
荣浩：一直以来，我的梦想就是能够写自己的小说，高中时，在当地杂志和报纸上发表过几篇文章，那时的目的很单纯，就是想引起喜欢女生的注意；大学时，开始疯狂的看小说，最喜欢的是余华，他的文字能让我在合上全书时发出长长的一声的感叹；大三时，突然开始自己写了篇中篇小说，给北京文学投稿，没有回应，于是发表在了榕树下；工作了，身边充斥着的是厚厚薄薄的技术书籍，小说开始变得遥远，但我依旧能够时常记起那些温暖过我的小说人物们；现在，我越来越发现，我 们生活在一个很小说的年代，而现在的小说们，却源自生活低于生活，在穿越在科幻，我想，这正是个写小说的好年代，你不需要加工，生活本来就是小说，荒诞而黑色。
于是，就有了这篇《张小庆，在路上》的小说，计划分为四卷，分别是：开始、奋斗、迷茫和平淡，它讲述了一个普通程序员的生活，一个处于社会底层的小人物，他的喜怒哀乐，他的生活。
为什么要写这篇小说，理由很多，但我想最重要的是：喜欢！我不想在我老去的时候，对我孙子说，知道吗，你爷爷年轻的时候文章写得很好，如果那时写小 说去了，一定是个大作家。这话听起来就很虚伪，给人一种生不逢时的感觉，但是去他妈的生不逢时，与其那时后悔，不如现在开始，来吧，在路上的张小庆。
总的来说。就是想写，似乎也没有目的，因为觉得自己是文艺青年，文艺青年总要写点东西什么的，很想做一件事情的时候就去做了，就是这样。写给未来的自己看，到时候，再看到这些文字，可以对自己说，看，那时候的自己，年轻真好。
CSDN：听说你写了一半又重写，为什么？期间还有哪些困难？又是如何克服的？
荣浩：重写的原因其实是因为写的不好，太细节，没有主线，连我爸爸都读不下了，他总担心我会写出个一百万字出来。其他没有困难，因为是我想做的事情。我爱人说我是一个特别爱折腾的人。
CSDN：小说中，讲了张小庆的爱情、工作和生活等，最受大家关注的是什么内容？而你最青睐的是哪部分？为什么？
荣浩：其实想表达的是自己在那段时间的一种生活状态，所以可能和很多人有共鸣吧。自己对这个小说其实到现在还是很难满意。很多想表达的东西没有表达出来，而随着年龄的增长，对当时的一些事情也有了新的看法和认知。希望能够过一段时间，回过头来，再写写自己新的感触。
CSDN：如今这本书已完结，而且获得了读者的一致认可，你现在最大的感悟是什么？
荣浩：做一件自己喜欢的事情和找一个自己喜欢的妹子一样不容易，且行且珍惜。
未来
CSDN：对于未来你有什么样的规划和期许？是否还有出书或写小说的计划？
荣浩：对于未来，还是希望能够不断碰到自己喜欢做的事情，去尝试，去做。希望能够把51daifan做成一个很好的分享社区。
对于小说，希望在自己修改满意的时候能够出版《张小庆，在路上》。什么时候能够修改满意呢？不知道，也许明年，也许后年，谁知道呢，也许，过程才是最重要的。修改小说的过程也是不断修改自己认知的过程。
CSDN：你是什么时候接触CSDN的？它对你学习和工作都带来哪些影响？同时，对CSDN有什么建议？
荣浩：接触CSDN是在上大学的时候，01年，还有《程序员》杂志，当时就想自己什么时候能在《程序员》上发表文章，后来这个愿望就实现了。04年第一次接触spring也是在《程序员》，希望CSDN越办越好，因为我的好多朋友都在CSDN，能够提供更多的高质量文章。
最后，想说：有喜欢的事情赶快去做吧，很多事情，做起来就会发现没有那么难，就像和妹子表白，真的就是一层窗户纸。
若想获悉荣浩更多动态，请关注：