一．背景
今天和研發(fā)主管宋和產品經理支溝通工作安排和進度的時候，了解到了幾個問題，梳理了一下，這些問題回過頭來看，其實這一直是我們團隊一直有的問題，它嚴重阻礙了研發(fā)團隊的效率和質量。
1.研發(fā)主管告訴我，天天很忙，但不知道在忙什么，忙到椅子都坐不下來，每件事都是緊急的事，都是要馬上辦的事情，可是領導交代的事情，卻沒做。我說你現(xiàn)在的工作狀態(tài)和我在臺里的時候很像，你要有一個工作主線，例如用戶畫像，說了很久了。宋說心里天天記著這件事，但是天天又有新的緊急的事，沒有時間。
2.產品經理告訴我，榜單工作做得也很累，文檔也寫了，評審會也開了，需求一條一條的過，研發(fā)當時明確了，也說理解了，可做出來還是錯，做的過程中不清楚也不溝通。
一個BUG，上午催了研發(fā)不回，下午再催研發(fā)說“也不是不能改”，輕描淡寫，讓人無語。
前端做完了不自測，需求不理解也不溝通，一定等上線后，支親自測，親自指出問題，才來想辦法改。一問又扯一堆技術細節(jié)，這是研發(fā)的通病！所以支一直陷在細節(jié)里面，非常疲憊。
我想:
雖然團隊目前只有10幾個人，而且很多人認為，我們還是個小作坊，有小作坊自己的運行模式。但是我認為，團隊再小，但崗位工種已經初步完備，工作已經開始是流程化了：產品文檔、后端開發(fā)、前端實現(xiàn)、測試驗收。一個環(huán)節(jié)出了問題，直接影響下游的工作。但是，又由于每個人的責任心和認知是不一樣的，正是因為流程化了，責任心和能力所產生問題就理所應當的向下傳遞了，這就導致越有責任心的越累，工作效率也非常低。
所以，在梳理出問題后，我思考了如下解決方案：
二．關于研發(fā)主管忙得不知道要做什么的問題?
針對宋的問題，我的想法是，感覺上每件事都很緊急，其實是因為沒有一個緊急工作的評定標準和一個有效工作排期機制，工作無法自己判斷主次，又不及時上報溝通，導致自己不知道在忙什么，領導也不知道你在做什么，要求做的卻沒做。所以應該從制度上解決這個問題。
工作分為規(guī)劃性工作和臨時性工作：
規(guī)劃性工作是有明確的時間節(jié)點，有一定的執(zhí)行時間跨度，具體執(zhí)行人在明確的時間節(jié)點內，合理的安排自己的工作計劃。
臨時性工作是突發(fā)的，需要這這些種類型的工作做一個緊急性評判預設：
1.影響日活和收入（成本）的工作，例如CDN防盜鏈被嚴重突破、客戶端閃退，列為緊急工作，需要立即上報并處理
2.政治性問題，涉及到內容安全，誘發(fā)政治問題的需求或bug，需要立即上報并處理
3.其他工作，應該主動和上級或產品溝通，獲取明確的安排。
上報和溝通不是追責，而是化解責任，不應該有心理負擔。
研發(fā)與產品、上級溝通很重要。正是因為沒有溝通，有些事站在更高層面來看，并不是特別緊急的，急著處理了。有些事看來不在眼前，但是從團隊層面上來說，卻是應該花精力立即去攻關去盡快解決的，變得遙遙無期。
所以，在設定并全員了解緊急工作的評定標準后，還應該建立一個快速流動運轉的需求池，有些產品經理可以決定排序，產品經理決定不了的，讓主管來決定排序，這樣工作才能有序，大家的目標才能對其。但這個工作池需要高效，否則扭轉的效率就低了。
一句話，工作需要密集的溝通，溝通的目的不是匯報，是給預期和了解預期。
另一句話，所有的需求，都應該是由產品來對接，研發(fā)永遠不能和運營直接溝通。因為產品的責任就包括需求的整理和優(yōu)先級的設置。研發(fā)則應該是在和產品溝通商定后，堅決執(zhí)行指定好的工作目標。
三．針對產品經理“陷入研發(fā)執(zhí)行細節(jié)”的痛苦?
首先我堅定一個信念，這個問題在其他研發(fā)團隊里肯定是普遍存在的，但一定是得到了解決的。
在和彭一的溝通后，我整理出如下方案：
1.產品在輸出文檔時，不僅僅是解釋需求，是要拆解需求形成功能點，最重要的是每個功能點要有“驗收條件”。?
例如產品設計一個計算器，用戶輸入1+1，結果必須等于2?！暗扔?”就是驗收條件。
驗收條件是對于研發(fā)來說是目標，也是緊箍咒。
[if !supportLists]2.[endif]研發(fā)根據產品文檔各個功能點的“驗收條件”，編寫實現(xiàn)代碼的同時，必須同時編寫“測試用例”代碼，用于代碼自測。
從制度上，如果研發(fā)不編寫測試用例或謊報測試用例，則應該被嚴重的警告、扣分，甚至被優(yōu)化掉。
在**公司，80%的測試用例代碼是由研發(fā)提交的，測試團隊只是站在更高的維度考慮全局產品的穩(wěn)定性和質量，來編寫測試用例。
3.有限次數的輪測機制
為研發(fā)設置提測限制，研發(fā)自測完成后提測，最多不超過2輪，第3輪提測應該就是完善的代碼。再出問題就需要被處理，被考慮是否是能力或態(tài)度的問題了。
四．用工具來實現(xiàn)想法、規(guī)范流程
為了實現(xiàn)上面的想法，我們必須逐步引入流程性生產工具，當所有工具都開始使用，并發(fā)揮價值后，我們就實現(xiàn)了devops。
devops不是開發(fā)工具集，是人+流程+工具的一種研發(fā)理念。
我越發(fā)的感受到，研發(fā)能力是在優(yōu)秀的流程引入并落實的結果，并不是要等研發(fā)能力的提示再來引入新的研發(fā)流程。
所以，我給自己設定了一個目標，用1-2個月的時間，在今年3月底前，先把研發(fā)單元測試、自動化測試制度和所需的Jenkins工具，落地落實。
幾個補充：
1.工作任務的拆解，是研發(fā)工作中非常重要的一環(huán)。一個功能點，必須是限定在2天以內，如果超過2天，那么功能點拆解有問題，需要進一步拆解。
首先工作任務的拆解是產品和研發(fā)共同的工作。拆解在評審會上，商討完成并進入管理平臺。
將需求詳情的拆解為功能點，并限定功能點為2天，最重要作用是產品迭代“小步快跑”的基礎。
在**公司，2周研發(fā)執(zhí)行開發(fā)，2周測試和產品驗收，幾乎都能按計劃進行迭代，原因就是工作量的精準量化。產品會知道什么功能需要多久，應該分幾個版本。而不是一個需求，一做一個月，然后測試半個月，我們設置的每個月16號迭代，很少有準時的情況，原因就出在這。
2.研發(fā)寫測試用例
開始研發(fā)寫測試用例，時間是慢的。一般來說，一般要用1個月的工期，第一次引入測試用例編寫，會花到1.5個月。但隨著版本迭代，編寫測試用例的研發(fā)團隊迭代效率，會是不編寫測試用例的2-3倍。
針對二手代碼沒有測試用例的問題，彭一解釋，只能補，也必須補。因為這些沒有通過自動化測試的代碼，不知道什么時候就是個坑，必須統(tǒng)一納入體系中來。
