【3018】最近对项目管理的一些实践

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

大家批判着看啊,周边条件不同,做法一定不同,希望有启发就好。

产品设计体会(3016)一个只有七天的项目

为了写书,我在翻看几年来的邮件,找到了一个只有七天的项目,光从项目日报里,就让我觉得那几天奋斗的时光恍如昨日:

2009323日星期一,我接到一个任务,说为了配合331日下周二的新闻发布会,要做一个项目。我做过不少这种救火队员式的任务,每次开始的时候老板总能让我的嘴张成一个O型——这怎么可能么,但结束的时候我们也屡次让老板的嘴张成O型——居然真做到了!

一大早接到任务,迅速的四处找人组建临时团队、制定时间计划、讨论项目方案……我一直是反对加班的,但在这种情况下,晚上晚点走也是不可避免的了,不过,我的计划中仍然留了余地:争取周五完成上线的准备,周末尽量不加班,下周一机动。我们直接看邮件来感受一下当时的情况吧。

主题:第1/7天,魔方计划2.0,项目进展汇报:

发送时间:2009323 21:16

Hi all,项目一共只有7个工作日,一切从简,尝试自由体日报。

今天主要进展如下:

1. Kick Off完成;

2. 项目范围与方案确定;

a) 数据提取与分析,确认项目方案(详见附件);

b) 某功能决定免费,账号数上限取消;

c) 魔方计划1.0遗留问题加入项目:更新帮助、修改“新手上路”、替换首页广告及链接;

d) TK(业务有关,不便透露,用字母替代,后面还有一些类似的。)相关问题另起项目,3月31日之前只对用户做告知。

3. 需求写作;

a) 附上PRD,明早评审。

4. 团队组建;

a) 开发同学(某某某、某某)搬到8楼,大家集中办公;

b) 测试资源在明天需求评审完成后确认。

5. 知会周边干系人。

a) 某某搜索引擎某某某

b) 某某产品:某某、某某某。

明天重点预告:

1. 需求评审;

2. 进入设计与开发。

主题:第2/7天,魔方计划2.0,项目进展汇报:

发送时间:2009324 22:44

Hi all,今天是项目的第2/7天,晚上大家辛苦,感谢肯德基全家桶的支持,进展如下:

1. 上午需求评审 & 确认完成;

a) 下班时需求冻结,终稿见附件。

2. 下午进入开发阶段;

a) 只有16工作小时,周四中午提交测试;

b) 明天下午TC评审。

3. 测试人员确定;

a) 某某 + 半个某某某,可能需要周末加班,先说一句辛苦了;

b) 存在人员不足的风险,随时监控,周五晚、周日晚为两个监控点。

4. 相关事宜的跟进。

a) 财务同学跟进修改用户协议;

b) 服务同学修改帮助;

c) 某某方案制定;

d) 培训事宜跟进;

e) 配合运营整理MF与TK的材料。

主题:第3/7天,魔方计划2.0,项目进展汇报:

发送时间:2009325 20:19

Hi all,今天是项目的第3/7天,进展如下:

1. 开发;

a) 晚上部分功能提前半天提交测试,感谢同学们的努力。

2. TC评审;

a) 来了6位测试的同学把关,感谢大家的支持。

3. 相关事宜的跟进。

a) 财务同学修改用户协议,周五下班前提交;

b) 服务同学修改帮助;

c) 某某方案制定,原则确认;

d) 配合运营整理MF与TK的材料,某某某负责制作页面;

e) 培训事宜跟进。

主题:第4/7天,魔方计划2.0,项目进展汇报:

发送时间:2009326 19:52

Hi all,今天是项目的第4/7天,进展如下:

1. 开发:

a) 全面提交测试,据测试同学说质量不错,感谢大家;

2. 测试:

a) 截至下班时,比计划稍有领先约1/3工作日;

目前一切顺利,但项目时间已经过半,更加容不得任何闪失,+U+U~~~

主题:第5/7天,魔方计划2.0,项目进展汇报:

发送时间:2009327 18:04

Hi all,今天是项目的第五天,进展如下:

1. 第一轮测试完成,Bug全部修改完毕,等待下周二,配合新闻发布会上线。

2. 周末测试的同学会加班再测一轮,其他人员待命。

3. 下周一团队临时解散一天,下周二集合发布,谢谢大家。

之后的周末没有碰到大问题,第六天空出来了,第七天的发布也很顺利。这是我喜欢的风格,先紧后松,但,又有多少次能这么幸运呢。