软件行业怎样做出好的产品？

      仅仅就编程来说，实在是一件很简单的事，就是“程序 = 算法 + 结构”，但要想做出一个软件产品来就不是这么简单的事了。

 

      虽然“程序 = 算法 + 结构”没错，但随着市场的变化，需求的变更，这些算法和结构也是在时刻变动，有可能我们分析出这些算法和结构后，投入到市场中却发现产品已经过时。所以我们有必要建立一个平台,用来管理和分析这些影响算法和结构，并导致其发生变化的需求，以至我们能够实时的把算法和结构对应的程序发布到市场中给客户使用。

  

      显然这时候算法和结构已经越来越多，所以更加有必要建立一个开发平台来整理这些算法和结构，方便我们更好的开发改进程序。

  

      但一个好的软件产品除了程序本身，还有产品理念、操作说明、培训教材、实施步骤、问题反馈等一系列为客户服务的事物，所以有必要建立一个实施平台来存放这些事物，共享这些事物。

  

      因此一个存在于市场的优秀产品，必然拥有这三个平台：需求平台、开发平台和实施平台。

 

      建立平台就要知道这个平台包含哪些东西，有什么方法可以管理这些东西，这是个复杂而长久的过程。我们只能够先从简单的做起，从实践中慢慢的整理出来这些内容和方法。自己马上实践，总比别人成功后走别人的老路好！

 

      首先要设立三个岗位，需求平台组长、开发平台组长和实施平台组长。

 

      需求平台组长就把现在所有的需求全部收集整理，并实时的更新这些需求，可能开始都是些文档，手动处理，形成规模就可以考虑做一个管理工具，在线需求提交、审查等系统。

 

      开发平台组长就整理所有程序功能模块，重新整合设计，提出公共的算法结构等。

      程序 = 算法 + 结构 + 方法  

      因为程序的复杂，所以我们在分析算法和结构的时候就有了不同的方法，以前是面向过程，现在又面向对象，接着比较热门的面向服务。这都是我们实践中产生的一些方法，但他们也不是相互独立的。面向对象里面可能包括了面向过程，面向服务里面也包括了面向对象。所以在构建不同的算法和结构是就需要用到不同的方法，我们现在用得最多的算是面向对象方法，所以面向对象也就成了开发组长整理的一个重要东西。

     “懒人精神”并不是要我们做事懒，而是重于发现，遇到问题可以停下来多思考讨论，可能就找到了更好的方法。

 

 

      实施平台组长负责整理实施需要的文档，包括操作手册，培训教材等。

 

      等到这些平台都有所规模走上正道后，有必要还要成立一个质量监省平台，以第三方的眼光指导三个平台的进步。 

 

      现在阻碍这种开发模式最大的障碍就是项目，为什么这么说，因为一个项目就是一个陷阱，整个开发部门就十几个人，如果有几个项目在同时进行，那么这十几个人就这样分别掉进了各自的项目，以致整个开发部出现没人没时间的情况，变成一个空部门。

 

      为什么每一个项目对于开发部来说都会变成了一个个陷阱了？

 

      首先，产品的不成熟，就由三个人几个月搞出来的东西，没有明确的需求，参考别的系统做，没有正规的设计，画几个流程图，就设计表结构开始编码，没有专业的测试，互相之间点点界面看有没有错误报出。就这样搞出来的东西，上场就几百万的项目，开发人员哪跑得掉。现场调试程序，修改需求，到处救火。

      其次，实施力量薄搦，随便抓来的几个人，没有经过系统的培训，连个sql语句都写不出来，更别说跟客户讨论需求、挡需求，他们做的就是培训客户，教他们操作，有问题丢给开发人员解决。

      再次，客户的素质低下，使用系统的客户大部分都没摸过电脑，需要从打字培训起，提出的需求很随意也很随时，大半年下来没断过需求。

      最后，公司领导层的制度方向，以打单抢占市场为重，对技术的漠视，人够用就行。没有想过搞一批人认认真真的专门研究这个产品。

      这些技术人员，在这个项目从头到尾累死累活，转到另一个项目又是从头开始。所以说这些项目就把所有的技术人员全部都陷了进去，以致于公司技术部门空无一人，也就是一本书上所说的“软件作坊”。

 

      怎么跳出陷阱，走出软件作坊？

 

      下面是吕建伟先生说的两道防火墙教我们从哪里开始走出软件作坊。

      大家想想美国金融危机吧。美国经济发生问题，奥巴马首先做的是什么？是设立防火墙，不要让危机扩展到更多的行业更深层次的方面。

      我们想扭转公司现状，也是如此。先设立防火墙。

      走出软件作坊，我是以研发部门为中心的。当然，和我交流的大部分人都是研发部的。大家都是共同的视角，共同的权限，想解决需要变革整个公司模式的问题。

      我们不可能变革其他部门，只能从自己先下手。要走出的第一步，就是给自己设立防火墙，不要让自己的问题扩散到别的部门，也不要让别的部门的问题扩散到自己部门。

      这个防火墙怎么设立呢？首先得有人。没有人，说句脏话，就叫干个屁啊。

      但是，这立刻会面临到一个很现实的问题，没有人。确实没有人。老板也不给人，每个人都忙的很厉害。没有人啊。

      向老板申请人。这几乎是不可能的事。一般在现状，没有作出成绩还要人，这是不可能成立的事。鸡生蛋，蛋生鸡。有人是舍不得孩子套不住狼，有人是不见兔子不撒鹰。我们一般遇到的都是不撒鹰的主儿。所以大家不要抱怨，有啥人就用啥人，能改善多少就改善多少，尽力了。

     就现在这三五个人，大家看着办。为了拯救自己，不做也得做。抱怨起不了任何作用。

     OK，我们说有人。要有什么人？

     我说的是是开发项目经理。这个人得单提出来，不能开发编码，专门做需求管理、BUG管理、团队中每个人的工作计划、工作推动、团队内部资源调配、团队内矛盾解决、执行过程中异常问题处理、每天向各个协调方报告工作进展和工作困难。我说的各个协调方包括客户、客户老板、自己的上司、自己的老板、销售部门、实施部门、支持部门。

      我们整天在忙，其实在穷忙。很多穿插进来的事情和异常让我们常常不得不停下手中的工作，接电话、查找客户的BUG、临时修改BUG、给客户更新、跟踪客户更新后使用情况。我们本想完成的计划，都成了空话。当月底检验计划的时候，总会有一大堆的理由说是因为什么什么异常，所以无法按照计划执行。

      对，这就是没有防火墙，每个人都直接受到各种来源的直接干扰。而开发项目经理，就是防火墙。

      售前方面的方案制作、需求讨论、打单演示，销售部门反馈回来的客户现场提出的需求和问题，老板在客户现场发现的问题和需求，实施部门在实施过程中发现的需求和问题，客服支持部门在日常支持中转过来的需求和问题，在项目开发过程中客户的各个业务部门包括客户IT部门提出的需求和问题，这么多的冲击，需要有一个专门的人来统一归口，屏蔽。任凭外部这么多异常的穿插，有项目经理一人挡关，开发人员在研发内部安安心心的按照项目经理的工作计划扎实的开发着。

      不管收到多少需求和问题，每个人都觉得自己的问题是最简单的，是最需要立即解决的。每个人都会这么想。但现实就这么摆着，有100件事，就三五个人，看着办。累死也不可能把这100件事1天内干完。

      项目经理把来自各方的需求和BUG，统一汇总到一个EXCEL中。和各方讨论明白到底想要的是一个什么功能，细节是什么，会引发的问题是什么，都要项目经理来做好功课。确实要开发的，就根据现在的开发进展和开发计划、开发负荷，排好后续的开发计划。

      其他人着急啊，着急也没有用，你看，所有的需求和BUG都在这里，其他人也在提，不光是你销售部门一个部门在提。你看，我们的工作内容，已经排出来老长了。都很明确，大家没有偷懒，大家确实很忙，丁是丁，卯是卯，就是到了老板那里，拿出来这些EXCEL，老板也没有办法。就这点人啊。

      这就是第一道防火墙。

      第二道防火墙就是增加测试人员。软件不稳定，实施有问题会直接找开发人员，客服支持有问题会找开发人员。因为这些是软件BUG，就得开发人员跟踪和修改。怎么让软件稳定呢？我和很多人都聊过，在长久的不间断的修改代码接客户电话做跟踪支持的，程序员们普遍很累，对这种状态很腻，有厌烦心理，甚至有了虱子多了不嫌咬的无赖状态。

      这是人的正常生理和心理。程序是程序员用手一个个敲字母敲出来的，这是个手工作业活。人是肯定要受各种生活和工作的影响。人不是冷血动物，人也不是机器。人是感性的，人是需要生活的。

      这种状态存在，我们就要去解决问题，而不是一味强压。有时候，强压也失去了作用。想解决，臭骂一顿也没有办法。说吧，想不想解决？想，那我们就摆好心态，继续往下看。

      测试人员一方面会使软件质量提高，这样BUG少了，未来的程序员的支持就少多了，实施部门和客服部门的工作就轻松了，当然部门冲突也就会少了，合作也就比较改良了。

      另外，测试人员需要兼任技术支持人员。因为测试人员为了能测试出更多的BUG，把软件问题消灭在开发内部，所以他对软件的细节了解的仅次于项目经理和开发人员。测试人员比实施人员、客服支持人员、销售人员要了解软件深的多。他来做技术支持，他解决问题查找问题比实施人员、客服人员要快的多、准的多。这样就不需要干扰程序员了。程序员就可以正常的按照开发计划一步步继续了。

      而且，在实施过程或客户应用过程才发现的BUG，那就是测试人员当初没有测试到的地方。为什么没有测试到，为什么忽略了，以后要加强注意。这也是对测试人员工作质量的一个反馈。

      所以说，测试人员兼任开发部门技术支持人员，对测试本岗位工作非常有好处，是对测试工作的促进和提高，也给研发部门设立了第二道防火墙，防止实施部门、客服部门对程序员的干扰。

      只要程序员能安心工作。他写的代码质量就会提高，BUG减少，功能细节完善，思考周密。如果整天让他救火，程序员只能以救火的心态来工作。人不可能长期处于高度紧张救火的状态。

      有了这两道防火墙，负向转到的企业文化、部门冲突、工作质量、工作效率才能慢慢再回到正向转动上来。这就是开始的切入点。

      上面所说的两道防火墙都是在有人的情况下的一些措施，但现在就是整个部门空无一人，连普通的技术人员都没有，更别说那些技术骨干，都被陷入项目中，就是拉不出来，现在就是先用什么办法拉出这些人来？ 

      没有人不要紧，要紧的是，研发团队需要承担更多的工作。但这是理顺前，走向正轨的必然付出。在老板没有看到效果不投入人力之前，研发团队要想变好，是必然要付出更多的。大家不要想着和过去一样付出就能达到更好的效果。我们在现有人手下，有些人需要承担更多的开发工作，这样才能挤出一个人来做项目经理，专心管好需求、BUG、工作计划、协调、推进、汇报。这样才能挤出第二个人来做测试与技术支持。这必然会有人职业转型，会有人承担更多的代码开发工作。但其实，专心开发代码，一切杂事都屏蔽了，开发质量和开发效率都会提高，反而比过去工作更顺溜了。程序员，最擅长的还是自己本职的开发工作。

      但冰冻三尺非一日之寒。所以不要一有救火，整个改良就都放下了，重新回到过去的状态了。这是不对的。从负向到正向，必然有很大的逆摩擦。坚持，咬牙，挺过，负向的车轮才会静止，然后正向转动。想实施改良的人，必须要深刻认识到这个冲击，要承受得住，要有勇气来面对挑战，要有勇气来面对失败。

      你是否有这种牺牲付出和坚持推进的勇气？