開發小結-產品類

本文總結了在開發過程當中，產品類的相關經驗總結。

開發心得之產品類

產品思惟是發現現有產品的問題而且描述清楚，轉化爲一個需求，結合上下游資源，造成一項任務，組織一批人將該任務完成，而且以主人公的心態去跟蹤，維護該產品。

在作需求分析時，能夠從業務角度去思考功能，一些非業務功能，好比性能、可擴展、可複用性、安全性、可測試性，在需求說明書中是不會涉及到的，這些非功能行需求，由開發來全盤掌控。

測試人員要可以從產品需求文檔中梳理出可行性的測試案例，若是梳理不出來，或者說對於完成這個功能的正確性有疑惑，那就要在需求評審的時候提出來。針對一個需求來講，作成什麼樣的，和作成什麼樣是正確的是兩個層面的思考。

要寫一份讓開發和測試認爲是完美無歧義的需求文檔，真的是有難度。需求規定的太細了，開發會揪住太細的地方逐個確認，以防理解有誤差。規定的太粗了，開發又會有疑惑，這個地方該如何作。無論怎麼說，需求是源頭，源頭有不肯定性，後面就會逐級放大該不肯定性。考慮到完備性，需求文檔中，除了正常場景下的業務流程以外，另外一方面，對一些錯誤和異常狀況下的業務流程，要給相應的解決方案。

一個需求的落地，是落地爲組成需求的各個功能模塊以及構成的功能點，開發人員根據功能點來開發，測試人員也是按照功能點來測試，而產品人員和最終人員是按照需求來體驗。從工做上下游價值鏈上來看，開發要"測試"產品人員提出的需求，肯定無誤後投入開發，測試要測試開發提供的軟件產品，肯定無誤後上線運維。而運維就在無時無刻測試"測試"提交的產品。

需求討論

在進行需求討論時，不要被細枝末節耽誤太多時間，分清討論的重點和非重點內容。關鍵業務路徑要儘可能達成一致。

當有任何需求不明確的地方時，須要將現有問題的現狀，預計修改後的狀況一一按照案例場景法描繪出來，而後提交到討論組裏面去，因爲這個問題相關的人員來一致決定在各類場景下該如何去表現，等到他們作出最後的一致意見後，再由開發人員去按照討論出的共識去，原模原樣的作出來。

在需求到解決方案的思考過程當中，不要考慮改動帶來的影響和現有工程中的已實現邏輯，要跳出現有的框架，努力從各個不一樣的方向去尋求不一樣可能的解決方法，最後綜合對比各類狀況，從而選擇一個最適合當前場景的解決方案。

解決問題的方法可能只是一小行，可是背後的思考和許多驗證類代碼是必不可少的。對於任意一個Bug修改後的性能、可擴展性以及影響範圍，要有本身的思考和判斷。對於產品經理提出的不合理的需求，要學會積極主動反駁，就產品功能提出本身的合理化建議。

每一個人都是產品經理，對於功能、需求、交互、UI和實現，不能只管實現已提出的部分，而不顧哪些被需求、設計人員忽略的特例狀況和異常狀況，從單純的實現角色轉變爲對本身負責的模塊、甚至是整個總體流程的理解和掌握。

不一樣安全級別的業務要作隔離，這樣作的好處是當出現緊急狀況時，咱們能夠將風險隔離在較小範圍，作後續處理時的牽掛更少。

動機評估

動機評估，下面從如下幾個方面開展：

• 目的分析
  爲何要作這個項目，或者說，咱們但願經過這個項目達成什麼樣的目的？

• 收益成本風險分析
  項目實現之後，可以獲得哪些收益？要付出哪些成本？有哪些實際或者潛在的風險？

• 效率分析,戰略分析
  如何在儘量少的成本和風險敞口下，能得儘量多的收益？
  上面提到項目能夠替換爲[需求、模塊、公司]，均可以按照這樣的思考框架來進行。

下面就一個具體的需求： 「將大型C++項目從依賴MFC環境下移植到Mac環境下」，進行分析：

1. 目的分析
   1.1 軟件的大客戶提出但願跨平臺使用
   1.2 軟件的衆多我的用戶提出跨平臺使用需求
   1.3 公司軟件產品將來發展路線

2. 收益成本風險分析
   2.1 收益分析
   • 鞏固現有大客戶關係，多收錢
   • 提高我的用戶忠誠度，依次吸引新用戶加入
   • 實現公司前進戰略
     2.2 成本分析
   • 全功能移植所需的人力成本很是高
     2.3 風險分析
   • 移植所需時間過長，致使用戶放棄跨平臺使用該產品
   • 若是移植後的產品質量沒法保證，會影響產品口碑，
     不只不會吸引新客戶，還會流失舊用戶

3. 效率分析,戰略分析

根據以上分析，要保證收益，減小成本，避免風險的核心在於開發時間不能太長，軟件質量必須保證，若是有可能的話，投入儘量少的開發人員。

通常來講，在軟件開發過程當中，開發工做量、產品質量和所需時間這三個因素不可能都要求完美，在有限的開發資源中，最多隻能保證二者達到理想狀態，所以，須要對開發工做量進行妥協。在軟件的具體使用過程當中，遵循8/2定律，在大多數時候，80%的用戶的80%的時間，在使用軟件中的20%的功能。據此，咱們須要選擇當前軟件產品中最核心的20%的功能，爭取在最短的時間裏，以儘量高的質量進行移植。

目標：在新平臺上，實現最核心的功能，若原有code base上的公用組件具有跨平臺特性，則可基於公用組件開發。不然，重新設計和實現，不用負擔過去的歷史包袱。

可靠性理解

理解一個系統的可靠性，這裏提供一個思路，能夠從反面來思考，當一個系統由於某種故障致使沒法提供服務時，咱們就說系統不能可靠的處理這類故障。或者說，若是系統可以處理這類故障，那麼能夠認爲，咱們的系統對這些故障是可靠的。

不一樣故障發生的可能性，有高有底。下面從高到底列出典型的故障狀況：

1. 應用程序代碼有漏洞
2. 系統組件有漏洞
3. 消息隊列溢出
4. 網絡臨時中斷
5. 硬件系統崩潰，致使全部進程停止
6. 網絡出現特殊狀況的中斷，例如某個交換機的端口發生故障，致使部分網絡沒法訪問
7. 數據中心遭遇雷擊、地震、電壓過載、冷卻系統失效等。

小結

每一個人都是產品經理，而產品就是本身，要在本身的崗位上作出最極致的產品，對待本身的代碼，就要像對待本身的小孩同樣，看着它從弱小、不完美，一步步的更加可以適應外部變化，響應外部變化。