laofo 推荐：宗绵大佬通过自己多年的工程实践、管理实践在组织管理、工具建设、目标对齐、绩效考核、用户故事粒度、MVP、过度设计、代码质量等方面进行了分享。造轮子有成本为啥还不断重复造？产品创意怎么评估验证？质量是免费的么？字字珠玑，没有上手实操干过的人，写不出这么深入的文章，推荐给大家。

关于官僚主义

就我个人而言，我一直批判官僚主义。它政治、迂腐、效率差等等，我想大家也对这个概念并不陌生。直到我看到了下面这段话：

官僚主义的目标是，通过将规则应用于行政行为来确保公平。规则面前，人人平等 -- 没有人会得到特殊优待，也没有人会被歧视。不仅如此，规则还能很好地体现组织所积累的知识；制定规则的官僚是来自各个领域的专家，这些规则将高效的结构和流程强加于组织，同时保证公平性，消除任意性。也许，最好将官僚主义型文化理解为：比完成使命更重要的是遵循规则。

嗯，希望看完这段话大家能对官僚主义有另外一个视角的看法。显然这段话里面也包含了一些前提条件，否则便是灾难性的。它预设了两个条件：1.制定规则的人是专家。但是我们都明白在现实中往往并非一定如此，我们的老板不一定比我们更加知道一线的细节，我们的老板不一定写代码就比我们厉害。往往职位越高不仅对于知识的深度有更高的要求，对于知识的广度也要求颇深。

创业当过老板的知道，不同的职能部门都需要你来做最后的决策，而如果自己在某个职能不够专业的时候，往往做出的决策怎么都会不够周全，甚至是完全错误的一个决策。2.规则本身是公平的。我们大概都应该知道法规是最低的道德底线。规则是最低的保障，它不能面面具到的涵盖所有场景和条件。再者，我们想利用规则来为自己行方便这显然也不是一件非常困难的事情，特别是掌握了一定的权力时，行起方便来还是很方便的。

我说这么多，只是想表达两点：

1. 尽管这么多年来官僚主义已经变成一个完完全全的贬义词，但其实官僚主义也有它的作用，并没有那么不堪，且自上而下的管理模式在目前还是被无数次证明是效率最高的一种。

2. 让官僚主义发挥它的价值是一件很难的事情，虽然每种方法论都有它的局限性，但落地的效果其实与组织的能力更加相关。

关于工具

我们常常在提倡不要重复地造工具，显然觉得这样并不是非常经济的行为。但是为什么会有人需要（是的，我说的是需要）重复地造工具呢？

我一直在说工具的背后是隐含了一种方法论，工具开发者希望通过自己的工具来解决某一个或者多个问题。TA 首先想到了解决某个解决问题的方法，然后开发出相应的工具。针对同一个问题，不同的人对于解决它的思路是不同的，从 A 地到 B 地，人们生产了不同的工具（或服务）：汽车、火车、单车、地铁等。对于工具的使用，不同的人也有不同的需求，比如可以选择自己开车、骑单车、打车、坐地铁等等，于是面对同一个问题，不同的的解决思路衍生出不同的工具。

作为一个工具，它面对要解决的问题有一定的针对性，它无法完全覆盖不同团队的管理模式，不同团队的现实状态。它不妨是一个好的工具，但是对于某些团队来说引入成本过高，所在团队为了解决特定的问题需要自己制作一个相对更低成本的工具来解决遇到的问题。即便一个工具大部分的功能可以被复用，但是当使用方需要对一些功能做出调整或者添加新功能时，会面临在需求优先级的冲突，对于使用方来说是高优先级需要解决的需求，在工具研发团队来说可能只是一个特别小的需求，而无法马上去实现功能上的支撑，这个时候使用方需要面对两个选择：1.自己学习工具源码然后自己实现；2.自己做一个新工具来满足自己的需要。嗯，还有一个情况是：使用方的需求与工具研发团队的思路是相违背的，而被工具研发团队拒绝实现。

【注：复用也是需要成本的 1）发现成本 2）使用成本 3）改动成本 4）等待支持成本】

目标与绩效

关于 OKR

OKR 提出来并被大家知晓已经有不少年头了，但是真正能把这套方法论很好落地的案例少之又少。在我接触的大多数人中，都把 OKR 当作一种绩效管理方法来看待。重要的事情说三遍：OKR 不是绩效方法，是目标对齐方法。OKR 不是绩效方法，是目标对齐方法。OKR 不是绩效方法，是目标对齐方法。而且 Google 也没有废弃 OKR，他们变更的绩效管理方法。

简单地讲，OKR 就是 CEO 定了一个目标“今年公司的利润率要增长 20%”。这个时候不同的部门再各自按照各自的岗位来确定自己的目标和工作内容。比如对于 人力部门来说：他们可以招聘能力更好的员工，也可以淘汰掉更多不合格的员工。对于市场部门来说：他们可以提高 ROI、减少营销成本，也可以加大市场推广力度来增加销售额。对于研发部门来说：他们可以研发更多产品市场，也可以优化研发流程降低成本。出发点在于每个部门都比 CEO 更加接近一线，他们更加知道所在岗位的问题、所在领域的发展情况，因此应该比起 CEO 来决定他们应该做什么，他们自己决定自己如何完成既定目标更加可靠、接地气。

而现实的状况是，OKR 这套方法对员工的能力有了更高的要求，需要有更好的主观能动性，要更加善于思考，更加全面的能力要求。在目前大部分的螺丝钉管理模式下，他们已经被驯化成一个听话的员工，领导喊我做什么我就做什么，做完就收工。他们不被允许有过多自己的自主操作空间，他们的工作计划、工作内容已经被上层管理者详细思考和拆解，他们不需要过多思考，只需要按照计划和安排的工作内容按部就班完成好自己的工作就可以了。推行 OKR 方法将会彻底的改变他们的思维方式和工作方式，基层员工们举步艰难，他们无法做出正确的行动来完成目标，这种改变带来的无形阻力让 OKR 的落地变得异常的艰难，推行失败自然也不足为奇了。

关于绩效考核

很多年前，有幸参与为一个百人研发团队制定绩效考核制度，并最后以失败告终。作为人类我们是复杂多样的，且对于同一个人来说，TA 也无时不在变化（嗯，我不用成长这个词，因为有时候是走下坡的）之中。

当时在制定制度的时候，我就知道需要考虑到不同岗位，不同人之间的细微区别。另外也希望能改变绩效考核一直是领导主观评估这样一个现状，应该是可以做到客观量化的。我先是按照不同岗位列出不同的技能点，然后不同的技能点分出不同的能力掌握程度，且具体的定义不同掌握程度的衡量标准（其实并不能完全量化，有些也是主观的衡量，比如对 JAVA 的掌握程度，不可能去考核每个知识点，而且有些知识点实际工作根本用不上）。这份岗位技能标准也是一份岗位晋升的指引，一套成长体系，只要掌握了其中某些技能到达某个程度就能升职为某个岗位。每个岗位会有不同的 Excel 表格，先下发给全员研发各自填写评估当前自己的技能程度，做摸底调查，作为年末绩效评估的基线。

这套制度很细致，于是它就很复杂，评估成本很高，如果不细致它就无法覆盖现实中的各种个性化的差异。它深深地陷入了各种自身的矛盾中。另外，它只是衡量了技能，没有衡量产出，要衡量产出就需要再引入一套复杂指标。它会朝着一个越来越可笑的方向发展。

足够的主观是一种偏激，足够的客观也是一种偏激。人的主观感受也是一种指标，是否善于合作，是否善于沟通等等都应该被列入考核的范围内。但是这种主观的感受并不能被量化度量。两个有相反性格差异的人无法顺利地合作，但并不表示这两人是不善于合作和沟通的。

好了，这个事情做不下去。既然做不到，让各位负责人自己决定就好了，说不好听叫甩锅，说得好听就是充分信任向下授权了。绩效这个事情总会有人不满意的。

顺便说一下，没事不要折腾绩效。对于基层员工来说，他们的第一反应是，老板又要一套规则来剥削我们了。调整绩效规则会带来不小的风波，而搞不好就是激起民愤，这个时候，公司想不倒也挺难的，不伤点元气都对不起它这个名字。所以没事别折腾，本来大家还好好干活，一折腾大家都没心思好好干活了，然后还有一波要离职的。各位老板好好想想自己折腾绩效到底为了啥。

关于故事

故事（需求，以下统称故事）是流程最开始的一环，它的质量直接影响后继环节的质量。大多数情况下，我们都更应该回到故事环节来思考，是否我们在做故事评估、故事拆分、故事演进等环节中是否可以进行优化调整，从而解决后继流程中遇到的问题。

MVP

MVP 最小可用性产品，大家对这个概念应该都不陌生。但是谁又能说自己合理的定义了一个 MVP 呢？每个人对这个概念都要有一些自己的理解和看法。在不同的场景下需要验证的需求各不相同。即便在相同的场景下，也有不同的需求需要验证。还记得上面提到的从 A 点到 B 点吗？单车、火车、油车、电车的 MVP 定义是各不相同的，且无法断言哪种方法就是有效验证。

有些团队资源更加丰富一些，他们会用用户调研来验证自己的需求假设，但是被调研的人群种类、数量是否能够足够充分地验证假设呢？比如：向男士询问什么卫生巾更好用；向 80 岁老奶奶询问哪个口红颜色更好用；向低收入的年轻女生询问对名牌包包的需求；向不去肉菜市场的人询问是否需要改善市场环境等等。向 1000 个人中的 100 人进行了调查取样来证明另外的 900 个人也有同样的需求，看起来也是不太可靠的。发生幸存者偏差的可能性是很大的。

创意无法预先评估，只能被市场验证

一个新的创意或者业务需求被提出的时候，我们如何才能衡量这是否是一个好的创意和需求，而不至于浪费后继更多研发、市场推广等等的成本呢？我们要如何掐住成本的喉咙？反正我自己是不够聪明能够想出好的度量方法，更多的是自己自以为是的主观感受，一种不知道从哪里来的自信。

作为最终的用户大概他们也不知道需要的是什么，当询问他们是否需要一台带触摸屏的手机时，答案可能是否定的，但是你把 IPhone 给他们看的时候，他们眼睛会发光。而这样带来的验证成本是极高的，起码你要做多几台样机出来给用户看看。更接近现实的状况是大多时候用户的反馈是负面的，像 iPhone 这样出圈的产品在这个世界上并不经常发生。

于是，业务敏捷是该出现的时候了，为了降本增效，需要让创意更加快速的推向市场，业务部门也需要敏捷起来。关于业务敏捷我没有更多可说的（主要是不懂），只是告诉大家有这么个概念。它好像还不太出名，因为我偶尔才能从别人那里听到这个名字。

故事粒度

一辆汽车和一辆单车的制造成本是不同的，在定义故事的时候，我们需要充分考虑故事粒度，以便让它更快的速度完成研发推向市场。我经常遇到觉得研发速度慢，一个功能要做很长的周期才可以推向市场的抱怨。作为直男研发人员，我们的直觉是去堆人、优化研发流程，很少去思考如何在需求的角度解决这个问题。当一个故事被确定下来之后，它的工作量基本就确定了，所以在一开始确定故事时，就应该考虑它的实现成本，避免需要使用过多的工作量才能推向市场。我们更应该拆分过大的故事，通过不同的迭代周期控制大故事的上市周期。这样也可以更快地收到市场反馈来调整故事。

顺便说下，我不是说堆人、优化研发流程不重要，只是想说明故事的粒度相对更加容易能够直接控制推向市场的时间。

过度设计

过度设计这个事情很微妙，非常的见仁见智。过度设计显然是一种成本的浪费。但想要不过度设计，需要有一个合理预见事情未来发展的能力。我们设先假设我们某个功能的服务的会有较大的用户群体和访问量，于是我们在设计中通过加入缓存等等的技术手段来提高系统性能。我们也会预设下个版本需要增加的新功能，而预埋一些在当时看起来合理的设计。但是现实是可能这个功能上线只有少的可怜的访问量、可能下个迭代我们调整了产品方向而导致之前预埋的设计并没有发挥作用，于是之前做的准备工作就变成了过度设计，但是能完全说之前的预估在事情发生的当下是不合理的嘛？我想也不能这么说吧。这也许就是所谓的成功之后，说什么都是对的吧。

代码质量

我相信大家都认可质量本身的重要性，但在实际的研发活动中，我们常常迫于业务功能的完成截止时间而对质量有所取舍。编写单元测试、性能测试、重构等等质量活动在截止日期面前都显得不那么重要了，我相信这个便是大多数团队中的现实状况。我们常听到的是下个迭代再补上，而下个迭代其实时间也是很紧迫的，根本没有时间来完成这些非业务需求。而同样的大家也都在吐槽自己项目中的各种质量问题，并且对此束手无策。

首先我们自己就是项目成员，项目代码就是我们自己写出来的，那么第一个要问的就应该是问问自己，为啥自己写出来的代码质量过一段时间回过头来看的时候，质量并没有那么高？其实自己就是那个制造质量问题的罪魁祸首。我想我们首先需要承认的就是自己的技术能力有待提升，并且在这个认识之后努力付诸实践的提升自己的代码能力。

我承认比较好的质量是有成本的。就我自己的开发经验来说，写面条代码是最一气呵成的方式，而且它可以正常的运行，但是当我需要考虑设计模式的时候，需要按照逻辑拆分方法的时候，需要符合 Linter 规则的时候，确实需要停下来想想如何处理更好，写代码的速度的确会有降低。但是经过一定时间的练习之后，这个速度是会有不少提升的，并且写出来的代码质量要更好的。当然，这需要老板们能扛得住截止时间的压力，允许生产力在某段时间的下降来让团队去做更多的练习，而这个某段时间的范围根据不同团队的具体情况而有不同，这与学习能力有关，可能很短也可能很长，还有可能失败。

说质量不能免俗的总要提提单元测试，写单元测试比上面写相对高质量的业务代码其实难度更大一些。我们在说单元测试最大的价值在于在修改被测试代码之后，可以通过运行单元测试来检测修改后的逻辑是否正确，是否影响了原有的代码逻辑。但是在现实的案例中，我们经常会因为需要去 Mock 被测试方法依赖的逻辑， 而导致单元测试过度的描述了被测试代码的逻辑，于是导致单元测试用例无法被直接复用，我们修改为被测试代码之后，做得更多的是修改测试用例来让让这个测试可以通过。其实这样已经违背了测试用例存在的意义，反而成倍地增加了维护代码的成本。我想说的不是测试用例做不到让系统更可靠，而是想说其实写出合格的单元测试是一种不小的挑战，它需要更多的思考和练习才能达到的。

资本的角度

我想大家心里都明白，真正产生利润的是业务部门，研发部门是成本中心，并不直接产生利润。现实状态下谁赚钱谁是老大，谁赚得越多话语权就越大，于是研发部门往往活得也憋屈，想推行一些新东西新方法，做出一点改变的时候，得不到业务部门的支持也只能作罢。站在业务侧来说，让新功能上线，满足客户需求帮公司赚取更多收入才是最重要的事情，要用 10 块钱的投入赚取 100 块钱的回报。而系统的稳定性跟性能只要在一个合理的范围就可以，并不需要精益求精，因为终端客户并不需要，他们需要的是一个可以正常运行的产品就已经足够了，而不是一个高性能的产品，他们也不会为更好的稳定性跟更好的性能多付一分钱。

在客户角度来说，仿佛稳定性和高性能并不需要付出任何一点成本而是本身就是理所当然的最低产品标准。对于研发团队来说，无法证明提高了 1 秒的响应速度到底给公司带来多少利润，甚至可能因为引入了其他中间件而导致花费了更多成本。

在大部分情况下，一个产品的生命周期并没有足够长到需要为质量买单的时候，很多时候一个产品的瓶颈不在它的质量，而在于它的市场规模远远没有想象中的那么大，因为错误的预估市场、用户需求而胎死腹中的产品远远比因为质量不过关而失败的产品多得太多了。所以我认可在产品的初期阶段，是允许产品的质量大不了预期标准的，这个时候把产品快熟推向市场获得反馈来得更加重要得多得多。当然，在验证了有效需求和用户规模之后，对于质量的要求应该严格地提上日程，并要还上之前欠下的质量债务。

另外，在业务能够赚到足够利润的时候，其实相对低效的研发效能和高昂的成本并不是一个首要的问题，更甚者的是这可能是一个业务上天然的壁垒，意味着竞争对手大概率也要付出等额或更多的成本。在利润可观的情况下，往往浪费会变成一种默许，用于彰显自己的实力。只有当市场不景气，追求更高的利润率时，研发效能才会被摆上台面，成为公司活下来的救命稻草。但到了这个时候也就为时已晚了。

最后

有人提醒我，这仿佛是在用一种纸上谈兵的方式讨论如何不纸上谈兵，之后，我深深地陷入了这个驳论中。我努力地让这篇内容更多描述现实之中的细节，但也因为自己本身认知的局限、世界的复杂而无法完全一一认识和描述。就像开头说的，时至今日我们对于官僚主义也并没有一个很完整的认知，同样的道理，这篇内容的观点不一定对 （更可笑的可能是以上的这些只是我自己不知道而已，且我以为很多人都不知道。），且当它被写出来的时候已经过时，作为作者的我无法也不能实时的向大家更正我的观点和认知。但也希望这个内容能够带来一些启发和思考。

最后的最后，希望我们能够跨越现实与理想的鸿沟，一起构建那个我们理想中的世界。好运。

感谢点赞、转载，关注我，了解最新研发效能发展动向，欢迎进入「DevOps 研发效能群」一起探讨