分类： ROUND1

产品经理在实战中想必遇到过类似情景：
a、面临某个问题，想到了彻底的解决方案，于是上路启程，但是途中可能由于碰到原来并未识别到的外界约束或者边界，而无法继续前进。诸如：目前的技术实力不足以支持、外部新出台政策限制、配套强关联的支持部门/系统存在致命短板无法匹配；

b、清晰的识别到了当下的约束条件和背景，知道前进路径的踩点在哪里，也看到了未来的应有的路径是什么（可能是推翻原有的踩点重建，也可能是基于原来的踩点进行大保健）
总之上面情形下，都不得不面临“仰望星空，关注脚下”的现实，说到底就是我们生存的世界无时无刻不面临着当时环境和时间下的约束与边界。

可通常工作中产品面临快速的迭代演进，当初的踩点、路径，为什么如此建立？当初的约束条件和背景信息，却很难得到有效的保留，更别说指望团队的成员都可以记住这个事情。

随着市场、业务、产品、技术、时间的推进，外界约束条件不断发生变化，或是国家政策、市场风向、业务模式、新技术、新要素等。

没有一蹴而就的产品，更没有一蹴而就的用户价值满足。妥协的方案一定意味着用户价值的打折，即便用户的直观体验并未影响，但也可能由于曲折的将就方案导致其他维护成本、研发成本的增加，间接来说也是在伤害用户体验，因为你丧失或者说延误了本可以创造更多用户价值的机会成本或者时间窗口。

研发资源在大部分团队通常都是有限的，奢求无限资源无限开火权无疑痴人说梦。如何使用的更加高效、更加具备长期价值，如果指望甩给PMO单靠项目经理根本不可能完成，更多的也需要产品经理、研发负责人、技术负责人共同进行思考规划。

保持关注，时刻审视每个点在当下约束条件和边界中，是否已经不合时宜？是否可以更上一层楼？这要求产品经理对于产品时刻要保有初心和小白的审视，而不是懒惰的认为，曾经的路就是不变的基石，特别是在互联网软件产品行业中。快速的迭代，难免会让团队成员忽略回头看，甚至记忆中模糊掉了来时的路。

成长都是血泪的教训，失败给我们不断反思和成长（想一想优秀是不是需要真金白银的支撑，给你磨刀练级）。记得2022年初为了解决当时业务上供应商退货批次准确性的问题而提出的设计方案，在研发途中识别出来在概念、方案设计、测试用例评审基本都没有发现出来的问题。

索性没有上线，好在当时也不是研发资源吃紧的阶段，等可行的步骤全部进行完之后及时止损，也算是为以后重启这项工作做了技术性的探索和铺垫。

后来随着业务发展，产品架构不断演进，到达2023年末该问题直接所属系统的周边系统产品不断迭代，功能一步一步往前走。再回头看当时无解的问题，已经变得可解了。这就是我们所说的随着时间变化，外界约束和边界的变化。

很容易想到，站在未来的某一天，重新了解到曾经这个无解问题的人，大概率会狂傲的一句：sb，这么显而易见的问题都不能搞定？

我们都曾这样看待世界，看待我们不了解的事情，站在无知的愚昧山峰，审视众生而以为自己看透了人间。

⭐️西西弗三方仓储服务商集成项目
👨产品经理
🗓2024年2月-2024年4月
【项目介绍】:西西弗轻餐饮业务线由于原材料的特殊性，需要强依赖冷链运输、储存能力，同时经营需求较高的配送频率。因此欲集成外部成熟的服务商能力，满足当前阶段业务快速发展的诉求。
【项目业绩】:深度参与前期业务调研、外部服务商集成沟通，负责系统间集成方案设计，研发跟进、验收、交付培训。上线后有效提升了轻餐饮业务配送秩序。

⭐️西西弗电商平台集成项目
👨产品经理
🗓2023年9月-2023年10月
【项目介绍】:西西弗电商业务除了自研APP之外，还有丰富的三方电商平台，比如:抖音、小红书、天猫等，外部电商平台一直游离在团队的系统框架之外，无法进行有效的订单、平台库存管理、仓内发货管理，此次集成通过三方电商ERP完成订单的中中心化管理和对仓库下发，实现平台订单、发货的自动化。
【项目业绩】:负责自研ERP 、三方电商ERP、WMS外部电商平台集成方案设计，跟进研发、验收、交付培训。顺利支持了外部电商平台线上业务的自动化运转。

⭐️西西弗RFID集成项目
👨产品经理
🗓2023年8月-2023年9月
【项目介绍】:RFID项目是团队2023核心战略级项目，期望将市面上已经非常成熟的RFID技术应用到实际业务中，核心目的是想解决类别图书盘点的效率和准确率的问题，同时提升物流间调剂和配送门店到货清点效率问题。
【项目业绩】:全程深度参与业务前期的沟通、外部技术服务商的产品研究、内部多系统的对接讨论。负责核心ERP部分的对接方案落地设计、DWS规格采集系统的对接方案设计，以及后续的产品验收、交付培训。有效支撑了门店盘点效率的提升，提高了门店库存的准确率，为后续门店参与线上发货提供了基础。

⭐️西西弗外部供应商首次系统集成
👨产品经理
🗓2023年3月-2023年4月
【项目介绍】:西西弗虽然具备了完整的供应链系统,但是与上游供应商的数据对接仍然存在断点，订单的报出、确认、发货数据还在延续专统的邮件、IM形式,一旦遇到采购高峰，就会形成严重制约于报订效率。另外，采购在途的监控始终存在空白,此次集成项目是首次与外部供应商进行系统打通尝试，为未来开放外部供应商对接奠定基础。
【项目业绩】:全程负责与三方团队进行业务沟通、对接方案设计、研发测试跟进，集成验收，业务交付培训。顺利支持首家轻餐饮供应商的自动采购报订、订单确认回传、发货回传、退货数据下发。

⭐️西西弗供应商管理系统研发
👨产品经理
🗓2022年10月-2023年1月
【项目介绍】:西西弗二十多年发展历史，供应商和采购规模增长迅速，但供应商管理、采购管理，两 重点业务一直是线下较为粗放的人工管理。作为供应链管理中重要的起点，制约着整个业务链条的供应效率，无法将价值数据进行沉淀利用。本项目研发独立的供应商管理系统，通过组织、标准、流程、系统等各个维度的构建和优化，来提升公司整个供应链的效率，以达到降本增效创收的目的，未来甚至会考虑将供应链能力输出给整个行业，让整个行业更加有序、良性地发展。
【项目业绩】:联合流程团队深度参与前期业务调研、流程设计。主导产品全程方案设计、研发跟进，负责产品全线验收工作、业务培训，联合项目团队完成实施跟进。业务上打通了采购的全链路数据，从采购需求到申请、订单、发货、收货、退货，支撑业务的有序开展及供应链数据的分析。另外对于供应商档案、价格管理均实现数字化，并和采购订单有效互动。

⭐️西西弗轻餐饮效期管理
👨产品经理
🗓2022年8月-2022年10月
【项目介绍】:西西弗餐饮业务在系统数据层面一直缺乏效期管理，导致数据实物错位严重，影响业务管理和生产安全。此次改造涉及仓配入库、库内管理、仓间/店间留流转、仓内/店内盘点、零售出库等，旨在进行全链生产日期 有效期的监督管理。
【项目业绩】:完成仓储管理系统WMS的三方沟通、改造方案设计对接、功能验收;完成wms与ERP对接方案设计，研发跟进、验收，业务交付;有了效期的链路数据，给大数据团队的管理数据分析提供有力支撑。

⭐️西西弗电商仓发货系统升级
👨产品经理
🗓2022年6月-2022年7月
【项目介绍】:西西弗电商仓上线初期业务量较小，仅完成订单层面的数据通路，仓内作业模式保留原B端的业务逻辑，当时主要目的为验证线上业务流程。经半年运行后，业务增长，仓内作业效率收到制约，主要受制于配货、波次、打单、拣货/二次分拣、出库复核等环节。该项目全线梳理以上业务痛点，进行系统改造升级，打造纯C端仓储模式。
【项目业绩】:完成C端逻辑下的供应链相关系统(ERP、WMS、OMS)产品对接及升级方案设计，实现收货人信息、快递信息有效下发仓库，支持仓内进行波次拣货、分拣、快递面单打印、复核等业务环节。同时支持了多仓发货的业务模型。

⭐️西西弗中心退货仓系统集成
👨产品经理
🗓2021年12月-2022年4月
【项目介绍】:西西弗全国十大物流仓较为分散，分别承担退货周期长、成本高，对于供应商的结算影响较大。根据核心供应商的地域分布，选择其中一个仓集中承担退货功能，并上线自动化分拣线加快分拣退货效率。项目涉及到外部仓储管理wmIs系统、分拣设备Wcs系统、自研ERP系统的三方对接，以及硬件的生产调试及实施。
【项目业绩】:负责三方系统对接方案的梳理设计，通过和三方团队的密切沟通调研，主导产研团队建立完整的系统对接知识图谱，快速对齐项目、开发、测试的信息认知水平。如期在2022年4月完成系统集成，为硬件调试落地做好准备。

⭐️西西弗APP对接库存中心
👨产品经理
🗓2021年10月-2022年1月
【项目介绍】:西西弗APP原独立运行，并未打通内部订单系统、库存管理系统、ERP,以“订单”为核心对象，处于游离状态。无法高效串联企业的订单、库存管理、订单同步、仓储发等环节。此次目标在于全链条打通线上订单的下单库存锁定、订单确认库存扣减、库存处理同步、仓库发货、售后退货等核心场景。
【项目业绩】:负责B端相关产品方案的全案设计,WMS仓储管理系统、ERP系统、库存中心中台系统共3个系统的对接方案设计，其中仓储WMS作为三方外采系统，全程负责三方方案对齐/实现。在2022年1月初全部落地上线，并负责对业务的交付。顺利实现APP业务仓库系统直连发货。

⭐️西西弗书店ERP2.0
👨产品经理
🗓2021年8月-2021年10月
【项目介绍】:西西弗原ERP11.0版本只具备库存单据、任务流转等基础的能力，书店和咖啡馆的业务是完全割裂的两套系统在分开管理，很难支撑未来公司业务融合的大趋势，也无法支撑线上线下业务融合的公司级战略目标。因此对ERP本身能力的改造提升和扩展性的考虑
就成为本次项目的核心目标。
【项目业绩】:2个半月内负责完成产品方案设计、方案评审，协同进行技术评审，跟进开发、功能验收和业务交付培训。

⭐️懒龟生活优选
👨信息产品经理
🗓2020年3月-2020年5月
【项目介绍】：2020年疫情后于3月份团队启动生活电商项目，定位是本地生鲜电商平台。通过原有旅游行业同业渠道资源，加上有赞的零售分销平台，对于疫情初期人们基本生活物资难以顺畅购买的现状，从而快速切入日常生鲜消费的市场。
【项目业绩】:深度参与项目前期筹划，负责项目对应的信息系统选型(微商城/电商WMS)、产品细节摸底/采购/功能测试/流程梳理/系统配置/上线培训/需求优化对接，保证了项目的时间窗口需求(14天从立项到商城开张），为项目提供了可靠的数字化支撑;

⭐️钢铁匣
👨信息产品经理
🗓2018年10月-2020年10月
【项目介绍】:“美匣云”是一套集B2B同行分销平台B2C微商城系统、旅行社内部管理系统于一体的旅游Saas系统平台，全方位解决旅行社产品货源、直客销售、同业分销、内部管理等难题。
【项目业绩】:完成前期业务逻辑梳理、用户需求整理分析、部分原型设计、项目落地；联合乙方完成产品2.0到5.0的迭代，为乙方对旅游业建模提供了有力支撑；同时组织团队顺利完成旧系统向新系统的迁移工作(数据迁移、培训落地、需求实现等)。最终实现团队业务数据的沉淀以及颗粒度的降低，为未来的决策做支撑

⭐️小强ERP实施项目
👨项目负责人
🗓2016年6月-2017年10月
【项目介绍】:旅游团队传统办公模式，没有信息系统辅助，内部信息单元流通效率低，存在大量纸质文档，业务管理、协作效率面临巨大挑战，同时线下流程导致的损耗不断增加。小强ERP是专攻旅游批发商环节的信息化经营办公系统。该项目主要完成了系统和团队业务模型的匹配、上线部署、个性化优化、集团内部执行标准落地。
【项目业绩】:负责整个项目的前期系统调研、公司需求匹配对接、落地实施、需求管理和持续对接优化;建立了标准操作规范，且在成都/武汉/长沙/北京多公司协助落地执行及规范推行。最终实现向无纸化自动化的跃迁，提升经营效率的同时大大降低了业务损耗。

2023年还在上一个团队，当时有一个产品设计，大胆抄袭了企业微信，把它的日程待办搬了过来。

业务背景如下：

为了给采购人员提供工具支撑采购业务跟进，第一采购订单创建之后的审核、报出、确认，方便采购人员跟进自己负责订单的审核情况、报出情况、供应商回复确认情况，确保订单的有效及时报出。也清晰看到已经完成订单的占比情况；

第二是发货的跟进，关注迟迟待发货的订单、等待门店收货的发货单，可以及时催供应商发货、跟进门店收货，监控门店异常收货。

功能层面终于上了心心念念的日历看板，采购业务产品本身也有较强的时效性诉求，特别是如今零售流通行业对于供应链效率要求越来越高的时代。

曾经一度也在纠结满足这个业务诉求到底用一种什么呈现才好，那种带有巨强时间属性的产品（比如：机票、酒店这种严格分布在时间线上产品）放在日历的维度是天然成立的，因为用户有心理预期就是对于基于时间的需求（我要哪天住酒店，我要哪天飞，我要哪天出去旅游）。

而这次对于采购链路的跟单过程也采用日历看板模式，则是将原来的一维信息升维处理，需要用户大脑对于一维信息的处理过程，在经过简单的组装之后二维呈现在看板上，让用户获取信息时大脑减少思考过程，达到的结果就是让用户觉得自然的发生。用户的业务数据采集过程，完成了对于业务闭环的数据沉淀，然后自然的享受数据带来的价值，提升驾驭感，这个时候用户不再只是数据的投喂工角色、同时也是数据的驾驭者。

这次产品引用的主要是：日历看板+待办，日历看板由用户投喂的订单、发货数据编织而成，待办由系统自动策略+用户添加组成，提醒落位到不同的日历天，用户需要做的就是在平铺的时间线上进行常规的数据投喂，然后让一切自然发生，处理当天待办、识别分析异常、采取业务动作。

产品设计过程中思路、交互、甚至视觉方案借鉴参考有什么大碍呢？

当然，我们构建产品的过程并不能从它处作为起点，最多只是参考信息而已。自己产品的构建过程一定是从自己的业务、用户、商业目标中生长构建出来的，我们要满足的是自己用户的目标、业务目标、商业目标。

上述的方案其实只完成了第一步，即底层跟办的数据、逻辑模型搭建，最多算是到达了框架层而已，表现层的空间还有很大，产品也在持续的优化演进之中。

“上周肝考试，这周肝项目”——2023.9

一周肝了 3 个外部协同项目，A项目 涉及到 3 方三角拉扯，B、C 项目分别涉及一个外部相关方拉扯。先说结果：A项目顺利进入测试、B 项目达到上线准备、C 项目捞底明确了问题清单进入外部协作方处理阶段。

A 项目涉及 3 方最为复杂，任意2 方都有协同对接任务，作为业务方 除了主导自己成员和外部 1 、外部 2 的对接，关键还得全程操心外部 1、外部 2 他们之间的协调沟通。明确核心逻辑，甄别关键任务，这当然是作为“串串”角色必须具备和秉持的。焦躁的表象下无非是各个相关方的不确定。这个过程惊奇的发现，基本的关键信息串联、看前后文，原来也是稀缺的基本功🤫更别提目标驱动了。舍我其谁？每每遇到这种情况，就有“让我来”的冲动行为。

B 项目、C 项目作为单一外部协作方，自然简单不过，简单的做法就是完全确保给他们正确的指令执行就好，心情好一些的时候科普一下场景，时间闲的无聊也可以给他们指导建议。

回顾学生时代、职场的一些经历，经历外部协作绝不算少，或许是这些经历、或许是不愿牵强，遇到极限拉扯总想拨茧抽丝一探究竟，找到真相、穿越迷雾。

清楚记得当年初入职场第一个工作任务，嗯…对，就是“任务”，boss让我和一个办公室老师一起接待工程勘察队员（工程人估计要会心一笑），个个肚子跟怀孕似的，带着他们大夏天白天一起钻玉米地，晚上一起去洗浴中心 happy。作为业主方角色，后续经典的工程5方关系拉扯不断上演。

后端有一段短暂的经历是当年酒店线上大战时，携程、艺龙、去哪儿、美团，都在搞酒店，去哪儿势头资本市场势头正猛，城市BD的角色就是要独立完成客户拓展/拜访/签约/拍摄/产品包装上线/销售跟进/产品优化，那会儿已经是996，今天啥时候来、晚上啥时候走就欧啦。这当中最拉扯的当然是酒店旅馆小老板儿，房价要拉扯、房型要拉扯、能不能多给签几种销售方式也要拉扯，最高兴的是第一次陌拜就签了一家满贯合作的酒店。

第二段时间较长职场经历中，用一张脑图协调过全公司近100人参与筹备举办产品发布会（参会规模在近千人）；一个人3个月跑4个城市驱动集团5家分子公司对标ERP实施规范；为了做细颗粒数据支撑管理和业务升维，联合筹备外部研发系统，内部和财务销售产品各部门拉扯，外部和乙方公司的产品研发测试甚至boss拉扯；这都还不算当时负责范围的各种外部厂商拉扯的（硬件的、软件的、服务的）…

大学也协调过全班几十个人，从学校骑车一路狂飙几十里到黄河边野外烧烤，炭——校门口烧烤摊让人老板帮订的、锅——一东北大姐火锅店借的、碗筷——都自己家伙事儿、肉/菜/馍/饮/油/料/刷——拉几个同伙逛附近菜超买的、串串——分给男女生宿舍晚上自己洗菜切菜穿芊的、自行车——自己的/借的/一拖一的/租的、灶台——黄河边石头摆的。狂奔几十公里，导航也没有，逢人就问路，可就是开心啊！四月春风草长、红花绿柳，一群傻二青年欢快的摆灶、生火、烤制、碰杯、爬树，比拼烤技、互相换吃，悬河边跑着打闹…

很多时候，我们经历了到了更远的地方，便也不会再纠结脚下的路。

对于极限拉扯无非几个关键点：

1、搞清楚自己的目标、大家的目标是什么，是不是一致的

2、搞清楚每个参与方的驱动来自于什么

3、识别关键路径、把握核心信息链路、用好关键人

4、进程中甄别关键任务、挖掘关键信息

5、带领/影响成员，穿越风险迷雾区，实现目标

最近切换成全键盘输入法，据说可以锻炼双手防止老年痴呆，赶紧来试试。

猛的一下是真的不习惯，从 2006 年接触第一款手机就是九宫格啊。当年如日中天诺基亚值班机的按键是真的经典，记得第一天到大学宿舍，有个老乡那九宫格的手速简直起飞，还给我们演示在裤兜里面盲打，牛皮大王。

但是体验下来发现全键盘的容错性和精准性是真的调教的好，我用的是微信键盘，感觉已经做到了区域识别，你就在键盘上大概的字母位置点上去之后就可以出来精准的短词或者长句，联想修正能力优秀。

想起来也是挺逗的，当初 qwerty 键盘就是因为技术之初打字太快容易机械故障，所以调整的布局可以降低按键之间点击时间。后来这种按键方式逐渐成为用户共识得以保留。现在我们又要效率和准确，不变的布局在不同的时代焕发新生。

这不就是典型的老瓶装新酒嘛！产品设计里面的很多经典设计早已打穿用户心智，我们在需要做的创新，不一定是改变他们，而是更新他们的内核。

这里有2个维度可以解释这个现象，首先从用户体验设计的层次来看，我们保留经典的已经形成用户心智的表现层、框架层，而去更新迭代突破更往下的资源、能力、战略层的内容，由此可以让用户在熟悉的认知里面感受到强大的生机。

另外从用户体验价值来单看表现层、框架层，如果新价值-旧价值-用户切换成本，还不如旧价值也就确实没有必要，往往仅凭体验的表层实现用户迁移概率也是极低的。

常见的搜索引擎的交互窗口时一个输入框，可以搜索文本、视频、图片、网站、音乐等等。
通常也会有一个分类导航：图片、地图、音乐、视频etc
足够简单的背后代表着足够复杂的逻辑。

不让用户走回头路，及时的发现错误并提示，同时也尽可能减少错误发生的可能。有些意识是用户的潜意识认知，也就是常识范围，我们认为的常识通常不一定会表达出来。
比如：我对一个同事说等你空了我找你核对一个需求；背后大概率对应的是工作时间范围内、工作场合内。不可能是晚上、咖啡馆。这是一种角色框架层的共识信息。

如果产品没有及时识别到共识信息，或者没有再正确的逻辑节点去识别，会造成最终用户体验的逻辑混乱。比如一个交互流程，最开始就应该定义正确的信息，放在最后提交做判断提示。就会让用户非常的不爽，甚至于愤怒，特别是这个共识信息如果是过程的依赖的话，相当于用户要推到重建自己的交易行为。那么这次交易就是失败的，如果是一个开放的场景，我们就失去了这个用户。就算是一个封闭的使用环境，我们也失去了用户对于产品的好感。

为自己的用户考虑，为每一个交易价值的实现和顺畅考虑，可见很重要。

交互即交易！！！#潜意识##ispiik小站#

范围即标的，是一个迭代冲刺的目标。围绕冲刺目标，通常会有匹配的：时间窗口、前后端开发资源、测试资源、运维资源、业务资源，同时会有匹配的协同系统协同处理方案、应急处理方案。当然，背后依赖的还有整个产品roadmap，再往底层其实是商业和战略规划。

 

范围的控制不论从风险、时间、团队信心哪个角度来说都是很有必要的事情（这里不谈绝对，比如突发的bug，不修复就要挂了，那没的说绝对是重要且紧急且马上就得做）。

1、风险控制：一个想要插队的需求，如果要做，不仅是开发、测试资源日历的问题。同时需要评估和既有范围的耦合度，其本身的相关方系统、业务有哪些，明确出来需求的地图边界在哪里。前面是进行风险的识别、评估，同时必须准备风险的应对措施，如果因为插队需求问题导致的诸如需要紧急

修复、回滚等，对原迭代范围的应急方案是什么？最坏的结果，如果发生了之后，还需要去做的就是持续的关注监控，避免次生的业务和系统问题发生，比如：系统和业务不一致导致的无效数据。关于风险，因为团队内分工的不同，会存在不同岗位角色的信息差，这里最好要有开发、测试、产品、项目、业务协同进行上述风险的预判过程；

2、时间：世上不如意之事十之八九，项目管理、产品迭代又何尝不是如此。人员请假、线上问题、bug暴露、老板需求都会挤压既定的时间规划。尽管我们在做迭代评审后，项目成员都会自己评估绝对的工作量，标记自己的deadline。尽管每个人都或多或少预留了一些buff，但是通常结果是，开发的交付、测试交付基本都会达到整个范围的deadline。不能说是团队成员效率问题，或许是deadline的标的成为了大家心理的一种暗示。所以范围蔓延通常意味着时间的不可控概率大幅度上涨。

3、团队信心：一次冲刺对于每个成员来说都是整装待发重新出发的一段旅程。大家有清晰的里程碑、有清晰的目标，过程中不断的持续交付并按照节点推进，最终达成一次交付。这感觉一定程度是可以刺激人的慢性多巴胺的，让成员充满信心、并拥有成就感和责任感；无控制的范围蔓延，会打乱成员的节奏，引起团队信心的打击，团队信心就像nba2k里球员的自信值，对于投篮命中率具有牛皮的加成效果。

每个产品经理成长过程中一定遇到过，加法的过程，我们想把一些小不点搭顺风车。不乏遇到由于评估偏差导致连累正常的范围。搭顺风车其实是件小事，但是需要背后评估分析的却是一套严谨的方法体系。

周期性波动意味着往复，很多人的一生大概率只能接受1个周期。生活中遍地可见，曾经的勇士…

某个行业曾经很辉煌，现在已经不行了，所以就被大多数人看衰。但是即便是衰退期，仍然存在波动，成长期时候供小于求，供给侧开始高速涌入，在成熟期趋于饱和白热化，直至供大于求。出现市场需求的相对减少，继而引发供给侧挤压，又会出现供给侧规模变小，跟随又回出现市场需求的相对增加。

在往大了看，就是经济周期的影响，可能是漫长的，5年甚至十几年、二十年。经济大背景下面，起迹-成长-辉煌-衰退-复苏-辉煌-衰退…如此不疲终日。这代8090绝对时眼睁睁的看着房地产行业从2000年左右到如今二十年的周期内，一路狂飙，盛极一时，而今又徘徊踟蹰后继无力。眼见他起高楼、眼见他宴宾客、眼见他楼不好卖了～ 当然这跟中国的城市化进程密切相关、跟中国整个经济的增长密切相关，但这就是周期。找到一块大路一路狂奔，越来越多的人加入，结果一定是熵增的过程。

周期的往复是一场长期游戏，属于有耐心的长期主义者。跨越周期找到非连续增长实现第二曲线的人，更是领袖人物。带领团队穿越生死线跨越周期，这样的人物在梁宁老师课程中听过。现实中还未真正见过、经历过，但隐隐有种感觉，现在的团队非常具备这种气质。