走出软件作坊的秘密

《走出软件作坊》已经一周岁了。在这一年里得到了许多朋友的钟爱，也收到了许多朋友的来信。

仁者见仁智者见智。有人从书中看到了心态和坚持，有人看到了朴实的创新（原来创新就是这样，不要整天大战略大构思大蓝海），有人看到了术，有人看到了方法论。每个人都或多或少能收获到一些东西，这已经达到了这本书想要传达的目标了。

有的朋友想改变现状，在日常工作中尝试着使用了一些书中的方法。有些方法非常好，简单、易实施、不用申请资源调配资源协调他人，就能很好的达到效果。有些方法尝试了，但是不起效果，或者效果微乎其微，深叹积重难返，非一点能撬的动的。于是就反复看书，想了解到笔者是怎么把一个乌合之众扭转成兄弟连的进而走出软件作坊。但是，看来看去，还是找不到下手点。越看书，越发觉书中讲的内容是融会贯通的，从组织结构、职责划分、过程管理、考核、企业文化、经理修养，是整个连贯的，单一方面很难支撑方法执行达到效果。要么全部实施，要么只能用些小方法小点子当改善，不能从整体上进行新的面貌。

于是，就成为了困兽。看着方法不错，但现状无法改变，焦躁。焦躁过后是恢复到过去，继续撞钟，反而心态更不如过去。有人忍不住了，给我打了电话，希望当面请教。

这是书中的一个忽略。直到这一年经过，我也才认识到关键的那个开始点在书中没有讲明白。我只是安排组织结构、过程管理、未来发展、企业文化、个人修养这几方面讲下来，至于如何从现状扭转，先从哪个点切入，这点当时始料未及。

所以我在这里给大家讲讲。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这就是第一道防火墙。

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

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

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

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

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

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

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

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

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

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

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

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

《走出软件作坊》网上评论：

http://www.douban.com/subject/3319935/

《走出软件作坊》网上订购：

互动网：http://www.china-pub.com/508874

卓越网：http://www.amazon.cn/mn/detailApp?prodid=bkbk812538&ref=GS_TS&uid=168-8093432-0389064

当当网：http://product.dangdang.com/product.aspx?product_id=20435119