手机国产精品一区二区,另类第一页,亚欧在线,日韩一国产极品99热在线播放69_国产美女久久精品香蕉欧美_亚州中文无码aⅤ在线_免费国产v片在线

談?wù)劗a(chǎn)品敏捷開發(fā)的幾大要點

2013-4-10    藍藍設(shè)計的小編

轉(zhuǎn)載藍藍設(shè)計(   www.88yangsc.com  )是一家專注而深入的設(shè)計機構(gòu) ,為期望卓越的國內(nèi)外企業(yè)提供有效的   BS界面設(shè)計 、 cs界面設(shè)計 、  ipad界面設(shè)計   、  包裝設(shè)計 、  圖標(biāo)定制 、  用戶體驗 、交互設(shè)計、   網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

來源:http://www.woshipm.com/pmd/20677.html

如果您想訂閱本博客內(nèi)容,每天自動發(fā)到您的郵箱中,   請點這里

[核心提示] 我們時常聽到許多產(chǎn)品團隊提到“小步快跑,快速迭代”,但它到底指的是什么?對此不了解的同學(xué)可以看看這篇文章。

今天在微博上又一次看到有人轉(zhuǎn)發(fā)小馬哥的:“小步快跑,快速迭代”理論,剛好鄙人近期收集了一些快速迭代的資料,接下來結(jié)合自身的經(jīng)驗來淺談產(chǎn)品的快速迭代方式。這篇文字可能會偏項目管理一些,不過我認(rèn)為項目管理也是產(chǎn)品經(jīng)理基本素質(zhì)之一。

  關(guān)于立項

這一點相信大家都不陌生,每個產(chǎn)品在經(jīng)過 BRD、MRD (當(dāng)然,這兩個過程并不是所有產(chǎn)品經(jīng)理都能參與)之后,就會進入立項階段。在傳統(tǒng)的立項過程中,我們更多的是走流程,項目負(fù)責(zé)人提出立項申請,項目組進行可行性討論分析,然后召開大會進行立項評審,負(fù)責(zé)人根據(jù)評審結(jié)果進行相應(yīng)修改,最后再召開一次轟轟烈烈的項目啟動會。而快速迭代的立項方式?jīng)]這么復(fù)雜,基本上 10 分鐘之內(nèi)一頁幻燈片就可以確定,一般會闡述這么幾個問題:我們?yōu)槭裁匆鲞@件事?有沒有更重要的工作要做?項目完成的標(biāo)準(zhǔn)是什么?項目的風(fēng)險點在哪里?只要項目組明確了這四個問題的答案,是否立項就可一目了然。

  關(guān)于晨會

現(xiàn)在大部分互聯(lián)網(wǎng)公司都有開晨會的制度,在快速迭代的產(chǎn)品管理模式下,晨會首先必須是站立式,以此保證會議的簡短、,一般情況下團隊的每個人都會逐一描述三大問題:昨天做了什么事情,今天要做哪些事情,在工作中遇到了什么問題。在會議中產(chǎn)品經(jīng)理應(yīng)該重點關(guān)注兩個方面:其一是昨天工作是否真的完成,這里所說的完成不是代碼寫完了就了事,也不是自測沒問題了就是完成,所謂一個任務(wù)的完成應(yīng)該是真正意義上的完成,即滿足用戶需求,可立即部署到真實環(huán)境中進行使用。我見過太多的工程師口口聲聲說功能已經(jīng)完成,但最終部署到服務(wù)器上依然需要經(jīng)歷大量的聯(lián)調(diào)測試,然后看著你說:“在我機器上是沒問題的”。其二產(chǎn)品經(jīng)理應(yīng)該重點關(guān)注團隊成員在工作中遇到了哪些問題,并想辦法通過團隊其他人的力量幫助其解決,這里我提到的是其他人而不是產(chǎn)品經(jīng)理,產(chǎn)品經(jīng)理在這個過程中應(yīng)該培養(yǎng)團隊的合作能力以及成員相互配合解決問題的成就感、信任感。

  關(guān)于過程優(yōu)化

在產(chǎn)品快速迭代的過程中,有很多地方需要產(chǎn)品經(jīng)理進行主導(dǎo)優(yōu)化,讓我們來列舉幾個例子:

思想優(yōu)化。在開發(fā)過程中一定會出現(xiàn)研發(fā)人員的意見與產(chǎn)品經(jīng)理、交互設(shè)計師的意見不一致的情況,因為從人性的角度分析,每個角色都一定會用自己慣性思維去思考問題,比如工程師會告訴這個 Banner 放在左面程序運行效率最高,而交互設(shè)計師認(rèn)為放在右邊會更符合行為習(xí)慣,產(chǎn)品經(jīng)理則認(rèn)為放在更上方一點會換來更多的點擊率,此時產(chǎn)品經(jīng)理一定要引導(dǎo)大家站在更高層、更客觀的角度去尋找解決方案。

代碼優(yōu)化。這一點更多的是指代碼 review,一般會采用每天團隊成員交叉 review 和每周團隊一起進行重點功能 review 兩種模式。有句話叫磨刀不誤砍柴工,代碼 review 是發(fā)現(xiàn)潛在 BUG、發(fā)現(xiàn)功能偏差的成本投入。

文檔優(yōu)化。推薦使用類似 wiki 的系統(tǒng)來統(tǒng)一管理產(chǎn)品文檔,產(chǎn)品經(jīng)理在寫文檔的過程中不要因為怕麻煩就降低文檔的可讀質(zhì)量,要知道產(chǎn)品很有可能因為你少寫幾個字就走向了另一個極端,很可能就因為這幾個字,工程師就需要返工,這也是為什么大部分工程師都想暴打產(chǎn)品經(jīng)理的原因所在。因此產(chǎn)品經(jīng)理在寫文檔的過程中應(yīng)該多以工程師的視角去寫需求,如果你是工程師,看到需求后是否會出現(xiàn)理解偏差?如果會,那么請用更多的時間來完善需求文檔,產(chǎn)品經(jīng)理應(yīng)該時刻清楚,需求文檔的本質(zhì)不在寫得多么有文采,能讓工程師正確理解才是王道,正所謂不管黑貓白貓,抓到耗子就是好貓。

團隊溝通優(yōu)化。產(chǎn)品經(jīng)理應(yīng)該增加與團隊成員在一起的時間,可以選擇工作時坐在一起,或者一起吃午飯等等,你要時刻找機會把自己的想法準(zhǔn)確的灌輸?shù)焦こ處煹哪X袋里,并且盡可能的在不動聲色間解決他們心中的疑惑。

流程優(yōu)化,需求管理系統(tǒng)、BUG 管理系統(tǒng)、產(chǎn)品打包機制最好都是高度智能化的,可以讓團隊成員第一時間找到自己想要的信息。

  關(guān)于產(chǎn)品質(zhì)量

快速迭代所帶來的弊端就是產(chǎn)品質(zhì)量無法保證,因為時間有限,往往無法對產(chǎn)品的健壯性進行足夠的測試,甚至有時候一個功能完成后測試人員也是僅憑借著經(jīng)驗隨便點點就通過了,這里我建議大家選用一款智能化的 BUG 管理系統(tǒng),系統(tǒng)每天通過群發(fā)郵件的方式來展現(xiàn) BUG 情況,產(chǎn)品經(jīng)理自己心中要有一個 BUG 可容忍的最大值,一旦某天的 BUG 數(shù)量超過這個值,就要分析原因并采取相應(yīng)的措施來解決了。

  關(guān)于總結(jié)

在產(chǎn)品上線后,我們通過數(shù)據(jù)來分析產(chǎn)品上線是否成功,并總結(jié)上一個迭代過程中所遇到的問題,因為快速迭代的團隊人員都不會很多,所以大家可以對出現(xiàn)的問題暢所欲言,評價成員在過程中的表現(xiàn)得分,當(dāng)然這個評分與績效無關(guān),我們的目的僅僅是希望團隊更好,團隊好了產(chǎn)品才會好。

我相信每一個互聯(lián)網(wǎng)公司對于快速迭代的看法都不盡相同,這是一個仁者見仁智者見智的事情,但是請大家明白,快速迭代絕對不是邊改 BUG 邊上線的過程、也絕對不是將功能進行分解來逐步實現(xiàn)的過程。快速迭代的實施是有前提條件的:

第一、環(huán)境,周圍環(huán)境在快速變化、產(chǎn)品沒有足夠的時間來進行需求分析及相關(guān)測試;

第二、用戶,用戶不知道自己真正想要什么,產(chǎn)品需要通過迭代的方式進行試錯;

第三、成本,一般情況下可迭代產(chǎn)品的成本都很低,并且可以快速的進行版本更新。

你的產(chǎn)品,是否可以快速迭代?你是否已經(jīng)了解如何進行快速迭代了?

分享本文至:

日歷

鏈接

個人資料

藍藍設(shè)計的小編 http://www.88yangsc.com

存檔