在接近三年的开发生涯中，做过了不少项目，但发现个人能力的成长上确没有达到自己所期望的程度。不能说自己不够努力，细细想来，每天都处于忙碌的状态。但是是否处于一个高效的工作状态，在开发中处于良性的循环？在产品开发的过程中，注重的仅仅是完成开发任务，还是关注产品的性能、架构以及代码的质量？在这些方面，就做的相当差劲了。

当然，作为程序员，这些方面都是我们应该关注的，毕竟这对个人的职业发展是相当重要的。但这只是个空口的希望（这句有点奇怪），现在的互联网行业中，产品的开发是处于快速迭代的时期，需求的不断改动对开发工作带来很大的影响，使我们的效率大打折扣。怎样使产品开发更加高效，质量更高，同时保证程序员对产品实现有着更深入的思考？ 这便是作者思考尝试解决的问题，应该从以下几个方面做起：

1. 流程划分

清晰流程，详细的交互设计文档以及后台接口基本提供完善，才可进入App开发的阶段。我们在App开发的开始，是需要针对设计交互文档确认过，细至每个细节的交互都了解；开发过程中，可能产生的一些交互问题，都应该在交互文档详细地体现出来，做到一切有迹可循。程序员在开发过程中不再有模糊的交互，不再有口头上的交流，是我们在文档最终定稿应该达到的理想效果。需明白，在开发过程中，口头交流来确定交互的实现，对开发效率都是大打折扣的，出了问题，我们都是没法责任到人的。

这样，就要求在前期设计交互文档的人员的责任比较重，需要针对每个细节的实现都要考虑清楚，产品经理在对一个新的迭代的开发的同时，需要明确提及到这个迭代中的会涉及到的交互的实现。人无完人，不能各个层面都涉及到，所以在这个期间，可以让程序员加入来讨论，毕竟最后的实现是需要程序员来完成的嘛，有问题的过程再确定重新形成方案，必要的时候，可以给与程序员一定的调研时间，当然考虑地越多，意味着我们的工作将能够更加地明确。

清晰地可以看出一个版本的开发将会有两个阶段，阶段一 需求的定义形成设计文档，主要角色有产品经理、产品设计、产品交互； *阶段二 * 程序员进入开发阶段最后交付完整的产品。此时，我们可以让下一个版本跟当前版本做一个简单的交错，即在阶段二中，产品进入下一个版本的的需求设计阶段，借此来并行地保证各个部门的高效工作。

虽然看起来在操作过程中，可能会遇到不可料想的麻烦，毕竟没有一成不变地需求，这样就需要产品经理权衡，尽量将这些需求放在下个版本中，将是最好的方式。不然交错地流程开发，带来更多的是开发成本的上升，产品的迭代周期的延长。

2. 规范定义

界面设计、接口设计、App设计定义一些通用的规范。 + 接口设计需要对返回的数据进行统一格式。譬如：统一返回的是 JsonObject，其中包装成功状态result 以及错误的信息，真正的数据则统一放置在 data 字段中进行处理。 + 界面设计遵循设计规范。 Android 可以选择 Material Design，苹果也有自己的设计规范。若是不采用这些，则需要对一些通用的样式，做些统一定义，譬如常有的间距，弹出框样式，常用的颜色值，字体大小等等。这样客户端也可针对这些定义，遇到的时候则可直接使用。 + App开发的规范。统一的命名、格式化文件标准、尽量清晰的处理逻辑、类文件编写。

定义规范，即多做约定，最直接的好处就是：多人员协作能够有一套的标准，不至于杂乱无章。

3. 角色明确

这一点在小公司可能不太清晰，经常出现一人兼多职的情况，不太好定义。在成熟公司，这一点是相当重要的，因为角色到人，使得我们可以精确到单一问题该有何人负责。若是一个团队中出现职责不清晰的情况，使得我们解决一个问题便会出现踢雪球的情况，问题得不到解决，雪球还有变大的可能。

4. 产品至上

产品是最最最重要的。最终的成果都是拿产品来说话的，即使再牛逼的销售团队，再漂亮的设计到产品上，也经不住产品的不断闪退，卡顿，高耗电，不人性化。而这最终的成果的展示都是在程序员身上，产品的优化又是一个任重道远的过程，毕竟你产品经理还要加功能。所以应该以程序员的工作为主，API设计以及UI团队应配合甚至服务于程序员的工作，尽量保证程序员能够高效地工作。遇到过App展示一个界面，要发送三个甚至更多的API请求，只想说真是够了。所以这里应当简化App端的工作，能尽量少在客户端做的就少做，服务器端的改动肯定比客户端来的容易些。

总结

作者是站在一个程序员的角度上，以及要不断迭代地去开发一款长周期的产品，来看待产品开发应该具有一个怎样正确的姿势的，欢迎来拍砖讨论。当然，如果你就只是想快速开发出一款产品，那我上面的都是瞎扯淡了。。

PS

这里感谢Jaeger大神的审阅，并提出的修改。