1.理論與實踐差異
問題場景：計畫和風險(進度、質量等)在實踐操作中有偏差
解決辦法：計畫先行，盡早暴露不好的風險，最小成本處理
2.研發質量提高
問題場景：功能調整影響原功能(反覆、驗證成本)
解決辦法：自測、草稿設計、草稿場景驗證
3.測試質量提高
問題場景：常規、非常規測試，功能點測試要點不足
解決辦法：多業務場景測試用例、功能點測試要點羅列
4.計畫執行偏差較大
問題場景：過於理想評估計畫，實際執行不可預期偏差較大
解決辦法：要做充分計畫，羅列計畫要點，預留足夠緩衝時間
5.集中測試對進度干擾大
問題場景：功能開發調整完畢，集中提交，測試驗證時間較長
解決辦法：區域性交付，做階段性驗收測試，確保已驗證功能穩定性
6.客戶驗收緩慢
問題場景：客戶遲遲不願驗收，是因為一些不太願意說、做的事情要做完
解決辦法：多與客戶溝通，找到客戶顧慮，解決痛點，推進下一步
7.後期測試發現重大漏洞
問題場景：發現重大漏洞，雖不是我們這邊導致的，但對整體專案影響不好
解決辦法：專案經理要多想，要替客戶多想，把控範圍、進度、質量、風險等
8.注意與客戶溝通方式
問題場景：與客戶溝通，不要用理論的形式交流，多關注客戶的痛點
解決辦法：注意把控不同角色關注點，平靜、平和、淡定，莫著急，平穩推進
注意良好溝通方式學習，平息對方顧慮和急躁，以合作共同解決為出發點
9.多做一點，可減少很多成本
問題場景：研發提交的功能總會留乙個小尾巴，測試覆蓋測試也不太嚴謹
解決辦法：在不超範圍前提下，如果只是成本(進度、質量、實現難易程度)很小，風險很小，
對功能優化、功能bug修復、功能體驗公升級，那就隨手多做一點，可以達到很好的效果
10.客戶提出的無理要求
問題場景：客戶針對模糊的需求提出可擴充套件的無理要求，甚至超需求的無理要求
解決辦法：跟客戶很好的溝通，把範圍往小了圈定，針對最根本的痛點，滿足最小的需求
不是不做，可以做，往小了做，解決目前最緊急、最根本的痛點問題，以解決問題為宗旨
11.客戶提出的需求和問題
問題場景：客戶說要對某個功能設計進行修改，客戶說要實現某某需求
解決辦法：客戶告訴你的未必是他真的想要的，需要多場景、多角度幫他分析，讓他自己深入分析，並告訴你結論這到底是不是他想要的
如果不具備快速驗證發布條件，不需要那麼快的響應速度，避免朝令夕改，很是頭痛和疲憊，幫他們深入分析，讓他們想清楚他們真正想要的是什麼
1.研發提交測試流程
問題場景：
研發修改bug完畢，未進行**發布，直接將bug狀態進行修改，測試回歸bug，未通過是因為未發布。
假設昨天測試提交的bug，昨天開發改好了，把bug狀態改為已解決，卻沒有進行發布。
今天測試登陸，看到bug已解決，進行回歸測試，驗證還是不可以。其實是沒有發布導致，浪費測試時間。
解決方法：
為提高團隊運作效率，大家有成效的工作。
研發修改完bug，在相關調整功能發布之後，再到bug管理平台修改bug狀態。
2.缺陷提交規則
問題場景：
測試測過的功能，還潛藏著嚴重的bug，或是一些不合理的邏輯操作、不合法的資料操作還是會有bug產生。
使用者使用場景測試不全，只進行符合規則的資料進行測試，卻沒有進行非法資料、非法操作進行測試，測試深度不夠。
測試使用操作不方便，不好用，跟常規的使用習慣不一致。
解決方法：
測試為確保專案質量，需要進行多瀏覽器、多邊界值、各種可能的使用者場景、不合規的操作、不合法的資料進行測試。
bug都要登記bug管理平台，嚴重bug需要研發進行解決，非嚴重bug研發酌情處理，
非嚴重bug登記，也是以防問題或是好的優化建議被遺忘(優化需要討論確定修改方案)，為孵化產品做優化儲備，提高產品易用性、提高使用者體驗。
3.為什麼要組織相關評審活動
評審的目的是為了在真正投產前，進行設計把握，整合大家的意見，以確保該項檔案或是該項活動是正確的、有價值的，降低一些不可預期的成本損失。
如：需求的遺漏、設計的不合理、專案管理的不到位、質量風險等等。
4.某模組問題層出不窮
問題場景：
研發對乙個功能完好的模組進行功能調整，導致產生不必要的bug和問題，而且未經充分測試直接丟給客戶。
尤其是在推動使用者驗收，進行驗收測試的時候，更需要保持執行環境的穩定性，如果出現重要模組的重大bug很不好。
解決方法：
研發對功能進行調整，不能盲目自信，一定要自測，且覆蓋到相關的使用場景；
如果研發沒有時間測試，一定提交到測試部，讓測試人員進行充分測試，不能把未經測試的**直接發布丟給客戶使用。
5.研發工作被打擾
問題場景：
來自客戶的問題、現場同事的問題、測試同事的問題，直接找到研發這邊處理的，都會對研發的開發工作造成中斷。
研發一旦被打斷需要重新梳理思路，容易導致**不嚴謹，潛藏一些bug在裡面。
或是陷入整天忙於處理問題，而忽略主體功能開發工作；處理的小問題，而影響大功能。
解決辦法：
緊急嚴重問題，及時響應處理；非緊急嚴重問題，可參考如下建議：
(1).客戶的問題、現場的問題，及時記錄彙總，集中抽時間，向研發請教或討論；
(2).測試的問題，登記bug管理平台，集中抽時間，向研發反饋問題，溝通狀況；
(3).專案經理把關，專案經理有責任保護研發團隊的開發工作不受干擾，可以幫助協調處理、登記非必要問題；
(4).研發自我把控，告知相關人員，研發工作相對重要，請將問題記錄，在某天某時找我溝通，確認問題細節；
6.常規功能的常規驗證和提示
問題場景：
有些功能缺失常規的校驗邏輯，基本的驗證邏輯不能得到保障，不合法的資料得不到控制，影響專案的質量。
對於可以明確對應不合法操作或不合法資料的，最好可以提供明確的資訊提示，便於客戶、測試、開發自己理解。
如：表單頁面，兩個起始日期的大小校驗；上傳附件功能，檔案格式校驗、檔案合法校驗(exe程式)、檔案伺服器找不到；
表單錄入儲存，基本的郵箱、手機號碼、輸入長度、輸入型別、非法字元錄入、sql注入等等
解決辦法：
常規功能的常規驗證，可以建立問題知識庫，而不是僅僅存在每個人憑經驗的腦海裡，梳理出來。
研發每次開發常規功能時，要注意邏輯的嚴謹性，確保最基本的驗證必須通過；
測試每次測試常規功能時，必須先把基本驗證，驗證通過才可以進行業務測試或高階測試；
這個可以慢慢的彙總積累起來，可以來自個人、來自團隊、來自外部開放的資源。
7.uat測試通過而生產環境出問題
問題場景：
在uat環境下測試通過的功能，在生產環境下出現問題，除了環境搭建的差異導致問題的其他問題；
在uat環境下測試的資料過於簡單，在生產環境真實的生產資料，發現一些bug和體驗性的問題；
解決辦法：
盡可能模擬生產環境，一些初始化的資料和配置項，嘗試模擬搭建一套生產環境；
盡可能用生產環境的資料進行uat測試，不要做簡易資料的功能測試，盡早發現問題，不要推到生產環境再解決；
8.源**的版本管理
問題場景：
對於要交付的功能，已經開發完畢，測試完畢，**已經穩定，沒有進行發布部署。
繼續進行新功能開發，新功能還未開發完畢，就進行發布部署，在同一套**裡面進行修改。
解決辦法：
需要確保交付的**穩定，做好**分支管理，**版本管理，熟練使用源**管理工具tfs；
需求分析 專案日誌管理系統
使用者故事 專案日誌管理系統 第一次迭代 1，使用者登入，顯示對應使用者管理模組。2，使用者寫日誌。備註 日誌儲存方式 a 本機檔案方式儲存 b 區域網檔案儲存 c 資料庫儲存 3，使用者瀏覽自己的日誌 4，使用者更改登入密碼 5，使用者退出。第二次迭代 1，驗證使用者登入是否是管理員，顯示對應的使...
實訓專案日誌（一）
故事版 動作設計 寒假期間，我們對專案進行了初步的構想。最後將目標鎖定 製作一部三維動畫。寒假完成了劇本內容的設計，形成了劇本初稿。期間，我參與了劇本的設計修改工作。故事以母子親情為主題，講述了母親去世後兒子因思念母親給過去的家撥 後發生的一系列充滿奇幻色彩的感人故事。兒子 少年 青年 中年 老年 ...
專案管理系列一
從技術轉向管理，重點要調整好心態 可以這樣設計提公升的路線 pm 經理人 高層管理運作者 ceo 專案經理的各個方面的能力及其比例 1 溝通能力 84 2 組織能力 75 3 班子建設 72 4 領導能力 68 5 解決問題的能力 59 6 技術能力 46 其實，還有乙個很重要的能力 執行力 對於乙...