26｜知识过程下的团队管理

May 6, 2024

26｜知识过程下的团队管理-徐昊 · AI时代的软件工程-极客时间



下载APP





关闭

渠道合作

推荐作者

26｜知识过程下的团队管理

徐昊 · 徐昊 · AI时代的软件工程

课程介绍



讲述：徐昊

时长07:36大小6.96M



你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
通过前面的学习，我们了解了如何使用大语言模型（Large Language Model，LLM）辅助软件开发，以及如何有效地提取软件开发中的关键知识——测试工序。从今天开始，我们来学习如何通过 LLM 辅助构建团队。
认知分歧在第一部分知识工程的综述中，我们介绍了认知行为模式，并反复利用认知行为模式，解释了知识的学习、应用与传递。然而之前我们对于认知行为模式的应用，主要集中在个人视角。如果将团队看作一个整体，那么我们同样可以使用认知行为模式来理解团队行为。
而一旦站在团队视角，我们会面临一个非常重要的问题，那就是认知分歧（Cognitive Diffusion）。也就是对于同一个问题，团队中不同的成员，可能会处在完全不同的认知模式。
比如，对于如何在项目中完成用户故事指定的功能，在项目上完全胜任的成员可能处在庞杂的认知模式下（Complicated），他们完成任务的行为是：感知（理解用户故事的上下文，以及验收条件）- 分析（按照测试工序指引，分解任务）- 响应（依据任务列表逐步完成工作）。
项目上不完全胜任的成员可能处于复杂的认知模式下（Complex），他们完成任务的行为是：探测（尝试 spike 一下故事卡中某些不清楚的地方）- 感知（按照得到的结果，重新理解要如何完成整张卡片）- 响应（逐步试错，完成功能）。
而刚毕业没有什么编程经验的成员，可能完全就是混乱模式了。他们甚至不会仔细辨别到底要做什么功能，就被巨大的恐慌驱动，冲过去写代码了。那么带来的自然是大量的返工和修改。
除了不同的经验水平之外，认知分歧也会存在于不同的角色中。比如在业务分析师和开发之间，开发与测试之间都会存在认知分歧。认知分歧是无法消除的。这源于成员的不同经验水平、专业背景、个人偏好或是对问题的理解方式等等诸多原因。
认知分歧当然存在有益的一面，比如它能够带来多样的思考方式和解决方案。特别是在需要创新的领域中，趋同的认知行为也可能会让团队陷入僵局。但是，在更多的情况下，认知分歧会带来效率和质量上的严重损失。这个我们在前面的课程里，已经讲解过了。
那么对于软件开发而言，是否存在一个理想的认知行为呢？或者说，我们要怎么判断一个团队处于良好的认知行为模式下，而另外的一些团队则存在较大的问题呢？
理想的认知行为模式在我看来，软件开发中的理想认知模式是存在的。下面是我在 20 年总结的理想的认知行为模式：
绝大部分活动处于有序的状态（清晰或庞杂），严格控制无序状态的成本。
尽可能地减少混乱的情况；
存在持续提升认知的手段；
在编写生产代码（Production Code）时，应该处于清晰认知模式；
检查软件的功能性质量时，应该处于清晰模式，极少情况处于庞杂模式；
诊断问题时，应该处在有序的认知模式下（清晰或庞杂），极少情况处于复杂模式；
按照大家现在对于认知行为模式的认识，这里的很多条要求都很容易理解。
我们挑几个重要的展开讲一讲。
首先是第一条，绝大部分活动处于有序的状态（清晰或庞杂），严格控制无序状态的成本。
这里需要强调的一个概念就是有序和无序，我们将认知行为模式分为有序——清晰和庞杂，以及无序——复杂和混沌两类。比较这两类认知行为模式就会发现，有序的行为模式是感知（sense）在先，而无序的行为模式则是行动在先，感知在后。对应到复杂的行为模式就是探测 - 感知，对应到混沌就是行为 - 感知。
这意味着什么呢？这意味着当我们处于有序的认知行为模式时，我们对于要解决的问题是有定义的，可能对于解决方案不太了解。而处于无序的认知行为时，我们甚至不清楚要解决的问题是什么。
举个例子，还是以编码为例，如果拿到的用户故事，存在明确的验收条件，且进行编码的人，对于架构知识和测试策略有充分的了解。那么他们在编写测试代码的时候，认知行为模式就可能是：感知（阅读用户故事的验收条件）—— 分析（通过测试工序，将验收条件分解）—— 响应（按照分解的结果编写测试）。这时，他们就处在有序的认知行为当中。
而如果进行编码的人，缺乏架构知识和对于测试策略的理解，那么他们就可能会进入复杂的认知模式：探测（随便编写一个功能测试）—— 感知（是否能有效地覆盖要编写的组件）—— 响应（编写测试）。
两者相对比，显然有序的认知模式可以带来更好的质量和效率。所以我们强调的第一点就是，在进入软件开发后，绝大部分的活动要处于有序的状态。只有有序才是能够管理的出发点。
那么符合这个条件的最佳实践有哪些呢？比如，正确实施的迭代交付，就完全符合这个要求。在迭代交付中，每一个迭代被看作是一个固定的时间窗（time box）。所有进入迭代的需求，需要在迭代开始前明确验收条件。也就是，要解决的问题进入迭代前，需要给出范围和验收的定义（感知 sense）。
需要注意的是，在迭代过程中，需求是不允许修改的，从而保证问题的定义在迭代过程中不变。这就有效地保证了，开发实践都可以处在有序的认知模式。而忽略了这一点，就无法保证是这样的情况了。所以站在认知行为的角度，很容易就可以发现，采纳的实践是否是走样的。
再比如，我们前面讲过的测试工序，也是一样的道理。对于如何使用架构和测试策略给出了明确的定义，从而减少了探测行为和对于架构的重新定义。前面对这个实践已经讲了很多了，这里不再重复。
那为什么要严格控制无序状态的成本呢？这是因为，当我们处于无序的活动时，不仅仅成本很高，而且时间不可控。仔细想一想无序的两个行为模式，无论是复杂还是混沌，实际上都缺乏对于待解决问题的理解。本质上讲，我们就是不会，不能胜任，我们就是在学习。学就要分学得会和学不会两种情况了。这意味着，我们可能无法完成要解决的问题。
那么站在管理的角度上来看，任何无序的认知活动，实际都是项目风险，不光是质量风险，更是进度风险。于是对于这类活动最常见的管理方式，就是卡住时间——给予一定的时间，如果无法解决，那么就要立即止损。
止损的方式包括换人、寻找外援等等。我想大家都有过看起来简单，实际是大坑，最后造成项目严重延期的经历。这实际上告诉我们，当我们处在无序认知的时候，不要相信自己的判断，理想的做法就是及时止损。
比如，敏捷社区中有一个常用实践叫 spike。它只指当开发人员碰到对于解决方案不清楚的情况时，停下手头的工作，给定一个探索时间。开始进入 spike 的时候，需要通知整个团队，告知存在一个瓶颈。而一旦超过规定的时间限制，需要马上停止并告知团队，这就是及时止损的做法。
我们再看另一条，检查软件的功能性质量时，应该处于清晰模式，极少情况处于庞杂模式。
对比清晰模式和庞杂模式的区别，清晰模式的关键是分类（categorize），庞杂模式的关键是分析（analyze）。那么这句是什么意思呢？其实是说我们检查软件质量时，主要应该依赖自动化测试，只有在极少的情况下，才需要手动测试。
当存在自动化测试时，我们对于质量的判断，会简化为测试是否全部通过（绿），还是有测试失败（红）。这时候，我们采用的就是分类行为（红还是绿）。而如果需要引入手工测试，我们就要进一步关心，要如何执行测试的过程，以及测试的结果是对是错。
为什么我们对于功能性质量的检测有这么高的要求呢？还是因为任何对于代码的修改，都需要回归测试。当质量检测处于低效的认知模式时，代码修改也会处于低效的认知模式。
另一个类似的是诊断问题时，应该处在有序的认知模式下（清晰或庞杂），极少情况处于复杂模式。
有序认知的问题诊断就是通过测试发现和定位问题。处于清晰模式的问题定位，就是通过失败的自动化测试，发现存在问题的代码。而处于庞杂的问题定位，是指根据出现的 bug，构造一个新的自动化测试来重现这个问题。测试所覆盖的范围，就是问题出现的范围，可以通过逐步分解测试范围的办法，准确定位问题出现的位置。而复杂模式的问题定位就是 debug。所以，简单来说就是多写测试，少做 debug。
小结认知行为模式这个框架贯穿了我们的整个课程，放到团队里也是一样的。
不过切换到团队视角的时候，我们要面对的重要问题就是认知分歧。前面我也强调过认知行为模式并不是对于问题的划分，而是要从行为出发来分析，结合认知分歧的讨论，我想你应该对这点理解得更深入了。
既然认知分歧无法消除，那如何判断一个团队处于良好的认知行为模式，还是存在较大的问题呢？这里我给出了一个自己总结的理想模式。
这个理想的认知模式中的每一项，都可能在团队中出现认知分歧。因此我们需要“存在持续提升认知的手段”，这将是我们下节课讨论的问题。
思考题你觉得有哪些可以持续提升认知的手段？
欢迎在留言区分享你的想法，我会让编辑置顶一些优质回答供大家学习讨论。

1. 认知分歧是团队管理中的重要问题，不同成员可能处于不同的认知模式，导致效率和质量上的损失。 2. 软件开发团队需要判断是否处于良好的认知行为模式下，以及如何解决团队中存在的认知分歧问题。 3. 理想的认知行为模式包括绝大部分活动处于有序的状态，严格控制无序状态的成本，以及在编写生产代码和检查软件的功能性质量时应该处于清晰模式。 These are the key points from the article.

分享给需要的人，Ta购买本课程，你将得29元

生成海报并分享

2024-05-06

赞 2

提建议

术子米德｜边干边学：如何开启LLM探索之旅

27｜围绕测试工序的认知对齐

 写留言

全部留言(9)

最新
精选

奇小易
2024-05-07 来自湖北
tdd经典学派是一种复杂认知模式？通过红绿重构循环来提升认知，在这个过程中获得了更加清晰的架构，在后续新需求加入后，能够处于庞杂模式和清晰模式。
作者回复: 对的伦敦学派一开始就是庞杂
共 2 条评论
2
术子米德
2024-05-06 来自浙江
🤔☕️🤔☕️🤔 【Q】哪些可以持续提升认知的手段？【A】定投式学习，每年给自己划拨一笔钱，假设年薪10W，拿出1%来定投自己的学习，那就有1K钱可以买课，再稍微加点就可以买个VIP年卡。只要课程的标题，稍微有点兴趣，就可以点进去听听看。大概率会发现，就这么个知识点，至于要写到这么大的篇幅嘛？然后回头又会发现，原来这么个小地方，还是有这么多细节可以思考和探讨。接触越多，越容易发现自己之前做事情还是太糙，想问题还是太局限，谦卑感自然会来，也更愿意接触各种有的没得课程与分享。听得多见得多，认知的基础在持续打造和积累。当真问题来到面前，拥抱它、分析它、解决它、反思它，认知才有真提高。 — by 术子米德@2024年5月6日
展开
3
6点无痛早起学习的和...
2024-05-09 来自北京
尝试再次理解：“前面我也强调过认知行为模式并不是对于问题的划分，而是要从行为出发来分析” 认知行为模式是一种我们面对任何事，当前处于 xx 状态，基于 xx 状态采用了不同的认知行为模式去对 xx 事做不同的行为处理。
2
范飞扬
2024-05-07 来自广东
原文 ==== 有序认知的问题诊断就是通过测试发现和定位问题。处于清晰模式的问题定位，就是通过失败的自动化测试，发现存在问题的代码。而处于庞杂的问题定位，是指根据出现的 bug，构造一个新的自动化测试来重现这个问题。勘误 ==== 这里是笔误把，处于清晰模式的应该是“问题发现”，而不是“问题定位”吧。两个理由：第一、原文后面就写着“发现存在问题的代码”。第二、不然的话，这段话的逻辑就有问题：使用自动化测试的“问题定位”，又处于清晰，又处于庞杂。那怎么区分？
展开
2
Geek_692b91
2024-06-24 来自湖北
对于以前的困惑，有了更清晰的分类和认知：实际上不止是软件工程，大部分项目的管理，都应该给出时间做探索，及时评估。并基于绝大多数分解的模块都是有序的才开始行动。否则就都是坑。
1
6点无痛早起学习的和...
2024-05-09 来自北京
持续提升认知：每次做完一个需求复盘，复盘哪些是出现了问题，后面可以再次迭代优化的。但是实际上要做到正确实施的迭代交付，又有多少人、团队做到呢？反正我们团队是没有做到，每次在技术方案评审时候都会留一大堆 ToDo 确认，开发过程中都还有一堆需要明确的事。这种情况也让我很难受，可惜我不是 leader，没有直接权利止损。
1
aoe
2024-05-06 来自浙江
1. 学习一下「知识管理」的相关知识，如彼得·德鲁克的《管理》 2. 遇到问题从多个角度思考、分离关注点：问题的最简单定义、最简单的解决方案、借助 TDD 中的正常、异常、默认路径思考不同场景；不同层面：业务、技术架构、代码层、数据存储、模块划分、接口设计、部署、运维等 3. 学习自己感兴趣的专业知识，扩大「清晰」或「庞杂」的覆盖范围 4. 借助 AI 分析问题，缩短「探测」、「感知」、「spike」的时间 5. 尽量将问题有序化，降低认知负载，提高认知效率 6. 多关注、参与 8X 老师的互动，少走弯路
展开
1
kenan
2024-05-06 来自北京
徐老师，可以详细展开说说有哪些提升认知手段的方法。
1
术子米德
2024-05-06 来自浙江
🤔☕️🤔☕️🤔 【R】认知分歧（Cognitive Diffusion）：相同问题、不同成员、不同的认知模式，存在且无法消除。老兵 ~ 庞杂，新手 ~ 复杂，刚入行 ~ 混乱。有序状态 = 清晰/庞杂 = 感知在先。无序状态 = 复杂/混沌 = 行为在先。【.I.】面对相同的问题，你听我说，会带来下一句话，依然是你听我说；反过来，你来说说看，会带来下一句话，你说得这个地方，能否再说仔细说一下。最容易破功的地方是细节，让对方自己发现待有问题的细节点，更容易带入到更加平和理性的交往场域。【.I.】认知分歧，是否跟区别对待一样，只要是有选择，必须要做区别，只要有视角和立场，就必须存在分歧。视角要多，才能看到和思考更多方面，从而发现暴露出更多问题，立场要明确，公司利益、团队收益、个人好处的比例要做个估算，即使不公开，那也得保持稳定和平衡，表现出来像个正常合理的人。【Q】不可言说的知识，在认知分歧里，以怎样的形式存在，并左右着分歧的发生？另：本节课程与大模型的关系在哪里体现？ — by 术子米德@2024年5月6日
展开
1

