昨天的推文里面有分享王师母的"幕后产品"，其中师母有讲到产品信息一章。
原文提到
“信息架构是最前端的表现层架构，产品架构是连接业务和用户的产品功能，业务架构是包含商业逻辑的架构。
思考的时候依次从业务架构到产品架构到信息架构思考。”
今天发到产品遇上运营群里，鹏哥提出了不同的意见，我觉得很有探讨意义，包括我自己，过去对信息架构、产品架构、业务架构的关系都傻傻分不清楚。
鹏哥的观点是：
“最底层的是业务架构，中层的是产品架构，上层的是信息架构，底层到中层我同意，因为这就是推演承接关系。
信息架构本身是产品的一个局部，前台产品的展现层。它可以单独分出章节来论述。”
鹏哥的认为信息架构和产品架构不是并行的，信息架构应该是产品架构的一个局部。
由于这方面的产品资料很少，我看过关于产品分层比较经典的书是《用户体验五要素》，书中把产品分为五层：
分别是 表现层→框架层→结构层→范围层→战略层。
受到这本书的影响，我个人倾向与把业务架构、产品架构、信息架构做并行处理，并且依次分解。
这样分层最核心是好记！
我认为表现层、框架层、结构层统一归类为信息架构，范围层对应产品架构，业务架构对应战略层。
对于B端负责产品，从业务架构到产品架构到信息架构，依次怎么推演，其实杨老师有张图最好能说明
我个人认为B端产品在抽象、复用上有天然的基因，但是C端产品，如何从业务架构、到产品架构到信息架构推演出来，其实我是蒙逼的。
呱哥自己没有做过C端产品，所以关于C端产品信息架构如何做得简洁，让用户感觉简单，而且还好用，也没有相关思路，如果你知道请留言。
B端产品如果按照上面的流程进行规划，能提高复杂业务系统的架构能力和扩展性，但是这只是如果罢了。
有个读者朋友提到
“之前出现过产品功能堆砌，然后代码变成屎上雕花的情况。分析了下原因，主要有两块：
初期业务调研不充分，业务认知不全面，导致业务建模过程中有遗漏，主要其中于业务用例层面有疏漏；
业务建模搭建的时候，没有从顶层设计，而是从业务用例层面逐渐堆砌的，这样也会导致后面很难撸代码。”
呱哥听到屎上雕花这个四个字是又好气又好学，特别共鸣！
呱哥之前在创业公司就是这样，小公司对产品的考核第一要务是"快"，要什么产品质量和架构，功能只要最快速度的能上线就行，上线改bug这才是基操。
呱哥之前按业务架构到产品架构梳理的思路做了一套系统，但是业务部门觉得太麻烦了，并且因为历史数据问题，2个月搭建的系统说扔就扔，最后嘴碎的人还说系统不好。
没办法！最后用低代码平台给他们做了一套表单系统，大概是带流程的excel系统，业务部门到是欣然接受。
大部分做复杂业务系统的产品经理都是在填坑中度过，无非是前人挖了一大堆坑，或者是核心人换了又换，系统一点点改，越改到后面越没有什么追求了。
直到有一天来了新的高层，生怕老系统直接塌了，于是组织人力来了一次重构，并且也是一次投名状。
可是当业务继续发展下去，匆匆忙忙重构的系统又变成老系统，如此反复下去。
呱哥之前做过乙方项目，当年我们就是每隔几年要求客户换系统，一来是为了创收，二来也是老系统实在不想改下去了，这样人也留不住啊，工程师内心还是觉得新项目有价值。
一次标准的业务架构、产品架构、信息架构梳理，前期还是比较费时费力，而且研发成本初期也会比较高。
但研发费钱，如果你所在的团队拮据，还是老老实实堆功能吧，如果你恰好赶上一个大项目，那恭喜你，好好梳理清楚，别丢产品人的脸~
好看的人在点亮小花
扫一扫
8万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
