需求會議
2023年都是一周一次迭代，每週都會有下次迭代的需求會議，並不是真正意義上的需求評審，產品驅動的公司，基本就是需求講解，交付，以及相關時間點確認
需求準備要充分
在需求會議上，面對技術和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一起成長。
算是工作總結吧，主要是自己梳理一下，路還長，繼續跟著一班牛人加油唄！
一線工作法
上海楊浦區委，敢於創新，打破傳統的群眾工作方法，在2004年12月，建立了 一線工作法 它規定每個月的第二個星期四的下午，全區的處級領導幹部定點下基層，到群眾中去，直接聽取老百姓的意見，並且要解決群眾的實際困難。當你坐在群眾中的時候，你就是 一線工作法 的一名工作人員，群眾提出的各種問題，你都要去協...
一線大客戶經理營銷心得的啟示
替馬嘯 把握時機疏梗阻 一線大客戶經理營銷心得的啟示 在市場競爭日趨激烈的今天，電信營銷工作難做，這是廣大客戶經理的共同感受。特別是在與客戶溝通遇阻後，如何做好跟蹤服務，敏銳關注客戶動向，使客戶最終選擇企業產品，這裡有乙個時機把握的技巧。筆者結合自己在營銷實踐中的體會談幾點膚淺的認識。一 巧打同行攀...
如何提高一線經理工作有效性
我在生產廠工作，所談的是如何提高生產系統一線管理者的工作有效性問題。從企業組織的角度來說 要想提高工作的有效性首先你要選對人 要選擇那些有責任感的人，工作細緻謹慎的人，身先士卒的人，努力尋求改善提高的人。通過公正合理方式和途徑選拔幹部，並對用人的效果進行跟蹤。選拔過程應體現公平公正和透明的原則。要有...