该帖子同步发自：(飞眉的博客  访问该博客)

　　最近，因为产品的需要，又开始做一些项目管理的工作，一直认为，各种管理工作都是手段，是为了产品服务的，所以切忌“杀鸡用牛刀”，本着够用就好的原则，和团队(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的需求也用系统管理;