我的项目管理最佳实践

项目管理的作用对象是项目团队(当然也有项目外部的干系人,本文只针对项目团队),最好的项目管理应该是让团队有清晰统一的目标、亲密无间的团队协作,团队成员各司其职,在舒适的心理状态下(良好的人际关系),同仇敌忾,为同一目标不懈努力。这一前提的关键是经过不断探索和磨合,找到适合团队的项目管理最佳实践,并雷打不动地执行最佳实践。由此,团队将越来越好,越来越亲密无间。

下面总结梳理一下我自己跟踪项目的最佳实践。正是因为这个最佳实践,让团队中的每个人每天在逗逼开心中,完成着几乎不可能的进度。期望也对大家有帮助:

一、项目立项阶段:一致认同的产品定位

虽然此阶段还不涉及写代码等实现层面的工作,但对产品定位的清晰认识和认同,是帮助团队成员在后期实现中寻找成就感、理解细节需求的必要条件。
若仅在后期实现时,开发人员才接触到产品,他们一定会被淹没在细节需求和如何实现需求中,最后演变成,他们自己不知道自己做的是个神马东西。如此,成就感何来?当他们理解了产品的定位,一开始就知道大概的业务,对他们后期理解需求,绝对有很大的帮助,且能够站在技术实现的角度给产品设计提出很好的建议。如此,何乐而不为?
此阶段产品人员一般要输出MRD  BRD 竞品分析等文档,但对项目组来说,一份精简的产品规划书就够了。具体有哪些内容,可参考上一篇文章《如何用一份产品规划书代替BRD、MRD 竞品分析?》或下图:
我的项目管理最佳实践
通过项目组内评审讨论,达成共识的产品规划书,是此阶段的最终产物。

二. 项目实施阶段有条不紊的迭代步伐

1. 清晰的迭代流程

清晰的迭代流程,标准的迭代周期帮助团队成员掌握工作的步伐,保证大家在同一频道上。
每次版本迭代逃不掉的流程有:
我的项目管理最佳实践
(1)如何确定需求范围?
产品经理根据自己的判断,以一个月为周期(视情况而定,不同公司、团队, 长度不同),从backlog中挑出若干个优先级高的需求,形成细化版的版本需求列表。版本需求列表与backlog的区别在于,产品对每个需求的细节逻辑经过了更深入的细化和描述,能够很清楚地告诉团队,这个功能是做什么的,业务逻辑是怎样的,方便团队判断技术难度和研发周期。
我的项目管理最佳实践
产品出具此列表后,召集团队进行评审。评审过程中,一般会砍掉或替换一些需求。经过评审后,团队就此次迭代的目标和范围有了清晰的认识和共识。除非非常极端的情况,达成共识的需求列表不轻易做变更。
(2)如何细化需求?
迭代范围确定后,进入需求细化、PRD设计阶段。
细化需求的步骤是什么?应该注意的点有哪些?可参考文章《当我们接到一个新需求点时,应遵循的需求分析步骤有哪些?》。不再赘述。
(3)如何管控研发阶段?
进入研发阶段后,工作的大头从产品转向研发。此时管控的对象从自己转向了别人。最好的管控就是积极参与到他们的工作中。为此,产品应积极参与到研发工作中,主要有两点:一是,积极帮助研发人员理解需求,有求必应,帮助研发解决一切影响他们工作的外部因素(此时像一个“家庭管家”的角色);二是,帮助研发人员走查测试功能点,这不仅帮助研发节省时间和精力,也将大部分问题扼杀在摇篮里,减轻后期测试的风险。
(4)如何管控测试工作?
测试工作有两部分重要的工作内容:一是编写测试用例,通常需求确定提交研发后,测试人员开始进行此项工作。此时,产品要积极帮助测试人员理解需求,保证用例的全面准确性。要知道,高质量的测试用例,是高质量测试结果的前提。若迭代时间允许,团队可就编写完的测试用例进行评审,评审的过程又是项目组理解需求,发现问题的一次机会。第二项主要的测试工作就是,对版本功能进行测试验收,并出具测试报告。在研发人员提交测试人员前,产品应先走查主流程是否走通。只有主流程通常后,才可正式提测。
(5)如何组织内部测试?
测试完成后,测试人员出具正式测试报告。产品根据测试报告,判定是否可上线(通常结果都是YES,因为影响上线的大bug应在早期就发现并解决,不可能留到最后才发现)。若需要组织内部测试,则先更新内测环境,并通知安排相关部门进行内测。这一步骤是可选的,如此次迭代属于技术上的化造,则无需内测。
(6)如何进行上线验收?
内测结束后,重要的bug修修补补后,即可上线正式部署,部署后产品需第一时间在正式环境走查。此步骤必不可少,产品千万不可偷懒,认为测试都测过了,不用走查。走查的目的是,避免因部署系统时,参数配置错误导致的bug。这些bug在测试时,无法覆盖。
(7)如何对外发布?
验收无问题后,功能就算正式上线,要面向用户使用了。此时需要产品给运营、市场等外部干系人正式发出发布说明。说明一般交代此次更新的功能是什么?有什么注意事项等。

2. 轻巧灵活的站会

同步信息是保证大家齐力同心目标一致的前提。站会无疑是很有效的信息同步方式。
(1)组织者
由产品经理把控和组织
(2)频率
至少两天一次。若觉得有必要,如每天都有新功能完成(这可是很重要的节点和信息呢),可一天一次。
(3)长度
时间长度应掌控在十五分钟以内,最长不要超过20分钟,否则,就丧失了效率。我一般控制在十分钟内。
(4)时间
一般为早上上班十五分钟后或晚上快下班前,不建议选择一天中的中间时刻。
(5)主题
主题有三个,即昨日进展、今日安排、问题障碍。

  • 昨日进展 指每个人昨日任务的完成情况,如XX功能已做完;XX功能完成40%等。
  • 今日安排 指每个人今日要做的任务有哪些?通常是大功能的拆分,由技术负责人进行并分派给各个研发负责。
  • 问题障碍 指每个人在完成任务时遇到的问题 或项目组遇到的外部影响因素。

这三个主题帮助项目组成员了解其他人的工作情况,也帮每个人了解项目的状况。对问题和障碍,若需要群策群力,则大家一起讨论解决;若只是小范围的问题,则进行点对点的沟通解决;若涉及到外部影响因素,则产品要积极进行推进和解决。
(6)决议
有会议就应该有决议。此决议可用于领带汇报,也可同步到项目组交流群。每次站会开完后,产品话几分钟时间输出总结:
我的项目管理最佳实践
应注意, 站会不是大家向项目主管汇报工作的形式,而是项目组内相互同步信息的信息交换机制,产品经理作为组织者,要做好气氛的调节。比如一句逗逼的话语和表情结束会议,也开启了小伙伴们一天的美好心情。

3. 实时更新的Task Board

任务墙是很常规的任务跟踪方式。网络上有很多此方法的解说,每个人在使用中都会创新和寻找适合自己的方式。我的做法是:

  • 买一张白板,放在项目组座位范围内。买一些便利贴用来写任务。
  • 横轴为任务状态:todo(已分配在手上,还没开始着手做的)、doing(正在做的)、testing(已完成可提交测试的)、done(已测试完成可上线的)。纵轴为姓名:开发、产品、前端、UI 等所有项目组成员。
  • 每个人每天根据情况更新便利贴内容,并贴在相应的位置。

我的项目管理最佳实践
通常站会和Task Borad结合使用。站会时大家围着白板讨论。
诚然,项目性质和团队大小等因素不同,流程和操作方式也不尽相同。比如toB项目跟toC项目,迭代流程会有较大差异。
除标准的流程和操作外,在日常的沟通工作中,或许应时刻谨记:
(1)多问观点背后的原因
当与开发、UI观点不一致时,先不要判断谁是谁非。仔细聆听他人观点背后的原因、他为什么觉得应该是这样?由此,可相互补充,使得方案更加完善。且在沟通的过程中,能够帮助自己了解到开发、设计方面的知识,是很好的补充自己知识盲区的方式。
(2)荣辱与共,相互扶持
应该知道,同一项目组是荣辱与共,不问谁是谁非,只关注团队共同的成果的。外界对每个人成果的评价,也是建立在团队成果的基础上。因此团队成员之间应该是相互扶持,共同解决项目遇到的任何问题,而不是干产品的,需求完了就没自己什么事了;开发做开发的,做不完是他们的错。绝不是这样的。
以达到团队目标为基准,提高团队工作效率的方式方法就是最好的管理。营造轻松快乐的工作环境,让团队在舒适的状态下高效运转的方式方法就是最好的管理。
 
文 @小麻雀 

关键字:项目管理, 测试

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部