1.不在开发过程调整细节的东西，先完成主体业务，细节放后处理。 

在项目开始执行的过程中，由于一些不可控的因素，需要调整一些细节。这个时候最好的做法是去记录这些细节，而不是直接进去排期，因为开发工程师有自己的节奏，很可能会因为临时插进来的需求扰乱正常的开发节奏与周期。就全局角度而言，项目过程的主体业务和逻辑是最为关键的，细节完全可以放在最后处理，抽出几个小时去处理所有细节是非常高效的事情~ 

2.给研发的任何东西都要十分明确，和质检员一样，负责人要把好关口。 

之所以会出现这种情况，根本原因还是不够细化！这也是我以前经常犯的错，后来我用了“最小单位”的概念，也就是以项目模块为根基，拆分到不能再去简化的单元，比如一个“头像”，罗列出所有可能出现的情况。这样的好处是会大幅度提升开发的进度，在需求和逻辑层面，不要让工程师进行思考。总之，不要觉得简单就不去做需求的描述和细化。作为产品经理而言，你的勤快与完整性是基本要求。 

3.基础的业务不要创新，符合用户习惯，快速实现。 

以前犯的最大的错就是业务的创新，比如简单的登录注册都能做得很炫酷，实际上，不要盲目做设计上的创意，创意的前提是效果好。实际上，千变万化的产品都有相似的功能和业务，对于这些而言，最重要的是符合用户的操作习惯，完成100%是非常难的，但做到80%以上还是很容易，而且大多数的业绩来自于此，剩下的20%实际上是锦上添花，不要在此浪费大量的时间。 

4. 把精力放一件事上，效果会很好，要做精益。

比如说我们这周的任务是去做订单管理，那么就不要去思考数据汇总业务，这并不是说没有全局思维，而是在一个周期内先集中精力做好一个事情。一旦分散，意识着每个环节都处理不到位，或没达到最好的效果。

5.项目上的问题及调整策略，需要让每个成员都知道。

项目实施中，信息不通畅是导致沟通不顺的主要原因，往往也会导致项目的结果不是所想。解决问题的关键在于信息的透明，比如需要让小组内的每个人都知道项目当前的问题和每个人负责的事项。项目负责人需要让群体做到心中有数，才会做到真正的无障碍沟通。

6. 层层把关，方案稿和设计图没任何问题再进入开发。 

大多时候，需求的改动是因为产品或设计的方案存在问题而导致，因此需要做校验。就像工程师在编码后，对功能进行校验一样，产品经理与设计师也需做到全方位的检验。否则，很可能因为一个细小的问题，甚至是一句文案的问题都会为开发节奏的顺畅进行制造障碍。

7. 设计的统一性。 

这里主要说的是设计师的要求。页面的设计和交付是同等重要的事情，项目的开发并不仅仅需要完整的页面，更重要的是统一性。比如同样的业务上，界面应做到图标、颜色的一致性。如果你的标注图与效果图有出入，就会导致工程师不知该去参考哪项。实际上，需要认真检验自己的输出文件，不能出差错。

8.保持产品的简洁易用 

简洁的本质是提高用户使用的效率，只要做的是服务类的产品，界面设计一定是易懂的，操作上也一定是简单的。去掉花里胡哨的设计和操作，让小白都能知道怎么去用。 

9.保持需求反馈的及时性。

如果项目开发的过程，发现发现业务也有问题怎么办，比如订单中少了一个状态……。我以前总是等工程师开发完，再去描述补充，以为就像加一个功能那样简单，实际上是非常愚蠢的办法。细节问题可以最后调整，但如果是业务逻辑的错误，一旦发现就立即说明。否则后期调整的成本一定是非常高的。

10.只做有意义的功能，不为开发而开发。 

这点很重要，以前做项目，还会犯的一个错误是因为不能让工程师闲着，会想各自新功能，甚至很多是没有必要的功能。这不但导致资源的浪费，也会导致产品的性能下降。实际上，还是需要多去思考功能开发的意义，如果某个时间段实在没有可迭代的，那么就可以让工程师留出空闲时间去完善产品的性能，或者提前了解一些新的技术。

这些原则是我在几个项目过程当中的总结，会作为我的警示灯，如果觉得有用，那么就按照相应的方式执行吧！