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

图文来源于BIMBOX。

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

Part.1

区展聪的故事

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Part.2

图图的经验之谈

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

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

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

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

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

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

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

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

区别非常大。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

讲这么一件事:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图图的小Tip

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

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

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

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

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

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

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

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

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

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

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

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

Part.3

老孙的思考

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0

评论0

请先

没有账号? 注册  忘记密码?

社交账号快速登录

微信扫一扫关注
扫码关注后会自动登录网站
普人特福的博客cnzz&51la for wordpress,cnzz for wordpress,51la for wordpress