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

本篇本來打算寫如何跟技術進行溝通，其實跟技術的溝通，是貫穿于整個從需求文檔到產品上線、產品跟蹤、迭代的過程之中的。本篇更多的是講作者工作半年來，從需求文檔到產品上線的過程，也希望與同行朋友多交流。

需求文檔看不看

當你辛辛苦苦寫出來一堆需求文檔，跟UED的同學定好交互、視覺、重構；滿以為技術會認真對待，但是你會發現，技術同學基本不會看你準備的一堆東西，基本是按照自己的理解來開發，當開發不下去，第一時間也不是看文檔，而是看測試用例，或者直接跟產品溝通；基本文檔只是QA同學對著寫用例。

剛剛開始工作的時候，對于技術不按照文檔開發，是比較著急上火的，經歷一段時間后，發現重點就好了。產品的本質是保證產品核心功能的質量，保障用戶體驗，用戶端和商戶端的功能不能含糊；運營后臺、客服后臺之類的，保障功能完整和業務流暢的基礎上，可以給技術適當的自由發揮；就算是前臺頁面，多聽聽技術的意見，讓技術同學參與進來；開發過程中，保持溝通，對于技術提出的問題，最快速度的響應。

什么樣的需求要寫文檔？對于功能性、涉及業務流轉，狀態切換，邊界條件灰常多的需求，流程圖、交互、PRD一個都不能少；對于非功能性的需求，提升用戶體驗的部分，文檔可以不準備，準備好原型圖，然后在上面標注出重點，交付的時候講清楚。

todolist與優先級

產品在迭代過程中，不斷有新的需求，不斷有需求被完成，通過list來管理這些需求，整理的過程也是對產品思考的過程，不停問自己，這個需求用戶是誰，解決什么問題，是否必要，以及是否必要現在就做？

list的好處就是，可以盡量多的記錄所有需求，雖然有些天生就是被砍的命，但是list一堆需要完成的事情，對整個項目組都會有緊迫感；一句話講清楚每個需求，標明優先級，負責人，對應的開發，開始時間，完成時間，完成狀態，讓項目組所有人（包括老板），都知道我們現在有多少事情在做，已完成來多少，接下來做什么。

需求永遠做不完，對于優先級安排，平時工作中最常用的就是四象限法，重要又緊急，重要不緊急，緊急不重要，不緊急也不重要，根據項目實際來做判斷。

需求會議

12年都是一周一次迭代，每周都會有下次迭代的需求會議，并不是真正意義上的需求評審，產品驅動的公司，基本就是需求講解，交付，以及相關時間點確認

需求準備要充分

在需求會議上，面對技術和QA，甚至老大們的挑戰，這是正常的，他們會問為啥要這么做，為啥不那么做，甚至直接對你的需求提出挑戰：這個東西不靠譜，不可能；拍桌子打板凳的事情也時有發生；唯一避免發生的情況，就是對于需求的準備要充分；不管面對何種挑戰，講清楚數據、用戶需要、和競爭對手怎么做的，基本就能說服；一般只要保持平和的心態，不會有大問題。

真有自己無法立即解答的，快速承認錯誤：不好意思，這個是我沒有準備好，會后我再去做詳細調研和準備，快速跳過這個問題，繼續下面有把握的內容；會后再去完整論證，并把問題描述清楚，郵件給大家；既可以避免沖突，會后大家平和心態來對待，也便于解決。

講好我的故事

這里應該是講好用戶的故事，為啥叫講好我的故事，因為產品需要把自己代入到各個角色中；做過幾次用戶訪談，很多用戶描述這樣一個場景，我快下班了，拿出點評App搜索附近找吃的；運營說這個這個很煩，我需要這么這么做，其實可以這樣就解決了；

客服說，這個信息在這里查，那個信息在另外一個頁面，每條記錄處理的時間增加多少分鐘；

最有意思的是商戶端，商戶那邊有簽合同的、店長、負責人、前臺、收銀，會計，每個人都有可能來用我們的后臺，去商戶端做訪談的時候，觀察他們如何使用點評的產品；

講需求的時候，先描述用戶遇到的困境，繪聲繪色，動人心弦；如何做到，代入自己的角色，不要假裝用過，而是自己真正使用過程中的痛點，放大再放大，感情方式來打動技術。

描述痛點只是第一步，可以清楚描述，如果這個需求做來，運營效率可以提升多少，節約多少成本，最終轉化率預計提高多少，以及ROI（投入產出比），所有功能點的改進，最后都可以結算為Money，因為錢，會讓所有人興奮，并集中精力來解決問題。

讓更多的人參與需求討論

需求被挑戰，會有點不舒服；但是若所有人都表現出對你的需求漠不關心，那才是最難受的。如何讓技術更多的參與需求討論：首先可以挖掘對業務有興趣的人，多跟他們聊，他們會主動告知他們的想法。一般工作幾年的技術比剛剛工作的童鞋更關心；其次讓技術有存在感，定時告知他們相關的產品數據，月用戶數，月增長量，收入等，根據技術所開發的功能點，細化到此功能帶來的數據，以及同比環比數據；最后在Scrum中，計劃撲克能夠讓所有人都參與到需求當中，因為每個人都要評估task的工作量，目前來看，效果還不錯。

確定好時間點和相關責任人

Scrum確實是一個好的方式，能夠估算出工作量，并且技術自發領取任務，直至每個人工作內容都填充滿整個sprint。
在未開始Scrum之前，每周一次需求會議，只是交付好相關需求，由開發主管來指派任務，并定好工作計劃表，然后QA同學補充相關測試安排，最后敲定上線時間。

其實不管何種方式，最終的結果導向就是，產品盡快上線，且以最有效、風險最小的方式。

適當地砍需求

產品是不需要懂技術，但是如果能根據需求大致預估工作量，排期更簡單；每次我都會提前多準備一些，連交互和重構都準備好，擺出一副不做此需求是誓不罷休的架勢；資源充分時，技術童鞋會主動領取需求的，但是當工作都排的比較滿的時候，就很難了；所以需求評審時，每個需求的優先級都排的高高的，將用戶痛點描述的栩栩如生，如果技術實在抱怨太多，那就象征性地砍掉部分，前提是保證核心必須完成，其實當砍掉一部分，不會一直砍下去，而且心里也會有滿足感；其次給技術緊迫感，趕緊完成，后面還有一堆事情呢，即使這次迭代不做，下次迭代也需要完成

產品開發過程中

保持溝通

在產品開發過程中，技術都是非常有責任心的，會幫你考慮邊界條件，作為產品積極響應技術提出來的各種疑問，是維系技術與產品之間很有效的方式。雖然有一些問題，可能是技術對需求的理解并沒有產品那么深刻，講清楚就好了，沒有必要上綱上線，因為最終大家的目的都是為了產品，另外公司開始實踐的Scrum也對整個團隊保持溝通，既是要求，更要成為一種習慣。

認真對待測試用例

測試用例，又是一個保證產品質量的利器；剛開始工作的時候，認為測試用例只是QA同學的工作，第一版本App上線做UAT的時候，發現對著需求文檔并不能完整驗證完所有需求，但是對著測試用例，所有的主流程，輔助流程，邊界條件，非功能性需求，清晰明了，感覺太有用了。所以每次都提前完成需求文檔交付QA，QA在技術正式進入研發完成用例文檔；在過測試用例時，產品同時參與，避免一些需求理解上的偏差，此外技術同學對著case開發，比需求文檔描述更清晰，另外技術同學可以參與部分自測；UAT的時候，也是產品的參考。

需求變更與delay

需求變更是永恒的話題，Scrum中一般是不接受需求變更，其實不允許變更的本質不是需求定板不動，而是對產品提出了更好的要求，從需求調研、準備、設計、交付每一步都需要考慮周全和清楚；即使在要求嚴格的Scrum中，需求真的不能變更么？如果臨時線上bug造成用戶無法訪問，技術同學是不是要停下手中工作，來排查線上故障呢。作為一個產品，不是神，盡量保證所有的需求都是合理且必要，并且將所有的需求準備工作做到位；如果還不能避免，就要影響甚至說服整個團隊來擁抱變化。

正確處理需求變更

需求變更已經發生，那就趕緊處理吧。如果是產品沒考慮清楚，用戶調研或者數據支持出錯，果斷向團隊承認自己的錯誤，沒有人會責怪一個真心誠意道歉的人；并在第一時間交付變更后的需求文檔、交互、視覺、重構等，并跟技術溝通如何以最小的代價，完成此次實現；若技術的工作在本次迭代已經安排很滿，那考慮需求的緊急程度，適當情況下，可以放到下個迭代去完成。

若是因為行業或者市場變動，產品轉型等原因，直接向團隊傳達變更的原因，以及接下來的產品規劃，讓所有人都看到一個清晰明確的目標，技術會有疑問和挑戰，耐心解答，通過行業數據、競品等角度去闡述；遇到老板變更需求，那比較簡單，因為老板的需求優先級永遠是最高的，但是作為跟技術直接溝通的產品，要認真對待老板變更的部分，若老板頻繁變更需求，煩的是技術，會不會以后合作留下影響呢。

關于產品delay

不管產品還是技術，沒有人愿意看到delay的；面對delay，怎么處理？換個思路：就算delay了，只要用戶還能用，服務照樣跑，地球還照樣轉。如果真的導致用戶不能訪問，整個技術團隊肯定加班加點，不吃不喝也會搞好的。一旦出現delay，整個團隊一起來排查delay原因，是需求變更，還是資源沒到位，還是項目之間的耦合關系，前面小的改動，導致后面項目的延期，做好每次的總結會議，并在下一個迭代中避免此問題。

目前團隊中正慢慢引入Scrum敏捷開發，而本篇總結，大部分是基于小瀑布模式的迭代；需要學習的還有很多，一轉眼又過了兩個月，正式工作已經八個月，需要走的路還有很多，跟隨整個team一起成長。

本文作者系大眾點評產品經理@七手八腳裸奔地小石頭。來源：leiphone.com