第一阶段：计划与定义：
Planning and Definition
· Product Concept Proposal (M0)
· Design Inputs - Integrated Design Plan (M1)

第二阶段：设计开发与（内部）验证
Design Development and Verification
· Evaluation Release (ME)
· Release Components/Parts (M2)
· Design Verification (MV)

第三阶段：设计转移（这个不会翻译）与（外部）验证
Design Transfer and Validation
· Sales Announcement (MS)
· Product Validation & Release (M3)

第四阶段：产品生产和商业化
Product Release and Commercialization
· Unrestricted Production (M4)
· Product Vitality (M5 - Periodic Review)
· Decision to Stop Sales and Production (M6)

第五阶段：产品退市
Product Retirement
· Communicate End-of-Product Life with Customers (M7)
· Decision to Scrap Spares (M8)
· End-of-Product Data Management (M9)

只要是一个新的产品线，无论大小，都要经过这5个阶段，但并不是说要经过所有里程碑。因为要是所有里程碑都要经过，有点太费体力。
但是就算减少几个里程碑，事实上每个里程碑里的子里程碑也相当给力，全部走完也是一件不容易的事情。所以在实际执行中，里程碑的子里程碑也要根据实际情况进行裁剪。
所以在有些产品的开发起始阶段，先要来两剪子，以切合实际产品特点，以最少的投入得到最大的回报。
曾经有一段时间，公司感觉这13个里程碑有点太彪悍，投入大，周期长，产品出来还不怎么样，所以根据先有流程，另提出简化版的，称呼为Lite。但经过几个项目的开发后，发现这个流程其实也不怎么省事，在产品质量控制上也存在问题。所以就放弃了。
但有同学可能关心，如果是不大不小的部件（Component）开发怎么办，难道也走这个流程？实际上对于Component的开发也有在上述大流程的管理下的一套流程。在这里我们就不多说了，因为第一，限于篇幅有限，第二，我个人也不懂这个流程。

比如，现在有个新产品要进行开发，为了简化开发过程，现在给你两把剪刀，怎么去用？
得有个原则，在上述的流程中，有以下几个原则：
1. 5个阶段13个里程碑中必须的执行的，不可剪掉
2. 每个里程碑中必须的子里程碑，不可剪掉
3.如果非要剪掉某些不可剪掉的子里程碑，也不是不可以，就是需要一袋烟的功夫：开村民代表大会（这个会非常重要，以后会讲到），大家都举手投票，要全票通过。
4.如果不能全票通过，就不能裁剪。
5.如果非要通过，但不是全票通过怎么办，还是开会，有几种办法：
A。项目经理做主，下决定，讲明要通过的理由和责任，然后开会，做会议记录，然后正式发布出来，要求大家都来批复通过
B。通过会议，采用群殴战术，大家一起说服这个不识相的同学，迫使其举手
C。潜规则。。。（这个里面讲起来战略战术方法就多了。。。。）

基于上述的原则，一个产品开发的整个流程就确定下来了。

可能有些同学觉得这个过程实在有些不靠谱，浪费时间，而且明显有些扯淡的东西在里面，到底是为什么呢？

我个人觉得有以下几个方面的原因：
1.在这个企业里，质量是第一的。比如，如果遇到一个项目或者新机会，得到的回报很大，但质量方面存在一丝的风险，该企业的理念是："I would like to go way other than taking the risk that can not be avoided"。就是说，如果风险不能回避，那咱就不做了。但如果不做，岂不是挣不到钱了？这个企业的一些老鬼老妖精的看法是，我们有钱，玩的起，等上一段时间也没有关系，等到有人在这个地方跌倒了，我们也找到方法，再去把他们的钱抢回来。
2.外企对每个人的职责定义是比较清晰的（但也不是很清晰，含糊不清的也不少），尤其是在产品开发流程上，规定是相当清晰，所以每个人都必须为自己做的事情负责，也要为团队负责。作为项目经理，在向前走的每一步之前，必须统一团队的意见，达成共识，发现风险，消除分歧。
3.对于每个项目成员，一般情况下只有某个决策设计自身的利益，或者说威胁到自身，他才会跳出来反对，只有他不是脑残，不是神经病，和他不相干的事情，对自己没有利的事情，他不会如此倔强的反对。当然对于愤青类的同学不在这个范围内，遇到这种同学，潜规则是必须的。
4.在这个企业里，在人员招聘时，有一点必须的要求：思路清晰。所以思路不清晰的愤青分子就被滤掉了大部分（外企的招聘过程还是比较规范的）。然后在成立项目组的时候，思路不清的漏网愤青一般也很少能够被选为村民代表，所以第二层又过滤掉了一部分愤青。如果确实有潜伏时间很长的愤青怎么办？那只能说你活该，愤青会武术，谁也挡不住。（其实还有办法，就看你想的出来不）。
综上所述，剪刀的使用办法是：
1.遵循基本原则
2.采用民主集中制
3.理论与实际相结合
4.在不影响质量的前提下
5.在保证合理的资源投入下（这点没讲呢）
6.裁剪出一套流程来

当然有些同学不同意这种看法，也没关系，反正不是我分析的，想骂也骂不到我。

上面讲了这么多，想表达的是针对用户，在满足基本需求的基础上，要把握用户的核心价值，进行差异化竞争，才能开发出一套值得去开发的产品。

无论有多么神奇、多么严谨、多么高贵典雅的人才、技术、品牌，如果用户不认可，不能给用户带来好处和价值，是没有用的。

但是这个和解决产品开发Delay的问题有什么关系呢？我觉得1，有关系，2，很有关系。

好了，先喘口气，歇歇，然后回到正题上来，看看我们面临的问题：
1.产品开发时间的Delay是不可避免的
2.市场变化总是比较快的
3.资源总是有限的。
我们现在的思路是从市场入手，看看有没有好的办法。我想到的第一个办法是：
尽量把产品开发时间定的长一些，比如大家都同意我们开发产品需要18个月，而按照国际惯例，所有产品开发的周期会Delay80%，那我们就更极端一些，按照100%的Dealy估计，制定一个36个月的开发计划，然后给Stakeholder留20%杀价的Buffer。
这样行不行？我个人觉得行。
有没有现实的例子？有！
成功没有？成功了！
最后用户认可了没有？认可了。
那到底是什么呢？
下面我就说说我看到和听到的。

M0的主要目标有三个：
1.定义满足用户和公司本身Business目标的：市场需求和产品概念
2.在产品级别，定义清楚主要的功能特征，对这些功能特征进行优先级设定，并与客户的需求对应（就如前面说的三层类马洛斯模型）
3.识别项目风险

你想生个娃，就离不开女人。同理，你无论想做什么样的产品，都离不开市场。离开了市场，不是说你生不出娃，不过生出来的娃可能是个好娃，就是没人要。

记得我原来做工程师的时候，当时我心高气傲，采用了一个比较牛逼的图像算法，对原有图像进行了处理，最终的图像看起来很漂亮。然后就拿给用户看，用户看完了之后说：
1.你的算法确实很牛，虽然我不懂，你能把一个东西变得看起来知道原来可能是个什么东西，但仔细看又好像不一样
2.你这个东西我没有用，我需要看到原图的信息，不需要美化处理，你这么一搞，把有用的信息全都搞的不清晰，我没法用来做判断
3.你能不能做点正事？给你的产品设计一个功能，可以把图像另存到本地硬盘上？这个事我好像给你说了两回了耶？

伤自尊了！彻底伤自尊了。
其实道理很简单，别人就是想在街边小店吃个窝窝头，喝点稀饭，你非要把人家搞到大酒店给人家吃鱼翅燕窝，喝人头马，你以为别人会领你情，其实人家早就烦的不得了：糟蹋人也没有这么糟蹋的呀？
所以说第一点一定要是满足用户需求，知道用户想要什么。（事实上我们很多同学在做项目做到一定阶段就把这茬给忘了，这种例子是天天都能看到）。

第二点是你自己要搞清楚自己的目的，你去满足用户需求的目的是什么？是因为吃撑了，没事干消消食，还是因为昨夜独依寒窗，听雨声，菊花微痒？
我相信大多数情况下这些都不是理由。
比较拜金的理由是出卖脑力、精神和肉体，满足客人的核心需求，从而获得金钱上的回报，从而能够有机会坐在宝马里面哭，而不是骑在自行车上笑。

比如说，你作为项目经理带领一群人开发产品，加班加点，被老板骂，被客人搞，最后客人总算满意了，买了你的产品，然后你就有项目奖了，职位提升了，老板给你配车了，你自己也买车了，然后你包二奶了，你就开始笑了。

综上所述，M0的第一个目标是要搞清楚别人想要什么，你自己想要什么！

M0的第二个目标：
今天咱们就把这事摆的清清楚楚！