写在前面

距离上一次写点东西好像已经过去了很多年，其实是觉得敏捷转型里东西就那点东西，反反复复唠唠叨叨也没什么意思，翻过来调过去就是类似“减肥就要管住嘴迈开腿”一样正确而无用的废话，起初我也不知道问题出在什么地方，只是隐隐约约觉得这就是个胜利者的游戏，成功减肥的人说什么都有道理，成功的企业家好像干什么都成方法论，那对于还在路上、还在山脚下的人来说，该如何选择自己要走的路呢？我好像琢磨出来点什么，又好像没有，姑且呢喃出来，让自己再多想想。

关于认知

知行合一的知

认知影响判断，判断决定行为，行为改变环境，环境又会塑造认知。
你可以想象一下，你认为身边哪些事情是可以被改变的，哪些是必须要遵守的条件，就简单行人过马路一件事，我相信所有人的认知都是有所不同的，有人认为必须严格遵守交通规则，绿灯行红灯停，哪怕是放眼望去几公里之内都没有车；有人认为绿灯行红灯停是有条件的，如果你觉得周边是安全的，那就可以闯红灯。
后者就更有意思了，因为不同的人对“安全”的认知是不同的：有人觉得大晚上的几公里之内都没有车，那才是安全的，可以闯红灯；有人觉得自己身怀绝技，哪怕车水马龙车子呼啸而过，也能闪转腾挪猴顶灯耍杂技。
这就是认知如何影响的行为。
如果有一个平时闯红灯习惯的人，有一天被车碰到之后在医院里躺了一百天，有很大的概率，他的行为所带来的后果会影响他的认知，也许之后他就变成了一个红灯停绿灯行的人。
这些其实没什么难理解的，动物都是这样：按人说的做，从水里跳起来顶到球就有小鱼吃；听到铃声、一流口水对面那个大胡子就会低头在本子上写东西。
更何况人呢。

关于“专业领域”

我们需要学习的东西无非就两样：自己认为正确的认知和过硬的技术。真正某个领域的专家，必定都会知道在自己所处的领域之中，有一些外行看起来很“反直觉”的东西。
比如想用双手装尽可能多的水，用力抓和攥是没有用的，越用力越少，把手掌朝上张开并拢才能装更多的水。
比如PMBOK里的项目管理铁三角，教科书里就说清楚了：除了“好”不可妥协，“多”、“快”、“省”三者只能取其二，这也是个对外行“反直觉”的例子。
比如衡量一个开发工程师的好坏，去度量代码行数是没有用的，代码行数又不是越多越好。
软件工程的这个问题会更明显一些，软件工程的管理和技术进展非常快，2000年时候的技术和管理放到2022年显然会格格不入，比如云原生、比如DevOps，更不要提上世纪60年代总结出的软件工程知识体系，那个时候机器是比人贵的。
所以对于软件工程的认知也是需要与时俱进不断学习的，出了大学校门开始从事软件产品开发，才算是刚刚开始。

我自己对软件工程的认知

2001年的《敏捷宣言》其实讲的就是认知，只不过多数人对它的理解都不到位，觉得里面写的内容都是前提，但实际上是认知。两者的差别在于如果你把那些话当成认知，就有了一把尺子，能帮你识别哪些是是约束，需要被尊重，哪些是问题，需要被解决。直到问题一个一个被解决掉，离乌托邦就越来越近了。
反过来，如果你把它当成是前提，那就会始终感觉自己生不逢时。
这些认知直接决定了后续管理手段和沟通方式。
我也知道想改变他人认知是一件非常困难的事，历史上尝试这样做的人都没什么好下场。
我无意去改变他人，所以我以分享的方式，谈一下我自己对软件工程这件事的认知，但也仅限于当下，也许过一段时间就会发生变化。
姑妄言之，姑妄听之。

• 需求不是做得越多越好
• 需求变更是无可避免的
• 缺陷是可以避免的
• 软件开发不是高科技，而是沟通的学问

1、需求不是做得越多越好

而是在不断提升业务满意度的前提下，做得越少越好。
过去我对敏捷宣言十二原则中的“极力减少不必要工作量的艺术”这句话感觉很费解，英文原文更拧巴：“the art of maximizing the amountof work not done。”
直到我工作了十年以后，亲身经历了很多项目、旁观见识了很多项目之后，才慢慢体会到这句话的意思，其实用人话来说的话，就是用尽可能少的功能来最好地满足尽可能多的需求——需求并不是做得越多越好。
如果还理解不了的话，对比一下微博和推特，再不行就想想各种APP里的种树养鸡的小游戏。
多数技术团队把需求量当作重要的指标的时候，作为业务方的感受就是这样事儿的：

“你这菜不好吃。”
“可我们量大。”
“你这菜不好吃，也不卫生啊。”
“我们会努力在更短的时间内提供更大的量。”
想要解决这个问题，需要做到以下两点：

真正理解用户的需求

绝大多数的技术团队是不具备“理解用户需求”能力的。
早些年企业内的技术团队以及做toB软件产品的软件公司是没有“产品经理”这个职位的，有的只有“业务分析师”。随着过去10年互联网、移动互联网的兴起以及乔布斯的带货，“产品经理”这个职位逐渐被业界所熟识，产品经理的职责恰恰就是理解用户的真实需求，并将需求用良好的设计和功能实现出来。
目前软件产品已经深入到了每个人的日常生活，淘宝、微信、微博、抖音、B站甚至招商银行APP都在影响并塑造着每个人对软件产品的期望，15年前，通过表单进行数据操作就已经能满足很多业务场景了，而2022年别说一个超大的、填写不方便的表单，就算是不支持多端数据同步都已经会被吐槽了。
在这样的环境和背景下，B端产品的打磨也会越来越像C端产品，除了功能之外，效率、体验甚至配色都是需要考量的要素。而且更麻烦的事是B端的业务产品由于有复杂的业务逻辑在背后，平衡复杂的业务逻辑和出色的用户体验就变成了一件更加困难的事，所以目前优秀的B端产品经理真正是一将难求。
正如在上文中提到的“领域专家”，每个领域的专家都会有一些自己的“独门秘籍”是不为外行人所知的，而且由于“知识的诅咒”的存在，他们也很难将自己这些“秘籍”讲得出来。

比如电子商务里的“退款”流程，如果你在设计系统的时候本着“退款越快越好”的原则把系统做出来，我相信从CEO、CFO到客服总监都会对着这个系统骂街，但究竟为什么不好用，就不见得能/会讲清楚了。
那么如何能够做到理解用户，或者说业务用户的需求呢？这就是一个完整的精益需求管理的方法论了。

具备基本的成本意识

如果作为一个技术，在产品设计方面一时半会儿无法有突飞猛进的提升的话，至少可以从成本入手去和业务方进行沟通。投入产出比，产出不好算，投入还不好算么？需求的大小估算、耗时、资源投入，只要能逻辑自洽深思熟虑，那就开诚布公地和需求方去沟通吧，投入产出比自然有人会去帮你计算出来。

2、需求变更是无法避免的

频繁地增量式交付

我们能做的只能是频繁地增量式交付，让迭代周期比需求变更周期更短，毕竟俗话说“夜长梦多”。
如何能够让迭代周期变得更短一些，敏捷开发里的多数方法论都是为了解决这个问题的，包括短迭代、小批量、自动化、协同模式等等。
如果说有降维打击的话，云原生会是个方向，只不过我自己对云原生也在学习中，而且云原生作为一个还比较新的技术方向，整个业界都还在熟悉和普及中，持续保持关注就好了。
以我自己对云原生有限的理解，它是更高的一层抽象，把资源算力等进行了更好的封装，使业务开发可以更多地去理解业务本身。

3、缺陷是可以避免的

所有的软件工程方法论都基于一个共同的目标：如何能够更早地发现缺陷并修复。
我们在软件工程的课本里早就学习过：缺陷发现的时间越晚，修复它的成本就越高，但反过来却不见得成立，因为提早发现缺陷这件事本身就是需要付出成本的，在这里面有两个可以努力的方向，一是在软件功能生命周期的更早期发现缺陷，能在开发阶段发现的就不要拖到测试阶段；二是在交付时间的更早期发现缺陷，比如一个一年的项目，在第一个月发现缺陷就比第十个月发现缺陷要经济一些。

在软件生命周期的更早期发现缺陷

软件是对业务需求的实现，一个业务逻辑都无法自洽，满是补丁和bug的业务逻辑，如果用软件来进行实现，你得到的只能是一个业务逻辑无法自洽、满是补丁和bug的系统。
如何能够在需求阶段就能够发现缺陷呢？

• 实例化需求——举例说明，具体一点、再具体一点
• 验收驱动开发——先说清楚这个功能/系统将来如何测试、如何验收
  纸面上都跑不通的逻辑，就不要期待它能用软件和系统跑通。
  如何能够在开发阶段就能够发现缺陷呢？
• 持续集成——尽早编译、尽早部署、尽早进行静态扫描修复问题，分支的生命周期越短越好
• 自动化测试——尽管这个功能的自动化脚本可能还没写，但最起码别影响了基础功能
  测试阶段就不说了。
  以上的阶段都失守了怎么办：如何能够在用户发现之前，我们先发现并修复缺陷？
• 自动化测试——说得都不想再说了，自动化测试其实就是尽可能地降低回归测试的成本，一遍又一遍地滚，频繁执行、早一点发现问题
• 持续交付/DevOps——上线之后的监控如果完善的话，流量的异常是能够被发现
  我们终归还是没能在用户发现之前发现问题，用户发现了缺陷，这个时候我们只有最后一个机会了：如何能够尽快让系统回复正常？
• 持续交付/DevOps——借助完善的DevOps平台和能力，尽快回滚
  如果到这里还是没守住的话，那就等待迎接用户和上层管理者的怒火燎原吧。

在交付时间的更早期发现缺陷

一方面是在软件生命周期的更早期发现问题，但也得看这个生命周期的长度，如果沿用瀑布的模型，一个需求分析的时长就有3个月，那发现问题的成本也是非常高昂的。所以——

• 短迭代的生命周期是必须的——第二点里展开过了，不再复制一遍了

4、软件开发不是高科技，而是沟通的学问

软件开发工程师挣钱更多并不是因为软件开发科技含量更高，而是因为在过去的20年中，电子商务创造出了更高的集中度、更大的利润，社交软件让信息的触达更加精准、广告更加有效。
多说一句，最近的一个只有技术还没有“正经”场景的东西是区块链，人们对它寄予厚望，但除了虚无缥缈的币圈之外，还没有产生能真正影响生产力的应用。
基于这样的认知，会发现一个事实：只要技术不是太差劲，软件产品做得好与坏，更多取决于人与人的关系：项目经理与团队的关系、产品经理与技术的关系、技术与业务、程序员与程序员的关系。

• 项目经理与团队的关系在PMP里有知识体系，各种管理的书里也有讲如何更加具备领导力，都讲得挺好但又没什么用
• 产品经理和技术的关系、技术与业务的关系本质上是一样的：是否能够更好地理解对方的领域，并且能用对方能听懂的话互相沟通，不要鸡同鸭讲

可以给的建议

首先是认知，如果你仍然认为需求做得越多越好、需求变更再努努力就能避免、软件缺陷无可避免、软件开发是了不起的高科技，那很抱歉，整个文章浪费了你宝贵的十几分钟。但你会浪费更多的时间在软件开发这个行业里。

知行合一

发现问题——解决问题——发现新的问题——解决新的问题，干成就是干成了，没干成知道再多大道理也没什么用，我还知道减肥只需要管住嘴迈开腿呢，所以——
认知，首先是认知，当你有了一个特定的认知之后，你会发现处处都是问题：

• 如何能把需求拆小？
• 如何能更理解我的用户？
• 如何能降低自动化测试的成本？
• 如何能让团队投入额外的精力来做各种自动化？
• 如何能说服我的用户在开发过程中更投入地进行反馈？
• ……
  如果进展到这一步的话，我相信寻求问题的答案就是一个人经验逐渐丰富、资历不断成长的过程。

多读书

太阳底下没有新鲜事，精益软件开发、看板方法、云原生等等，任何一个名词展开都能找到至少一本书，里面包含了从问题到方法论的全部，只读书进步太慢，不读书的话无知又无边无际，所以以认知为线索，把书里的内容为自己所用，才是效率最高的方式。