论“再造”与“重构”

题记：回忆《企业再造》

在书店发现这本书时，我正为自己负责的工作感到迷茫。当时做的产品已经开发了1年多了，技术难题都逐一的被克服了，产品的各项指标比市场上的同类产品还要好，正在准备产品化，可是市场却迟迟没有起色。

该怎么做呢？我苦思冥想，希望找到解决办法，帮助我以及我所在的产品团队。新产品如果成功了，这个产品团队都会受益。什么是新产品成功？对企业来说，产品获得市场的认可、获得订单、获得利润，这些都是产品成功的标志。

就是这个时候，我读了《企业再造》。《企业再造》中的这段话“企业流程再造就是对企业的根本性再思考和彻底性再设计，从而获得成本、质量、服务和速度等方面业绩的戏剧性的改善”，而再造的原则之一“以顾客为导向”，所有这些都让我看到了一些曙光。我的执行力很强，可是不善于表达，一般很少发表自己的见解。看了这本书，忽然有一种冲动，想写一写对产品的方向的建议。

经过几番斟酌，终于提交了报告，产品也真的做了调整。谢谢这本给我勇气的书籍。

 

 

一、           “再造”与“重构”

1.企业再造

什么是企业再造？百度一下。企业再造（Re-engineering）也译为“公司再造”、“再造工程”（ Reengineering）。它是1993年开始在美国出现的关于企业经营管理方式的一种新的理论和方法。所谓“再造工程”，简单地说就是以工作流程为中心，重新设计企业的经营、管理及运作方式。按照该理论的创始人原美国麻省理工学院教授迈克·哈默（M·Hammer）与詹姆斯·钱皮（J·Champy）的定义，是指“为了飞越性地改善成本、质量、服务、速度等重大的现代企业的运营基准，对工作流程（business process）进行根本性重新思考并彻底改革”，也就是说，“从头改变，重新设计”。

2.     代码重构

什么是代码重构？也百度一下。重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。　

通过重构可以达到以下的目标：

l 持续纠偏和改进软件设计

　　重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。

l 使代码更易为人所理解

　　Martin Flower在《重构》中有一句经典的话："任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。" 

l 帮助发现隐藏的代码缺陷

　　重构代码时逼迫你加深理解原先所写的代码。通过重构代码可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。

l 从长远来看，有助于提高编程效率

　　良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。

3.     “再造”与“重构”

从定义可以看出：

Ø “再造”是指“重新设计”。

l 企业再造针对企业的工作流程，重新设计，彻底改革。

l  彻底地改变, 是再创新, 而不是改进, 或提高, 或修改。

l 企业再造的前提是不改变企业的经营方向和战略目标。

Ø “重构”则是指“改善设计”。

l 代码重构针对的是软件产品，改善设计，提高可读性，减少缺陷。

l 改善设计、提高可读性、减少缺陷，提高软件的扩展性和维护性。

l 代码重构的前提是“在不改变软件现有功能的基础上”。

两者针对的对象是不同的，目的也不同。再造是彻底的改革，从头再来；而重构是改进设计，完善软件产品。从产品管理的角度的理解是：“再造”就是产品的重新开发；“重构”就是产品的完善。对产品的发展，选择“再造”还是“重构”，需要服从企业的战略方针，需要针对具体的情况而定。

二、           遇到了什么问题？

1.     混乱的现状

目前事业部的产品处于什么状态，

Ø  关于系统运行的描述：

l  监控中心报警，XXX前端通信失败，原因待查；

l  现场反馈，XXX调度方案执行错误，原因待查；

l  XXX时间校验时，系统死机；

l  在做实测XXX时间时，客户端非常卡，甚至死机直接退出；

l  下发XXX指令时，系统返回数据慢，超过10分钟；

l  进行XXX操作时，系统反映缓慢，经常卡死；

l  ……

Ø  关于使用界面的描述：

l  对终端设备的选择，部分功能提供快捷选择方式；

l  杂乱的弹出页面，部分弹出页面尺寸过大，覆盖了主菜单行；

l  没有用处的设备出现在设备管理中，解释是为了数据库的关联；

l  报警类型与故障名称，同一个功能，不同称谓；

l  庞大的统计分析菜单，23项子菜单一字排开，可谓壮观；

l  “统计分析”中“设备一览表”的子菜单仅一项，多此一举的分层；

l  ……

Ø  关于……

面对每天应付突击事件的研发人员，面对每天跑现场的支持人员，面对不断返工的实施人员，沉默中的我们在思考着，到底怎么了？

2.     深入的分析

产品从无到有，从一个想法到雏形到上线的产品，都有个过程。很多公司都希望将自己的产品流程化，正规化，希望按照一定的流程走下去。可是在这儿，没有看到流程化的产品管理过程，没有找到正规化的制度。

那现在我们怎么管理着产品或者项目呢？

Ø  质量体系与我们无关

公司目前执行两套质量体系，ISO9000是针对公司管理方面的，CMMI是针对软件开发的。不管什么样的质量体系，其实都是管理一个手段、方法、工具。不明白为什么，事业内的所有人员对质量体系都很抵触，或者说很不屑。为什么说是不屑呢？因为觉得公司是为了证书而做的质量体系，我不反对这句话。可是请各位领导认真的想一想，这是不是公司给予各位的一把可以伸缩的尺子，一个可以帮助提高管理的工具呢？

Ø  没有计划的工作

a)     无计划的项目开发

项目立项了，可是项目计划呢？因为人员不到位，没有做项目计划。无语。当一个开发团队中存在两个事情：新产品开发和老产品的维护，市场反馈回来的问题-老产品的维护都是一些紧急而必须要做的事情。在人员紧迫，在我们这样的小公司，从项目开发中抽调人员实属正常。对于一个预计需要10个左右的人员，预期1年完成的开发任务，没有开发计划，不知道这算不算灾难？这不是项目开发，这是在玩过家家。

b)     无计划的日常工作

项目开发没有计划，日常的工作呢？至少没有看到过，据说每个部门的老大每周都会提交周报的。很好奇周报的内容，也许那就是周计划和周总结吧，我的级别比较低，所以看不到而已。

c)      无计划的设备开发和维护

还是因为好奇心，“怎么没有看到你们的计划啊？”答曰“做计划有什么用啊？开发中遇到问题，谁知道什么时候解决啊？”偶无语。

Ø  需求在大家的脑子里

产品不断地增加新的功能，不断地改进，可是需求分析文档好像一直维持在原有版本上，呆板的我，又问了不该问的问题，为什么需求和目前的产品不对应呢？哎，请原谅我，我是真傻啊。可是新项目立项之后，架构文档都完成了，偶又犯晕了，问了一句“怎么不见需求文档呢？”话说完，偶只想给自己一个耳光，接着偶听到了不耐烦的声音“不是去年给过你需求文档了么？你还不了解需求啊？”哎，我脸红啊。

Ø  问题已经反馈了

慢慢的适应了，偶不再言语了，沉默着。终于有一天，发现其实这儿也有很规范的工作，比如维护人员制定的维护规范和维护人员的日志。真的很规范，详细的记录了发现的问题，包含问题出现的时候系统界面的截屏图，以及问题提交给谁了，跟踪问题的目前状态。偶看了觉得很值得表扬啊，结果偶就又犯了一个错误。偶找出将问题反馈给研发的问题，找研发人员追问这些问题怎么修改的，哪里有记录？结果一鼻子灰，“不是已经修改了么”，“这个问题，不能改，反馈给领导了”……是啊，可能已经修改了，但是没有测试报告，没有修改记录，请问怎么就应用到目前正在运行的系统中的呢？

Ø  被忽视的测试

事业部的产品其实就一个，包含软件平台和前端的监控设备。事业部所中标的项目都是以这个项目为主体的。那么在项目实施和交付中遇到的很多问题，反馈出来的都是产品问题。但是为什么就没有看到研发人员去现场看看，为什么没有看到针对这些问题所做的实验和问题分析呢？大部分时候听到的是“我们无法搭建这么大的实验平台？”这是真的么？“这还用测试么？我负责的这部分绝对没有问题”请问您凭什么这么说？“测试的时候没有问题啊？”请问都做了哪些测试？

Ø  ……

不想再描述了，上面这些只是冰山一角。不，我情愿这只是我片面的认识，我情愿希望我的认识是错误的。有这些现象，不需要分析，遇到了什么问题已经很明显了。我们需要什么？需要规范化的工作流程，需要严格的执行力，需要认真负责的工作态度，需要……

3.     解决的措施

问题已经很明显了，现在这个系统有很多问题。市场广阔，当前正是好时机，不可能放弃这个市场方向的。怎么办呢？是要重新策划系统呢，还是修补现有的系统呢？是啊，“再造”还是“重构”？

“再造”将面临的是什么？“重构”的压力有多大？这些都是决策者需要权衡的。我不知道这个权衡都考虑了哪些，有哪些人参与了决策。最终的决定是重新开发系统。

三、           问题解决了么？

1.     从头再来

选择“再造”是否合适？

前面已经发表了最终的决定，从头再来。从头再来真的是英明的决定么？不知道。只是觉得缺少了对目前现状问题的分析，这么匆忙的从头开始，风险很大。

Ø  立项建议书

首先看到新项目的是立项建议书。建议书采用的模板基本上就是“CMMI 3级软件过程改进方法与规范”原版。但是在讨论草稿的时候，偶又犯了一次傻，偶坚持要写一写目前系统的问题，逐个梳理一遍。当然最终的结局就是再次讨论这个文档的时候再也没有让偶参加。

Ø  架构文档

不清楚为什么项目建议书和系统架构文档同时出现，这次偶没有问。可是让偶不明白的是，这个架构文档是基于什么做的呢？没有看到需求和需求分析文档，这个架构是凭空出现的么？也许还是那句话“需求在大家的大脑里”，只是偶看不到而已。

Ø  项目人员与开发计划

前面提到了，研发人员忙于两件事情：新项目开发和老项目的维护升级时，维护任务永远是最紧要的。而在人员比较紧张的时候，所以新项目的人员一直无法确定下来。这也造成了前面分析的，竟然没有开发计划。

Ø  项目需求

项目既然真的要从头再来了，那么应该从哪儿开始，这是常识了，不用多说吧。但是奇怪的事情天天有，前面说了，项目需求在大家的脑子里，那么请在这个项目开始的时候将大家脑子里的需求落实到项目文档中吧。只是不知道，我的期盼是否能够实现。有人在部门会议的时候提出了要做项目需求分析，我真的很想尽快的看到需求了。希望有机会参与项目需求讨论或者评审会议吧。

综上，其实从头再来好像只是一个一厢情愿的想法。是啊，还是原来的原班人马，还是原来的制度，还是原来的管理办法，还是原来的思考模式，所有的一切都打着深深的烙印呢。真的是从头再来么？请大家拥有“再造”的精神，真的做到从头再来。

2.     不堪重负的产品团队

前面已经提到了，研发团队面临着新项目的开发和老项目的维护工作。造成现在这样的局面的原因不用再次的分析了，那么怎么办呢？这就像背着包袱前进，而且包袱还在不断的增加，压得我们无法喘息，越走越慢，慢慢的，直到走不动了……

这些包袱是什么呢？是系统的问题，一个问题就是一个包袱，那么这些问题是否可以彻底的解决呢？怎么把这些包袱放下呢？需要做什么呢？建议大家认真的考虑一下。问题发现了一次有一次，为什么得不到彻底的解决？是因为我们的技术实力不够呢还是因为我们的时间不够呢还是其他什么？不管什么原因，其实只要认真的去找，一定能找到最根本的原因的。有时间请读读《目标》。

3.     新一轮的混乱

“再造”是否真的解救了再造的企业？企业再造的失败率很高，一项调查表明有约75％的企业再造活动是不成功的。那么我们选择“再造”是否真的合适呢？看看我们现在状况就明白了。我们新项目进展的怎么样呢？哦，请等等，新项目好像还没有开始制定项目计划呢，新项目的人员还在做老系统的维护工作呢。而老系统的问题解决的是否彻底呢？好像不需要了，因为这个系统已经被判定为在一段时间之后就要终结它的使命了。所以大家忙碌着，忙碌着采用临时应对措施解决目前的紧急问题。结果呢？都很忙，可是问题还是一堆。从去年到今年，也许还要到明年，依然忙碌着……

四、           无言的结局

1.     产品怎么了

事业部的产品做了三年，改了多版，研发人员已经做了足够的技术积累，市场需求也了解的很清楚，目前产品的功能大部分也还是值得肯定的。其实目前混乱的原因，主要还是细节问题，设备的质量不可靠，软件的性能不好等。这些问题，不是因为我们缺少高水平的研发人员，而是工作制度和开发流程等造成的，是因为从产品策划开始对质量，对性能不够重视造成的。但是到目前也没有建立相关的制度，对于发现的缺陷问题没有管理流程，对于发现的问题没有闭环处理流程。

2.     请“再造”

刚刚也分析了，造成目前局面的不是缺少高水平的研发人员，而是制度和流程的不健全导致的，所以请“再造”开发流程和产品管理流程。

3.     请“重构”

软件平台持续不断地增量开发，以及常年对反馈的问题的修改，造成了目前平台的不稳定。为了持续纠偏和改进软件设计，为了使代码更易为人所理解，为了帮助发现隐藏的代码缺陷，请“重构”软件平台。