没有什么虚头巴脑的开场，我们直奔主题：
自我修养的目标：不加班，且让全团队不加班。
不加班的关键手段：提升人效。
提升人效的方法：
首先，调整心态。
这里主要是给年轻PM们的建议，主要是之前遇到过很多同学业务不够明朗、找不到正确方向尤其是看到别人“如火如荼”的时候就会陷入焦虑，如果焦虑的同学选择“卷起来”那就会产生杀伤力极大的影响：盲目堆砌没有深度思考（且底层逻辑浅薄）的项目。
为什么说杀伤力极大，这种行为一方面对研发人力会产生极大的浪费，另一方面会导致业务臃肿，冗余功能过多且可维护性差，到了业务中期会成为进一步上升的巨大阻力。
因为杀伤力巨大所以只让年轻PM们自律解决并不科学，对高阶PM们的要求则是一方面需要传导正确价值观帮助团队调整心态；
另一方面则需要飞速依靠靠谱的方法论把不明朗变明朗，找到合理方向并逐步落地。
所以，
第二步，调研。
合理有效调研可以显著提升项目成功率，当我们把失败的项目都尽量干掉以后，那些为失败项目浪费的时间精力可以用来早点下班追剧或者写文投给知识库赚稿费。
但是调研本身需要充分注意：交调研作业≠完成调研。
这里比较扎心的说一句，不扎心的调研不是好调研。
翻译一下：如果调研顺畅的给出一份结论是“我们的idea是天选之点，经过一番调研之后我们一定能成功且收益blablabla”，这就很交作业。顺便很主观的评价一句：存在较强不确定性且成本较高的需求，PM调研周期一般不建议低于正式开发周期（当然，低成本测试也算调研）。
今年是2022年，互联网诞生的第52年，中国接入互联网的第27年，百度都成立22年了，有什么看起来“天选之点”的项目不是有坑就是有坎。
所以调研的关键任务是：
1.风险考察-找到可以能搞死自己产品的不确定因素
2.切入点选择-找到成功率最大的点
哦对了还有个前置条件，需要先有个产品基础框架，不然调研就会很发散。
基础框架有个非常简易版的做法是：基于场景预期做好的产品说明书。
当风险和可预见巨大前景并存的时候，是最值得期待的过程，因为
有前景/钱景+有麻烦=你的对手和你一样要翻山越岭。
卡掉他们没卡掉你，你赢。
为啥会卡掉别人卡不掉你是一个完整的值得论证的过程，因为包含SWOT在内的一系列成熟分析方法都可以参考，本文不做详述。
当然极强的控本能力也是优势之一，被成本卡掉也是卡掉。
说回到调研，风险点可以是我们的不可控因素、也可能是攻坚风险、也可能就是市场的不认可（对于创新项目，这一点极为关键），在充分罗列风险并根据调研进行完“我们有希望解决”的论证后，仍然会有不低的比例发现对于风险点，我们还是“前途未卜”。
那么这时候，我们需要进入
第三步，规划。
规划是控本这一步真正的核心环节。
既然在这个行业日趋成熟的时代挑战钱景项目，就得有失败的觉悟。
规划在控本的意义在于：
1.拆分阶段
2.根据阶段定位当前阶段的-使命、目标、衡量标准
3.根据阶段的使命、目标、衡量标准确认-关键项目、关键指标、风险及对应预案
根据以上所有，在特定时间进行review：此事是否进展正常？
Review结论可以分为以下几种
1.顺利
1.1完成目标->向下阶段正常继续
1.2超预期->调高目标？加码提速？
2.不顺利（没达到目标），这就相对复杂一些
2.1 目标定的有问题，这里的问题又分：
a.阶段拆分不够细，需要中间环节做过度=>那就增加中间阶段即可
举个栗子，某个垂类平台打算做内容生态，开始拆分的中间阶段是创作者提供内容获得的pv，下阶段再看内容转化，结果中间阶段发现pv卡住，那么细拆之后可能需要先保障其中某N个（建议<3）关键引流渠道的覆盖，保障关键渠道覆盖拿下后，再往实际pv引。
b.目标本身就搞大了，这里的目标可能是数值定高了，但也很可能是产品主体摊子铺太大了=>直接收拢重心，单点打透（当然产品规划和设计需要保障延展性）
还是刚才栗子，某个垂类平台打算做内容生态，开始拆分的中间阶段是创作者提供内容获得的pv，下阶段再看内容转化，结果发现创作者搞了一堆乱七八糟的形态效果千奇百怪，这时候可能需要聚焦到某个内容形势（图文or视频），甚至聚焦到少数垂直创作主题。
c.选了不合理的指标，这个如果明朗就更简单了，直接换指标就好
2.2 目标没问题
那事儿可能有问题
其实很多喜欢深入思考的PM在认知逐步加深的时候，常常会对自己的业务有一些灵魂拷问，我做的事情对么？我的方向对么？这个事情到这一步似乎发生了一些不合逻辑的现象，这合理么？
没有灵魂拷问是个很危险的状态，很可能是自己陷入了给自己编织的美好构想，到了死胡同里腾挪不开之后才不了了之。
避免这个问题出现的最好方式除了一开始做好充分心态建设、调研（主要是先自觉扎心）之外，还需要诚恳的接受负面意见。
“你好，你怎么看待我们做的事情？”
这里的角色可以包含用户/客户、项目深度或浅度参与的研发运营及其他人员，倾听其他人的所有灵魂拷问然后自我确认这些问题是否可以很好回答。
这里当然不是要当场解决问题（能解决当初就不用规划拆阶段了），而是去自我review下业务的底层逻辑是否有问题，终极目标可以遥远但不能跑偏，一旦业务底层逻辑正义性出现问题那就不是拆阶段能解决的了。
底层逻辑真的不对->收摊换方向
底层逻辑没问题->可以认为是客观/主观因素导致拿不下关键目标
这里的因素就千奇百怪了，比如投入确实还是不够高、时机未到、技术瓶颈、协同线条节奏没跟上等，可根据项目情况自拆。
然后我们就要扣个题了，本文主题是降本增效，通过一定周期论证事情成功率有问题的情况下，就不要耗着，需要开始迅速组织应对方案。
1.减投：保留少量维护成本，相关功能入口隐藏，减少投入‘
2.冷藏：直接暂停项目，相关功能做下线处理，保留有价值数据、机制（和背后的代码）
实际操作中大家会感觉“减投”和“冷藏”的过程都很痛苦和抗拒，核心问题在于规划阶段实际上缺少这部分的考虑，阶段性功能完成度差，起线条的时候缺少对后续维护成本的计划，看似“减投”实际后续维护修复压力巨大。
这里可以做个简单的业务自查-你的项目是否可以以低成本方式减投/冷藏：
1.触达群体范围较小（<1%)
2.业务复杂度不算很高（或大部分可剥离成为可复用能力）
举个例子，偏C端功能如果有展示一些数据、字段是采用不太需要动态维护的静态数据，还是需要动态高频更新的接口？后者维护成本就会高很多。
3.是否在时机成熟的时候可以方便重启进入优化状态
第三条是减投/冷藏显著区别于坠机的状态，因为我们仍然希望有朝一日，这些当初的项目可以等到
特殊的时候，资源整合。
回到起点，控本很重要的一件事是杜绝浪费，除了杜绝自己业务线无谓消耗的时间之外，从前辈的库存中沙里淘金仍然是一件值得投入精力的事情。
以我个人为例，在百度这样的大公司，花费一定的时间去找前人的文档，或者干脆去找前辈面聊获取经验，是可以获得大量惊喜的。
更不论项目组在之前一段时间的积累中，最终也许会沉淀一些宝贵的可再利用资源（前提是前人是冷藏而不是坠机），所以，PM不是项目堆砌着，而是为产品和业务负责，去内卷时代的PM整合能力极为值得看中和拔高。
当然，很多前人也许会有一点淡淡的忧伤，被后辈继承的财产，和自己又有什么关系呢？明明自己想要的是眼前的收益啊。
这里我的观点是：如果这个事情是底层逻辑正义的事情，或多或少为自己和世界也是带来价值的，不能摘到果子，至少也曾经欣赏过开出来的花呀～