［OEM嘅嘢］非聲討，樓主都冇好惡咁鬧。況且一向我唔鍾意審人。你見我一定打格仔（而家post都刪埋）。所以純學術討論。
不過認真，700蚊有咁嘅早餐畀你，還神啦。仲特登幫你買，我真心覺得應該表揚間酒店！隻蛋我幾想食（得，我知，粟米肉粒飯嘛）
朋友話銀龍好過啲三星酒店嘅油淋淋早餐。我raise ，四星都係！當然好睇你啲星點定。但結論都係700有咁嘅早餐十分超值
（得，我知銀龍粟米肉粒飯）
又，我好細個已經諗呢樣嘢，會唔會啲高級餐廳都係OEM，大排檔買嚟畀你。大個見啲酒吧真係咁，去隔離買豬頸肉畀你咋。
當然講到尾，係鬥個「氛圍」，感性消費。鬥食材鬥廚藝鬧裝修都未夠高，好易抄。
competition is for losers。我個廚八歲由越南🇻🇳偷渡嚟 十歲死老母十四歲落仔 然後自學成才再著到Maggie Q咁出嚟影相，包你冇得抄。
唔係話只講包裝不講實力，咁首先你都要識煮嘅（但，麥玲玲羅庚都未識睇啦，who cares？）。但得罪講句，好多領域，你有幾多人真係blind taste分到 唔同嘢？30蚊同300蚊紅酒分得出。5000同50000呢？其實有冇分別？
呢個亦係好多「技術人」嘅盲點。你講音質好 像素勁，但啲消費者係分唔到阿嬌同阿sa 嘅盲毛。蘋果幾時同你鬥spec？
況且spec有得鬥，叫做有客觀，3T好過2T，9秒8快過9秒。但音樂，寫文，煮嘢，點分高下？
講返OEM，咁啱呢排我老豆生日。一件小事，好似細個去半島定乜，充大頭鬼（佢），嗰時我已經諗，點解幾廿蚊杯汽水都有人叫（當年大家樂食個飯六七蚊）？咪又係一罐嘢。總係有啲嘢。
咁當然細細個已經知食裝修呀溝女呀呢啲。但另外仲有一次，老豆先同我講，實會斟埋畀你呀，加塊檸檬🍋呀，甚至有花生咁。
呢啲，就係「差異化」，未必令你忘記背後都係可口可樂生力啤，但至少令你覺得可以justify 。
即係同一個道理，啲奀星𡃁模KOL，只要求其搵拍過套 《喜愛夜蒲曼谷版》，片尾有名嘅。就已經身價唔同啦。明星喎。明星喎。
所以，我同意有人回（原post已刪），理應該掉走個銀龍袋佢嘅
當然如果係再高級啲嘅，倒出嚟自己再擺盤都仲得，加多塊蕃茄青瓜又收你舊幾水。
同以上酒店可樂同一道理，我細個住酒店，係唔明做乜有人會畀咁貴錢在房食早餐。當然首先貧窮限制我想像，二來嗰時唔知有唔少人可以開公數，三來最重要係春宵一刻直筆甩，那年冬天蕭在吹，有女伴嘅，唔好話落去食早餐，真係落床拎杯水都懶啦
on an unrelated note，關於粟米肉粒飯，再講一次。實不相瞞，有一期，97年夏天，我有一排成日都食銀龍茶餐廳早餐，仲要係西洋菜南街，洪葉書店樓下嗰間
原因？嗰時返暑期工。屯門去九龍塘，my god。就係巴士旺角落，再轉地鐵。就日日食銀龍。然後我就由A level 學霸變成大學second lower 。諗落應該搞個集體訴訟class action （香港係冇的）
暑期工就在浸會大學，冇Q嘢做。我每日最開心就係下午茶（自己）鼠出去睇女。新舊校園我都返過，新校睇李惠利嘅女，舊校咪睇浸會女。心諗有一日到我食。結果後來就食到，其實唔難。
我在浸大嘅日子，就係幫人影印，同埋送文件。最初我拎本書返去睇，後來當然被勸止。結果我拎本書去影印，得閒幾頁咁，拎住疊紙就冇人理我。果時就睇西洋文學，《雙城記》呀《孤星淚》呀咁。
呢啲可歌可泣嘅故事，記住keep多幾個。
牛年比別人知得多。subscribe now.
Patreon.com/ivanliresearch
spec文件 在 [心得] PM分享：如何撰寫產品需求與規格文件？ - 看板Soft_Job 的推薦與評價
各位大大中秋節快樂，我是在軟體業工作的PM，
之前有分享過我跟夥伴們一起寫的PM工作與職涯相關文章～
這次的分享是關於PM該如何撰寫產品需求與規格文件，
這也算是我跟工程師合作上的一個痛（之前寫太爛、工程師都懶得看），
好在跟我合作的工程師們人很好，給了我滿多回饋，
在這幾年工作中也得到一些心得，希望可以跟大家交流！
如何撰寫產品需求與規格文件？問題、心法與實作小撇步！
有圖有排版完整版：
https://pesc.pw/LQBAD
什麼是產品需求文件？
我在【PM夥伴攻略】如何跟工程師合作？中曾經寫到 PRD（Product Requirements Document 產品需求規劃書）這個文件類型，有時也叫做產品規格書（Product/Feature Spec），更小型的功能修改則可能只是一張票（Ticket）。PRD 內容通常包含：
【目標＆問題】
- 產品目標、預期產出
- 問題、指標、假設
- 使用者分群＆使用情境
【解決方案】
- 使用者故事（User Story — As a … user, I want to …, so that …）
- 使用流程與設計（User Flow / Wireframe / Mockup，PM、設計師負責）
- 產品規格細節、系統邏輯、極端使用情境（PM、工程師、QA 負責）
【其他注意事項】
- 功能範疇（Phase 1, Phase 2 …）、功能相依性（Dependencies）
- 功能上線策略規劃、市場溝通策略
- 未來擴充可能、後續規劃（上線後的下一步是什麼？）
- 其他參考資料：使用者研究、競品研究、會議記錄
每天寫這些文件都快堆得比人還高，為何 PM 苦口婆心用心良苦歸心似箭地產出詳細而精美的文件，有時卻會被詬病，甚至最讓人困擾的，工程師不看文件、不照著規格開發？
問題：為什麼！為什麼工程師就是不能好好用心仔細地看看產品需求文件？
因為從他的角度，這份產品需求文件無法達成有效的溝通。
讓我試著從工程師的角度來思考一下他們遇到的問題：
1. 文件太長，根本不知道重點在哪裡。
這一段是寫給我看的嗎？怎麼感覺是寫給老闆或 PM 主管看的？雜七雜八到底要我看哪部分？
2. 文件內的需求、規格細節寫的不清楚。
這文件真的寫完了嗎？還是又要我通靈？發文不附圖，此風不可長。
3. 文件總是都一直改、或沒更新。
實在無法信任我看到的任何一個版本。敏捷起來，連我自己都會怕。
這些問題導致工程師覺得看了文件也沒用、懶得看，不如直接抓 PM 本人講個清楚，或是先照自己的想法做，等到測試時看 QA 或需求單位最後提什麼問題再來修。這之中的來來回回不但造成時間與精神成本的浪費，也顯示出文件本身並沒有有效達成他的目標。
其實不只是在與工程師用文件溝通時會遇到這些問題，產品規劃涉及很多不同的單位，例如商業端（客服、業務、老闆）、設計師、工程師、QA、其他 PM 以及主管，我也遇過丟出文件後卻沒人回應、沒人提意見、沒人看的狀況，可能的原因就是我寫的內容沒有正中要點，或是我根本選錯溝通方法。與其用文件，很多時候當面溝通完再用文字記錄下來會是更有效率的做法。（只用口頭開需求也是會被電爆的，請自重！）
解法：先確認目的與對象，再來有目的的撰寫
寫產品文件就跟做產品一樣（跟這世上的萬事萬物都一樣），要先確認使用的對象是誰、我想要達成的目的是什麼，瞭解他們到底想要/需要看什麼後，再來設計這份文件的內容，有目的的寫文件以確保觀看者可以得到他想要的資訊，來達到實際而有效的溝通。
【目的】
・我為什麼要寫這份文件？
・我希望它達成的目標與結果是什麼？
・這是一份主要文件、還是參考文件？
・若是主要文件，哪些參考可以直接附上，避免重工？
【對象】
・誰會看這份文件？
・他將如何使用這份文件？
・他預期在這份文件得到哪些資訊？
・他習慣的文件格式是什麼樣子？
回到上面那份落落長的 PRD 來看，對於工程師來說，瞭解目標、使用者研究、使用情境也許重要，但這些都是次要資訊，僅需要在專案一開始時確認沒有問題就行；而最重要的其實是產品要如何修改、功能細節的規劃，這些跟工程直接相關的實作細節。
舉一個各司其職、效率極大化的例子，在產品需求文件中 PM（你、團隊、主管）想了解價值（outcome）、QA 想直接看到產出（output）長怎樣、工程師則需要知道實際要做哪些改動（changes），一份文件的確可以滿足所有人「想看到相對應資訊」的需求，但單單一份統一的文件可能無法達成「有效率的傳遞資訊」的目標。
流程：在對的時間，用對的方式溝通對的內容
而儘管是跟同一個對象，可能會因為不同目的在不同的時間點溝通，這時溝通方式、文件的內容也會不太一樣。以這個流程舉例：
1. 確認產品目標、商業問題 / PM 主管、商業端團隊
2. 討論目標、問題、指標、假設 / PM 團隊、設計師、資料團隊、工程團隊
3. 討論使用情境、發想不同解法、確認解法 / PM 團隊、設計師
4. 設計使用流程、功能介面、研究與測試 / PM、設計師
5. 確認使用流程、功能介面、規格細節 / PM、設計師、工程師
6. 回去修改，再來確認修改過後的 PRD / PM、設計師、工程師、QA
7. 討論開發實作（切 Phase、切 Story、資源時程） / PM、工程師
8. 與商業端確認改動與上線規劃 / PM 主管、商業端團隊
9. 將以上所有討論內容的最終結論寫下，PRD 最終版本定案！
口頭溝通還是很重要
以上每個階段，主要都還是仰賴口頭溝通（當面、視訊），再以不同階段、不同完整度的 PRD 作為輔助文件。產品開發是團隊合作，同一份 PRD 會隨著團隊的討論而慢慢變完整，就算 PRD 最終版本已經定案（希望是真的 final 版本），在正式開發前、中、後，還是需要大量的口頭溝通！
PRD 作為最完整的文件之一，最主要還是 PM 自己要看的，當要 brief 給工程師或其他成員時、當忘記某個討論過的細節時、當要分享給其他團隊作為參考時，它就會是個很棒的資料來源。
階段性溝通完成後，持續調整文件類型與內容
當要開始實作時，在一開始用完整的 PRD 跟團隊成員 brief 完產品需求與確認規格後，可以直接將拆分的 Stories 開到專案管理工具裡面，每張 Ticket 只寫上那個任務需要完成的工程實作細節、產品畫面，並將 PRD 反作為參考資料，讓工程師在開發的時候可以專心在實作上。
原先的 PRD 可能隨著你們釋出一些 Stories 、得到一些回饋後需要修改、變換方向，或甚至是建立一份新的 PRD 開新的需求，那也代表又進入一個新的階段，文件類型和內容又需要重新調整了。
實作小撇步
1. 溝通前先說明目的並畫重點
傳遞文件與溝通時，明確告訴對方目的、預期結果，並幫對方擷取出重點。不要期待他會把整篇 PRD 完整看完，很多人看到落落長的文件會想說晚點再看，然後就沒有然後了。因地制宜、設身處地為對方著想，主動讓他知道哪邊是最重要的部分，其他則是次要的參考資料。
更清楚一點，文件中待確認的部分也可以用紅色標記大大的 TBD（To Be Discussed）讓對方一眼看出要討論的部分！
2. 視覺化、圖像化
圖像永遠比文字表達得更清楚，討論時可以溝通細節，實作時確保所有人認知一致，附上流程圖、Wireframe、Mockup 是基礎中的基礎，就算只是手畫的都好！
3. 條列目錄
最核心的問題是「我如何寫一份架構邏輯完整的文件？」但是這部分會因人而異，PM 與工程師思考的順序、邏輯、對每個段落的重要性看法不同，因此為了讓事情更明朗，至少在比較大篇幅的文件中放個簡單的目錄吧！也別忘了用錨點超連結，讓使用者可以一鍵到達他想看的部分。
大部分線上協作文件的軟體都內建有這個功能（Google Doc, Confluence, Dropbox Paper），只要確保自己有設定對、使用者也會使用就行了！
4. 從看文件的使用者身上蒐集回饋
其實上述使用目錄的建議，就是我在跟工程師討論為何他覺得我寫的文件很難看懂後，我們想出的其中一個修正方法。
舉例來說，我寫 PRD 的邏輯是按照我的思考順序寫下來，並把所有參考資料放在文件開頭；但他在閱讀 PRD 時認為應該要把最重要的、他需要知道的資訊放在最開頭，隨著重要程度遞減，將參考資料放在文件最尾端。
修改寫 PRD 的順序對我來說並不理想，況且這份文件也會給其他人看，每個人肯定會有不同的看法，因此我們討論了一些在不需要修改文件順序與架構的情況下可以改善的解法：
- 條列目錄 + 錨點超連結
- 用不同顏色的標題來區分不同目的的區塊（例如：商業相關、使用者相關、工程實作）
- 傳遞文件給特定對象時，在文件中收合（隱藏）某些區塊，使用者想看再自己打開
每個團隊、每個工程師喜歡的工作方法不同，這也是為何我會在文章一開始提到，文件怎麼寫、格式怎麼設定、要寫多細，這些都是「看情況」。有些公司就是一個步驟一個步驟嚴謹的走下來，不會有太密集的討論，有些公司則是隨時都在找不同的人開會討論、做新的決策，他們會需要的文件和溝通方式就絕對不同，因此從一起工作的夥伴身上得到回饋是最快的修正方式！
文件只是一個溝通的工具
說到底文件就只是一個溝通的工具跟自己溝通、跟正在一起工作的團隊溝通、跟未來不認識的交接同事溝通。
文件能作為良好溝通工具的原因，在於它具有穩定性與可傳遞性，在穿越時間（歷經多個月的專案）與空間（跨國團隊）的情況下，能夠讓所有人得到一致的訊息，如同英文所說的 ”on the same page”。
放到近代的話，線上文件工具不但可以讓多人同時協作，也可以看到歷史變更紀錄，方便團隊回去考察在過去時間點做的決策與變更，讓整個溝通的過程能夠輕易的攤在觀看者面前，同時確保公司與團隊能夠有組織性的維護共同知識，持續做經驗的累積與傳承。
除此之外，我私心認為寫文件也是一個與自己溝通的工具，在下筆的過程中更透徹地思考整個專案，大至目標、小至細節，反覆雕琢進而讓問題的形狀更清晰。
所以說何時該寫產品文件？要寫多細？
既然是溝通的工具，就應該只在「使用文件溝通是最有效率」的情況下使用它。重點不在於文件，而在於它是否能讓溝通更順暢，別讓文件的產出與維護成本超出了它所能帶來的價值。
儘管這篇文章主要在分享 PRD 的實作，但廣義來說，我認為所有為了溝通「產品」相關資訊而存在的文件，都算是產品文件。包含了：
- 產品路線圖（Product Roadmap）
- 產品需求規劃書（PRD）、產品規格（Product/Feature Spec）
- GitHub / JIRA / Trello Ticket
- 產品使用說明
- 產品會議記錄
在修修改改了好多不同版本的 PRD 格式後，我發現其實也不用拘泥於格式（網路上可以查到的格式真是千奇百樣），不用每次都像填表單般把每個欄位空隙填滿，只要能夠達成有效溝通的，都會是一份好文件！
畢竟如果一張 JIRA Ticket 就可以講完的事情，就用不著在 Confluence 寫一篇落落長的需求文件。
PRD 是你的產出，但不是你的產品，產品上線後產生的影響力才是 PM 真正重要的工作，因此善用產品文件來說服利害關係者、跟實作者溝通細節，進而推動產品影響力才是真正重要的事！
--
以上，歡迎給我們回饋與意見！
3PM LAB Medium: https://medium.com/3pm-lab/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 126.244.195.61 (日本)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1568453496.A.2D2.html
文件只是個溝通、紀錄、達成共識的工具，格式不是重點！
與其寫產品文件，PM 寫幫忙 Test Case 做測試還對團隊比較有幫助（那時沒QA）
偷分享我寫的另一篇文章：https://pesc.pw/L9HPF
... <看更多>