两个朋友「正向设计做族」的血泪分享，跟你聊聊「上游思维」

你好，这里是BIMBOX，我是老孙。

今天想通过一位老朋友的亲身经历，引出另一位老朋友的干货分享，你可以选择学习技术要点，也可以翻到最后，听我唠唠关于职场工作中「上游思维」的思考。

Part.1

区展聪的故事

前段时间，我看到区展聪在他的个人公众号「装BIM」写了一篇文章，叫《设计阶段门窗族创建血泪史》，听着就挺惨的哈。

他在2020年5月，从同事手上接管了一套公司的标准门窗族，这套族拿给负责设计的人员去使用的时候，反馈回来一大堆问题，于是区展聪就开始修改这套族。

他花了一周多的时间，先琢磨公司的出图习惯，再重新梳理门窗族在设计阶段的需求，然后把整套门窗族重新建了一遍。

图片来源：区展聪《设计阶段门窗族创建血泪史》

这套族在公司内部用了一段时间，后来公司内部又有了二次开发的需求，需要读取族里面的特定参数信息，为了配合算法的识别需求，他又重新做了一遍排查和修改，弄完了人就有点麻。

不过，这时候他还没意识到，整套族存在着一个致命的缺陷。

后来他们公司开始用Revit做一个正向设计的试点项目，他发现单凭一套标准门窗族库，永远无法满足一个项目的门窗需求。

项目里除了标准的门窗，还有大量的非标准门窗。参与项目的都是刚接触 Revit 不久的设计人员，完全没有自己创建族的能力，项目时间又特别紧，非标准门窗的创建，还是得由他来负责。

于是又拉了两个同事，一起加班建族。经过几天奋战，总算是弄出来了，可忙完了项目，区展聪想再把所有人的族整理到一起，就又发现问题了。

三个人创建的门窗族虽然都能满足项目需求，但建族的方式各不相同，这就会导致后期族库的维护特别困难。

于是他就想，必须得让所有人多学会使用同一套建族方式，他们需要的不仅是一套门窗族库，更是一套门窗族创建标准。

图片来源：区展聪《设计阶段门窗族创建血泪史》

于是，为了提高其他人的接受程度，区展聪推翻了自己以往的建族思路，重新研究了一套简单快捷的工作流程，制定了通用的族样板，还把大的族拆分成一系列更基本的小族，比如玻璃、门框、把手等等，这样其他人就能像搭积木一样把整个门窗族给组装出来。

区展聪在复盘整个过程的时候说，如果从一开始就不急于做那些缝缝补补的工作，而是先把标准的工作流程梳理出来，尽量考虑多人合作的坑，让所有设计人员都能参与到这套族的建设中，有些班就不用加了。

他在这篇文章里，提到了去年我给他推荐的一本书，叫《上游思维》，书的副标题是「变被动为主动的高手思考法」。

这本书文章末尾会给大家送出几本看看。

那些防患于未然、在问题发生之前解决掉的思维，叫上游思维，与它对应当然的就是下游思维了。

下游的问题是显而易见的，而上游的问题不容易被看出来。下游问题的责任非常明确，该是谁的事儿一清二楚；而上游问题往往没有明确的责任人。下游的问题都比较紧急，不解决不行；而上游的问题常常是「重要而不紧急」的。

后来，我又和BOX一位老伙计图图聊起了区展聪的故事，聊到了这个上游思维，他说正好自己也有关于团队建族方面的避坑经验，这里面值得说的东西还真不少，于是专门整理了一篇文章，在这儿分享给大家。

下面就是图图热乎乎的分享。

Part.2

图图的经验之谈

你好，我是图图，之前和BIMBOX一起合作了《精装室内BIM分享课》，这门课程是根据我自己一年多的工作经验总结的。

最近我在北京结束了一个阶段的工作，回到武汉正在重新找工作，间歇期总结了一些感悟，和大家分享一下多人团队做正向设计的一些经验，帮助大家避开我趟过的坑。

我曾经在一家头部民营房地产公司控股的精装设计院做BIM技术负责人，日常的项目大部分都是住宅项目，有用CAD出图的，也有用BIM的。

我所在的技术部，主要是给项目组提供BIM各方面的技术支持，并负责所有基础资源的制作迭代、标准的制定管理工作，另外还跟集团有对接的任务，同时也兼任多个产品的产品经理。

和一般的设计单位和咨询单位不一样，我们无论是CAD还是BIM的生产工作，都是由设计团队完成的。

做精装出图的时候，用到的族是特别关键的，要保证族放置后做到零调整、不二次加工，才能保证效率。

要知道绝大部分设计师为了效率不会做任何妥协，所以出图体验要摆在第一位，体验好了，后面落地执行都是水到渠成的事，就和做产品一样，好的产品用户体验永远摆在第一位。

我想重点讨论的是：一两个人做正向设计，和几十上百人做正向有啥区别呢？

区别非常大。

一个人做设计，自己改改族、出出图，做完一个项目没有什么大问题，但是当参与者扩大到几十、上百人的团队时，完全就是两种概念了。

首先，这几十上百人的设计师，绝大部分都没有独立做族的能力。其次是做族手法，每个人做族习惯都不太一样，每当有新的族需求时，你拿到一个其他人做过的族，看了族的内部结构之后，大概率会想自己重新做一个。

所以，为了保证族的重复利用价值，以及规范生产流程，我们制定了一套完整的做族规范，具体到每一个参数怎么设置，每个族使用什么族类别，族的二次分类等等。

其中族的二次分类是个很重要的步骤，Revit默认的族类别是固定不变的那些大类，比如系统族的墙、可载入族的门窗等，我们把它记为一次分类，你无法自己创造一个一次分类出来，比如门槛石，你没法创建出一个名为「门槛石」的族类别，并让它和其它默认的族类别享有同等地位。

但在实际应用过程中，不管是哪个专业，肯定都是有这种需求出现的。

所以，在建族之前，我们在规范里指定门槛石的族类别为常规模型，这里不一定非得是「常规模型」族类别，只是选一个相近的族类别放进去，没有相近的就统一丢到常规模型里了。

这一步的选择不是关键因素，关键因素是这个族的二次分类。二次分类强调动作，和「二级分类」可能会混淆，需要重点强调一下。

和前面的一次分类相对应，我们在所有的族里面都加了几个固定的新参数，比如：一级分类、二级分类（注意，这里是二级分类参数，而不是二次分类这个动作）、族发布日期、族发布者、族版本、构件层级、编码，等等。

这些参数都是用插件或脚本一次性写到所有族里的，所以和族样板里自带的那些参数并没有什么区别，同时也可以在过滤器中被直接调用。

说到过滤器，族的二次分类好处就出来了。

举个例子，在创建一个视图样板过程中，其中一步是需要把所有的地面构件隐藏，那么，按照传统的手法，你需要先隐藏楼板，再通过常规模型的过滤器单独隐藏门槛石；如果还有其他的构件，比如地漏，那么你可能还需要通过卫浴装置的过滤器单独隐藏地漏。

虽然可以使用多个条件同时过滤，但设计师很难理解这个逻辑，也不利于样板的维护迭代。

如果进行过二次分类，那么以上所有的构件的「一级分类」都是地面构件，「二级分类」才是地砖、木地板、门槛石、地漏等，所以通过一级分类，我能直接在过滤器中过滤掉所有的地面构件。

这里首先解决了效率问题，另外还有一个很关键的点，我们使族的分类信息变得更加整洁、规范，有规范可循，有标准可依，不再像以前那样某个人拍脑袋就定了一个分类，量大了之后，导致后期维护样板和族的时候异常艰辛。

其实无论是民航局、建标院编写过的《建筑信息模型分类和编码标准》，还是各部门发布过的标准，都有对构件进行分类，一开始我在咨询单位，对这些分类其实没啥感觉，不觉得有什么作用，直到自己用到了，才有如梦初醒的感觉。

老孙和我谈到了区展聪在做族过程中的血泪史，还有顺便聊到的上游思维，说的都是这个事。

族的分类不可能一开始就做得非常完备，一开始1.0版本的族规范，会定得大而全，只要能想得到的都给定了，等到具体实施的时候，如果发现不合适，再启动修改规范的流程，接着按照新规范修改对应的族。

一旦修改了规范，那么这条规范涉及到的族理论上都需要修改，我的建议是将涉及到的常用族都一并更新掉，不常用的可以慢慢迭代，这样虽然麻烦，但是可以避免后期版本混乱的情况。

反之，决策者一旦开了「先这样吧」、「后面再说」等等类似的口子，那么后面就会越缠越乱，导致整个系统崩溃，不得不来一次大换血，这是小病不治拖成大病的真实写照。

如果是新增规范，就比较简单，直接往原规范里塞就行了，新做的族也大概率不影响旧的族。

为什么说是「大概率」，而不是百分之百呢？因为族和族之间还真能互相影响。

讲这么一件事：

我们自己在族规范这一波手术之后，面对橱柜类的族，又陷入了两难。

橱柜类的成品族是由通用的组件组成了不同的形态，比如门板、侧板、顶板、层板、底板等，类似的还有窗户的窗扇、窗框、把手等组件族。

针对所有组件级别的族，我们面临两个选择，要么勾上「共享」这个选项，要么不勾这个选项。

勾上之后，在所有橱柜类的成品族里，该组件的版本将会成为唯一，如果有其他版本，那么必须选择是否覆盖。这批已经组装好的族文件载入到同一个项目里，它们的小组件版本也必须是唯一的。

如果项目里的双开门橱柜和单开门橱柜共用了一个门把手，但这个把手的版本不一样，软件就会提醒你是否覆盖，你只能保留其中一个。

这样也就意味着，只要你正在载入的组件是最新的版本，那么你可以一次性在项目环境下，替换掉所有橱柜类成品族的该组件，前提就是：之前迭代的时候组件全部勾上了共享选项。

这样操作下来之后，不管再多的变更，一个组件永远只需要一次修改，之后再载入项目环境就能覆盖所有的成品族。

这样能给每次迭代工作带来极大的便利，但是，代价也是巨大的。

一旦决定了勾选共享，那么所有的橱柜类成品族都需要一次性迭代完，基本上等于重做了，因为组件参照以及方向的原因，原本正常的橱柜成品族，在被新组件替换后，方向和参数的约束出现混乱是很常见的，一旦在载入项目环境下时选择了覆盖，以前旧的族都会被打乱。

一个项目里有的橱柜是正常的，有的组件方向就错了。

所以这一百多个柜体，必须完完整整的拿出去一次性修改完，再完完整整的放回来，供设计师使用。那么实际操作会是怎样的呢？

当时我们制定了初代的族规范后，集合了5名有做族能力的设计师，将所有的常用族进行了迭代，一共有一百多个成品族。

单纯的看这一百多个族，算不上特别特别多，但是按照新规范，一个成品族，组件就有好几个，像复杂的门、柜体，这些组件就有七八个，再加上图例，总数量在一百多的基础上是番了好几番。

我们把这次版本统一在了3.0。

后来，在3.1版本柜体族专项迭代的时候，我们就在勾选共享这里趟了坑。

这一次，就没有上次那么大张旗鼓的一波弄完，因为图纸不稳定、错误多、投入人员不够等原因，迭代是缓慢进行的。

但因为之前3.0版本的迭代，已经将所有的组件勾了共享，所以3.1版本已经迭代完的橱柜族，会对未迭代的橱柜族造成影响，而剩余的族数量更多，而且因为审核的原因没法继续迭代。

也就是说这一波现有的资源，是互相冲突的，但是，项目又不断在推进，我们必须保证平台上的族是能用的版本，所以，我无奈地决定将已更新的橱柜类成品族及其组件全部取消共享，并上传族库平台，保证设计师正常使用。

经历这一波之后，我知道我们选错了战场，不应该决定在橱柜类的族里勾上共享。正常情况下，人员足够的话，我们能一次性迭代完，但是实际上叠加了太多debuff，导致没法快速解决战斗，最后不得不壮士断臂，回到原点。

如果问我前期能不能预想到这种结局？我恐怕不可能做到，这些负面因素完全是意料之外，也就是这波教训，不管我怎么挣扎预判，都会挨上。

取消共享的常规操作比较麻烦，甚至无法撤回。我这里有个小技巧，可以适用大部分情况，但不是百分百，所以共享需谨慎，以免导致部分资源报废。

图图的小Tip

共享识别冲突的机制是根据族名称来的，只要组件族名称不一样，就不会冲突。

所以只需要在成品族环境下，在项目浏览器里右键编辑组件族，取消组件族的共享，此时组件族环境下族名称未修改，还是原样。

再切换到成品族环境，在项目浏览器里将该组件族的族名称后面加一个1，或者其他字母都行，这时候成品族环境下带后缀1的就是旧组件了。

接着切换到组件族环境，把该组件载入到前面的成品族里，按下ESC不要放置，再选中后缀为1的旧组件，通过属性栏切换族类型为刚刚载入的不带后缀1的新组件族，切换完成后不报错就是没问题了。

参数约束比较多的可能会报错，删除约束后需要检查一下参控是否正确，最后删掉后缀带1的旧组件族就行了。

最后总结一下，规范和标准是排在第一位的，同时还会解决其它的小问题，要记住，不是为了解决某个问题而制作的规范，而是接地气的规范顺便解决了这个问题。

目前，正向设计的成果目前主要还是施工图，成果单一，可替代性强，由Revit生态衍生出来的算量、渲染等应用，还没有得到很好的发挥。

在这次算量经验的总结之后，我加更了一期精装算量的课程，对于已经购买过的小伙伴是免费的，大家有兴趣可以去看看。

Part.3

老孙的思考

图图的分享就说到这儿，最后我想再聊几句「上游思维」。

《上游思维》这本书我是去年读的，带来的思考和收获很多，也让我想清楚一件事：这几年见到一些圈子里的朋友，一开始的水平能力都差不多，为什么四五年之后无论是能力、职位还是收入都越差越多？

有这么个故事，说有两个人，看到有个孩子掉到河里在喊救命，就赶紧跳进河里开始营救。好不容易把这个孩子救上岸，可马上又听到一个孩子在河里被淹着喊救命。

紧接着，一个又一个小孩出现在河里，两个人都有点筋疲力尽了。这时候，其中一个人上了岸，往上游走去，他的朋友就赶紧喊他，这河里还有孩子救不过来了，你干啥去呀？上岸的人说，我得到河的上游去看看，是谁把这些孩子扔进水里的。

你看，这个故事里的两个人，其实代表着完全不同的两种思维方式。

下游思维的人，是典型的遇到问题就解决问题，每天都在处理最紧急的情况，每一个行为都很被动，而且还经常陷入「只有苦劳、没有功劳」的境地。

而与之相对的，是那些拥有上游思维的人，他们懂得未雨绸缪、防患于未然，能够去找到问题的本质，主动出击，他们的工作会从容很多，也经常会取得改变组织的大成绩。

所谓普通人改变结果，优秀的人改变原因，顶级高手改变模型。

拥有上游思维能给我们带来什么好处？我总结了三个：

➤ 第一层好处：给领导一个提拔你的理由。

现在大家都很卷啊，你敢加班到10点，人家就敢加班到12点，所以仅凭「苦劳」等着升迁，不太现实。

那领导在一群辛苦的小绵羊之中，最想提拔的人是哪个呢？对，就是那个最能扛事儿的人。

下游思维本质上都是在甩锅，是只敢承担自己一亩三分地的责任，领导都是考虑几十几百口子的人，他需要的是在更大的格局下，帮他解决更大问题的人，这个更大的格局，就是上游思维。

这里的领导不一定是你现在的领导，可能是下一次跳槽面试你的领导，也可能是你出去创业时的第一个投资人，总之，你的上游气质，会吸引生命里的贵人。

➤ 第二层好处：境界稍微高一点，打造你的秘密武器。

有的公司，两个人各带一个团队，手里的资源差不多，一段时间之后，一个团队的战斗力就很强，客户也很满意，而另一个团队的表现就很糟糕。

你要去问团队里的人，他们可能会给你一些很模糊的答案，比如大家手里的工具好用，比如大家很团结，比如老大人很好。

但他们不知道，所有这些模糊的体验，都不是碰运气，而是团队负责人站在上游，有意设计出来的。他在问题还没发生的时候，就把问题解决了，所以除了他之外，没有人知道到底秘诀在哪里。

当别人把你的努力看做天赋或者运气的时候，你就已经成功了。

➤ 第三个好处：再提升一下境界，上游思维给你更大的自我成就感。

你迟早会面临这样的问题：当温饱问题已经解决，一定会有更高的需求，比如赢得他人的尊重，找到工作的意义，以及自我实现。

要得到自我实现的满足感，光是自己给自己画饼——我不是在搬砖，我在建造一座城市，这是不够的，当你真的去思考一座城市应该是什么样的，并且用自己的智慧去解决了关乎更多人的大问题的时候，可能有时候你做的事没有带来直接的经济利益，甚至可能你的贡献不为每个人所知，但你会觉得不枉此生。

好了，升职加薪，偷偷成功，自我实现，就是我敬佩那些拥有上游思维的人的原因，希望能给你一点点参考。

最后送点小福利：今天的文章下留言，聊聊你的思考，截止到9月27号中午12点，留言点赞排名前三的小伙伴，会收到我们免费送出的一本《上游思维》。

有态度，有深度，BIMBOX，咱们下次见！

本篇文章来源于微信公众号: BIM清流BIMBOX