问题思考脑图
🤔 问题引言
几乎所有的专业项目管理课程都会教授如何制定计划、如何执行计划、如何追赶进度、如何监管风险等等。但这一切的前提都是需要项目经理手握一张「项目进度表」，软件研发行业也会成为「甘特图」，以下是一张项目进度表的示例。但无论项目进度表是什么样的，其中总包含这样几个元素：
- 项目目标或愿景：大家可以一起使劲的理由
- 分解任务项：为了达到目标需要分解成几个可达成的子项
- 任务关系：观察任务之间是否存有依赖关系，是否可以并行
- 风险项：在整体项目中最可能出现的风险与替代方案
- 责任人：为了更加明确认责主题，同时激发个体责任心
- 时长：作为任务项所需要花费的时长与精力
- 里程碑：确认阶段目标与里程碑时间点，有时会加上度量指标
- 最优路径：通过以上约束限制，找出项目达成节点的「最佳」完成顺序
- 预算：计算任务项支出成本与预测收益，从而判断项目的财务状况
当你有了以上一张表后，项目经理随后几乎所有的时间都需要确保这张表格的「照常发生」
，但哪有一帆风顺的项目，因此才会有项目经理天天救火、心力交瘁、项目进度一再拖延、新 PDCA（Plan - Delay - Cancle -
Apologized）诞生的局面。
但这背后其实都揭示了一个问题：你的进度表中为了所谓的「数字好看」，背后叠加了多少假设？假设需求背景大家都清楚、假设需求范围不会蔓延、假设时间估算是靠谱的、假设团队没有人请假、假设监管是起效果的…
那么恭喜你，在计划之初团队做下的这些假设，在项目管理的过程中必然要保证这些假设的发生。稍有偏差，假设的计划表就会不堪一击。
而你的计划表也不过是华丽的空中楼阁，不是一份 足够抗击脆弱 的 可信赖的 交付策略
1. 项目经理管的是什么？
如果依照之前的推论，软件研发中真正的产品是「是蕴含在软件中的知识」，那么项目管理真正要管的即为「软件中的知识管理」。
由此，在知识管理的领域中，任务与进度变得不再可控。难度可以类比于「编辑管理作家写书的进度」、「画廊管理艺术家创作的进度」，知识的获取、灵感的转化变成整个过程的重点。
那么项目经理也需要将大量的时间花在，如何管理软件中的知识。借鉴知识管理领域中，可知其中有三部分：
- 知识的获取：如何可以最快速获取最准确的信息
- 知识的构建：如何可以搭建出团队容易理解的知识地图
- 知识的运用：如何可以更高效更高频的运用团队知识
与其他团队管理知识的顺序不同，BeeArt 团队更多的考虑顺序将从知识运用 - 知识构建 - 知识获取，毕竟 消费才能拉动内需。
2. 如何管理知识的运用
为了避免团队成为「数字仓鼠🐹」，陷入文档编写与收藏的谬误，感觉某个人写完一篇文档，就等于全团队学习到。
但实际上团队应该正视「知晓某事」并不是「知道某事」；「一人知晓某事」并不是「团队知晓某事」。因此，项目经理需要最先优化的是在软件开发的流程中，什么知识最应该被运用？
- 用户：你的软件的用户是谁？他们的目标是什么？痛点是什么？
- 解决方案：最初你设定的解决方案是什么？解决了用户哪些方面的问题？与自身企业、团队的目标关系是什么？
- 如何成功匹配：整个方案中你的假设是什么？什么时候去做验证？
我相信以上这些问题，在大部分软件交付的初期都被讨论梳理汇报过，不过最后都被放入了团队的「收藏夹」中。只有在新人 OnBoarding
的时候，翻出来看看，但也不会检查吸收的效果。可是，团队成员在查看文档库时，更像是将信息进行搬运（而非加工），途中没有增加任何知识。如果日常工作中再不加以运用，那这些搬运的知识将会很快被大脑清洗掉（潜意识会默认过滤掉大量无用信息，这一点很难觉察到）
因此，我们需要一种方式，在日常的软件研发过程中，不断的提醒大脑，团队的知识是什么？我们的假设是否是正确的？
2.1 知识运用 - 故事卡范式
在敏捷研发中「故事卡」正是日常软件中被高频使用的「需求载体」，更是研发与业务之间的「知识集中交换地」
由此团队重新定义了「故事卡」的生命周期与范式：
| 缩略图：需要采用用户故事三句话中的「so that 价值」作为卡片标题，同时表明 用户画像（照片）、Epic 归属（白板中 Container）、迭代号（I8）、迭代内优先级（Iteration Priority:9）、复杂度点数（8）、负责人（KW） | 详情：分为三段共同描述，由业务分析师 BA 着重阐述用户故事三句话、由业务与技术共同完成 AC 部分（业务和技术各写一版，IPM上讨论）、由用户体验设计师 UX 附设计稿或 DS 运用规则 | Logseq 知识库：由技术人员共同将故事卡中故事与领域模型对应，并完成模型展开与工序拆分（详见实践集），并将每个工序标注预计完成时间与研发工程师 |
|---|---|---|
 |
 |
 |
| Trello 中故事卡 - 缩略图 | Trello 中故事卡 - 详情 | Logseq 中故事卡 - 详情 |
2.2 管理知识运用 - 工作堆积与认知堵塞点
通过团队每日最高频接触的「故事卡」，如此可以确保团队知识的运用场景
而作为项目经理，每天着重需要管理的「时间进度」也就变更成为寻找「工作堆积与认知堵塞点」
同样的，在软件研发过程中，一张故事卡也是具有生命周期的，是由需求转化为方案、转化为验收标准、转化为研发工序，其中需要经过业务分析师、用户体验设计师、研发、测试工程师等角色。
因此每一步都需要时间，但如果一张故事卡在某一个环节 停留
过久后，花费的时间过长后，整个流程变出现了堆积点，这个堆积点会造成整个流程的瓶颈，降低吞吐率。而造成的背后很有可能就是团队的认知堵塞点。
作为项目经理可以结合每日站会上团队更新的累积流图中判断出，本迭代内哪里出现了工作堆积，需要如何处理与应对。
- 需求侧出现堆积：需要引入用户调研、需要引入产品路演从而消除业务对产品的不确定…
- 研发侧出现堆积：需要判断是否是故事卡拆分过大、还是研发对需求上下文不理解导致频繁沟通与返工…
- 测试侧出现堆积：需要判断是否测试人手不足、还是自动化测试过少…
3. 如何管理知识的构建
在知识的构建部分需要先理解什么是「认知负荷」，谈到认知负荷，我们可以简单地将其理解为任何一个人在给定的时间内大脑中所能保存的信息量是有上限的。对于任何一个团队来说，简单地将所有团队成员的认知能力累加起来即可。
结合 Cynefin Framework 中，可以简单的理解为团队整体对某个知识的认知「从
Complex 到 Complicated 到 Obvious」的 总攀登阶梯数。
但是现在，当项目经理给一个团队分配职责或者软件构建的时候，我们几乎不会考虑认知负荷。可能是因为认知水平与负荷都难以量化，又或者本身就希望团队能够不假思索地完成被交代的工作。
如果不考虑认知负荷，团队会做过多大量疲于奔命的工作，从而导致了计划延迟、质量等问题。团队中无意超出认知负荷的实例有：
- 提出不可能的任务：让现有研发工程师 3个月内复制 ChatGPT
- 过分自治：研发工程师身兼多个系统与平台的研发
- 阶段目标过多：阶段内的故事卡横跨多个领域与目标用户
因此，我们鼓励项目经理在思考团队任务时，去限制他们的认知负荷。将认知负荷明确作为团队规模、分配职责和建立团队边界的有力工具。
3.1 认知负荷的种类
在 1988年，心理学家 John Sweller 将认知负荷定义为「工作记忆中使用的脑力劳动总量」。Sweller 定义了三种不同的认知负荷：
- 内在认知负荷，与问题领域的基本任务相关，比如：Java 类的结构是什么样的？TDD
知识本身。就像「冰山的自重」，在我们学习任何知识的时候，都一定会带来认知负荷，属于中性，谈不上好坏- 外在认知负荷，与任务处理的环境相关，比如：我要如何重新部署这个组建？我要如何配置这个服务？类似于
「北极熊带来的额外压力」，它会加重本来就不轻的认知负荷，使得学习更为困难，是「坏」的负荷 - 相关认知负荷，与那些需要格外关注学习和高性能方面的任务相关，比如：这个服务是如何与其他服务进行交互的？它是「海水的浮力」，它会减轻学习过程中的认知负荷，是「好」的负荷
- 外在认知负荷，与任务处理的环境相关，比如：我要如何重新部署这个组建？我要如何配置这个服务？类似于
有了这幅图作为隐喻，对认知负荷的三个种类的理解就应该比较容易了！
- 内在认知负荷，对于特定的学习者（所掌握的先进知识）、特定的学习材料（难度），内在认知负荷是确定的。例如：在软件研发中，你的用户是谁，你的软件是属于什么行业的，所包含了哪些知识？
- 外在认知负荷
，是由信息的组织方式和呈现方式带来的，信息的组织方式。在日常任务重应是最为重视的，同样的内容，用不同的信息呈现方式，知识吸收效果（以及认知负荷）是不同的。例如：同样是表述场景与功能之间关系，功能列表与用户故事地图就是不同的呈现方式 - 相关认知负荷，这是唯一能够产生「浮力」的要素，因此对于知识传递起到 关键性作用
。在项目中好的知识管理，应该将知识分类呈现，并建立一定的关联关系。例如：在拆分工序的时候引入模型展开，不仅可以降低拆分工序的难度，同时也加深对模型的认知与理解。
3.2 管理知识构建 - 团队中三张地图
在软件研发的过程中，作为项目经理有三张地图可以帮助团队降低知识的「外在认知负荷」，将产品中有效的信息串联起来
| 需求地图：用户故事地图，可以关联 用户目标 与 产品的需求模块，讲清楚每个需求存在的价值 | 研发地图：领域模型图，可以关联 产品需求模块 与 软件实现架构，保证软件实现与业务逻辑之间相匹配 | 管理地图：估点与速率偏差统计，可以将 实际损耗人天 与 估算进行偏差统计，从而找到团队认知最薄弱的模块，迭代中通过学习时间集中补充知识 |
|---|---|---|
 |
 |
 |
| 用户故事地图 | 领域模型图 | 估点与速率偏差统计 |
而提升「相关认知负荷」就需要靠外界工具帮忙，BeeArt 团队采用的是白板 + Logseq 的双链方式。
4. 如何管理知识的获取
根据消费决定需求的方式，软件研发的团队主要需要获取以下 5类知识：
- 业务知识：对市场、对行业、对趋势、对竞品的理解
- 用户知识：对目标用户、对使用场景的理解
- 商业化知识：对产品自身竞争力、对企业平台战略的理解
- 技术知识：对先进技术的尝试、对技术可反哺业务的创新
- 团队能力：对团队认知现状的了解
作为项目经理，不仅需要让团队有主动自发获取知识的 源动力，更需要有让团队有互相交流被动获取的 安全空间
但我们不得不承认，让团队在工作中主动承认自己需要学习，对每个人都是需要勇气的。
但项目经理也必须承认，团队的学习时间是「必要的浪费」，因为如果不学习猜测无法变成事实，决策无法可靠，团队的错误也会反复发生
4.1 自发获取专业知识
团队成员主动自发的获取知识一方面是方式方法，但更多的需要团队成员的心态调整。
需要从「专家心态」，调整成为空杯的「初学者心态」。团队成员需要承认自己的猜测与假设，而不是一味的「藏马脚」
在 BeeArt 181 团队组建第一天，团队原则中边有两条与主动学习有关：
- BA 是一定帽子，全员要当
BA。背后的原因是我们需要用于承认产品研发的高风险性与不确定性，我们不能指望产品经理或业务分析师一人就可以掌握全部的业务知识，就可以让产品走向成功。因此思考业务与用户知识，因为是全团队的行为，包括研发与测试，不分角色 - 对团队来说足够好的东西，对你来说永远都不够好。要从错误中学习，要互相学习。背后的原因是无论业务与技术需要不断追求「卓越」与「不确定」，不能「受困于」足够好的现状
因此我们的实践在基础的敏捷研发工程中，多加了
- OnBoarding 书单：团队具有固定书单，书单中有与业务密切相关的图书，读完后对全团队演讲，团队认可后才可开始工作
- 产品路演 Roadshow：区别于迭代 Showcase，定期与目标用户沟通，讲述自己的猜测并获得用户的反馈与验证
- 反串讲：业务进行模型实例化展开并向技术讲解，技术拆分故事卡的 AC 并向业务求证
4.2 被动获取关联知识
被动获取知识需要团队有安全开放的学习环境
首先需要团队领导者承认学习的必要性，而非只看时间进度的机械式管理
因此，在BeeArt 181 中，我们有以下「时间的浪费」，来保证团队认知的整体提升
- 每天站会后占用工作时间 30分钟，研发进行 Rotation 轮转卡，保证自己可以将手中故事卡的业务讲解清楚，并传递给下一个研发工程师
- 每天中午占用工作时间 30分钟，每人都会轮流进行 Session 分享，但要求必须与团队知识相关，可以是先进技术，也可以是业务商业知识
- 每周五下午占用工作时间 1小时，进行实践总结会，总结每周高效的工作方法与实践，并思考可以解决什么项目问题
- 每个迭代 IPM 后，研发需要 0.5 - 1天的时间分析本迭代所有故事卡，并集中进行模型展开与工序拆分，不着急开卡进入写代码环节
- 每个研发工程师在开始一个工序超过 40分钟后还未提交，需要在团队内部举手，提出自己是否遇到困难，而团队中的其他小伙伴是否可以
pair 帮忙 - 每个新人需要完成人传人 OnBoarding，近 1个月，完全掌握业务上下文与技术模型后，才成为正式成员，编写生产代码
- 每人轮流成为 IM（迭代经理），理解迭代交付风险与认知提升的管理办法
以上就是 BeeArt 所提倡的根据提升团队认知，从而进行的项目管理
因为知识领域下的项目管理需要更科学的管理手段与方法，如果只是盯流程、盯时间、盯责任人、开会催进度，将会严重的伤害团队工作意愿
毕竟，虽然人人都可以成为项目经理，但也有好坏之分！
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 350394277@qq.com
