蘇杰:最近對項目管理的一些實踐
最近,因為產品的需要,又開始做一些項目管理的工作,一直認為,各種管理工作都是手段,是為了產品服務的,所以切忌“殺雞用牛刀”,本著夠用就好的原則,和團隊(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
- 目前還沒評論,等你發揮!