本文作者將以自己所在公司的項(xiàng)目經(jīng)歷為例，講述公司日常交付項(xiàng)目中主要使用的敏捷實(shí)踐是如何幫助團(tuán)隊(duì)實(shí)現(xiàn)最大價(jià)值的。雖然文章內(nèi)容對象是以項(xiàng)目經(jīng)理展開敘述，但項(xiàng)目管理中的敏捷實(shí)踐值得我們產(chǎn)品經(jīng)理去學(xué)習(xí)。enjoy~

作為項(xiàng)目經(jīng)理，我們經(jīng)歷了不同的項(xiàng)目，卻總是受限于相似的困局。比如以下三個(gè)典型難題：

• 團(tuán)隊(duì)目標(biāo)不一致
• 團(tuán)隊(duì)成員不熟悉
• 信息發(fā)布不流暢

倘若我們?nèi)斡蓡栴}存在，而不在每次項(xiàng)目中進(jìn)行總結(jié)和提煉，就會反復(fù)的徘徊于豐滿理想與骨感現(xiàn)實(shí)當(dāng)中。

敏捷思想和實(shí)踐能夠?yàn)槲覀兲峁┮环N可能性，幫助我們解決在項(xiàng)目交付過程中遇到的具體難題。

敏捷的項(xiàng)目管理——追求最大價(jià)值的成功

當(dāng)我們提到敏捷的項(xiàng)目管理，就得先說說瀑布式開發(fā)和迭代式開發(fā)的區(qū)別。

（圖片來自：http://t.cn/R9IjtIs）

大家都知道瀑布式開發(fā)的特點(diǎn)是大批次、緩慢流動(dòng)、在每一階段追求工作完整，但因其缺乏并行迭代的概念，對變化的響應(yīng)必然很慢。而迭代式開發(fā)則恰恰彌補(bǔ)了這個(gè)弱點(diǎn)。在迭代式開發(fā)過程中，整個(gè)開發(fā)工作被組織為一系列短小的、固定長度（在我們公司通常是2周）的小項(xiàng)目，我們將其稱為一系列的“迭代”。每一次迭代都包括了需求定義、需求分析、設(shè)計(jì)、代碼實(shí)現(xiàn)與測試。

采用這種方法，開發(fā)工作可以在需求被完整地確定前啟動(dòng)，并在每次迭代中完成系統(tǒng)的一部分功能開發(fā)工作，再通過客戶的反饋來細(xì)化需求，并開始新一輪的迭代。

敏捷開發(fā)通過逐步細(xì)化、迭代前進(jìn)的方式，分階段地將需求予以實(shí)現(xiàn)。比如說，我們先從整體功能規(guī)劃中定位出一小部分核心功能，打造能基本運(yùn)轉(zhuǎn)、對用戶有價(jià)值的最小可用產(chǎn)品（Minimum Viable Product，MVP），然后迅速迭代開發(fā)，聽取用戶反饋，及時(shí)調(diào)整功能規(guī)劃。

我曾在一次培訓(xùn)中聽到同事談到敏捷團(tuán)隊(duì)與西游團(tuán)隊(duì)的相似性，他認(rèn)為唐僧師徒可以被看作敏捷中的全功能團(tuán)隊(duì)：團(tuán)隊(duì)有共同的目標(biāo)——取到真經(jīng)；他們歷經(jīng)了九九八十一難，好比九九八十一個(gè)迭代，每次打怪成功都是完成了一次交付；在不斷迭代的過程中，這個(gè)團(tuán)隊(duì)不斷地收集反饋、持續(xù)改進(jìn)，一步步地完成了最后的目標(biāo)。取到了真經(jīng)，意味著完成了項(xiàng)目的交付，同時(shí)使得團(tuán)隊(duì)能力得到質(zhì)的提升。這是一個(gè)美妙的結(jié)果。

項(xiàng)目成果的交付和團(tuán)隊(duì)能力的提升，這是項(xiàng)目經(jīng)理在項(xiàng)目管理中最希望達(dá)成的目標(biāo)。 傳統(tǒng)項(xiàng)目管理的定義是：“在有限資源限定的條件下，實(shí)現(xiàn)或超過設(shè)定的需求和期望”。一句話概括了傳統(tǒng)項(xiàng)目管理的鐵三角：需求是范圍，資源包括時(shí)間和成本。

那么，這個(gè)定義是正確的嗎？

大家都看過電影《泰坦尼克號》，如果我們套用上面這個(gè)“范圍、時(shí)間和成本”定義的框架，《泰坦尼克號》會被判斷為一個(gè)失敗的項(xiàng)目。為什么呢？這部電影在拍攝過程中多次延期，預(yù)算也超出很多，無論從成本還是時(shí)間來看，這都是一個(gè)失敗的項(xiàng)目?？墒俏覀兌贾溃短┨鼓峥颂枴分钡浆F(xiàn)在仍然是一個(gè)難以超越的票房神話。

由此可知，左圖的“傳統(tǒng)項(xiàng)目管理鐵三角”概念忽略了“價(jià)值”這一重要因素。右圖的“敏捷項(xiàng)目管理鐵三角”強(qiáng)調(diào)，團(tuán)隊(duì)?wèi)?yīng)得到來自市場的真實(shí)反饋，以此來幫助敏捷團(tuán)隊(duì)持續(xù)不斷地、盡早地交付有價(jià)值的軟件。

在追求價(jià)值交付過程中，我們越來越多地發(fā)現(xiàn)敏捷項(xiàng)目管理中有著至關(guān)重要的一環(huán)——人，也就是我們的團(tuán)隊(duì)。價(jià)值是人創(chuàng)造的，是為人服務(wù)的，很多敏捷實(shí)踐都圍繞人展開。我們試圖找到一種通用的方法來最大限度地發(fā)揮人的能量。未來社會最有價(jià)值的人，是以創(chuàng)造力、洞察力、對客戶的感知力為核心特征的，我們相信這樣的團(tuán)隊(duì)能創(chuàng)造最大的價(jià)值。

下文將以我所在公司的項(xiàng)目經(jīng)歷為例，講述公司日常交付項(xiàng)目中主要使用的敏捷實(shí)踐是如何幫助團(tuán)隊(duì)實(shí)現(xiàn)最大價(jià)值的。

用戶故事

用戶故事（User Story）是敏捷開發(fā)的基礎(chǔ)，它從用戶的角度來對需求進(jìn)行描述。軟件開發(fā)是為了實(shí)現(xiàn)產(chǎn)品的商業(yè)價(jià)值，滿足用戶需求。只要需求足夠明確，所有人都了解其具體內(nèi)容，團(tuán)隊(duì)就能簡單有效地把需求轉(zhuǎn)化成可實(shí)現(xiàn)、可測試、能夠發(fā)布的代碼。為了實(shí)現(xiàn)這個(gè)目標(biāo)， 需要找到一種方法來描述需求，讓所有人都能對任務(wù)的范圍有一個(gè)共同的認(rèn)知。這樣團(tuán)隊(duì)對任務(wù)完成會有一個(gè)共同的定義，不會出現(xiàn)“你做的不是我所要求的”、 “我忘了告訴你這個(gè)需求”等類似的問題。

用戶故事體現(xiàn)了用戶需求以及產(chǎn)品的商業(yè)價(jià)值，同時(shí)定義了一系列Acceptance Criteria(AC)。只有團(tuán)隊(duì)完成的工作符合這一系列的AC時(shí)， 才算真正完成了這個(gè)用戶故事。一個(gè)用戶故事通常包括三個(gè)要素：

• 角色：誰要使用這個(gè)功能；
• 活動(dòng)：需要完成什么樣的功能；
• 商業(yè)價(jià)值：為什么需要這個(gè)功能，這個(gè)功能帶來什么價(jià)值。

用戶故事可以有不同的展現(xiàn)形式，以下是其中一種：

作為一個(gè)<某種類型的用戶角色>，我要<達(dá)成某些目的>，只有這樣我才能夠獲取<商業(yè)價(jià)值>。

所以用戶故事一旦被確定，那么它所要實(shí)現(xiàn)的功能、需求范圍、所需工作量也就隨之確認(rèn)了。之后開發(fā)人員所要做的就是根據(jù)這個(gè)用戶故事的內(nèi)容進(jìn)行開發(fā)，只有當(dāng)所有AC被覆蓋到，測試人員完成測試，發(fā)現(xiàn)所有功能是可測試的、可運(yùn)行的，這個(gè)用戶故事才算完成了。

估算和迭代計(jì)劃

估算(Estimation)：團(tuán)隊(duì)在動(dòng)手開發(fā)一個(gè)用戶故事功能之前，應(yīng)當(dāng)對實(shí)現(xiàn)這個(gè)用戶故事所需要的工作量有清晰的認(rèn)識。如Martin Fowler所說，”Estimation is valuable when helps you make a significant decision”。只有當(dāng)團(tuán)隊(duì)對達(dá)成一個(gè)目標(biāo)的工作量以及完成它之后的“收益”有明確的認(rèn)知， 才能做出明智的決定。

當(dāng)團(tuán)隊(duì)在為工作排定優(yōu)先級、制定迭代計(jì)劃時(shí)，業(yè)務(wù)分析師需要知道每個(gè)用戶故事的成本，團(tuán)隊(duì)成員需要知道每個(gè)用戶故事的價(jià)值。有很多種估算用戶故事工作量的方法，其中一種就是把完成這個(gè)用戶故事所需要的點(diǎn)數(shù)（根據(jù)用戶故事的復(fù)雜度估算）寫到對應(yīng)的故事卡上。估算可以幫助團(tuán)隊(duì)以不同的方式，對實(shí)現(xiàn)即將開始的用戶故事、未來的架構(gòu)方向和代碼庫的設(shè)計(jì)，有更好的理解。一個(gè)迭代能完成多少個(gè)點(diǎn)數(shù)是能估算出來的。也可以使用一些工具統(tǒng)計(jì)出過去每個(gè)迭代所完成的點(diǎn)數(shù)，比如燃盡圖。

只要整個(gè)團(tuán)隊(duì)共同協(xié)作，估算本身也可以變成一種很有意義的活動(dòng)。它有助于團(tuán)隊(duì)增進(jìn)理解，并保證團(tuán)隊(duì)每個(gè)人都對要交付的需求范圍和價(jià)值達(dá)成共識。讓評估變得更有趣的是，通常不采用簡單連續(xù)的數(shù)列，比如1，2，3，4，5等——而是采用一種近似菲波拉契數(shù)列的形式，像1，2，3，5，8，13等（正如《達(dá)芬奇密碼》里面看到的），這樣當(dāng)數(shù)字越大、相鄰數(shù)之間的間隔就越大，使得團(tuán)隊(duì)更容易區(qū)分哪個(gè)故事更小、哪個(gè)更大。

在做迭代計(jì)劃(Iteration Planning)時(shí)，團(tuán)隊(duì)需要從客戶價(jià)值維度和技術(shù)風(fēng)險(xiǎn)的角度來排定優(yōu)先級。下圖中是常用的工具之一——需求優(yōu)先級矩陣。

迭代會議和功能演示

敏捷宣言里面有一條：客戶協(xié)作優(yōu)于合同談判。在敏捷團(tuán)隊(duì)中有一個(gè)角色叫做業(yè)務(wù)分析師(BA)，其核心職責(zé)是確保業(yè)務(wù)需求的清晰和透明，保證開發(fā)團(tuán)隊(duì)對業(yè)務(wù)有足夠的理解，并將這些待完成的用戶故事按照優(yōu)先級排列出來，以任務(wù)卡的形式來驅(qū)動(dòng)團(tuán)隊(duì)的開發(fā)。

迭代會議(IPM)通常發(fā)生在每個(gè)迭代的第一天，團(tuán)隊(duì)成員一起制定迭代計(jì)劃。這個(gè)會議由BA主持，大家一起同步幾個(gè)方面的內(nèi)容：

• 下一個(gè)迭代的用戶故事；
• 對下一個(gè)迭代的期望和計(jì)劃；
• 風(fēng)險(xiǎn)的評估和總結(jié)。

不同的人對需求有著不同的理解，所有團(tuán)隊(duì)成員都要對用戶故事所有相關(guān)內(nèi)容、所要實(shí)現(xiàn)的功能、滿足哪些條件用戶故事才算完成達(dá)成一致。迭代會議的主要產(chǎn)出是下一個(gè)迭代中需要完成的用戶故事，這些用戶故事即為下一個(gè)迭代所要完成的主要目標(biāo)。

功能演示（Showcase）是敏捷開發(fā)流程中的又一個(gè)實(shí)踐，通常發(fā)生在每個(gè)迭代的最后一天，目的是演示可工作的軟件。團(tuán)隊(duì)把一個(gè)迭代中開發(fā)好的功能給相關(guān)人員演示，并收集反饋，以便在下一個(gè)迭代中可以對變化作出快速響應(yīng)。

站會和用戶故事開卡

簡單地說，站會(Standup)是團(tuán)隊(duì)在一起快速地開一個(gè)會(通常在物理墻前)，成員逐個(gè)更新自己的狀態(tài)。更新包含以下幾個(gè)方面：

• 昨天完成的工作；
• 今天計(jì)劃做的工作；
• 面臨什么阻礙，需要什么幫助；
• 自己手頭用戶故事的進(jìn)展，是否存在技術(shù)風(fēng)險(xiǎn)。

既然是快速的會議，站會的時(shí)間就不宜過長，10分鐘左右為佳。建議團(tuán)隊(duì)成員站著開會，因?yàn)檠芯勘砻?，?dāng)人們坐著開會的時(shí)候，會議的時(shí)間會被無形中拉長。

這里有一些實(shí)踐原則：

• 團(tuán)隊(duì)成員都要參加站會，輪流主持，誰遲到了都不等——儀式感很重要。
• 站會的時(shí)候，每位團(tuán)隊(duì)成員圍繞故事卡進(jìn)行更新。介紹一種有意思的實(shí)踐——使用Token(也就是使用一個(gè)實(shí)物作為”令牌”，準(zhǔn)備發(fā)言的人首先取得”令牌”，發(fā)言完成后將“令牌”傳給下一個(gè)人。令牌要醒目，可以是毛絨玩具，也可以是一頂帽子)。

用戶故事開卡(Story kick-off)：在每個(gè)用戶故事開發(fā)之前，要確保BA、DEV和QA對用戶故事理解一致。這個(gè)溝通活動(dòng)通常表現(xiàn)為由DEV講解這個(gè)用戶故事要完成的功能及AC，一旦發(fā)現(xiàn)任何疏漏，BA及時(shí)補(bǔ)充。DEV有任何疑惑也需及時(shí)提出來，當(dāng)場確認(rèn)，使這些功能得以正確實(shí)現(xiàn)。在后續(xù)開發(fā)中如果碰到任何疑惑，也應(yīng)及時(shí)找BA了解清楚。QA會嚴(yán)格按照AC來驗(yàn)收用戶故事。

代碼審查和回顧

代碼審查（Code Review） 開發(fā)團(tuán)隊(duì)在完成每天代碼之后，會聚在一起評審當(dāng)天的代碼，這樣做有幾個(gè)好處：

• 團(tuán)隊(duì)經(jīng)過一天高強(qiáng)度的思考與編碼，適當(dāng)?shù)赝Ｏ聛恚纯雌渌藢懙拇a，同時(shí)將自己的代碼講解出來，往往能獲得一些意外的靈感，或許能解決自己面臨的阻礙；
• 互相了解設(shè)計(jì)思路，獲得更好的建議和進(jìn)行思路重構(gòu)，提高代碼質(zhì)量；
• 及早發(fā)現(xiàn)潛在缺陷，降低事故成本：如果這個(gè)時(shí)候發(fā)現(xiàn)代碼的壞味道和一些需要改進(jìn)的地方，代碼審查結(jié)束后可以花少量時(shí)間作出更改；
• 促進(jìn)團(tuán)隊(duì)內(nèi)部的知識共享。

回顧（Retrospective）：回顧會議的目的是通過新的溝通形式喚起大家對團(tuán)隊(duì)的集體意識，指出團(tuán)隊(duì)或個(gè)人在一段時(shí)間內(nèi)的不足并列出對應(yīng)行動(dòng)。持續(xù)而有效的回顧和反饋，可以保證團(tuán)隊(duì)關(guān)心生產(chǎn)力和效率，了解自身的不足，這將成為團(tuán)隊(duì)持續(xù)改進(jìn)的起點(diǎn)。

回顧的關(guān)注點(diǎn)也多種多樣，除了“項(xiàng)目開發(fā)”之外，還可以關(guān)注“敏捷成熟度”、“團(tuán)隊(duì)角色和職責(zé)”、“人員技能提升”等。在堅(jiān)持回顧的同時(shí)，需要做的還有保證回顧的有效性。應(yīng)根據(jù)團(tuán)隊(duì)建設(shè)目標(biāo)的發(fā)展變化，不斷調(diào)整回顧的關(guān)注點(diǎn)和形式，確?；仡櫮軌蛴嗅槍π缘匕l(fā)現(xiàn)團(tuán)隊(duì)的缺陷并轉(zhuǎn)化為實(shí)踐。長期有效的回顧和正確的回顧產(chǎn)出，還能夠不斷提升團(tuán)隊(duì)內(nèi)部的安全感和信任度。

回顧的形式和方法非常多，最常見的是“Well & Less Well”。

最大程度的可視化

看板源于精益生產(chǎn)實(shí)踐，敏捷將其背后的可視化管理理念借鑒過來，形成了具有自己獨(dú)特風(fēng)格的可視化管理工具。

在敏捷項(xiàng)目里，掛在墻上的“人人可見的大圖表”是一種普遍的實(shí)踐，它被用來共享項(xiàng)目的狀態(tài)并將之可視化。比如表示項(xiàng)目狀態(tài)的物理墻，這樣的物理墻通常包括三個(gè)元素：時(shí)間、任務(wù)和團(tuán)隊(duì)。

除了表示項(xiàng)目狀態(tài)，項(xiàng)目團(tuán)隊(duì)還會可視化其他的元素，比如團(tuán)隊(duì)?wèi)?yīng)堅(jiān)持的規(guī)則、項(xiàng)目上的經(jīng)驗(yàn)分享以及項(xiàng)目的里程碑。

一般來說，通過有關(guān)聯(lián)的團(tuán)隊(duì)和個(gè)人之間相互協(xié)商，可以識別出未來一段時(shí)間里各自的活動(dòng)，以及相應(yīng)的、對成功的衡量方式，然后將其可視化出來，每段時(shí)間再回顧和調(diào)整一次。有了這樣的可視化，團(tuán)隊(duì)會更加容易對齊目標(biāo)，并不斷培養(yǎng)和加深責(zé)任感。

可視化帶來的好處是：

• 日常工作透明，將迭代過程中所有的故事卡可視化出來，團(tuán)隊(duì)成員可以隨時(shí)知道當(dāng)前需要完成的工作以及將要完成的工作。由于人對視覺反應(yīng)更靈敏，可視化的故事墻能立刻聚焦團(tuán)隊(duì)的注意力。
• 將迭代過程中遇到的問題暴露出來，可以促進(jìn)團(tuán)隊(duì)成員在工作中一起積極討論解決方案。
• 團(tuán)隊(duì)也可以根據(jù)現(xiàn)在的進(jìn)度以及遇到的問題，了解需要哪些幫助，更好的分配資源，減少開發(fā)進(jìn)度被滯后的風(fēng)險(xiǎn)。

溝通計(jì)劃

敏捷里面的自組織團(tuán)隊(duì)其實(shí)是敏捷的結(jié)果，而不是先決條件。實(shí)施敏捷的過程也是打造自組織團(tuán)隊(duì)的過程。每個(gè)團(tuán)隊(duì)成員在面對“做什么、怎么做”的問題時(shí)，也會以自組織的方式去解決。每一天，團(tuán)隊(duì)中的每一個(gè)人都要其他成員保持協(xié)調(diào)。為了保持同步，我們會創(chuàng)造基于敏捷實(shí)踐的溝通機(jī)會，這個(gè)也是實(shí)施敏捷的過程之一。

在ThoughtWorks有一個(gè)非常有名的活動(dòng)叫Inception。Inception是啟動(dòng)軟件設(shè)計(jì)和交付項(xiàng)目的方法，通過集中式、互動(dòng)式的設(shè)計(jì)工作坊，幫助客戶在最短時(shí)間內(nèi)對項(xiàng)目范圍達(dá)成一致，快速進(jìn)入項(xiàng)目交付。而Inception的一個(gè)產(chǎn)出就是溝通計(jì)劃(Communication Plan)。比如在這個(gè)溝通計(jì)劃中會討論：以什么頻率、什么形式作項(xiàng)目的更新，比如說每周五以周報(bào)的形式作一些主要信息的更新；站會和迭代會議什么時(shí)候召開，需要邀請哪些人，比如說業(yè)務(wù)負(fù)責(zé)人，技術(shù)負(fù)責(zé)人等等。

以下內(nèi)容都會在溝通計(jì)劃中定義清楚:

寫在最后

回到文章開頭的部分，我認(rèn)為可以將敏捷實(shí)踐和解決方案做如下對應(yīng)：

團(tuán)隊(duì)目標(biāo)不一致

• 用電子墻和物理墻展示用戶故事、需求全景圖、項(xiàng)目進(jìn)度燃盡圖；
• 通過迭代會議和功能演示會議對齊迭代計(jì)劃，項(xiàng)目進(jìn)度、識別項(xiàng)目風(fēng)險(xiǎn)。

團(tuán)隊(duì)成員不熟悉

• 基于敏捷實(shí)踐，創(chuàng)造更多的溝通機(jī)會，比如回顧會議、代碼審查和站立會議。通過不斷地創(chuàng)造這樣的溝通機(jī)會讓團(tuán)隊(duì)成員更加默契。

信息發(fā)布不順暢

• 共享信息，制定溝通計(jì)劃；
• 最大程度的可視化。

文中提到了很多類型的敏捷實(shí)踐，這些實(shí)踐需要貫穿到團(tuán)隊(duì)的日?；顒?dòng)中去，持續(xù)的實(shí)施和改進(jìn)。行為心理學(xué)研究認(rèn)為：21天以上的重復(fù)就會形成習(xí)慣。任何一個(gè)動(dòng)作，重復(fù)21天就會變成習(xí)慣性的動(dòng)作；任何一種想法，重復(fù)21天、或者重復(fù)驗(yàn)證21次，就會變成習(xí)慣性的思維方式；任何一種信念或者有益的實(shí)踐，經(jīng)過團(tuán)隊(duì)持續(xù)驗(yàn)證，它一定會成為團(tuán)隊(duì)的信念和實(shí)踐。

劍道中有這樣一個(gè)心訣：守、破、離。

• 守：最初階段須遵從老師教誨，認(rèn)真練習(xí)基礎(chǔ)，達(dá)到熟練的境界
• 破：基礎(chǔ)熟練后，試著突破原有規(guī)范讓自己得到更高層次的進(jìn)化
• 離：在更高層次得到新的認(rèn)識并總結(jié)，自創(chuàng)新招數(shù)、另辟新境界

項(xiàng)目管理者中的大多數(shù)人都處于“守”的階段：他們學(xué)習(xí)、吸收了前人的項(xiàng)目管理經(jīng)驗(yàn)，帶領(lǐng)自己的團(tuán)隊(duì)有序地開展項(xiàng)目交付工作；但是他們經(jīng)常困惑于某些在管理中反復(fù)出現(xiàn)的問題，苦于找不到有效的解決方法，不得不在新的項(xiàng)目中重復(fù)之前的困惑；

有的項(xiàng)目管理者已經(jīng)達(dá)到了“破”的層次：他們能夠以全局優(yōu)化的角度去總結(jié)自身項(xiàng)目管理的經(jīng)驗(yàn)，并通過學(xué)習(xí)、分享及各種交流平臺去開闊眼界、拓寬思路，借鑒或改良項(xiàng)目管理的方式方法，使之更適用于團(tuán)隊(duì)；

而所有項(xiàng)目管理者的最高目標(biāo)則是“離”：隨著項(xiàng)目經(jīng)驗(yàn)的不斷積累、對管理的思考日漸加深，對項(xiàng)目管理有了新的、更高層次的、屬于自己的獨(dú)特認(rèn)知，并將其應(yīng)用在實(shí)踐中，獨(dú)辟蹊徑，使整個(gè)項(xiàng)目管理思路煥然一新。

希望越來越多的項(xiàng)目管理者能夠達(dá)到更高的階段。這是我們在項(xiàng)目管理中不變的追求。

作者：萬學(xué)凡，ThoughtWorks咨詢師，資深項(xiàng)目經(jīng)理，擁有豐富的項(xiàng)目管理經(jīng)驗(yàn)和行業(yè)經(jīng)驗(yàn)，現(xiàn)任武漢分公司負(fù)責(zé)人。業(yè)余喜歡登山和讀書。

本文由 @ThoughtWorks （微信公眾號：“思特沃克”） 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。