下面的文章與大家共同學習，有些細節是平時我們也講，但沒這麼全面，比如有文字記錄的，要謹慎，邊界不清晰的，可以談，只要是雙方合情合理的，不會過分要求的。
我發現我們可能缺乏比較多的是溝通技巧，以及溝通頻率。終端使用者關懷。
1、在軟體專案實施過程中注重里程碑的確定，制定階段性目標
如果要做好乙個軟體專案，完成專案的驗收條件，主要還是以業務是否可用作為衡量的。不是一定得實現所有使用者的需求（這裡指的是口頭上的需求，如果落實到文字上的還是要實現的），也不是只有將一些所謂的技術難點解決使用者就會同意驗收，而是可以完成一定的階段應用業務目標。
進行需求調研的時候就要主動控制專案的邊界，將乙個乙個業務流根據客戶方的實際情況合理組織實施順序，形成軟體專案實施計畫中的里程碑點，明確達到里程碑點的條件，並得到雙方一致正式認可。
沒有雙方高度達成一致的里程碑認可（確定階段目標是非常重要的），也就是沒有專案目標約定，沒有目標約定的專案實施計畫一定會經常變更內容、變更初始設定目標，導致計畫不可控制，更談不上驗收。
很多人希望通過詳細的系統需求規格說明書來定義專案要實現的內容和業務目標，這是很有必要的，但需求規格說明書得到認可並非是通過使用者審核就可以的結果，應該想辦法讓使用者一起參與到需求規格說明書的制定過程中來，變成使用者自己推導出來的業務實施目標，未來才不容易變形。
2、積極主動地與客戶進行溝通
專案中一定要有溝通策略，和高管如何匯報工作進展，取得支援？和中層如何就業務目標不斷確認，逐步清晰？和基層如何就專案應用操作模式達成一致，持續改進？都需要通過溝通反饋完成。
溝通的作用對於高管是讓他們清楚專案一直按照目標前進，每個階段工作進展是否順利，影響專案正常運做原因是什麼，需要哪些資源幫助。和高管溝通比較多的話，第乙個好處是高管經常聽匯報就知道專案進展程度，可以安排反饋檢查，看是否具備專案所說的進展，這樣一旦認可了各個階段目標後，最終要求高管簽字確認也就順理成章了。
給高管匯報技巧就是簡潔明瞭，真實客觀，有理有據分析問題，提出對策建議請其決策即可。
中層往往是專案主要的推動力量和實際執行者，也往往是對具體業務需求最主要的要求者，他們對企業實際運做過程最清楚，提出要求最具體，而且專案驗收與否沒有中層的同意往往也是不太容易做到的。
往往通過前期業務調研只能對企業專案目標有乙個大的，巨集觀的認識，但如何細化並最終落實並非是一步到位的過程。因此在整個專案過程中，雙方專案組要不斷溝通，特別是企業中層溝通，才能逐步認識越來越深刻，最終達成一致。
和基層的溝通主要體現對
終端使用者的關懷
，定期主動和終端使用者溝通，消除一些怨氣，
讓使用者能堅持用下去
，這個時候往往發現很多使用者真的是非常好相處，儘管軟體還有很多值得改進的地方，但他們一旦認可團隊，反而會盡心盡力幫助推動專案的進行。
目前一般要求每個專案經理在專案進行中都要填寫詳盡的專案月報，反映專案的進度，與計畫的偏差，完成的專案內容，投入人力，目前專案存在的問題，以及預計專案下月的進度等等。將進度月報交部門負責人、
專案管理
中心、總經辦審閱。
類似地也要
制定針對客戶的月報甚至是週報
，將相關的資訊反應到客戶方的負責人，及相關高層。可以先發郵件，然後還要**落實收到並口頭簡要匯報，特別是高管層，千萬不要以為發了就等於別人會去看，一定要口頭跟進匯報一次，保證客戶各方面負責人對專案進展做到心中有數。
在專案的過程中，也需要注意平時做人的積累，比如要做到講誠信，講原則。主要是三條：
1）做不到的事情千萬別隨意承諾；
2）承諾的事情一定要努力做到；
3）每次做到的事情都進步一點點。按這三條做事，即使在系統的使用過程中總會有這樣或那樣的一些不方便，使用者也會慢慢接受稍微長一點的響應週期，也會用更多積極性眼光看現在的問題，也相信問題一定有人響應，也一定可以得到解決。進而使賣方和客戶之間形成一種較為和諧的關係。
3、寫好備忘錄和問題跟蹤記錄
在乙個漫長專案週期中，很多任務作做了也就做了，認可了也就認可了，時間一長也就忘記了很多承諾和約定，到了驗收的時候就可能重新翻出來，這種事情很多人可能都經歷過，明明說可以先不做的內容最終驗收的時候又成了必要條件。
每次備忘錄要口頭交流認可後才列印簽字確定階段性工作成果。下次工作則根據前次備忘錄的雙方約定繼續進行，保障專案在每次工作基礎上不斷前進，並用備忘錄約束雙方的行為。
同時建議在收集專案出現的各種問題時，採用問題跟蹤記錄表的形式，這樣可以一目了然地顯示出曾經收集到的各種問題，目前的解決情況，以及還有什麼問題沒有解決，準備什麼時候解決。這樣客戶和賣方都會對目前的情況非常了解，通過不斷地解決出現的問題，來收斂可能出現的問題，當存在的問題越來越少時，也就表示系統已經在接近驗收的標準了。
4、驗收階段的準備工作及注意事項
做乙個詳細的驗收計畫是非常必要的，可以用來作為驗收階段的工作指導。這就需要與客戶進行詳細的溝通，再次明確驗收前需要完成的工作，盡量避免客戶方在此階段提出過多的更改需求，這是極為重要的。驗收計畫中不光要有需要繼續完成的工作，還需要有乙個相對固定的工期，使雙方都繼續朝著這個方向去努力，防止無限制的拖延。
專案驗收對任何乙個專案管理者都是乙個極大的挑戰，即使已經採取本文提到的幾種手段，也不能保證專案能夠順利驗收
adb 命令 之 Pm 相關
檢視應用列表的基本命令格式是 adb shell pm list packages f d e s 3 i u user user id filter 即在adb shell pm list packages的基礎上可以加一些引數進行過濾檢視不同的列表，支援的過濾引數如下 引數顯示列表 無所有應用 ...
QPM 之同類 PM 對比
qpm 的注意事項以及和其他同類 pm 類軟體的對比。qpm 的懸浮窗如果開啟過多的功能，可能會影響效能，推薦 需要什麼功能，就開啟什麼開關，這樣把影響降低到最低。與其他同類 qpm 工具相比，有以下優勢 內建多個引數指標開關，想用哪個就開哪個 精簡模式，只顯示關注的資料指標 螢幕錄製 h5頁面效能...
軟體測試基本方法（七）之驗收測試
驗收測試是在功能測試和系統測試之後進行的，所以驗收測試的前提條件是系統或軟體產品已通過了內部測試。然後和使用者一起驗收軟體，在真實環境下執行軟體，看是否存在與使用者需求不一致的問題或違背產品規格書的要求。由於測試人員不可能完全使用者實際使用情況，所以軟體是否真正滿足終端使用者的要求，應由使用者進行一...