中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

在這篇文章中，本文作者分享了他對(duì)于產(chǎn)品文檔的看法以及撰寫(xiě)產(chǎn)品文檔的常用流程。

產(chǎn)品文檔撰寫(xiě)指南

很多人聽(tīng)到「產(chǎn)品文檔」這四個(gè)字就像吞了蒼蠅一樣，人們通常會(huì)認(rèn)為這意味著又要花幾周寫(xiě)一個(gè)根本沒(méi)人看的文檔。如果一個(gè)團(tuán)隊(duì)總被產(chǎn)品文檔這種事情拖累，怎么可能「敏捷」得起來(lái)，怎么可能高效地產(chǎn)出代碼？

我在過(guò)去十幾年創(chuàng)造了多個(gè)數(shù)百萬(wàn)人使用的軟件產(chǎn)品之后，越發(fā)認(rèn)為這種觀(guān)點(diǎn)是完全錯(cuò)誤的。根據(jù)我的經(jīng)驗(yàn)：

• 高效的產(chǎn)品文檔是創(chuàng)造偉大產(chǎn)品的過(guò)程中所不可或缺的重要組成部分。
• 撰寫(xiě)產(chǎn)品文檔可以強(qiáng)制所有人從項(xiàng)目初始就理性思考，頻繁溝通，明確權(quán)責(zé)——所有的這些都會(huì)帶來(lái)更好的軟件質(zhì)量，更低的進(jìn)度風(fēng)險(xiǎn)，以及更少的時(shí)間浪費(fèi)。

在這篇文章中，我會(huì)通過(guò)一個(gè)案例來(lái)分享一些普適的建議，這些建議會(huì)對(duì)大中型（超過(guò)二百人的）公司中的產(chǎn)品經(jīng)理們非常有幫助。

首先，舉個(gè)例子

假設(shè)你在這里工作：

一家從事在線(xiàn)旅游預(yù)訂服務(wù) （就像 Hotels 或者 Airbnb 但是規(guī)模更小一些）的公司。目前這家公司的支付轉(zhuǎn)化率偏低，所以這個(gè)季度大家打算嘗試通過(guò)在支付環(huán)節(jié)加入在線(xiàn)客服的方案來(lái)提升轉(zhuǎn)化。

你的工單/用戶(hù)故事/路線(xiàn)圖是：

通過(guò)在支付環(huán)節(jié)增加在線(xiàn)客服來(lái)嘗試提高支付轉(zhuǎn)化率。支付轉(zhuǎn)化率目前僅有 18％，而業(yè)內(nèi)平均轉(zhuǎn)化率有 30％。我們打算測(cè)試下在支付時(shí)展示在線(xiàn)客服聊天窗口是否可以提高這個(gè)轉(zhuǎn)化率。用戶(hù)運(yùn)營(yíng)團(tuán)隊(duì)已經(jīng)同意了提供 1 人月的客服人力支持。

在你沒(méi)有產(chǎn)品文檔時(shí)，你會(huì)這樣做：

比方說(shuō)，你覺(jué)得行動(dòng)起來(lái)總是最重要的，因此直接開(kāi)始動(dòng)手：

1. 在迭代計(jì)劃會(huì)上，你和團(tuán)隊(duì)討論了這個(gè)需求。
2. 然后你挑選了一個(gè)靠譜的第三方客服供應(yīng)商（例如 SnapEngage ）。
3. 提交一個(gè)工單來(lái)讓工程師添加一些 Javascript 代碼。
4. 和支持團(tuán)隊(duì)開(kāi)個(gè)會(huì)，確定他們都準(zhǔn)備好了

搞定了！這么簡(jiǎn)單的事情怎么能要我們寫(xiě)產(chǎn)品文檔呢？如果你是在一個(gè)小型創(chuàng)業(yè)團(tuán)隊(duì)，你也確實(shí)并不需要——因?yàn)楫a(chǎn)品改動(dòng)相對(duì)小，涉及到的人也相對(duì)更少。

但如果你是在一個(gè)更大的組織之中，或者產(chǎn)品更加成熟/復(fù)雜，就會(huì)陸續(xù)出現(xiàn)下列這些問(wèn)題，并且相比寫(xiě)文檔，這些問(wèn)題會(huì)需要更多時(shí)間來(lái)處理。

例如：

• 工程師把工單標(biāo)記完成了，但是一驗(yàn)收測(cè)試，就發(fā)現(xiàn)這個(gè)功能完全沒(méi)有考慮移動(dòng)端的適配?！赴ρ?！你忘了提醒大家手機(jī)端的使用才是核心場(chǎng)景?！?/li>
• 用戶(hù)運(yùn)營(yíng)經(jīng)理打算開(kāi)展一個(gè)漫長(zhǎng)的評(píng)審流程，以確定最合適的聊天服務(wù)商?！赴　枰ㄒ粋€(gè)會(huì)議，向大家解釋下這次上線(xiàn)只是一個(gè)灰度測(cè)試?！?/li>
• 發(fā)布一小時(shí)后，客服報(bào)告說(shuō)他們收到了西班牙語(yǔ)的在線(xiàn)聊天請(qǐng)求?！干?？要追加一個(gè)緊急發(fā)布，把這個(gè)測(cè)試限定在英語(yǔ)用戶(hù)中。」
• 一個(gè)設(shè)計(jì)師花了幾天，為聊天窗口滑入屏幕的交互繪制了一個(gè)完美的動(dòng)畫(huà)?！赣脩?hù)體驗(yàn)過(guò)度優(yōu)化，你是否對(duì)整個(gè)團(tuán)隊(duì)統(tǒng)一了「這次只是一個(gè)測(cè)試」的預(yù)期？」
• 一周的測(cè)試完成之后，數(shù)據(jù)分析師發(fā)現(xiàn)無(wú)法產(chǎn)出你要的報(bào)告，因?yàn)橄嚓P(guān)的必要指標(biāo)并沒(méi)有埋點(diǎn)。「史詩(shī)級(jí)的失敗。從頭再來(lái)吧?！?/li>

如果這是一個(gè)相對(duì)簡(jiǎn)單的項(xiàng)目，即使沒(méi)有產(chǎn)品文檔可能也不至于陷入這樣的災(zāi)難之中。但是在簡(jiǎn)單的項(xiàng)目中你仍然有可能會(huì)因?yàn)闆](méi)有文檔浪費(fèi)許多時(shí)間和機(jī)會(huì)成本。

如果你寫(xiě)了一篇文檔

為了便于說(shuō)明，我準(zhǔn)備了兩個(gè)示例文檔：一篇思路筆記，和一篇完整的產(chǎn)品文檔示例——這樣可以完整介紹產(chǎn)品文檔的撰寫(xiě)流程。

請(qǐng)?jiān)诶^續(xù)閱讀文章之前，花幾分鐘讀一下這兩篇示例文檔吧。

（1）閱讀示例思路筆記。（閱讀時(shí)間 2 分鐘）

這是一個(gè)根據(jù)你已知的信息和想要解答的問(wèn)題所梳理成的列表。

這會(huì)是你需要做的第一件事情，大約需要一個(gè)小時(shí)來(lái)完成這個(gè)文檔。這個(gè)文檔會(huì)成為你和團(tuán)隊(duì)中其他人的一個(gè)溝通基礎(chǔ)。

（2）閱讀示例文檔。（閱讀時(shí)間 6 分鐘）

只有和團(tuán)隊(duì)一起評(píng)審了你的假設(shè)和創(chuàng)意之后（無(wú)論是在專(zhuān)門(mén)召集的會(huì)議上，喝咖啡時(shí)，或者桌上足球的休息時(shí)間），你才應(yīng)該真正開(kāi)始寫(xiě)產(chǎn)品文檔。

如果已經(jīng)完成了溝通和評(píng)審，整個(gè)文檔應(yīng)該花費(fèi)你 1-3 個(gè)小時(shí)的時(shí)間。

啊哈！有了文檔之后是不是就感覺(jué)踏實(shí)多了？寫(xiě)文檔看起來(lái)是額外的工作成本，但是其實(shí)并不是，高效的文檔可以幫助你和你的團(tuán)隊(duì)節(jié)約時(shí)間投入，并且在交付上線(xiàn)時(shí)會(huì)更有信心。

等等！——你已經(jīng)讀完示例文檔了么？請(qǐng)務(wù)必先讀完它再繼續(xù)閱讀下面的文章。

Ben Horowitz

文檔撰寫(xiě)指南

我通過(guò)示例文檔詮釋了這篇文章中所講述的思考，在繼續(xù)閱讀全文之前，請(qǐng)務(wù)必確認(rèn)你已經(jīng)閱讀了示例文檔 。

為什么要寫(xiě)產(chǎn)品文檔？

為了以更高的質(zhì)量、更快的速度和更佳的預(yù)判來(lái)交付正確的產(chǎn)品。

是的，就是這樣。那么，產(chǎn)品文檔將如何幫助你做到這一切呢？Ben Horowitz 分享了上圖中這個(gè)看法，我的示例文檔也是一個(gè)很好的例證。明確一下要點(diǎn)：

1. 從一開(kāi)始就理性思考：在團(tuán)隊(duì)開(kāi)始付出更高成本去設(shè)計(jì)軟件架構(gòu)、實(shí)施代碼開(kāi)發(fā)、完善界面設(shè)計(jì)、測(cè)試軟件質(zhì)量之前，寫(xiě)文檔可以迫使你提前思考每一個(gè)細(xì)節(jié)。這將會(huì)提高你決策的質(zhì)量，降低意外事件發(fā)生的概率。
2. 高效溝通：你常常需要和不同的利益相關(guān)方（支持團(tuán)隊(duì)，工程團(tuán)隊(duì)，設(shè)計(jì)團(tuán)隊(duì)，財(cái)務(wù)團(tuán)隊(duì)，管理層等等）溝通你的方案。產(chǎn)品文檔可以幫助你事半功倍地完成溝通，避免口頭溝通中產(chǎn)生的歧義，團(tuán)隊(duì)中的所有人可以更好地理解你的意圖，并且更有的放矢地做出答復(fù)。
3. 明確權(quán)責(zé)：明確項(xiàng)目目標(biāo)的評(píng)價(jià)標(biāo)準(zhǔn)，公開(kāi)承諾獎(jiǎng)懲激勵(lì)機(jī)制：利益相關(guān)方可以知曉如果最后一刻變更需求會(huì)意味著什么，工程師們也會(huì)在預(yù)估工期時(shí)再三斟酌。

產(chǎn)品文檔中應(yīng)當(dāng)包含哪些內(nèi)容？

產(chǎn)品文檔應(yīng)該明確溝通要做一個(gè)「什么」產(chǎn)品，以及「為什么」要這么做。用來(lái)說(shuō)明清楚一個(gè)產(chǎn)品的表達(dá)方式很多，但最核心的，一定要說(shuō)清楚這五件事情：

1. 問(wèn)題：描繪你此次打算解決的問(wèn)題。更重要的是，解釋為什么要去解決這個(gè)問(wèn)題。描述要盡可能地具體，并且提供相關(guān)的數(shù)據(jù)指標(biāo)。
2. 可衡量的目標(biāo)：明確承諾交付和成果，明確哪些事情超出了此項(xiàng)目的范疇。每一個(gè)目標(biāo)，都應(yīng)該可以明確衡量「是否達(dá)到目標(biāo)」。
3. 需求背景：提供你的觀(guān)眾理解當(dāng)前問(wèn)題以及接受你的提議所需的所有背景信息。包括但不限于假設(shè)、用例、數(shù)據(jù)指標(biāo)等信息。
4. 解決方案詳情：你的提議應(yīng)該有充足的細(xì)節(jié)，易于團(tuán)隊(duì)成員消化理解及執(zhí)行——可以把這部分內(nèi)容想象成對(duì)人腦進(jìn)行編程和執(zhí)行。
5. 時(shí)間軸：列出你的團(tuán)隊(duì)共同認(rèn)可的截止日期和其他重要時(shí)間點(diǎn)。這部分內(nèi)容開(kāi)始的時(shí)候可能會(huì)比較模糊，但是在最后一次文檔評(píng)審之前應(yīng)當(dāng)完全敲定。

你可以使用我的示例文檔做你的文檔模板，按照你的想法增/刪/改任何章節(jié)。只要你能夠清晰并且條理清楚地表述上面提到的這五點(diǎn)信息，文檔形式并不重要。

如何寫(xiě)產(chǎn)品文檔？

接下來(lái)我會(huì)介紹我撰寫(xiě)和評(píng)審文檔的常規(guī)流程。根據(jù)項(xiàng)目大小，利益相關(guān)方的數(shù)量不同等情況，流程細(xì)節(jié)可能會(huì)有所變化，但是大體的流程是確定的。

（1）快速完成一個(gè)草稿（1-2 個(gè)小時(shí)）

關(guān)閉電子郵件和聊天工具。泡杯茶，坐在椅子上開(kāi)始思考，然后逐一把你所了解的信息列成清單（見(jiàn)上文中的思路筆記示例）。

（2）安排幾個(gè) 30 分鐘的一對(duì)一會(huì)議 （1-4 個(gè)小時(shí)）

這個(gè)步驟的目的是過(guò)一遍文檔中的細(xì)節(jié)，優(yōu)化你的方案，并且獲得更多人的支持。盡可能控制這些會(huì)議的規(guī)模，人越少越好（理想狀態(tài)下都應(yīng)該是一對(duì)一會(huì)議）。

在本文的示例中，我會(huì)和客服部門(mén)的負(fù)責(zé)人，一個(gè)財(cái)務(wù)人員和一個(gè)工程師分別安排一次會(huì)議。

（3）撰寫(xiě)和編輯文檔 （0.5-3 天）

此時(shí)，你應(yīng)該對(duì)能做，并且應(yīng)該做什么有了一個(gè)明確的想法，但是大腦中塞滿(mǎn)了大量的細(xì)節(jié)等待著梳理清楚。于是接下來(lái)需要將所有這些細(xì)節(jié)都整理出來(lái)，并且逐一梳理斟酌。

在完成第一版文檔之后，需要繼續(xù)大篇幅編輯修改，通常最終的文檔可以在你的第一版草稿的基礎(chǔ)上壓縮 30%-50% 的長(zhǎng)度，簡(jiǎn)潔和清晰的文檔就意味著更加容易閱讀。

大部分文檔都可以在半天到一天的時(shí)間里完成，不過(guò)實(shí)際上也會(huì)有一些文檔需要兩三天才能寫(xiě)完。

（4）群發(fā)文檔并且安排一個(gè) 1 小時(shí)的評(píng)審會(huì)議（15 分鐘）

將文檔群發(fā)給項(xiàng)目的所有利益相關(guān)方，并且抄送給其他可能對(duì)文檔感興趣的團(tuán)隊(duì)（例如你所在的產(chǎn)品團(tuán)隊(duì)，整個(gè)支持團(tuán)隊(duì)等）。

跟進(jìn)這些關(guān)鍵人員是否接受了會(huì)議邀請(qǐng)：將會(huì)執(zhí)行這件事情的人，和所有對(duì)這件事情有通過(guò)/否決權(quán)力的人。

（5）評(píng)審文檔（1小時(shí)）

在開(kāi)始會(huì)議之前，詢(xún)問(wèn)是否有參會(huì)者沒(méi)有詳細(xì)閱讀你的文檔。通常都會(huì)有一兩個(gè)人中槍?zhuān)谶@種情況下可以說(shuō)：「沒(méi)問(wèn)題，我們先用 10 分鐘一起來(lái)看一下文檔。已經(jīng)讀過(guò)文檔的人可以利用這個(gè)時(shí)間先放松休息一下」。

這次會(huì)議上你需要獲得利益相關(guān)方的同意，并且獲得執(zhí)行方（工程師、支持團(tuán)隊(duì)等）的知曉、認(rèn)可以及人力支持。

你可能需要開(kāi)多次評(píng)審會(huì)議，并且根據(jù)評(píng)審會(huì)議上溝通的信息不斷修改文檔。

（6）通過(guò)評(píng)審后，及時(shí)同步信息和建立工單 （1-2 小時(shí)）

會(huì)后同步信息的電子郵件需要包含更新后的產(chǎn)品文檔鏈接，和此項(xiàng)目相關(guān)的工單鏈接（例如「在頁(yè)面上添加 JavaScript 代碼」，「完成數(shù)據(jù)分析報(bào)告」，「測(cè)試 Staging 環(huán)境」，「和支持團(tuán)隊(duì)預(yù)演流程」，等等）。

一般接下來(lái)將會(huì)有一位工程師完成技術(shù)文檔，不過(guò)并不總是這樣（文中的示例項(xiàng)目就不需要這一步）。

寫(xiě)出高效產(chǎn)品文檔的進(jìn)階技巧

盡量簡(jiǎn)短

沒(méi)有比這更重要的文檔寫(xiě)作建議了。簡(jiǎn)潔意味著清晰的思路和溝通，也意味著你的文檔更加易于閱讀和理解——這一點(diǎn)至關(guān)重要。

使用平白的語(yǔ)言和簡(jiǎn)單的格式

使用簡(jiǎn)短而不是花哨的語(yǔ)句，使用列表和加粗強(qiáng)調(diào)可以使文章更一目了然，以放松有趣的方式寫(xiě)作而不是一板一眼，如果你有得體的幽默感就再好不過(guò)了。

為開(kāi)發(fā)團(tuán)隊(duì)預(yù)留時(shí)間

通過(guò)評(píng)審并且達(dá)成一致通過(guò)的文檔才是完善的文檔。如果你希望在未來(lái)的某一個(gè)迭代 Sprint 中開(kāi)發(fā)此項(xiàng)目，就應(yīng)該提前兩到三周開(kāi)始這個(gè)產(chǎn)品文檔寫(xiě)作流程。

像工程師一樣思考

在項(xiàng)目得以進(jìn)入開(kāi)發(fā)之時(shí)，常常會(huì)發(fā)現(xiàn)大量未預(yù)料到的邊緣情況——但這種情形其實(shí)可以避免。如果你認(rèn)真考慮過(guò)項(xiàng)目進(jìn)入開(kāi)發(fā)的所有必要條件，你就可以提前發(fā)現(xiàn)這些問(wèn)題（例如，是否在移動(dòng)設(shè)備中可以使用在線(xiàn)聊天功能？）。

確保每一個(gè)人都跟上了你的節(jié)奏

當(dāng)我組織產(chǎn)品評(píng)審時(shí)，會(huì)議室里的大部分人都已經(jīng)大致了解我要講的內(nèi)容——因?yàn)槲乙呀?jīng)提前在討論會(huì)和日常聊天中溝通過(guò)這個(gè)事情了。既然大家都已經(jīng)清楚了「做什么」和「為什么要做」的問(wèn)題，文檔評(píng)審會(huì)上我們只要關(guān)注實(shí)施細(xì)節(jié)就好了。

在圖表中下功夫

流程圖、線(xiàn)框圖等圖表可以通過(guò)易于理解的方式提供很大的信息量，同時(shí)也需要消耗非常多的時(shí)間來(lái)制作這些圖表。

在思考和寫(xiě)文檔上花 0.5-3 天時(shí)間

具體時(shí)間根據(jù)項(xiàng)目大小而定?；ㄙM(fèi)在寫(xiě)文檔上的時(shí)間越長(zhǎng)，所帶來(lái)的邊際收益就會(huì)遞減。特別需要指出的是，沒(méi)有人能夠讀的下去超過(guò) 5-6 頁(yè)的文檔。

指明方向，明晰愿景

你不僅僅是在定義一個(gè)功能，也是在解釋「為什么我們要做這件事情」以及「我們的目標(biāo)是什么」，在文檔中指出這個(gè)項(xiàng)目將會(huì)對(duì)更高層面的規(guī)劃造成什么影響，以及接下來(lái)會(huì)發(fā)生什么。

確保你的觀(guān)眾閱讀了文檔

如果你的文檔又臭又長(zhǎng)，或者從來(lái)不分享給對(duì)應(yīng)的人，那你還不如不寫(xiě)文檔。務(wù)必確保你的文檔被對(duì)應(yīng)的人閱讀了，我上面關(guān)于評(píng)審開(kāi)始時(shí)留時(shí)間給大家讀文檔的建議值得大家參考。

獲取真誠(chéng)的反饋?

你的文檔是否是在贅述人盡皆知的事情？或者是文檔缺乏足夠的細(xì)節(jié)？是否在后續(xù)實(shí)施中發(fā)現(xiàn)了太多的邊緣情況？又或者，是否在制定計(jì)劃和文檔評(píng)審上耗費(fèi)了太多的時(shí)間？你應(yīng)該和你的團(tuán)隊(duì)時(shí)刻保持溝通。

說(shuō)好的敏捷開(kāi)發(fā)（Agile/Scrum）呢？

我知道會(huì)有爭(zhēng)議，但是產(chǎn)品文檔和敏捷宣言的原則沒(méi)有絲毫沖突，并且在類(lèi)似于 Scrum 這樣的敏捷方法上得到了充分發(fā)揮。
畢竟，用戶(hù)故事（Story）許多時(shí)候需要詳盡的描述，文檔可以增加溝通中的清晰度和可傳播性，為什么非要刻板地認(rèn)為僅僅使用口頭溝通和使用白板才算是敏捷開(kāi)發(fā)呢？

「產(chǎn)品文檔會(huì)導(dǎo)致發(fā)布變慢，過(guò)度規(guī)劃，通常會(huì)浪費(fèi)時(shí)間」的想法完全是無(wú)稽之談。

我工作過(guò)的多個(gè)世界級(jí)團(tuán)隊(duì)遵循著一些敏捷原則（例如兩周一個(gè)迭代周期），每天（甚至更頻繁地）發(fā)布代碼，并且以發(fā)布產(chǎn)品（而不是文檔或者會(huì)議）作為衡量成功的標(biāo)準(zhǔn)——這些團(tuán)隊(duì)也都仍然認(rèn)為文檔是他們打造成功軟件的一個(gè)關(guān)鍵部分。

你對(duì)技術(shù)文檔怎么看？

我是一個(gè)技術(shù)文檔的支持者。產(chǎn)品文檔通常關(guān)注 做什么 ，而技術(shù)文檔更多關(guān)注在如何做 。這兩種文檔為研發(fā)流程中的不同環(huán)節(jié)帶來(lái)同樣的清晰視角，并且都使得工程師（和他們的用戶(hù)）身心愉悅。
未來(lái)如果大家有興趣的話(huà)我可能會(huì)寫(xiě)一篇關(guān)于技術(shù)文檔的文章。

總結(jié)

感謝你讀到這里。如果你認(rèn)為這篇文章有用，請(qǐng)分享給其他人——特別是你的產(chǎn)品/工程團(tuán)隊(duì)。

如果你想看更多的產(chǎn)品經(jīng)理內(nèi)容（例如：規(guī)劃產(chǎn)品路線(xiàn)圖），或者想了解其他人如何使用產(chǎn)品文檔， 請(qǐng)用兩分鐘填寫(xiě)這個(gè)小調(diào)查（英文） 。我會(huì)在未來(lái)的文章中分享調(diào)查結(jié)果中有意思的信息。

以上，祝寫(xiě)文檔愉快！

備注

1. 感謝周思博（Joel Spolsky） （微軟早期 PM，曾參與創(chuàng)辦 Stack Overflow，Trello，F(xiàn)ogBugz 等產(chǎn)品，《軟件隨想錄》作者）的「文檔是對(duì)人腦的編程」的比喻。早在2000年，他寫(xiě)了4 篇關(guān)于文檔的系列文章（英文） ，這對(duì)我的 PM 道路產(chǎn)生了巨大的影響，強(qiáng)烈推薦。
2. 在頂部的引文中，貝索斯所說(shuō)的筆記是指為高層管理會(huì)議使用的，介紹新業(yè)務(wù)/產(chǎn)品創(chuàng)意的備忘錄。這實(shí)際上不算是產(chǎn)品文檔，但是兩者并不是完全不一樣。貝索斯在會(huì)議開(kāi)始的時(shí)候會(huì)組織所有人默讀文件——這激發(fā)了我在文檔評(píng)審時(shí)做同樣的事情。來(lái)源
3. 感謝 iDoneThis 博客這篇關(guān)于寫(xiě)作的價(jià)值的文章（英文）。這是貝索斯和 Horowitz 的引言的來(lái)源。
   感謝 Vikram Oberoi 。

原文作者：Gaurav Oberoi 是 SurveyMonkey 的（前）聯(lián)合創(chuàng)始人，曾于 Amazon、Xmarks 先后從事工程師、產(chǎn)品經(jīng)理等職位，在西雅圖和硅谷有十余年的工作經(jīng)驗(yàn)。

原文地址：https://goberoi.com/on-writing-product-specs-5ca697b992fd

翻譯：Tomy

譯文地址：http://zhuanlan.zhihu.com/p/23778590

本文由 @Tomy 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。