作為一名qa，跟另一名小夥伴，中途介入乙個專案，對接6+pm，10+rd，還得處理需求上下游的反饋。
各pm說有新需求，上下游pm、qa說，你們系統這、這、那、那有問題，rd說這個模組我優化了一下，
相信你特別忙，疲於應對，即使一天給你48個小時，事情應該也處理不完。
可是，當一周結束，坐下來打算寫週報時，竟發現想不起來這一周都做了什麼，經手的內容，質量也不高。
原因嘛：一，找你的人那麼多，雜事、小事那麼多，根本沒有時間梳理專案邏輯，每次都是忙於應對當前的小點，幹完之後效果咋樣，會不會影響別的模組，我不管，也管不了。
二，那些雜事，小事，你好意思跟你老大匯報嗎，在鍵盤上敲出來，都覺得自己特別low逼。
這樣的狀態持續了一段時間，作為一名幹了3年的qa，之前還帶人，我竟然不知道問題出在哪，只知道自己特別忙，特別疲憊。
後面還是乙個pm跟我聊起研發那邊的**都沒有統一的svn，沒有svn版本，都是基於trunk開發。現在想想其實pm的需求又何嘗有版本的概念。
各路pm，每天圍繞rd，風風火火，私底下把需求跟rd說了，rd寫完**，釘釘找我說一聲，***提測了，你測試一下，***上線。我聽之後，
心想，手上的活還沒有幹完，事先也沒人跟我說，x你大爺的。等等，提測這個事，還是我逐步要求的，之前是沒有的。
作為qa的我處在這樣的環境，有三個選擇。一，找老大說，這個我幹不了；二咬牙幹下去；三，推動改進流程。
方案二持續了一段時間後，在各方的努力下，終於朝著方案三邁進了。
具體方案：
1. 需求源頭唯一化，pm介面人制度：
rd、qa只從乙個pm處接需求，其餘pm的需求統一反饋到需求介面人處。
2. 需求版本+排期：
pm介面人在上線週期前整合所有的需求，進行需求評審，跟rd、qa分別排期。
3. 職責分明，各司其職：
上下游pm之間對接，qa之間對接，bug高效流轉。
4. 分別搭建功能測試、效能測試、預發布、測試環境：
5. 研發**歸入統一的svn，基於分支開發，每天乙個版本。
ps：小技巧
--》擒賊先擒王。推動問題解決時，先要搞定各個團隊有發言權的人，自上而下的推進。
--》每個方案必須有deadline。各方給出方案後，一定要設定deadline（可以是初步的），到期未解決，一定要說明原因，避免隨口應付。
--》定期總結歸檔。
解決專案問題的流程反思
1.要看起來，找綜述等，首先粗略調研問題的背景及發展史，分析每一步發展各自解決了什麼問題，各自貢獻了什麼新的視角或者解決了什麼新的問題？效能？速度？2.根據以上確定當前新的效能較好的解決方案，詳讀對應文獻，最後尋找pytorch實現或其他實現。2018年12月出的pytorch1.0，0.4太老了 ...
解決專案問題的流程反思
1.要看起來，找綜述等，首先粗略調研問題的背景及發展史，分析每一步發展各自解決了什麼問題，各自貢獻了什麼新的視角或者解決了什麼新的問題？效能？速度？2.根據以上確定當前新的效能較好的解決方案，詳讀對應文獻，最後尋找pytorch實現或其他實現。2018年12月出的pytorch1.0，0.4太老了 ...
IT專案流程
1 產品經理確認需求，畫rp 2 ui設計師根據rp出設計稿 並切圖 3 前端工程師根據設計稿和切好的，搭建頁面。前端工程師可以對資源提出自己的需求。4 後端工程師根據rp及功能與前端工程師確認介面，包括每個介面的相關字段，資料字典等，達成一致後，開發介面並撰寫介面文件以供前端工程師使用 5 開發任...