由移植亚马逊SDK引发的思考
Amazon 提供的云服务产品公认的世界领先，特别是在文档的输出方面，详细到令人惊叹。 网上流传着一个帖子，亚马逊CTO介绍开发产品的流程是这样的：
- 写新闻稿
- 写FAQ (常见问题解答)
- 写用户文档
- 写代码
这种以终为始的产品开发流程确实让人耳目一新，这也难怪亚马逊的产品能做得这么好，开发文档写得好就更不用说了。 在这当中我们可以学到产品开发流程，那就是做事情之前先推演，先考虑达到目的时刻需要些什么，再反过来想现阶段需要做些什么。
非常荣幸，我所在的公司就是亚马逊服务的系统集成商， 所以有机会真正开发集成由世界级云服务提供商提供的SDK到产品中。
产品开发过程
就拿我集成亚马逊AVS SDK的需求为例。
借用高人的说法，把实现这个需求的产品开发分几个阶段，迭代0， 迭代1
…
迭代0
对于迭代0 ，也就是对应于需求评估阶段。在这个阶段，我们需要对AVS功能做详细的了解，在需求方面，这个功能适合用户的群体是？集成这项功能后能给用户带来什么？在技术方面，集成这个功能要对使用硬件平台的资源的要求，app和后端的工作有无风险性。如果有出货的产品，也要考虑兼容性和生产流程的变更。
在这个阶段，我负责调研公司F平台硬件的对这项功能的支持情况。打开亚马逊开发者网站对应的SDK 说明文档， 一看目录，里面关于AVS功能介绍，SDK集成的开发指南，app和后端开发指南，生产，认证指南。 上面一清二楚。于是也就有了我开篇的感叹：亚马逊的文档写得真是好。
AVS开发文档
当然在需求评估——硬件资源调研阶段，我走了不少弯路， 总结下来，就是没有做到以始为终，明细目的。
比如说，SDK有介绍集成所需的硬件资源，比对RAM, FLASH的大小支持。由于目前F平台正常工作时RAM剩余的资源不能满足SDK集成要求，所以我一开始把时间花在如何在压缩现有功能使用的资源上， 看来看去，最后发现挤牙膏似的也不能挤出资源满足要求。于是乎敲定结论：现有硬件不能满足要求，有很大风险。
但我心有不甘，后面在多次详细看完文档，才发现这个功能的使用场景和时间上并不会与现有的主体功能有资源上冲突，硬件资源是能满足SDK的运行要求的。 于是乎结论就反过来了：现有的硬件资源能满足要求。
可见，抓住目的了，才能高效的开展工作。
迭代1
这个阶段对应的是需求细化的阶段，需要细化到各协作部门可执行的程度，同时要有验收标准。
在这里，我推荐使用“用户故事模型”。 这里最好的参考就是亚马逊的开发者文档了。
从文档中，我们可以详细了解到这项服务是什么，适合什么样的用户群体，能给用户带来什么体验。关于技术开发上，集成的详细流程是什么；关于生产认证上，需要做的事情有什么。
在梳理完这个用户故事后，我就可以知道各协作部门需要干些什么了。同时最重要的是，需要把相关人员召集起来开会，分享关于这个功能的介绍和工作内容，讨论提前记录在在线文档的疑惑点。在这个环节能帮助确认未来产品开发，上线需要注意的风险点。一方面要好让产品经理能提前与客人沟通；另一方面，制定验收标准，排定可交付计划。会后输出会议记录方便落实计划。
迭代1的后续，迭代2 …
这里面的内容后续专栏介绍，欢迎关注。
总结时刻
作为一名程序员，有时独善起身并不是什么好事。 对于需求评估阶段和开启启动阶段，如果只考虑自己部分的工作，没有关注需求涉及的其他协作部门，有可能入坑的还是自己。特别是需求评估阶段，有时需求也不是真正的需求，只有真正了解用户是否需要才是真需求。
亚马逊的开发文档确实起到一个标杆的作用，以后在其他的开发流程，也一样可以参考实践。文档的目的不是本身，通过文档输出，提前推演产品开发上线阶段的工作，能考虑到很多问题和细节，提升效率的同时，帮助打造真正符合用户需求的产品。