【文章內(nèi)容簡介】 向的競爭力；前者要求細節(jié)，后者要求高度。那么，這兩個人到底誰是傳統(tǒng)意義上的Product Owner呢？另一個常常被問到的問題是：“我們只有一個產(chǎn)品經(jīng)理，而有20多個開發(fā)人員，這一個產(chǎn)品經(jīng)理能忙得過來嗎？”再有一個問題則是：“PO只在迭代開發(fā)會上溝通需求，還是在迭代開發(fā)期間仍然與團隊在一起？”還有一個問題則是：“PO在最后的評審會上才看到結(jié)果，萬一發(fā)現(xiàn)問題需要改正，是否會為時過晚？”又有一個問題則是：“可以讓客戶代表參加計劃、評審活動嗎？”……這些諸多問題，都指向一個答案：“一個PO很難完成其所應(yīng)履行的各種職責(zé)，我們需要一個PO團隊?！苯Y(jié)構(gòu)PO團隊整體上是一個上下分級、內(nèi)外疏密的團隊。所謂上下分級，就是說一定要有產(chǎn)品總監(jiān)層面的人員參加，以便把控整個產(chǎn)品的走向。這種把控的結(jié)果，是能按照商業(yè)步調(diào)形成大的版本計劃。若失去這種大的方向，就很難真正“按優(yōu)先級排序”，因為真正的優(yōu)先級，來自于對盈利性產(chǎn)品的持續(xù)盈利能力、新產(chǎn)品的價值判斷發(fā)展方向等商業(yè)目標(biāo)的追求，而不是技術(shù)上的優(yōu)先級。在總監(jiān)層面的工作完成后，產(chǎn)品經(jīng)理會在具體版本、計劃、需求開發(fā)、評審、發(fā)布等工作中將商業(yè)目標(biāo)落實到開發(fā)工作中。從時間上，保證產(chǎn)品進度符合商業(yè)步調(diào)，從空間上，保證產(chǎn)品需求符合目標(biāo)客戶群。在大型的PO團隊如游戲的策劃團隊（常常占總?cè)藬?shù)的1/4）中，還會有三層結(jié)構(gòu)：主策劃（產(chǎn)品總監(jiān)）策劃組長（產(chǎn)品經(jīng)理）策劃人員（產(chǎn)品助理），負責(zé)一小部分故事的編寫與跟進（跟進活動見下文）。所謂內(nèi)外疏密，則是在開發(fā)過程中由客戶、市場、銷售、產(chǎn)品、開發(fā)、售后等綜合角度審視產(chǎn)品。比如游戲公司常常邀請運營部門或發(fā)行商參與產(chǎn)品的管理，消費電子則會邀請分銷商、售后部門等，目的是提供第一手的反饋。產(chǎn)品研發(fā)團隊的代表也常常參加PO團隊，來幫助PO團隊把握產(chǎn)品演進的技術(shù)路線。研發(fā)團隊代表還會從整個商業(yè)路線圖中勾勒出技術(shù)路線圖，來判斷是否以及在何種程度上“為未來做準(zhǔn)備”。（在《智慧敏捷系列》中曾經(jīng)提到，準(zhǔn)備太多會浪費；準(zhǔn)備太少會返工。）產(chǎn)品經(jīng)理在整個過程中扮演穿針引線的作用，即作為各方的Servant，向上提供決策依據(jù)，向下提供目標(biāo)指引，向外提供產(chǎn)品支持，向內(nèi)提供用戶需求?；顒映顺Ｒ姷男枨髢?yōu)先級排序、計劃會講解故事、評審會評審需求之外，整個PO團隊還有很多工作，下面按照工作的大小、層次列舉一下。 產(chǎn)品初期o 產(chǎn)品總監(jiān)：設(shè)定商業(yè)目標(biāo)和路線圖 日常工作o 產(chǎn)品經(jīng)理：制定發(fā)布計劃，形成和描述故事o 研發(fā)團隊的代表：制定技術(shù)路線圖 迭代前o 產(chǎn)品經(jīng)理：優(yōu)先級排序，選擇下個迭代的待開發(fā)列表（Willing List），選擇故事群，制定迭代目標(biāo)o 產(chǎn)品經(jīng)理/研發(fā)團隊的代表：預(yù)估故事，協(xié)助拆分故事 迭代中o 產(chǎn)品經(jīng)理/產(chǎn)品助理：負責(zé)細化需求，跟進需求的完成情況（漸進式評審，見下） 評審會o 產(chǎn)品總監(jiān)/產(chǎn)品經(jīng)理：評審需求完成情況，提出意見，重新排序某些PO團隊參與開發(fā)過程的活動，請參考：漸進式評審所謂漸進式評審，又叫跟進人制度，是為了防止迭代最后一天的評審會上發(fā)現(xiàn)了問題，由于第二天就想發(fā)布了所以來不及改正，因而將評審改為每一個故事完成，都進行一次評審，若需要改正則提前進行。一般需要以下實踐配合：1. PO團隊人數(shù)較多，且有層次，能為每個故事設(shè)定跟進人，負責(zé)解釋和驗收這個故事。2. 配合MoSCoW方法，按優(yōu)先級逐個完成故事，若M、S類型的故事評審后需要改進，則可能犧牲后面的W類型工作。3. 中期評審會。有些團隊在為期30天的迭代的第20天左右，會開一個預(yù)評審會，以完成2中提到的工作。敏捷開發(fā)產(chǎn)品管理系列之八：基于業(yè)務(wù)設(shè)計技術(shù)架構(gòu)（兼談12306性能問題）在產(chǎn)品開發(fā)中，常常遇到產(chǎn)品性能問題，這些性能問題會很大程度上影響到產(chǎn)品的架構(gòu)。但解決這些性能問題，切莫認(rèn)為只是技術(shù)人員的事情，產(chǎn)品經(jīng)理和產(chǎn)品總監(jiān)也要參與其中，甚至是業(yè)務(wù)人員（銷售、售前）。下面以12306的售票問題為例，來做一個完整的說明。本文的目的，不是說技術(shù)性優(yōu)化不必要，而是說作為開發(fā)人員不要悶頭只想技術(shù)，而作為產(chǎn)品經(jīng)理不要把所有“技術(shù)”問題推給開發(fā)人員，這一點很重要。技術(shù)方案的局限性12306為什么崩潰了？原因眾說紛紜，解決方案也眾說紛紜。到網(wǎng)上一搜“12306 性能”+%D0%D4%C4%DCamp。rsv_bp=0amp。rsv_spt=3amp。inputT=8540支招者不計其數(shù)，但多數(shù)集中在技術(shù)方面。本人對數(shù)據(jù)庫一項所知甚少，也不懂如何優(yōu)化，但下面我們從業(yè)務(wù)的角度看看有沒有什么解決方法。先看看這個方案：為何不上10倍的服務(wù)器？很多人提出，如果上10倍的服務(wù)器（或10倍的內(nèi)存/硬盤/……），可能就解決了擁堵問題。實際上我也想過是否可以上10倍的火車，解決中國的春運問題。答案是不能。因為任何能夠滿足春運數(shù)量的火車，在非春運的時候都會變成很大的負擔(dān)，只能停在什么地方風(fēng)吹雨淋等待下一個春運到來。所以，突發(fā)性是核心矛盾，無論用技術(shù)方法，解決突發(fā)性是主要矛盾。突發(fā)性的放大除了很多人在這段時間買票之外，有一個正反饋過程加重了突發(fā)性，那就是買不到票?？梢哉f，訪問人數(shù)無論上升還是下降，只要還有票，多數(shù)人都只會登錄此網(wǎng)站一次，性能問題至少還是線性的。但如果買不到票，或買不到某個車次的票，人們就會突然多次訪問網(wǎng)站，性能問題就變成非線性的了。比如有一個人就刷新200多次，終于購票成功。把200變回1，這不是一個簡單地利用技術(shù)能解決的問題。在某個攻略中也提到，由于人數(shù)太多，登錄都需要20～30次才能完成。這些非線性因素，乘上本來就增加的人數(shù)，難免崩潰。從業(yè)務(wù)角度思考問題先胡寫幾個方案看看，先假設(shè)我不會編程。1. 把提前售票時間從10天改為20天“什么？”是的，這個傻方法差不多可以降低服務(wù)器負載50%。2. 設(shè)計一個排隊系統(tǒng)，完成登錄以前玩游戲的時候，經(jīng)常因為部分服務(wù)器崩潰而無法登陸，不過，這時候都會出現(xiàn)一個排隊系統(tǒng)：“您正在排隊登錄，前面還有1000人……900人……800人……（別亂動鍵盤啊，快到你了）”這個是用來解決雪上加霜的突發(fā)性放大問題的。我相信12306肯定為30億人次的春運做過準(zhǔn)備，只是沒為6000人次的春運做準(zhǔn)備，排隊系統(tǒng)可以把人數(shù)重新變回30億。3. 設(shè)計一個排隊系統(tǒng)，完成預(yù)訂票進去了，還是沒有票，怎么辦？每天抽空就上來看看，然后重新登錄……刷新……又是一個突發(fā)性放大因素。如果有一個排隊系統(tǒng)，你按優(yōu)先級排列上自己想買的幾種票，甚至直接說“某月日，哪到哪，無論車次，有票就給我”，在家等著退票，或者偶然發(fā)出臨時車次吧。如果是我，我還會做個短信服務(wù)，如果買到了就短信通知；如果還在排隊……如果你愿意接收，每排名向前10%，可以再發(fā)個短信；你耐不住性子想查詢一下，也可以反向發(fā)個短信來，實時查詢。不過，短信要付費的，1毛一條，平價的。我聽說短信分賬是2：8開，電信才拿2分錢，剩下8分歸鐵道部，不知道現(xiàn)在是否還是這個規(guī)矩。一個春運下來短信還能賺幾億（應(yīng)該完勝CCTV的春晚），而且客戶還挺高興，畢竟這幾毛錢解決了大問題了，免去半夜爬起來/請假/寒風(fēng)中排隊。撇開這些不說，一臺臺式機開機3小時就是一度電，6毛錢，管保3小時內(nèi)你買不到票的；而現(xiàn)在能了（如果還有票）。當(dāng)然，如果鐵道部愿意讓利于民，免費發(fā)短信就更好了，不過如果能解決這個問題，相信實際上大家都會覺得讓不讓的都無所謂了；畢竟火車票10年沒漲價，這些錢給人家發(fā)加班費吧。另外這個排隊系統(tǒng)還能把黃牛的刷票軟件干掉，黃牛再多，也跟著十億人民一起排隊吧。……等等諸種業(yè)務(wù)方法，雖然不能解決有沒有票的問題，但能解決購票的性能問題。實際客戶體驗也要好得多，畢竟無論你怎么上服務(wù)器和優(yōu)化技術(shù)，如果我還是上去200次，依舊耽誤工作和生活，弄不好還的從黃牛黨買票（他們有專業(yè)刷票軟件，從性能優(yōu)化的收益遠超過我們）。從業(yè)務(wù)角度思考技術(shù)架構(gòu)正題反而很簡單了，如果要做技術(shù)架構(gòu)，先要了解業(yè)務(wù)架構(gòu)。這一點要說服產(chǎn)品人員和業(yè)務(wù)人員參加進來，在。《火星人開發(fā)紀(jì)實：敏捷開發(fā)一千零一夜》序言本文是《火星人》系列的子系列，將分期向大家分享火星人敏捷開發(fā)管理工具的開發(fā)和管理實踐。一直以來，敏捷開發(fā)長期受困于各種名詞、術(shù)語的堆疊、羅列、解釋，而較少出現(xiàn)原創(chuàng)和實踐分享過程。而敏捷實際上本來只把自己作為一個起點，需要大家的豐富和擴展。這可能與中國的軟件業(yè)發(fā)展長期落后于國際所致，以及在PMP、CMMI推廣中所養(yǎng)成的重標(biāo)準(zhǔn)、輕實踐的的情況有關(guān)。本子系列會與大家分享我們自己的開發(fā)和管理實踐，它們可能不完美，也不是終極實踐（因為我們未來會做地更好），但卻是在時間、人員、市場、產(chǎn)品、團隊……眾多因素的限制下的真是實踐。每一期中，除了實踐本身之外，我們都會盡量分享關(guān)于這個實踐我們的考慮過程、未來設(shè)想，以便幫助大家思考和實踐出自己的敏捷開發(fā)來。本文已經(jīng)收錄于《敏捷開發(fā)案例集》，有志于提交和發(fā)表自己案例的讀者，可致信wanglijie9057@，或申請加入：173709637。注意這是一個內(nèi)部討論群，僅對潛在的案例提供者開放。序言這是一個真實的故事。這是一個只會在世界上發(fā)生一次的故事。所以，它揭示的是真理————————在現(xiàn)實世界中的一次閃現(xiàn)。 去年在業(yè)余時間開始了一個產(chǎn)品研發(fā)項目，開始的時候一個人隔三差五地抽空開發(fā)，后來投入了比較常規(guī)的時間進行開發(fā)，最后又有一個兄弟加盟兩個人一起開發(fā)。這個產(chǎn)品，就是“火星人”，一個敏捷開發(fā)管理工具。既然是敏捷開發(fā)管理工具，自然就應(yīng)該按照敏捷開發(fā)的規(guī)矩辦事：用戶故事，迭代計劃，每日立會，自動化測試……一個都不能少，對不對？然而在開始了不久以后，我們發(fā)現(xiàn)問題沒有這么簡單。 下面的故事，就是摘選了其中圍繞用戶故事相關(guān)的心得體會，以后還會有一些關(guān)于測試、重構(gòu)、迭代規(guī)劃、團隊管理等方面的心得。由于我們的前后人數(shù)變化、實際生產(chǎn)率、開發(fā)日程很特殊，下面的時間點做了一些加工，以利于可以像正常項目一樣理解。免責(zé)聲明：本系列文章涉及的若干中間產(chǎn)品截圖，本文作者也認(rèn)為非常丑陋。但為了保持紀(jì)實性，仍然保留這些在實際產(chǎn)品中已經(jīng)不復(fù)存在的歷史資料。請在其他正式火星人產(chǎn)品文章的指導(dǎo)下進行閱讀。《火星人開發(fā)紀(jì)實：敏捷開發(fā)一千零一夜》第一個月：一個產(chǎn)品的誕生第一個月：一個產(chǎn)品的誕生沒有國王，沒有宰相，沒有能講故事的王后，也沒有需求文檔，開發(fā)就這樣開始了：為何不先寫需求文檔？因為敏捷開發(fā)不寫文檔！不是的。策劃這個產(chǎn)品的時候，有一個大愿：就是用這個產(chǎn)品管理這個