鱼熊兼得——管理的追求

小时候，我一直对“鱼和熊掌不可兼得”这句俗语有疑问：两者为什么不可兼得？学习了孟子的原文：“鱼，我所欲也；熊掌，亦我所欲也。二者不可得兼，舍鱼而取熊掌者也。生，亦我所欲也；义，亦我所欲也。二者不可得兼，舍生而取义者也。”之后方知，不是两者不可兼得，而是在二者只能选其一的情况下，必须做出取舍。

管理所追求的不是二选一，而是两者兼得，是效率与效果兼得。

效率和效果是衡量做事情成效的两个维度。效率是做事情的产出与投入之间的比值，比值越大，效率越高。比如读书，同样投入一个小时，A读完50页，B读完100页，B的读书效率是A的两倍。效果则是指做事情结果好坏，是做事情的质量。A一小时读完了50页书，合上书本，不仅能够条理清晰地复述出所读的内容，还能谈出很多自己的思考和感悟，B一小时读了100页，但合上书本之后，只能零星地说出一些不连贯的内容，更没有任何自己的思考和感悟。尽管B的读书效率高，但读书的效果远远不及A。

管理既不能片面追求效率，也不能片面追求效果，而是要两者兼顾。换句话说，管理追求的是“又快又好”地做事情。

为了更深入地理解这一管理的本质，有必要就管理与技术的关系进行一下阐述，因为技术也关乎做事情的效率和效果。

酸辣土豆丝是很多国人喜欢的一道菜，但仅仅切土豆丝一道工序就让很多人望而却步。土豆丝切得又快又好，需要经过长时间训练，掌握了较高的刀工之后，才能做到。如果刀工不行，还可以购买切土豆丝“神器”，使用专业的工具，土豆丝也可以切得又快又好。在这里，决定切土豆丝效率、效果的是刀工和专业工具，都属于技术范畴，与管理无关。人类发明了大量的技术，制造了难以数清的工具，都是为了增进做事情的效率，提升做事情的效果。这样的例子，每个人都能列举出很多。

技术在提升效率，改进效果方面不是万能的。当一种产品的生产、一项服务的提供需要分工完成时，技术只能用以改进某道具体工序的效率和效果。产品（或服务）整体生产效率和效果的提升，则需要管理的加持。（注：管理产生的根源在于劳动分工，想了解这方面的观点，请点击阅读《劳动分工——管理的缘起》一文。）

管理对效率、效果的关注与提升，与技术本质不同，可用我正在提供咨询服务的一家企业为例，对此进行说明。这家企业是一家软件开发公司，为各种组织用户定制软件产品。为方便问题的阐述，我们将软件产品的生产简化成三项工作：对客户需求的了解、软件开发、软件测试。三项工作分别由售前人员、开发人员、测试人员分工完成。软件产品的生产效率高低主要取决于所花费开发工时的多少，开发时间的长短。用的开发工时越多，时间越长，生产效率就越低。软件产品的效果，主要看用户的使用体验，用户的体验越好，满意度越高，则说明软件产品的效果越好。

该企业的软件开发效率有很大的提升空间。其软件开发过程中变更非常频繁：有时是一些功能开发完成后，发现其深度达不到用户要求，需要返工；有时是功能开发完成或者基本完成时，发现该项功能用户并不需要；有时是软件开发到一定程度，发现需要增加某些功能，而为了增加这些功能，其他模块需要配套进行调整……每变更一次，就要增加所用开发工时，既提高了成本，又导致工期的紧张，大大降低了软件开发工作的效率。

该企业软件开发的效果同样存在改进空间。很多开发中的问题只有等到产品上线后，在使用过程才能被用户发现，这必然导致用户体验的下降，满意度的降低。

通过深度访谈，我认识到软件开发效率和效果之所以不高，最主要的原因在于对用户需求的了解不到位。公司的现行做法是：客户需求的了解主要由售前人员承担，售前人员将了解到的客户需求口头传达给开发人员；开发人员根据从售前人员处获得的需求信息展开软件开发，只有他们在开发过程中认为需要的时候才会跟客户沟通，进一步了解客户的需求，开发人员一般不会将这时了解到的顾客需求信息向其他相关人员传达；在整个软件开发过程中测试人员对于客户需求的了解较少。

根据公司的实际情况，为提高软件开发效率，改进软件开发效果，针对客户需求调研，我提出了如下解决方案：

（1）制定用户需求调研纲要。公司成立“用户需求调研纲要编撰小组”，成员为软件开发部负责人、售前部门负责人、测试部门负责人。该小组负责纲要的编撰和迭代工作。纲要需要条理清晰地罗列出进行用户调研都需要了解哪些问题，并对每个问题需要达到的程度做出规定。编撰小组需要定期对纲要进行迭代完善。纲要是公司用户需求调研工作相关经验的沉淀和共享，为售前人员了解客户需求提供了一个标准化的用户需求调研规范。

（2）售前人员向开发人员提交《用户需求明细表》。售前人员将了解到的客户需求，形成详细的《用户需求明细表》，将用户需求向开发人员以书面方式传递。公司要配套出台《用户需求明细表》编撰规范。

（3）召开用户需求分析会议。会议由售前人员负责组织，参会人员有项目开发人员、测试人员。会议上，售前人员针对《用户需求明细表》，将了解到的用户需求给开发人员和测试人员进行详细解读，参会人员就用户需求展开讨论，并达成共识。会议结束，要形成所有参会人员签字认可的《**项目用户需求分析报告》。

（4）召开用户需求反馈会议。会议由售前人员负责组织，参会人员有项目技术经理、测试人员、用户关键干系人。会议上，项目技术经理以《**项目用户需求分析报告》为基础，向用户详细汇报对用户需求的认识，充分听取用户意见。会后，售前人员、开发人员、测试人员三方共同对《**项目用户需求分析报告》进行补充完善，并签字认可。以完善后的《**项目用户需求分析报告》为基础，形成一式两份《**项目用户需求调研备忘录》，加盖公司公章后，将其中一份发给用户备存。

（5）召开软件开发框架研讨会。开发团队形成比较详细的软件开发框架后，具体的开发工作开始前，要召开这次研讨会。会议召集人为项目经理，参会人员有项目技术经理、测试人员、用户关键干系人。会上，技术经理向用户介绍开发框架和思路，进一步征求用户意见。会后，根据用户反馈，对开发框架进行完善，形成一式两份《**项目开发框架研讨备忘录》，加盖公章后，一份发给用户存档。这次会议完成后，就可以展开具体的软件开发工作。

（6）建立开发过程中的需求信息反馈机制。开发人员在开发过程中了解到的客户需求，必须同时向其他相关人员进行反馈。需要公司在相应的制度中，就什么时间、向什么人反馈，如何反馈等做出规定。

（7）对开发、测试人员的考核办法进行调整。考核办法调整的核心，是兼顾对效率和效果的考核和引导，追求效率、效果兼顾。

以上措施的阐述，还是一个高度简化的版本。实际工作中，要把它们转换成具体的、详细的、可操作性很高的流程和规范，并且要严格督导执行。流程和规范还要不断进行迭代升级。

考虑到有些朋友对软件行业可能不太了解，这里有必要解释一下，为什么要让测试人员深度了解客户需求。对于软件开发来说，测试承担着低级和高级两个层面的任务。较低一级的任务，是通过测试发现开发人员在开发过程中不容易发现的问题（行业内一般用“BUG”来称呼），然后反馈给开发人员，进行修正和完善。较高一级的任务，则是测试人员能够站在用户的角度去发现产品的一些问题，在交付给用户之前就能将这些问题解决掉，而不是交付给用户之后，让用户在使用中发现这些问题。要更好地完成较高一级的任务，需要测试人员准确、深入了解客户的需求，这样才能有针对性开发出优质的测试案例，开展富有成效的测试工作。

上述七条措施，目的都是提高软件开发工作的效率和效果。我相信读者朋友，能够看出这些措施与切土豆丝的刀工、神器有着本质差异：它们不属于技术范畴，都是管理措施！与技术往往着眼于某一道工序的效率提高、效果改进不同，管理更关注提升具有劳动分工的工作任务的整体效率和效果。

效率和效果兼顾，是管理的目的，也是管理的本质，每一位管理者需要彻底参悟透彻这一本质，将其内化于心。当然，光内化于心是不够的，关键是要外化于行。所谓外化于行，作为管理者要养成这样的工作思维习惯：每天要琢磨自己分管范围内的工作，还存在哪些效率不高，效果不好的方面，分析其原因，然后想方设法提高效率，改进效果。让追求效率提高，效果改进成为一种长期坚守的思维习惯。如果做到这一点，即使是一个管理小白，也会很快成长为一个卓有成效的管理者。

套用并改写一下《孙子兵法》开卷的一句话，作为文章的结语：双效兼顾，管理大事，死生之地，存亡之道，不可不察也。

感谢作者对本文的分享和授权。

如需获取更多信息，请关注公众号“淡泊宁静做学者”。