MVP&MAP
MVP（minimum viable product）最小可行性产品。
MAP 完成度低但是足够惊艳的产品。
还未做实际项目的时候，MVP对与我来说还只是一个产品相关的概念，只知道是一个法则， 并没有太多感受，但进入我司之后，发现难怪会被列为一个法则，是因为太特么重要了。我司核心业务系统折腾近3年，至今未上线使用，反而到目前需求还是在无止境的扯皮，而且看样子如果不进行产品研发策略的改进，在折腾几年依旧如此，陷入恶性循环。还在执行传统企业软件的思路，等所有需求都确认了才开发，且不说你这么多需求要一一确认要耗费2几年，那先确认的那些需求随着业务和时代的变化又进行了变化，肯定又得跟着变，这就造成了目前的局面，需求永远确认不完，业务方和产品组不断扯皮中。
如果使用MVP进行产品分期迭代开发，这事能简化不少。但是这是一个类似于披着互联网转型企业的正统传统体制企业，那么就这么折腾下去吧。
今天又看到MAP的概念，即现在用户已经被目前各种互联网产品培养出了对特定产品类型应有既定大概功能以及设计的固定思维，所以现在想要做好一款产品，不仅需要达到行业同类产品的功能、性能、设计的平均水平以上，还需要有足够惊艳的地方才能杀出重围，获得瞩目。但对于我们业务型产品来说，这个似乎暂时不适用，能保证功能上完成使用起来，不影响业务才是关键，其次才是更深层次的用户体验等惊艳功能设计。但不得不说，前端产品是后端产品的一个驱动，因为后端产品用户每天都在使用前端产品，对产品的某些功能设计就会产生思维定式，于是在使用后端产品就会带有这种定式，后端产品在设计相似功能的时候其实对与用户的教学成本就非常低，于是后端的设计会借鉴前端的产品设计。同样，由于用户的前端使用习惯的养成就会促使其在向后端产品提需求的时候要向前端产品功能交互看齐，进而推动后端产品的用户体验优化。当然，后端产品也得益于前端产品培养用户的思维以及不断将设计交互上的原则排雷，使其到后端这都是被前端验证后的可直接使用不会犯太多错误的。
