2013-4-10 藍藍設計的小編
轉載藍藍設計( www.ocunn.cn )是一家專注而深入的設計機構 ，為期望卓越的國內外企業提供有效的 BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
來源：http://www.woshipm.com/pmd/20677.html
如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里
[核心提示] 我們時常聽到許多產品團隊提到“小步快跑，快速迭代”，但它到底指的是什么?對此不了解的同學可以看看這篇文章。 今天在微博上又一次看到有人轉發小馬哥的：“小步快跑，快速迭代”理論，剛好鄙人近期收集了一些快速迭代的資料，接下來結合自身的經驗來淺談產品的快速迭代方式。這篇文字可能會偏項目管理一些，不過我認為項目管理也是產品經理基本素質之一。 關于立項 這一點相信大家都不陌生，每個產品在經過 BRD、MRD (當然，這兩個過程并不是所有產品經理都能參與)之后，就會進入立項階段。在傳統的立項過程中，我們更多的是走流程，項目負責人提出立項申請，項目組進行可行性討論分析，然后召開大會進行立項評審，負責人根據評審結果進行相應修改，最后再召開一次轟轟烈烈的項目啟動會。而快速迭代的立項方式沒這么復雜，基本上 10 分鐘之內一頁幻燈片就可以確定，一般會闡述這么幾個問題：我們為什么要做這件事?有沒有更重要的工作要做?項目完成的標準是什么?項目的風險點在哪里?只要項目組明確了這四個問題的答案，是否立項就可一目了然。 現在大部分互聯網公司都有開晨會的制度，在快速迭代的產品管理模式下，晨會首先必須是站立式，以此保證會議的簡短、，一般情況下團隊的每個人都會逐一描述三大問題：昨天做了什么事情，今天要做哪些事情，在工作中遇到了什么問題。在會議中產品經理應該重點關注兩個方面：其一是昨天工作是否真的完成，這里所說的完成不是代碼寫完了就了事，也不是自測沒問題了就是完成，所謂一個任務的完成應該是真正意義上的完成，即滿足用戶需求，可立即部署到真實環境中進行使用。我見過太多的工程師口口聲聲說功能已經完成，但最終部署到服務器上依然需要經歷大量的聯調測試，然后看著你說：“在我機器上是沒問題的”。其二產品經理應該重點關注團隊成員在工作中遇到了哪些問題，并想辦法通過團隊其他人的力量幫助其解決，這里我提到的是其他人而不是產品經理，產品經理在這個過程中應該培養團隊的合作能力以及成員相互配合解決問題的成就感、信任感。 關于過程優化 在產品快速迭代的過程中，有很多地方需要產品經理進行主導優化，讓我們來列舉幾個例子： 思想優化。在開發過程中一定會出現研發人員的意見與產品經理、交互設計師的意見不一致的情況，因為從人性的角度分析，每個角色都一定會用自己慣性思維去思考問題，比如工程師會告訴這個 Banner 放在左面程序運行效率最高，而交互設計師認為放在右邊會更符合行為習慣，產品經理則認為放在更上方一點會換來更多的點擊率，此時產品經理一定要引導大家站在更高層、更客觀的角度去尋找解決方案。 代碼優化。這一點更多的是指代碼 review，一般會采用每天團隊成員交叉 review 和每周團隊一起進行重點功能 review 兩種模式。有句話叫磨刀不誤砍柴工，代碼 review 是發現潛在 BUG、發現功能偏差的成本投入。 文檔優化。推薦使用類似 wiki 的系統來統一管理產品文檔，產品經理在寫文檔的過程中不要因為怕麻煩就降低文檔的可讀質量，要知道產品很有可能因為你少寫幾個字就走向了另一個極端，很可能就因為這幾個字，工程師就需要返工，這也是為什么大部分工程師都想暴打產品經理的原因所在。因此產品經理在寫文檔的過程中應該多以工程師的視角去寫需求，如果你是工程師，看到需求后是否會出現理解偏差?如果會，那么請用更多的時間來完善需求文檔，產品經理應該時刻清楚，需求文檔的本質不在寫得多么有文采，能讓工程師正確理解才是王道，正所謂不管黑貓白貓，抓到耗子就是好貓。 團隊溝通優化。產品經理應該增加與團隊成員在一起的時間，可以選擇工作時坐在一起，或者一起吃午飯等等，你要時刻找機會把自己的想法準確的灌輸到工程師的腦袋里，并且盡可能的在不動聲色間解決他們心中的疑惑。 流程優化，需求管理系統、BUG 管理系統、產品打包機制最好都是高度智能化的，可以讓團隊成員第一時間找到自己想要的信息。 快速迭代所帶來的弊端就是產品質量無法保證，因為時間有限，往往無法對產品的健壯性進行足夠的測試，甚至有時候一個功能完成后測試人員也是僅憑借著經驗隨便點點就通過了，這里我建議大家選用一款智能化的 BUG 管理系統，系統每天通過群發郵件的方式來展現 BUG 情況，產品經理自己心中要有一個 BUG 可容忍的最大值，一旦某天的 BUG 數量超過這個值，就要分析原因并采取相應的措施來解決了。 關于總結 在產品上線后，我們通過數據來分析產品上線是否成功，并總結上一個迭代過程中所遇到的問題，因為快速迭代的團隊人員都不會很多，所以大家可以對出現的問題暢所欲言，評價成員在過程中的表現得分，當然這個評分與績效無關，我們的目的僅僅是希望團隊更好，團隊好了產品才會好。 我相信每一個互聯網公司對于快速迭代的看法都不盡相同，這是一個仁者見仁智者見智的事情，但是請大家明白，快速迭代絕對不是邊改 BUG 邊上線的過程、也絕對不是將功能進行分解來逐步實現的過程。快速迭代的實施是有前提條件的： 第一、環境，周圍環境在快速變化、產品沒有足夠的時間來進行需求分析及相關測試; 第二、用戶，用戶不知道自己真正想要什么，產品需要通過迭代的方式進行試錯; 第三、成本，一般情況下可迭代產品的成本都很低，并且可以快速的進行版本更新。 你的產品，是否可以快速迭代?你是否已經了解如何進行快速迭代了?
