最近，因為產品的需要，又開始做一些項目管理的工作，一直認為，各種管理工作都是手段，是為了產品服務的，所以切忌“殺雞用牛刀”，本著夠用就好的原則，和團隊(10多個人，運營占了大半的奇怪組合，呵呵)一起邊做邊設置一些規則，下面是最近我發的一封郵件，加上點評分享一下。 一些事

首先，開發同學工作時間分配的共識：

a) 因為產品屬于“二手房改建”，所以各種Bug和可優化的地方很多，開發很容易被各種零散需求占滿，但產品還處于新生階段，必須強制只留20%的時間給日常bug修復和優化，確保主要精力還是在做一些整塊的需求，保證產品整體是在向前走的(產品進入成熟期，可以把大部分時間留給優化); yixieshi

b) 因為團隊結構里，運營人數很多，之前每位運營都會直接找開發提需求，把開發的工作計劃打亂、碎片化，所以規定運營可以直接找技術，但只限于嚴重的問題，技術不接運營直接提的任何需求，必須走產品人員過一下(必須有人通盤衡量，運營人員通常會站在自己負責的一件事上，把自己需求的優先級無限提高); 互聯網的一些事

c) 技術同學的評估，之前因為經驗不足，會把“工作量”和“工期”混在一起，現在分開，并不是說工作量10人天，2個人做的話，就是5個工作日后發布(也是讓團隊所有人明白兩者的不同);

其次，在公司里找了一個小系統，管理日常的Bug 和優化（積累了幾十條以后，用口頭、郵件什么的管理都是不靠譜的），主要是寫給運營了解的一些原則：

1 優先級判斷

a) 1-urgent，系統大面積不可用，必須馬上改，需要申請緊急發布;

b) 2-high，明顯的bug，需要修改，盡量趕下一次發布; 互聯網的一些事

c) 3-medium，不嚴重的bug，平時過掉;

d) 4-low，優化建議，平時過掉：優化可以用“嚴重程度”字段來表達重要性;

2 使用流程

a) 運營先提給產品，狀態new;

b) 由產品來確定優先級和指派給誰，確認方案，需要修復的，狀態改為open，指派給開發安排，確定“期望修復時間”;

c) 開發修復完成，狀態改為fixed;

d) 產品驗證后，狀態改為closed; 互聯網的一些事

3 系統里的具體條目，產品平時和開發排掉，產品運營雙周會上不討論，需要特別說明的，請錄入者在會上提出：

a) So，需要錄入者會前自己review一下自己提出的條目(如果狀態已經不是new，就說明已經安排了)

b) 平時，每個人都可以隨時去系統里查看自己提出的條目的進展，有異議找產品溝通(前提是，我們團隊有一個產品原則的共識，比如“目標用戶有哪幾種，他們的優先級排序，每個群體的需求又有哪幾類，優先級排序……”); 互聯網的一些事

4 UED也視為技術人員，給UED的需求也用系統管理; 一些事

大家批判著看啊，周邊條件不同，做法一定不同，希望有啟發就好。

鏈接：http://www.yixieshi.com/ucd/12265.html