由移植亞馬遜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 …
這裏面的內容後續專欄介紹，歡迎關注。
總結時刻
作爲一名程序員，有時獨善起身並不是什麼好事。 對於需求評估階段和開啓啓動階段，如果只考慮自己部分的工作，沒有關注需求涉及的其他協作部門，有可能入坑的還是自己。特別是需求評估階段，有時需求也不是真正的需求，只有真正瞭解用戶是否需要纔是真需求。
亞馬遜的開發文檔確實起到一個標杆的作用，以後在其他的開發流程，也一樣可以參考實踐。文檔的目的不是本身，通過文檔輸出，提前推演產品開發上線階段的工作，能考慮到很多問題和細節，提升效率的同時，幫助打造真正符合用戶需求的產品。