25｜节点四：架构规划之需求确认
该思维导图由 AI 生成，仅供参考
需求确认前的准备工作
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文讨论了架构规划中的需求确认过程中可能出现的问题域和执行域的冲突。作者指出，不同角色在不同语境中存在冲突，而统一语义的过程能够帮助及早暴露这些冲突，有利于架构活动的顺利进行。文章列举了架构活动中最常见的七种冲突，包括优先级冲突、定位冲突、团队和个人的冲突、边界冲突、问题域到执行域的映射关系的冲突、生存空间的冲突以及决策权的冲突。这些冲突在企业中普遍存在，需要及时解决以确保架构活动的顺利进行。文章强调了统一语义的关键作用，能够让人及早看到这些冲突，并及时解决，以避免架构活动面临不确定性。 在架构活动中，需求确认过程中可能出现的问题域和执行域的冲突是不可避免的。作者提出了解决这些冲突的建议，包括对有限资源的争夺进行明确沟通、迅速裁决生存空间的争夺、避免个人与团队之间的矛盾以及设立决策信条等方法。执行域划分是一个压力非常大的环节，需要架构师保持开放心态，充分表达建议，但也要意识到自己并没有决策权，需要尊重决策者的视角。 文章最后强调了统一语义的重要性，通过暴露团队和职能间的冲突，有助于在架构活动的早期阶段解决问题，避免项目后期出现无法挽回的困难。整个过程强调了尊重人性，从用户思维出发，先看清楚问题的重要性。文章没有涉及具体的架构方案选择，而是强调了在解决方案设计之前，要让所有参与方先坐下来，放弃一切技术执念，先在“我们要解决什么问题”和“怎么分解问题域”上达成共识。 总的来说，本文通过讨论架构规划中的需求确认过程中可能出现的问题域和执行域的冲突，强调了统一语义的重要性，以及在解决方案设计之前达成共识的重要性。文章内容丰富，为读者提供了解决架构规划中常见冲突的建议，并强调了尊重人性和用户思维的重要性。
《郭东白的架构课》，新⼈⾸单¥68
全部留言(12)
- 最新
- 精选
罗均古人云：“不为良相，愿为良医。”东白老师真是现代科技类企业的“良相良医”，所总结的技术活动中的种种问题，广泛、精确且深入人心！任何企业的任何技术活动，必然存在或多或少的问题，而老师的总结归纳，正如医书一样可以指导学生们对症下药。 听完老师的课程，让学生回忆起Peter Drucker的灵魂拷问：“Who are our customers? What are our missions?”并由此引起的三大管理活动：Tasks, Responsibilities and Practice。这三点，又刚好与老师总结的问题域、问题域与执行域的划分、执行域，一一对应。因此老师的总结，不仅可用于指导技术活动，应可适用于以科技为主导的所有大规模企业活动。 关于老师安排的第一个问题，正如“畏疾忌医”的故事一样，一开始管理层不想面对，甚至还会喷暴露问题的同事，结果必然是产品带着各类“未执行”或重大质量问题进行“交付”。然而学生觉得，更重要的是暴露问题的方法或形式很重要，毕竟良药苦口。以前跟过一位美国人老板，曾经教我如何以充足的数据，以reasonable和acceptable的描述去暴露问题，并准备好可执行的resolution proposal。结果虽然暴露问题的时间，会比自己预期的晚，总无法完全避免损失，然而自己尽力也是问心无愧。作者回复: 惭愧， 做不到你说的这个境界。 不过能帮助到你很高兴！
2022-03-2914
术子米德🤔☕️🤔☕️🤔 * 📖：需求确认。 * 🤔：每次看到这个词，我就有点想笑，不是因为我能够做好，而是每次都觉得，需求确认是件真戏假做的尴尬演出，至少在我身上经常发生。我个人比较喜欢需求挖掘，尤其喜欢把需求挖掘到，如何还能赚到未来的钱。可是确认需求的时候，经常连最基本的需求点，互相都无法达成共识。我觉得已经理解，而且做了清晰的分析，有角色、有动作、有结果，有图有阐述。可是需求方，无心细看这些分析的结果，草草过场，表面认可，实际并不在意，自然没啥共识。此后的某个时刻，忽然说需求要改变，那就变呗，变不是问题，问题在于有点忘记自己曾经的需求，以及当时的需求分析，忘记也不是问题，问题在于对需求的轻视。细想起来，需求方实际只是个需求条目的搬运工，并未对需求有认真思考，所以才无心需求分析的结果。至于需求是否真的实现满足，那就看谁测试、谁使用，等着反馈，当然最好是别反馈。这样的情况，很无厘头的样子，却是真的经历过。 * 🤔：有时候见到高人，需求分析出来的结果，跟我的迥异，但是又有忽然被点亮的感觉。虽然不明白为啥会分析如此结果。后来自己学了点通识，用经济学的成本思维，用科学里的证实和证伪思维，甚至再加点人性思维，尤其把自己代入到需求的视角，唤起同理心，居然会多出很多看待需求的视角，新鲜、独特、有见解。可是，懂你的人，相同认知的人，才会赞叹不已，否则会面临很多自负满满的评审意见，不痛不痒又不爽快的那种感觉。不知道老师是否遇到过类似的场景，自己对需求有独到的见解，却得不到认可，但是又不得不经过所谓的需求评审，如此矛盾怎么解？作者回复: “需求确认是件真戏假做的尴尬演出” 我觉得你还是要坚持做那个喜欢 **较真** 的人。 其实我自己的观察是你总是较真，最后大家也就容忍了。 但是最终你是获益的， 公司也是获益的。 2. 我是个很令人讨厌的人， 我想说的话一定要说出来。 你喜不喜欢听是你的事情。 反正我不把它堵在我自己的心里。 堵出癌症咋办尼？
2022-03-3046
spark郭老师，take away~~~做事的思维方式需要完整，缺失的思维维度必然导致局部视角。您在上节课分享，架构师也需要掌握局部视角的细节和痛点，才能保证全局思考和执行的到位~~~ 有人分享需求的逻辑，“业务需求(愿景与目标)、客用户需求(问题)、设计方案(方案)、产品需求(功能特性)”，就包括问题域和执行域~~~ 另外，我认为做减法是重点，同样的实力和业务背景，就看谁的洞察力和做减法的本事大~~~作者回复: “同样的实力和业务背景，就看谁的洞察力和做减法的本事大~~~” 非常赞同！！！
2022-03-295- Helios问题一让我想起几年前一个名校毕业生刚进华为就对华为的战略高屋建瓴的规划，然后任正非回复的大致意思是“有病看病没病辞退”； 在二十多年前（1997）还有一个清华博士写了一封《千里奔华为》，也是万言书但是谈的是以自己职位的视角来谈华为，任正非回复“一个会思考并热爱华为的人”。 前者就对应着在架构设计中找茬儿的人，允许提意见不是让你过来当老板，反而从小角度出发能提出真知灼见。所谓当我们对一个设计的提建议的时候也要考虑语境和语义。
作者回复: 不是任正非做得每件事情都是对的。 这个毕业生的建议不一定靠谱， 但是 “有病看病没病辞退” 的态度对待一个毕业生的大胆表达还是有点太自以为是了。 这样做打击的不是这个毕业生， 而且成千上万的想法。 一个企业还是要给员工足够的安全空间来自由表达的。
2022-07-14归属地：美国3 - 沈子砚这节课强调了要提前暴露问题。但也有人认为暴露组织中本来就存在的问题，其实是没事找事。一个大型的架构活动已经有很多挑战了，没必要暴露更多的问题而人为制造困难。有一次，在大规模的软件架构中，我提前暴露风险，被喷了，我不知道我错在哪里了，罗均的评论给大家指导了一个新的工作方法
作者回复: 没错， 错的是喷子
2022-04-082 
亚林提出问题比解决问题更重要。（by爱因斯坦）能提出正确的主要问题都是一门本事作者回复: 是的， 赞同赞同。
2022-07-25归属地：美国1
Iris很多时候，一个项目的所有需求都是由一个承接方，也就是开发团队去做的。如果是这样的情况，每个团队成员是不是可以看成一个承接方？作者回复: 可以的。 主要看你规划的粒度
2022-06-06
彭彭😄第一次听说统一语义和领域映射是在DDD相关的书上。 先把一个大的域，拆分成若干小的问题域。再完成问题子域到解决方案域的映射。主要思路是分而治之，降低复杂度，将一个大的问题拆分成若干小的问题，然后关注点进入到子域内部，子域也可以继续拆分，直到复杂度可以被理解或者掌控为止。其中问题域的拆分只是评经验或者直觉，并不是特别精确的划分。而问题域到解决方案域确是相对精确的划分。上面的方式是自顶向下架构设计的方法，比较适用于熟悉的，或者深耕多年成熟的领域。另一种自底向上的划分方式适用于默认领域从0-1的构件。正常架构设计是一般两种模式相结合。2022-07-052
哈德韦文中提到精度与召回，不确定是不是所有人都了解。最近学习了一下，举个例子来说明一下。假设有两个搜索系统，A 搜索出 100 篇文档，其中 40 篇是相关的；而 B 可以搜索出 400 篇，其中 80 篇是相关的。 哪个更好呢？这取决于假阳性（被返回的不相关的文档）和假阴性（未返回的相关的文档）哪个成本更高。研究人员是这样定义召回和精度的： 召回 = 返回的相关文档数目 / 相关文档总数 精度 = 返回的相关文档数目 / 返回的文档总数 （分子相同，分母不同）2023-08-15归属地：丹麦
小昭
这节又听的云里雾里了，先打个卡，后面再来复习2023-05-18归属地：上海
