最近，因為產品的需要，又開始做一些專案管理的工作，一直認為，各種管理工作都是手段，是為了產品服務的，所以切忌「殺雞用牛刀」，本著夠用就好的原則，和團隊（
10多個人，運營佔了大半的奇怪組合，呵呵）一起邊做邊設定一些規則，下面是最近我發的一封郵件，加上點評分享一下。
首先，開發同學工作時間分配的共識：
a) 因為產品屬於「二手房改建」，所以各種
bug和可優化的地方很多，開發很容易被各種零散需求佔滿，但產品還處於新生階段，必須強制只留
20%的時間給日常
bug修復和優化，確保主要精力還是在做一些整塊的需求，保證產品整體是在向前走的（產品進入成熟期，可以把大部分時間留給優化）；
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的需求也用系統管理；
大家批判著看啊，周邊條件不同，做法一定不同，希望有啟發就好。
對專案管理的一些記錄
明確專案所解決的問題或輸出的產品，服務 明確專案的相關干係人 明確專案的風險，如果專案失敗了，延期了，會造成什麼樣的影響 明確專案所涉及的資源，包括人員資源，時間資源等 明確專案輸出對其他專案 產品 的影響，明確專案 產品 依賴關係等 專案目標 專案驗收標準 演示,文件,測試報告等 專案關鍵里程碑 ...
最近專案的一些事兒吧
首先不是吐槽,不是不想吐槽,因為是無力吐槽,水平有限,沒資格吐槽.就說說最近的一些問題和總結吧 自己比較喜歡簡潔爽約的 和架構,合理的注釋,合理的命名.清清爽爽,便於 的開發和維護.個人感覺良好的編碼風格和習慣是乙個人的職業素養和基本功的體現 下面根據這段時間遇到的問題標註一下吧 1,android...
專案管理一些體會
專案管理需要的知識，是乙個體系的知識，包括專案管理本身的知識體系，以及專案管理要應用到的領域所需要的知識體系，然後就是管理的技能，當時最重要的，是軟技能，也就是人際關係技能。管理的核心 人。管理的四大要素 1.選擇正確的人 2.為他們分配正確的工作 3.保持他們的積極性 4.幫助團隊凝聚起來並保持團...