【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的需求也用系统管理;

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

------------------------------------------------------------如果你想第一时间看到最新内容, 就猛击此处订阅吧!

《【3018】最近对项目管理的一些实践》有17个想法

  1. 苏杰你好,看了这篇日志后,我笑了,因为我目前所在的公司(华为)做法和你说的一模一样,真的一模一样耶,我们用的是notes和teamspace系统,都是从IBM搞过来的,做法和你说的一模一样,希望有一天能加入梦想中的淘宝!!!!!

    iamsujie Reply:

    @seven, 如果我们都应用正确的话,只能说,很巧,我们所处的境遇是相似的,:)

  2. 苏杰,你好!我刚毕业,想做产品,目前只会写代码,所以从写代码开始,逐步接触需求管理,设计,项目管理,运营,推广。但现在只有销售肯录用我,想听听你的建议?

    iamsujie Reply:

    @shine031127, 你先说,你打算怎么做?

  3. 苏杰,你好,我最近正在读你的书,受益匪浅。我在网上在寻找“wbs chart pro”这个软件,但是一直没有找到,下载后都有病毒被删掉了。想问问你,你那有下载的地址或链接吗?能提供给我吗?谢谢!

    iamsujie Reply:

    @快消品也来学, 这个软件很老了,你随便找个画WBS的都行,呵呵

  4. 现在工作中用的是bugzilla后台,运营在此系统中追踪自己的bug状态,一旦开发人员修改bug或产品完成需求开发,置fixed,由运营验证后再置close,运营关闭bug的同时回复所有反馈问题的用户,也算是新版本的小范围宣传,用户也会小有“成就感”~

    iamsujie Reply:

    @狸猫宝宝, 恩,运营关闭感觉不错

  5. @shine031127
    做好销售比做好程序员要难的多了,如果你能好做一名出色的销售人员,对今后项目管理的帮助也是很大的。

  6. 就目前情况,我想通过销售与用户接触,在推广的过程中了解他们的需求,了解产品的不足处,再将意见反馈给产品部门,逐步接触产品设计

  7. 建议使用www.easybug.net进行需求和BUG管理。我们公司现在都使用这一个系统进行BUG管理,效率很高,刚好契合了苏杰提出的这个流程和管理方法。 PS:苏杰说的东西,对于业务系统的建设非常适用。

  8. 应该是redmine吧,我们也刚开始用哈,以为你们早就用这类系统了呢

    iamsujie Reply:

    @fox, 不是你说的,但,这类系统不都一个样么。。。

  9. 需求是否有可能在立项前确定好?如果在开发过程中有需求变更或新增,是需要决策的。这样可以避免不断新增的需求对项目交期的影响,否则产品什么时候能交付呢?

发表评论

电子邮件地址不会被公开。 必填项已用*标注