这城市已摊开她孤独的地图 我怎么能找到你等我的地方
《模范情书》；词：高晓松，曲：高晓松，唱：老狼；1996
前些年，互联网产品经理圈子流行这样的口号“我们只做最重要的需求”、“砍掉80%的功能，专注于剩下的20%”。哇，这个道理真棒！那怎么判断哪条需求最重要？砍掉哪80%？ 没有愿景的支持，这些将沦为空话，愿景就是需求排序的主要依据。
以一个目标系统为研究对象，其愿景（Vision）的定义是：
从目标组织负责人的视角看，目标系统最应该给目标组织带来的改进。
要理解好这个定义并不容易，我们从头来理清一些概念。
2.1 系统
2.1.1 “系统”的历史
关于“系统”的研究，在计算机诞生之前就已经有了。
Arthur D. Hall在1962所著的“A Methodology for Systems Engineering”一书中提到，贝尔实验室从1940年代开始使用“Systems Engineering（系统工程）”一词，见图2-1。
图2-1 贝尔实验室和系统工程，摘自A Methodology for Systems Engineering，Arthur D. Hall，1962
Arthur D. Hall的书还出现了object、attribute、relationship等词，如图2-2。这似乎在说面向对象软件开发，但实际上当时软件开发中的“面向对象”还没有诞生。仔细看文中的atom、star等词，可以知道此处说的“系统”并非我们现在当作缺省选项的信息系统，而是广义的“系统——对外能够提供某些服务，内部由若干部件组成的东西，从整个宇宙到一家企业、一个软件系统甚至一个细胞，都可以称为“系统”。
图2-2 Arthur D. Hall书中的“面向对象”
★“面向对象编程（object-oriented programming）”的说法由Alan Kay在1967年首先使用（www.purl.org/stefan_ram/…
2.1.2 系统和容器
本书第1章在讲到UML和SysML在建模中的区别时，谈到了处理信息的系统以及处理物质、能量的系统的区别。
信息系统接收输入的信息，使用其内部所封装的逻辑计算得到输出的信息。本书研究的是信息系统，因此把除了信息系统之外的其他系统，统称非信息系统。非人生命体（从大猩猩到病毒）以及机械（从老式的汽车到算盘）都归入非信息系统，不再细究其分类。
根据以上内容，系统初步分类如图2-3。
图2-3 系统的初步分类
★虽然本书到第8章才开始讲解类图的建模，但第2到7章也会用类图来表达概念以及概念之间的关系，目的不是要建模类图，而是帮助理解。如果读者之前没有类图的基本知识，可先阅读本书第8章或其他UML书籍中的相关章节。其他UML书籍推荐《UML和模式应用》（Larman）或《UML精粹》（Fowler）。
根据所驻留的位置，信息系统又可以分为驻留人脑的信息系统（简称人脑系统）以及驻留计算机的信息系统（简称软件系统）。
此处的“计算机”是广义的，是支撑软件系统的基础设施的统称，而不单指某一台计算机的硬件。即使在单机时代，像“浑元太极学员管理系统”这样的软件也已经离计算机硬件有一定距离，更不用说现在的云计算和虚拟化了。
★选择用“软件系统”这个词和“人脑系统”对应，是一个折衷的选择。和“（驻留在）人脑（的）系统”对应的，最直接是“（驻留在）电脑（的）系统”。如果觉得“电脑”港台味浓或者不能用在学术场合，可以改为“（驻留在）计算机（的）系统”，但“计算机系统”一直以来被认为指计算机本身——类似于《深入理解计算机系统（CSAPP）》所讲解的内容。如果不使用“人脑系统”这个称呼，可能不会有这些问题，但目前先这样使用，特此说明。
图2-4表达了进一步的分类。
图2-4 系统根据驻留位置进一步分类
其实，像图2-4这样进一步泛化意义并不大，我们更在意的是系统的能力而不是驻留位置。同样能力的信息系统可以驻留在人脑中，也可以驻留在计算机中，人脑中的信息系统可以复刻到计算机，计算机中的信息系统也可以复刻到人脑。哪一个系统能力强，我们就用哪一个。
“人脑”和“计算机”可以看作容器类型，如图2-5。
图2-5 把人脑和计算机看作容器类型
把人脑看作容器之后，人担任的角色或职位就可以看作驻留在人脑中的系统。例如，马宝国是一名.NET程序员，人称阿宝，同时也是一名浑元太极教练，人称马老师，这可以看作马宝国这个人脑中安装了“阿宝：.NET程序员”和“马老师：浑元太极教练”两个系统。
同样，我们把计算机看作容器，上面可以驻留很多软件系统。例如，马宝国所使用的计算机安装了“Visual Studio 2022”和“浑元太极学员管理系统”。
我们把“时间”想象成运行在驻留在上帝中的信息系统，至于它是人脑系统还是软件系统，就要看我们把上帝看作是人还是计算机了。“时间”不停地向其他人脑系统或软件系统发送时间信号，这些系统收到时间信号后，可能会做一些事情。从物理学的角度，这个想象是有问题的，但对于本书的内容来说，这个想象够用了。
这里顺便谈一下面向对象初学者的一个常见错误（包括不久前刚批评的一个领域驱动设计创新“宏论”）。例如，研究一个烹调软件系统，这个系统里面有哪些类呢？有的人会认为系统里有一个“厨师”类，封装了烹调的逻辑。他这样想的理由是，如果没有这样的烹调软件系统，烹调的逻辑是放在厨师的人脑里。
根据上面的剖析，厨师对应的这个人只是一个容器。这个人之所以会烹调，不是因为他是人（我也是人，我就不会烹调），而是因为他的人脑里安装了“厨师”系统，这个“厨师”系统和以计算机为容器的“烹调软件”是对等的。
输入一个信息“宫保鸡丁”，人脑中的“厨师”系统为什么能想到一个烹调的流程，然后按照流程指挥他的手脚以及各种设备烹调？回答“因为系统里有一个厨师类”、“因为他是厨师”虽然很有投资少、见效快、产量高的领域驱动设计风味，却是没有意义的，有意义的回答是“因为系统（即厨师）知道菜品-制作步骤-食材之间的关系”。
同理，输入一个信息“宫保鸡丁”，计算机上的“烹调软件”系统为什么能输出一个烹调的流程，甚至能按照流程指挥电子烹调设备来烹调？回答“因为系统里有一个厨师类（烹调软件类）”也是没有意义的。有意义的回答是“因为系统（即厨师）知道菜品-制作步骤-食材之间的关系”。
实际上，人脑中的“厨师”系统中可以没有“厨师”类。厨师只要记得菜品-制作步骤-食材，忘了自己姓甚名谁并不妨碍烹调。同理，“烹调软件”也可以不需要厨师类，因为它不记住厨师的信息，不影响它输出烹调的流程。
注意：
（1）是“可以没有”。如果有需要，“厨师”或“烹调软件”当然可以记住厨师以及他和其他几个概念之间的关系。
（2）注意区分“厨师”和“（供）厨师（使用的）界面”。
第8章还会探讨这些问题。
2.1.3 系统和系统规格
由于本书只深入讨论信息系统相关的建模，因此从以下内容开始，我们说到信息系统时只说“系统”，这样可以在称呼上减少一半字数。也许后续讨论的内容其中一部分也适用于非信息系统，但本书就不加以鉴别了。
目前为止，我们对“系统”的定义其实是模糊的。
如果有两名.NET程序员马宝国和张雪风，他们的电脑都安装了Visual Studio 2022，这到底算几个系统？如果认为是多个系统，那就会出现多个“系统”对象属性值完全相同的情况。例如，很多系统的名称都叫“Visual Studio 2022”，其厂商都是“Microsoft”（如果关注这些属性的话）。
因此，需要区分“系统规格”和“系统”。我们把“Visual Studio 2022”看作一个“系统规格”，某个人脑或计算机容器中安装的“Visual Studio 2022”是一个“系统”。添加上“系统规格”后，类图如2-6。
图2-6 系统和系统规格
用上面的马宝国、张雪风数据实例化图2-6，得到的对象图如图2-7。
图2-7 对象图
如果更严谨地追问，上面的模型还是存在模糊。
我们把“.NET程序员”和“Visual Studio 2022”看作是对等的，但马宝国后面可能会使用“Visual Studio 2026”，或者改用另一个厂商出品的.NET集成开发环境“Rider”。那么，“.NET程序员”最合适的对应应该是“Visual Studio 2022”、“Visual Studio”还是“.NET集成开发环境”？
这个模糊的根源可能是：我们比较清楚 “Visual Studio”和“Rider”的差别、“Visual Studio 2022”和“Visual Studio 2026”的差别以及“Visual Studio 2022社区版”和“Visual Studio 2022专业版”的差别，但是不清楚“.NET程序员”之间的差别。
这个问题我们暂时搁置，以上所提炼的概念对于本书的建模够用了。
后续的建模过程中，我们在研究系统时会有意忽略容器。我们只要知道有两个人脑系统“.NET程序员”和“浑元太极教练”就够了，它们是不是驻留在同一个人脑中，或者说这两个岗位（角色）是不是指向同一个人，是无所谓的。软件系统也是如此。
所以，在描述系统之间的协作时，我们可能会像图2-8这样建模：
图2-8 “.NET程序员”和“Visual Studio 2022”的协作
“.NET程序员”和“Visual Studio 2022”安装在容器（人脑或计算机）中，这两个系统事实上并不直接接触。如图2-8左侧的场景，两者的接触点是人的手指和键盘。人的大脑指挥手指去敲击键盘，键位的变化被捕获并翻译成相应键的编码……但这些都属于容器相关的行为，图2-8右侧的序列图不用表达。
容器类型也不会经常被提到，因为从系统规格的名称就可以判断，例如，“.NET程序员”是人脑系统，“Visual Studio 2022”是软件系统。
2.2 组织
2.2.1 组织和组织规格
和系统一样，我们区分“组织规格”和“组织”。
例如，“县区教育局”是组织规格，“天火市稻积区教育局”是该组织规格的一个组织；“企业人力资源部”是组织规格，“大米公司人力资源部”是该组织规格的一个组织。
一个组织规格由若干系统规格组成，其中至少有一个系统规格是人脑系统（可以只有一个）。也就是说，如果没有人，就算堆满了机器人，都不算我们这里说的组织。
可以给“组织规格”加约束来体现这个规则：
系统规格s->exists(s | s.容器类型 = 容器类型::人脑)
用类图表达如图2-9：
图2-9 组织和组织规格
从组织价值的视角看，当前组织里面的系统，有的是合适的，有的是应该更换的。更换人脑系统，就是裁员和招聘，更换软件系统，就是……大家熟悉的场景。组织里面还有非信息系统，也要更换，但这部分本书就不涉及了。
2.2.2 组织规格的分类
可以对组织规格做一些分类，像图2-10这样用泛化关系表达：
图2-10 泛化关系表达组织规格分类，空间有限，只表达一部分
在图2-10的子类中，有一个“个人组织”。我们把“人以群分”视角下的个人看作一个组织，该组织的部件包括一个人脑系统和若干非人系统。
例如，“程序员”可以看作一个个人组织规格，该组织规格的部件包括一个“程序员”人脑系统规格，还有“编码工具”、“UML建模工具”、“版本控制工具”、“AI工具”等非人系统规格，如图2-11所示。
图2-11 程序员个人组织和程序员人脑系统
这个地方的阐述和以前的《软件方法》版本有了根本的不同。以前的《软件方法》版本把“人群”和“机构”看作对等，可以说是《软件方法》方法学的一个大缺陷。漏了“机构群”这个抽象级别无法对应，同时，生硬地把“人”看作“人群”中的业务工人，也不合理。
这个版本的阐述通过把个人及其所利用的其他工具看作是一个“个人组织”，应该补上了这个漏洞。法律上也有类似的做法，通过“法人”的概念，把自然人和机构拉平，成为对等的民事主体。
注意区分个人组织和只有一个人的机构。有的部门在某个时间点只有一名人类成员，甚至有的企业在某个时间点只有一名人类成员，例如暂时没有另外增加雇员的“一人有限公司”或“个体工商户”，但这样的组织并非人群视角下的“个人组织”。
图2-10所示子类的上面和下面还可以加泛化层次。
往上走，企业、党政军单位、事业单位（以及社会团体、民办非企业单位）等，可以泛化出“正式组织”，它们都有“信用码”属性；部门、团队、家庭、人群视角的个人等可以泛化出“非正式组织”。
往下走，“企业”、“党政军单位”等等，下面还可以分为更细的子类。
泛化的用处是体现行为的变化。本书无意探讨不同子类的组织规格在行为上有什么不同，所以我们把泛化结构取消，用“组织类型”代替，如图2-12:
图2-12 用组织类型代替组织的泛化结构
2.2.3 开发组织和目标组织
在图2-10和2-12中，“组织”和“系统”之间只有一个关联，所以我们没有给关联或关联端的角色命名。如果要命名，应该如图2-13中的某一个：
图2-13 给图2-10和2-12中“组织”和“系统”的关联添加细节
除了“系统正在担任组织的部件”之外，系统（或系统规格）和组织可能还有其他关系。
山东枣庄有一家“武德物业”，总经理是房竹韧。“武德物业”服务的楼盘有“中原裕府花园”、“拉斐公馆”等。“武德物业”目前使用 “银蝶物业管理系统”来协助各项工作。“银蝶物业管理系统”由“银蝶软件”开发。
软件公司“浑元科技”的总经理马宝国看到了商机。他认为，类似“武德物业”的组织目前还有很多可以通过信息化来改进的地方，这些组织中，以“武德物业”最为典型。
于是，他想要做一个“以和为贵物业管理系统”，取代“银蝶物业管理系统”为“武德物业”服务。“浑元科技”有开发团队，但资金不足，马宝国拉来了“五连鞭资本”加入。
从上述内容看，系统（或系统规格）和组织有以下关系：
图2-14 组织和系统的更多关系
用刚才举例的内容实例化图2-14，得到图2-15的对象图：
图2-15 实例化图2-14得到的对象图
图2-15中，有两个系统规格的实例名称同为“总经理”，这两个不是同一个系统规格。一个对应武德物业总经理的职位，一个对应浑元科技总经理的职位。
有了以上的建模作为铺垫，我们可以定义以下概念：
（1）开发组织和开发组织负责人
负责构思和生产某个系统规格的组织，称为该系统规格的开发组织；该组织的负责人就是开发组织负责人。
我们不进一步区分出钱、出力、出**资源的组织，如果资源来自多个组织的合力，可以把开发组织视为这多个组织合并而成的一个大组织。上面描述的例子中，可以把“以和为贵物业管理系统”的开发组织看作“浑元科技+五连鞭资本”。
不过，大多数情况下不需要考虑“五连鞭资本”。做事需要钱，钱投进来是为了赚更多钱，这是一个和特定领域无关的普遍道理。如果出资方不是直接指引关于目标系统规格的各种决策，可以当作不存在或者普遍存在，否则很容易变成批量刷废话。
所以，如果马宝国没有被出资方架空，“以和为贵物业管理系统”的开发组织设为“浑元科技”即可，马宝国是“以和为贵物业管理系统”的开发组织负责人。
其他和特定领域无关的普遍资源也是如此考虑。例如，不管开发什么系统，都不能违反法律，否则都没法出现在市场上，谈何盈利？而法律是由全国人民代表大会制定的，所以，全国人大是所有系统的最重要涉众——但这样的思考对特定系统来说没有意义。
（2）目标组织和目标组织负责人
最适合用某个系统规格的系统来改进其组织流程的组织，称为该系统规格的目标组织。
上面描述的例子中，“武德物业”就是“以和为贵物业管理系统”的目标组织，总经理房竹韧是“以和为贵物业管理系统”的目标组织负责人。
在《软件方法（上）》的前两版中，目标组织负责人也被称为“老大”。从这一版开始，我们将尽量使用“目标组织负责人”，不使用多余的词汇。
某个系统规格的开发组织和目标组织可以是同一个组织。
组织A里有部门A1（通常是IT部门），A1开发了系统规格x，用于改进A1自身的流程。这时，系统规格x的开发组织和目标组织都是A1。
组织A里有部门A1，A1开发了系统规格x，用于改进组织A的流程。这时，系统规格x的开发组织是A1，目标组织是A。A1属于A，也可以认为开发组织和目标组织都是A。
下面这个就不一样了：组织A里有部门A1，A1开发了系统规格x，用于改进部门A2的流程。这时，系统规格x的开发组织是A1，目标组织是A2，开发组织和目标组织是不同的，不能说它们都是组织A的部门，所以是同一个。
用医学来类比，看看是否可以帮助理解：
一名心脏内科医生自己检查自己的心脏；
一名心脏内科医生请另一名心脏内科医生帮自己检查心脏；
一名心脏内科在医院院长的命令下给全院员工检查心脏；
一名骨科医生觉得自己心脏不舒服，挂了本院一名心脏内科医生的号。
不过，心脏长在谁身上，心脏当前状态好不好，怎样才会对心脏好，这是有医学事实和医学规律的，不以谁给谁看病而变化——这一点后面还会不断强调。
开发组织和目标组织是组织和特定系统规格关联时所扮演的角色，所以在提到开发组织和目标组织时，务必要指明是哪一个系统规格的开发组织和目标组织，除非已经有一致的认识。
平时我们说的甲方、乙方、客户等，是很含糊和简陋的说法，很多错误就是由这些含糊导致的。
很多开发人员和我说，我们这是一个内部项目，没有客户。噢，那你们可以为所欲为了？想想就不可能嘛。所以，在下面的内容中，除了描述某个开发组织的具体场景时可能会使用之外，我们在严谨叙述方法学时，会尽量避免用甲方、乙方、客户这些含糊的词汇。
2.3 建模步骤A-1定位目标组织（可选）
在定位系统规格的目标组织和愿景时，有两个思考的出发点：从开发组织负责人出发和从目标组织负责人出发。
在上面所举的“以和为贵物业管理系统”例子中，说“浑元科技”的总经理马宝国看到了商机，这是以开发组织负责人作为思考的出发点。
还有一个可能：“武德物业”的总经理对自己组织的现状不满意，打算引进信息系统来改进，这是以目标组织负责人作为思考的出发点。
平时所说的“做项目”，有一定概率出现第二个情况，而平时所说的“做产品”，都是第一个情况。
第二个情况可以不需要定位目标组织，直接快进到定位系统的愿景。当然，思考的起点必须来自真正的目标组织负责人。“武德物业”IT部门的经理可能会觉得“武德物业”需要引进信息系统来改进“武德物业”各方面的工作，但“武德物业”已经超出了IT部门经理的管辖范围，因此这样的“觉得”是不算数的。
定位目标组织和目标组织负责人（老大）的步骤如图2-16，我们缺省认为使用了AI来辅助，后文在描述接下来的建模步骤时也是如此。
图2-16 定位目标组织和目标组织负责人的步骤。注意，目标组织负责人的类型是“系统”。
★在之前的《软件方法》版本中，目标组织负责人被称为“老大”。
2.3.1 步骤A-1-1 识别开发组织的能力
开发组织负责人就像军队的指挥官，他决定军队当前最应该开往哪个战场，和那里的敌人搏杀。A城富庶，打下来可得巨额钱粮，但敌人重兵布防，拿下来的概率很小；B城敌人力量薄弱，拿下来的概率很大，但B城很穷。
要做出最佳的决策，首先要开发组织负责人对自己组织的能力有清醒的认识。
下面是描述开发组织能力的一个例子：
接化发软件公司自评有以下能力：
*Java技术能力，能力等级为领袖等级。开发团队核心成员是Apache顶级项目的代码贡献者。公司有一个内部研发的框架“左正蹬（ZZD）”，水平处于业界前列。
*农业信息化能力，能力等级为卓越等级。做过十几个农业信息化的项目，在病虫害预警、精准灌溉和产量预测方面积累了丰富的经验，但业界还有体量更大、背景更深的竞争对手——耗子尾汁科技。
*烟草业人脉，能力等级为优秀等级。公司总经理马宝民的伯伯最近调任省烟草专卖局局长。
可以看到，能力不仅包括软件开发能力、行业知识能力，还包括人脉背景等。
可以用类图表达组织能力相关概念如图2-17：
图2-17 组织能力类图
注意，图2-17的类是“组织”，不是“开发组织”。组织有这些能力就有这些能力，即使它躺平不扮演开发组织，也有这些能力。
用接化发软件公司的数据实例化图2-17，得到对象图如图2-18：
图2-18 组织能力对象图
2.3.2 步骤A-1-2 定位目标组织规格
2.3.2.1 放下幻觉，尊重现实
识别开发组织能力之后，接下来就是从能力来定位目标组织规格。如果开发组织打算做一个系统来改进某个组织的流程，最合适的组织应该是什么样子？
根据我接触各种各样开发组织时的所见所闻，大多数开发人员，甚至有一部分挂着“产品经理”头衔的开发人员，头脑中根本没有定位的概念。
在给某团队剖析他们当前正在做的项目时，我问负责的产品经理，谁最适合用这个系统？
如果是目标系统为某个组织定制的系统，也就是所谓“做项目”，这个有现成答案的，产品经理还能回答得上来。
如果是非定制的系统，即所谓“做产品”，回答可能就是这样的：
对于有明显行业性质的产品，例如“医院信息系统”，产品经理回答：医院最适合用。
对于没有明显行业性质的产品，例如“通讯软件”，产品经理回答：谁都可以用。
这两个回答都是“正确无用的废话”，其中没有任何的思考。如果挂着“产品经理”头衔的人这样回答，而且丝毫没有觉得有什么不妥，问题就比较大了，很可能会造成大量的资源浪费。
如果这一点上不做任何思考的根源是偷懒摆烂，危害还不是最大的。
危害最大的是这个自大心态：干嘛要想这个？我做产品，当然希望用的人越多越好了！
这是把幻觉当成了现实。
幻觉：所有组织、所有人都用他做的系统。这个幻觉不需要任何思考，傻子都知道这是好事来着。
现实：目前还没有人用他做的系统。这就需要思考怎样做才能挖到第一桶金，这个思考可不容易！
如果顾客的额头上贴着一份招标书，上面写着资质、评分标准等信息，产品经理会清醒过来，原来这里也是有门槛、有竞争的、有花销的。遗憾的是，顾客只是把这份招标书默默地藏在心里。
除了自大心态之外，也有自卑心态。
有的开发组织负责人以为，有资格和有必要考虑定位问题的开发组织，应该是有较强实力，有雄心壮志的组织。这些组织可能想做产品赚大钱，或者想精准地去投标大项目。自己的组织目前处于苟活状态，靠人脉接点小项目维持，有资格和有必要想这个吗？
只要以开发组织组织负责人作为思考出发点，这个思考都是有必要而且有资格的。
靠人脉接点小项目，也不是说谁的项目都接。为什么接了二舅舅的，不接大姨妈的？可能大姨妈的项目接不到，因为竞争者和大姨妈那边的关系更近；可能大姨妈的项目对自己这边来说很难，怕做得很烂大姨妈那边都说不过去；可能大姨妈那边太抠门；可能觉察到大姨妈的项目有陷阱……
就算是乞丐讨饭，也不是对所有的施舍都会感激涕零。
2.3.2.2 形成定位意识
在原始人眼里，喝水是很简单的事情，也没多少选择，靠着河就喝河水，靠着泉就喝泉水。随着社会的发展，“喝水”变得越来越复杂。
“我进超市去买几瓶水带在路上喝”，您猜会买什么？图2-19展示了超市里摆的各种“水”（严格来说应该叫：主要成分为H2O的可饮用物质），它们瞄准的目标顾客并不完全相同。
图2-19 超市里摆的各种“水”抢夺顾客的胃
62岁的秦大爷找到KK可乐公司，和公司负责人说“我喝你们家KK可乐几十年了，特别是夏天喝冰可乐，气泡在舌尖上破裂的感觉，那叫一个爽！不过现在我年纪大了，有胃病，还有糖尿病，所以我希望你们家产品在保持原有优点的同时，又不会加重胃病和糖尿病。你看啊，我这里有一个方案，用食品纳米技术把益生菌做成纳米胶囊，这些胶囊在口腔的温度和唾液作用下破裂，又有类似碳酸气带来的爽感，又不伤害肠胃……”
KK可乐公司负责人会不会很感动，哇，这么棒的老顾客，把要求提得那么具体，实现方案也给了，省下好多我们调研需求和研发实现的时间，好，下个版本就这么办！
我觉得KK可乐公司负责人大概率会先感谢秦大爷的精彩建议，然后置之不理。此时的秦大爷已经不属于KK可乐的目标顾客（用近几年的时髦词语说就是“基本盘”）。只要年轻的肥宅足够多，他们喝可乐时依然感到快乐，KK可乐公司就不会改。
如果秦大爷坚持冒着胃病和糖尿病加重的风险继续购买可乐享用，可乐公司依然会卖给他，只是不理睬他提的建议而已。
如果有一家A公司投入资金，按照秦大爷的思路研发一款“纳米可乐”，并以较高的价格卖给秦大爷这样的人（可以把这个人群称为“退休精致大爷”），那也是可以的。这时候这款“纳米可乐”和原来的KK可乐已经不是同一产品，面向的目标顾客也不同。A公司为什么乐意做？有可能是在争取原来的目标顾客时竞争不过可乐公司，只好换一个战场。
图2-20 不同的“可乐”面对不同的目标顾客
当然，KK可乐公司也可以考虑做这个“纳米可乐”留住老顾客，但要考虑可能的风险：做出讨好“退休精致大爷”的举动之后，“年轻肥宅”会不会对品牌心生反感。
甚至不用品牌方主动讨好，非目标顾客自己送上来可能也是灾难。试想一下，一个目标顾客设定为“年轻精英男性”的品牌，突然被老年暴走团的大爷大妈追捧，受到因“女拳”出名的杨女士、王女士追捧，会有什么后果？近两年这样的例子有：某购物网站、某酒、某汽车……。
IT产品同样需要定位。下面几个看起来功能差不多的产品，小红书的目标人群是热衷于分享生活方式的都市精致女性，Bilibili 的目标人群是爱好二次元文化的Z世代，抖音的目标人群是从事非思考性事务工作的年轻上班族。
（以上只是作者的看法，可能是有偏差的。自家产品的目标人群是什么样的，厂商的负责人最有发言权。）
并不是说，秦大爷是男性，不能上小红书，秦大爷是老年人，不能上Bilibili，韦东奕是高校数学教师，不能上抖音。对于厂商来说，自然是来者不拒，多多益善，只不过不同的人所提的意见，被厂商采纳的概率和程度是不一样的，就像上面所举的秦大爷例子。
定位相当于对需求的源头做了排序，最终目的是推导出目标系统当前最重要的需求。如图2-21，A和B是两个不同的涉众类型，从他们的利益衍生的系统需求分别是A→x、y、z，B→z、m、-x。
图2-21 不同涉众类型衍生的系统需求
可以看到，需求中有相同的内容，例如需求z，不过，在不同涉众看来，需求z的排序不同；需求中有不同但可共存的内容，例如y和m；需求中还有不能共存的内容，例如x和-x。
如果有了定位的思考，就能确定需求x应该先实现。如果没有定位的思考，那就会出问题：
产品经理为图方便吃窝边草
产品经理刚好和B比较熟，认为反正B“也”可以用，而且调研B更方便。注意这个“也”字，相当于秦大爷“也”也可以上小红书。
于是，产品经理就按B的来，需求z应该先实现。宝贵的时间、金钱和人力资源会被拿去优先实现需求z，而在战场上发挥更大作用的需求x，却迟迟实现不了，甚至因为在实现需求z时资源耗尽而且在战场上节节败退，再也没有实现的机会。
这个“吃窝边草”的问题，后面还会继续提到。
这还不是最糟糕的，至少产品经理还是从涉众的角度来决定需求的排序，只不过涉众找错了。下面这个更糟糕：
被程序员绑架
我们再看图2-22，加上了“程序员乐意实现程度”的干扰因素：
图2-22 加上“程序员乐意实现”的干扰因素
程序员最乐意实现的是需求-x，如果被这个因素绑架，需求x只能沉入海底了。
至于为什么程序员最乐意实现-x，可能是因为-x刚好在他的舒适区内，不用费脑子思考，也可能-x的实现刚好需要用到程序员最近感兴趣的某个“新技术”。为了学习“新技术”和美化自己的简历，程序员对-x充满热情。
二十年前，一位技术总监的话让我印象深刻：
“知道这两个（和愿景相关度最大的）功能实现难度太大做不下去，在我看来这个项目已经没有价值，但是开发人员还乐在其中，觉得还有其他功能可以做。”
由于开发团队中各方关注的利益不同，需求被迫对实现退让——或者说得严重一点——被实现绑架，这样的场景并不鲜见，毕竟领导不能所有事情都亲力亲为，最后还需要有人搬砖。就像电视剧《康熙王朝》里姚启圣所说：
图2-23 电视剧《康熙王朝》截图
幸运的是，AI的降临横扫搬砖职位，大大削弱了实现绑架需求的力量。前些年被嘲笑的“我有一个绝妙的创意，就差一个程序员了”，将来可能就没那么可笑了，因为连“差一个程序员”都没有了。
2.3.2.3 步骤A-1-2-1 思考候选目标组织规格和目标系统规格（AI辅助）
再看图2-22，凭什么涉众类型A排在B前面？根本的依据要追溯到开发组织的能力。
在“2.3.1 步骤A-1-1 识别开发组织的能力”，我们定义了接化发软件公司的能力。现在，接化发软件公司总经理马宝民需要思考，公司做的软件最应该为什么样的组织服务，最应该改善目标组织哪方面的工作？还有，这个软件应该叫什么？
马宝民可以根据之前所归纳的能力以及对当前竞争态势的了解来思考。现在，AI有了很大的进步，他也可以借助AI的力量，获得一些启发。
马宝民可以这样写提示词：
我想利用我当前所在的软件开发组织的能力优势开发一个软件系统，并希望通过这个软件系统来获利。利益不一定是金钱，也可以是权力、名声。
我把这个想要开发的系统称为目标系统。目标系统是什么样的，有哪些功能，销售给什么样的人和组织，目前我没有确定的概念。我想请你和我一起，一步步推导出目标系统的这些信息。
请你根据我所提供的开发组织的能力集合，结合你所了解的市场竞争态势，定位目标系统的目标组织规格以及目标系统可以给目标组织的哪些流程和哪些度量指标带来改进。
目标系统的目标组织规格的定义为：如果把目标系统向这样的组织推销，打败其他竞争对手被这样的组织接受的可能性最大，而且在竞争中获胜后会有一定的利益。
目标组织规格可以是机构（例如省级税务局），也可以是人群（例如福建茶农）。
提供给你的信息包含以下内容：
*某开发组织拥有的能力集合，每一个能力给出当前在业界中能力等级。等级从高到低依次为：领袖＞卓越>优秀>普通。
要求输出的信息应包含以下内容：
*系统名称
*目标组织规格
*所改进的组织流程
*所改进的组织指标
*为什么得到这个结果（如果我指定了知识库或者附件作为参考资料，应重点回答使用了参考资料中的哪些知识点来思考）
按照以上格式，返回至少3个结果。
#例子：
附件“定位目标组织规格示例.txt”提供了一个示例，帮助你理解。
开发组织：接化发软件公司
能力集合：
*农业信息化能力，能力等级为卓越等级。做过十几个农业信息化的项目，在病虫害预警、精准灌溉和产量预测方面积累了丰富的经验，但业界还有体量更大、背景更深的竞争对手——耗子尾汁科技。
*Java技术能力，能力等级为卓越等级。开发团队核心成员是Apache著名项目的代码贡献者。公司有一个内部研发的框架“左正蹬（ZZD）”，水平处于业界前列。
*烟草业人脉，，能力等级为优秀等级。公司总经理马宝民的伯伯最近调任省烟草专卖局局长。
请你根据真实的输入信息，按照以上要求思考并给出结果。
读者替换“#真实输入信息”段落的内容，就可以把以上提示词用于自己的项目。
Claude-4.5-Sonnet（通过poe使用）针对以上提示词返回3个候选。第一个候选“烟叶种植智能管理系统”见图2-24：
图2-24 Claude-4.5-Sonnet的回答
考虑到篇幅问题，就不完整复制回答的所有内容了，另外两个方案是：基于ZZD框架的农业信息化快速开发平台，面向的目标组织规格为中小型农业软件开发公司和农业科技企业的技术团队；经济作物智能种植顾问系统，面向的目标组织规格为种植高价值经济作物的专业合作社、家庭农场和规模化种植企业。
使用UMLChina研发的AI智能建模工具“发糕”，可以轻松生成提示词并提交给AI，然后解析AI的json格式返回结果，放入软件模型中，如图2-25：
图2-25 通过“发糕2025”定位目标组织规格
关于“发糕”的更详细信息，可以到这个链接观看视频：umlchina.com/url/fagao01.html。
2.3.2.4 步骤A-1-2-2 定位目标组织规格
AI返回的候选结果只能作为决策的辅助，如果能够给我们“眼睛一亮”的启发，那自然是最好。如果感觉平平无奇，甚至感觉AI在胡说八道，也是正常的结果，毕竟这相当于在问：我这样一个人，做什么赚钱最快？要让答案带来价值，比做数学题和编代码难度大多了。
当然，可以多试几个不同品牌的AI，提高“眼睛一亮”的概率。
图2-24中的“智慧烟叶种植管理系统”（第1候选）和图2-25中的“智慧烟农助手”（第4候选），都是把烟草业人脉和农业信息化能力综合考虑得到的结果，有经验的建模人员应该也会这样来定位。或者说，这样的结果是符合建模人员的预期的。
全部符合预期也未必是好事，说明AI没有带来启发。建模人员也要提防先入为主：AI给出的结果，凡是和我预期的一致，就是好的，否则就是坏的。如果是这样，AI就白用了。
既要防止先入为主，又要不被AI的胡说八道迷惑，这个尺度如何把握，还得读者自己捉摸。
2.3.3 步骤A-1-3 定位目标组织和目标组织负责人
2.3.3.1 摧毁偷懒的庇护所
目标组织规格只是定义了规格，符合规格的组织可能有很多个。我们需要进一步回答：符合规格的组织中，哪一个组织最适合用目标系统来改进？在这一步中，我们从很多个组织定位到一个具体、真实的组织。
图2-26 从很多个组织定位到一个组织
例如，图2-24提到的“烟叶种植合作社”，全国或全世界的“烟叶种植合作社”数量可不少。哪一家烟叶种植合作社最适合用“智慧烟叶种植管理系统”来改进？
目标组织不但要具体，而且要真实，这有别于虚构的Persona 或用户画像。
坐在办公室里摆弄各种属性，虚构出一个目标组织（前文已说过，个人被视为个人组织），看起来似乎比一个具体的真实组织更精准——就像概念中的直线比真实世界的直线要直，但这很容易沦为偷懒的庇护所。
定位到一个真实的目标组织，接下来建模人员要辛苦地深入第一线调研。调研的过程是实实在在的，得到的各种文字、录音、录像素材中，可能有一部分素材和建模人员预想的或想要的并不一致，但素材就摆在那里，是不好随便更改的。
如果虚构一个目标组织，建模人员就找到了理由来逃避深入第一线调研的辛苦，因为现实中不存在这样一个“完美”的虚构组织。于是，建模人员安心地闭门造车，想象这个虚构组织的流程，想象这个虚构组织负责人想要的改进指标——更妙的是，他可以随意修改各种数据，直到符合自己的预想。
实在不得不到第一线调研时，建模人员会按自己的喜好挑选一个真实组织来调研，反正大家都不“完美”，我图自己方便挑一个也没关系嘛。
例如，做一款智能项链，如果定位到一名真实的女性：上海浑元商贸公司市场总监 刘艺菲。建模人员需要花时间去观察、访谈刘艺菲， 而且有可能刘艺菲的访谈结果会推翻建模人员之前对智能项链的设想，给建模人员增加了不少工作量。
如果虚构一名女性：上海A公司市场总监 安风，建模人员就可以肆意想象安风会怎样说和怎样做， 这些想象往往会暗合建模人员之前对智能项链的设想——相当于先想好了答案，再不断修改题目来迎合答案。
实在不得不到第一线调研时，由于现实中不存在安风这个人，建模人员可能就会图方便，找隔壁工位的女同事罗玉凤调研，反正罗玉凤也可以用这款智能项链（注意这个“也”字，很多需求问题根源就是它）。
坚持要求建模人员尽其所能定位到具体的真实组织，这是逼迫建模人员深入第一线调研的一个好手段。和其他工作流以及工作流步骤一样，任何逼迫懒惰者思考的做法都会受到阻力，不一定推行得下去，这很正常，但一定要警惕伪创新在其中浑水摸鱼。
★汽车跑得比马车快，但奈何百万马车夫衣食所系，目前不宜推行汽车，这可以理解。伪创新则是把马车改个名叫“有机动力驱动设计全域感知出行终端”，把它包装成革命性的创造、划时代的洞见，宣称汽车过时了。
定位目标组织，可以使用以下思考方法：
2.3.3.2 比较法
列出适用于当前目标组织规格的定位条件，观察和思考哪一个定位条件对于定位目标组织是最重要的。
此处可以用UML的类图。以上面提到的“烟叶种植合作社”为例，画出类图如图2-27：
图2-27 烟叶种植合作社的定位条件
先找对于定位目标组织最重要的定位条件。假设建模人员经过思考，认为“人脉关系强”是最重要的定位条件，从而把范围缩小到最符合“人脉关系强”的HN省，接下来，认为“流程规范程度高”是第二重要的定位条件，筛选出最符合“流程规范程度高”的“HN省HH市ZJ**烟叶合作社”。
可以看到，定位条件包括一个可以量化的属性（例如：农户数量）以及数值的偏好（大、小、适中……），通过比较找出最符合定位条件的组织。
从零开始来标出这些定位条件，难度很大。例如，看着“烟叶种植合作社”几个字，能想到什么属性？可能会先想到名称、地址、负责人、成立时间、农户数量、土地面积，并不容易总结出“（开发组织和所在行政区划）的人脉关系”、“流程规范程度”这样的定位条件。
建模工具可以考虑复制其他项目为相同名称或近似名称的组织规格设置的定位条件，在此基础上编辑。
可以在图2-17基础上添加类，得到图2-28：
图2-28 给组织规格加上定位条件
图2-28只是记录“名称”属性，没有进一步分解其中的概念。例如，“流程规范程度高”就是“名称”属性的值。
如果要分，还可以从“流程规范程度”抽象出“定位属性”的概念，从“高”抽象出“定位偏好”的概念，这样“定位属性”和“定位偏好”可以随意组合得到不同的条件。有的系统瞄准流程规范程度高的组织，有的系统则反其道而行之，瞄准流程规范程度低的组织，这都是有可能的。
不过，贯彻本书方法学的工具“发糕”在系统中维护定位条件的作用仅用于辅助思考，不打算承担更多的责任——例如从外购的大数据筛选出目标组织，这些交给更擅长的系统去完成。
注意定位条件和能力的区别。例如，“血压高”不是能力，但可能是常用的定位条件。
2.3.3.3 爆炸法
通过直觉先得到初步结果，再通过不断质疑来修正结果。
假设你是建模人员，投资人在你身上绑了炸弹，命令你推销目标系统并且盈利，而且条件很苛刻：（1）几分钟之内推销出去；（2）只能找一个人推销。
假设这个炸弹能感应推销对象的脑电波。推销完毕后，如果炸弹没有感应到推销对象认为这个系统能解决他的问题并且愿意付出相应代价获得系统，炸弹就会爆炸——既然系统不能盈利，就拿建模人员的命来填。
这时，为了最大可能地保住自己的性命，你会选择向谁推销？这个人就是目标组织负责人，也就是前面两版所说的“老大”。
很多人可能会第一时间想到向自己的父亲或母亲推销，但是，父亲或母亲买单只是为了救你的命，并非认为这个系统能解决他（她）的问题，炸弹依然会爆炸！
如果上面的场景还不足以刺激你思考，可以用加强版：
如果投资人在你和你的情敌身上绑了炸弹，命令你们分别按刚才的条件推销目标系统，谁的推销对象对系统感兴趣的脑电波更强，谁就活下来，活下来的人的情敌被炸死。
通过爆炸法初步得到的目标组织负责人，更多是靠直觉得到的，这个结果只是思考的起点，建模人员还需要进一步追问：是什么原因让我选择了他？
以上面的“智慧烟叶种植管理系统”为例，使用“爆炸法”，建模人员凭直觉给出结果“HN省HH市ZJ**烟叶合作社的理事长（社长）”，这时需要进一步追问：
Q：为什么是HN省HH市ZJ**烟叶合作社？
A：HN抽烟的人多，烟厂也多。
Q：就是说，烟民或烟厂数量多的，更像目标组织，HN是最多的吗？比YN怎样？
A：……没有YN多，刚才说错了，是因为我对HN这边比较熟悉。
Q：好，就是说你是先根据熟悉程度来选择的。HN这个ZJ**烟叶合作社是你最熟悉的合作社吗？
A：只能说相对于其他省份，我对HN最熟悉，但选择ZJ**烟叶合作社的原因应该不是熟悉。
Q：那为什么选ZJ**烟叶合作社，它有什么特点？
A：这个合作社从育苗到烘烤，流程都比较规范，而且还没有信息化，这样的情况比较适合用我们的系统。
Q：按“流程规范而且还没有信息化”的条件来看，HN省内，HH市ZJ**烟叶合作社是最突出的吗？
A：以我目前掌握的信息看，是的。
Q：假如，YN有比ZJ**烟叶合作社更符合“流程规范而且还没有信息化”条件的合作社，如果让你再重新思考“爆炸法”的回答，你会不会选择YN这个？
A：……不会，现在没有实力让他们接受。
……
上面的对话中，可以是建模人员自问自答，即提问者（“Q：”部分内容的提供者）和回答者（“A：”部分内容的提供者）是同一个人；也可以由一名水平较高的建模人员扮演提问者，本书作者在训练和咨询中经常扮演提问者的角色，不过，水平较高的建模人员费用不低。
幸运的是，AI非常擅长这样的问答，现在已经可以扮演提问者的角色。
我们可以把上面的套路教给AI，让AI扮演提问者，和建模人员展开问答，推导最合适的目标组织。
提示词如下，替换[ ]里的系统名称，即可用于你自己的项目。
我现在正在做一款[智慧公寓系统]，当前目标组织规格定位为[城中村房东]，需要进一步定位具体的目标组织。
请你参考附件“爆炸法.md”中的问答套路，扮演提问者的角色（即“Q：”部分内容的提出者），和我展开问答，推导最合适的目标组织。
-
在确认你理解了附件参考资料的内容后，向我提问“请你用爆炸法思考，定位一位你认为最应该向其推销的[城中村房东]负责人。”
-
得到我的回答后，你继续追问，不断质疑我所定位的具体目标组织和目标组织负责人是不是最合适的，我们将做多轮问答。
-
当我表示“我认为问答可以终止”时，你停止提问，并以清晰的列表形式，总结出我们共同提炼出的目标组织和筛选条件。
把以上提示词提交给AI，问答的过程如图2-29（为缩短图片长度，已裁掉AI界面控件部分）：
图2-29 让AI扮演提问者
和上一步“定位目标组织规格”不同，“定位目标组织”这个建模步骤，公用的AI不能一步到位告诉我们，它认为目标组织是哪一个。一是因为它没有数据，二是因为法律问题。
问公用的AI，哪个城中村出租房管理最落后，AI回答，我认为是某某市某某路某某号（真实存在）；问AI，那个年轻人最符合“年轻肥宅”的形象？AI回答，我认为是某某（真实存在）。这麻烦就大了。
当然，购买某个领域的数据，用私有部署的AI或数据处理工具来帮助筛选，不存在上面提到的两个问题。
2.3.4 常见定位错误
2.3.4.1 吃窝边草
“吃窝边草”的错误：建模人员不知不觉拔高“地理位置离开发组织近”这个定位条件的排序。
以下是本书第2版中所举的“吃窝边草”错例，今天仍然有参考价值。这些错例都来自真实的项目。
★XTY酒家
做餐饮系统，把目标组织定位为“XTY酒家”。XTY酒家就在公司旁边，开发团队的同事经常去哪里吃饭。
★隔壁老头
做老年陪伴机器人，把目标组织负责人定位为住在自己对门的Z老先生，毕竟大家是熟人，方便调研。其实Z老先生的老伴还健在，他不是最需要这个产品的人。
不知不觉“吃窝边草”，背后的心态是轻飘飘的“***也可以用”。如果前面“爆炸法”的方式思考，轻飘飘的“也可以用”大概率会导致炸弹爆炸，把建模人员炸死。在定位的思考中，必须要思考“最”，警惕“也”这个字。
注意，不要把“地理位置离开发组织近”和“人脉关系强”混淆。上面说的XTY酒家和Z先生并没有额外给予开发组织一些其他组织所不能给的利益，纯粹是建模人员偷懒图方便。
2.3.4.2 吃自己的狗粮
上面两个例子还不是最离谱的，毕竟开发组织大概率不会兼职开餐馆，开发人员也大概率不是老头，没法说“我也可以用”。或者说，定位定不到自己头上。目标组织就算近在咫尺，也不是自己，还是需要付出一点辛劳去调研的。
下面这个，连这点辛劳都不用付出，想要什么素材，自己编造就可以了：
★我就是幼儿园家长
做一款幼儿园家长用的app，开发人员的儿子也刚好上幼儿园，干脆就把自己当成目标组织负责人，自己想要什么功能就做，不要的就不做！
软件行业的民粹主义者大力推崇这样的做法，喊出了“吃自己的狗粮（dogfooding）”、“工程师文化”等得到广大程序员响应的口号。
★花絮：2025年9月，还有同学传给我一份DDD圈子的布道言论：学习DDD最好的办法是一切需求自己说了算。
有的人还打出Steve Jobs和张小龙的旗号来佐证，说Steve Jobs和张小龙从来不管客户的想法。其实他们只是不管非目标客户的想法，对目标客户的想法是极端重视的，这正是定位所要达到的目的。
以目标组织的需要为先，可以不管非目标组织的需要。这不能歪曲成谁都不用管，开发团队为所欲为。
实际上，定位目标组织后，开发团队的自由度减少了。之前张三提一个要求，开发团队懒得做，可以找到理由“会损害李四的利益”——总会找到这个李四的。一个事情对大多数人来说利大于弊，这是可能的，但不可能对所有人都利大于弊。如果定下了以张三为先，之前偷懒的理由就不成立了。
本书的前两个版本使用“老大”一词来简称目标组织负责人，有的读者没有仔细阅读“老大”的定义，看着“老大”二字就会产生这样的错觉：最合适的“老大”就是开发组织负责人。他想要做这个系统，才有这个系统，他不想做这个系统，把公司关了改行开饭馆，也由得他。
对于容易被“投资少、见效快、产量高、门槛低、仪式感十足”的伪创新诱惑的开发人员，这样的答案是非常诱人的。它貌似给了一个放之四海皆准的答案，而且不需要任何思考。
是的，想做什么就做什么，不想做也没人拿枪指着你，这无可指责。该指责的是，你不应该在如此自由飞翔的同时，还期望自然而然地财源滚滚来。懒惰自私是可以的，但懒惰自私的同时又要得多，这就有问题了。
有没有这样的可能，开发组织所定位得到的目标组织规格的代表恰好就是开发组织自身？当然有可能，如果是这样，那就是中了彩票大奖了，是大好事，同时概率也很小。
前面提到的AI智能建模工具“发糕”，就是典型的（UMLChina）“也”可以做，（UMLChina）“也”可以用的例子。我们就拿这个来剖析看看：
开发组织：UMLChina；开发组织负责人：我（潘加宇）。
如果我（开发组织负责人）产生了一个想法：做一款封装《软件方法》方法学的智能建模工具，接下来需要思考哪些问题？
首先思考，自己组织的能力做这款智能建模工具是不是最有竞争力？
可能有的同学觉得很荒谬，你自己写的书，自己塑造的方法学，你不是最有竞争力谁是？未必。
能力一：对《软件方法》方法学的理解深度。这个就算我最有竞争力吧。当然，不排除有的同学在熟读《软件方法》的基础上比我更上一层。
能力二：图形操作、渲染和布局。这个压根没有自己的积累。就算看不上开源库，花高昂授权费去买更好用的商业库，竞争对手同样可以从第三方免费或付费获得此能力，大家持平。如果和EA、MagicDraw、Rhapsody等私有、自研20+年并（很可能）包含一定建模语言语义的图形引擎相比，竞争优势就是负值了。
能力三：手绘识别……
能力四：利用AI……
也许某个成熟的工具厂商再加上一名熟读《软件方法》的建模人员，做出来的“智能建模工具”能轻松打败UMLChina开发的工具。
第一步就已经倒下了：UMLChina做这个未必是合适的。
如果还是坚持做，那么这款智能建模工具可能需要把焦点放在“智能”上，放弃图形相关的部分。幸运的是（以下内容涉及一些暂时不便公开的思考）……，这一切有了可能。
接下来思考，什么样的目标组织规格，最认为这款智能建模工具能帮到自己，乐意付出代价来获得它，然后开发组织能从中获得满意的回报？这个目标组织规格是以潘老师为代表的“类潘老师人群”吗？
如果“潘老师这样的人”指的是“软件开发方法学家”人群，那就别指望了。
首先，那些不学习不研究的伪创新“方法学家”在忙着造新词和组圈子，怎么可能会踏实思考方法学问题？
“真·方法学家”呢？都方法学家了，肯定要推自己的方法了！他可能会买一个来参考，但更常见的可能是“要”一个。注意，不是南宁周某“要了几辆电动车”那个“要”，就是人情往来。再说了，就算是买，有几个“真·方法学家”？能收多少钱？
如果“潘老师这样的人”指的是“认同《软件方法》的开发人员”人群，这个人数还算多，但我并不是这个人群中最需要这款智能建模工具的人。实际上，这款智能建模工具封装的知识和我大脑里的知识是重叠的，它起到的作用就是取代我。
也就是说，如果目标组织规格是“认同《软件方法》的开发人员”，目标组织负责人应该是一名《软件方法》水平为中级，有意愿和有权力在团队中推行《软件方法》的开发团队负责人（我大脑里有具体的人，此处隐去），并不是潘加宇。
第二步又倒下了：回旋镖旋回到自己头上，并不容易。
最后，我归纳一下“吃自己的狗粮”的不同场景，大家自行比较。
开发人员张三所在公司的老板让张三开发一款给钓鱼佬用的app，我们假设盈利模式老板心里有数。张三觉得自己偶尔也会去钓鱼，“也”算钓鱼佬，所以就按自己的想法来。
这是出于自私，图省事而不顾公司利益。
开发人员张三热爱钓鱼，并结交了一群钓鱼佬同好。张三想利用自己的能力做个app，给兄弟们带来方便，同时自己还能获利。张三认为自己就是钓鱼佬的代表，所以就按自己的想法来。这个场景和上面的智能建模工具类似。
这里面的问题不是自私，为兄弟谋福利倒是可敬的。问题是错估了自己。
自己的能力做这个有没有竞争优势？不好说。自己是不是钓鱼佬的典型？这个很可能不是。和前面所说的幼儿园家长类似，一名职业为软件开发人员的幼儿园家长能代表典型的幼儿园家长形象吗？一名职业为软件开发人员的钓鱼佬能代表典型的钓鱼佬形象吗？
可能有人会辩解说，“吃自己的狗粮”是鼓励开发人员尽量多使用自己开发的系统，感同身受地体察系统给涉众带来的方便和痛苦，并不是让开发人员把自己当目标涉众。
遗憾的是，现实中很容易这样滑坡。开发人员大概率会把自己感受到的方便和痛苦当作目标涉众的方便和痛苦，因为客观上他已经没有更多的精力再去体会目标涉众的方便和痛苦，更要命的是，主观上，他也不愿用目标涉众的方便和痛苦来否定自己感受到的方便和痛苦，而是会说“系统很好用，是你太笨了”……
不可否认，开发人员感受到的方便和痛苦和目标涉众的方便和痛苦有一部分是相同的。比起更烂的情况“开发人员随心所欲开发，对涉众置之不理”，“吃自己的狗粮”肯定是有好处的。
但要在竞争中胜出，思路并不是找“还有没有比我更烂的”，而是要找“还有没有比我更不烂的”。这样的思考难度更大，更耗费脑力，很多人不是愿意去做的。
这就是第1章所归纳的伪创新手法“割裂历史”，把参照物拉回到蛮荒时代——如果不用我这个，就什么都没得用。因为还有比我更烂的，所以我就是最好的。
参见：
《潘老师有点理想化了，现实中程序员很菜的占多数》（umlchina.com/url/lxh.html）
《“以炮换马”的DDD歪招是否可以作为起步》（umlchina.com/url/waizhao.html）
如果有人就是乐意“为爱发电”呢？做出来的东西有没有用，有没有人乐意用都无所谓，那就和本章或本书的内容没关系了，但不得不泼一盘冷水：有权力和有意愿“为爱发电”的人非常稀少。
以上文所说的“钓鱼佬”场景为例，第一个场景中，张三作为一个打工人，没有权力随着自己的喜好“为爱发电”。如果他这样做，就是渎职。第二个场景中，张三也许并不想从钓鱼佬兄弟那里收钱，但他可能追求的是兄弟们的感谢和赞赏，这也是利益，甚至是比金钱还难获得的利益。如果是这样，张三也并非有意愿“为爱发电”。
“为爱发电”也好，想要获利也好，都是个体的自由选择，不分高低。需要批评的是“又当又立”：打着“为爱发电”的旗号，其实却很在乎获利；在乎获利，却懒得去体会目标涉众的感受，以“工程师文化”为名，随性而行。
★有些人的“爱”，其实是自己想怎么爽就怎么来，这是自私自利，根本不是爱他人。
2.3.4.3 因果颠倒和装模作样
定位的时候，装模作样给出了一个结果，但这个结果不含任何思考的价值。
例如，问“这个系统给谁用”，答“给适合用这个系统的人”，这就是正确而无用的废话，但一些人乐此不疲。
很多时候没那么直接，可能会先入为主地设想系统的一个功能F，然后从这个功能出发来定义目标组织规格——“特别需要F来做事情的人”。
例如，一个二手交易的系统，开发人员认为“官方鉴定”是一个亮点，于是把目标组织规格定位为“特别需要二手交易官方鉴定服务的人群”，看起来好像正确，但并未包含任何增值的信息。
我们在业务建模工作流所做的一切，目的就是推导出功能“正确”的系统。这里的“正确”，判断标准就是利润。如果先想好了某个系统或系统的某个功能是什么样子，再以此为出发点去“推导”业务建模的内容，这实际上就是因果颠倒。
★伪创新的诱人之处：批量产出“看起来好像正确，但并未包含任何增值的信息”。
我们需要刻意避开先入为主的内容，从其他视角来思考。例如，如果预想了“二手交易官方鉴定”可能是一个亮点（当然，这样的预想不是凭空产生的，而是建模人员在大脑中朦朦胧胧地做了未知对错的业务建模），定位时就要避开这些字眼，从其他视角思考，如“大学生还是家庭主妇更像目标客户”。
即使不是开发软件系统，而是做其他事情，在这一点上，定位的道理也是类似的。例如开一家餐馆，如果问目标客户是什么人，从“功能”出发回答“来吃饭的人”或“肚子饿的人”没有任何增值信息，并不能帮助推导出餐馆合适的选址、环境风格、菜品。如果先避开餐厅的功能，定位出“科技公司的年轻打工人”，就可以推导出有价值的信息。
在第1章中说过，伪创新擅长“换词”、“砌词”。有时候，废话会经过包装。例如，做一款功能类似于抖音、快手的app，目标组织规格定位为“爱刷一族”或“视觉体验爱好者”，看起来就隐蔽得多，不像“喜欢刷短视频的用户”这样，容易让人一眼看出是废话。
注意，我们并不是要禁止反向思维。从业务建模推导出系统需求后，再把结果放回业务建模的工件来验证结果是否正确，这是可以的，不是因果颠倒。
导致因果颠倒的“验证”是：以所谓的“系统需求”为依据，否定了业务建模的内容。相当于考试做题，也不打草稿理思路（反正也不会），直接就乱答。答完把结果2456代回题目验算，发现不对。此时，应该检查自己的解题思路是否正确，但这太辛苦了！很多做题的人下意识优先怀疑题目有错，要改题。
这也是现实中很多“敏捷试错”受欢迎的原因。如果诚实地“敏（无）捷（脑）试错”，错了就真的老老实实重做，那是非常非常累的。如果板子真的打到自己身上，“大聪明”们就不会鼓吹“敏捷试错”了。“大聪明”的选择是，把判定错误的尺度隐藏在自己的大脑里，主打一个by experience、心领神会和拈花微笑。
所以，在一些改起来比较麻烦的地方，他们并不认为自己错了，而是想办法换一个适用的场景——能不能真的“改题”并不要紧，开发人员只需要假设能就行了，反正亏损的又不是他。
★伪创新诱人之处：留出了偷奸耍滑的空间，让懒惰者自行把握判定的尺度。
以为可以随意“换题”的幻觉，还带来了一个有趣的现象。在某些不知柴米油盐贵的开发人员眼里，“做产品”比“做项目”更容易，因为“做产品”看起来没有“做项目”那样难侍候的“客户”或“甲方”，自己想怎么做就怎么做！
2.3.4.4 假装圣母
要做一个电子病历系统卖给医院，说“客户是医院”肯定不够。医院有大型三甲医院，也有二级医院、中心卫生院，甚至社区卫生服务中心……还有根据性别细分的男子医院、女子医院，根据人体器官细分的口腔医院、肝病医院、肛肠医院……还不要忘了国外的医院，美国的JHH、Mayo、乌干达的@％&，孟加拉的&￥#……。
建模人员使用前文所述的方法定位出目标组织为“北京大兴中医院”。这时，可能就会有人质疑，要是我们只关注“北京大兴中医院”，那“北京协和医院”是不是就漏掉了？难道“北京协和医院”不重要吗？
事实是，这个时候“北京协和医院”确实不重要。“大兴中医院”想要的都还没有满足，第一桶金都没挖到，去想“协和医院”干什么？害怕“漏掉”的想法是幼稚的。需求是一口深井，永远做不完。只要您愿意，可以满世界去调研所有医院，甚至不用调研，拍脑袋就可以得出上万条"需求"。
★上面的故事也可以改成：建模人员定位了“北京协和医院”，有人质疑：难道“北京大兴中医院”不重要吗？
警惕“难道……不重要吗”的话术。说话人可能在假装圣母，以胸怀天下的姿态有意无意地扩大讨论范围，然后在更大范围内选择对自己更有利的结果。也许是去“北京大兴中医院”调研太累了，扩大范围后挑选自己方便调研的医院或者之前已经调研过的医院，这样可以省时省力。
这样的现象，在软件开发的各个工作流中都会观察到。
例如，针对一个外卖平台，产品经理定位下一步最应该做的工作是优化骑手配送路线。这时，有人质疑“难道其他地方的优化不重要吗”，目的是要扩大范围，然后再落实到和自己利益相关的“优化”上，例如App界面的优化——如果能实现，就会成为自己作品集的一部分。
社会生活中也有类似情形。例如，我们说要保障人的权利。假圣母会说，人只是动物的一种，难道其他动物的权利就不重要吗？于是，范围从人扩大到动物，然后在动物这个大范围内，落实为优先保障自己所养的宠物的权利。
为什么不既要又要都要呢？严格来说是可以的，只不过要排序，因为资源是有限的，要先解决排序最靠前的问题，再解决排序最靠前的问题，再解决排序最靠前的问题……
不只是定位目标组织，一直到后续各个工作流的各个步骤，都需要有排序的思想，习惯说“最”，警惕说“也”。这根线如果守不住，会很快滑坡，陷入废话和浪费的泥潭——当然，这也是一些盖着遮羞布的开发人员有意无意想要达到的。
