文章探讨了创新项目的轻量化站位选择的话题，并对轻量化展位进行了全方位的梳理分析，与大家分享。
公司里面喊MVP已经喊了很多年，也有越来越多的PM在践行MVP，我今天想聊聊MVP的前序环节。
轻量化我指的是你选择下手的位置，我叫他站位，是这个项目在整个系统中的准备放在哪儿，站位的不同需要解决的问题不同，MVP方案的设计和方案覆盖的范围也不同。
所以我们需要在开始MVP方案设计前，充分的想清楚项目的站位在哪里。争取找到轻量化的MVP方案，才能真正最大程度的做到“最小”&“可行”
02 选择轻量化的原则
我总结了4条原则共大家参考：
轻量化会降低很多系统层面打通的成本，团队协作的成本，调整的成本……所以如果有轻量化，近况选轻量化方案。之所以说尽量，是因为你还要做下面的三个判断。
2. 轻量化方案到完整方案是演进的关系不能是推倒重来
轻量化方案不是指临时方案，不是说验证了可行，然后推到重新从常规路径重新进行建设的方案。如果是这种临时方案，就违背了做轻量化真正追求最小、可行的初衷。并且会造成资源的浪费。
3. 轻量化的方案不会对其他的上下游造成严重的影响
轻量化站位站在哪儿要充分的考虑是不是会对上下游产生影响，会不会在这个点上看起来轻量化了，但是往更大的盘子看，对其他环节的影响的总和是不是可能比常规方案还复杂，资源占用还更大？所以，在判断的的时候，一定要在更高的层面做完整的判断，如果自己无法判断，就请相应环节的产品、研发的负责人参与进来。提前规避掉会对上下游造成严重影响的方案
4. 不伤害用户体验以及需求本身的目标
轻量化是站位的选择，选择不同的站位更多的是从系统层面出发，所以这一点写在最后却最重要，轻量化与否都不能以牺牲用户体验和影响需求本身目标为代价。存在这种代价的方案不能被视为合格方案。
1. 充分了解全链路产品方案及系统是前提
找到合适的最有的站位的前提是你需要对全链路有足够多的了解，一方面在于对系统的熟悉度，另一方面需要请更多的角色参与到方案的制定中，帮你找到最优站位；
2. 放宽视野，组织内部是不是有成熟的系统可以复用？
选择如何最轻量化，除了在系统层面寻找，还应该尝试寻找大团队内是不是有现成的解决方案，能不能通过共赢的利益分配的方式直接获得这些能力的使用权，特别是在大公司，很多时候解决方案有现成可复用的。
它山之石可以攻玉，用已有的成熟解决方案比自己造轮子快的多，也让自己少走别人走过的弯路。
3. 不要拘泥于现有的技术分工
团队中要建立“突破现状”的文化，如果打破技术分工的界限，可以让整个的项目成本明显减少，就应该去挑战打破，让项目站在最合适的位置上。当然第二点中提到的原则不可被打破。
做这件事要主动联动技术主动寻找更有的承接方案，要让技术合作方同样清楚的认知到分工是为了业务更好的发展而不是为了阻碍业务发展。
举个例子：
现在要为公司的商品分类做一套打标系统；整个系统从生产到销售有非常多的系统。这个分类标签系统应该做在哪儿？
在最前置的生产环节打标，是可扩展性最强的选择方案，但是需要打通到展示层面需要做多个系统的改造，投入大时间长；直接做在展示层的服务端，链路短了，时间和投入都降下来了，但是扩展性需要面对各平行不耦合的系统打通，实际是把成本后置，甚至后置成本还有增长。
该怎么办？一个完全解耦的可以直接服务于展示层服务端的标签系统如何？新独立系统与其他系统打通难度大概率比成熟系统间的互相打通要容易，而且纵向也不需要打通生产流程的太多环节？
再举个例子：
你公司的系统原本为简单层级的库存而设计，现在接入了一个重要的供应商，提供的产品库存结构比你现在的产品复杂。我们该怎么办？为一个供应商重新建设一套库存体系，看起来并不是ROI非常合理的事儿。
但是如果这个时候其他业务线有合适的库存接口可用，是不是我们只用开放入口，让商家在合适的地方上单，我们和提供系统的业务线沟通清楚利益分配，这件事儿就可以被解决~？用户的体验并不会被影响，上下游也不会因为接入新的产品类型而被影响。
启动标准的衡量各公司的规模不同，行业不同，项目面临的情况不同，所以无法简单的用一条线来界定，但是原则上的判断是：至少有多少参与，这件事才有尝试的意义，达到了就可以开动了。
这个事儿的意义在于我们要充分思考并排除那些无法达到边界的无效需求占用大量的业务资源，影响真正重要的项目。当然，如果无法达到边界要求却找到了充分降低成本投入可以快速尝试的方案，也不是一定不能尝试。核心还是在于避免无效需求占用大量资源。
以上是我对于创新项目站位选择的思考，最后附上我的大纲脑图，供大家参考。欢迎收藏、评论、关注、转发~！谢谢大家~~
