研发团队中的边界原理

我曾在某软件公司作为顾问参与研发管理日常工作，在公司日常工作中，从销售到工程师都非常敬业，销售在接到客户的问题后，立刻会找到工程师协商解决，研发部的主管和工程师们会立刻一起讨论问题。讨论内容相当全面，从客户问题到实现细节都有。很快，有工程师把问题解决了。这样的情况经常发生，其实也就是企业的一种工作习惯，如果大一点说，就是一种企业文化。

这样做究竟好不好？我曾分别和研发部主管、销售等面谈，销售也有自己的抱怨，所有的事情都是自己从头跟着，技术问题也要参与解决，很累啊，有时候一个报表的数据技术也不知道对不对，自己必须跟着才能保证，等等。研发部有时候会直接拒绝业务部门提出的需求，例如会影响性能，有时候需求经常变动，造成返工的情况很多。以第一段的例子来说，可以想象，在讨论过程中，大家都积极参与，但是责权不明，问题可能是很快解决，如果后来发生相关问题，就无可追溯，存在着不少隐患。

可能有人会说，解决问题就行了呗。如果一个人只是自己干，而且这件事情只干一次，那么完全可以。实际工作中，一个项目往往需要很多人一起共同参与，一个问题往往可能成为新问题的起点。大家将会关心问题是什么？客户想干什么？问题出现在哪个版本？还需要改哪些版本？该问题讨论了哪些相关问题？是不是关系到系统架构？是不是影响其他业务模块？。。。。。。还会有很多只有你碰到的时候才会想得到的问题。

大家都有把事情做好的愿望，更重要的是掌握正确的方法。我不知道管理学中有没有边界原理这个术语，在研发管理的实践中我提出“边界原理”，任何一项工作的参与者（人或者组织）均有自己的边界，每个参与者首先有责任和义务完成自己边界内的工作，参与者之间通过明确的接口进行交流，交流包括方法和数据。例如，交流方法包括EMail、电话、一对一面谈、会议等，数据包括对问题的描述、客户的要求等等。说白了，就是各负其责。在很多大公司中，企业已经建立了良好的工作习惯，或者叫企业文化，每个人从工作开始就形成了自己的工作边界，在发展中的企业中，往往还是存在想怎么干就怎么干的行为，这倒不是说大家有意的随意工作，而是认为自己的按对的方式工作。就像石真语老师说的一句话，世界上最可怕的事情不是自己不知道，而是不知道自己不知道。关于团队中成员看待改进的话题，以后再单独讨论。

任何工作的参与者均有一个领域，随着对外接触的角色不同，领域的范围也有所不同。例如销售是与客户和研发部打交道，与客户打交道时，其领域是公司，客户不认为你是销售甲还是乙，他只认为你代表了公司；当与研发部打交道时，销售代表了项目的销售团队。同样，研发部工程师在面对客户、销售和同事时，其领域分别是公司、研发部和自己，因此，对待对方的方式以及自己的职责就会有所不同。再讲一个案例，有一次开会培训QMS（质量管理系统）使用，提到了Bug的优先级分为P1~P5，其中P1最高。有一个业务部的同事讲，我的问题都设置为P1不就行了，我说，你当然可以这么做，但是你得讲出来为什么？对于P1~5是有一定规则的，而不是以自己为中心随便设置。说白了，工作都是为客户服务，而不是满足某一个人的日常工作。

在第一个案例中，销售与研发部在工作中有着明确的边界。相信很多公司已经建立了规范明确的流程，但是不得不承认，在执行过程中还存着一定的难度，关键看公司的领导者是不是一定要变。老板作为公司的头（借用石真语老师的定义），只有他坚定了规范化的信心，改进才成为可能，否则还不如不改。